CN103246749A - 面向分布式计算的矩阵数据库***及其查询方法 - Google Patents

Abstract

本发明公开了一种面向分布式计算的矩阵数据库***及其查询方法。在该矩阵数据库***中，包括模式转换模块、元数据管理模块、数据存储***、检索***和工作流管理模块；其中，模式转换模块以关系型数据库管理***作为输入源，并将预定的数据库分解成相对独立的部分，冗余存储到数据存储***中；元数据管理模块与工作流管理模块进行双向的数据交互，用来维持原有的关系模式和新的存储结构之间的映射关系；工作流管理模块用于分析SQL语句，并对查询处理的子任务进行调度管理。相对于两个现有的数据仓库工具Hive和HadoopDB，本矩阵数据库***及其查询方法具有明显的性能优势。

Description

面向分布式计算的矩阵数据库***及其查询方法

技术领域

本发明涉及一种关系型数据库***，尤其涉及一种面向分布式计算的需要，将面向对象的实体存储和键-值索引存储集成在一起的矩阵数据库***，同时也涉及该矩阵数据库***实现查询处理的方法，属于数据库管理技术领域。

背景技术

随着互联网技术的深入发展和分布式计算技术的兴起，数据库管理***需要处理的数据量越来越庞大，基于单机运行的传统关系型数据库管理***很难满足要求。为此，人们进行了多方面的技术尝试。例如多种没有共享服务器的NoSQL分布式数据库***已经被开发出来，包括BigTable、HBase、MongoDB、Cassandra和Redis等。这些分布式数据库***可以包括数百或数千个节点，具有处理从TB级到PB级数据的能力。

在现有技术中，NoSQL分布式数据库***往往倾向于简化集中与自治相结合的控制机制，以避免复杂的逻辑分析和事务管理，实现可扩展性和可用性。然而，大量的事实已经证明，这样的设计特点只能实现弱一致性，并且很少的复杂查询可以打破传统关系型数据库在高并发访问效率上的瓶颈。例如，MongoDB作为现有的文档型数据库，适合嵌套的数据结构和不同类型的文件，但是不能针对特定的复杂查询，而且缺乏高度的可扩展性。HBase是一个分布式、可伸缩的列数据库。它构建在HDFS文件***与随机实时读写访问数据之上。每个HBase的表存储为多维稀疏图。每个单元具有一个时间戳，通过主键访问所有表。但HBase本身并不能支持SQL查询。因此，现有的NoSQL分布式数据库***大多不符合理想的数据访问要求。

MapReduce是美国Google公司提出的一种软件架构，用于实现大规模数据集的并行运算。在软件实现时，指定一个Map（映射）函数，用来将一组键值对映射成一组新的键值对；指定并发的Reduce（化简）函数，用来保证所有映射的键值对中的每一个共享相同的键组。MapReduce通过将对数据集的大规模操作分发给网络上的每个节点实现可靠性，但是它仍存在严重的效率问题。

在MapReduce的基础上，人们先后提出了Hive和HadoopDB两种数据仓库工具。Hive是一种基于Hadoop的数据仓库工具，可以将结构化的数据文件映射为一张数据库表，通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。HadoopDB是一种开源并行数据库，集关系型数据库的数据处理能力与Hadoop、MapReduce等技术于一身。与Hive等不同，HadoopDB不是简单地在语言/接口层面上的混合，而是在***实现层面上实现了MapReduce和并行数据库管理技术的集成。

发明内容

本发明所要解决的首要技术问题在于提供一种面向分布式计算的矩阵数据库***。该数据库***将面向对象的实体存储和键-值索引存储集成在一起，可以提高数据查询处理的效率。

本发明所要解决的另一技术问题在于提供上述矩阵数据库***实现查询处理的方法。

为实现上述的发明目的，本发明采用下述的技术方案：

一种面向分布式计算的矩阵数据库***，包括关系型数据库管理***、模式转换模块、元数据管理模块、数据存储***、检索***和工作流管理模块；其中，

