ra2 studio - Fotolia
How to choose the right database to fit your data model(s)
Choosing the right database for your enterprise applications can be a difficult process. Read on for some considerations on data platforms and model needs before making the choice.
The era of the one-size-fits-all database has been over for some time. IT shops realized years ago that not all the data their organizations needed to store, process and present to end users neatly fit into relational rows and columns.
The need to store unstructured data in conjunction with the ability to provide almost absurdly high degrees of scalability, data distribution and availability were the business drivers that led to the creation of database management systems that did not adhere to the relational model. Document, graph, key-value, wide column and other unstructured data storage technologies became viable, competitive offerings because they offered a solution to the IT community's need to store semistructured and unstructured data.
The new class of products allowed IT consumers to tailor a database engine and data model that met each application's unique storage and processing requirements. And with the increased options available, IT shops have to evaluate many things when figuring out how to choose the right database to fit their data models.
The growth of multimodel database platforms
During the relational database era and the initial stages of NoSQL platform growth, most vendors specialized in one data model. Their strategy was to market their products to organizations looking for a solution that their database engine and storage model were uniquely qualified to address.
Relational and NOSQL vendors alike quickly realized that integrating multiple data models into their database engines would provide them with a distinct advantage over competitors offering a single solution.
We began to see database vendors of all types and sizes stating that their products were now able to support additional data models. We fast forward to today and find that eight of the top 10 most popular database engines ranked by DB-Engines classify themselves as multimodel.
Polyglot persistence vs. multimodel database platforms
There has been a long and lively debate on what the best strategy is to support applications that need to process different types of data that cannot be effectively stored by a single data model. For example, a retail website could potentially access a graph database for part explosions and recommendations, a document database for product descriptions, and a relational system for financial data processing.
Polyglot persistence is the strategy of using multiple databases in tandem to support a given application's need to access multiple data models. Think of it as a best-of-breed solution that uses purpose-built database platforms with each system focusing on meeting a unique set of data storage and processing requirements.
The competing strategy is to use a multimodel database, which allows the application to seamlessly access multiple data models provided by a single platform. The goal is to limit the number of data stores that the application needs to access.
Deciding how to choose the right database plan between these two options requires some consideration. Let's review the high-level pros and cons of each strategy.
Polyglot persistence benefits
- The application will use best-of-breed databases and each system addresses a specific set of needs.
Polyglot persistence weaknesses
- Accessing multiple platforms adds complexity to the application.
- Administrators need to configure, administer and monitor multiple database products.
- Application developers need to access multiple database engines.
- It is more challenging to ensure overall data consistency across multiple database products.
Multimodel benefits
- A multimodel approach reduces application complexity.
- Multimodel database options lower product licensing, training and support costs.
- Having fewer platforms minimizes risk by limiting the number of systems that support the application -- fewer products for availability and performance simplifies administration and reduces risk.
- Depending on the product, some multimodel database offerings provide ACID compliant transactions across data models.
- Several multimodel databases allow application developers to use a common language to access multiple data models.
Multimodel weaknesses
- Multimodel database platforms may not provide the same level of features and functionality as purpose-built systems that focus on a single data model.
- Most multimodel database systems support a limited number of data models. Applications that need to store information that doesn't easily integrate into the platform's supported data models will be required to either force fit their data into the system or move to a polyglot persistence architecture.
- Vendor lock-in is also a concern for applications that depend on multimodel database systems. It is much easier to replace a database that supports a single data model and reengineer the application to access the new product than it is to redesign an application that accesses a multimodel engine.
Fitting your application's data model requirements
My first recommendation is to understand the different data models that are available. Knowing how to choose the right database starts with understanding your database options.
In addition to the standard vendor evaluation criteria that includes company reputation, pricing, documentation and support, here is a list of recommendations to help you select a database that fits your application's data model requirements:
- Visit vendor websites that support the different types of models, including relational, document, key-value, graph and wide column. In addition to selling their products, vendors will highlight the benefits and use cases of the data models they support.
- Understand the application's business needs. What problem is it trying to solve? What benefits will the application provide to the organization?
- Know the state of your data. Is it structured, semistructured, unstructured or a combination?
- Understand the application's data storage, processing and presentation requirements. You'll be able to map those requirements to one or more data model. Will a multimodel database platform meet the application's needs, or is it better suited to a best-of-breed polyglot persistence architecture?
