The first type of database technology that we will be examining is a key-value store. As the name implies, a key-value store database persists data as a collection of key-value pairs, where keys serve as unique identifiers for accessing stored data within a particular collection. By this definition, key-value stores are functionally equivalent to a hashmap data structure. Popular key-value store implementations include memcached [15], AWS DynamoDB [8], LevelDB [13], and SSD-optimized RocksDB [20].
The basic set of operations supported by key-value stores are insertions, deletions, and lookups. However, some popular key-value store implementations also provide support for range queries, which allow clients to iterate an ordered list of key-value pairs between two particular keys. As far as keys and values are concerned, the majority of key-value store implementations do not enforce any constraints on their contents. This means that any kind of data (for example, strings, integers, or even binary blobs) can be used as a key.
The data access patterns that are used by key-value stores make data partitioning across multiple nodes much easier compared to other database technologies. This property allows key-value stores to scale horizontally so as to accommodate increased traffic demand.
Let's examine some common use cases where key-value stores are generally considered to be a great fit:
- Caches! We can use a key-value store as a general-purpose cache for all sorts of things. We could, for instance, cache web pages for a CDN service or store the results of frequently used database queries to reduce the response time for a web application.
- A distributed store for session data: Imagine for a moment that we operate a high-traffic website. To handle the traffic, we would normally spin up a bunch of backend servers and place them behind a load balancer. Unless our load balancer had built-in support for sticky sessions (always sending requests from the same user to the same backend server), each request would be handled by a different backend server. This could cause issues with stateful applications as they require access to the session data associated with each user. If we tagged each user request with a unique per-user ID, we could use that as a key and retrieve the session data from a key-value store.
- A storage layer for a database system. The properties of key-value stores make them a very attractive low-level primitive for implementing more sophisticated types of databases. For example, relational databases such as CockroachDB [5] and NoSQL databases such as Apache Cassandra [2] are prime examples of systems built on top of key-value stores.
The main caveat of key-value stores is that we cannot efficiently search within the stored data without introducing some kind of auxiliary data structure to facilitate the role of an index.