Выбор и настройка Cassandra Compaction Strategies
Мы настраиваем Cassandra compaction под ваши данные — не выбираем стратегию «на глаз», а анализируем профиль нагрузки, TTL, частоту обновлений и размеры SSTables. Неправильный выбор стратегии приводит к деградации read latency в 2–3 раза, переполнению диска и TombstoneOverwhelmingException. Наша команда имеет 5+ лет опыта с Apache Cassandra и более 30 проектов по оптимизации производительности. За 1–3 дня мы проведём аудит, подберём стратегию (STCS, LCS, TWCS) и выполним смену без даунтайма.
STCS, LCS и TWCS — три основных механизма, каждый со своей физикой. STCS объединяет SSTables схожего размера при накоплении порога (по умолчанию 4). Write amplification минимальный, но read страдает из-за множества разрозненных SSTables. LCS раскладывает данные по уровням: каждое чтение касается не более одного SSTable на уровень, что даёт отличную read performance ценой десятикратного write amplification. TWCS спроектирован для time-series: разбивает данные на временные окна и финализирует каждое окно, а при истечении TTL целиком удаляет SSTable — без проверки каждой строки.
| Характеристика | STCS | LCS | TWCS |
|---|---|---|---|
| Write amplification | Низкий | Высокий (~10x) | Низкий |
| Read performance | Средняя | Отличная | Хорошая |
| Дисковое пространство | Требует 2x в пике | ~1.1x | ~1.1x |
| Работа с TTL | Плохо | Средне | Отлично |
| Рекомендуемая нагрузка | Append-only, write-heavy | Read/write, updates | Time-series с TTL |
Какую стратегию выбрать для вашей нагрузки?
Для insert-only таблиц без удалений — STCS. Для баланса чтения и записи с частыми updates — LCS. Для метрик, логов и других time-series с TTL — TWCS. На практике в одном кластере уживаются разные стратегии. Пример: таблица events (append-only, TTL) → TWCS; user_profiles (частые запросы и изменения) → LCS; raw_data (bulk insert, без TTL) → STCS. Мы помогаем настроить каждую таблицу индивидуально.
Что делать, если compaction отстаёт?
Команда nodetool compactionstats показывает pending tasks. Если они растут — compaction не успевает за writes. Краткосрочное решение: увеличить compaction_throughput_mb_per_sec до 64–128 МБ/с (зависит от дисковой подсистемы). Долгосрочное — пересмотреть стратегию или добавить ноды. Типичная ошибка — держать default для SSD (16 МБ/с), что приводит к росту read latency. Мы в своей практике поднимали throughput до 200 МБ/с на NVMe без потери стабильности.
Tombstones — ещё один враг производительности. При чтении одной партиции может быть прочитано более 100 000 tombstones, что вызывает TombstoneOverwhelmingException. Причина — частые DELETE или UPDATE без компактификации. Решение: правильно выбрать стратегию и настроить gc_grace_seconds. В LCS tombstones удаляются быстрее, в STCS — медленнее. Для time-series с TTL tombstones практически не образуются.
| Сценарий | Рекомендуемая стратегия | Причина |
|---|---|---|
| High write, no deletes | STCS | Низкий write amplification |
| Read-intensive, updates | LCS | Минимальное число SSTables на чтение |
| Time-series, TTL | TWCS | Автоматическое удаление истёкших SSTables |
Почему tombstones убивают read latency?
Tombstones — метки об удалении строк. При чтении партиции Cassandra сканирует все SSTables, собирая живые данные и игнорируя tombstones. Если их много (например, при частых DELETE без своевременной компактификации), latency растёт. TWCS решает эту проблему для time-series: истёкшие SSTables удаляются целиком, не оставляя tombstones. Для остальных случаев помогает настройка gc_grace_seconds и выбор правильной стратегии.
Процесс работы: от аудита до деплоя
-
Аудит — анализируем
nodetool tablestats, метрики compaction и load, выявляем узкие места. - Проектирование — для каждой таблицы выбираем стратегию и параметры (min/max threshold, bucket size для TWCS).
-
Реализация — применяем
ALTER TABLEв непиковое время. При необходимости запускаемnodetool compactперед сменой стратегии. - Тестирование — проверяем read/write latency, дисковое потребление, количество tombstones.
- Деплой и мониторинг — настраиваем alerts на pending tasks и tombstone ratio в Prometheus/Grafana.
Пример из практики
Для time-series таблицы с 1 млрд строк, TTL = 30 дней, мы перешли с LCS на TWCS. Write amplification снизился с 8x до 1.5x, read latency упала на 40%, дисковое потребление сократилось на 30%. Весь процесс занял 2 дня без даунтайма.Что входит в работу
- документация с новыми настройками и рекомендациями,
- мониторинг compaction после изменений (1 неделя поддержки),
- обучение команды: как диагностировать проблемы с compaction,
- доступ к дашборду Grafana с метриками compaction.
Сроки: от 1 до 3 дней в зависимости от количества таблиц и сложности реструктуризации. Оценим проект после аудита — свяжитесь с нами для консультации.
Типичные ошибки при настройке compaction
- Использование STCS для таблиц с частыми delete — накапливаются tombstones.
- Переход на TWCS без предварительного компакта старых SSTables.
- Игнорирование параметра
compaction_throughput_mb_per_sec— оставляют значение по умолчанию. - Применение LCS на write-heavy нагрузке — убивает диск.
Если требуется разобраться с compaction в вашем кластере, напишите нам — проведём аудит и предложим оптимальные настройки под ваш профиль нагрузки. Результат — предсказуемая read latency и снижение дисковых затрат до 40%. Закажите аудит compaction уже сегодня, чтобы избежать простоев. Подробнее о compaction strategies можно прочитать в официальной документации Apache Cassandra.
