MatrixDB|MatrixDB 4.3 新特性（从“持续聚集”说起） MatrixDB4.3新特性：从“持续聚集

【MatrixDB|MatrixDB 4.3 新特性（从“持续聚集”说起）】随着时序数据库近几年越来越火， MatrixDB 作为一款备受业内关注的国产时序数据库也不停的更新迭代。4.3 版本在兼容性及性能上得到提升外，还新增在时序场景中能达到快速查询的 —— “持续聚集”。
1. 简介在时序场景中，聚集查询一般是基于较大量级的数据集合，对其进行归纳分组聚合运算，是一种相对耗时的查询类别，多用于分析场景。时序场景对聚集查询的需求也越来越多，同时对聚集查询的响应时间要求也越来越高。
因此，在 MatrixDB 4.3 版本中推出 “持续聚集”，一种能快速响应聚集查询的机制。
2. 持续聚集使用方法

创建数据表
基于数据表创建持续聚集视图
向数据表插入数据
查询持续聚集视图

#创建数据表 CREATE TABLE con_view_test_t1( c1 int, c2 int ) DISTRIBUTED BY(C1); #创建持续聚集视图 CREATE VIEW con_view1 WITH (CONTINUOUS) AS SELECT c1, COUNT(*), SUM(c2) FROM con_view_test_t1 GROUP BY c1; #向原表插入数据 INSERT INTO con_view_test_t1 SELECT 1, generate_series(1, 10); INSERT INTO con_view_test_t1 SELECT 2, generate_series(1, 100); INSERT INTO con_view_test_t1 SELECT 3, generate_series(1, 1000); #查询持续聚集视图 SELECT * FROM con_view1 ORDER BY c1; c1 | count |sum ----+-------+-------- 1 |10 |55 2 |100 |5050 3 |1000 | 500500 (3 rows)

从如上演示可以看到，持续聚集视图存储的是“创建聚集时聚合 SQL 语句聚集过的数据”，查询视图可以得到聚集后的结果，减少运算量。
3. 实现方法数据同步
普通视图只做查询重写，并不存储实际数据，而持续聚集所创建的视图相当于物化视图，是用于存储物理数据。所以，每次向原表插入新数据时，要同步到物化视图。

文章图片

数据同步在内存中进行，为了保证数据插入的延时不会受同步到物化视图过程的影响，在实现时额外增加了进程来异步处理。
数据通过共享内存同步到后台进程，后台进程并行完成数据写入，以此降低时延。

文章图片

存储引擎
持续聚集应用在聚集操作场景，通常都是按列分组后，做 SUM、COUNT、MAX、MIN 等聚集操作，数据同步到物化视图后，需要特殊的数据结构做优化处理，否则和从原表扫描数据做统计没有任何区别。
优化的本质是对已有的聚集结果做合并，减少数据集合数量；对增量数据做增量合并。要做合并，则需要数据有序存储。所以，持续聚集存储引擎核心技术可以归纳为：排序和归并。
为了存储的有序性，持续聚集在实现上使用了自研的存储引擎，和 Heap 类似，是将数据划分为 Block；不同的是，Block 内部的数据是有序存储的，Block 之间也通过链表构成了有序集合。

文章图片

基于如上存储，后台进程会在满足触发条件时，对排序后值相同的数据做归并，归并后存储数据量减少，查询性能提升。

文章图片

聚集视图中，数据的归并是在后台进行的，执行器在执行对聚集视图的查询时，并不仅仅是简单的扫描，还要做数据再聚集。再聚集数据量会随着归并逐渐减少。
聚集数据分布
MatrixDB 是分布式数据库，数据分散在 segment 上存储，持续聚集的数据同步与排序归并也是在 segment 上独立完成，不存在跨节点的互通，也就是说物化视图的数据分布与原数据表的数据分布相同。
在对视图进行查询的时候，每个 QE 完成聚集结果后，到 QD 节点再做二阶段聚集。