LSM读写放大问题

🛸 其他技术问题
1

TiDB使用LSM，你是否在生产环境遇到过此类问题？有什么好的解决措施预防此类问题？

3 个赞
2

没有遇到

2 个赞
3

生产环境遇过 LSM 触发的写放大、Compaction 性能抖动问题。预防的话，可以调 Compaction 策略，分冷热数据存储，监控磁盘 IO 和内存。

2 个赞
4

LSM的特性，空间换时间

5

对, LSM-Tree 存储引擎的缺点

6

合并好像是还有两种算法？TiDB不知是哪种？

7

归并排序?

8

没遇到过

9

我看资料上有两种合并策略：Size-tiered和Leveled

10

学习了，楼主的分析思路很清晰，对我很有启发。

11

哦,那可能是我记错了

12

LSM机制本身就是解决写放大问题的,不对元数据做修改,只用数据版本进行都快照的控制的.

13

对对对，我在OB从新看了一下理论

14

应该不是解决，是LSM的特性决定了有这种现象

15
1 个赞
16

TiDB 的 LSM 读写放大（TiKV 基于 RocksDB 的 LSM 树）常出现于：

  1. 频繁小写入（如大量小事务）：触发频繁 Compaction，加剧写放大；
  2. 范围查询跨多 SST 文件：需读取多个分层文件，引发读放大；
  3. 写入压力过高：Compaction 资源占用多，读写放大同步恶化；
  4. 数据冷热不均：冷数据被重复合并，额外增加读写开销。
1 个赞
17

感谢老师分享

18

感谢分享，细品一下

19

只能调整合并策略

20

按照官方的规范，系统上线的时候使用nvme接口的ssd磁盘，这样多节点之后的总iops高于集中式存储好几倍，抵消了读写放大带来的影响。