What does "Document-oriented" vs. Key-Value mean when talking about MongoDB vs Cassandra?

What does going with a document based NoSQL option buy you over a KV store, and vice-versa?

A key-value store provides the simplest possible data model and is exactly what the name suggests: it's a storage system that stores values indexed by a key. You're limited to query by key and the values are opaque, the store doesn't know anything about them. This allows very fast read and write operations (a simple disk access) and I see this model as a kind of non volatile cache (i.e. well suited if you need fast accesses by key to long-lived data).

A document-oriented database extends the previous model and values are stored in a structured format (a document, hence the name) that the database can understand. For example, a document could be a blog post and the comments and the tags stored in a denormalized way. Since the data are transparent, the store can do more work (like indexing fields of the document) and you're not limited to query by key. As I hinted, such databases allows to fetch an entire page's data with a single query and are well suited for content oriented applications (which is why big sites like Facebook or Amazon like them).

Other kinds of NoSQL databases include column-oriented stores, graph databases and even object databases. But this goes beyond the question.

See also

• Comparing Document Databases to Key-Value Stores

• Analysis of the NoSQL Landscape

Well, I've been investigating NoSQL myself the past month or so. I think it generally could be stated something like

• KV stores doesnt know of the value content actually stored for a key
• Document based lets you define secondary indexes within the value content, as the db knows the document structure (e.g. tags of a blog post).
• NoSQL solutions each have specific features which should be taken into consideration, such as
• Special datatypes in a KV store (e.g. sets with left/right pop/push like in redis)
• easy scale up/down cluster as riak says it has (I havent tried it ... yet)
• pluggable data store as in Voldemort
• build-in web configuration and web app support like in CouchDB / couchapp

1. In the key-value database model, users can choose what the keys are, whereas the document identifiers in the document model are typically system-generated.

2. The key-value pairs in the key-value database model cannot be grouped whereas, in a document database, we can group key-value pairs into separate documents; moreover, some forms of document databases allow us to even group these documents further, namely into so, called "collections" or "domains".

3. While the documents in a document database have an internal structure that is clearly defined (and, thus, can be operated on by the DBMS; for instance, to create indexes), the same is not the case for the values in a key-value database where any possible internal structure of such values is opaque from a DBMS perspective.

4. In the key-value model, access to multiple database entries (key-value pairs, in this case) requires separate requests. In the document model, on the other hand, multiple database entries (documents, in this case) may be retrieved in a single request.