所述模式转换模块以所述关系型数据库管理***作为输入源，并将预定的数据库分解成相对独立的部分，冗余存储到所述数据存储***中；

所述元数据管理模块与工作流管理模块进行双向的数据交互，用来维持原有的关系模式和新的存储结构之间的映射关系；

所述工作流管理模块用于分析SQL语句，并对查询处理的子任务进行调度管理。

其中较优地，所述数据存储***由面向对象的实体存储和键-值索引存储两部分组成。

其中较优地，所述数据存储***中，数据存储在面向对象的实体中，并且被划分为键-值索引存储的列。

其中较优地，所述键-值对索引存储以原始数据作为索引，每一个区域的原始数据以键-值对的形式分开存储，其中包括由所述关系型数据库管理***分配的ID和相应的数据。

其中较优地，所述数据存储***中，在进行数据分布时遵循如下的原则：（1）与相同类型的不同实体之间的字段的值索引被存储在同一节点中；（2）采用尽可能小尺寸的数据类型存储与实体相同的数据表；（3）在传输阶段中被删除的隐含关系给予优先考虑。

一种查询处理方法，基于上述的矩阵数据库***实现，包括如下步骤：

首先在工作流管理模块中，将用户输入的SQL语句分为三个部分，包括目标、范围和条件，分别进行处理；其次，关系型数据库管理***确定所涉及的实体，并根据得到的SQL语句创建查询任务；再次，将条件转换成节点连续的子任务，这些子任务被交给含有所需数据的特定服务器进行处理；在处理过程中符合规范的ID集合被逐渐收集，直到子任务全部被执行；最后，根据目标和ID进行索引存储，将存储结果提交给用户。

其中较优地，所述子任务包括映射子任务、合并子任务和过滤子任务，其中映射子任务和合并子任务运行在一个不需要等待其他子任务结束的数据流上。

其中较优地，所述过滤子任务作为最终结果的定位阶段，与所述映射子任务、所述合并子任务一起分配。

在本发明中，首先通过转化原有的关系模式实体和键-值索引，实现了更多的本土化运作和数据定位；其次为确保流和并行方式执行而使矩阵查询子任务之间相互作用，减少了写中间文件的负面影响；再次对数据结构和子任务管理进行了优化，以提高矩阵查询的性能。相关实验结果表明，相对于两个现有的数据仓库工具Hive和HadoopDB，本矩阵数据库***及其查询方法具有明显的性能优势。

附图说明

图1为本发明所提供的矩阵数据库***的体系结构示意图；

图2为从ER图映射到新的实体的示意图；

图3为键-值对索引存储的示意图；

图4为矩阵数据库***所采用的数据存储结构示意图；

图5为矩阵查询的操作示意图；

图6为查询处理的一个实施例示意图；

图7为查询处理的另一个实施例示意图。

具体实施方式

下面结合附图和具体实施方式对本发明作进一步的详细说明。

本发明人经过深入研究，认为可扩展的计算模型和支持SQL（或SQL_like）查询是分布式数据库***的未来发展趋势之一。为此，本发明提供了一种新颖的数据库***架构—矩阵数据库***。在该数据库***架构中，不仅实现了行式数据处理，也实现了列式数据处理，故称为矩阵数据库***。下面展开详细具体的说明。

图1显示了本发明所提供的矩阵数据库***的体系结构。该矩阵数据库***除了关系型数据库管理***（DBMS）之外，还包括五个主要的功能模块：a）模式转换模块；b）元数据管理模块；c）数据存储***；d）检索***（图1中将其分解为多个任务执行者）；e）工作流管理模块。其中，模式转换模块以关系型数据库管理***作为输入源，并将用户指定的数据库分解成相对独立的部分，冗余存储到数据存储***中。元数据管理模块用来维持原有的关系模式和新的可扩展存储结构之间的映射关系。元数据管理模块与工作流管理模块进行双向的数据交互。工作流管理模块用于分析SQL语句，并对查询处理的子任务进行调度管理。关于这一点，将在图5及其相关说明中进行解释。

