一、存储优化

GBase 8a MPP CLuster是一款基于列存储的关系数据库，与传统的行存数据库有所区别。并且在后续的完善过程中，GBase 8a MPP Cluster目前可支持两种存储方式：列存，行存列。今天主要介绍存储中为优化带来价值的一些特点。

1 列存

在列存储模式下，对于列的DML ( Data Manipulation Language, 数据操纵语言) 操作，仅仅是对列所对应的数据库页链（列）进行数据扫描，不会导致对全表的数据访问，可以有效降低DML操作的I/O操作。

1.1.优化特性：

  • 智能索引：列存数据库普遍采用了一种稀疏索引技术，我们通常称之为智能索引，这种索引的关键是将数据分块（页）创建索引（或者说是一种统计信息），可用于数据的粗粒度筛选和过滤，这种索引占用存储空间很小，维护费用很低，且维护工作全部是自动完成的，不需要任何人工的干预。
  • 压缩：列存数据库由于按列存储数据，同列数据的特征相似性及更有针对性的压缩算法使其通常具有比行存更高的压缩比，行存数据库通常只有2~3倍的压缩比，而列存数据库可以普遍达到5~10倍的压缩比（甚至在某些项目中可以达到20~40倍的压缩比）。
  • 延迟物化：列存数据库的执行计划中，无论过滤，投影，连接，聚合操作，列式数据库都不解压数据直到最后数据才还原原始数据值。这样做的好处是：降低CPU 消耗，降低内存消耗，降低网络传输消耗，降低最后储存的需求。

1.2.优化限制：

只对单列数据扫描有明显的性能优势，如果为select 多列或select * 模式，则会造成I/O性能低下，严重影响执行性能。

粗粒度索引只对DC的统计信息的查询性能比较明显。

2 行列混和存储（行存列）

由于GBase 8a MPP Cluster是列存储的架构，因此当列数较多，访问的数据记录又非常离散时，会造成大量的离散I/O，引起I/O性能及有效性低下，严重影响执行性能。

冗余行存储总体的实现逻辑为：将需要冗余的各列数据拼成行，以单独一列的形式存储，相当于在原始表上添加了一列，该列为VARCHAR类型，存储着对应的行数据。行存列的管理与普通列大体相同，但DC被划分为多个page，可以根据要访问的page进行加载，不需要读取整个DC。

行列混存功能，通过冗余行存储来有效提高I/O性能，可将典型SELECT * FROM场景的性能提升一个数量级。

2.1.优化特性：

  • 支持行存列压缩存储，减少冗余。
  • 行存列以更小粒度的Data Page读取数据，减少无效I/O，提升查询性能。
  • 使用gbase_hybrid_store配置参数控制是否使用行存数据，用于对比测试、排查错误等，该参数取值为：
    •0：不使用；
    •1：server自动判断是否使用；
    •2：强制使用，有则一定使用。

自动判断逻辑，如果满足以下条件则使用：
•字段被定义为行存列；
•RowsPerDC的值小于等于参数_gbase_hybrid_store_limit的定义值；RowsPerDC：就是当前查询所返回的记录数/命中的DC个数。

  • 存储冗余方式灵活，用户可自定义行存列中的字段，主要是通过select语句中投影列出现的频率来选择行存列应该包括哪些字段。

2.2.优化限制：

行存列数据暂时不用于scan、join、group等运算，目前仅能用于单表查询带order by的select（即物化）部分以及order by的相关列，如：

SELECT * FROM t [ WHERE … ] ORDER BY ...;

2.3.优化参数：

•查询时是否使用行存列参数：gbase_hybrid_store=0(不使用)/1(自动判断/2(强制使用)，该参数默认值为1。
•行存列存储时的页大小：gbase_hybrid_store_page_size=<1k –1G> ，默认值32K。
•返回结果中平均DC返回记录数的上限：_gbase_hybrid_store_limit=<1-65536>，默认值100。

2.4.其它特性及限制:

•支持建表时指定行存列；

•支持在已有表上新增行存列；

•支持删除行存列；

•支持一个表上建立多个行存列，但行存列不能重名；

•行存列的数据更新由系统自动维护，对用户透明。当用户执行INSERT、快速UPDATE、DELETE、LOAD等时，系统会自动更新冗余的数据；

•不支持修改行存列的定义，只能先手工删除再重建行存列；

•行存列的原始列定义不允许删除或修改数据属性（但允许更改列名称和列顺序）；

•原始列的数据不允许做批量update操作（整列替换模式）；

•同一grouped中所有列的总长度不允许超过32KB；

•行存列支持分区表，允许原始列上有索引。

3 Hash分布列的选择原则

  • 根据数据特点为大表关联和等值查询条件的应考虑建hash分布表，选择分布键时要结合数据特征，选择的原则如下： 
  • 数据均匀分布：尽量选择count(distinct)值大的列做Hash分布列，尽量使数据均匀分布；
  • 分布式多节点操作：优先考虑大表间的JOIN，尽量让大表JOIN条件的列为Hash分布列（相关子查询的相关JOIN也可以参考此原则），以使得大表间的JOIN可以直接分布式发布到每个节点执行；
  • 尽量选择使用频率高的grour by列：尽量让GROUP BY带有Hash分布列，让分组聚合一步完成； 
  • 多节点运行：选择某数据列随机性很大的字段，避免部分节点的热查询，导致执行性能不均衡；

二、Hash索引的充分利用

Hash Index 通常可以用来解决等值查询的定位效率，特别是对以单表精确查询为主的应用场景尤为适合，如电信业务中的并发话单查询等（特别是内存基本充足的场景）。

在使用上，GBase 8a MPP Cluster一定是首先进行智能索引过滤的，之后，如果发现查询条件中的等值查询条件列上建立了Hash Index，则使用Hash Index，否则进行全DC扫描。这一点，可以在Trace Log中观察到对有实时数据加载的场景，可以先建立无索引的临时表加载数据，再将临时表内数据插入到带索引的同结构目标表中或在临时表上创建索引。一次性处理索引建立，可较大幅度地降低索引带来的维护成本。

注意：

  • 索引是一种有损的优化手段，使用索引通常会带来维护的成本，会影响数据加载及DML操作的性能，实际使用时需根据具体需求而定；
  • 选择建立hash索引的列应尽量选择重复值较少的列，否则hash冲突严重，影响hash索引的性能；
  • 二进制类型的列不适合使用HASH索引。 

三、数据有序入库

1.有序数据入库的性能优势：

  • 提升智能索引对DC命中率 
  • 大幅度提升查询性能 

2.局部范围排序 

数据库使用中，定期的增量数据入库，在每次增量数据批量入库前先对批量数据做排序后入库，使数据库数据在局部范围内有序，提高读取速度 。

示例： 建立日表、月表，日表数据进月表前排序，当月结束时全月数据排序。

a)分析SQL找出表内主要查询过滤字段（1个字段）； 

b)将表内数据按照选出的过滤字段进行排序。

3.排序方式： 

  • 外部排序：使用排序工具（psort）对数据文件进行排序，排序后使用加载工具加载至表内；
  • 库内排序：创建临时表，将未排序的数据先存储进临时表，再通过insert into select * … order by XXX方式将临时表内数据排序后插入正式表。 

注意：外部排序后，加载入库时依然可能会造成数据顺序打乱，所以推荐使用库内排序。

对于排序方式适应场景 ：外部排序适合非实时加载的业务 、库内排序适合实时加载业务 。

 

以上就是今天的内容，感谢大家阅读！