openGemini 1.0版本，带来哪些新特性和性能提升？

3月30日，openGemini社区发布了v1.0.1版本，较v1.0.0版本，主要修复了一些异常场景下发现的问题，欢迎大家下载试用和反馈。

openGemini在v1.0版本中新增了多个关键特性，并在数据压缩算法、内存管理、查询引擎等方面做了大量优化工作，整体性能取得进一步提升。

由于对数据压缩算法进行了修改，v1.0版本与v0.2版本的数据存在不兼容

性能优化

内存优化

内存优化是性能优化中非常重要的一部分，在华为云内部业务的实际生产环境中测算，openGemini整体的内存占用较优化前减少了40%，关键优化项如下：

1. 优化乱序文件合并流程

   乱序文件合并不再将乱序文件全部加载到内存，改为流式合并方式，不同数据模型下，内存开销可减少20%-80%不等

2. 优化索引搜索流程

   一方面在查询场景中，设置时间线内存分配上限，避免因无节制对内存索取，对其他查询请求造成影响；另一方面在查询数据组装过程中，放弃内存拷贝，改为数据原地更新，相比优化前，单次查询可减少40%内存空间使用

3. 查询场景优化

   通常一个查询请求到来后，在openGemini内部会生成相关时间线的迭代器，时间线越多，一次性加载时间线元数据和迭代器占用的内存空间越大，采用延迟加载技术，根据需要加载指定时间线的元数据和迭代器，有效提升了内存的利用率，降低内存开销达80%以上

1. 简化DAG构建流程和编码
   在openGemini内部，查询请求被生成为一棵树形的查询计划，为了将查询计划中各个操作尽可能并发起来，以达到查询效率提升的目的，需再转换成表示分布式执行计划的DAG关系图，由ts-sql分发到不同的ts-store节点执行。通常一个简单查询的DAG关系图序列化之后大小为1-2KB，其序列化和网络传输开销却成为了简单查询的性能瓶颈。通过对DAG进行编码，有效降低了网络数据传输数据量，降低网络开销达95%
2. 时间范围查询优化
   针对时间范围的查询，进行了预裁剪，提升了时间跨度较大场景下的查询性能
3. 文件句柄优化
   随着系统长期的运行，数据文件越来越多，这对操作系统的文件句柄资源带来较大的消耗，优化采用按需打开的方式进行文件句柄管理，极大的节约了系统文件句柄资源
4. 进程启动RTO优化
   ts-store进程重启时，优化了immutable的open速度，支持WAL异步回放机制。优化后，500万时间线，存储共50.4亿条数据（Metrics），进程重启RTO为1.96s，提升400%
5. castor服务优化
   增加失败重试、连接池以提升可靠性；支持返回更详细的错误信息；castor算子支持GroupBy time和tags

数据压缩算法优化

openGemini采用列式数据存储，针对每一列数据，根据不同数据类型使用不同的数据压缩算法，从而实现较好的数据压缩效率。

Float类型数据在运维监控等场景下应用非常广泛，当前业界比较常用的是基于Facebook的Gorilla浮点数压缩算法，openGemini亦是如此。但实际分析来看Gorilla算法在部分数据模型下，压缩率并不理想，存在优化空间，因此在openGemini中采用了自适应的压缩处理方式，根据Float数据特征的不同，选择不同的压缩算法。优化后，openGemini采用了Snappy，Gorilla，RLE三种压缩算法的组合，相比于单独使用Gorilla，压缩率提升了60%，解压耗时减少38%

新增特性

支持多表full join

在某些场景下，为了更灵活地分析时序数据，我们需要使用full join操作。例如：

> SELECT * FROM mname: mtime                host region total val----                ---- ------ ----- ---1434055562000000000 1    east   2     31434055562000000000 1    west   2     11434055562000000000 2    east   2     41434055562000000000 2    west   2     2

用户可以编写以下查询语句来使用full join，并得到以下结果：

