A database back end for your application is vital, and odds are that your database is a relational database or a "not only SQL" (NoSQL) database. Relational databases have dominated the software industry for decades, even as other technologies have radically changed around it. A relational database management system (RDBMS) should be understood as though management system is in bold type, as you must actively manage the data contained within it.
An RDBMS categorizes data in the form of tables, and you must create a blueprint (or schema) of the relationships between those tables before you store data. The fields in these tables must have well-defined data types for which values may be stored. Don't forget about the query language used to interrogate the database and the need to create indexes to speed data operations and the administrative tooling to operate it. While these databases are like indestructible tanks, they are often criticized for being heavy, slow, and inflexible.
This becomes especially problematic as the amount of unstructured data corporations create and store grows exponentially, forcing relational database schema changes to keep pace with that growth. This is where the NoSQL database originally came from: filling the gaps left by relational databases. For comparison, consider the core characteristics of a NoSQL database:
- Schema-less: no complex relationships
- Distributed: data is replicated to avoid a single point of failure
- Flexible storage of both unstructured and semi-structured data
- Highly scalable
Key-value (KV) databases are often considered the simplest and fastest of the NoSQL databases. KV databases 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 associated with one -- and only one -- value in a collection, and is known as a key-value pair. Every record (equivalent to a row in a relational database) in a KV database is uniquely identified by a key.
To better understand it, think of a dictionary: When you want to look up the definition of a word, you flip to that word and find the associated definition. The word is the key, and the definition is the value. To visualize this further, envision 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 the third key is the name of a city. These are admittedly simple examples of storing string values, but the data can be much 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, but can contain almost anything. They do not not recognize (nor require) relationships between values, as there are no columnar relationships in a key-value database. Nor is there a default query language to learn. NoSQL databases provide more intuitive data modeling, flexibility, and scale. They are not subject to the complexity of SQL joins or the unbounded nature of queries that characterize an RDBMS.
Searching the key field can return a single data value very quickly -- much faster than a relational database. Clients retrieve data using get, put, and delete commands. This is why a KV store has high performance. A client can get the value of a key, assign a value for a key, or delete a key from the data store. The database does not care what is stored inside; it's the responsibility of the application to understand what was stored.
This does not mean the demise of RDBMS databases, especially in use cases where highly structured data is needed. But the benefit of structure is also its Achilles' heel, making it harder to customize relational databases for different use cases. In contrast, what a KV store sacrifices in structure, it makes up for in read performance, the ability to handle high volumes of traffic, flexibility, and improved developer productivity.
Not every application needs a relational database. Developers often spend countless hours setting up relational databases and schemas, and dealing with ORM systems. Instead, they could simply treat data as keys and values, and spend more time creating something new. This is not to say KV stores are a panacea, but they are a great fit for many applications.
Soon, Akamai will give you another choice in NoSQL databases. Stay tuned...