Uniform Query Framework for Relational and NoSQL Databases
J.B. Karanjekar1 and M.B. Chandak2
Abstract: As the data managed by applications has evolved over the years with the arrival of Web 2.0, a large number of new databases have been developed to manage various types of data. While the traditional relational databases continue to exist, NoSQL databases which are document oriented or key-value stores or columnar continue to evolve and are embraced very rapidly across the industry. It is not just the type of data handled by these databases that is different but also the query language they use is also different. This paper talks about a uniform query framework that can be used for traditional relational databases and NoSQL databases. This query framework can also perform joins, aggregates, filter on data from various data sources in a single query.
Keywords: NoSQL, RDBMS, data tetrieval, inter-database joins, SQL, Cassandra, MongoDB, Calcite, MySQL.
1 Introduction
The rise of cloud computing and Web 2.0 has opened an ongoing debate regarding the pros and cons of using traditional Relational Database Management Systems or document and key-value based NoSQL (Not-Only SQL) implementations. While the NoSQL databases are being embraced at rapid pace, no one is rejecting the relational databases just yet. What has helped NoSQL databases gain the popularity is its ability to scale out horizontally which would not have been possible without cloud computing. Amazonrsquo;s Elastic Compute Cloud (EC2) on the AWS platform was released in 2006 and took advantage of low-cost servers and high-bandwidth networks first offered by Grid and Utility computing methods [Foote (2017)]. The merits of reliability, scalability and accessibility of data quickly led the public to see the values of using Infrastructure-as-a-Service over dedicated or shared hosting solutions, and several copycat companies have sprung up in recent years as a result.
For database administrators, the challenge has become choosing which among a wide variety
of emerging database types to implement when hosting in the cloud. The relational model has
its advantages in documentation, simplicity, familiarity, data integrity and reliability. SQL implementations in the cloud are capable of far morecomplex queries and aggregates than other solutions [Cattell (2010)]. They support transactions to ensure only atomic changes are made to your data while keeping a single master copy by which all other copies replicate. The drawbacks come when a developer needs to scale outward across multiple servers. Standard RDBMSrsquo;s have trouble with efficiently expanding a database due to their inherent complexity of organization [De Witt, Floratou, Patel, Teletia and Zhang (2012)].
On the other hand, SQL implementations are either key-value based, columnar or document-based and have grown in popularity because of their ease of scalability. NoSQL implementations are based on entities and support many of the functions of RDBMS such as sorting, indexing, projecting and querying but are not as reliable or effective when using complex database models. Transactions that guarantee atomic consistency are not supported and updating the database across multiple entities is an eventual process. Joins and ACID guarantees are traded off in favour of transaction speed. Scalability is where NoSQL earns its edge wherein quick ability to scale out or shrink the database allows administrators to have flexibility to meet their requirements [Chi, Pierre and Wei (2012)].
One of the challenges faced by NoSQL database family is lack of standards in NoSQL space. For so many years before NoSQL gained momentum, there was just one query language that was good enough for all the databases. Now there are many flavours trying to establish their own standards. Through this paper we are presenting a framework with which traditional SQL style of query mechanism can be implemented for RDBMS and NoSQL database systems. This framework also allows users to query different databases through a single query and perform operations such as joins, aggregation, nested queries and filters.
In this paper we are focusing on providing a uniform query framework for four data storage implementations which are MySQL, MongoDB, Cassandra and CSV files. MySQL has become one of the most popular open-source implementations of RDBMS for online applications. MySQL is highly efficient with complex structured data models and queries. MongoDB is currently the most popular NoSQL solution largely because of its simplicity of use and efficiency in clustering data. Unstructured data such as that gathered by social media websites is presumed to be best handled by NoSQL implementations. Cassandra is a massively scalable columnar NoSQL database which provides users the ability to store large amounts structured and semi-structured data. Cassandrarsquo;s ability to scale out across multiple data centers is what make companies turn to Cassandra to store their data in the cloud.
2 Related work
The comparison between traditional RDBMS and NoSQL database has been widely studied in the distributed systems and database communities. While RDBMS has SQL, there are many different mechanisms developed to retrieve data from NoSQL databases. For instance, Cassandra provides a python based cqlsh utility [Cqlsh] as well as libraries and modules for different languages such as Python, JAVA, Go, C , etc. [Cassandra Client Drivers]. Similarly, MongoDB has the mongo shell to query data and also drive
and client libraries for almost all popular programming languages [MongoDB Drivers].
MongoDB also provides connectors for Hadoop.However, the query language used by these dat
剩余内容已隐藏，支付完成后下载完整资料
用于关系数据库和NoSQL数据库的统一查询框架
J.B. Karanjekar1 和M.B. Chandak2
摘要:随着Web 2.0时代的到来，应用程序所需要管理的数据正在飞速膨胀，人们开发了大量的新型数据库来管理各种类型的数据。在传统的关系数据库的基础上，面向文档或键值存储或列的NoSQL数据库继续扩展，并迅速在整个行业中赢得了大量市场。这些数据库不仅处理的数据类型不同，使用的查询语言也各不不同。本文介绍了一种适用于传统关系数据库和NoSQL数据库的统一查询框架。此查询框架还可以在单个查询中，对来自不同数据源的数据进行连接、聚合和筛选等操作。
关键词:NoSQL, RDBMS, data tetrieval，Inter数据库联接，SQL, Cassandra数据库, MongoDB,MySQL。
- 介绍
云计算和Web 2.0的兴起引发了，关于传统关系数据库管理系统和NoSQL数据库实现的优缺点的持续争论。虽然NoSQL数据库正在迅速获得市场，但关系数据库仍然拥有大量用户。NoSQL数据库流行的很大原因是，它具有强大的横向扩展的能力，而这些在没有云计算的情况下是很难实现的。由Amazon在AWS平台上于2006年发布弹性计算云(EC2)，利用了网格和实用计算方法，首次同时提供了低成本服务器和高带宽网络。该方案的可靠性、可伸缩性和数据可访问性的优点，使公众很快意识到在专用或共享主机解决方案上，使用基础设施服务的价值，因此，近年来出现了很多模仿公司。
对于数据库管理员来说，最大的挑战在于，在云托管方面，需要从各种各样的数据库中选择出一种，合适的数据库。关系型数据库有在文档化、简单性、熟悉性、数据完整性和可靠性方面具有很大有点。然而云计算中的SQL，相较于其他，需要能够进行更复杂的查询和聚合操作。它们支持事务，以确保对数据进行更改时，同时保留一份原始数据，所有其他副本都可以通过这个原始数据进行复制。当开发人员需要跨越多个服务器操作时，问题就出现了。由于复杂程度的问题，标准RDBMS很难有效地扩展数据库。
另一方面，SQL实现要么是基于键值的，要么是基于列的，要么是基于文档的，并且由于其易扩展性越来越受欢迎了。NoSQL实现基于实体，支持RDBMS的许多功能，如排序、索引、投影和查询等，但是在使用复杂的数据库模型时，这些功能就显得不那么可靠有效了。NoSQL具有可伸缩性的优势，通过快速扩展或收缩数据库，管理员可以灵活地应对他们的需求。
NoSQL数据库家族面临的挑战之一是缺乏统一标准。在NoSQL大好发展之前的这些年里，只有一种查询语言是可以适用于所有数据库的。然而现在有很多数据库都在尝试建立自己的标准。本文提出了一个面向RDBMS和NoSQL数据库，实现传统的SQL查询机制的框架。该框架还允许用户通过单个查询，查询不同的数据库，并进行连接、聚合、嵌套查询和过滤器操作等等。
本文重点为MySQL、MongoDB、Cassandra和CSV文件这四种数据存储实现提供一个统一的查询框架。MySQL已经成为如今的应用程序中最流行的RDBMS开源实现之一。MySQL对于复杂的结构化数据模型的查询是非常高效的。MongoDB是目前最流行的NoSQL解决方案，主要原因是它简单易用和集群数据的效率高。社会媒体网站收集的非结构化数据，被认为是NoSQL实现最好的处理方式。Cassandra是一个可大规模伸缩的列式NoSQL数据库，它为用户提供了存储大量结构化和半结构化数据的能力。Cassandra能够跨多个数据中心进行扩展，正是这种能力让企业转向Cassandra，将数据存储在云中。
- 相关功能
传统的RDBMS与NoSQL数据库的优劣比较，在分布式系统和数据库社区中得到了广泛的研究。虽然RDBMS有SQL，但是人们仍然开发了许多不同的机制，用于从NoSQL数据库中进行数据检索。例如，Cassandra提供了一个基于python的cqlsh实用程序[cqlsh]，以及用于不同语言(如python、JAVA、Go、c 等)的库和模块[Cassandra客户端驱动程序]。类似地，MongoDB也有mongo shell来查询数据和驱动以及几乎所有流行编程语言的客户端库。MongoDB还为Hadoop提供连接器。但是，这些数据库使用的查询语言并不不同。MySQL使用SQL, 而Cassandra使用却是Cassandra的专属查询语言(CQL)， MongoDB使用自己的JSON查询语法。毫无疑问，这些数据库使用这些不同的查询语言，各有各的优势和原因，但是有一个问题却一再出现，还没有对标准查询语言的本机支持。Couchbase社区开发了一种名为N1QL的数据库查询语言，它扩展了JSON对象的SQL。但是，它不像Cassandra那样支持柱状数据库。因此，需要为RDBMS和NoSQL数据库的标准查询机制提供统一的框架。
3 体系结构
体系结构的主要组件(图1)是框架层，它为整个设置提供了管理框架。将各种数据库系统连接到框架层。框架层可以在不影响其他数据库系统的情况下，添加和删除任何特定数据库系统的节点。
图1:系统架构
框架层是一个动态数据管理系统。它有许多组成典型数据库管理系统的组件，但是它却故意舍弃了诸如数据存储和处理存储数据的算法等组件。它被有意地排除在存储数据的业务之外，因为它只能作为不同的数据存储和处理引擎之间的媒介。框架层负责维护数据、接受来自客户端的请求，处理查询并把结果返回客户端。
3.1 连接适配
框架层数据库的连接配置，如图2所示。它是以JSON文档的形式存储的，其中包含数据库、相关模式/键空间和Apache Calcite的模式工厂的连接参数。在框架初始化时，这些适配器用于数据库连接和模式初始化。
图2:MySQL的示例配置文件
3.2 架构发现
该框架使用Apache Calcite进行架构发现。当我们定义连接适配器时，模式工厂和连接参数用于扫描数据源中可用的表。当解析查询并计划使用某些表时，Apache Calcite读取这些表并执行对应的的操作。我们正在为Cassandra、CSV、MongoDB和MySQL使用连接适配器和模式工厂。MySQL适配器使用JDBC schema factory，它由Apache Avatica提供支持。为了详细说明模式发现，我们以CSV模式工厂为例。当使用CSV模型的参数信息初始化模式工厂时，它使用CSV文件所在目录的路径，初始化模式对象。这个模式对象的任务是生成一个表列表。模式扫描目录并找到所有名称以“”结尾的文件。并为它们创建表。表对象依次实现 “表”接口。当解析查询并从这些文件中获取数据时，此接口将从CSV文件中读取数据。
3.3 查询流
该框架的一大优点是，能够支持行业标准的SQL查询语言。底层数据源支持哪种查询检索机制并不重要。框架层首先接收SQL查询，如图3所示，然后解析它，优化它，并标识处理查询所需的下游数据库。一旦确定了数据库，Apache Calcite中与这些数据库对应的“表”接口，将读取用于查询的数据。当从单个节点读取数据时，框架层对数据执行最终处理，并将结果流回客户端。
图3:查询流
3.4 查询解析和优化
框架层使用Calcite解析传入查询。当查询首次涉及Calcite时，它解析查询并将其转换为关系数据。解析器输出的，是一个语言无关的计算机逻辑，它表示查询。当涉及到读取表时，我们在会话3.2和3.3中谈到的“表”接口，可以很好地用于小型和中型表。然而，如果一个表有100列和100万行，我们就不会希望访问所有数据查询了。我们希望通过找到访问所需数据来优化和简化操作。优化是通过应用基于查询关系代数转换查询的planner规则来实现的。Calcite对查询的关系代数应用规则，以便将其转换。
下面用一个示例来详细说明查询优化，请观察下面的查询，它显示了MySQL的一个名为“weekly_sales”的表和Cassandra的另一个名为“stores”的表的联合连接。
SELECT ca.'store_type', SUM(my.'weekly_sales')
FROM 'mysql'.'weekly_sales' my, 'cassandra'.'stores' ca
WHERE my.'store_number' = ca.'store_number'
AND my.'week_date' = #39;2011-11-25#39;
GROUP BY ca.'store_type'
解析之后，查询将如图4所示，其中来自两个数据源的数据将被连接，并对合并的数据执行筛选操作。
图4:优化之前的执行计划
上面的查询产生了预期的结果，但是Calcite在连接两个不同数据源时，需要使用转换规则或planner规则进行优化。我们希望实现优化，既能够查询产生正确的结果，又能尽可能高效地使用更低的成本。
当应用查询转换规则时，执行方案发生了变化，如图5所示。在本例中，过滤器在连接之前被推送到MySQL数据库。这里有两个转换规则。一种方法是，如果过滤器不引用来自其他输入的列，则可以将过滤器推入内部联接的输入。第二个是，如果数据源能够独立执行过滤器，则可以将过滤器下推到数据源。
图5:优化之后的执行计划
- 数据模型
考虑到关系数据库和NoSQL数据库的优缺点，我们同时使用了高度结构化数据模型和半非结构化数据模型。对于结构化数据，我们使用Walmart发布的位于不同地区的45家门店的历史销售数据，如图6所示;对于非结构化数据，我们使用Reddit发布的用户评论的数据集。我们为每个数据库(MySQL、Cassandra和MongoDB)使用一个单独的AWS EC2实例，并将相同的示例数据上传到每个数据库。
图6:结构化数据的实体关系模型
- 查询执行
在本文中，我们讨论了在只读数据库操作时，主要使用连接、聚合、过滤器和嵌套查询的SELECT查询的方式。这些操作通过Calcite的代数生成器传递，其中每个查询都被转换为对应的关系代数，并被表示为关系运算符树。查询规划器，规定使用，保留语义的数学标识，用来转换表达式树。例如，如果过滤器不引用，来自其他输入的列，则将过滤器推入内部联接。
如第3.4节所述，通过对关系表达式，反复使用用planner规则来优化查询。正如模式发现一节中提到的，一旦解析了查询，并决定了数据库中使用哪个表，Calcite就会调用表对象来读取数据并执行对应操作。
6.1 Inter-database join
为了演示数据库间连接，我们使用下面的查询来找出store_number、store_type和任意给定周内销售额超过500,000美元的商店的。在这个查询中，在MongoDB中的一个名为weekly_sales的集合和MySQL数据库中的一个名为stores的表之间执行一个join查询。
SELECT my.'store_number', my.'store_type', my.'size'
FROM 'mongo'.'weekly_sales' mo, 'mysql'.'stores' my
WHERE mo.'weekly_sales' gt; 500000
AND mo.'store_number' = my.'store_number';
这个查询花费了286毫秒。查询中提到的模式名mongo和mysql，分别是指在连接适配器中配置MongoDB和mysql数据库时使用的模式名。
6.2 聚合
框架支持SUM、AVG、COUNT、MIN、MAX等聚合函数。在下面的例子中，我们试图找出周销售额在2011年11月25日(感恩节后的一天)结束的那一周(按store_type分组)的总和。在本例中，我们使用了Cassandra和MySQL数据库的组合。
SELECT ca.'store_type', SUM(my.'weekly_sales')
FROM 'mysql'.'weekly_sales' my, 'cassandra'.'stores' ca
WHERE my.'store_num
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[442757]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
