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: що куди

• Гаманці/баланси, платежі, бухгалтерія (сувора узгодженість, транзакції).
• КУС/комплаєнс-записи, довідники, аутентифікація/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→strim→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, дисципліну схем і ключів шардування, і ви отримаєте платформу, яка одночасно надійно рахує гроші і миттєво реагує на поведінку гравців.