> SELECT m1.val, m2.val FROM (SELECT val FROM m WHERE host = '1') AS m1 FULL JOIN (SELECT val FROM m WHERE host = '2') AS m2 ON (m1.region = m2.region AND m1.total = m2.total) GROUP BY region, total name: m1,m2tags: region=east, total=2time                m1.val m2.val----                ------ ------1434055562000000000 3      4
name: m1,m2tags: region=west, total=2time                m1.val m2.val----                ------ ------1434055562000000000 1      2

全连接查询语句以关键字ON后的等效条件连接左右子查询表中的所有行，并可以使用Group BY分组

支持流式聚合计算

• 磁盘I/O消耗过大，影响其他业务

• 如果对同一张表做多种降采样，数据重复拉取

• I/O放大效应明显，对内存、磁盘以及网络带宽造成巨大压力

流式聚合计算，采用5级Pipeline，stream阶段负责任务管理，数据接入以及初步过滤。window阶段负责时间窗口过滤、计算、以及数据下盘。该方式具有高性能、网络开销小等优点，能有效降低数据降采样的资源消耗。

创建流式聚合语句示例如下：

CREATE STREAM cq_basic INTO average_passengers AS SELECT mean("passengers") FROM bus_data GROUP BY time(1h)," passengers" delay 20s

降采样（Downsampling）在此是指对时序数据进行降频，将原本较细粒度的数据降频后得到较粗粒度的数据。这样一来可以成倍减少历史数据规模，使得粗粒度的数据能够以更小的成本保存更长时间。

降采样后的数据点只保留原始数据的一些统计特征，openGemini支持五种统计特征：

• max：采样周期内样本值的最大值

• min：采样周期内样本值的最小值

• mean：采样周期内样本值的平均值

• sum：采样周期内样本值的和值

• count：采样周期内样本个数
  

可见降采样会造成原始数据失真，而不同场景对数据失真的容忍程度不同，在查询一年趋势的场景下，数据只需要大致的趋势正确即可。

与其他数据库中降采样功能不同的是，openGemini可同时自定义多个降采样时间范围和策略，例如将过去1年的数据按时间范围分为3部分：过去2-5个月采用全部5种统计方法，过去6-9个月的数据采用max、min统计方法。过去10-12月的数据采用count和mean方法，采样周期分别为15m，30m和1h。该功能可有效减少存储空间50%，节约计算资源90%

支持近似分位数查询

在时序数据分析的场景中，有时需要能够有效的理解数据分布（例如，P50，P90，P95），而无需对庞大的时间序列数据集执行昂贵的计算，则可以使用近似分位数查询。

较多数据库使用 TDigest 算法计算百分位数，例如InfluxDB、ClickHouse，ElasticSearch等，该算法在数据分布末端精度较高，计算速度快，内存开销小。但其缺点是数据非末端时精度可能会降低。openGemini设计的OGSketch近似统计算法，全范围的近似分位数查询能达到更高的精度，并同时考虑了数据增量更新问题，大幅提升每次算法构建与查询的效率，有效降低查询时延

时序预测是一类经典的问题，在学术界和工业界都有着广泛的研究和应用。例如根据过去一段时间的数据预测存储空间何时达到水位线，或者预测一个设备何时可能老化进入故障维修期等。

holtWinters函数可在指定的间隔内预测给定Field Key的n个预测值，但该方法适用于具有周期性规律的时序数据。

节点间RPC通信支持数据压缩

openGemini各个节点之间使用RPC通信，当频繁查询大量数据时，可通过配置项打开该功能，可有效减少数据传输带宽，提高数据传输效率

总结

本文主要介绍了openGemini v1.0新版本为用户提供的特性和性能优化，帮助大家更清楚了解新版本提供的能力，以及如何更好使用好这些能力。

欢迎大家试用和反馈，openGemini将一如既往提供更多更好用的功能，不断推动时序数据库的技术向前发展！

openGemini 共创新，赢未来！