Partitioned Raft KV 特性讨论

[Jellybean (李文杰)]

TiDB v6.6.0 引入了 Partitioned Raft KV 存储引擎作为实验特性，该引擎使用多个 RocksDB 实例存储 TiKV 的 Region 数据，每个 Region 的数据都独立存储在单独的 RocksDB 实例中。
在 TiDB v7.4.0 中，Partitioned Raft KV 引擎在兼容性和稳定性方面得到了进一步提升。

有几个问题想和各位大佬讨论一下：

1. 一个 Region 独占一个 RocksDB 实例，假设一个集群有几万个 Region 就会有几万个 RocksDB 实例。

• 这么多实例的管理是如何考虑的？
• 每个 RocksDB 都有 MemTable 等的使用，内存可能会急剧增加，OOM 风险更高？

2. 以前一个 TiKV 实例上全部 Region 都写入一个 RocksDB，当数据量比较大时（TB级别）会有明显的写放大问题，现在用了 Partitioned-Raft-KV 就不会再有 TB 级别的 RocksDB了，因为不会有 TB 级别的 Region 。
   所以，写放大问题会得到极大改善？

3. 我们使用 Placement Rule in SQL 策略以及大 Region 也能实现海量数据的存储，目前有单RocksDB（存在HDD）超过 15TB 的存储实践，如果替换为 Partitioned Raft KV 在压缩率上、磁盘空间占用上会不会有提升？怎么理解？

[h5n1]

大佬，个人愚见：
1、Partitioned KV 开启后region-split-size 默认为10G ，region-max-size 默认为15G，region数量会减少很多。 memtable 有刷新参数控制write-buffer-flush-oldest-first ，是刷新最老的还是最大。write-buffer-limit控制所有memtable使用的总内存大小。
2、 我觉得写放大不会有太大改善吧，不同的表根据写入情况触发的时间会有差异，比如有很多历史数据类表很少写入那他就compact就少，IO也就少了，而原来的方式每次compact可能都要读这些数据又再写一遍。另外 Partitioned KV开启后就不写WAL了，能节省IO
3、之前方式的大region 是通过调整参数大小，但是有限制 我记得好像类似tikv传输有个4G限制就跟region大小有关， Partitioned KV 的实现基础有个dynamic region size ，这个具体原理还没研究，应该会解决之前的限制问题。在压缩率上应该还是和原来一样压缩算法，都是rocksdb嘛。磁盘空间上可能触发compact更有效率，之前版本发现GC后的delete数compact并不及时，我觉得起码按表compact功能应该会有，这样对其他的表也没太大影响。

https://github.com/tikv/rfcs/blob/master/text/0093-rocksdb-per-region.md

[TiDBer_小阿飞]

看的脑瓜子嗡嗡的

[Jellybean (李文杰)]

感谢大佬回答。

1.新引擎应该是会更容易触发OOM的现象。在文档里也提到了一些优化方法，可以通过减小每个 RocksDB memTable 的方式，缓解这一现象。
Drawbacks
This RFC may be easier to OOM compared to existing architecture

2.写放大这个不太好判断，但是整体上对集群的 IO 消耗确认是节省了的，大大减少了不必要的数据扫描和Compaction。
Partitioned Raft KV 开启后就不写 WAL 了，这个操作应该会有别的机制来规避宕机数据丢失，不然风险太高。

3.从压缩率和空间占用角度来看，使用上 Partitioned Raft KV 后变化不大，不过从 IO 消耗角度来看有大的优化，对于冷热归档存储方案还是有不少应用价值的。用上Placement Rule in SQL 策略 + Partitioned Raft KV ，不仅能保证绝大部分数据保存在 HDD 上，还能保证 IO 消耗得到缓解，仔细深挖应该也是一个不错的应用思路。

[h5n1]

还有不知道block cache 是怎么管理分配的

[Jellybean (李文杰)]

是的，底层核心引擎换了很多东西和之前的不一样，官方在这方面得提供文档详细说明才行，不然不太敢上这个特性。

如果说官方同学太忙了，由版主大佬你们在社区里提供相关文档资料也是一个不错的思路

[Fly-bird]

看的脑瓜子嗡嗡的，向大佬学习