The rise of multimodel databases to support data variety

The challenge with diverse data structures

Storing and processing structurally different data is a challenge -- one size does not fit all. Data comes in many shapes -- some of the most popular data models include relational, document, key-value and graph.

In the past, when presented with a new data structure, we had to either force data into the data model of our existing DBMS or purchase a new DBMS that supported the new structure.

For the longest time we've had the relational (SQL) DBMS and its predecessors solving our structured data needs. This has proved to work well for a good portion of our data. Albeit not optimized, we used these traditional databases for the small amount of unstructured data in our applications.

With an increase of semistructured and unstructured data driven by new data sources -- big data and real-time processing -- we saw a renewed interest in special-purpose nonrelational DBMS options. These databases, commonly referred to as NoSQL databases, model data in nontabular structures.

Consequently, the proliferation of data models and new DBMS models presented a dilemma. Managing different data models with a mix of database technologies resulted in optimization at a cost of added complexity.

Solving the single-model dilemma

Purpose-built single-model DBMS products optimize data storage and processing. However, adding an additional DBMS into an architecture adds complexity in the form of increased integration, development, maintenance and operations. This leaves organizations looking for a better approach in dealing with diverse data models.

Fortunately, both SQL and NoSQL DBMS vendors are responding by adopting many aspects of each other's features, including multiple data models, in hopes that organizations will rationalize their DBMS technology to a single data store. Data model support, once a clear differentiator between each DBMS, is becoming a common denominator.

What are multimodel databases

The convergence of data models within a single data management system has spawned a new class of DBMS called multimodel databases. Some leading DBMS options have been supporting multiple models for a while, although not at the rapid adoption we've seen of late.

Implementations can vary. I prefer architectures that store supported models in native data types and structures with a single integrated database engine (see image). This provides consistent data management across all models and allows multimodel access to data within a single statement.

Where to start with multimodel databases

At first glance, multimodel databases seem to fly in the face of polyglot persistence, which advocates storing data in multiple data storage technologies based on its use. However, what if you could deal with different data models within the same DBMS?

If you already have an investment in a multimodel DBMS and it meets or exceeds both the functional and nonfunctional requirements of your data and application, it may make more sense to utilize your organization's existing technology rather than to introduce new technology.

With the advent of multimodel databases, we can now separate the data model and the DBMS into two decisions.

First, determine which data model is best suited for your data's structure and use.

Second, identify which DBMS options support that data model and the requirements of the application. Practically speaking, you could expect to have both single-model and multimodel DBMS options in your technology architecture.

For special-purpose components of your application, a single-model DBMS will likely deliver the best data management. For all other components, a multimodel DBMS will rationalize and simplify your technology architecture.

When it comes to data variety, one data model doesn't fit all. Regardless of your choice to use single-model or multimodel databases, there is no longer an excuse to force data into nonoptimized data models.