openGemini v1.2.0 版本正式发布,IoT 场景性能大幅提升!
![openGemini v1.2.0版本正式发布,IoT 场景性能大幅提升!](https://static001.geekbang.org/infoq/a3/a370e483a3190d8018091e390f9a779e.jpeg)
本文分享自华为云社区《openGemini v1.2.0版本正式发布,IoT 场景性能大幅提升!》,作者:华为云开源。
在 openGemini v1.2.0 版本中,我们为您带来了一系列令人振奋的内核优化,将您的体验提升到新的高度,这包括
针对 IoT 场景的性能优化,查询效率有极大的提升。
针对数据存储的优化,进一步节约磁盘空间,降低数据存储成本。
针对部分功能的优化,比如
show tag keys
,stream
等,使得功能更加丰富。新增了一部分内核的监控指标,进一步清楚了解内核的运行状态、行为和性能,帮助分析、定位和优化数据库性能。
此外,我们还进行了一系列的读写流程上的改进和修复,以提供更稳定和可靠的体验。
内核优化
IoT 典型场景性能优化
本次版本针对 IoT 场景的写入和典型查询场景进行了优化,通过 TSBS 工具的测试结果可以看出,openGemini 全面超越 InfluxDB,最高提升了 50 倍。相比其他时序数据库,openGemini 也是具有领先优势。
具体性能数据参考:https://docs.opengemini.org/zh/guide/introduction/performance.html
schema 数据压缩
openGemini 将行数据协议转化为 Record 结构进行存储,Schema 保存每一列 FIELD 的数据类型和名称,并会随着数据一起保存在磁盘上,当表的 FIELD 数量很多,比如 1000 列或者更多时,加之时间线数量很大的情况下,这里的 Schema 数据会变得很大,在 tssp 文件中的占比可能超过 80%。
可以通过配置文件开启 schema 数据压缩(默认关闭),但需要注意的是,该功能会对查询性能有一定的影响,因为查询过程中要对 schema 进行数据解压
优化效果:500 万时间线 1000+列模型下,开启压缩功能后(Snappy 算法),写性能提升 2.5+倍,平均刷盘时延减少 68%,level 0 文件大小减少 70%
最佳实践:针对列比较多的情况,尽可能用短字符串给 FIELD 命名。再考虑开启 schema 数据压缩。
该优化优先级高于 "tssp 临时文件磁盘占用优化",开启该优化后,临时文件的优化将自动失效
优化仅一行数据情况下的数据编码
在一些业务中,时间线很多,但是每次写入时,同一时间线仅一条数据,这使得在 level 0 的文件中,一条时间线仅一条数据,本身没有办法进行压缩,还需要存储很多额外的信息,占用了大量的磁盘空间。 本次优化是专门针对上述场景,减少 level 0 文件大小,达到提升 compaction、Merge 和部分查询的性能的目的。
优化效果:250 万时间线,优化前文件大小 987MB, 优化后 733MB,存储空间减少 25%。
优化全空值或没有空值列的存储
在 openGemini 中,数据的压缩存储是以 segment 为粒度(1000 行),可能存在 segment 为全空值(ColVal.Len == ColVal.NilCount
)或没有空值(ColVal.NilCount == 0
),此时可以不存储 bitmap 相关数据,减少磁盘占用。
优化效果:3 万时间线,2400 万行数据,没有空值的情况下,优化后存储空间减少 20%
tssp 临时文件磁盘占用优化
数据写入 openGemini 后,在数据刷盘过程中,文件元数据会先保存到一个临时文件,在所有数据刷盘完成后,将临时文件追加到数据文件中,然后删除该临时文件,当写入数据量非常大时,临时文件数据也会频繁刷盘,占一部分磁盘 I/O,本次优化是对临时文件进行一个压缩处理,减少磁盘 I/O。该优化对刷盘,compaction,merge 等操作有效。
可通过修改配置项 data.temporary-index-compress-mode
来开启,该优化方法是用 CPU 开销(解压)换取磁盘 I/O,在选择压缩算法时需要考虑实际情况。
SHOW TAG KEYS
支持条件过滤
用法如下:
流式聚合(stream)用法和性能优化
在用法上,之前使用该功能时,必须是 tags & time 一起分组,当前版本支持仅按 time 分组。例如
在性能上,聚合效率较之前版本有数倍提升。
新增监控项
IOReadMetaCounts、IOReadMetaSize、IOReadDataCounts、IOReadDataSize,分别表示从数据文件中读取元数据的次数和大小和读取数据的次数和大小。
有了这些基本数据,通过简单的处理就可以知道在某段时间内查询的数据量大小,以此作为性能优化或根因分析的依据。比如在定位查询问题时,如果查询时延比较大,此时可以观察该指标,了解 openGemini 存储引擎从文件读取数据的情况,以此判断是否由于计算数据量太多导致,从而优化查询语句。
新增监控项
IOFrontIndexReadOkCount,IOFrontIndexReadOkBytes,IOFrontIndexReadDuration ,在 openGemini 中,磁盘 I/O 包括业务数据读写 I/O, 索引读写 I/O,Compaction 读写 I/O,乱序合并读写 I/O 等,这里新增的 3 个监控项均为索引读写 I/O 的指标,分别是索引数据读取次数/字节数/时延。
当性能瓶颈发生在磁盘 I/O 时,通过调取相应细分 I/O 数据,确定何种类型的 I/O 流量占比较大,可以进行针对性优化。
新增监控项
以下为本次优化新增的关于 ts-store 上查询请求执行相关的监控项,用于洞察 ts-store 上的查询执行情况
调整配置项read-page-size
,默认 32KB,最大可配 64KB,对提升查询性能有帮助,但会增大磁盘 I/O 带宽,二者需要平衡。
Bug 修复
修复了一些异常场景下节点 Panic 的问题
修复了批量删除表时,ts-store 出现删除表失败的问题
修复了一些内核中锁的问题
修复了一些内核处理空值的问题
修复了一些内存泄露的问题
安全
修复漏洞:CVE-2022-41723,通过升级 golang.org/x/net 的版本到 v0.7.0
修复漏洞:CVE-2023-39325,通过升级 golang.org/x/net 的版本到 v0.17.0
修复漏洞:CVE-2023-47248,通过升级 pyarrow 的版本到 v14.0.1
结束
openGemini 是一款开源时序数据库,它的 v1.2.0 版本已经正式发布,在这个版本中,内核得到优化,新增几项监控项,修复了若干 Bug 和漏洞,无论是性能还是使用体验都得到了有效提升。欢迎大家试用 openGemini,提出您宝贵的优化意见。
如何参与社区贡献,参考:
https://docs.opengemini.org/zh/dev-guide/get_started/
https://docs.opengemini.org/zh/guide/contribution/Document.html
openGemini 官网:http://www.openGemini.org
Star for me😊:https://github.com/openGemini
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/de60fe062022a4b2b1d08fee2】。文章转载请联系作者。
评论