## 2 Background
### Polyglot Persistence  
The general polyglot persistence conception was evaluated from the polyglot programming conception proposed by [PERSON] in 2006. The main idea of both conceptions is choosing the right tool for the given task. In polyglot programming, it is a programming language, in polyglot persistence, it is a data storage engine. Polyglot persistence defines a hybrid approach where different kinds of data are best dealt with in different data stores [46; 47].  
No single database technology, be it SQL or NoSQL, can satisfy all of the business needs and solve all technological challenges. To choose the right database, a set of criteria has to be considered: the data model, CAP support, capacity, performance, query API, reliability, data persistence, rebalancing, and business support. It is also important to evaluate databases from different viewpoints: technical, business, system domain, and environmental. Polyglot persistence technology has the potential to scale to millions of users a day and be able to store an incredible amount of data by combining SQL and NoSQL technologies into one solution [37; 38; 39; 40; 41; 42; 43; 44; 45; 46; 47; 48].  
[PERSON] categorized polyglot database architectures into three types: polyglot persistence, lambda architecture, and multi-model databases [47]. [PERSON] recommends using polyglot persistence only if several diverse data models have to be supported, otherwise there is a risk to overhead maintenance. The lambda architecture is recommended for real-time data analytics applications. The lambda architecture relies on the same data stores as polyglot persistence and has similar disadvantages. Multi-model databases store data in a single store but provide access to the data with different APIs according to different data models. This type of polyglot database architecture is recommended if only a limited set of data models is required by the accessing applications.  
[PERSON] et al. proposed a modeling methodology capable of unifying design patterns for polyglot persistence, bringing an overview of the system as well as a detailed view of each database design [46]. The proposed methodology consists of three steps: (1) conceptual design, (2) logical design, and (3) physical design. The conceptual design translates the requirements into a conceptual database schema. The logical design realizes the translation of the conceptual model to the internal model of a database management system. The physical design implements all peculiarities of each database software.  
According to [PERSON] et al., a crucial part of the efficiency of a polyglot system is the selection of a database engine [39]. The authors proposed the design of a polyglot persistence system for an e-commerce application and compared it with a system where data were stored only in the SQL or NoSQL databases. The most optimum results were obtained from the polyglot system with three databases: (1) document type (Mongo DB), and (2) key-value type (Redis), and (3) relational database (SQLite).  
An evaluation of the NoSQL Multi-Model data stores in polyglot persistence applications were conducted by [PERSON] et al. [29]. Multi-model databases (ArangoDB and OrientDB) were compared with a combination of the document type database (MongoDB) and graph type database (Neo4j). The experimental results showed that in some scenarios, multi-model data stores had similar or even better performance than a combination of different data stores.