CN102521282B - 基于行指针的数据库垂直分区存储方法 - Google Patents

基于行指针的数据库垂直分区存储方法 Download PDF

Info

Publication number
CN102521282B
CN102521282B CN201110382224.XA CN201110382224A CN102521282B CN 102521282 B CN102521282 B CN 102521282B CN 201110382224 A CN201110382224 A CN 201110382224A CN 102521282 B CN102521282 B CN 102521282B
Authority
CN
China
Prior art keywords
vertical partitioning
line pointer
tuple
database
subregion
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201110382224.XA
Other languages
English (en)
Other versions
CN102521282A (zh
Inventor
李茂增
王颖泽
杨尚
冯玉
李祥凯
冷建全
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Electronics Technology Group Jincang Beijing Technology Co ltd
Original Assignee
Beijing Kingbase Information Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Kingbase Information Technologies Co Ltd filed Critical Beijing Kingbase Information Technologies Co Ltd
Priority to CN201110382224.XA priority Critical patent/CN102521282B/zh
Publication of CN102521282A publication Critical patent/CN102521282A/zh
Application granted granted Critical
Publication of CN102521282B publication Critical patent/CN102521282B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种基于行指针的数据库垂直分区存储方法。在该方法中,将数据库中的数据表被分为若干个分区,其中最先访问的第一个分区为主分区,在主分区内记录有后面一个或多个分区的行指针。与现有技术相比较,本发明通过两种基于行指针的垂直分区表的存储方式,实现了在多数情况仅需访问主分区,部分情况下访问主分区就能够直接跳到其他分区的元组,仅需要访问特定的分区,而跳过其它的不必要分区的访问,有效提高了跨分区访问时的效率。

Description

基于行指针的数据库垂直分区存储方法
技术领域
本发明涉及一种数据库存储方法,尤其涉及一种基于行指针的数据库垂直分区存储方法,属于数据库存储技术领域。
背景技术
随着数据库应用规模的扩展,需要管理的数据规模也越来越大,普通的数据库查询优化机制在某些情况下已不能满足性能要求。利用数据库分区技术,可以有效减少数据吞吐(I/O)量,提升系统查询性能。
数据库分区是一种物理数据库设计技术,其主要目的是为了在特定的SQL操作中减少数据吞吐的总量以缩减响应时间。在数据库分区技术中,对于一个大的数据表,既可以选择进行水平分区,也可以选择进行垂直分区。其中,水平分区在主流的数据库产品中都得到了实现,垂直分区一般要靠数据库设计人员自行实现。
垂直分区通过对表的垂直划分来减少目标表的宽度,使某些特定的列被划分到特定的分区,每个分区都包含了其中的列所对应的行。使用垂直分区主要利用了数据库应用对数据表中字段访问的如下特性:
(1)字段访问频率的不均匀性:即某些字段访问特别频繁,其他字段则访问的较少。
(2)应用对字段访问的聚集性:即数据库应用中的查询倾向于一起访问某些字段,如a、b、c三列总是一起访问;d、e两列总是一起访问。
(3)字段访问顺序的依赖性:即数据库应用中的查询按照某个特定的顺序访问字段,例如访问d、e字段前总是先访问a、b、c字段。
在数据库应用对数据表的访问满足以上特性之一时,使用垂直分区可以使访问/修改这些列的查询不再需要访问/修改其他无关列,从而减少数据吞吐(I/O)量。
目前,主流的垂直分区技术均是基于行拆分的原则,即根据分区列将一行元组拆成多个独立的元组存储在不同的子表中。对于仅需要访问某个子表的查询,这种存储方式能够有效降低数据吞吐(I/O)量,但对于需要访问跨多个子表的列时,由于涉及到多个子表的连接,导致分区比较大时严重影响数据库的性能。
发明内容
本发明所要解决的技术问题在于提供一种基于行指针的数据库垂直分区存储方法。该存储方法可以实现提高数据表的命中率,提高数据库缓存的利用率,降低IO访问。
为实现上述的发明目的,本发明采用下述的技术方案:
一种基于行指针的数据库垂直分区存储方法,将数据库中的数据表被分为若干个分区,其中最先访问的第一个分区为主分区,其特征在于:所述主分区内记录有后面一个或多个分区的行指针。
较优地,所述主分区内记录有后面一个分区的行指针,且除最后一个分区之外,其他分区均记录有下一个分区的行指针。
较优地,所述主分区内记录有后面所有分区的行指针。
较优地,所述行指针指向所述分区中相应的分区元组。
较优地,所述主分区的每一个元组包含有下一个分区的与所述主分区的所述元组相对应的元组的行指针。
较优地,所述主分区的每一个元组包含有所有分区的与所述主分区的所述元组相对应的元组的行指针。
较优地,所述主分区包含频繁访问/更新的列,最后一个分区包含不频繁访问或通过索引即可访问的列。
较优地,最后一个分区包含不需要访问的索引列。
较优地,所述主分区包含频繁访问/更新的列,后面所有分区分别包含访问频度差异性不大的不同列。
与现有技术相比较,本发明中涉及的垂直分区技术更加灵活。通过两种基于行指针的垂直分区表的存储方式,实现了在多数情况仅需访问主分区,部分情况下访问主分区就能够直接跳到其他分区的元组,仅需要访问特定的分区,而跳过其它的不必要分区的访问,有效提高了跨分区访问时的效率。
附图说明
下面结合附图和具体实施方式对本发明作进一步的详细说明。
图1是链型元组存储结构的示意图;
图2是星型元组存储结构的示意图;
图3是链型垂直分区的存储结构示意图;
图4是星型垂直分区的存储结构示意图。
具体实施方式
在数据库技术中,将数据表中的行作为元组,列作为字段。一个数据表由行(元组)和列(字段)构成,组成一个二维关系表。若干个数据表、视图及相关的文件等组成一个统一的相关联的数据库系统。为了解决基于行拆分的垂直分区技术带来的跨表操作需要进行表连接的问题,本发明在子元组间通过指向存储磁盘存储位置的指针进行顺次连接或一对多连接等多种方式的连接,使得在访问数据表的不同列时,仅需要访问特定的分区,而跳过其它的不必要分区的访问,从而节省了数据吞吐(IO)量。在数据库应用中,根据该应用对数据表的数据访问特点,灵活地设计基于行指针的垂直分区表结构及各分区元组间的连接方式,从而提高数据库应用过程中对数据库缓存的利用率,达到降低IO访问的效果。
为此,本发明中使用了两种元组存储结构:一对一的链型(chain)元组存储结构和一对多的星型(star)元组存储结构。如图1所示,在一对一的链型元组存储结构中,垂直分区的元组通过行指针顺次连接在一起,访问后面的分区需要通过访问前面分区里存储的行指针进行。如图2所示,在一对多的星型元组存储结构中,垂直分区的首个元组存储所有其它子元组的行指针,访问后面的元组仅需要通过访问首个元组相应的行指针进行。
基于上述的两种元组存储结构,本发明可以实现两种垂直分区存储方式:链型垂直分区存储方式和星型垂直分区存储方式。这两种垂直分区存储方式均要求首先访问数据表的主分区,并且主分区内记录有后面一个(链型垂直分区存储方式)或多个(星型垂直分区存储方式)分区的行指针。在需要访问多个垂直分区时,根据垂直分区之间的索引关系,通过行指针直接定位到相应的分区元组。
如图3所示,链型垂直分区存储方式是将一个数据表分为若干个分区,其中第一个分区为主分区。除最后一个分区外的每个分区均需要记录下一个分区的行指针。主分区的每一个元组包含有下一个分区的与主分区的元组相对应的元组的行指针。在图3中,分区1(主分区)的第一元组(位于图3中分区1中的上方的元组)中包含有,与分区2中第一元组相对应的行指针。类似的,分区1中的第二元组(位于图3中分区1中的中部的元组)中包含有与分区2中第二元组相对应的行指针。分区1中的第三元组(位于图3中分区1中的下方的元组)中包含有与分区2中第三元组相对应的行指针。同样,分区2的第一元组中包含有与分区3中第一元组相对应的行指针;第二元组中包含有与分区3中第二元组相对应的行指针;第三元组中包含有与分区3中第三元组相对应的行指针。
在这种存储方式下,当访问主分区的列时,同拆分列的垂直分区相同,因此仅需要访问主分区即可。当访问分区的列时,需要首先访问主分区,然后根据行指针依次往后找到所需的分区元组。当分区比较靠后(第三个分区或第三个分区之后)时,这种存储方式需要多次访问前面分区的访问接口,有些得不偿失。因此,这种存储方式适用于数据库应用的列访问阶段性差异比较大的情况,这时可以将频繁访问的列放到第一个分区(即主分区),将次频繁访问的列放到第二个分区,将不频繁访问、根本不会访问或通过索引即可访问(需要确保应用使用索引扫描)的列,即访问频度差异性不大的多个列,放到后面的分区中。
如图4所示,星型垂直分区存储方式是将一个数据表分为若干个分区,其中第一个分区为主分区,需要记录后面所有分区的行指针,其它分区则不需要记录行指针的信息。主分区的每一个元组包含有,所有分区的与主分区的元组相对应的元组的行指针。具体而言,在图4中分区1(主分区)中第一元组(位于图4的分区1中的上方的元组),依次包含有后面所有分区,分区2、分区3直到分区n的第一元组的行指针。分区1中第二元组依次包含有后面所有分区的第二元组的行指针。分区1中的第n元组依次包含有后面所有分区的第n元组的行指针。
在这种存储方式下,主分区存储的内容相比链型垂直分区存储方式有所增多,需要存储多个行指针的信息。但与链型垂直分区存储方式相比,星型垂直分区存储方式对于后面分区的访问,仅仅需要多一次主分区访问的数据读写过程。因此,这种存储方式适用于某些列访问较频繁,其余列访问相对较少,但列访问模式又比较分散的情况,例如有时访问这几列、有时访问那几列的情况。换言之,主分区包含频繁访问/更新的列,后面所有分区分别包含访问频度差异性不大的不同列。
这两种垂直分区存储方式各自有其优缺点。例如对于链型垂直分区存储方式而言,当访问后面的分区时,需要首先访问前面的分区,这样对于后面分区的访问可能造成多次数据读写过程。对于星型垂直分区存储方式而言,访问非主分区都需要发生一次访问主分区的额外数据读写过程,但对于仅访问主分区的列的情况,则不会引起访问分区的数据读写过程。同时,星型垂直分区存储方式不需要为每个垂直分区子表均建立索引,仅需要对垂直分区的主分区表建立索引即可。特别地,索引列可以存放在后面的分区中,以减少主分区元组的大小。索引列的值可以直接通过索引元组字段获得,而不需要访问索引列所在内存堆(heap)的分区。
链型垂直分区存储方式和星型垂直分区存储方式可以在同一个数据库系统中并存。用户可以根据链型垂直分区和星型垂直分区中数据表的不同存储方式,结合数据库应用中对数据表的列的访问特点,决定每个数据表在数据库中的最优存储方式,从而达到数据库检索时能够节省数据吞吐(IO)量,同时避免表连接操作的效果。
下面,以TPCC(基准测试)应用中的c_customer表为例,具体阐述本发明的实施步骤及其效果:
1.首先,判断c_customer表是否需要进行垂直分区,以及进行垂直分区所采用的具体存储方式。经过研究,确认该表应该进行垂直分区,具体理由如下:
(1)c_customer表中的一个元组平均占543个字节,c_data列即占404个字节,且访问频率很小。
(2)c_customer表的列数很多,但访问上比较有聚集性。
(3)c_customer表的访问具有一定的规律性,列之间访问频率差异很大,少数列的访问频率达到80%以上
2.选择进行垂直分区所采用的具体存储方式
由于少数列访问频率达到80%,故把这些列放到主分区后,要求主分区元组应该尽量小。同时列访问聚集性较高,但无法明确分成若干类,不适合星型垂直分区存储方式,应该使用链型垂直分区存储方式。
3.进行具体分区的划分
参照分区原则,可以确定如下的分区划分方法:
(1)c_data由于比较大,且访问频率小,比较独立,最好单独分一个分区,且放到最后一个分区。
(2)对于访问频率达到80%的列c_delivery_cnt和c_balance,可以都放到第一个分区,同时列c_last,c_id访问频率较高,也可以放到第一个分区。
(3)其余各列相对访问比较集中,但有一些列的访问模式比较散(即不固定地被多个查询访问),可以统一放到第二个分区。
(4)由于索引的存在,c_w_id和c_d_id这两个索引列从来不会被从内存堆(heap)上访问到,且所占空间较小,可与c_data一同放到最后一个分区。
依照上面的分区划分方法进行c_customer表的划分后,可以计算出第一个分区的元组长度为40字节,第二个分区的元组长度为128个字节,第三个分区的元组长度为408个字节。
在数据库应用中,选定查询计划后会首先扫描获得c_customer表的主分区元组。对于大多数查询来说,通过该主分区元组即可获得需要操作的列,不需要访问后面的分区。对于部分查询来说,需要读取第二个分区的元组进行操作。对于极少数的查询,才需要访问到c_data字段,需要读取第三个分区。
在针对c_customer表的实际测试中,通过iostat磁盘工具观察到每秒读扇区数从50000降到了35000,每秒写扇区数从15000降到了10000左右。观察命中率时,发现c_customer三个分区的命中率分别是0.94、0.73、0.76,两个索引的命中率分别是0.99,0.97,这说明所使用的链型垂直分区存储方式解决了原先c_customer表命中率过低的问题。
在使用本发明所提供的数据库垂直分区存储方法后,多个垂直分区子表对用户来说是透明的。用户使用顺序扫描或索引扫描得到的均是主分区的元组,然后,根据查询需要访问的列来决定是否需要继续扫描哪些元组。对于链型垂直分区存储方式而言,访问第n个分区的元组需要访问所有前面n-1个分区的元组,通过每个分区的行指针找到后面分区的元组,依此类推。对于星型垂直分区存储方式而言,访问第n个分区的元组仅需要通过主分区中存储该分区元组的行指针即可直接定位。相应地,更新列的过程如果仅涉及个别几个分区,也只需要在这几个分区上进行更新即可。
上述的技术解决方案提供了在数据库应用中节省IO操作、提高效率的一种有效途径。用户还可以依据上面提到的数据库垂直分区存储方法,根据数据库应用的具体要求来判定是否定义类似垂直分区的数据表来提升性能。具体来说,使用基于行指针的数据库垂直分区需要满足以下条件:
1.数据表的列比较多,或个别字段的长度比较大,如果集中存储会造成访问比较随机;
2.数据库应用对数据表的访问模式基本确定,即可以根据数据表的访问的统计信息确定数据表中每个字段的访问模式及频率;
3.根据对数据表的访问模式,可以推测出数据表的列的访问存在比较大的差异性。
在进行基于行指针的数据库垂直分区划分时需要遵循以下原则:
1.查询/更新语句访问的频度较高的列应该尽可能放在前面的分区中;
2.对于列访问频度差异非常大的数据库应用,应优先考虑链型垂直分区存储方式;对于列访问频度差异不大、但不同查询访问不同列的数据库应用,应优先考虑星型垂直分区存储方式;
3.对于同一查询中涉及的列,尽量集中存储在同一个分区中;
4.对于更新的列,应尽量存储在同一个分区中,且尽量靠前;
5.如果数据库应用中使用索引扫描,则不需要从内存堆(heap)中访问索引列。对于不需要访问的索引列,则可以放到最后一个分区。
6.划分过程中应尽量避免划分过小的数据表,因为划分一个数据表需要多出存储行指针的空间。如果划分的数据表中元组不超过行指针大小或基本持平,则无分区的必要。
以上对本发明所提供的基于行指针的数据库垂直分区存储方法进行了详细的说明。对本领域的技术人员而言,在不背离本发明实质精神的前提下对它所做的任何显而易见的改动,都将构成对本发明专利权的侵犯,将承担相应的法律责任。

Claims (7)

1.一种基于行指针的数据库垂直分区存储方法,用在链型垂直分区存储方式和星型垂直分区存储方式并存的数据库中,其特征在于:
将数据库中的数据表分为若干垂直分区,其中最先访问的第一个垂直分区为主分区,所述主分区内记录有后面一个或多个垂直分区的行指针;
对于列访问频度差异大的数据库应用采用链型垂直分区存储方式,其中所述主分区记录后面一个垂直分区的行指针,且除最后一个垂直分区之外,其他所述垂直分区均记录有下一个垂直分区的行指针;
对于列访问频度差异不大、但不同查询访问不同列的数据库应用采用星型垂直分区存储方式,其中所述主分区记录后面多个垂直分区的行指针;
在需要访问多个垂直分区时,根据垂直分区之间的索引关系,通过行指针直接定位到相应的分区元组。
2.如权利要求1所述的基于行指针的数据库垂直分区存储方法,其特征在于:
所述行指针指向所述垂直分区中相应的分区元组。
3.如权利要求1所述的基于行指针的数据库垂直分区存储方法,其特征在于:
当采用链型垂直分区存储方式时,所述主分区的每一个元组包含有下一个垂直分区的与所述主分区的所述元组相对应的元组的行指针。
4.如权利要求1所述的基于行指针的数据库垂直分区存储方法,其特征在于:
当采用星型垂直分区存储方式时,所述主分区的每一个元组包含有所有垂直分区的与所述主分区的所述元组相对应的元组的行指针。
5.如权利要求1所述的基于行指针的数据库垂直分区存储方法,其特征在于:
当采用链型垂直分区存储方式时,所述主分区包含频繁访问/更新的列,最后一个垂直分区包含不频繁访问或通过索引即可访问的列。
6.如权利要求1所述的基于行指针的数据库垂直分区存储方法,其特征在于:
索引列的值直接通过索引元组字段获得,不需要访问索引列所在内存堆的垂直分区。
7.如权利要求1所述的基于行指针的数据库垂直分区存储方法,其特征在于:
当采用星型垂直分区存储方式时,所述主分区包含频繁访问/更新的列,后面所有垂直分区分别包含访问频度差异性不大的不同列。
CN201110382224.XA 2011-11-25 2011-11-25 基于行指针的数据库垂直分区存储方法 Active CN102521282B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201110382224.XA CN102521282B (zh) 2011-11-25 2011-11-25 基于行指针的数据库垂直分区存储方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201110382224.XA CN102521282B (zh) 2011-11-25 2011-11-25 基于行指针的数据库垂直分区存储方法

Publications (2)

Publication Number Publication Date
CN102521282A CN102521282A (zh) 2012-06-27
CN102521282B true CN102521282B (zh) 2016-01-20

Family

ID=46292203

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201110382224.XA Active CN102521282B (zh) 2011-11-25 2011-11-25 基于行指针的数据库垂直分区存储方法

Country Status (1)

Country Link
CN (1) CN102521282B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105630803B (zh) * 2014-10-30 2019-07-05 国际商业机器公司 文档型数据库建立索引的方法和装置
CN110019342B (zh) * 2017-12-13 2023-03-28 金篆信科有限责任公司 分区表访问方法、装置及设备、计算机可读存储介质
CN112948864B (zh) * 2021-03-19 2022-12-06 西安电子科技大学 基于垂直分区数据库的可验证ppfim方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5933820A (en) * 1996-05-20 1999-08-03 International Business Machines Corporation System, method, and program for using direct and indirect pointers to logically related data and targets of indexes
CN101676899A (zh) * 2008-09-18 2010-03-24 上海宝信软件股份有限公司 海量数据库记录的归档和查询方法
CN101630322B (zh) * 2009-08-26 2011-04-13 中国人民解放军信息工程大学 树形目录结构下的文件集在数据库中的存储和访问方法

Also Published As

Publication number Publication date
CN102521282A (zh) 2012-06-27

Similar Documents

Publication Publication Date Title
CN106708427B (zh) 一种适用于键值对数据的存储方法
US8782324B1 (en) Techniques for managing placement of extents based on a history of active extents
CN102200892B (zh) 一种基于动态raid系统的扩容方法
CN103942289B (zh) 一种Hadoop上面向范围查询的内存缓存方法
CN102364474B (zh) 用于机群文件系统的元数据存储系统和管理方法
CN104850358B (zh) 一种磁光电混合存储系统及其数据获取和存储方法
EP2454691A2 (en) Database storage architecture
CN102262512A (zh) 一种实现磁盘阵列缓存分区管理的系统、装置及方法
US8005836B2 (en) Method and system for performing logical partial declustering
CN102663116A (zh) 面向列存储数据仓库的多维olap查询处理方法
CN103440245A (zh) 数据库系统的行列混合存储方法
CN102682108B (zh) 一种行列混合的数据库存储方法
US20130254240A1 (en) Method of processing database, database processing apparatus, computer program product
CN102521406A (zh) 海量结构化数据复杂查询任务的分布式查询方法和系统
US8108400B2 (en) Database segment searching
CN104112008A (zh) 一种多表数据关联查询优化方法和装置
CN104361113A (zh) 一种内存-闪存混合存储模式下的olap查询优化方法
US20160246785A1 (en) Hybrid data distribution in a massively parallel processing architecture
CN106095342A (zh) 一种动态可变长条带的瓦记录磁盘阵列构建方法及系统
CN104111898A (zh) 基于多维数据相似性的混合存储系统及数据管理方法
CN102999428A (zh) 一种瓦记录磁盘的四级编址方法
CN102298633A (zh) 一种分布式海量数据排重方法及系统
CN106031827A (zh) 基于redis的游戏服务器数据存储、读取方法及系统
CN106909323B (zh) 适用于dram/pram混合主存架构的页缓存方法及混合主存架构系统
CN102521282B (zh) 基于行指针的数据库垂直分区存储方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CP03 Change of name, title or address

Address after: 100102 201, 2 / F, 101, No. 5 building, No. 7 Rongda Road, Chaoyang District, Beijing

Patentee after: China Electronics Technology Group Jincang (Beijing) Technology Co.,Ltd.

Country or region after: China

Address before: Room 601, Building 4, No. 8 Shangdi West Road, Haidian District, Beijing

Patentee before: BEIJING KINGBASE INFORMATION TECHNOLOGIES Inc.

Country or region before: China