一种分布式并行数据库系统的数据分区方法

暂无

一种分布式并行数据库系统的数据分区方法\n技术领域\n[0001] 本发明涉及一种分布式并行数据库系统，尤其涉及一种分布式并行数据库系统的数据分区方法。\n背景技术\n[0002] 将数据存储在数据库中是常用的数据管理方法，特别是存储在关系型数据库中。我们可以根据所要管理的数据需求，选择成熟的数据库管理系统(DBMS：Database Management System)，用标准的数据定义语言(如SQL DDL)，定义包含数据表(Table)或关系(Relation)、数据结构、索引、主键(Primary Key)和外键(Foreign Key)等信息的数据库数据管理方案(Database Schema)，部署数据库系统。而应用程序根据DBMS提供的数据操作语言(如SQL DML)，可以进行数据操作，如插入、查询、更新、导入和导出等。\n[0003] 当前许多行业应用，产生和累积的数据量非常巨大，例如物联网感知数据(Sensor Data)、金融交易数据(Transaction Data)、电子商务商品数据(GoodsData)、公司销售数据(Sales Data)等数据集(Data Set)。这些数据集可能会达到几百TBs(TeraBytes)或PBs(PetaBytes)这样海量的规模，而且随着时间的增长和业务的发展，产生数据的速度也可能会不断提高。对这些海量数据的操作效率，如查询速度，提出了更高的要求。\n[0004] 对于海量数据的管理，单节点的数据库系统，受其计算或存储能力的局限，已经不能胜任。分布式并行结构或极大规模并行处理(MPP：Massively ParallelProcessing)结构的数据库或数据仓库系统可以提供更好的容量和性能方面的伸缩性和扩展性。其中的多节点无共享集群(Shared-nothing Cluster)架构已被证实具有管理大规模数据的优势。\n[0005] 无共享(Shared-nothing)多节点分布式并行数据库系统架构图如图1所示，前端服务器实现一个全局分区器(Partitioner)，它将各个数据表按照某种规则(如按各数据表特定属性域的HASH值或时间段等)进行分区(Partitioning)或分片(Sharding)，将数据分布存储在多个不同的存储和处理节点上(如图中的节点1～节点N)，并由每个节点上运行的本地数据库实例(Local Database Instance)，来管理根据分区器分配到该节点上的数据分区或分片；同时，一个运行在前端服务器上的全局优化查询器(Global Querier)，对应用发起的特定查询(Query)，进行分析，并发送(Dispatch)给各节点数据库系统实例，由各节点上的本地查询器(Local Querier)来处理，然后将结果返回给全局查询器，进行进一步的处理，如合并(Merge)和排序(Sort)等操作，最后将结果返回给相应的应用。\n[0006] 分 区 器 在 对 各 数 据 表 进 行 划 分 时，采 用 诸 如 轮 转 划 分 (Round RobinPartitioning)、散列划分(Hash Partitioning)、范围划分(Range Partitioning)和链表划分(List Partitioning)等分区方法，将数据发送给相应的节点。由于采用的分区方法单独作用于各个数据表，因此，对于针对多个数据表的较复杂的关联查询时，特别是涉及多表间连接(Join)操作的查询，全局查询器无论根据Join查询判断式(Predicate)所涉及的任何一个表的分区信息，将查询发送给各分区所对应的节点上的局部查询器处理时，对于Join判断式所涉及的其他表，各节点都要从其他节点上的分区拷贝搬运数据。这种查询时的节点间数据搬运也称作动态再分区(Dynamic Repartitioning)，不仅会消耗网络带宽，也会产生传输耗时，极大地增加查询的响应时间，影响查询效率。\n发明内容\n[0007] 为了解决现有技术存在的不足，本发明的目的在于提供一种分布式并行数据库系统的数据分区方法，消除查询时节点间数据的拷贝和搬运，提高查询响应速度和效率。\n[0008] 为实现上述目的，本发明提供的一种分布式并行数据库系统的数据分区方法，该方法包括以下步骤：\n[0009] 根据构建的分布式并行数据库系统及分布规则，创建事实表和维度表，并将所述事实表纪录和维度表纪录插入到节点上；\n[0010] 将维度表纪录复制到事实表的节点上；\n[0011] 对数据进行删除和更新。\n[0012] 本发明在对数据集或数据流分区导入或插入分布式数据库系统时，能在每一个节点，满足数据库方案所定义的表间关系，特别是主-外键约束条件，使每一个节点上的数据，具有数据的局部完备性。对于利用主-外键约束条件进行表间连接的查询处理，由于各节点的数据对这类查询具有局部完备性，不需要在节点间做数据动态再分区，避免了数据的网络传输耗时，降低查询响应时间，提高查询效率。\n[0013] 本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。\n附图说明\n[0014] 附图用来提供对本发明的进一步理解，并且构成说明书的一部分，并与本发明的实施例一起，用于解释本发明，并不构成对本发明的限制。在附图中：\n[0015] 图1为现有技术中无共享多节点分布式并行数据库系统架构图；\n[0016] 图2为根据本发明的分布式并行数据库系统的数据分区方法流程图；\n[0017] 图3为根据本发明的事实表和维度表关联图；\n[0018] 图4为根据本发明的划分成单一星型后的数据表关系图；\n[0019] 图5为根据本发明的维度表纪录插入后数据分布图；\n[0020] 图6为根据本发明的事实表纪录插入后数据分布情况示意图；\n[0021] 图7为根据本发明的Bloom Filter位数组初始值示意图；\n[0022] 图8为根据本发明的根据x的哈希函数值设置位数组示意图；\n[0023] 图9为根据本发明的判断y是否属于集合示意图。\n具体实施方式\n[0024] 以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。\n[0025] 在构建数据库系统或以分布式数据库为基础构建的数据仓库时，一般总是将实际的事实数据和用于描述属性的数据用不同的表分隔，实际的事实数据存放于一类被称为事实表(Fact table)的表中，而从不同角度来描述属性的数据则放到不同的维度表(Dimension table)中。比如，一个Sales数据库或数据仓库可以这样设计，每一笔销售记录，应该会包含销售的产品，销售的客户，产品的供货商，销售的时间，销售的数量和获得的收入等。对于销售的数量和金额这类具体的数字型的数据，通常是系统要分析的对象，而对于像时间，产品，客户，供货商，我们往往希望从这些不同的角度来得到数字型数据的一个统计结果。所以，一般将数字型的数据存放在事实表中，将时间、产品、客户、供货商存放在不同的维度表中。自然，在维度表和事实表之间存在一个主-外键的关联，各个维度表之间则没有关系。\n[0026] 以类似上述的方式来建模数据库系统关系和属性的方式，由于它将不同的数据表分为维度表和事实表，并以主-外键相关联，拓扑上，事实表处于中间的位置，维度表则绕事实表围成一圈，形似一颗星，所以被称数据库系统的星形模型(Star Schema)。事实表中除了区分每条纪录的外键(关联维度表的主键)外，就只有我们关心的数字型数据，所以事实表中的每条纪录，有个专门的术语称之为度量(Measurement)，因为我们利用数据库或数据仓库做统计分析的时候，这些数据就是统计分析的一个个基本单位，也就是度量值。我们知道，在数据库系统查询和分析中，一般的查询处理，总是基于对度量即事实表度量的分析和处理展开进行的，即在查询的判断式中，总是含有涉及事实表的判断式。\n[0027] 星型模型是数据库系统或数据仓库建模关系和数据的最主要的模型。另外，从星型模型中衍生出来主要有雪花模型(Snowflake Schema)。雪花模型就是在星形模型的基础上，对维度表做规范化后得到的模型。由于每个维度表规范化可能得到一个星形拓扑或多级的星形拓扑，使整个模型拓扑上形似雪花，所以称为雪花模型。雪花模型比起星模型就更加复杂，查询的时候也需要关联更多的表。\n[0028] 图2为根据本发明的分布式并行数据库系统的数据分区方法流程图，下面将参考图2，对本发明的分布式并行数据库系统的数据分区方法进行详细描述：\n[0029] 首先，在步骤201，根据所要管理的数据性质以及节点数，构建分布式并行数据库系统。例如，在销售数据库或数据仓库中，构建的数据表包含有销售的产品，销售的客户，产品的供货商，销售的时间，销售的数量和获得的收入等数据；\n[0030] 在步骤202，创建事实表和维度表。创建用于存放实际的事实数据的事实表，定义该事实表的主键和外键，并将事实数据的纪录插入到该事实表，该事实数据如上述Sales数据库或数据仓库中销售的数量和获得的收入这类具体的数字型的数据；创建用于存放从不同角度来描述属性的数据的维度表，定义该维度表的主键，并将描述属性的数据的纪录插入到该维度表中，描述属性的数据如上述Sales数据库或数据仓库中的时间、产品、客户、供货商等数据；利用事实表的外键与维度表的主键，对事实表和维度表进行关联。图\n3为根据本发明的事实表和维度表关联图，如图3所示，Table1和Table2定义为事实表，Table3、Table4和Table5定义为维度表。Table1的外键Field11关联Talbe3的主键ID3，Table1的外键Field12和Table2的外键Field21均关联Talbe4的主键ID4，Table2的外键Field22关联Talbe5的主键ID5；\n[0031] 图4为根据本发明的划分成单一星型后的数据表关系图，如图4所示，根据图3的事实表和维度表关联图，把维度表Table4划分成逻辑的2张表，形成2个单一的星型结构，维度表Table4在物理上仍然是一张表；\n[0032] 在步骤203，将事实表纪录和维度表纪录插入到节点上。在本步骤中是按照分区策略，将事实表纪录和维度表纪录插入到不同的节点上；\n[0033] 在步骤204，复制维度表纪录。事实表的纪录插入完成后，为了保证数据的局部完备性，将该事实表的纪录外键关联的维度表的纪录，复制到本节点。这样，表间连接(Join)生成连接表的时候，不需要搬运其他节点的数据，减少网络开销。\n[0034] 确定将维度表的纪录复制到事实表的节点上的方法是：首先要确定的是，事实表的外键所关联的维度表才需要复制；其次，该新插入纪录中的外键所关联的维度表中的纪录，需要复制到该事实表纪录的同一个节点上。例如，事实表的纪录的外键值为X，那么需要将维度表中主键值为X的纪录复制到本节点。如果事实表的纪录有多个外键，需要将每个外键关联的维度表的纪录复制过来。由于分区一般是以表的主键作为关键字，所以根据事实表外键的值(也就是维度表主键值)，能够很容易找到维度表中需要的纪录位于哪个节点上。\n[0035] 图5为根据本发明的维度表纪录插入后数据分布图，如图5所示，以图4中的Table1、Table3和Table4这一星型为例，在维度表(Table3和Table4)纪录插入后，各节点上的数据分布情况，从图5可以看出，在事实表纪录插入之前，维度表的纪录在各节点上是不重叠的(Non-Overlap)。\n[0036] 图6为根据本发明的事实表纪录插入后数据分布情况示意图，如图6所示，在节点\n1插入一条Table1的纪录，其Field11(值为2)和Field12(值为3)所关联的Table3和Table4的纪录(分别为ID3＝2和ID4＝3)在节点1上不存在，所以需要分别从节点2和节点3复制过来；\n[0037] 在节点2插入一条Table1的纪录，其Field11(值为2)所关联的Table3的纪录(ID3＝2)在节点2上已经存在，不需要复制。而Field12(值为1)所关联的Table4的纪录(ID4＝1)在节点2上不存在，所以需要从节点1复制过来；\n[0038] 在节点3插入一条Table1的纪录，其Field11(值为3)和Field12(值为3)所关联的Table3和Table4的纪录(分别为ID3＝3和ID4＝3)在节点3上都已经存在，所以不需要复制。\n[0039] 我们可以看出，在事实表纪录插入后，维度表纪录可能在不同节点上产生重叠(Overlap)，而事实表纪录是不重叠的(Non-Overlap)。我们把某个纪录按照初始分区策略划分的节点称为该纪录的主节点(Primary Node)，而维度表纪录为保持局部完备性复制过去的节点称为该纪录的备份节点(Backup Node)。\n[0040] 上述方法，对于大量涉及到Join的查询操作，系统能够快速获取到外键关联的纪录，因为在同一节点已存储了这些关联的纪录，不需要每次都进行数据搬运，从而提高查询效率；\n[0041] 对于维度表的查询操作，先由前端服务器将查询请求发送到每个节点，每个节点获取本节点的纪录，然后返回给前端服务器进行汇总。由于维度表纪录可能在不同节点上产生重叠，所以前端服务器收到的维度表纪录可能会重复。解决这个问题的方法可以在前端服务器上过滤掉重复的纪录；也可以在单个节点上，对纪录区分主节点和备份节点，过滤掉备份节点的纪录；\n[0042] 在步骤205，数据的删除处理。删除事实表中的纪录，在事实表中的纪录被删除后，如果关联的维度表的纪录不再被其他事实表关联，则需要删除本节点上关联的维度表纪录(主节点的纪录不删除)；维度表中纪录的删除，只需要删除主节点上的纪录。因为删除维度表纪录之前，需要先删除事实表纪录，而在删除事实表纪录的时候，已经删除那个节点上维度表纪录；\n[0043] 在步骤206，数据的更新处理。事实表中纪录更新后，如果涉及到外键的更新，需要先删除旧的维度表纪录(主节点的纪录以及被其他事实表关联的纪录不删除)，再复制新的维度表纪录；维度表中纪录的更新，除了要更新主节点的纪录外，还需要更新备份节点的纪录。更新维度表纪录的一种实现方法是搜索所有节点的事实表，查看事实表中是否存在外键等于要更新的维度表纪录的主键，如果存在，则更新该节点上维度表的相关纪录。这种方式需要遍历所有节点的事实表，将消耗较长的时间；更新维度表纪录的一种优化的实现方法是针对每个维度表和每个节点，建立一个布隆过滤器(Bloom Filter)表，记录维度表纪录在节点上的分布情况，从而轻易找到保存某条指定纪录的节点。\n[0044] 布隆过滤器(Bloom Filter)是一种空间效率很高的随机数据结构，它利用位数组很简洁地表示一个集合，并能判断一个元素是否属于这个集合。BloomFilter的这种高效是有一定代价的：在判断一个元素是否属于某个集合时，有可能会把不属于这个集合的元素误认为属于这个集合(False Positive)。因此，Bloom Filter不适合那些“零错误”的应用场合。而在能容忍低错误率的应用场合下，Bloom Filter通过极少的错误换取了存储空间的极大节省。\n[0045] 下面我们具体来看Bloom Filter是如何用位数组表示集合的。图7为根据本发明的Bloom Filter位数组初始值示意图，如图7所示，初始状态时，BloomFilter是一个包含m位的位数组，每一位都置为0。\n[0046] 为了表达S＝{x1，x2，…，xn}这样一个n个元素的集合，Bloom Filter使用k个相互独立的哈希函数(Hash Function)，它们分别将集合中的每个元素映射到{1，…，m}的范围中。对任意一个元素x，第f个哈希函数映射的位置hf(x)就会被置为1(1≤f≤k)。\n注意，如果一个位置多次被置为1，那么只有第一次会起作用，后面几次将没有任何效果。图\n8为根据本发明的根据x的哈希函数值设置位数组示意图，如图8所示，在图8中，k＝3，且有两个哈希函数选中同一个位置(从左边数第七位)。\n[0047] 在判断y是否属于这个集合时，我们对y应用k次哈希函数，如果所有hf(y)的位置都是1(1≤f≤k)，那么我们就认为y是集合中的元素，否则就认为y不是集合中的元素。图9为根据本发明的判断y是否属于集合示意图，如图9所示，在图9中y1就不是集合中的元素，而y2要么属于这个集合，要么刚好是一个False Positive。\n[0048] 在计算机科学中，我们常常会碰到时间换空间或者空间换时间的情况，即为了达到某一个方面的最优而牺牲另一个方面。Bloom Filter在时间空间这两个因素之外又引入了另一个因素：错误率。在使用Bloom Filter判断一个元素是否属于某个集合时，会有一定的错误率。也就是说，有可能把不属于这个集合的元素误认为属于这个集合(False Positive)，但不会把属于这个集合的元素误认为不属于这个集合(False Negative)。在增加了错误率这个因素之后，BloomFilter通过允许少量的错误来节省大量的存储空间。\n[0049] 本发明中，将每张维度表在每个节点上的纪录分布情况记录在一个BloomFilter表中，维度表的主键(Primary Key)作为Bloom Filter表的查询关键字，Bloom Filter表数量＝(维度表数量×节点数量)。如果Bloom Filter发生错误(False Positive)，产生的后果是试图更新一个节点上维度表纪录，但是这个节点上却没有保存这条纪录。这种错误不会影响数据的正确性和一致性，它是可以被容忍的。而且只要哈希算法和位数组的长度选择得当，这种错误率将非常低。\n[0050] 这些Bloom Filter表可以存储在前端服务器上，作为一个全局数据集；也可以分布存储在每个节点上，各节点负责记录本节点上维度表纪录的分布情况。由于Bloom Filter表占用的空间很小，在实现中，可以预先载入内存，以提高查询速度。\n[0051] 本发明的数据分区方法可以应用于涉及到大量关联表Join的查询操作的分布式数据库系统，例如在商品数据管理中，用户往往需要根据商品种类进行分类，根据价格进行排序等。运用本发明，我们可以将商品种类和价格定义在事实表中，另外定义一些外键关联维度表，如卖家，生产厂商等。事实表纪录插入的时候，将关联的维度表纪录复制到同一节点。在进行种类/价格/卖家/生产厂商等关联表的连接查询(Join)的时候，前端服务器把查询发送给每个节点，每个节点就可以进行这种Join操作，不需要到其他节点搬运数据，大大提高查询效率。各节点把各自的处理结果返回给全局查询器做汇总就可以了。\n[0052] 而在销售数据管理中，我们可以将销售额、利润值等定义在事实表中，将客户、销售时间等定义为维度表，并以主外键关联事实表。事实表纪录插入的时候，将关联的维度表纪录复制到同一节点。在对某一客户的销售额进行统计的时候，由前端服务器将统计工作分发到各节点。每个节点依靠所保存的信息，可以轻易判断事实表销售纪录是否属于该客户，因为本节点上已经存在该客户信息，从而可以很轻松地完成本节点的统计工作，最后发送给前端服务器汇总。\n[0053] 本领域普通技术人员可以理解：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。