데이터베이스 파쇄 및 복제

(섹션: 기술 및 인프라)

간단한 요약

iGaming 플랫폼, 트래픽 증가 (베팅, 예금, PSP 웹 후크, 게임 이벤트) 및 가용성 요구 사항 (약 99. 9–99. 99%) 는 빠르게 하나의 DB 한계에 도달했습니다. 복제는 수평 판독 스케일링 및 내결함성을 제공합니다. 샤딩 - 레코드 및 데이터의 수평 스케일링. 핵심은 PACELC (실패 후: CA/P, 그렇지 않으면 Latency vs Consistency), 명확한 SLO 및 제도/핵심 분야의 의식적인 타협입니다.

이용 약관

복제-사이트 간 데이터를 복사합니다.

Leader-Follower (1 차 복제본): 하나의 항목 → 많은 읽기.
다중 리더 (Active-Active): 여러 지역의 항목, 충돌/병합.
합의 복제 (Raft/Paxos, NewSQL): 쿼럼 레코드 (Cassandra/Scylla-AP 쿼럼, CockroachDB/Yugabyte-CP 쿼럼).
동기화/반동기/동기화: 지연 밸런스 대 RPO.
샤딩 - 파편으로 테이블/키를 수평으로 나눕니다.

해시 샤딩 (균일 성, 단단한 범위).
레인지 샤딩 (키 범위, 핫 엔드 위험).
일관된 해싱.
지역/관할권별로 (Geo-sharding).
기능적 샤딩 (도메인 별: 지불/요금/CRM).

iGaming에서 언제 무엇을 선택해야합니까?

주요 문제가 읽히는 경우: 이벤트 피드, 보고서, 공개 디렉토리. 레코드는 하나의 리더에 배치되며 복제본에서 읽습니다.
샤딩-쓰기/보류 병목 현상: 요율 흐름, 대차 대조표 거래, 이벤트 트리거.

다중 지역:

Player/PSP 대기 시간 → 복제본에서 로컬 읽기.
규제 (데이터 현지화) → 지오 샤딩.
지역 간 DR → 비동기 복제본 + 전환 계획.

PACELC 및 보증 속성

CAP: 분할 네트워크를 사용하면 C (일관성) 또는 A (가용성) 를 선택하십시오.
PACELC: 실패가없는 경우 Latency (L) 와 Consistency (C) 중에서 선택하십시오.
현금 방법: 일반적으로 C 지향 (CP/엄격한 직렬화 가능 또는 직렬화 가능 + 비즈니스 demempotency).
덜 중요한 하위 시스템 (로그 클릭, 디렉토리): L 지향 (AP/EC, 최종).

복제 관행

리더 추종자

→ 리더를 작성하고 읽으며 → 읽기 스케일링을 읽습니다.
쓰기 후 읽기: 사용자 작업의 경우 리더에서 읽거나 지연을 기다립니다 ('last _ cumded _ lsn '/' wait _ for _ replay _ lag' 확인).
임계 경로에서의 반동기 (대기 시간 비용으로 RPO 감소).
실패: 자동 (patroni/raft 코디네이터) + 펜싱 (이중 리더가 없도록).

멀티 리더

분할 도메인 및 낮은 충돌에 적합합니다 (예: 콘텐츠/설정) 이지만 특별한 조치가없는 단일 플레이어 계정에는 해당되지 않습

병합 정책: 마지막 쓰기, CRDT, 도메인 통합 규칙.

컨센서스/쿼럼 데이터베이스

정원 쓰기 (예: 'WRITE QUORUM'), 쿼럼 읽기 ('READ QUORUM') → 강력/구성 가능한 일관성.
AZ/지역 간 대기 시간 및 쿼럼 비용을 고려하십시오.

샤딩: 전략과 주요 선택

키를 선택하는 방법

(PHP 3 = 3.0.6, PHP 4)

레인지 샤딩- "핫" 테일에서 단조로운 키 (자동 증가) 를 피하십시오.
결제 - 종종 'player _ id' 또는 'play _ id'; 로그- '이벤트 _ time' + 버켓 팅; 콘텐츠- '테넌트 _ id'.

전략

플레이어 _ id에 의한 해시 샤딩: 속도/균형의 흐름에 대한 균형.
분석/아카이브를위한 범위 기반 시간 기반 샤딩.
Geo-sharding: EU 플레이어 → EU-shard (현지 법률 준수).
하이브리드: 관할권별로 지역 + 지역 내 해시.

뜨거운 키 싸움

키 소금 (키에 소금/버킷을 추가).
쓰기 조절은 본질적으로 명령 대기열 (직렬 집행자) 입니다.
시퀀스 큐가있는 별도의 행에서 "집계" (밸런스) 를 재료화합니다.

크로스 샤드 작업

송금/보상: 핫 트랙에서 2PC를 피하십시오.
사가 패턴: 로컬 트랜잭션 + 보상 조치, 하드 dempotence 및 아웃 박스로 나뉩니다.
2PC/커밋 프로토콜: 허용 가능한 포인트 (백 오피스 배치) 이지만 대기 시간 및 내결함성이 비쌉니다.
투영: 스트림에서 업데이트 된 도메인 간 화면에 대한 모델을 읽으십시오.

계획, 지수 및 진화

스키마 버전 지정: 백 컴파트에서 마이그레이션, 코드의 기능 플래그.
샤딩 키 및 빈번한 쿼리에 대한 색인; 크로스 샤드 조인을 피하십시오 (사전 결합/비정규화).
JSON/도킹 스토리지의 경우 "잡음" 컬렉션의 유효성 검사 체계 (JSON-Schema/Proto) 및 TTL입니다.

