随着时序数据的急剧增长，单机版时序数据库受计算资源限制，无法处理海量时序数据的并发写入，难以满足业务增长对时序数据库的性能要求，需要数据库支持横向扩展来满足业务系统对时序数据的处理和计算能力。线性度是衡量集群处理能力的重要参考指标之一，好的线性度意味着在相同业务负载情况下，集群需要的节点数更少，反之则需要添加更多的节点，甚至可能因为节点数的增加，性能反而下降。
openGemini支持100+节点集群规模，实测48节点线写性度在76%左右，本文主要分享：openGemini保持较高写线性度的三种最佳实践方法。
数据批量化写入
数据批量化写入指客户端批量将数据写入到集群，目的是减少网络传输的次数，减少集群内部加锁释放锁的次数，提升写性能。
如上图所示，随着集群横向扩展，数据节点数增多，如果客户端一次向ts-sql批量写入的数据行数不变，那么经过数据打散后发送到每个ts-store节点的数据会变少（与扩容前相比），但集群的处理能力因新增数据节点（ts-store）后得到加强，可以一次处理更多数据的写入，因此可以增加ts-sql向ts-store单次分发的数据量，充分利用新节点计算资源，以此确保新增节点后，数据处理效率有线性增长，即有良好的线性度。具体做法如下：
修改ts-sql配置
[http]...read-block-size=128 * 1024
read-block-size表示ts-sql一次读取客户端发送过来的数据大小，默认是64KB。
read-block-size的值可以参考批量写入时一个batch的大小，如果batch小于64KB，建议加大batchsize。这里还需要考虑ts-sql处理数据的并发数，通常是vCPU核数，要确保内存有足够空间容纳 read-block-size * 并发数的这部分数据，另外还要考虑给数据查询预留内存空间（这里前提是内存空间是充裕的）。
写请求在ts-sql上的调度如上图所示，流程如下：
1. 按照配置的read-block-size，读取网络io中的数据
2. 按照配置的并发数（cpu核数），对读出来的block进行调度，在调度过程中会执行unmarshal将二进制流转换为openGemini可识别的rows，最后，按照分区规则，将数据分发送到对应的ts-store节点进行写入
3. 等待本次写入的所有block都调度完成后，返回写入执行结果
符合时序数据特征的索引周期
对于时间线是确定的业务来讲，可以通过设置Index Duration为Shard Duration的整数倍或者更长，即减少了重复索引，同时也减少了在切换Shard Group时的性能抖动，提升写性能稳定性，降低扩容对写性能线性度的影响。
Index Duration和Shard Duration默认都等于1天，即每天的数据写入一个新的ShardGroup中，每切换一次ShardGroup就要重新构建倒排索引，重新构建索引会有一定的性能损耗。
如何修改Index Duration请参考官网文档
https://docs.opengemini.org/zh/guide/schema/retention_policy.html
什么是Index Duration？
Index Duration是指ShardGroup之间倒排索引复用的时间范围，主要目的是为了灵活应对时间线变化的场景，以及时间线比较固定的场景。
在时间线不确定的场景下，新的ShardGroup周期开始后，可能不断有新时间线数据写入，因此需要重新构建新的倒排索引，复用原来的索引意义不大，通过设置Index Duration等于Shard Duration，就能确保每次切ShardGroup时都重新创建索引。
但在绝大多数场景中，时间线是确定的，也就是说存储引擎创建的时间线倒排索引是可以被长期复用的，不用在切换ShardGroup时为Shard重新构建新的倒排索引，可以通过设置Index Duration等于Shard Duration的整数倍或者更长时间。
什么是保留策略(Retention Policy简称RP)，与Shard和ShardGroup是什么关系？
如图所示，在openGemini里，RP定义了数据保留周期(Duration)，意味着过期会自动被删除。RP需要与DB关联才生效，意味着这个DB内的数据采用了该RP规定的过期时间，一个DB内也可以创建多个RP。
在RP下面有多个ShardGroup，openGemini按ShardGroup来管理数据，它是一个逻辑概念,时间范围由Shard Duration决定。一个ShardGroup由多个Shard组成，Shard是存储数据的最小单位，一批数据到来，会按照时间线Key进行Hash打散均匀分散在多个Shard里。
默认情况下Duration和Shard Duration有对应时间范围如下表所示：
| Duration |
Shard Duration |
| 大于6个月 |
7天 |
| 2天-6个月 |
1天 |
| 小于2天 |
1小时 |
设置ShardGroup的目的是更加细粒度管理数据，一方面方便数据查询，通过查询语句给定的时间范围可以准确定位数据属于哪些ShardGroup，从而可以确定数据落在哪些Shard里；另一方面是方便进行过期数据删除。举个例子，如果Duration（数据保留时长）是3个月，从1月1日开始计算，1月1日的数据全部存入ShardGroup-1下面的三个Shard，1月2日的数据则存放到新的ShardGroup-2下面的三个Shard，以此类推，到4月1日时，第一个ShardGroup-1的数据已超过3个月，这时就可以批量把Shard-1，Shard-2，Shard-3的数据删除即可。
支持分片键可配
前面我们介绍了增大read-block-size的方法，可以在扩容后充分利用ts-store批量数据处理能力。这里我们介绍另外一种方法，同样可以提升集群写入线性度，那就是指定ShardKey，参考文档见：
https://docs.opengemini.org/zh/guide/schema/measurement.html
我们知道在openGemini内部，数据默认是按时间线做Hash打散，再写入到不同的ts-store，如果单批次写入数据量不变的情况下，集群扩容增加了ts-store数量，但是每个ts-store处理的平均数据量减少了，资源并未得到很好的利用。
openGemini通过配置shardKey，将shardKey对应的value值相同的时间线放在一个节点上，大大减少了写入和查询的扇出度，提高了写入和查询性能。实际应用中，用户可根据需要配置合适的shardKey，按照shardKey分组的数据最好是均匀的，这样按照shardKey打散后，数据可以均匀分配到各个ts-store节点。按照shardKey对应的value值分组后，写入openGemini，减少跨节点转发，提高ts-store上的批量度，对于同样的写入数据，ts-store上的写请求由少量多次变成更少的写入次数，每次写入的数据量变大。但是有个前提条件是，客户端需要尽可能的让相同ShardKey的数据放在一个Batch中写入到openGemini。
举个例子，如上图所示，假设数据中有一个标签为host，原始的一批数据存在多个host的数据，写入时，按照seriesKey打散，将1000条数据中，将host=127.0.0.1的500条数据，写入到store1，将host=127.0.0.2的500条数据写入到store2，那么写入两批数据，store1和store2分别处理了2次写入500条数据的请求；如果将host设置为shardKey，client端提前按照host分组，那么一批数据，只会路由到一个节点，即写入两批数据，store1和store2分别处理了1次1000条数据的写入请求，减少了store处理写请求的次数，提高整体写性能。在store节点扩容时，由于一批数据只会写到一个节点，不会因为节点数量的增加，导致每个节点处理的请求数变多，保证写性能的线性度。
写性能线性度测试结果（非指定ShardKey）
通过数据批量化（一批处理64M）以及配置索引周期（索引周期设置为7天，数据周期设置为1天），openGemini在72个节点（48核）的环境中对写性能线性度做了测试，测试模型为240张表，按照seriesKey哈希打散，300w时间线/节点，10亿点/节点，共2.16亿时间线，并发数为48/节点，写性能线性度可以达到76%，测试结果如下：
总结
本文主要介绍了三种提升写性能的最佳实践方法，分别是：
1. 增加ts-store节点时，在ts-sql上内存允许的情况下，可将read-block-size设置大一点，提高ts-sql上一批处理的数据量，减少发送到ts-store的rpc请求次数，保证ts-store的批量化，保证扩容时，写性能的线性度，但需要注意read-block-size与cpu核数的乘积不超过ts-sql内存大小。
2. 可根据本身数据特点，如标签比较固定，不怎么变化的情况下。换句话说，时间线是固定的，可将索引周期设置大一点，减少到达索引周期需要重建索引带来的写性能抖动。
3. 在多个数据源产生数据比较均匀的情况下，将唯一能表示数据源特征的标签设置为shardKey，让同一数据源的数据写入到一个节点中，减少写放大，提升写性能线性度。
以上三种方法，既可以提升写性能，也对写线性度提升有很大帮助，希望可以帮助到大家。
openGemini官网：http://www.openGemini.org
openGemini开源地址：https://github.com/openGemini
openGemini公众号：
欢迎关注～ 诚邀你加入 openGemini 社区，共建、共治、共享未来！
开源框架 NanUI 作者转行卖钢材，项目暂停开发 苹果 App Store 免费榜第一是黄色软件 TypeScript 刚刚流行起来，为什么大牛们就开始抛弃了？ TIOBE 10 月榜单：Java 跌幅最大，C# 逼近 Java Rust 1.73.0 发布 男子受 AI 女友怂恿刺杀英国女王，被判入狱九年 Qt 6.6 正式发布 路透社：RISC-V 技术成为中美科技战的新战场 RISC-V：不受任何单一公司或国家的控制 联想计划推出 Android PC