10 Reasons to Consider a Multi-Model Database
Wednesday, March 4, 2015 at 8:56AM 
This is a guest post by Nikhil Palekar, Solutions Architect, FoundationDB.
The proliferation of NoSQL databases is a response to the needs of modern applications. Still, not all data can be shoehorned into a particular NoSQL model, which is why so many different database options exist in the market. As a result, organizations are now facing serious database bloat within their infrastructure.
But a new class of database engine recently has emerged that can address the business needs of each of those applications and use cases without also requiring the enterprise to maintain separate systems, software licenses, developers, and administrators.
These multi-model databases can provide a single back end that exposes multiple data models to the applications it supports. In that way, multi-model databases eliminate fragmentation and provide a consistent, well-understood backend that supports many different products and applications. The benefits to the organization are extensive, but some of the most significant benefits include:
1. Consolidation
In the NoSQL space in particular, engineers face many choices when deciding how to model and store data. Those choices are complicated by the fact that most database management systems tightly couple all the different “levels” of their technology stacks, such as the storage engine, data model, and query language. A multi-model database supports different types of data for different use cases and consolidates them on one platform. So you gain flexibility in the query language and data model but simultaneously benefit from a common storage engine technology. Minimizing the components that have to be maintained at that low level within the backend allows infrastructure to be more commoditized, leading to lower total costs of ownership and increased flexibility as infrastructure needs change.
2. Performance scaling
As the use of an application grows, the need for database performance grows too. But the exact performance needs of an application may change, and with many database systems, a user’s only option is to scale the system “vertically”--using a single, larger machine that has increased performance or capacity. Multi-model systems that decouple the query language and data model from the underlying data store allow different components within the architecture to be scaled independently as needs change. So various parts of the backend system can be scaled out horizontally in response to increased throughput or storage requirements, whether that’s because a new application comes online or an existing application workload changes. And fortunately, when the performance demands decrease, it’s simple to scale down the backend system to save on hardware costs and operations efforts.
3. Operational complexity
The fragmented environments caused by running different databases increase the complexity of both operations and development. The goal of polyglot persistence is to use the best component for the job, but in practice it means you may end up with multiple databases, each with its own storage and operational requirements. Just integrating those systems is a difficult operational challenge, and attempting to integrate them into a cohesive, larger system that applications can use--especially when trying to maintain data consistency and fault tolerance--may be nearly impossible.
4. Flexibility
It's often awkward and inefficient to shoehorn lots of data into a single data model. A multi-model approach involves mapping multiple data models onto a single underlying storage engine that can support different use cases and applications. This approach provides flexible data modeling without the complexity of operating multiple data stores.
5. Reliability
Database reliability is also an issue when running multiple databases since each database system could be a single point of failure for the larger system and application. With some systems, recovering from machine failures may require hours of coordination and processing before full application connectivity and functionality can be restored to users and customers. The costs of that downtime, whether it’s expected or unexpected, can be tremendous both in terms of monetary costs and user engagement and experience with the application.
6. Data consistency
Without higher-level transaction functionality built into your application, there is no support for transactions across different database systems. Consequently, there is no good way to maintain consistency among different models. Suppose your application receives a stream of data on user activity, and you decide to store related data elements in a time series structure, graph format, and document format. You usually require these components to reflect a consistent state, but without ACID transactions that work across those data models, this requirement can be difficult if not impossible to achieve. A single backend system that supports multiple data models based on application requirements, however, can achieve this goal.
7. Fault tolerance
Ensuring that a system with many components of any kind is fault-tolerant is not an easy task to say the least. And integrating multiple systems that were designed to run independently so they provide fault tolerance across the system as a whole imposes significant engineering and operational costs. Unfortunately, deployments of heterogeneous systems require that your team have expertise with each component so the overall system keeps running well. Because each system is different and has different requirements, however, this approach is time consuming and expensive. And even then, the fault tolerance of your whole system then depends on the weakest subsystem in the backend.
8. Cost
Using more, distinct database systems increases costs based on hardware, software, and operational needs associated with each system. Although each tool may have been adopted to solve a specific business problem, in the aggregate, the costs of this piecemeal approach can add up very quickly and likely will only increase over time. Each component requires ongoing maintenance, including the stream of updates, patches, bug fixes, and other software modifications delivered by each vendor. In addition, each change to each component requires the organization to test the new component(s), make any necessary changes to applications and products, and then execute a process to release all these changes into the production environment.
9. Transactions
Relational database systems, typically deployed on a single machine, generally provide strong transactional guarantees for database operations, which allowed applications and application developers to understand with strong certainty the current state of the database at a given point in time. However, it’s challenging to provide transactions across multiple machines, and almost all NoSQL databases do not provide transactional guarantees due to their architectural designs. Because a true, multi-model system requires transactions to ensure that data is stored consistently in the database, all your applications inherit this strong contract of how data is stored. Although this benefit may not seem significant since single-machine relational database can provide transactions, the benefits of transactions as part of a distributed, fault-tolerant system that you can flexibly scale are tremendous.
10. Better applications
Trying to run different databases to power an application can be an operational and development nightmare. In contrast, an application that is supported by a multi-model database gets the benefits of scalability, fault tolerance, and in a well-engineered system, high performance built into the product. With less extra logic needed at the application level to handle database interactions and potential failure conditions, developers can focus on building better applications. Because of these benefits, multi-model systems are where the database market is heading--ACID-compliant transactions, multi-model APIs, and shared, powerful storage engines that can better meet the requirements of demanding applications.
Reader Comments (7)
Native Advertising again. And not even real information, just marketing bla.
Just FYI, no content is ever paid for on HighScalability. In this case I thought the information content was high enough to outweigh very real concerns over PR cuckoldery. Though I understand your concern, I try to be liberal in what I accept and conservative in what I send.
The above is all quite true but it ignores a few critical aspects:
1) While integration greatly simplify development it also encourages intricate dependencies and you can`t upgrade just one area of the system. If the elephant is sick the whole system is down. More complex systems made of apparently disparate technologies have a higher initial cost and some maintenance overhead but they do bring additional flexibility that is impossible with the monolith approach. Each tool is also more specialized and easier to replace. It is not black and white. There is a trade-off on each side of the fence
2) The industry doesn't show any sign of going toward multimodel solutions. If there are I have not seen them and they are not mentioned here.
3) Because the author is biased (as mentioned by sleepless comment above) there isn't any mention of current multimodel databases currently on the market. There are others like OrionDB, ArangoDB and Intersystems' Cache. Cache has been there longer than any other and stays mostly out of media hype but it is used on large and critical systems in many vertical markets (health, finance, airports, etc). It is a multidimensional SQL,/NOSQL object database and I hear the next version is also a document database. OrionDB is different (deals with uncertain data), just as interesting but not as widely used.
I admit I don`t know FoundationDB and ArangoDB but isn't that just the point of such an article? Is the multimodel market expanding? Is the offering changing and what differentiate each product? What big players are using the multimodel approach (and not just 1 product).
The article fails to inform on all points
When I read that FoundationDB was recently sold to Apple, I remembered this post.
What a coincidence, that in the moment the company needed a good valuation this SEO pufff piece was published.
I know this is a niche Blog, which probably struggles to uphold the very high standards of intricate detail and insight. But your hard earned success should not bring down the quality I, and many others, are coming here for.
Thanks for the great blog, but please be at least aware what you want this blog to be, and also what others really like to use these blogs for.
sleepless, first I thank you for caring enough to comment. Twice.
Let me say I accept all types of articles aimed at all different audiences levels. That's how I've always worked. And I always get this same sort of criticism. But that's OK. I know going in it will happen, I just think it's more important to put different view points out there. As every being has an agenda all content is biased. I try to control that as much as possible. If I control it too much I'd publish nothing. So it's a balancing act and I choose to balance in favor of viewpoints.
So no, I've never accepted money for articles and I never will. That's an unjust criticism that does actually wound me.
And though I have a healthy ego I can't quite muster the hubris necessary to think Apple acquired a company based on anything they wrote in HS.
And I encourage you to contribute an article that models the type of content you would like to see on HS. I'm more than happy to take a look. That's how it works.
Here are the Guest Post Guidelines I send to everyone who contacts me about writing an article:
1. There's no length limit.
2. Please keep it technical, not a lot of PR.
3. Use a very simple HTML format (H1, etc). This means do not set fonts, spacing, etc. Headers are fine, bold is fine, links are fine. Otherwise the article looks silly when posted.
4. Please include a guest post line at the top that includes your name, a link for more information, that sort of thing.
5. Try and make a compelling introductory paragraph and title. This is very hard, but it would help.
6. Graphics are good, but not required.
7. Keep it useful. A key goal of the site it for readers to learn something that will help them on their jobs.
8. Please just email the result to me or share it via google docs to toddhoffious@gmail.com.
If you are stuck for some questions then here's a template: http://highscalability.com/architecture-template-advice-needed
Any questions please let me know.
thanks
Wow :) I honestly did not expect such a long answer.
Let me be clear, after your first answer I no longer assumed this was some kind of paid advertisement.
The imaginary picture I drew when I wrote my previous comment was something like this:
FoundationDB wants to sell, or feelers are put out for an offer. fDB heads start to think about $$ and come up with ways to prop up the perceived value, make marketing and other personell induce good stories and write guest posts about the fDB thing.
HS blog gets guest post, does not know about all this in the background, reads article, decides to publish guest post, despite realizing that guest post is total shallow marketing rubbish.
My criticism is not, and cannot be, more than a wishful reminder, - I think I am just used to better content.
When I am in the fortunate position to be able to contribute something I deem share worthy, I will sieze the opportunity :)
(And hope for a seo puff piece filter before it gets published)
I also, sort of, apologize for the general tone of my posts. - Its just, one gets into a certain mindset in the world of internet comment sections...
No problem sleepless. I sensed you were coming from a good place, which is why it mattered to me that I respond honestly.
thanks