I have previously written about the functional evolution and emerging use cases for NoSQL databases, a category of non-relational databases that first emerged 15 or so years ago and are now well established as potential alternatives to relational databases. NoSQL is a term used to describe a variety of databases that fall into four primary functional categories: key-value stores, wide-column stores, document-oriented databases and graph databases. Each is worthy of further exploration, which is why I am examining them over a series of analyst perspectives. Following a closer look at graph databases, I now turn to document-oriented databases.
The level of adoption of document databases pales in comparison to relational databases. Almost three-quarters (72%) of participants in Ventana Research’s Analytics and Data Benchmark Research are in production
The category of document-oriented databases is dominated today by NoSQL data platform products that store data using the JavaScript Object Notation lightweight data interchange format, which was specified in 2001 and became a standard in 2013. The most prominent providers of databases that store data using JSON include MongoDB and Couchbase, while document databases are also available from the likes of Amazon Web Services, Google Cloud, IBM, Microsoft and Oracle. It is also worth noting that document-oriented databases had been a part of the data platform market for several decades prior to the emergence of NoSQL or JSON, with databases that store data using extensible markup language having been commercially available since the early years of this century.
As with XML, many relational database vendors have added the ability to store and process data using JSON. Combined with the ongoing popularity of relational databases, this might leave some organizations wondering why a separate document database is needed. The simple answer is that there is more to document-oriented databases than simply storing and processing JSON data. The document model provides developer agility and application flexibility that cannot be replicated by simply storing data as JSON in a relational database. Much of the initial adoption of document databases was driven by developer enthusiasm and their applicability to the rapid development of new applications.
The flexibility of the document model was fundamental to this enthusiasm. Rather than recording data in the tables of rows and columns associated with the relational model, data is stored in documents of field-value pairs. Given the ubiquity of relational databases it is perhaps worth explaining these concepts in the context of the relational model. A document can be considered the equivalent of a row, while the fields are the equivalent of columns. Field attributes can take various forms, including strings, numbers, arrays and objects as well as embedded documents (similar to nested tables or objects in the relational model).
Documents can be grouped into collections (the equivalent of a table from a relational context), and the identification of relationships between entities can be achieved by join operations between documents, similar to join operations between tables in a relational database. Documents in a collection do not need to have the same fields. Unlike relational databases, document databases do not rely on fixed schema. This provides flexibility, making document databases suitable for use cases that require storage and processing of data sets with diverse attributes and values. Classic use cases include user profiles, product catalogs and content management. However, the inherent flexibility of the document model means that document databases can be considered general purpose databases to be used across a variety of industries and use cases, including customer experience, payment processing, operational analytics and IoT and time series.
Documents can be mapped to objects in application code, providing intuitive ease of use for application developers, while the fields used by a document can evolve in response to changing data and application requirements,
In addition to these potential benefits, some of the arguments against the use of document databases have been diminished by functional developments in recent years. A key example is support for atomic, consistent, isolated and durable transactions ‒ or ACID. Most document databases were initially designed to favor availability over consistency via an approach known as BASE — basic availability, soft-state eventual consistency — but several of the most prominent document database vendors (including MongoDB and Couchbase) have added support for distributed multi-document ACID transactions.
Document database vendors have also added compatibility with the SQL query language to enable organizations to use SQL tools and skills to query and manage data stored in the JSON format. Couchbase is at the forefront of adding compatibility with SQL through its development of the SQL++ specification, which can best be thought of as an extension to the SQL standard. MongoDB introduced mongosql, an SQL dialect designed specifically for the document model that is compatible with SQL-92.
The developer-friendly attributes of document databases means that they are typically used to support the development and deployment of new applications. Support for ACID transactions and SQL compatibility are increasingly suitable for use as direct replacements for applications that depend on relational databases. I recommend that all organizations considering options for databases to support new application development projects and transformation initiatives evaluate document databases.
Regards,
Matt Aslett