共计 5252 个字符，预计需要花费 14 分钟才能阅读完成。
3 月 30 日，openGemini 社区公布了 v1.0.1 版本，较 v1.0.0 版本，次要修复了一些异样场景下的发现的问题，欢送大家下载试用和反馈。
v1.0 版本新增了多个要害个性，并在数据压缩算法、内存治理、查问引擎等方面做了大量优化工作，整体性能获得进一步晋升
因为对数据压缩算法进行了批改，v1.0 版本与 v0.2 版本的数据存在不兼容
社区地址：https://github.com/openGemini
社区联系方式：http://opengemini.org/contact-us
性能优化
内存优化
内存优化是性能优化中十分重要的一部分，openGemini 的要害优化项如下：
- 优化乱序文件合并流程 乱序文件合并不再将乱序文件全副加载到内存，改为流式合并形式，不同数据模型下，内存开销可缩小 20%-80% 不等。
- 优化索引搜寻流程 一方面在查问场景中，设置工夫线内存调配下限，防止因无节制对内存索取，对其余查问申请造成影响；另一方面在查问数据组装过程中，放弃内存拷贝，改为数据原地更新，相比优化前，单次查问可缩小 40% 内存空间应用。
- 查问场景优化
通常一个查问申请到来后，在 openGemini 外部会生成相干工夫线的迭代器，工夫线越多，一次性加载工夫线元数据和迭代器占用的内存空间越大，采纳提早加载技术，依据须要加载指定工夫线的元数据和迭代器，无效晋升了内存的利用率，升高内存开销达 80% 以上。
查问优化
查问优化是性能优化中最为间接的优化源头，但查问优化是一个简单的工程，须要多方面的数据库领域专家常识和教训，它应用了十分多的优化策略来生成一个最优的查问打算。通过性能测试，openGemini 整体的性能较优化前再次晋升了 30%-80%，次要优化项如下：
- 简化 DAG 构建流程和编码 在 openGemini 外部，查问申请被生成为一棵树形的查问打算，为了将查问打算中各个操作尽可能并发起来，以达到查问效率晋升的目标，需再转换成示意分布式执行打算的 DAG 关系图，由 ts-sql 散发到不同的 ts-store 节点执行。通常一个简略查问的 DAG 关系图序列化之后大小为 1 -2KB，其序列化和网络传输开销却成为了简略查问的性能瓶颈。通过对 DAG 进行编码，无效升高了网络数据传输数据量，升高网络开销达 95%
- 工夫范畴查问优化 针对工夫范畴的查问，进行了预裁剪，晋升了时间跨度较大场景下的查问性能
- 文件句柄优化 随着零碎长期的运行，数据文件越来越多，这对操作系统的文件句柄资源带来较大的耗费，优化采纳按需关上的形式进行文件句柄治理，极大的节约了系统文件句柄资源。
- 过程启动 RTO 优化 ts-store 过程重启时，优化了 immutable 的 open 速度，反对 WAL 异步回放机制。优化后，500 万工夫线，存储共 50.4 亿条数据（Metrics），过程重启 RTO 为 1.96s，晋升 400%
- castor 服务优化
减少失败重试、连接池以晋升可靠性；反对返回更具体的错误信息；castor 算子反对 Group By time 和 tags
数据压缩算法优化
openGemini 采纳列式数据存储，针对每一列数据，依据不同数据类型应用不同的数据压缩算法，从而实现较好的数据压缩效率。Float 类型数据在运维监控等场景下利用十分宽泛，以后业界比拟罕用的是基于 Facebook 的 Gorilla 浮点数压缩算法，openGemini 亦是如此。
但理论剖析来看 Gorilla 算法在局部数据模型下，压缩率并不现实，存在优化空间，因而在 openGemini 中采纳了自适应的压缩解决形式，依据 Float 数据特色的不同，抉择不同的压缩算法。优化后，openGemini 采纳了 Snappy，Gorilla，RLE 三种压缩算法的组合，相比于独自应用 Gorilla，压缩率晋升了 60%，解压耗时缩小 38%
新增个性
反对多表 full join
在某些场景下，为了更灵便地剖析时序数据，咱们须要应用 full join 操作。例如：
> SELECT * FROM m
name: m
time host region total val
---- ---- ------ ----- ---
1434055562000000000 1 east 2 3
1434055562000000000 1 west 2 1
1434055562000000000 2 east 2 4
1434055562000000000 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,m2
tags: region=east, total=2
time m1.val m2.val
---- ------ ------
1434055562000000000 3 4
name: m1,m2
tags: region=west, total=2
time m1.val m2.val
---- ------ ------
1434055562000000000 1 2全连贯查问语句以关键字 ON 后的等效条件连贯左右子查问表中的所有行，并能够应用 Group BY 分组
反对流式聚合计算
海量数据场景下，传统 CQ 须要从磁盘读取大量数据进行计算，再写回磁盘文件。这种形式会呈现一些问题
- 磁盘 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：采样周期内样本数个数
- first：采样周期内样本按工夫序的第一个值
- last：采样周期内样本按工夫序的最初一个值
可见降采样会造成原始数据失真，而不同场景对数据失真的容忍水平不同，在查问一年趋势的场景下，数据只须要大抵的趋势正确即可。
与其余数据库中降采样性能不同的是，openGemini 可同时自定义多个降采样工夫范畴和策略。
创立降采样工作的示例语句如下：
CREATE DownSample
ON autogen.mst (float(sum,mean,count,max,min,first,last),integer(sum,mean,count,max,min,first,last)) With Duration 60d SampleInterval(3d, 6d, 30d) TimeInterval(1m, 5m, 10m)上述语句中，针对表 mst 进行降采样，降采样分为三级，从第 3 天的数据开始做第一级降采样，采样周期为 1 分钟，采样对象为浮点和整形的字段，采样办法为上述 7 种统计办法。第 6 天开始做第二级降采样，以此类推。该性能可无效缩小存储空间 50%，节约计算资源 90%。
反对近似分位数查问
在时序数据分析的场景中，有时须要可能无效的了解数据分布（例如，P50，P90，P95），而无需对宏大的工夫序列数据集执行低廉的计算，则能够应用近似分位数查问。
较多数据库应用 TDigest 算法计算百分位数，例如 InfluxDB、ClickHouse，ElasticSearch 等，该算法在数据分布末端精度较高，计算速度快，内存开销小。但其毛病是数据非末端时精度可能会升高。openGemini 设计的 OGSketch 近似统计算法，全范畴的近似分位数查问能达到更高的精度，并同时思考了数据增量更新问题，大幅晋升每次算法构建与查问的效率，无效升高查问时延。
查问语句示例如下：
> select * from mst
name: mst
time address age alive country height name
---- ------- --- ----- ------- ------ ----
1629129600000000000 shenzhen 12 true china 70 azhu
1629129601000000000 shanghai 20 false american 80 alan
1629129602000000000 beijin 3 true germany 90 alang
1629129603000000000 guangzhou 30 false japan 121 ahui
1629129604000000000 chengdu 35 true canada 138 aqiu
1629129605000000000 wuhan 48 china 149 agang
1629129606000000000 52 true american 153 agan
1629129607000000000 anhui 28 false germany alin
1629129608000000000 xian true japan 179 ali
1629129609000000000 hangzhou 60 false canada 180
1629129610000000000 nanjin 102 true 191 ahuang
1629129611000000000 zhengzhou 123 false china 203 ayin
# percentile_ogsketch 函数
> SELECT percentile_ogsketch(age, 50) FROM mst WHERE time >= 1629129600000000000 AND time <= 1629129611000000000 GROUP BY time(5s),country
name: mst
tags: country=american
time percentile_ogsketch
---- -------------------
1629129600000000000 20
1629129605000000000 52
1629129610000000000
name: mst
tags: country=canada
time percentile_ogsketch
---- -------------------
1629129600000000000 35
1629129605000000000 60
1629129610000000000
...反对 holtWinters() 时序预测算子
时序预测是一类经典的问题，在学术界和工业界都有着宽泛的钻研和利用。例如依据过来一段时间的数据预测存储空间何时达到水位线，或者预测一个设施何时可能老化进入故障维修期等。
holtWinters 函数可在指定的距离内预测给定 Field Key 的 n 个预测值，但该办法实用于具备周期性法则的时序数据。
应用示例如下：
SELECT HOLT_WINTERS(FIRST("water_level"),10,4) FROM "db0"."autogen"."mst" WHERE "location"='Hunan' AND time >= '2015-08-22 22:12:00' AND time <= '2015-08-28 03:00:00' GROUP BY time(379m,348m)节点间 RPC 通信反对数据压缩
openGemini 各个节点之间应用 RPC 通信，当频繁查问大量数据时，可通过配置项关上该性能，可无效缩小数据传输带宽，进步数据传输效率。
总结
本文次要介绍了 openGemini v1.0 新版本为用户提供的个性和性能优化，帮忙大家更分明理解新版本提供的能力，以及如何更好应用好这些能力。
欢送大家试用和反馈，openGemini 将判若两人提供更多更好用的性能，一直推动时序数据库的技术向前倒退！
将来还将提供：
- 高可靠性：反对数据多正本
- 可观测性：反对 openTelemetry 的 OLTP 协定
- 高工夫序列基数：数据库不再受限于工夫线规模
- 规范 SQL：反对规范 SQL，升高学习老本
- 软硬件联合：将 DPU 技术与 openGemini 相结合，打造 openGemini 极致性能
openGemini 共翻新，赢将来！
