人大金仓KingbaseES列式数据库技术概述.doc

金仓列式数据库技术概述 一、概述 列式数据库是基于列存储的、主要面向OLAP型应用的关系型数据库。列数据库的特点是可以更好的应对海量关系数据中列的查询，占用更少的存储空间和更少的I/O，这些特点使其成为构建数据仓库的理想架构。 KingbaseES也选择了这种适合数据仓库应用的技术，用于海量数据的分析。KingbaseES实现了列存储引擎和列执行引擎，和现有的行存储引擎和行执行引擎组成双执行引擎、双存储引擎。 执行引擎接收优化器生成的执行计划，按照计划通过存取接口操作数据、进行计算并返回结果。 存储引擎提供可靠、可扩展的存储功能，定义了数据在内存和磁盘上的组织方式；同时为执行引擎提供高效的存取接口来操作数据。 在KingbaseES中： 列执行引擎可以使用列存储引擎； 行执行引擎可以使用行存储引擎、列存储引擎或两种存储引擎混合使用。 多引擎方式带来如下好处： 为优化器提供了更灵活的选择方式，可以在更多场景下给出更优的选择。例如当在列存储表上做结果集很大并包含大多数列的连接时，列执行引擎就没有优势，而且会额外存储中间结果的位置信息。这时使用行执行引擎就更合适； 针对特定的业务需求，可以处理OLAP、OLTP的混合场景。 二、技术特点 下面介绍一下KingbaseES的列存储、执行引擎使用到的技术。 列式存储 如图中的Customer表，行存储数据库中将数据按行存储在磁盘上： 列式存储则将同一列的数据存储在一起： 在磁盘上的组织方式如上图，可以看出，这种按列组织的存储方式可以带来最显著的好处，就是当操作只涉及较少列时相比行存储需要更少的I/O，例如： 对少量列的查询、聚集操作，这些操作是OLAP应用中的常见操作； 在少量列上的更新操作。 KingbaseES实现了列式存储，并将每一列分成若干段分别存储，这种分段式的存储方式是为了达到如下效果： 数据压缩后如果查询只涉及一部分数据或是有数据的修改，可以不用解压整个列数据； 便于建立稀疏索引，更好地过滤查询中不涉及的数据。 数据压缩 数据压缩并不是列式数据库的专项技术，行存储数据也可以使用数据压缩来减少数据量。但是列存储的数据同一列的数据存储在一起，数据间的相似度更高，具有的熵值更小。按照数据压缩理论，无损编码的效果在熵值小的数据上效果更好。 KingbaseES提供自动的用户透明的多种压缩算法，可以根据数据的特点自动选择一种或多种压缩算法来压缩数据，压缩比可以达到10:1～40:1。 数据压缩可以带来更少的存储空间占用，对于海量数据存储来说很重要。更重要的是，压缩可以降低I/O的开销，虽然压缩/解压缩会带来CPU的开销，但是在目前的CPU和存储设备发展来看，使用CPU开销换取I/O开销在很多情况下是值得的。 稀疏索引 在海量数据中，使用传统行存储使用的稠密索引会带来问题：为了适应各种即席查询，管理员需要在很多列或列的组合上建立索引，而索引本身占用的空间巨大，管理复杂。 KingbaseES将列存储数据分段存储，每65536个列数据存储在一个数据段中，每个数据段对应一个索引项。 索引中的信息包括（以数值型数据为例）： 该数据段中的数据最小值、最大值； 从最小值到最大值划分成若干范围，用位图标记是否有数据在这个范围 中； 该数据段中数据的统计信息，如数据的和。 这样索引所占的空间就会很少。如下图，TPC-H@SF=10场景下part表原始数据、压缩后的数据和在全部列上使用稀疏索引占用的空间比例如下图所示： 可以看出，稀疏索引的存储空间占用是非常少的，所以可以在全部的数据上建立稀疏索引，也减少了索引的管理的复杂性。 稀疏索引的效率同样很高，对于范围查询，可以根据索引中的最小值、最大值和位图来判断数据段中是否包含满足查询条件的值。索引中的统计信息可以用于聚集函数的计算。 举例如下： 关系part(p_partkey int, p_size int)，包含三个数据段，每个数据段的索引内容如下： 查询SELECT avg(p_size) FROM part WHERE p_partkey 65536; 通过索引将过滤掉数据段1，并且判断数据段2和数据段3都满足过滤条件，随后的avg运算可以直接使用索引中的统计信息（600000+800000）/（65536×2）完成。 延时物化 这里的物化是指将列数据从磁盘读入内存组成一条元组。物化的策略大致有两种，提前物化和延时物化。提前物化是指尽早组成逻辑元组，例如在执行计划的扫描阶段就将查询中使用的全部列值取出组成元组，后续的执行将和行存储执行过程相同,这种方式更适合于传统行存储类型的数据库。而延时物化是在计算的中间结果中保存值的位置信息，每个执行节点根据位置信息只获取当前节点计算所需要的列值。这种技术在OLAP场景中多表连接、分组聚集操作多、结果集逐渐