​v1.2.0 版本正式发布，IoT 场景性能大幅提升在 openGemini v1.2.0 版本中，我们为您带来了一系列令人振奋的内核优化，将您的体验提升到新的高度，这包括：

• 针对 IoT 场景的性能优化，查询效率有极大的提升。

• 针对数据存储的优化，进一步节约磁盘空间，降低数据存储成本。

• 针对部分功能的优化，比如 show tag keys, stream 等，使得功能更加丰富。

• 新增了一部分内核的监控指标，进一步清楚了解内核的运行状态、行为和性能，帮助分析、定位和优化数据库性能。

此外，我们还进行了一系列的读写流程上的改进和修复，以提供更稳定和可靠的体验。

内核优化

1. IoT 典型场景性能优化

本次版本针对 IoT 场景的写入和典型查询场景进行了优化，通过 TSBS 工具的测试结果可以看出，openGemini 全面超越 InfluxDB，最高提升了 50 倍。相比其他时序数据库，openGemini 也是具有领先优势。

具体性能数据参考:

https://docs.opengemini.org/zh/guide/introduction/performance.html

2. schema 数据压缩

type Record struct {	*RecMeta	ColVals []ColVal	Schema  Schemas}
type Schemas []Field
type Field struct {	Type int	Name string}

openGemini 将行数据协议转化为 Record 结构进行存储，Schema 保存每一列 FIELD 的数据类型和名称，并会随着数据一起保存在磁盘上，当表的 FIELD 数量很多，比如 1000 列或者更多时，加之时间线数量很大的情况下，这里的 Schema 数据会变得很大，在 tssp 文件中的占比可能超过 80%。

可以通过配置文件开启 schema 数据压缩（默认关闭），但需要注意的是，该功能会对查询性能有一定的影响，因为查询过程中要对 schema 进行数据解压

  [data]  ## Compressing ChunkMeta in TSSP Files. 0: not compressed(default); 1: use snappy  # chunk-meta-compress-mode = 0

优化效果：500 万时间线 1000+列模型下，开启压缩功能后（Snappy 算法），写性能提升 2.5+倍，平均刷盘时延减少 68%，level 0 文件大小减少 70%

最佳实践：针对列比较多的情况，尽可能用短字符串给 FIELD 命名。再考虑开启 schema 数据压缩。

该优化优先级高于 "tssp 临时文件磁盘占用优化"，开启该优化后，临时文件的优化将自动失效

3. 优化仅一行数据情况下的数据编码

在一些业务中，时间线很多，但是每次写入时，同一时间线仅一条数据，这使得在 level 0 的文件中，一条时间线仅一条数据，本身没有办法进行压缩，还需要存储很多额外的信息，占用了大量的磁盘空间。 本次优化是专门针对上述场景，减少 level 0 文件大小，达到提升 compaction、Merge 和部分查询的性能的目的。

优化效果：250 万时间线，优化前文件大小 987MB， 优化后 733MB，存储空间减少 25%。

4. 优化全空值或没有空值列的存储

在 openGemini 中，数据的压缩存储是以 segment 为粒度（1000 行），可能存在 segment 为全空值（ColVal.Len == ColVal.NilCount）或没有空值（ColVal.NilCount == 0），此时可以不存储 bitmap 相关数据，减少磁盘占用。

优化效果：3 万时间线，2400 万行数据，没有空值的情况下，优化后存储空间减少 20%

5. tssp 临时文件磁盘占用优化

数据写入 openGemini 后，在数据刷盘过程中，文件元数据会先保存到一个临时文件，在所有数据刷盘完成后，将临时文件追加到数据文件中，然后删除该临时文件，当写入数据量非常大时，临时文件数据也会频繁刷盘，占一部分磁盘 I/O，本次优化是对临时文件进行一个压缩处理，减少磁盘 I/O。该优化对刷盘，compaction，merge 等操作有效。

可通过修改配置项 data.temporary-index-compress-mode 来开启，该优化方法是用 CPU 开销（解压）换取磁盘 I/O，在选择压缩算法时需要考虑实际情况。

6. SHOW TAG KEYS 支持条件过滤

用法如下：

> select * from cpuname: cputime                cpu  host        mem----                ---  ----        ---1710209706991211420 0.8  192.168.0.1 0.31710209718880801483 0.65 192.168.0.2 0.421710209735839331535 0.77 192.168.0.3 0.46
> show tag keys from cpu where host="192.168.0.1"name: cputagKey------host

7. 流式聚合（stream）用法和性能优化

