Key-Value Stores in NoSQL
Key‐value stores NoSQL have a record with an ID field — the key in key‐value stores — and a set of data. This data can be one of the following:
An arbitrary piece of data that the application developer interprets (as opposed to the database)
Any set of name‐value pairs (called bins)
Think of it as a shared mailbox in an apartment building. All you see from the outside is a set of numbered holes. Using a key, you access whatever is in the mailbox. After looking at the mail, you decide what to do with it (probably just throw it away).
In this way, key‐value stores are similar to column stores in that it’s possible to store varying data structures in the same logical record set. Key‐value stores are the simplest type of storage in the NoSQL world — you’re just storing keys for the data you provide.
Some key‐value stores support typing (such as integers, strings, and Booleans) and more complex structures for values (such as maps and lists). This setup aids developers because they don’t have to hand‐code or decode string data held in a key‐value store.
In computer science, a “list” is zero or more data values. These values may or may not be stored in a sorted representation that allows for fast match processing.
Maps are a simple type of key‐value storage. A unique key in a map has a single arbitrary value associated with it. The value could be a list of another map. So, it’s possible to store tree structures within key‐value stores, if you’re willing to do the data processing yourself.
If you have numerous maps in your key‐value store, consider a document store instead, which will likely minimize the amount of code required to operate on your data and make search and retrieval easier.
Key‐value stores are optimized for speed of ingestion and retrieval. If you need very high ingest speed on a limited numbers of nodes and can afford to sacrifice complex ad hoc query support, then a key‐value store may be for you.