I've been looking at the wikipedia page for NoSQL and it lists several variations on the Key/Value store database, but I can't find any details on what it means by Key/Value store in this context. Could someone explain or link an explanation to me? Also, when would I use such a database?
Are you familiar with the concept of a Key/Value Pair? Presuming you're familiar with Java or C# this is in the language as a map/hash/datatable/KeyValuePair (the last is in the case of C#)
The way it works is demonstrated in this little sample chart:
Where you have a key (left) and a value (right) ... notice it can be a string, int, or the like. Most KVP objects allow you to store any object on the right, because it's just a value.
Since you'll always have a unique key for a particular object that you want to return, you can just query the database for that unique key and get the results back from whichever node has the object (this is why it's good for distributed systems, since there's other things involved like polling for the first n nodes to return a value that match other nodes returns).
Now my example above is very simple, so here's a slightly better version of the KVP
So as you can see the simple key generation is to put "user" the userunique number, an underscore and the object. Again, this is a simple variation, but I think we begin to understand that so long as we can define the part on the left and have it be consistently formatted, that we can pull out the value.
Notice that there's no restriction on the key value (ok, there can be some limitations, such as text-only) or on the value property (there may be a size restriction) but so far I've not had really complex systems. Let's try and go a little further:
You get the idea... all those would be stored in one massive "table" on the distributed nodes (there's math behind it all) and you would just ask the distributed system for the value you need by name.
At the very least, that's my understanding of how it all works. I may have a few things wrong, but that's the basics.
obligatory wikipedia link http://en.wikipedia.org/wiki/Associative_array
If you have a relational database, then you can easily experiment with this:
This is how all databases used to be, with Berkeley DBM being a good example, from 1979. Since then, things have advanced (you can have many values per key in any RDBMS). For many applications a key-value store is sufficient (e.g. this is how sendmail stores its aliases). But if you find yourself pre-processing the value in your own code (or concatenating strings to make your "key"), perhaps splitting the value on a delimiter or parsing it, before you can use it, you will probably be better off with an RDBMS and actually storing it that way.
I assume you have basic understanding of NoSQL movement and non-relational databases models.
Key Value store is one of the non-relation database model, like graph, document oriented database models.
View below slides/articles and you'll get an idea, when, why and why not use key value store :)
In SQL terms, a NoSQL database is a single table with two columns: one being the (Primary) Key, and the other being the Value. And that's it, that's all the NoSQL magic.
You would use NoSQL for one main reason: scalability.
If your application needs to handle millions of queries per second, the only way to achieve it is to add more servers. That is very cheap and easy with NoSQL. In contrast, scaling a traditional SQL database is much more complicated.
Only the biggest websites out there are actually taking advantage of the full NoSQL potential, i.e., Facebook, having thousands of servers running Cassandra.
I strongly recommend to read this blog post, comparing SQL, NoSQL and ORM:
Others have explained this, but I'm going to take a stab anyway.
A key/value database stores data by a primary key. This lets us uniquely identify a record in a bucket. Since all values are unique, lookups are incredibly fast: it's always a simple disk seek.
The value is just any kind of value. The way the data is stored is opaque to the database itself. When you store data in a key/value store, the database doesn't know or care if it's XML, JSON, text, or an image. In effect, what we're doing in a key/value store is moving the responsibility for understanding how data is stored out of the database in to the applications that retrieve our data. Since you only have a single range of keys to worry about per bucket, it's very easy to spread the keys across many servers and use distributed programming techniques to make it possible for this data to be accessed quickly (every server stores a range of data).
A drawback of this approach to data is that searching is a very difficult task. You need to either read every record in your bucket o' data or else you need to build secondary indexes yourself.
There are a few reasons you might want to use a key/value database:
There are about as many reasons to use a key/value database as there are to using an RDBMS and there are just as many arguments to justify one over the other. It's important to take a look at how you're querying your data and understand how that data access pattern guides how you're going to be inserting and storing data.
Just remember that a key/value database is just one type of NoSQL database.