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

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 months ago.

The community reviewed whether to reopen this question 7 months ago and left it closed:

Original close r开发者_StackOverfloweason(s) were not resolved

Improve this question

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

---

The biggest difference is that a document-oriented database supports secondary indexes, K/V does not. In general, document-oriented dbs tend to allow richer queries, allowing things like range queries, sorting, and other types of "advanced" operations.

---

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.