In key-value NoSQL systems each entry is simply a set of key-value pairs. Key-value stores alone are quite straightforward in that every value, whether an integer, string, or other data structure, has an associated key (i.e., they are analogous to PHP associative arrays). While a SQL table has a single primary key field for the entire record, here every value has a key, as shown in Figure 14.25.

Figure 14.25 Data in a key/value store

This allows fast retrieval through means such as a hash function, and precludes the need for indexes on multiple fields as is the case with SQL. Perhaps the most popular examples in the web context are memcache and Redis, which you will encounter again in the next chapter.

Document Stores (also called document-oriented databases) associate keys with values, but unlike key-value stores, they call that value a document. A document can be a binary file like a .doc or .pdf or a semi-structured XML or JSON document. By building on the simple retrieval of key-value systems, document store systems can read and write data very quickly. Most NoSQL systems are of this type. MongoDB, AWS DynamoDB, Google FireBase, and Cloud Datastore are popular examples.

To illustrate how a NoSQL document store differs from a relational database, consider the example in Figure 14.26. Here a user’s personal information might be highly normalized across many tables. A document store, in contrast, keeps the user’s information together in a single object (in this case a JSON object literal) associated with a key.

Figure 14.26 Relational data versus document store data

In order to get the equivalent data from a relational model, a relational database has to join the foreign keys across other tables, which can be a time-intensive operation when involving very complex queries or when the server is experiencing high loads. In contrast, the document store requires no joins to retrieve a single user.

It should be noted that the advantage of speed is offset by the challenge of maintaining integrity of the data. Since there are no relational checks in the NoSQL system, changes in one document will not easily be reflected in other documents representing a similar user (while they would in a relational model). In the relational model in the diagram, every address in Barcelona will always have the country of Spain due to how the data is modeled. In the document store approach, the system itself doesn’t maintain data integrity in the same way. Instead it is up to the application using it to maintain this integrity. Thus, if data input mistakes are made, one document in the NoSQL system might have Barcelona within Spain, but another might put it in Sweden, an inconsistency that would not happen in a properly normalized RDMS.

In traditional relational database systems, the data in tables is stored in a row-wise manner. This means that the fundamental unit of data retrieved is a row. To speed up those systems, indexes are used to create fast ways searching across rows by field. Column Store systems store data by column instead of by row, meaning that fetches retrieve a column of data and retrieving an entire row requires multiple operations.

The advantage of column stores is that in a column the data is all of the same type, so higher rates of compression can be achieved. The disadvantage is that writing rows requires writing multiple times to the multiple column stores.

Column stores are not a good choice for applications where rows of data are typically accessed. However, if the majority of a (large data) application uses only a few columns, column stores can offer speed increases, which is why they are integrated into many systems including Cassandra. A visual contrast of how row and columnar systems handle the same data is shown in Figure 14.27.

Figure 14.27 Contrast between row- and column-wise stores

In a Graph Store system (often simply called graph databases), data is represented as a network or graph of entities and their relationships. Recall that in a relational SQL database, relationships are expressed indirectly via foreign keys and primary keys (for instance, see Figure 14.11). In a graph database, relationships are explicit “things” that can be stored and queried; that is, each object or field in the graph database contains not just its “normal” data, but all its relationships as well, as shown in Figure 14.28.

Figure 14.28 Relationships in a graph database

The key advantage of this approach is the ease at which one can query relationships. For instance, in Figure 14.28, we could ask the database to provide us with all persons who work at a university in Canada, who teach web development, who have bought the book War and Peace, and who have watched a video on graph databases. In a traditional SQL database, which is designed for data integrity not relationship discoverability, such a query would likely require multiple subqueries as well as multiple joins, and thus be very computationally expensive (that is, slow). A graph database in contrast can run this query efficiently and easily. As such, they are ideal for efficiently discovering answers to unanticipated questions. Some examples of graph databases include Neo4j, OrientDB, and RedisGraph.