온라인 스케일링 및 재 하딩

N "tekushcheye에 가상 파편 (슬롯) → 유연한 재조정 횟수를 계획하십시오.
소프트 노드 추가를위한 일관된 해싱 또는 "가상 노드".

온라인 재편성:

이중 항목 (구 + 새 파편), 일관성 검증;
덩어리의 배경 사본 (논리 덤프/테이블 이동/스트리밍 클론);
"마커" + 관찰 창으로 전환 한 다음 이중 레코드.
다운 타임없이 리더를 이동: 역할 전환, 연결 해제.

SLO, 관찰 및 경고

SLO 쓰기/읽기: 핫 테이블에서 p99

메트릭: TPS, p95/p99, 복제 지연, 다중 리더, 재 시도 속도, 교착 상태, 잠금 대기, 캐시 적중률, IOPS/대기 시간 디스크.

추적: 데이터베이스 요청에서 'trace _ id', 브로커/이벤트 버스와 연계

분해의 조기 탐지를위한 카나리아 쿼리 및 합성 트랜잭션.

보안 및 준수

휴식 시간과 대중 교통에서의 암호화, 키 회전.
도메인/테넌트별로 세분화 된 RBAC/ACL은 지불/LCC를위한 별도의 클러스터입니다.
데이터 현지화 (EU/TR/LATAM) -지오 샤딩 및 보존 정책을 결합합니다.
감사: 누구와 무엇을 읽고/규칙하는지; PII 마스킹; 감사 수출.

백업, PITR, DR

전체 + 증분 백업, 오프 사이트 스토리지.
리더 클러스터의 PITR (포인트 인 타임 복구).

RPO/RTO:

중요 도메인 (밸런스/결제) - RPO
덜 중요한-최대 시간/시간까지 RPO.
DR 연습 (게임 데이) 및 문서화 된 스위치 런북.

성능 및 튜닝 (간단한)

메모리/캐시: 버퍼 (공유 버퍼/무고한 버퍼 풀) 를 늘리고 캐시 적중률을 95% 이상 모니터링하십시오.
매거진/엔진: 빠른 NVMe, WAL/redo에서 별도의 볼륨.
연결 풀 (PgBouncer/Hikari).
계획자/통계: 자동 분석/자동 진공 (Postgres), GC 압축/튜닝 (LSM 엔진).
정원/복제 계수: p99와 내결함성의 균형.

iGaming의 전형적인 토폴로지

1) 밸런스 및 결제 (CP- 루프)

플레이어 영역의 리더-추종자, 가까운 복제본과 반 동기화.
'계정 _ id' 에 의한 해시 샤딩.
"쓰기 후" 읽기 - 리더로부터; API 대기 시간에 대한 Redis 투영.
계산/분석을위한 이벤트 버스를 전송합니다.

2) 베팅 기록/게임 이벤트 (AP 지향 로그)

열/LSM 스토리지에서 'player _ id' 로 시간별 레인지 샤딩 또는 해시.
보고/OLAP에 대한 비동기 복제본.
최종 일관성이 허용되며 대역폭이 더 중요합니다.

3) 프로필/CRM (다중 지역 읽기, 현지화)

관할권 별 지역 독서 복제품.
가장 가까운 지도자를 통한 출품작; 교차 지역-비 임계 필드에 대해서만 비동기적으로 + 충돌 해결.

예 (개념)

후보: '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 (demempotent) 에 기록하십시오.
2. 이벤트 "제거" → 결제 서비스 (shard-B) 를 보내십시오.
3. 단계 2가 실패하면 "반환" 이벤트로 단계 1을 보상하십시오.

구현 점검표

1. 데이터 도메인 및 SLO (p99, RPO/RTO, 레플리카 로그) 를 정의하십시오.
2. 복제 모델 (리더/팔로어, 쿼럼) 및 샤딩 전략을 선택하십시오.
3. 날카로운 키와 구성표를 수정하십시오 (불변의!).
4. 읽기 후 정책을 입력하고 읽기 라우팅을 입력하십시오.
5. 온라인 리샤 딩 설계 (가상 파편, 이중 입력).
6. 이벤트/명령에 대한 demotency 및 Outbox를 보장하십시오.
7. 백업, PITR, DR 및 정기적 인 운동을 설정하십시오.
8. 관찰 가능성 포함: 지연, 쿼럼, 핫 키, 충돌.
9. 문서 런북: 장애, 분할 뇌, 분해.
10. 일치 피크에서로드/카오스 테스트를 수행하십시오.

반 패턴

"모든 것을위한" 그리고 "잘라낸" 거대한 파편.
크로스 샤드 가입은 요청의 뜨거운 방식으로 이루어집니다.
쓰기 후 읽기 정책 (플로팅 버그) 이 없습니다.
날카로운 키 "파괴" 체계의 마이그레이션.
엄격한 충돌 해결없이 현금 계좌의 다중 리더.
PITR/DR 없음-논리적 오류에서 복구 할 수 없습니다.

결과

복제는 읽기와 복원력을 해결하고 날카롭게하면 쓰기와 볼륨을 해결합니다. iGaming의 성공적인 아키텍처는 명확한 SLO 및 PACELC 타협, 안정적인 샤딩 키, 최소한의 크로스 샤드 조정 (2PC 대신 사가), 읽기 후 규율, 잘 작동하는 온라인 리샤딩 및 정기적 인 DR 연습입니다. 이 접근 방식은 토너먼트 피크로 확장되며 데이터 현지화에 대한 규제 제한을 견뎌내며 예측 가능한 상태로 유지됩니다.