Адміністрування Apache Cassandra та ScyllaDB: аудит і підтримка

Cassandra і ScyllaDB — бази даних для завдань, де PostgreSQL та MySQL здаються: мільйони записів на секунду, петабайти даних, нульовий tolerance до downtime. Але ціну за це лінійне масштабування доводиться платити — операційна складність вища на порядок. Ми часто стикаємося з ситуаціями, коли неправильно вибраний partition key або випадковий ALLOW FILTERING у продакшені призводять до деградації кластера. За роки роботи ми виробили методологію, яка запобігає таким сценаріям. Детальніше про Apache Cassandra можна прочитати в офіційній документації.

Ключові відмінності ScyllaDB від Cassandra

ScyllaDB написана на C++ і реалізує shard-per-core архітектуру: кожне ядро CPU обробляє свій власний набір даних без shared state між потоками. Це дає в 10 разів менші p99 latency при тому ж навантаженні порівняно з JVM-based Cassandra. На практиці: те, що потребувало 6 нод Cassandra, на ScyllaDB працює на 2 нодах з кращими показниками.

Cassandra — зрілий продукт з багатою екосистемою, кращою сумісністю з enterprise-інструментами та більш консервативним характером змін. ScyllaDB сумісна з CQL та Cassandra-драйверами, але має свої особливості (наприклад, іншу реалізацію lightweight transactions). Наш досвід показує, що вибір між ними залежить від вимог до latency та щільності нод.

Топологія та конфігурація кластера

Мінімальний production-кластер: 3 ноди з RF=3. Це означає, що кожен partition реплікується на всі три ноди, і втрата однієї ноди не призводить до втрати даних. Рекомендуємо використовувати інстанси з виділеними CPU та SSD для комітлогу.

cassandra.yaml для production-ноди:

---
cluster_name: 'prod-cluster'
num_tokens: 256
seed_provider:
  - class_name: org.apache.cassandra.locator.SimpleSeedProvider
    parameters:
      - seeds: "10.0.1.10,10.0.1.11"
listen_address: 10.0.1.10
rpc_address: 0.0.0.0
broadcast_rpc_address: 10.0.1.10
endpoint_snitch: GossipingPropertyFileSnitch
auto_bootstrap: true
# Compaction
compaction_throughput_mb_per_sec: 64
# Memtable
memtable_allocation_type: offheap_objects
memtable_heap_space_in_mb: 2048
# Commitlog
commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 64
concurrent_reads: 32
concurrent_writes: 32
concurrent_counter_writes: 16

GossipingPropertyFileSnitch використовується в production — він читає cassandra-rackdc.properties для визначення датацентру та стійки:

dc=DC1 rack=RAC1 

Чому важливо правильно вибрати partition key?

Partition key визначає, на якому вузлі зберігаються дані. Якщо ключ вибраний невдало, виникає hot partition — один вузол отримує 80% навантаження, а інші простоюють. Cassandra не реляційна: немає JOIN, немає вторинних індексів у звичному розумінні. Схему проектують під запити, а не під нормалізацію.

Приклад правильної таблиці для зберігання подій з сортуванням за часом:

CREATE TABLE events_by_user (
    user_id UUID,
    event_time TIMEUUID,
    event_type TEXT,
    payload TEXT,
    PRIMARY KEY (user_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC)
    AND compaction = {
        'class': 'TimeWindowCompactionStrategy',
        'compaction_window_size': '1',
        'compaction_window_unit': 'DAYS'
    };

user_id — partition key, дані одного користувача зберігаються разом. event_time — clustering key, визначає порядок всередині партиції. Запит WHERE user_id = ? AND event_time > ? виконується ефективно без ALLOW FILTERING.

Як налаштувати compaction для високого навантаження?

Compactions перепаковують SSTables та видаляють видалені записи. Типова помилка — вибір невірної стратегії. Для часових рядів використовуйте TimeWindowCompactionStrategy (TWCS): вона об'єднує SSTables лише в межах вікна, знижуючи навантаження. Для випадкового доступу — SizeTieredCompactionStrategy (STCS), але слідкуйте за min_threshold (за замовчуванням 4) — занадто часте compacting вбиває IO. Для ScyllaDB додатково налаштовується scylla.yaml:

compaction_static_shares: 0.5 table_compaction_dynamic_shares: true 

Параметр compaction_throughput_mb_per_sec в cassandra.yaml обмежує пропускну здатність compacting. Рекомендуємо виставляти 64-128 MB/s, щоб не обмежувати read/write latency.

Обслуговування кластера: nodetool та моніторинг

nodetool repair — критично важлива операція, яку часто ігнорують. Без регулярного repair anti-entropy дані між репліками розходяться. Запускати раз на gc_grace_seconds (за замовчуванням 10 днів). Використовуйте інкрементальний repair для зниження навантаження:

# Інкрементальний repair — менше навантажує кластер
nodetool repair -inc -pr keyspace_name table_name

# Моніторинг стану нод
nodetool status
nodetool tpstats # thread pool statistics
nodetool compactionstats # поточні compaction задачі

ScyllaDB додає scyllatop — інтерактивний top для моніторингу shard-рівня. Для Prometheus: cassandra-exporter або вбудований JMX exporter для Cassandra, scylla-monitoring стек для ScyllaDB (включає готові Grafana dashboards). Налаштовуємо алерти на p99 latency, compaction backlog та repair status.

ScyllaDB-специфіка

У ScyllaDB немає окремого nodetool repair — натомість scylladb-manager (окремий сервіс) керує repair-завданнями у фоні, розподіляючи навантаження за часом. Це значно зручніше. scylla.yaml має додаткові параметри:

---
# Developer mode (вимкнути в production!)
developer_mode: false

# SMP — кількість потоків (за числом ядер)
smp: 8

# Overprovisioning (для віртуалок)
overprovisioned: false
---

Наведу приклад з нашої практики. На одному з проєктів ми виявили, що через неправильно вибраний partition key один вузол отримував 90% запитів, що спричиняло p99 latency > 5с. Після зміни ключа та оптимізації compaction latency впало до 50ms, а навантаження рівномірно розподілилося.

Що входить в нашу роботу з адміністрування

• Аудит існуючого кластера: аналіз nodetool status, розподіл даних (nodetool tablestats), топ навантажених таблиць, виявлення ALLOW FILTERING у логах, стан compaction.
• Розгортання нового кластера: Ansible-роль для встановлення, налаштування конфігів, ініціалізація seed-нод, створення keyspaces з оптимальним RF, load-тестування через cassandra-stress.
• Передача результатів: повний runbook з інструкціями щодо додавання/заміни нод, розклад repair, конфігурація Prometheus-алертів, навчання команди.
• Гарантія: протягом 30 днів після передачі ми супроводжуємо кластер, виправляємо можливі проблеми. Наш досвід — 10+ років у продакшені, понад 50 успішних проєктів.

Вартість розраховується індивідуально після аудиту вимог до навантаження та об'єму даних. Для консультації та замовлення аудиту зв'яжіться з нами — ми підберемо оптимальний план.

Хочете убезпечити свій кластер? Отримайте консультацію інженера — ми проведемо аудит та дамо рекомендації щодо покращення. Замовте аудит вашого кластера прямо зараз — зв'яжіться з нами для запису.