Администрирование 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
---

Что входит в нашу работу по администрированию

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

Стоимость рассчитывается индивидуально после аудита требований к нагрузке и объёму данных. Для консультации и заказа аудита свяжитесь с нами — мы подберём оптимальный план.

Хотите обезопасить свой кластер? Получите консультацию инженера — мы проведём аудит и дадим рекомендации по улучшению. Закажите аудит вашего кластера прямо сейчас — свяжитесь с нами для записи.