Вибір та налаштування Cassandra Compaction Strategies
Ми налаштовуємо Cassandra compaction під ваші дані — не обираємо стратегію «на око», а аналізуємо профіль навантаження, TTL, частоту оновлень та розміри SSTables. Неправильний вибір стратегії призводить до деградації read latency у 2–3 рази, переповнення диска та TombstoneOverwhelmingException. Наша команда має 5+ років досвіду з Apache Cassandra (сертифіковані фахівці) та понад 30 проєктів з оптимізації продуктивності. За 1–3 дні ми проведемо аудит, підберемо стратегію (STCS, LCS, TWCS) та виконаємо зміну без даунтайму — гарантуємо зниження latency на 20-40%.
Як вибрати стратегію компактифікації?
STCS, LCS та TWCS — три основні механізми, кожен зі своєю фізикою. STCS об'єднує SSTables схожого розміру при накопиченні порогу (за замовчуванням 4). Write amplification мінімальний (1.5x), але read страждає через безліч розрізнених SSTables. LCS розкладає дані по рівнях: кожне читання торкається не більше одного SSTable на рівень, що дає відмінну read performance ціною десятикратного write amplification (до 10x). TWCS спроєктований для time-series: розбиває дані на часові вікна та фіналізує кожне вікно, а при завершенні TTL цілком видаляє SSTable — без перевірки кожного рядка. Для вибору стратегії важливо враховувати вплив на продуктивність Cassandra: STCS має на 70% нижчий write amplification ніж LCS.
Порівняльна таблиця стратегій
| Характеристика | STCS | LCS | TWCS |
|---|---|---|---|
| Write amplification | Низький (1.5x) | Високий (~10x) | Низький (1.5x) |
| 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. Ми допомагаємо налаштувати кожну таблицю індивідуально. Вибір правильної стратегії ущільнення (STCS, LCS, TWCS) критично впливає на продуктивність Cassandra: write amplification, read performance та управління tombstones.
Чому compaction відстає?
Команда nodetool compactionstats показує pending tasks. Якщо вони зростають — compaction не встигає за writes. Короткострокове рішення: збільшити compaction_throughput_mb_per_sec до 64–128 МБ/с (залежить від дискової підсистеми). Довгострокове — переглянути стратегію або додати ноди. Типова помилка — тримати default для SSD (16 МБ/с), що призводить до зростання read latency. Ми у своїй практиці підіймали throughput до 200 МБ/с на NVMe без втрати стабільності.
Вплив tombstone на read latency
Tombstones — мітки про видалення рядків. При читанні партиції Cassandra сканує всі SSTables, збираючи живі дані та ігноруючи tombstones. Якщо їх багато (наприклад, при частих DELETE без своєчасної компактифікації), latency зростає. TWCS вирішує цю проблему для time-series: прострочені SSTables видаляються цілком, не залишаючи tombstones. Для інших випадків допомагає налаштування gc_grace_seconds та вибір правильної стратегії.
| Сценарій | Рекомендована стратегія | Причина |
|---|---|---|
| High write, no deletes | STCS | Низький write amplification (1.5x) |
| Read-intensive, updates | LCS | Мінімальна кількість SSTables на читання |
| Time-series, TTL | TWCS | Автоматичне видалення прострочених SSTables |
Процес роботи: від аудиту до деплою
- Аудит — аналізуємо
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 дні без даунтайму. Економія на дисках становила $200 на місяць на ноду. Вартість аудиту compaction від 500 доларів.Що входить в роботу
- документація з новими налаштуваннями та рекомендаціями,
- моніторинг 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.
