## 2 Related Work  
Unifying querying over different databases spanning various data models is a tedious task. The problem of accessing heterogeneous data from polysources has been researched in the context of multidatabase systems, Polystore systems, and data integration systems [6]. The existing datasets have a large amount of data obtained from various data sources. There can be multiple languages to access these different datasets. The bottom-up approach to making a Polystore considers language translation as the main task, as shown in Figure 1. The bottom-up approach is not preferable if a lot of data come from various sources and environments which support other languages and schemes. Thus, data and information in these kinds of systems create database connectivity issues or compatibility issues. HYBRID is an analytical Polystore that is used to manage this type of data. HYBRID.POLY was created via a bottom-up methodology. HYBRID.POLY provides a unified platform for the storage, access, and analysis of several heterogeneous data types [25]. Numerous data models are supported by the in-memory storage engine. HYBRID.POLY's query interface allows queries written in a hybrid language. As a superset of SQL, the hybrid language can generate complex analytical queries on both nonrelational data (JSON, XML, and media files) and relational data. HYBRID optimizes the query and is capable of processing complex queries with a high number of nodes. The HYBRID.POLY query processing engine consists of a query parser, a query compiler, and a query optimizer. HYBRID.POLY utilizes a single unified data store that is capable of storing any form of data. This improves performance by lowering query processing and transmission costs. The BigDAWG (Big Data Analytics Working Group) Architecture at MIT includes a query function for huge multiple data sets in the MIMIC II medical domain [26]. BigDAWG's architecture comprises four layers: database and storage engines, islands, middleware, application programming interfaces, and applications. It is aimed for a bottom-up strategy. BigDAWG's original release supported three free and open-source database engines: PostgreSQL (SQL), Apache Accumulo (NoSQL), and SciDB (NEW SQL). Additionally, it accommodates relational, array, and text islands. The client establishes communication with a Middleware or an API. The middleware intercepts a client query and forwards it to the relevant island or islands for execution. The Shim interprets queries received from each  
Figure 1: Bottom-up design of a Polystore system. island and routes them to the appropriate database. Casts are used to migrate data across several databases [27]. The authors propose CloudMdsQL [28], a query language and query engine for cloud data. It is the golden mean between the two primary groups of query languages and combines the expressiveness of functional languages with the manipulation of declarative relational languages when it comes to integrating disparate data management systems. It also allows embedding invocations in native query interfaces. As it uses a distributed query engine, nodes can share code and data and there is no centralized wrapper/mediator. Small intermediate data can be processed by one node and they preserve query language expressivity. CloudMdsQL relies on the relational data model for join, union, and other relational algebra operations. They have integrated three DBMS--Sparksee (a graph database with a Python API), Derby (a relational database with a JDBC driver), and MongoDB for validation (a document database with a Java API). They demonstrated that CloudMdsQL meets the five important requirements for a cloud multiple-database query language by performing representative queries and showing the query engine's processing steps. It also optimizes query execution by rewriting queries using bind joins and pushed down selects, calculating optimal join execution orders, and transporting intermediate data efficiently. The results show overall query execution speed.