Multi-model database: Difference between revisions

Revision as of 16:58, 19 September 2020

Revision as of 18:02, 21 November 2020

Line 9:

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.

The first time the word "multi-model" has been associated to the databases was on May 30, 2012 in Cologne, Germany, during the Luca Garulli's key note "''NoSQL Adoption – What’s the Next Step?''".<ref>{{Cite web|date=2012-06-01|title=Multi-Model storage 1/2 one product,|url=http://www.slideshare.net/lvca/no-sql-matters2012keynote/47-MultiModel_storage_12_one_product}}</ref><ref>{{Cite web|url=https://2012.nosql-matters.org/cgn/wp-content/uploads/2012/06/KeyNote-Luca-Garulli.pdf|title=Nosql Matters Conference 2012 {{!}} NoSQL Matters CGN 2012|website=2012.nosql-matters.org|access-date=2017-01-12}}</ref> Luca Garulli envisioned the evolution of the 1st generation NoSQL products into new products with more features able to be used by multiple use cases.

The idea of multi-model databases can be traced back to [[Object-relational database|Object-Relational Data Management Systems (ORDBMS)]] in the early 1990s and in a more broader scope even to federated and integrated DBMSs in the early 1980s. An ORDBMS system manages different types of data such as relational, object, text and spatial by plugging ___domain specific data types, functions and index implementations into the DBMS kernels. 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.<ref name="polyglot">[http://martinfowler.com/bliki/PolyglotPersistence.html Polyglot Persistence]</ref> 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.

Line 35:

== Benchmarking multi-model databases ==

As more and more platforms are proposed to deal with multi-model data, there are a few works on benchmarking multi-model databases. For instance, Pluciennik,<ref>{{Cite journal|last=Ewa Pluciennik and Kamil Zgorzalek|first=|date=|title=The Multi-model Databases - A Review|url=|journal=BDASBdas 2017|volume=|pages=141–152|via=}}</ref> Oliveira,<ref>{{Cite journal|last=Fábio Roberto Oliveira, Luis del Val Cura|first=|date=|title=Performance Evaluation of NoSQL Multi-Model Data Stores in Polyglot Persistence Applications|url=|journal=IDEASIdeas '16|volume=|pages=230–235|via=}}</ref> and UniBench<ref>{{Cite journal|last=Chao Zhang, Jiaheng Lu, Pengfei Xu, Yuxing Chen|first=|date=|title=UniBench: A Benchmark for Multi-Model Database Management Systems|url=https://www.cs.helsinki.fi/u/jilu/documents/UniBench.pdf|journal=TPCTC 2018|volume=|pages=|via=}}</ref> reviewed existing multi-model databases and made an evaluation effort towards comparing multi-model databases and other SQL and NoSQL databases respectively. They pointed out that the advantages of multi-model databases over single-model databases are as follows : (i) they are able to ingest a variety of data formats such as CSV( including Graph, Relational), JSON into storage without any additional efforts, (ii) they can employ a unified query language such as AQL, Orient SQL, SQL/XML, SQL/JSON to retrieve correlated multi-model data, such as graph-JSON-key/value, XML-relational, and JSON-relational in a single platform. (iii) they are able to support multi-model ACID transactions in the stand-alone mode.

== Architecture ==