Multi-model database
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]
A Multi-model database is a database that can store, index and query data in more than one model. For some time, databases have primarily supported only one model, such as: Relational database, Document-oriented database, Graph database or Triplestore. A database that combines many of these is multi-model.
For some time, it was all but forgotten (or considered irrelevant) that there were any other database models besides Relational. The Relational model and notion of Third normal form were the de facto standard for all data storage. However, prior to the dominance of Relational data modeling from about 1980 to 2005 the Hierarchical database model was commonly used, and since 2000 or 2010, many NoSQL models that are non-relational including Documents, triples, key-value stores and graphs are popular. Arguably, geospatial data, temporal data and text data are also separate models, though indexed, queryable text data is generally termed a "search engine" rather than a database.
A Multi-model database is most directly a response to the "Polyglot Persistence" approach of knitting together multiple database products, each handing a different model, to achieve a multi-model capability as described by Martin Fowler.[3] 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, so Multi-model databases have begun to fill in this gap.
Some stories of overcomplicated systems from un-necessary "frankenbeast" database integrations are found on the web.[4][5]
Multi-model databases are intended to offer the data modeling advantages of Polyglot Persistence,[3] without its disadvantages. Operational complexity, in particular, is reduced through the use of a single data store.[2]
Databases
Multi-model databases include:
- MarkLogic - Document (XML and JSON), Graph (RDF with OWL/RDFS), text, geospatial, binary, SQL
- OrientDB - Document (JSON), Graph, Key-value
- ArangoDB - Document (JSON), Graph, Key-value
- CouchBase - Relational (SQL), Document
note that the level of support for the various models varies widely, including ability to query across models, fully index the internal structure of a model, transactional support, and optimization or query planning across models. 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.
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. Some products may provide an engine which supports documents and graphs while others provide layers on top of a key-key store.[6] 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.[7] 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
- Comparison of multi-model databases
- ACID
- NoSQL
- Comparison of structured storage software
- Database transaction
- Distributed database
- Distributed transaction
- Document-oriented database
- Graph database
- Relational model
References
External links
- OrientDB Document and Graph Model
- ArangoDB Key Features
- FoundationDB Multi-Model Architecture
- Polyglot Persistence
- The 451 Group, "Neither Fish Nor Fowl: The Rise of Multi-Model Databases"
- ODBMS, "On Multi-Model Databases. Interview with Martin Schönert and Frank Celler."
- ODBMS, "Polyglot Persistence or Multiple Data Models?"
- Infoworld, "The Rise of the Multi-Model Database"
- Crate.IO Storage and Consistency
- MarkLogic on Multi-model databases