我的理解，同一行记录，在多次转储和合并过程中，也有写放大的问题吧
7 个赞
LSM 的优势是规避随机写，把更新批量顺序落盘，不是降低总写入量。确实存在写放大，同一行多次更新，经过多次转储、合并，会反复重写数据。它换来的是很高的写入吞吐，写放大是要付出的成本。
3 个赞
转储合并是攒批，顺序写入。
2 个赞
点赞~~
1 个赞
LSM 并非“写放大更少”，而是将随机写转化为顺序写，大幅降低单次写入的 I/O 开销和延迟；其确实存在写放大（Compaction 导致数据重写），但相比 B+ 树在高频随机更新下的页分裂、原地重写等代价，整体写入吞吐更高、对存储介质磨损更可控。
2 个赞
不是吧，转储与合并就是为了解决写放大的问题
2 个赞
是的，理解正确
1 个赞
收藏
我记得确实有写放大问题
打卡!!!
你这个质疑是对的——“LSM 减少写”这句话本身是片面的，严格说是“减少随机写”，不是减少总写入量；而转储/合并（compaction）带来的写放大是 LSM 公认代价，OceanBase 也不例外
-
“LSM 减少写” = 减少前台随机写、把写延迟平摊到后台，不是总 IO 字节少
-
“LSM 有写放大” = compaction/merge 把同一行反复读写，总写入 ≥ 原数据若干倍