Key-value store DBMSs use three commands taken from Web languages to manipulate the values in the database:

Why would you want to use a database where you can’t search the data? Anywhere you need to store and retrieve entire files. You could, for example, store an entire Web site where the key is a page’s URL. When a user makes a request from a Web server to display a particular page, the Web server doesn’t need access to the page’s internal code; it just needs the HTML text as a unit. Therefore, the Web server submits the URL to the key-value store DBMS, which, in turn, uses the key to find the requested page. Any scripts, images, and videos used by the page could be stored and retrieved in the same way.

A key-value store database has no schema. In fact, the values associated with the keys do not need to be the same type of item. For example, one value could be a string of text, while another was a graphic image.

The biggest advantage to key-value store databases is extremely fast retrieval. However, if you need to be able to search within stored values rather than always retrieving by the key, this type of DBMS may not be a good fit for your data. Keep in mind that you can’t update parts of a “value” while it’s in the database. You must replace the entire value with a new copy if modifications are needed.

Key-value store databases are therefore best suited for applications where access is only through the key. They are being used for Web sites that include thousands of pages, large image databases, and large catalogs. They are also particularly useful for keeping Web app session information.

Text data can be searched by creating indexes to the elements within the documents. Although not all documents need to have the same structure, the elements within a document can be named, making it possible to index on all items of the same name.

Document store databases do not require a schema, but each document does have a primary key, a value that uniquely identifies the document. The primary key index is a permanent feature of the database, but secondary indexes can be created and deleted as needed.

Document store databases work well for large on-line catalogs, for example. They provide fast access by a catalog number. However, the ability to build secondary indexes supports fast access using keywords such as those a user might use in a search.

In a relational database, each table has a fixed structure: Every row has space for every column. This is not the case in a column-oriented NoSQL database. Because the basic unit of storage is a column rather than a row, rows can be assigned different columns as needed. A column has a name (for example, first_name) that identifies the row within the column and a value (for example, “George”) and, in many implementations, a timestamp. The timestamp not only anchors the data in time, but makes it easy to purge data that has been aggregated at any given point, as well as to keep multiple versions of the same data to track changes over time (versioning).

Columns are grouped into column families. When you place related columns in the same family, instances of those columns will be stored as physically close to each other as possible. You might, for example, create a column for each of street address, city, state, and zip. Then, you can group them into a column family with its own name (perhaps “address”). In contrast, most relational DBMSs try to store data in a single row together.

The biggest benefit of a column-oriented database is fast data aggregation. In other words, it will be extremely good at extracting data from a single column and providing summaries of that data. Google uses one, for example, to aggregate Web page visitation data. When the software has compiled the Web sites visited and the number of times each was visited, the data are archived.

The biggest advantage of the graph store is that joins aren’t necessary. The pathways between related data exist within the database. As an example, consider the graph in Figure 28.1. It shows six instances of nodes from an Antique Opticals database.

The price charged the customer and the quantity ordered are properties of the Contains relationship. There is no composite entity between the order and the inventory item. To retrieve data, the DBMS follows the relationships stored in the database.

Note: Graph databases are navigational, like the data models discussed in Appendix A, because access to data follows predefined paths. However, the stored relationships in the older data models cannot have properties.

Graph databases are well suited to large databases that must track networks of relationships. They are used by many online dating sites, as well as LinkedIn and Twitter. Avoiding the joins to traverse friend relationships can speed up performance significantly. In addition, they can be used effectively to plot routes (such as for a package delivery service).

NoSQL distributed solutions can also be very cost effective. Rather than needing large machines with massive amounts of storage, they can be implemented on small, commodity servers, such as those you might buy for a LAN subnet. Run out of space? Just add another machine. Doing so is significantly cheaper than adding similar capacity to a mainframe. Some people argue that the total-cost-of-ownership of a mainframe can be less than a distributed cluster, but this doesn’t take into account the idea of incremental upgrades. It costs less to add a small, single server to a cluster, than it does to add RAM or permanent storage to a mainframe.

There are two major types of NoSQL distributed architectures that can be used individually or together.

Virtually all current NoSQL products require configuration and data manipulation, either from a command line or from within an application program. This means that a company wanting to implement a NoSQL solution must have access to both systems and application programmers.

With their emphasis on performance, many NoSQL DBMSs tolerate some data inconsistency, with the idea that eventually all the data will become consistent. Therefore, transaction control is BASE (Basic Availability, Soft State, and Eventual Consistency) rather than ACID.

With a relational database, we want serializable transactions (multiple transactions running interleaved produce the same result as they would if the transactions were run in a series rather than interleaved). The DBMS therefore locks portions of the database to prevent problems such as the lost update and inconsistent analysis.

Avoiding lost updates is essential in a transaction processing system. However, systems that are used primarily for querying, rather than a high volume of updates, can be allowed to suffer from lost updates. A report may be inaccurate for a while, until the writes catch up, but will reflect the modified data when it is rerun.

In a BASE concurrency control environment, no writes are blocked. The goal is to avoid locking to make the database as available as possible. Whereas ACID concurrency control is pessimistic (something might go wrong, so we to make sure that doesn’t happen), BASE transaction control is optimistic (everything will become consistent in the end). BASE transaction control is also well suited to distributed databases because it doesn’t worry about keeping replicated copies consistent at every moment.