Шардинг і реплікація баз даних

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

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

Для iGaming-платформ зростання трафіку (ставки, депозити, вебхуки PSP, події ігор) і вимоги до доступності (≈99. 9–99. 99%) швидко впирають в межу однієї БД. Реплікація дає горизонтальне масштабування читання і відмовостійкість; шардинг - горизонтальне масштабування запису і даних. Ключ - усвідомлені компроміси PACELC (після відмови: CA/P, інакше: Latency vs Consistency), чіткі SLO і дисципліна схем/ключів.

Терміни та моделі

Реплікація - копіювання даних між вузлами.

Leader–Follower (Primary–Replica): один запис → багато читань.
Multi-Leader (Active–Active): записи в декількох регіонах, конфлікти/мердж.
Consensus-replication (Raft/Paxos, NewSQL): кворумні записи (Cassandra/Scylla - AP-кворуми, CockroachDB/Yugabyte - CP-кворуми).
Sync / Semi-sync / Async: баланс затримки vs RPO.
Шардинг - горизонтальне розбиття таблиць/ключів по шардах.

Hash-шардинг (рівномірність, складніше діапазони).
Range-шардинг (діапазони ключів, ризик «гарячих» кінців).
Consistent hashing (м'яке додавання/зменшення нод).
Geo-шардинг (по регіону/юрисдикції).
Функціональний шардинг (за доменами: платежі/ставки/CRM).

Коли і що вибирати в iGaming

Тільки реплікація (без шардингу) - коли основна проблема в читанні: стрічки подій, звіти, публічні каталоги. Записи поміщаються в один лідер, читання - з реплік.
Шардинг - коли вузьке місце запису/зберігання: потік ставок, транзакції балансів, тригерні події.

Multi-region:

Латентність до гравців/PSP → локальні читання з реплік.
Регуляторика (локалізація даних) → geo-шардинг.
Міжрегіональний DR → асинхронна репліка + план перемикання.

PACELC та гарантійні властивості

CAP: при мережі-спліті вибираємо C (консистентність) або A (доступність).
PACELC: при відсутності збоїв вибираємо між Latency (L) і Consistency (C).
Грошові шляхи (баланс, списання): зазвичай C-орієнтовані (CP/strict serializable або Serializable + бізнес-ідемпотентність).
Менш критичні підсистеми (лог кліків, каталоги): L-орієнтовані (AP/EC, eventual).

Реплікація: практики

Leader–Follower

Записи → лідер, читання → репліки (read scaling).
Read-after-write: для користувацьких операцій читайте з лідера або чекайте лаг (перевірка'last _ committed _ lsn '/' wait _ for _ replay _ lag').
Semi-sync на критичних шляхах (зниження RPO ціною латентності).
Failover: автоматичний (patroni/raft-координатор) + fencing (щоб не було подвійного лідера).

Multi-Leader

Годиться для розділених доменів і низького конфлікту (напр., контент/налаштування), але не для єдиного рахунку гравця без спеціальних заходів.
Політики мерджа: last-write-wins, CRDT, доменні правила консолідації.

Consensus/Кворумні БД

Запис з кворумом (наприклад, «WRITE QUORUM»), читання з кворумом («READ QUORUM») → сильна/настроюється консистентність.
Враховуйте латентність меж-AZ/регіонів і вартість кворуму.

Шардинг: стратегії та вибір ключа

Як вибрати ключ

Стабільний розподіл по player_id/ account_id/ bet_id.
Уникайте монотонних ключів (auto-increment) в range-шардингу - «гарячий» хвіст.
Для платежів - часто'player _ id'або'account _ id'; для логів -'event _ time'+ bucketing; для контенту -'tenant _ id'.

Стратегії

Hash-шардинг за player_id: баланс на потоці ставок/балансів.
Range-шардинг за часом для аналітики/архівів.
Geo-шардинг: EU-гравці → EU-шард (відповідність локальним законам).
Гібрид: hash всередині регіону + geo за юрисдикцією.

Боротьба з «гарячими» ключами

Key-salting (додавати сіль/bucket до ключа).
Write-throttling по суті, черги комманд (serial executor).
Матеріалізувати «агрегати» (баланс) в окремому сторі з чергою послідовності.

Крос-шардові операції

Грошові переказ/компенсації: уникати 2PC на гарячих шляхах.
Сага-патерн: розбити на локальні транзакції + компенсуючі дії, жорстка ідемпотентність і outbox.
2РС/протоколи коміту: допустимі точково (бек-офісні батчі), але дорогі по латентності і відмовостійкості.
Проекції: читацькі вистави (read models) для міждоменних екранів, що оновлюються зі стріму.

Схеми, індекси та еволюція

Версіонування схеми: міграції з back-compat, feature-flags на коді.
Індекси за ключами шардування і частими запитами; уникати cross-shard join (робіть pre-join/денормалізацію).
Для JSON/док-сховищ - валідуйте схеми (JSON-Schema/Protobuf) і TTL для «галасливих» колекцій.

Онлайн-масштабування та ресхардинг

Плануйте N≫tekushcheye кількість віртуальних шардів (slots) → гнучкий ребаланс.
Consistent hashing або «віртуальні ноди» для м'якого додавання вузлів.

Online-ресхардинг:

подвійний запис (старий + новий шард), валідація консистентності;
фонові копії чанків (logical dump/table move/streaming clone);
перемикання по «маркеру» + вікно спостереження, потім зняття подвійного запису.
Переїзд лідера без простою: перемикання ролей, дренування конекшенів.

SLO, спостережуваність і алертинг

SLO записи/читання: p99 ≤ X мс на гарячих таблицях, допустимий lag реплік ≤ Y секунд, доступність ≥ Z.
Метрики: TPS, p95/p99, replication lag, конфліктність (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency диска.
Трасування: 'trace _ id'в запитах БД, пов'язувати з брокером/шиною подій.
Канарні запити і synthetic transactions для раннього детекту деградацій.

Безпека та відповідність вимогам

Шифрування в спокої і в транзиті (TLS), ротація ключів.
RBAC/ACL, сегментація по доменах/тенантах, окремі кластери для платежів/КУС.
Локалізація даних (EU/TR/LATAM) - поєднуйте geo-шардинг і політки ретенції.
Аудит: хто і що читав/правил; маскування PII; експорт аудиту.

Бекапи, PITR, DR

Повні + інкрементальні бекапи, офсайт-сховище.
PITR (point-in-time recovery) для лідер-кластерів.

RPO/RTO:

Критичні домени (баланс/платіж) - RPO≈0 -30с (semi-sync або частий WAL-шипінг), RTO ≤ хвилини з автоматичним failover.
Менш критичні - RPO до хвилин/годин.
DR-навчання (game day) і документований runbook перемикання.

Продуктивність і тюнінг (коротко)

Пам'ять/кеш: збільшуйте буфери (shared buffers/innodb buffer pool), стежте за cache-hit ≥ 95%.
Журнал/рушій: швидкі NVMe, окремий том під WAL/redo.
Пул з'єднань (PgBouncer/Hikari).
Планувальник/статистика: автованалізу/автовакуум (Postgres), компакція/тюнінг GC (LSM-рушії).
Кворуми/репліка-фактор: баланс між p99 і відмовостійкістю.

Типові топології для iGaming

1) Баланси і платежі (CP-контур)

Leader-Follower в регіоні гравця, semi-sync до близької репліки.
Hash-шардинг по'account _ id'.
Читання «після запису» - з лідера; проекції в Redis для API-latency.
Outbox → шина подій для розрахунків/аналітики.

2) Історія ставок/ігрові події (AP-орієнтований лог)

