人大金仓KingbaseES企业级数据库中的两种垂直分区技术详解.doc

kingbaseES企业级数据库中的两种垂直分区技术详解

1 概述
近些年来，随着应用数据的海量增加，应用中的IO瓶颈成为数据库应用中颇为头疼的问题，如何有效解决IO瓶颈成为数据库必须要解决的问题，由此衍生了分区技术，包括水平分区和垂直分区技术。分区技术通过对物理表进行分片操作，使得某些行或列存储更为集中，达到应用查询时通常仅需要访问个别分区，减少扫描表所需要的IO量的目的。垂直分区技术，则是通过将表中元组以列为单位进行划分，将表存储为行数相同，但每个表列数明显减少的多个子表的方式，使得应用查询的列位于个别分区时，能够仅访问相关的分区表，明显减少IO访问量。相比水平分区而言，垂直分区在带来优化的同时，也可能存在潜在的不利因素。例如，不同的分区方式可能导致查询需要访问多个分区，则引入的多个分区访问及连接将会带来更高的系统开销。因此，垂直分区的划分相对于水平分区而言而具挑战性。从Kingbase V6开始，金仓数据库就开始实现垂直分区技术，至今已经实现了两种垂直分区技术，各适用于不同的应用场景，也为用户提供了更多的垂直分区使用选择。想要更深入地了解KingbaseES的垂直分区技术，在自己的应用中有的放矢地加以应用，请仔细阅读这篇文章吧。
2 两种垂直分区
目前，KingbaseES实现了两种垂直分区——主码连接的垂直分区（VP1）和基于伪列的垂直分区（VP2），在本文中简称VP1型和VP2型。下面列出了其建表语句格式（其中子句为VP1型垂直分区，子句为VP2型垂直分区）：
CREATE TABLE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] [SchemaName.]TableName
(
{ ColumnName [IDENTITY [(Seed, Increment)]]
[ DEFAULT { NULL | USER } ] [ ]
| [ ]
} [, ...n ]
) [ | ]
[TABLESPACE TablespaceName]

::= PARTITION BY COLUMN
( [PartitionName]
({ ColumnName [, ...n ])
[TABLESPACE TablespaceName] ) [, ...n ]

::=
PARTITION FROM
{{ColumnNo [TABLESPACE TablespaceName]} [, ...n ]}
{CHAIN}
1. 主码连接的垂直分区（VP1型）
VP1型垂直分区即Kingbase V6中实现的垂直分区，即通过主码连接的垂直分区。它通过在建表的时候指定主键，并根据语句建立多个物理上独立的表（其中主键列重复存储）。其存储结构如下图所示：
垂直分区VP1型，分区方式：(id1, id2, id3), (id4, id5)

可以看出，该表的每个分区实际上是物理上独立的表，拥有普通表的所有特性（元组头、单独索引等）。当查询仅涉及单个分区时，查询只需要访问特定的分区，大大减少IO量。但当查询涉及到多个分区时，VP1型垂直分区需要根据主键列进行多表连接，然后进行查询。当数据量比较大时，多表连接的代价将成为很大的瓶颈。
2. 基于伪列的垂直分区（VP2型）
VP2型垂直分区是KingbaseES V7新开发的一种特性的垂直分区，即基于伪列的垂直分区。这种垂直分区通过伪列将主分区和每个子分区连接起来，访问分区时仅能通过伪列进行访问，而不能单独访问某个分区。其存储结构如下图所示：
垂直分区VP2型，分区方式：（id1, id2, id3), (id4, id5)

可以看出，VP2型垂直分区通过指向分区的伪列将各个分区相互关联。它仅从逻辑上将表划分为各个分区，物理上还是相互依赖的，即分区仅能从前面的表的伪列指针进行查询，而不是单独进行访问。由于它不是独立的表，因此也没有元组头等普通表的特性。如果该表上建立索引，索引只是指向主分区元组。
3. 两种垂直分区的比较
VP1型垂直分区和VP2型垂直分区由于实现上的不同，存在较大差异。其中VP1型垂直分区仅从语义角度进行了修改，而VP2型垂直分区在低层针对垂直分区做了较多的修改。下表从各个方面，对两种垂直分区进行了比较。