在本发明中，数据存储***作为矩阵数据库***的重要组成部分，由面向对象的实体存储和键-值索引存储两部分组成。根据关系型数据库的设计特点，我们将这个数据结构看作ER（实体-联系）模型。在本发明所提供的矩阵数据库***中，数据组织成实体的形式，被存储在面向对象的实体中，并且被划分为键-值索引存储的列。当进行数据检索时，首先通过实体存储搜索索引存储，定位所选实体的结合关系，获得最终的检索结果。

下面，首先介绍面向对象的实体存储。在本发明中，面向对象的实体存储包括可以拓展的列和基于主键的随机存储，这样有利于阅读多层嵌套的数据表结构。在本发明所提供的矩阵数据库***中，最初的满足第二范式（2NF）以及第三或第四范式要求的数据表被重新集合成一个基于第一范式（1NF）的数据表。这个数据表中存在符合条件的关系，在它们之间可以提取元数据或者被SQL查询语句频繁地使用。数据表内采用一对一或者一对多的关系类型，即以一种联接（union）或者嵌套的形式进行连接。其中，复制操作更适合在多对多的关系类型下进行。图2显示了一个从ER（实体-联系）图映射到新的实体的实施例。考虑到操作的多样性和数据的复杂性，我们不使用单节点的简单数据管理每一个节点，而是由关系型数据库管理***依据特定服务器的哈希函数生成分配新的数据表的ID。因为作为数据库层的这部分不仅支持数据表之间的嵌套和数据表文件的管理，并且使用起来也方便、灵活。

接下来，介绍本发明中的键-值对索引存储。如图3所示，键-值对索引存储以可复制的原始数据作为索引。每一个域的原始数据被以键-值对的形式分开存储，其中一部分是由关系型数据库管理***分配的ID和相应的数据。特别地，在多对多的关系类型中，用于组成联合主键的外键，将彼此充当其他数据表的主键。在图3所示的两个索引中，第一个索引被称为键索引，在同一个实体中通过哈希值进行区分。第二个索引被称为值索引，通过哈希处理它的值。在后文中，对此有进一步的说明。

在矩阵数据库***中，实体关系的概念可以抽象为加权无向图的顶点和双方的关系实体。根据关系实体的不同特点，它们可以分为明示关系和隐含关系。前者主要产生于外键；而后者主要通过分析经常使用的SQL语句、字段之间的相似性、不同的权重、发生概率和数据大小等方式获得。

原始数据库的***问题实际上就是如何将加权无向图以最小的权重损失转化成几个子图，并保持每个实体表中适当大小的数据量。要解决这个问题，可以采用分而治之算法，不断取出其中具有最小的权重，直到加权无向图被划分成两个子图，然后以同样的方式再次划分两个子图，直到每个子图的数据大小达到要求。

接下来，将说明如何存储数据块分区，以便减少净数据转输，并利用合适的数据存储结构以加速查询。在矩阵数据库***中，我们采用了B+树的存储技术，以此来加快搜索索引值。由于键索引总是需要一次性地处理形成大量的键集合，所以按照键的顺序存储将是更好的选择。对于包含有大量副本的数据内容部分，矩阵数据库***维护一个由混合结构的列和顺序存储相对应的索引副本。图4以左右对照方式显示了矩阵数据库***所采用的数据存储结构。其中，键-值序列文件是原始文件，键索引和键数据块是分解后的文件逻辑结构。“用过两段字段重置的内容”是指包括多个副本内容、具有相当安全冗余的数据。在该数据存储结构中，为了增加本地化概率，我们在进行数据分布时遵循如下的原则：（1）与相同类型的不同实体之间的字段的值索引可被存储在同一节点中；（2）采用尽可能小尺寸的数据类型，例如数值类型，用于存储与实体相同的数据表；（3）在传输阶段中被删除的隐含关系给予优先考虑。

