データベースの共有とレプリケーション

（セクション： 技術とインフラ）

簡単な要約

iGamingプラットフォームの場合、トラフィックの増加（賭け、預金、PSPのWebhook、ゲームイベント）および可用性の要件（≈99。9–99.99％）すぐに1つのDBの限界を打ちました。レプリケーションは、水平読み取りスケーリングとフォールトトレランスを提供します。sharding-レコードとデータの水平スケーリング。重要なのは、PACELCの意識的な妥協点（失敗後：CA/P、そうでなければLatencyとConsistency）、明確なSLO、スキーム/キー規律です。

利用規約とモデル

「レプリケーション」（Replication）-サイト間でデータをコピーします。

Leader-Follower （Primary-Replica）： 1つのエントリ→多くの読み取り。
Multi-Leader （Active-Active）：複数のリージョンのエントリ、競合/マージ。
コンセンサス複製（Raft/Paxos、 NewSQL）： quorum records （Cassandra/Scylla-AP quorums、 CockroachDB/Yugabyte-CP quorums）。
Sync/Semi-Sync/Async：遅延残高とRPO。
シャーディング-シャードによるテーブル/キーの水平分割。

ハッシュシャーディング（均一性、ハード範囲）。
レンジシャーディング（キーレンジ、ホットエンドリスク）。
一貫したハッシュ。
ジオシャーディング（地域/管轄）。
機能的なシャーディング（ドメイン別：支払/レート/CRM）。

いつ、何をiGamingで選択するか

レプリケーションのみ（シャーディングなし）-イベントフィード、レポート、パブリックディレクトリなど、主な問題が読み込まれている場合。レコードは1つのリーダーに配置され、レプリカから読み取ります。
シャーディング-ボトルネックの書き込み/保持：レートフロー、バランスシートのトランザクション、イベントのトリガー。

複数の地域：

プレーヤー/PSPレイテンシー→ローカルはレプリカから読み取ります。
規制（データローカライズ）→ジオシャーディング。
地域間DR→非同期レプリカ+スイッチオーバープラン。

PACELCおよび保証の特性

CAP：分割ネットワークで、C（整合性）またはA（可用性）を選択します。
PACELC：失敗がない場合は、レイテンシ（L）とコンシステンシー（C）を選択します。
現金の方法：通常C指向（CP/strict serializableまたはSerializable+business idempotency）。
重要度の低いサブシステム（ログクリック、ディレクトリ）：L指向（AP/EC、最終的な）。

レプリケーション・プラクティス

リーダー・フォロワー

Writing→leader、 reads、→read scaling。
Read-after-write：ユーザー操作の場合、リーダーから読み取るか、遅延を待ちます（'last_committed_lsn'/'wait_for_replay_lag'をチェックします）。
クリティカルパスのセミシンク（レイテンシのコストでのRPO削減）。
フェイルオーバー：自動（パトロニ/いかだコーディネーター）+フェンシング（ダブルリーダーがないように）。

マルチリーダー

スプリットドメインと低い競合に適しています（例：コンテンツ/設定）、しかし特別な措置なしで単一のプレーヤーアカウントのためではありません。
ポリシーのマージ：last-write-wins、 CRDT、ドメイン統合ルール。

コンセンサス/クォーラムデータベース

Quorum書き込み（例：'WRITE QUORUM'）、 quorum read （'READ QUORUM'）→strong/configurable consistency。
AZ/リージョン間のレイテンシとクォーラムコストを考慮してください。

シャーディング： 戦略と主な選択肢

キーの選び方

player_id/ account_id/ bet_idによる安定した分布。
range-sharding-「hot」テールの単調なキー（自動増分）は避けてください。
支払いの場合-多くの場合'player_id'または'account_id'；ログ-'event_time'+bucketing；コンテンツ-'tenant_id'。

ストラテジー

player_idによるハッシュシャーディング：レート/バランスの流れのバランス。
分析/アーカイブ用のレンジベースのタイムベースのシャーディング。
ジオシャーディング：EUプレーヤー→EUシャード（現地法の遵守）。
ハイブリッド：管轄区域内のハッシュ+地理。

ホットキーを戦う

キー塩化（キーに塩/バケツを追加）。
Write-slottlingは基本的にコマンドキュー（シリアル実行者）です。
シーケンスキューで別の行に「集計」（バランス）を実現します。

クロスシャードオペレーション

送金/補償：ホットトラックでの2PCは避けてください。
佐賀パターン：ローカルトランザクションに分割+補償アクション、ハードidempotenceとアウトボックス。
2PC/commitプロトコル：許容ポイント（バックオフィスのバッチ）、しかしレイテンシとフォールトトレランスで高価。
投影：クロスドメイン画面のモデルを読み込み、ストリームから更新します。

スキーム、インデックス、進化

スキーマバージョニング：バックコンパットからの移行、コード上のフィーチャーフラグ。
シャーディングキーと頻繁なクエリに関するインデックス；クロスシャードジョインを避けます（事前参加/非正規化を行います）。
JSON/ドッキングストレージの場合、スキーム（JSON-Schema/Protobuf）とTTLを「ノイズの多い」コレクションに検証します。

オンラインスケーリングと再ハーディング

