SQL vs NoSQL: сравнение подходов

(Раздел: Технологии и Инфраструктура)

Краткое резюме

SQL (реляционные БД) — сильная консистентность, ACID-транзакции, богатый язык запросов и джойны. Идеальны для денежных операций и справочников.
NoSQL (документные/колоночные/ключ-значение/графовые) — гибкая схема, горизонтальный масштаб «из коробки», высокая пропускная способность и низкая латентность для узкоспециализированных паттернов (логи, поведенка, кэш, аналитические сканы, лидерборды).

Практика iGaming почти всегда приходит к полиглотной персистентности: SQL для балансов и ордеров, NoSQL для событий/логов/кэшей/поиска/онлайн-аналитики.

Базовые принципы: ACID, BASE, CAP и PACELC

ACID (SQL): атомарность, консистентность, изоляция, долговечность — транзакции со строгими гарантиями.
BASE (часто NoSQL): «Basically Available, Soft state, Eventual consistency» — упор на доступность и горизонтальный скейл, но итоговая согласованность достигается со временем.
CAP: при сетевом сплите выбираем C (консистентность) или A (доступность).
PACELC: при отсутствии сбоев компромисс Latency vs Consistency. Денежные потоки чаще C-ориентированы; телеметрия/логи — L-ориентированы.

Модели данных

• Строгая схема, нормализация, внешние ключи, джойны, представления.
• Богатый SQL (window-функции, CTE, транзакции, триггеры).

• Документные (MongoDB): JSON-документы, гибкая схема, индексы по вложенным полям.
• Колоночные/широкие строки (Cassandra/ScyllaDB): партиционирование по ключу, быстрые записи и сканы по партициям.
• Ключ-значение/кэш (Redis): миллисекундная латентность, структуры данных в памяти.
• Поиск (Elasticsearch/OpenSearch): инвертированные индексы, полнотекст, агрегации.
• Графовые (Neo4j): отношения и пути, рекомендации/anti-fraud-связности.

Транзакции и согласованность

SQL: полнофункциональные транзакции (до Serializable), триггеры, FK-ограничения — надежная инвариантность денег.
Документные NoSQL: транзакции часто ограничены коллекцией/партицией; междокументные — дороже и реже.
Колоночные NoSQL: кворумные записи/чтения (tunable consistency).
Практика iGaming: «деньги и юридически значимые записи» → SQL/CP-решения; «events/metrics/logs/кэши» → NoSQL с идемпотентностью и асинхронной коррекцией.

Масштабирование и производительность

SQL: вертикальный скейл + реплики для чтения, шардинг вручную/через фреймворки; отличная сложная выборка и ад-hoc аналитика на «горячих» наборах.
NoSQL: горизонтальный скейл «первого класса» (shard-by-key, auto-rebalance), высокие TPS на записи/простые чтения; ограниченные джойны/транзакции, проектируйте под запросы заранее.

Схема и эволюция

SQL: строгая схема, миграции (DDL), контроль типов — меньше «мусора», надежные инварианты.
NoSQL: «schema-on-read», гибкие изменения, но требуется дисциплина версий полей, валидаторы и «санитизация» данных.

Язык запросов и индексация

SQL: универсальный язык, сложные агрегации и джойны, богатая оптимизация, вторичные индексы.
NoSQL: язык/DSL отличен от SQL (aggregation pipeline, map/reduce, CQL), индексация специфична к движку; часто нет «общего» джойна — используйте денормализацию и материализацию.

Типовые домены iGaming: что куда

• Кошельки/балансы, платежи, бухгалтерия (строгая согласованность, транзакции).
• KYC/комплаенс-записи, справочники, аутентификация/ACL.
• Бэкофисные отчеты с гарантированной корректностью.

• Стрим событий/логи/клики/вебхуки PSP (высокая запись, партиции по времени/ключу).
• Лидерборды/рейтинги/счетчики в реальном времени (Redis/Cassandra).
• Персонализация и фичи онлайн-ML (ключ-значение + TTL).
• Поиск, рекомендации, антифрод-сигналы (ES/граф).
• Материализованные проекции из стрима (документы под конкретные экраны).

Полиглотная персистентность (рекомендуется)