对于每个数据表中的数据实体而言，可以从另外一个或两个服务器中复制一个新的副本，以满足最基本的分布式***冗余。与此同时，矩阵数据库***将根据字段缺少部分的情况而改变相应的检索形式。另外，现有的存储方式虽然可以确保数据仍然被访问，但是访问速度或者支持范围将是有限的。在矩阵数据库***的设计上，将更多地用于支持读优先。这又使得数据库的重建将不可避免地改变资源的分配，或增加新的节点。因此，相比于随机写入而言，矩阵数据库***更适合于分批写入。另外，尽管一致性哈希处理可以被设计用来提高矩阵数据库***的拓展性，但还是建议通过增加节点以成倍降低重组操作的复杂性。

下面，介绍基于矩阵数据库***进行查询处理（简称矩阵查询）的具体过程。实践中，主要的矩阵查询分别是查询位置和数据集合。图5显示了矩阵查询的具体操作步骤。

在图1所示的***结构中，模式转换模块将关系型数据库管理***作为输入源，并将用户指定的数据库分解成相对独立的部分，冗余存储到数据存储***中。元数据管理模块用来维持原有的关系模式和新的可扩展存储结构之间的映射关系。元数据管理模块与工作流管理模块进行双向的数据交互。

首先，在工作流管理模块中将用户输入的SQL语句分为三个部分，包括目标、范围和条件，分别进行处理。然后，数据库管理***将确定所涉及的实体，并根据得到的SQL语句去创建一个查询任务。接着，条件被转换成节点连续的子任务，这些子任务被交给含有所需数据的特定服务器进行处理。在处理过程中，符合规范的ID集合被逐渐收集，直到子任务全部被执行。最后，根据目标需求和ID进行索引存储，将存储结果提交给用户。在上述步骤中，为了改善SQL查询的性能，我们将分段处理转变为流处理。

在查询处理过程中，有三种类型的子任务—映射、合并、过滤。简单地说，映射（Map）表示获得在给定值范围内的键-值对的键或键的列表。合并（Merge）表示两组键-值对通过不同组中的值的关系得到一组键对键。另外，过滤（Filter）通常用作实例中和不同组之间的键对键或者键列表。建立在以哈希为基础的散列分区存储结构上的映射子任务和合并子任务能运行在一个不需要等待其他子任务结束的流上，这意味着打破了执行限制。过滤子任务作为最终结果的定位阶段，总是和映射子任务、合并子任务一起分配。这种子任务调度方式减少了网络传输的负担。

图6显示了一个查询处理的具体实施例。相应的SQL查询语句如下：

Select province，avg（study_time）from student

where grade＝5and score＞80group by province;（1）

上述SQL查询语句转换为一系列的子任务。通过散列“5”和搜索元数据，矩阵数据库***会发送一个映射子任务，分配给服务器A中包含所有的密钥对满足“grade＝5”在现场“grade”，同时将分发的运行子任务的所有节点保持学生的“分数”表。所有映射子任务可以并行执行。过滤子任务等待提前收集所有候选人的映射子任务。在多表操作的情况下，这个SQL查询语句不涉及合并子任务。

另外，当面对如下的SQL查询语句时，将会涉及合并子任务。

Select province，avg（score）from student as s，teacheras t

where s.classId＝t.classId and s.grade＝12and t.age＞40group by province;

（2）

图7显示了上述SQL查询语句的执行过程。其中，针对密钥索引的映射子任务和针对索引值的映射子任务在合并子任务中进行合并，合并结果送入过滤器中执行过滤子任务，最后执行数据收集环节。

在矩阵查询中，应该尽可能地避免中间文件写入。因此，在本发明中通过筛选键，逐步地减少移动大的结果集进行数据流查询。在各个子任务中，每个数据包可以及时处理，并被直接传送到下一个目的地进行输入。在一般情况下，分发子任务和合并子任务并不需要等待多个输入和合并结果集，而过滤器可以减少内存占用量。然而，中间文件有时是不可避免的，例如当查询涉及复杂的连接操作时。在这种情况下，工作流管理模块通过上述过程将代替一系列的映射子任务、合并子任务，并减少单节点的定位。此外，调节数据包的传输时间是有帮助的，可以改善内存占用所造成的性能问题。