Range-шардинг за часом або hash по'player _ id'в колонковому/LSM-сховище.
Асинхронні репліки для звітності/OLAP.
Eventual consistency прийнятна, важливіша пропускна здатність.

3) Профілі/CRM (Multi-region read, локалізація)

Geo-шардинг по юрисдикції, локальні репліки для читань.
Записи через найближчий лідер; крос-регіон - асинхронно + вирішення конфліктів тільки для некритичних полів.

Приклади (концептуальні)

Postgres: декларативний шардинг по'player _ id '

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Кворумний запис (псевдо)


WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

Сага замість 2PC (спрощено)

1. Списати депонування на шард-A (idempotent).
2. Відправити подію «знято» → сервіс виплат (шард-B).
3. Якщо крок 2 неуспішний - компенсувати крок 1 подією «повернення».

Чек-лист впровадження

1. Визначте домени даних і SLO (p99, RPO/RTO, лаг реплік).
2. Виберіть модель реплікації (leader/follower, кворум) і стратегію шардингу.
3. Зафіксуйте ключі шардинга і схему (незмінні!).
4. Введіть read-after-write політику і маршрутизацію читань.
5. Спроектуйте online-ресхардінг (віртуальні шарди, подвійний запис).
6. Гарантуйте ідемпотентність і outbox для подій/команд.
7. Налаштуйте бекапи, PITR, DR і регулярні навчання.
8. Увімкніть спостережуваність: лаг, кворуми, гарячі ключі, конфлікти.
9. Документуйте runbook: failover, split-brain, деградації.
10. Проведіть навантажувальні/хаос-тести під матчеві піки.

Антипатерни

Один гігантський шард «на все» і «потім розріжемо».
Крос-шардові join'и на гарячому шляху запиту.
Відсутність політики read-after-write (плаваючі баги).
Міграції схем «ламаючі» ключі шардингу.
Multi-leader для грошових рахунків без суворої резолюції конфліктів.
Немає PITR/DR - неможливо відновитися після логічної помилки.

Підсумки

Реплікація вирішує читання і відмовостійкість, шардинг - записи і обсяг. Успішна архітектура в iGaming - це чіткі SLO і PACELC-компроміси, стабільні ключі шардингу, мінімум крос-шардової координації (сага замість 2PC), дисципліна read-after-write, налагоджений online-ресхардинг і регулярні DR-навчання. Такий підхід масштабується під піки турнірів, витримує регуляторні обмеження щодо локалізації даних і залишається передбачуваним в експлуатації.