В теории LSM-деревья идеальны для записи. Но на практике, если пустить всё на самотёк, база может «встать колом» или сожрать весь диск. Вот шпаргалка по самым частым проблемам с продакшена и способам их лечения.
Частые грабли и как их лечить
| Проблема | Симптом на проде | В чем проблема | Чек-лист решения |
|---|---|---|---|
| Write Stall (Затор) | Запросы |
Уровень L0 переполнен. Фоновые потоки компакции не успевают «перемолоть» файлы, и база блокирует новые записи. | 1) Добавить CPU для потоков компакции; 2) Поднять лимит |
| Space Amp > 1.5× | Место на дисках тает быстрее, чем растет реальный объем данных. | Слишком много мертвых файлов. Долгие живые tombstones и устаревшие файлы ждут своей очереди на компакцию. | 1) Включить Periodic full-compaction; 2) Если данные временные — использовать TTL-шардирование. |
| Компакция жрёт CPU | top показывает 80% системной нагрузки при простаивающем диске. |
Неограниченный rate компакции и единый тред-пул для всех задач БД. | 1) Поставить |
| Out-of-space crash | База падает с ошибкой «Unable to compact». | В LSM (особенно Size-Tiered) для слияния двух файлов по 10 ГБ нужно временно еще 20 ГБ свободного места. Вы прозевали алерты. | Настроить жесткий алерт на < 15% Free Space. Если места нет — временно переключить на Universal компакцию или отключить автокомпакцию. |
Пример тормозящей компакции
Где LSM — это плохая идея
Для начала введем несколько терминов
- Endurance (Выносливость SSD): Предельный объем перезаписей, который физически выдержит диск до того, как начнет сыпаться. Измеряется в TBW (Терабайт записано) или DWPD (Перезаписей диска в день).
- Long-range scan: Запрос, который затрагивает такой огромный диапазон ключей (например, «все логи за год»), что фильтры Блума становятся бесполезны, и базе приходится читать файлы целиком, байт за байтом.
LSM — не серебряная пуля. Вот ситуации, когда стоит вернуться к B+ Tree или взять колоночную базу:
- OLAP-запросы и скан миллионов ключей (long-range scan)
- Почему больно: Большая часть данных лежит в самом нижнем, огромном уровне. При диапазонном чтении придется линейно пролистать гигантский файл.
- Что брать: Колоночные базы. Они умеют обрубать ненужные колонки и мгновенно прыгать по блокам благодаря мета-статистике.
- Точечные чтения без горячего кэша
- Почему больно: Чтобы найти один случайный ключ на холодном диске, LSM придется дернуть фильтры Блума и индексы на каждом уровне. Это много операций чтения (Read Amp).
- Что брать: B+ Tree. Оно делает ровно один бинарный спуск O(log N) и читает одну страницу диска. Средняя латентность будет ниже.
- Крошечный датасет на дешевом SSD (low endurance)
- Почему больно: На маленьких объемах вы не почувствуете плюсов от скорости вставки LSM. Зато огромный Write Amplification будет постоянно перезаписывать ячейки вашего накопителя. Ресурс дешевого диска сгорит в разы быстрее.
- Что брать: Классические базы на B-Tree (PostgreSQL, MySQL), они бережнее относятся к небольшим объемам.