• Postgres/MySQL — «система записей» для денег и договоров.
• Kafka → ClickHouse/Pinot/Druid — онлайн-аналитика и метрики.
• Redis — кэш балансов, лимитов, токенов; rate-limits.
• Cassandra/Scylla — телеметрия/истории ставок с огромным TPS.
• Elasticsearch — полнотекстовый поиск по играм/провайдерам/тiket-логу.
• MongoDB — гибкие профили/настройки/CRM-карты игрока.

Примеры проектирования

1) Баланс игрока (SQL, транзакции)

sql
BEGIN;
UPDATE wallet SET balance_cents = balance_cents - 5000
WHERE player_id = 123 AND balance_cents >= 5000;
INSERT INTO ledger (player_id, delta_cents, reason, ts)
VALUES (123, -5000, 'bet_stake', now());
COMMIT;

Гарантия инварианта «баланс не уходит в минус», целостная запись в журнал.

2) Лог событий ставок (NoSQL, колоночно)

Схема партиционирования: `partition_key = player_id`, `clustering = event_time DESC`.
Запросы: «последние N событий игрока», «все события за день по игрокам».

3) Лидерборд (Redis, упорядоченные множества)

Ключ: `leaderboard:tournament:2025-11-05`

Команда: `ZINCRBY` при каждой ставке/победе → чтение топ-100 `ZREVRANGE`.

Интеграция с Event Streaming

Outbox из SQL → Kafka → материализация в NoSQL/кэши/поиск.
CDC (Debezium) для обновлений справочников/балансов в реальном времени.
CQRS: команды меняют состояние в SQL; read-модели живут в NoSQL для быстрых экранов.

Операционная перспектива

SQL: зрелые инструменты бэкапов, PITR, строгие права, понятные планы запросов; шардинг требует дисциплины.
NoSQL: легкий горизонтальный рост, но больше ответственности на дизайн ключей и паттернов запросов; бэкапы/восстановление специфичны к движку.

Безопасность и соответствие

SQL проще применять как «источник правды» для аудита/комплаенса (ACID, FK, строгие логи).
В NoSQL обязывают: шифрование, TTL/ретеншн, контроль PII, аудит изменений, валидация схем.

Стоимость и TCO

SQL вертикально может стать дорогим на больших записях; однако экономит время разработки сложных фич.
NoSQL горизонтально дешевле на терабайтах событий и логов, но требует грамотного дизайна и больше DevOps-процедур под конкретный движок.

Миграции и эволюция

Из SQL в NoSQL: начинайте с дублирования событий (outbox→стрим→NoSQL), постепенно переключая чтения на проекции.
Из NoSQL в SQL: выделяйте «ядро правды» (денежные/юридические данные), переносите с валидацией инвариантов и дедупликацией.

Чек-лист выбора

1. Деньги/инварианты/юридическая значимость? → SQL/CP, ACID.
2. TPS на запись и линейный рост? → NoSQL с шардированием.
3. Сложные джойны/ад-hoc аналитика? → SQL или OLAP-СУБД.
4. Лидерборды/кэши/счетчики? → Redis/качественные KV.
5. Поиск/рекомендации/лог-разбор? → Elasticsearch/колоночные.
6. Нужна реальная time-to-insight? → стриминг + материализованные представления.
7. Соблюдение GDPR/локализации? → geo-шардинг и строгая PII-политика независимо от движка.

Антипаттерны

Пытаться «засунуть все» в одну БД (и SQL, и NoSQL) — потеря сильных сторон.
Использовать NoSQL как «реляционку без джойнов» — бесконтрольная денормализация и сложные апдейты.
Делать денежные транзакции в eventual-хранилищах без строгой идемпотентности.
Игнорировать ключ шардирования и горячие партиции.
Отсутствие схем-governance в документных БД → «зоопарк» документов.

Итоги

SQL и NoSQL — не конкуренты, а взаимодополняющие инструменты. Для iGaming надежная стратегия — SQL как источник правды для критичных данных и NoSQL-контуры для скоростных событий, кэшей, поиска и проекций. Добавьте стриминг (outbox+CDC), CQRS, дисциплину схем и ключей шардирования, и вы получите платформу, которая одновременно надежно считает деньги и мгновенно реагирует на поведение игроков.