ScyllaDB¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: ScyllaDB 2025.1; отдельно vnode keyspace и tablets. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. CQL/wide-column модель похожа на Cassandra, но реализация shard-per-core на Seastar назначает работу ядрам и управляет I/O собственным reactor. Совместимый протокол не означает идентичность всех CQL features, compaction, topology и consistency ограничений. Здесь baseline 2025.1; различаем vnode keyspaces и tablets.

flowchart LR
  Driver --> Routing[Token and shard routing]
  Routing --> S1[Owner shard core]
  Routing --> S2[Other owner shard]
  S1 --> LSM[Commit log memtable SSTable]
  S2 --> LSM2[Shard-local commit log memtable SSTable]

2. Физическое хранение и путь записи¶

Commit log, memtables, SSTables и compaction образуют LSM write path; owner shard обрабатывает данные с минимизацией shared locking. Remote shard forwarding, распределение CPU и I/O scheduling влияют на tail latency. Нельзя выводить производительность конкретного workload из общей фразы shard-per-core: нужны профиль ключей, mutation sizes и нагрузка compaction.

Источники механизма: документация 4.

3. Индексы и путь чтения¶

Partition/clustering keys задают маршрутизацию и диапазон; query-driven tables остаются основным инструментом. Secondary indexes/materialized views имеют собственный write и consistency path; переносить из Cassandra ограничения/поддержку автоматически нельзя. Для event history эффективный запрос содержит полный partition key и bounded clustering range.

4. Транзакции и consistency guarantees¶

CL ONE/QUORUM/LOCAL_QUORUM управляют количеством ответов replicas; обычная запись не превращается в consensus на каждую операцию из-за присутствия Raft. Критичное ограничение 2025.1: документация LWT прямо запрещает LWT в keyspaces с включёнными tablets. Для vnode keyspaces LWT conditional statements используют Paxos; scope и SERIAL/LOCAL_SERIAL проверяют отдельно.

Raft-based topology updates — согласование metadata, а не обещание serializable бизнес-транзакций всех пользовательских таблиц. Эта разница существенна при выборе между elastic tablets и conditional uniqueness.

Источники механизма: документация 1, документация 2.

5. Репликация, partitioning и sharding¶

Vnodes распределяют token ranges; tablets добавляют более мелкую единицу распределения и балансировки в поддерживаемых конфигурациях. Выбор topology mode фиксируется при проектировании keyspace и влияет на доступные возможности baseline. Реплики размещают с учётом DC/rack, а bootstrap/rebalance потребляют сеть и I/O. Изоляция отказов требует настоящих fault domains.

Источники механизма: документация 5.

6. Конкурентная запись и конфликты¶

Last-write-wins по timestamps имеет те же классы бизнес-рисков, что и другие timestamp-based модели: устаревшая команда с большим timestamp может перекрыть корректную. Использовать immutable events или явно версионированный протокол. LWT имеет цену координации и в 2025.1 требует подходящего keyspace; не добавлять IF NOT EXISTS в tablets-пример как якобы универсальное решение.

Источники механизма: документация 1.

7. Отказы и восстановление¶

Local commit log recovery не заменяет repair replicas. После timeout нельзя считать write неуспешным; retries должны сохранять идентичность данных. Tombstone safety зависит от repair и GC policy. ScyllaDB имеет собственные настройки tombstone GC; не копировать Cassandra gc_grace рекомендации без проверки режима и версии.

Runbook восстановления: оценить доступность replica quorum → fence/replace узел по штатной процедуре → stream/repair → проверить полноту partition ranges и retention. Snapshot без manifest/schema/topology-инструкции недостаточен для готового DR.

Источники механизма: документация 3, документация 4.

8. Масштабирование и ограничения¶

Распределять активную нагрузку по partitions и cores, избегать единственного celebrity player key. Tablets улучшают балансировку, но не дают бесконечный throughput одному логическому ключу. Oversized partitions и большие cells увеличивают работу reactor и очереди; capacity planning учитывает maintenance при потере узла.

9. Performance trade-offs¶

Compaction strategy выбирать по чтению, overwrite rate, TTL и I/O budget; названия общих стратегий не гарантируют идентичность реализации Cassandra. CPU-bound workload может выиграть от shard-local processing; сеть, fsync или hot key останутся ограничителями. Разделять клиентскую p99 и shard-level stalls в измерениях, не задавая вымышленных значений.

10. Мониторинг и эксплуатация¶

Scylla Monitoring, per-shard CPU, reactor stalls, I/O queue, cache hit, compaction backlog, dropped requests, repair age и disk headroom. Согласовать driver topology awareness и retry/speculative policies; speculative requests могут увеличить перегрузку. Rolling upgrade выполнять по поддерживаемому пути с проверкой keyspace modes и feature availability.

11. Сценарии FinTech и iGaming¶

INFERENCE. Append-heavy per-player/per-device event history с предсказуемым доступом и bounded retention. Тот же walkthrough D использует общий поднабор CQL; его настройка tablets/LWT намеренно отделена. Потенциальную выгоду относительно Cassandra определяет эксперимент с одинаковой моделью и durability settings.

12. Когда не выбирать¶

Не выбирать только по обещанию «быстрее Cassandra». Для multi-row ledger и произвольного SQL это другая модель. Если нужен LWT вместе с tablets именно на 2025.1, требования несовместимы в этом baseline: изменить дизайн, topology mode или отдельно исследовать другую версию.

13. Вопросы на собеседовании¶

Почему Raft topology не даёт serializable UPDATE? Metadata consensus и пользовательский write path — разные протоколы.

Есть ли LWT в tablets keyspace 2025.1? Нет по документации выбранной ветки; нельзя переносить поддержку из другого релиза.

Можно ли переносить CQL schema без теста? Даже совместимый синтаксис не доказывает одинаковые defaults, indexes, operational costs и recovery.

14. Практические SQL/config примеры¶

events.cql использует базовый partitioned event model, без LWT и tablets-specific DDL. Перед deployment выбрать replication/topology и проверить compaction options на ScyllaDB 2025.1. Конфигурация не прошла server runtime validation. Практика: найти hot shard при skew и сравнить bucket/shard layout, сохраняя одинаковый запрос.

15. Дополнительные источники¶

Политика версий и ограничений: реестр.

Типичные ошибки проектирования¶

Переносить Cassandra defaults; путать Raft metadata с data consistency; использовать LWT в tablets keyspace 2025.1; не учитывать per-shard skew.

Практические упражнения¶

Сравните vnode и tablets keyspace для требований LWT и rebalance baseline 2025.1. Запишите несовместимые требования и вариант переработки.