Jump to content

Multi-model database

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Nosql.analyst (talk | contribs) at 00:37, 9 January 2015 (→Engines: clarified section on architecture). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Most database management systems are organized around a single data model that determines how data can be organized, stored, and manipulated. In contrast, a multi-model database is designed to support multiple data models against a single, integrated backend.[1] Document, graph, relational, and key-value models are examples of data models that may be supported by a multi-model database.

Background

The relational data model became popular after its publication by Edgar F. Codd in 1970. Due to increasing requirements for horizontal scalability and fault tolerance, NoSQL databases became prominent after 2009. NoSQL databases use a variety of data models, with document, graph, and key-value models being popular.[2]

Enterprises and applications that require multiple data models sometimes adopt a strategy of polyglot persistence,[3] using separate data stores for each model. This strategy has two major disadvantages: it leads to a significant increase in operational complexity, and there is no support for maintaining data consistency across the separate data stores.

Multi-model databases are intended to offer the data modeling advantages of polyglot persistence without its disadvantages. Operational complexity, in particular, is reduced through the use of a single data store.[2]

The first multi-model database was OrientDB, created in 2010 as an answer to the fragmented NoSQL environment, with the goal of providing one product to replace multiple NoSQL databases.

Examples

Database Key-value SQL Document Graph Object License Transactions
OrientDB Yes Yes Yes Yes Yes Apache 2 License Full ACID, even distributed
ArangoDB Yes No Yes Yes No Apache 2 License Pessimistic locking and configurable durability
FoundationDB Yes Yes Yes Yes No Proprietary Full ACID, multi-key, cross-node

Architecture

The main difference between the available multi-model databases is related to their architectures. Multi-model databases can support different models either within the engine or via different layers on top of the engine. For example, graph databases are defined as "any storage system that provides index-free adjacency".[4] Products like ArangoDB and FoundationDB provide this feature in a graph layer rather than at the engine level. With a layered architecture, each data model is provided via its own component.

User-defined data models

In addition to offering multiple data models in a single data store, some databases allow developers to easily define custom data models. This capability is enabled by ACID transactions with high performance and scalability. In order for a custom data model to support concurrent updates, the database must be able to synchronize updates across multiple keys. ACID transactions, if they are sufficiently performant, allow such synchronization.[5] JSON documents, graphs, and relational tables can all be implemented in a manner that inherits the horizontal scalability and fault-tolerance of the underlying data store.

See also

References

  1. ^ The 451 Group, "Neither Fish Nor Fowl: The Rise of Multi-Model Databases"
  2. ^ a b Infoworld, "The Rise of the Multi-Model Database"
  3. ^ Polyglot Persistence
  4. ^ "Glossary of Big Data Terminology". Retrieved 5 August 2013.
  5. ^ ODBMS, "Polyglot Persistence or Multiple Data Models?"
Retrieved from "https://en.wikipedia.org/w/index.php?title=Multi-model_database&oldid=641654665"