What does "Document-oriented" vs. Key-Value mean when talking about MongoDB vs Cassandra?
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
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 valuecontent actually stored for a key
- Document based lets you define secondaryindexes within the value content, asthe 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
In the key-value database model, users can choose what the keys are, whereas the documentidentifiers in the document model are typically system-generated.
The key-value pairs in the key-value database model cannot be grouped whereas, in adocument database, we can group key-value pairs into separate documents; moreover, someforms of document databases allow us to even group these documents further, namely intoso, called "collections" or "domains".
While the documents in a document database have an internal structure that is clearlydefined (and, thus, can be operated on by the DBMS; for instance, to create indexes), thesame is not the case for the values in a key-value database where any possible internalstructure of such values is opaque from a DBMS perspective.
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 databaseentries (documents, in this case) may be retrieved in a single request.