VP1型
VP2型
分区相关性
相关性低，各分区可以看作独立的表
相关性高，子分区不独立，必须通过伪列访问
存储结构
1. 主键列需要重复存储
2. 每个分区上均需要元组头信息
3. 索引需要在列涉及的表上建立多份（比如主键索引需要在每个分区上建立）
总结：需要额外存储很多信息
1. 不需要有列重复存储
2. 仅主分区需要元组头信息
3. 索引仅需要建立一份，指向主分区元组
4. 非最后一个分区都需要存储伪列指向下一分区
总结：总体来说节省存储空间
建表限制
有很多限制，比如必须要有主键，约束、触发器不能跨表存在等等
无限制
性能
如果仅需访问某个分区，性能达到最优；当需要跨分区访问，则需要多表连接操作，性能急剧下降
对于仅访问主分区时，性能最佳，访问子分区和多个分区时均需要从主分区开始访问，可能涉及多次IO
灵活性
可以通过重复存储列的方式避免多表连接，但增加了额外存储消耗，相对不灵活
可以调节列在分区上的分布，使得尽可能多时仅访问主分区，达到最优
适用性
仅适用于应用中语句均可单表查询的情况，相对差一些。但对于可用情况，分区划分较容易实现
可以适用于各种情况，好的分区方式可以显著提高系统性能，但是划分起来比较困难
易维护性
每个分区作为单独表处理，易于维护
子分区没有元组头信息，分区元组的回收也需要通过伪列查找，性能较差
3 垂直分区的划分方法
通过上面的对比，可以看出VP2型垂直分区在多个方面明显优于VP1型垂直分区。但是，VP1型作为最先开发的垂直分区，也具有其优势，比如特定场景下的优势及易于使用、维护等。VP2型则使用时专业性较强，好的分区划分必须完全根据应用和数据库的特点来进行划分，当然良好的划分方法也将带来显著的性能收益。下面针对两个垂直分区分别进行叙述。
1. VP1型垂直分区
该垂直分区划分比较简单，要求应用中的语句在执行时必须进行单表查询（此为V1垂直分区的优势），或多表连接时，每表进行连接的条数很少的情况下（不具备优势）。因此，划分时可以采取列重复存储的方式来保证此原则。另外需要考虑应用中的表是否满足VP1型垂直分区的硬性限制。
2. VP2型垂直分区
该垂直分区涉及数据库的内部实现，相对复杂一些，但是对于不同的应用而言更加通用，仅需要满足以下条件即可使用：
l 表的列比较多，或个别字段的长度比较大，如果集中存储会造成访问比较随机。
l 应用对表的访问模式基本确定，即可以根据表的访问的统计信息确定表中每个字段的访问模式及频率。
l 应用对表的不同列的访问频率差异较大。
进行VP2型垂直分区划分时需要遵循以下原则：
l 查询/更新语句访问的频度较高的列应尽可能放在前面的分区中。由于Kingbase使用的是异地更新，故对于较大的表进行频繁更新操作也可以考虑使用垂直分区将更新列作为单独表存储在第一个分区中。
l 如果应用中使用indexscan，则不需要从heap中访问索引列，对于不需要访问的索引列，则可以放到最后一个分区。
l 划分过程中应尽量避免划分过小的表，因为划分一个表则需要多出6个字节的存储伪列的空间。如果划分的表元组不超过6或基本持平，则无分区必要。
4 总结
本文介绍了KingbaseES的垂直分区技术，详细说明了两种垂直分区实现、特点、适用场景上的异同。用户需要根据实际应用的特点来有针对地使用不同的垂直分区划分方式，以达到提高系统性能，节省IO的目的。