LSM-движок просто сбрасывает данные на диск (Flush) в виде новых файлов SSTable. Но если это будет продолжаться бесконечно, возникнут три проблемы: быстро закончится место из-за дубликатов, удаленные данные (Tombstones) продолжат висеть на диске, а чтение станет невыносимо медленным.
Чтобы дерево не захлебнулось, в фоновом режиме работает Compaction (Компакция). Она берет несколько старых SSTable, сливает их воедино, оставляет только свежие версии ключей и выбрасывает «надгробия» (Tombstones).
Три фактора усиления
В мире LSM производительность описывается тремя метриками компромисса. Мы должны понять, какая из трех проблем ниже для нас наименее значимая.
- Write Amplification (WA): Сколько физических байт записано на SSD на 1 байт данных от клиента. Фоновая компакция постоянно переписывает данные, что изнашивает ячейки SSD.
- Space Amplification (SA): Во сколько раз база на диске больше, чем реальный объем полезных данных (из-за дубликатов и Tombstones).
- Read Amplification (RA): Сколько блоков данных приходится прочитать, чтобы найти один ключ.
Стратегии компакции
| Стратегия | Когда выбрать | Плата (Боль) | Выгода |
|---|---|---|---|
| Leveled (RocksDB) | Случайные ключи, много апдейтов | Высокий Write Amp (20–30×) | Стабильное и быстрое чтение |
| Size-Tiered (Cassandra) | Пакетные вставки, логи, IoT | Высокий Space Amp (нужно 50% free) | Очень низкий Write Amp |
| Universal (RocksDB) | Почти чистый append-log | Чтение может проседать | Низкие WA и SA |
Каждая стратегия крутится набором конфигов в БД. Идеальная настройка всегда зависит от того, чего у тебя больше — записи или чтения