What's the Value of a Key-Value Store?
A key-value store is a data structure designed for storing and returning values associated with keys that act as unique identifiers. It’s often referred to as a “dictionary” or “hash table.''
Relational databases
A database back end for your application is vital. It’s likely your database is a relational database. This is because relational databases have dominated the software industry for decades, even as other technologies have radically changed around them.
In a relational database management system (RDBMS), data needs to be actively managed and maintained. An RDBMS categorizes data in the form of tables, and the database manager must create a blueprint — otherwise known as a schema — of the relationships between those tables before any data gets stored. The fields in these tables must also have well-defined data types for which values can be stored.
When considering implementing a relational database for your data storage needs, it’s important to completely understand what you’re getting into. While RDBMSs are known for being robust, they’re also known for being slow and inflexible.
Be sure to consider the query language used to interface with the database you’re interested in. You should also perform a cost-benefit analysis of what it will take to create indices that can speed data operations, as well as the administrative tooling to operate the database.
The benefits of NoSQL
"Not only SQL" (NoSQL) databases were designed to fill the gaps left by relational databases. Consider the core characteristics of a NoSQL database:
Schema-less with no complex relationships
Distributed by replicating data to avoid a single point of failure
Flexible storage of both unstructured and semi-structured data
Highly scalable no matter how much data is entered
The simplest NoSQL: the key-value database
Key-value databases are often considered the simplest and fastest of the NoSQL databases. They save data as a group of key-value pairs, which are made up of two linked data items. The link between the items is a "key" that acts as a pointer for an item storing a value. Each key is uniquely associated with a value in a collection, thereby making a key-value pair. And unlike with relational databases, you don’t have to constantly change your schema to keep pace with unstructured data that’s created and stored exponentially — because there is no schema.
Available options
Now that you understand some of the perks of key-value databases, here are a few options available to you:
Amazon DynamoDB: a managed NoSQL database capable of handling trillions of daily requests, and designed to run high-performance applications
Aerospike: an in-memory open source–distributed key-value NoSQL database management system capable of enabling high-performance real-time applications
Redis: an open source, in-memory key-value database that supports abstract data structures like lists, hashes, strings, and sets
Oracle NoSQL Database: a distributed NoSQL database that provides transactional semantics for data manipulation, horizontal scalability, and simple administration and monitoring
What is a key-value store?
To better understand what a key-value store is, consider a simple dictionary. When you want to look up the definition of a word, you flip to that word and find the associated definition. In the key-value store scenario, the word is your key, and the definition is the value. To visualize this another way, picture a two-column Excel spreadsheet, where the first column is the key and the second column is the value, as shown below.
Here, K1 is the first key, and its value is a street address. The second key, K2, is a phone number, and K3 is the name of a city. Admittedly, these are simple examples of storing string values — the data you keep in a key-value store can be far more complex. Values could just as easily be HTML fragments, nested JSON documents, or base64-encoded images.
As you can see from this example, key-value stores do not have defined data types, because they can contain almost anything. They don’t recognize or require relationships between values, as there are no columnar relationships in a key-value database. And there’s no need to learn a query language, because there is no language to learn.
More intuitive data modeling, flexibility, and scale
Beyond that, NoSQL databases provide even more intuitive data modeling, flexibility, and scale. They also aren’t subject to the complexity of SQL join queries, or the unbounded nature of any queries that typically characterize an RDBMS.
In many cases, using a key to perform a search can return a single data value far more quickly than in a relational database. Clients retrieve data using simple get, put, and delete commands, enabling key-value stores to have generally higher performance. The client can also get the value of a key, assign a value for that key, or delete a key from the data store.
It’s important to note that the key-value database doesn’t have any preferences about what gets stored inside it. Rather, it's the responsibility of the application using that database to understand what’s being stored.
The downsides of key-value databases
The benefits of key-value databases don’t necessarily spell out the demise of RDBMS databases. In cases where highly structured data is needed, RDBMS databases can be very useful. Here are some important key-value database drawbacks to know before you implement one to solve your problems:
No query language: Depending on your use case, lacking a unified query language can result in commonly used queries for one database being inaccessible from other key-value databases — meaning you’ll have to make new ones.
No key, no value: If, for some reason, you can’t procure the key to return your value, the value is essentially locked away in a black box.
Nonfilterable values: Databases can’t understand the data they store, so sometimes entire values will be returned instead of the specific information requested by the client. This is far less performant than returning only the portion of the value you need.
Whole updates: To update a part of a value, you need to update the entire value, which can have a huge impact on your performance.
When used correctly, a key-value store’s lack of structure can be made up for in overall read performance, the ability to handle high volumes of traffic, and flexibility. All this can result in hugely improved developer productivity. And since key-value stores don’t require a rigidly defined structure schema, it’s easier to customize them for a variety of use cases in a way that isn’t possible for an RDBMS.
The future of efficient data storage starts here
At the end of the day, not every application needs a relational database. Often, developers spend countless hours setting up relational databases and schemas, and dealing with object-relational mapping systems — time that could be better spent creating something new with simple key-value store options that work well with many applications.
Enter EdgeKV, Akamai’s distributed key-value store for building data-driven EdgeWorkers applications that require fast, frequent reads and infrequent writes. EdgeKV is simple to embed with a variety of applications, allowing developers to quickly read and write data at the edge — which reduces overhead from long and latent round trips to the cloud or to origin data centers.
Get started with EdgeKV
Ready to experience the future of databases? Take advantage of these resources to get started with EdgeKV:
Access the EdgeKV User Guide to discover how to make your first EdgeKV database and to read about use cases and examples to get the most out of your EdgeKV experience
Take advantage of the EdgeKV codebase by referring to the administrative API documentation
Learn about incorporating the EdgeKV command-line interface in your development ecosystem
See how EdgeKV works with a simple Hello World code sample
Download the EdgeKV Helper Library and read how to simplify interactions with EdgeKV in EdgeWorkers code
Install and utilize a set of EdgeKV companion utilities
Stay updated on the latest EdgeKV happenings on the Akamai blog
Originally published December 21, 2020; updated June 2022
