Multi-model database: Difference between revisions

Revision as of 11:06, 27 March 2020

Revision as of 11:06, 27 March 2020

Line 4:

The [[relational model|relational]] data model became popular after its publication by [[Edgar F. Codd]] in 1970. Due to increasing requirements for [[Scalability#Horizontal and vertical scaling|horizontal scalability]] and [[fault tolerance]], [[NoSQL]] databases became prominent after 2009. NoSQL databases use a variety of data models, with [[Document-oriented database|document]], [[Graph database|graph]], and key-value models being popular.<ref name="rise">[http://www.infoworld.com/article/2861579/database/the-rise-of-the-multimodel-database.html Infoworld, "The Rise of the Multi-Model Database"]</ref>

A Multi-model database is a database that can store, index and query data in more than one model<ref>{{Cite journal|last=Jiaheng|first=Lu|last2=Irena|first2=Holubová|date=2019|title=Multi-model Databases: A New Journey to Handle the Variety of Data|url=https://www.cs.helsinki.fi/u/jilu/documents/Multi_model_Databases__A__New_Journey_to_Handle_the_Variety_of_DataFinal.pdf|journal=ACM Computing Surveys|volume=|pages=|via=}}</ref>. 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.

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 journalweb|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.<ref name=":0">{{Cite journal|last=Jiaheng|first=Lu|last2=Irena|first2=Holubová|date=|year=2017|title=Multi-model Data Management: What's New and What's Next?|url=https://www.cs.helsinki.fi/u/jilu/paper/multi-model-data_EDBT.pdf|journal=EDBT|volume=|pages=602–605|via=}}</ref> 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.

Multi-model databases are intended to offer the data modeling advantages of polyglot persistence,<ref name="polyglot"/> without its disadvantages. Operational complexity, in particular, is reduced through the use of a single data store.<ref name="rise"/><ref name=":0" /> In general, there are two solutions to directly manage multi-model data currently: a single integrated multi-model database system or a tightly-integrated middleware over multiple single-model data stores.<ref>Jiaheng Lu, Irena Holubová, Bogdan Cautis. [https://www.cs.helsinki.fi/u/jilu/documents/CIKM18.pdf Multi-model Databases and Tightly Integrated Polystores: Current Practices, Comparisons, and Open Challenges]. CIKM 2018: 2301-2302 </ref>

== Databases ==

Line 31:

* [[Redis]] – key-value, document (JSON), property graph, streaming, time-series

* [[SAP HANA]] – relational, document (JSON), graph, streaming

* [[Virtuoso Universal Server]] -- [[Relational database|relational]], document ([[XML]]), [[Triplestore|RDF graphs]]

== Benchmarking multi-model databases ==