LSM-tree中有提到读放大和写放大，请问这是什么含义呢，看了一下文章还是不太懂，有比较好理解的解释可供参考吗，还有为什么说LSM-tree是以空间换时间呢
读放大和写放大都是 LSM-tree 的问题，主要原因是数据结构需要在内存中维护多个副本，以及在合并过程中需要进行大量不必要的磁盘操作。详细可以阅读这遍B-Tree 与 LSM-Tree介绍：
TiKV | B-Tree vs LSM-Tree
1 个赞
读放大指的是在进行范围查询时，LSM-Tree需要进行多次的合并操作，以获取所需的数据。由于上层的新数据可能会覆盖下层的旧数据，并且层与层之间存在交集，因此可能需要进行多次的合并操作才能获取一段数据。这种多次合并操作会导致读放大，即需要读取的数据量比实际数据量更大。
写放大指的是在进行写入操作时，LSM-Tree需要进行多次的磁盘写入操作。每次写入操作都需要将数据写入日志（log）和刷新脏页（flush dirty page）两个步骤。即使只修改了一个字节的数据，也需要将整个页写入磁盘。这种多次的磁盘写入操作会导致写放大，即实际写入的数据量比修改的数据量更大。
1 个赞
这篇文档你可以看下
2 个赞
TiDB每次变更都是插入一个key -value，那么写放大是否真的存在？我不认为写日志属于写放大的行为，TiDB存在刷新脏页或者以块写入的概念吗？ 感觉这是Oracle和MySQL的逻辑呢？
tidb数据结构是LSM-tree，写放大是LSM-tree的问题
1 个赞
用空间换时间，LSM-tree提升了写的速率，但是代价就是空间占用变大，可以这么简单理解吧？
这里的读放大是指本来简单的读取变得复杂了，要查找更多资源才能找到数据，写放大是指任何DML语句在tidb都是直接写入数据，而不是去更改以前数据
LSM树(Log-Structured-Merge-Tree)的名字往往会给初识者一个错误的印象，事实上，LSM树并不像B+树、红黑树一样是一颗严格的树状数据结构，它其实是一种存储结构
LSM树会将所有的数据插入、修改、删除等操作记录(注意是操作记录)保存在内存之中，当此类操作达到一定的数据量后，再批量地顺序写入到磁盘当中。这与B+树不同，B+树数据的更新会直接在原数据所在处修改对应的值，但是LSM数的数据更新是日志式的，当一条数据更新是直接append一条更新记录完成的。这样设计的目的就是为了顺序写，不断地将Immutable MemTable flush到持久化存储即可，而不用去修改之前的SSTable中的key，保证了顺序写。
1）读放大:读取数据时实际读取的数据量大于真正的数据量。例如在LSM树中需要先在MemTable查看当前key是否存在，不存在继续从SSTable中寻找。
2）写放大:写入数据时实际写入的数据量大于真正的数据量。例如在LSM树中写入时可能触发Compact操作，导致实际写入的数据量远大于该key的数据量。
3）空间放大:数据实际占用的磁盘空间比数据的真正大小更多。上面提到的冗余存储，对于一个key来说，只有最新的那条记录是有效的，而之前的记录都是可以被清理回收的。
所谓空间放大（space amplification），就是指存储引擎中的数据实际占用的磁盘空间比数据的真正大小偏多的情况。例如，数据的真正大小是10MB，但实际存储时耗掉了25MB空间，那么空间放大因子（space amplification factor）就是2.5。
为什么会出现空间放大呢？很显然，LSM-based存储引擎中数据的增删改都不是in-place的，而是需要等待compaction执行到对应的key才算完。也就是说，一个key可能会同时对应多个value（删除标记算作特殊的value），而只有一个value是真正有效的，其余那些就算做空间放大。另外，在compaction过程中，原始数据在执行完成之前是不能删除的（防止出现意外无法恢复），所以同一份被compaction的数据最多可能膨胀成原来的两倍，这也算作空间放大的范畴。
3 个赞
是呢，空间会变大，但有压缩的话，大不了哪里去
1 个赞
数据库的存储结构是解决众多问题的根基，看来LSM tree还是得多研究
解答全面
好全，
lsm-tree导致的
压缩是 LSM 树中的SSTable 自动压缩吗
用空间换时间呀
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。