在用法上，之前使用该功能时，必须是 tags & time 一起分组，当前版本支持仅按 time 分组。例如

# 之前版本用法> CREATE STREAM ... ON SELECT ... FROM ... GROUP BY time(1m),"cpu","host" delay 20s# 现在可以仅使用time分组> CREATE STREAM ... ON SELECT ... FROM ... GROUP BY time(1m) delay 20s

在性能上，聚合效率较之前版本有数倍提升。

8. 新增监控项

IOReadMetaCounts、IOReadMetaSize、IOReadDataCounts、IOReadDataSize，分别表示从数据文件中读取元数据的次数和大小和读取数据的次数和大小。

有了这些基本数据，通过简单的处理就可以知道在某段时间内查询的数据量大小，以此作为性能优化或根因分析的依据。比如在定位查询问题时，如果查询时延比较大，此时可以观察该指标，了解 openGemini 存储引擎从文件读取数据的情况，以此判断是否由于计算数据量太多导致，从而优化查询语句。

9. 新增监控项

IOFrontIndexReadOkCount，IOFrontIndexReadOkBytes，IOFrontIndexReadDuration ，在 openGemini 中，磁盘 I/O 包括业务数据读写 I/O, 索引读写 I/O，Compaction 读写 I/O，乱序合并读写 I/O 等，这里新增的 3 个监控项均为索引读写 I/O 的指标，分别是索引数据读取次数/字节数/时延。

当性能瓶颈发生在磁盘 I/O 时，通过调取相应细分 I/O 数据，确定何种类型的 I/O 流量占比较大，可以进行针对性优化。

10. 新增监控项

以下为本次优化新增的关于 ts-store 上查询请求执行相关的监控项，用于洞察 ts-store 上的查询执行情况

# ts-store处理的查询请求数storeQueryReq # ts-store的查询时延storeQueryReqDurationNs  # 当前ts-store上正在执行的查询请求数storeQueryReqActive # ts-store上反序列化查询请求的时延UnmarshalQueryTimeTotal  # ts-store上查询请求获取shard资源的时延。# 这里有流控，ts-store执行查询请求的并发数是一定的，如果查询并发比较大，就会出现排队情况，这里的时延就会比较大。GetShardResourceTimeTotal  # 以下两项分别是ts-store上TAG构建扫描索引计划的时延和扫描数据的时延IndexScanDagBuildTimeTotalIndexScanDagRunTimeTotal# ts-store上查询请求查找索引的时延IndexScanRunTimeTotal# ts-store上查询请求涉及的shard个数QueryShardNumTotal # ts-store上查询请求扫描的时间线数量IndexScanSeriesNumTotal# 以下两项是查询请求读取数据的监控项ChunkReaderDagBuildTimeTotalChunkReaderDagRunTimeTotal

11. 调整配置项read-page-size，默认 32KB，最大可配 64KB，对提升查询性能有帮助，但会增大磁盘 I/O 带宽，二者需要平衡。

[data]# read-page-size set pageSize of read from file of datablock, default is "32kb", valid setting is "1kb"/"4kb"/"8kb"/"16kb"/"32kb"/"64kb"/"variable"# read-page-size = "32kb"

Bug 修复

1. 修复了一些异常场景下节点 Panic 的问题

2. 修复了批量删除表时，ts-store 出现删除表失败的问题

3. 修复了一些内核中锁的问题

4. 修复了一些内核处理空值的问题

5. 修复了一些内存泄露的问题

安全

1. 修复漏洞：CVE-2022-41723，通过升级golang.org/x/net的版本到v0.7.0
   

2. 修复漏洞：CVE-2023-39325，通过升级golang.org/x/net的版本到v0.17.0
   

3. 修复漏洞：CVE-2023-47248，通过升级 pyarrow 的版本到 v14.0.1

结束

openGemini 是一款开源时序数据库，它的 v1.2.0 版本已经正式发布，在这个版本中，内核得到优化，新增几项监控项，修复了若干 Bug 和漏洞，无论是性能还是使用体验都得到了有效提升。欢迎大家试用 openGemini，提出您宝贵的优化意见。

如何参与社区贡献，参考：

1. https://docs.opengemini.org/zh/dev-guide/get_started/
   

2. https://docs.opengemini.org/zh/guide/contribution/Document.html
   

openGemini 官网：http://www.openGemini.org

Star for me😊：https://github.com/openGemini

openGemini 公众号：

欢迎关注～ 诚邀你加入 openGemini 社区，共建、共治、共享未来！