Nに計画≫ tekushcheye仮想シャードの数（スロット）→柔軟なリバランス。
ソフトノード追加のための一貫性のあるハッシュまたは「仮想ノード」。

オンラインリシェーディング：

ダブルエントリ（古い+新しいシャード）、整合性検証；
チャンクのバックグラウンドコピー（論理ダンプ/テーブル移動/ストリーミングクローン）；
「marker」+observationウィンドウで切り替え、ダブルレコードします。
ダウンタイムなしでリーダーを移動：役割の切り替え、接続の消耗。

SLO、 Observability、アラート

SLO書き込み/読み取り：ホットテーブル上のp99 ≤ Xミリ秒、有効なラグレプリカ≤ Y秒、Z ≥可用性。
メトリクス：TPS、 p95/p99、レプリケーションラグ、マルチリーダー、再試行率、デッドロック、ロック待ち、キャッシュヒット比、IOPS/レイテンシディスク。
トレース：データベースリクエストの'trace_id'、ブローカー/イベントバスに関連付けます。
劣化の早期検出のためのカナリアクエリと合成トランザクション。

セキュリティとコンプライアンス

安静時および通過時の暗号化（TLS）、キー回転。
RBAC/ACL、ドメイン/テナントによるセグメンテーション、決済/LCCのための個別のクラスタ。
データのローカライゼーション（EU/TR/LATAM）-ジオシャーディングと保持ポリシーを組み合わせます。
監査：誰と読む/ルール；PIIのマスキング；監査のエクスポート。

バックアップ、PITR、 DR

リーダー・クラスタのPITR（ポイント・イン・タイム・リカバリ）

フル+インクリメンタルバックアップ、オフサイトストレージ。

RPO/RTO：

重要なドメイン（残高/支払い）-RPO≈0 -30（セミシンクまたは頻繁なWAL配送）、RTOは自動フェイルオーバーで≤分です。
重要度が低い-RPOは最大数分/時間。
DR演習（ゲームの日）と文書化されたスイッチランブック。

パフォーマンスとチューニング（短い）

メモリ/キャッシュ：バッファ（共有バッファ/innodbバッファプール）を増やし、キャッシュヒットを95％ ≥監視します。
雑誌/エンジン：高速NVMe、 WAL/やり直しの下で別のボリューム。
接続プール（PgBouncer/Hikari）。
プランナー/統計：自動分析/自動真空（Postgres）、 GC圧縮/チューニング（LSMエンジン）。
クォーラム/レプリカ係数：p99とフォールトトレランスのバランス。

iGamingの典型的なトポロジー

1）残高と支払い（CPループ）

プレイヤーの領域のリーダー-フォロワー、近いレプリカにセミシンク。
'account_id'によるハッシュ共有。
読み取り「書き込み後」-リーダーから；projections to Redis for API-latency。
計算/分析のためのOutbox→イベントバス。

2）賭け履歴/ゲームイベント（AP指向ログ）

カラム/LSMストレージの'player_id'による時間またはハッシュによる範囲共有。
レポート/OLAPの非同期レプリカ。
最終的な整合性は許容可能であり、帯域幅はより重要です。

3）プロファイル/CRM（マルチリージョン読み取り、ローカライズ）

管轄によってジオシャーディング、読み取りのためのローカルのレプリカ。
最寄りのリーダーを介してエントリ；クロスリージョン-非クリティカルなフィールドのみ非同期+競合解決。

例（概念）

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.shard-A （idempotent）にデポジットを書き込みます。
2.イベント「削除」→決済サービス（shard-B）を送信します。
3.ステップ2が失敗した場合、ステップ1を"return'イベントで補償します。

実装チェックリスト

1.データドメインとSLO （p99、 RPO/RTO、レプリカログ）を定義します。
2.レプリケーションモデル（リーダー/フォロワー、クォーラム）とシャーディング戦略を選択します。
3.シャーディングキーとスキーム（不変！）を修正しました。
4.read-after-writeポリシーとread routingと入力します。
5.オンラインリシェーディング（バーチャルシャード、ダブルエントリ）を設計します。
6.イベント/コマンドのidempotencyとoutboxを確認します。
7.バックアップ、PITR、 DR、通常の演習を設定します。
8.観測性を含める：ラグ、クォーラム、ホットキー、競合。
9.ドキュメントランブック：フェイルオーバー、スプリットブレイン、劣化。
10.マッチピークの下でロード/カオステストを実行します。

アンチパターン

1つの巨大なシャード「すべてのために」そして「カット」。
クロスシャードジョインはリクエストのホットな方法です。
読み書きポリシー（フローティングバグ）がありません。
スキームの移行「破る」シャーディングキー。
厳格な紛争解決なしの現金口座のマルチリーダー。
No PITR/DR-論理エラーから回復できません。

［結果］

Replicationは読み取りと回復力を解決し、shardingは書き込みとボリュームを解決します。iGamingの成功したアーキテクチャは、明確なSLOとPACELCの妥協、安定したシャーディングキー、最小のクロスシャードコーディネート（2PCではなくSaga）、読み書きの規律、十分に機能するオンラインレッシングおよび通常のDR演習です。このアプローチは、トーナメントのピークまで拡大し、データのローカライズに関する規制に耐え、運用中も予測可能です。