When to use a key-value data store vs. a more traditional relational DB?

Question

When would one choose a key-value data store over a relational DB? What considerations go into deciding one or the other? When is mix of both the best route? Please provide examples if you can.

Answer 1

A traditional relational database has problems scaling beyond a point. Where that point is depends a bit on what you are trying to do.

All (most?) of the suppliers of cloud computing are providing key-value data stores.

However, if you have a reasonably sized application with a complicated data structure, then the support that you get from using a relational database can reduce your development costs.

Answer 2

In my experience, if you're even asking the question whether to use traditional vs esoteric practices, then go traditional. While esoteric practices are sexy, challenging, and fun, 99.999% of applications call for a traditional approach.

With regards to relational vs KV, the question you should be asking is:

Why would I not want to use a relational model for this scenario: ...

Since you have not described the scenario, it's impossible for anyone to tell you why you shouldn't use it. The "catch all" reason for KV is scalability, which isn't a problem now. Do you know the rules of optimization?

1. Don't do it.
2. (for experts only) Don't do it now.

KV is a highly optimized solution to scalability that will most likely be completely unecessary for your application.

Answer 3

Key-value, heirarchical, map-reduce, or graph database systems are much closer to implementation strategies, they are heavily tied to the physical representation. The primary reason to choose one of these is if there is a compelling performance argument and it fits your data processing strategy very closely. Beware, ad-hoc queries are usually not practical for these systems, and you're better off deciding on your queries ahead of time.

Relational database systems try to separate the logical, business-oriented model from the underlying physical representation and processing strategies. This separation is imperfect, but still quite good. Relational systems are great for handling facts and extracting reliable information from collections of facts. Relational systems are also great at ad-hoc queries, which the other systems are notoriously bad at. That's a great fit in the business world and many other places. That's why relational systems are so prevalent.

If it's a business application, a relational system is almost always the answer. For other systems, it's probably the answer. If you have more of a data processing problem, like some pipeline of things that need to happen and you have massive amounts of data, and you know all of your queries up front, another system may be right for you.