What does going with a document based NoSQL option buy you over a KV store, and vice-versa?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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