为了避免一些数据丢失所造成的硬件或软件的麻烦，可以根据丢失数据的类型对上述的矩阵查询过程进行调整。包括：（a）如果缺少实体表，矩形数据库***会降解成面向列的数据库；（b）丢失单个索引，如果缺少一个本地化的一部分，则每个节点都应参与执行任务，（c）如果丢失所有两个索引，矩形数据库***则会降解成多节点的实体表。

在本发明所提供的矩阵数据库***中，首先通过转化原有的关系模式实体和键-值索引，实现了更多的本土化运作和数据定位；其次为确保流和并行方式执行而使矩阵查询子任务之间相互作用，减少了写中间文件的负面影响；再次对数据结构和子任务管理进行了优化，以提高矩阵查询的性能。相关实验结果表明，相对于两个现有的数据仓库工具Hive和HadoopDB，本矩阵数据库***及其查询方法具有明显的性能优势。

以上对本发明所提供的面向分布式计算的矩阵数据库***及其查询方法进行了详细的说明。对本领域的技术人员而言，在不背离本发明实质精神的前提下对它所做的任何显而易见的改动，都将构成对本发明专利权的侵犯，将承担相应的法律责任。

Claims (8)

1.一种面向分布式计算的矩阵数据库***，包括关系型数据库管理***，其特征在于还包括模式转换模块、元数据管理模块、数据存储***、检索***和工作流管理模块；其中，

所述模式转换模块以所述关系型数据库管理***作为输入源，并将预定的数据库分解成相对独立的部分，冗余存储到所述数据存储***中；

所述元数据管理模块与工作流管理模块进行双向的数据交互，用来维持原有的关系模式和新的存储结构之间的映射关系；

所述工作流管理模块用于分析SQL语句，并对查询处理的子任务进行调度管理。

2.如权利要求1所述的矩阵数据库***，其特征在于：

所述数据存储***由面向对象的实体存储和键-值索引存储两部分组成。

3.如权利要求2所述的矩阵数据库***，其特征在于：

所述数据存储***中，数据存储在面向对象的实体中，并且被划分为键-值索引存储的列。

4.如权利要求2所述的矩阵数据库***，其特征在于：

所述键-值对索引存储以原始数据作为索引，每一个区域的原始数据以键-值对的形式分开存储，其中包括由所述关系型数据库管理***分配的ID和相应的数据。

5.如权利要求2所述的矩阵数据库***，其特征在于：

所述数据存储***中，在进行数据分布时遵循如下的原则：（1）与相同类型的不同实体之间的字段的值索引被存储在同一节点中；（2）采用尽可能小尺寸的数据类型存储与实体相同的数据表；（3）在传输阶段中被删除的隐含关系给予优先考虑。

6.一种查询处理方法，基于权利要求1所述的矩阵数据库***实现，其特征在于包括如下步骤：

首先在工作流管理模块中，将用户输入的SQL语句分为三个部分，包括目标、范围和条件，分别进行处理；其次，关系型数据库管理***确定所涉及的实体，并根据得到的SQL语句创建查询任务；再次，将条件转换成节点连续的子任务，这些子任务被交给含有所需数据的特定服务器进行处理；在处理过程中符合规范的ID集合被逐渐收集，直到子任务全部被执行；最后，根据目标和ID进行索引存储，将存储结果提交给用户。

7.如权利要求6所述的查询处理方法，其特征在于：

所述子任务包括映射子任务、合并子任务和过滤子任务，其中映射子任务和合并子任务运行在一个不需要等待其他子任务结束的数据流上。

8.如权利要求6所述的查询处理方法，其特征在于：

所述过滤子任务作为最终结果的定位阶段，与所述映射子任务、所述合并子任务一起分配。

Images