NoSQL Databases

Relational databases are not the only kind of databases in the world. There’s also an extensive and diverse group of non-relational databases called NoSQL.

What are NoSQL databases?

NoSQL database is an interesting term because it says what it’s not instead of what it is. NoSQL includes all the databases that don’t fit the relational schema definition.

This category is so big that if we pick two NoSQL databases randomly, they’ll probably have nothing in common. That’s why discussing NoSQL databases by themselves doesn’t make much sense. It’s helpful though to discuss specific types of NoSQL databases.

Types of NoSQL databases

We usually categorize NoSQL stores by the data structures they support. There’s no perfect categorization, and some specific databases might fall into multiple categories. Here are some commonly used NoSQL database types.

Key-value stores

As the name suggests, the record in the key-value database consists of the key and the value. Such databases don’t provide fancy search options. We can either select all records or search specific records by key. Instead, such databases have outstanding performance, making them great for storing some relatively small, frequently-used data.

Key-value databases are good for storing user sessions, configuration parameters, and other data accessed by key only.

Notable example: Redis

Redis is an open-source, in-memory key-value store with built-in persistence, replication, and transactions. Redis also supports lists, sets, and key-value maps as value types, making it possible to store more complex data.

There is a PHP extension for working with Redis.

Document stores

Document stores have tables (as relational databases do), but each record is not a predefined set of fields but a serialized document (usually JSON). Because of that, each record can have a different, complex and multilevel structure.

Of course, we can serialize records as JSON and save them in the key-value store, but document databases support searches, updates, and even indexes over the fields of such documents.

Document stores are handy when dealing with data that doesn’t have a static structure.

Notable example: MongoDB

MongoDB is one of the most popular databases, and it’s a document database. It supports joins, ACID transactions, and horizontal scaling.

There is a PHP extension for working with MongoDB.

Wide-column stores

Wide-column stores look like something between relational databases and document stores. They have tables with rows and columns, much like relational databases. But, columns can be different on each row, like in document stores. The main difference with document stores is that wide-column stores don’t support nested record structures. Each row has a key-value structure.

Notable example: DynamoDB

DynamoDB is a part of Amazon Web Services. It’s popular because of its speed and reliability. Users don’t bother with infrastructure and scaling since it’s a managed service.

DynamoDB supports these two kinds of primary keys:

• A single-column unique partition key.
• A two-column unique partition key and the sort key combination.

Information about key columns is defined during table creation. Every record must have these fields. All other fields might be different for each record. AWS SDK for PHP supports DynamoDB.

Graph databases

Graph databases aim specifically to store data that looks like graphs. The database records are graph nodes or edges. Graph databases treat relationships between entities as equally important to entity data. They support simple and fast queries over the data with relationships contrary to the slow and complex joins in relational databases.

Graph databases also implement common database algorithms. They are good when our data fits the graph structure and some queries select related data.