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

kingbaseES企业级数据库中的两种垂直分区技术详解 概述 近些年来，随着应用数据的海量增加，应用中的IO瓶颈成为数据库应用中颇为头疼的问题，如何有效解决IO瓶颈成为数据库必须要解决的问题，由此衍生了分区技术，包括水平分区和垂直分区技术。分区技术通过对物理表进行分片操作，使得某些行或列存储更为集中，达到应用查询时通常仅需要访问个别分区，减少扫描表所需要的IO量的目的。垂直分区技术，则是通过将表中元组以列为单位进行划分，将表存储为行数相同，但每个表列数明显减少的多个子表的方式，使得应用查询的列位于个别分区时，能够仅访问相关的分区表，明显减少IO访问量。相比水平分区而言，垂直分区在带来优化的同时，也可能存在潜在的不利因素。例如，不同的分区方式可能导致查询需要访问多个分区，则引入的多个分区访问及连接将会带来更高的系统开销。因此，垂直分区的划分相对于水平分区而言而具挑战性。从Kingbase V6开始，金仓数据库就开始实现垂直分区技术，至今已经实现了两种垂直分区技术，各适用于不同的应用场景，也为用户提供了更多的垂直分区使用选择。想要更深入地了解KingbaseES的垂直分区技术，在自己的应用中有的放矢地加以应用，请仔细阅读这篇文章吧。 两种垂直分区 目前，KingbaseES实现了两种垂直分区——主码连接的垂直分区（VP1）和基于伪列的垂直分区（VP2），在本文中简称VP1型和VP2型。下面列出了其建表语句格式（其中VerticalPartitions子句为VP1型垂直分区，PseudoColumnBasedVerticalPartition子句为VP2型垂直分区）： CREATE TABLE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] [SchemaName.]TableName ( { ColumnName DataType [IDENTITY [(Seed, Increment)]] [ DEFAULT { NULL | USER | Expression } ] [ ColumnConstraint ] | [ TableConstraint ] } [, ...n ] ) [ VerticalPartitions | PseudoColumnBasedVerticalPartition ] [TABLESPACE TablespaceName] VerticalPartitions ::= PARTITION BY COLUMN ( [PartitionName] ({ ColumnName [, ...n ]) [TABLESPACE TablespaceName] ) [, ...n ] PseudoColumnBasedVerticalPartition ::= PARTITION FROM {{ColumnNo [TABLESPACE TablespaceName]} [, ...n ]} {CHAIN} 主码连接的垂直分区（VP1型） VP1型垂直分区即Kingbase V6中实现的垂直分区，即通过主码连接的垂直分区。它通过在建表的时候指定主键，并根据语句建立多个物理上独立的表（其中主键列重复存储）。其存储结构如下图所示： 垂直分区VP1型，分区方式：(id1, id2, id3), (id4, id5) 可以看出，该表的每个分区实际上是物理上独立的表，拥有普通表的所有特性（元组头、单独索引等）。当查询仅涉及单个分区时，查询只需要访问特定的分区，大大减少IO量。但当查询涉及到多个分区时，VP1型垂直分区需要根据主键列进行多表连接，然后进行查询。当数据量比较大时，多表连接的代价将成为很大的瓶颈。 基于伪列的垂直分区（VP2型） VP2型垂直分区是KingbaseES V7新开发的一种特性的垂直分区，即基于伪列的垂直分区。这种垂直分区通过伪列将主分区和每个子分区连接起来，访问分区时仅能通过伪列进行访问，而不能单独访问某个分区。其存储结构如下图所示： 垂直分区VP2型，分区方式：（id1, id2, id3), (id4, id5) 可以看出，VP2型垂直分区通过指向分区的伪列将各个分区相互关联。它仅从逻辑上将表划分为各个分区，物理上还是相互依赖的，即分区仅能从前面的表的伪列指针进行查询，而不是单独进行访问。由于它不是独立的表，因此也没有元组头等普通表的特性。如果该表上建立索引，索引只是指向主分区元组