מסד נתונים שארדינג ושכפול

(סעיף: טכנולוגיה ותשתיות)

סיכום קצר

עבור פלטפורמות iGaming, צמיחת תנועה (הימורים, מרבצים, ספרי אינטרנט של PSP, אירועי משחק) ודרישות זמינות (text 99). 9–99. 99%) הגיע במהירות לגבול של DB אחד. השכפול מספק סבילות לקריאה אופקית; שריטה - סולם אופקי של שיא ונתונים. המפתח הוא הפשרות המודעות של PACELC (לאחר כישלון: CA/P, אחרת: Latency vsistency), SLOs ברור ו-scheme/key discipline.

תנאים ומודלים

העתק של נתונים בין אתרים.

Leader-Follower (ראשי תיבות של Primary-Recplice): רישום אחד = = קריאות רבות.
Multi-Leader (Active-Active): רשומות במספר אזורים, קונפליקטים/מיזוג.
שכפול קונסנזוס (Raft/Paxos, NewSQL): רשומות קוורום (Cassandra/Sylla - AP quorums, CockroachDB/Yugabyte - CP quorums).
סינכרון/סינכרון למחצה/Async: שיווי משקל השהייה נגד RPO.
חלוקה אופקית של טבלאות/מפתחות בשברים.

Hash-sharding (אחידות, טווח קשה יותר).
Range-sharding (טווח מפתח, סיכון קצה חם).
חשיש עקבי.
Geo-sharding (על ידי אזור/תחום שיפוט).
חדירה פונקציונלית (על ידי תחום: תשלומים/תעריפים/CRM).

מתי ומה לבחור ב ־ iGaming

שכפול בלבד - כאשר הבעיה העיקרית היא קריאה: הזנות אירועים, דיווחים, ספריות ציבוריות. רשומות ממוקמות במנהיג אחד, קורא משכפלים.
שריטה - כאשר צוואר בקבוק לכתוב/להחזיק: זרימת קצב, עסקאות יריעת מאזן, אירועי הפעלה.

אזור מרובה:

Player/PSP latency # local reads מתוך העתקים.
רגולציה (לוקליזציה של נתונים) * geo-sharding.
DR asynchronous העתק + תוכנית החלפה.

PACELC ונכסי אחריות

CAP: עם רשת מפוצלת, בחר C (עקביות) או A (זמינות).
אם אין כשלים, בחר בין Latency (L) לבין עקביות (C).
דרכי מזומנים: בדרך כלל מונחה C (CP/strict serializable או Serializable + adempotency).
תת-מערכות פחות קריטיות (לחיצות לוג, ספריות): מוכוונות L (AP/EC, בסופו של דבר).

שיטות שכפול

מנהיג-חסיד

כותב lough מוביל, קורא, לקרא את המדד.
קריאה לאחר כתיבה: עבור פעולות המשתמש, קרא מהמנהיג או המתן ללאג (check 'last _ died _ lsn'/' wait _ for _ replay _ lag').
סנכרון למחצה במסלולים קריטיים (הפחתת RPO במחיר של latency).
כשל: אוטומטי (מתאם פטרוני/רפסודה) + גידור (כך שאין מנהיג כפול).

רב ־ מנהיגName

מתאים לתחומים מפוצלים וקונפליקט נמוך (למשל תוכן/הגדרות), אבל לא לחשבון שחקן אחד ללא אמצעים מיוחדים.
מדיניות מיזוג: אחרונים-כותבים-מנצח, CRDT, כללי איחוד דומיין.

מסדי נתונים של קונסנזוס/Quorum

כתיבת מניין (למשל: "לכתוב Quorum"), לקרוא מניין ("לקרוא Quorum") "= עקביות חזקה/הגדרה.
תן דעתך למחיר בין AZ/אזור.

שריטה: אסטרטגיות ובחירות מפתח

כיצד לבחור מפתח

הפצה יציבה על ידי player_id/ account_id/ bet_id.
הימנע מקשים מונוטוניים (הצטברות אוטומטית) בזנב ”חם”.
לתשלומים - לרוב ”שחקן _ id' או” חשבון _ id'; עבור יומנים - "event _ time '+ bucking; עבור תוכן - "דייר _ id'.

אסטרטגיה

Hash-sharding על ידי player_id: איזון על זרימת תעריפים/מאזנים.
חדירה מבוססת טווח זמן לאנליטיקה/ארכיון.
Geo-sharding: EU players = EU-shard (ציות לחוקים המקומיים).
היברידי: חשיש בתוך אזור + geo בתחום השיפוט.

נלחמים במפתחות חמים

מלחת מפתחות (הוספת מלח/דלי למפתח).
חפירה בכתב היא בעצם תור פקודה (מבצע סדרתי).
התממשות ”אגרגטים” (איזון) בשורה נפרדת עם תור רצף.

פעולות חוצה שברים

העברת כספים/פיצוי: להימנע 2PC על מסלולים חמים.
תבנית סאגה: התפצלות לעסקאות מקומיות + פעולות פיצוי, אידמפוטנטיות קשה ותיבת יוצא.
פרוטוקולים 2PC/commit: נקודה מותרת (back-office arches), אבל יקרה באיחור וסובלנות אשמה.
תחזיות: לקרוא מודלים למסכי תחום חוצה, מעודכן מהזרם.

מזימות, מדדים ואבולוציה

סכימה: נדידה מגב-קומבט, תכונה-דגלים על קוד.
אינדקסים על מפתחות שירטוט ושאלות תכופות; הימנעו מהצטרפות חוצה שברים (לעשות טרום הצטרפות/denormalization).
עבור מחסומי JSON/עגינה - תרשימי תוקף (JSON-Schema/Protobuf) ו-TTL עבור אוספים ”רועשים”.

הגדלה מקוונת והקשה מחודשת

תכנית N≫tekushcheye מספר השברים הווירטואליים (חריצים) = איזון מחדש גמיש.
חשיש עקבי או ”צמתים וירטואליים” לחיבור צומת רך.

גלישה מחודשת באינטרנט:

כניסה כפולה (רסיס ישן + חדש), אימות עקביות;
העתקי רקע של נתחים (מזבלה לוגית/שולחן מהלך/שיבוט זרימה);
לעבור על ידי ”סמן” + חלון תצפית, ואז להקליט כפול.
להעביר את המנהיג בלי הפסקה: החלפת תפקידים, ניקוז קשרים.

SLO, תצפית והתראה

SLO לכתוב/לקרוא: p99 MS MS MX על שולחנות חמים, העתק Lag Lag Log Seconds, זמינות Z.
Metrics: TPS, p95/p99, lag שכפול, multi-leader, retry rate, deflocks, lock wait, tache hit ratio, IOPS/latency disk.
עקבות: "trace _ id' בבקשות לבסיס נתונים, מקושר עם broker/event bus.
שאילתות כנרית ועסקאות סינתטיות לזיהוי מוקדם של השפלה.

ביטחון וציות

הצפנה במנוחה ובמעבר (TLS), סיבוב מפתח.
RBAC/ACL, מקטע אחר דומיין/דייר, מקבצים נפרדים לתשלומים/LCC.
לוקליזציה של נתונים (EU/TR/LATAM) - לשלב מדיניות גיאו-שימור.
ביקורת: מי ומה קריאה/כללים; מסווה PII; ייצוא ביקורת חשבונות.

גיבויים, PITR, DR

גיבויים מלאים + מצטברים, אחסון מחוץ לאתר.
PITR (התאוששות נקודתית בזמן) עבור אשכולות מנהיגים.

RPO/RTO:

Domains קריטי (שיווי משקל/תשלום) - RPO weather 0-30 (סינכרון למחצה או משלוח תדיר של WAL), RTO flight דקות עם כשל אוטומטי.
פחות קריטי - RPO עד דקות/שעות.
תרגילי DR (יום משחק) וספר ריצות מתועד.

ביצועים וכוונון (קצר)

זיכרון/מטמון: הגדלת החוצצים (buffers/innodb buffer pool), צג מטמון-להיט mache-95%.
מגזין/מנוע: NVME מהיר, בנפח נפרד תחת WAL/redo.
בריכת חיבור (שומר פיג 'קארי/היקארי).
פלסנר/סטטיסטיקה: ניתוח אוטומטי/ריק אוטומטי (Postgres), דחיסה/כוונון GC (מנועי LSM).
גורם קוורום/העתק: איזון בין p99 לסבילות פגמים.

טופולוגיות אופייניות ל ־ iGaming

1) איזון ותשלומים (CP-לולאה)

Leader-Follower באזור של השחקן, חצי סנכרון להעתק קרוב.
Hash-sharding על ידי "חשבון _ id'.
קריאות ”לאחר כתיבה” - מהמנהיג; תחזיות לרדיס עבור API-latency.
Outbox Action Bus לחישובים/אנליטיקה.

2) הימור על אירועי היסטוריה/משחקים (יומן מוכוון-AP)

חדירה בזמן או חשיש על ידי "player _ id' בטור/LSM אחסון.
העתקים אסינכרוניים לדיווח/OLAP.
בסופו של דבר העקביות מקובלת, רוחב הפס חשוב יותר.

3) פרופילים/CRM (קריאת מולטי-אזור, לוקליזציה)

Geo-sharing על ידי שיפוט, העתקים מקומיים לקריאות.
כניסות דרך המנהיג הקרוב ביותר; פתירת סכסוכים באופן אסינכרוני לשדות שאינם קריטיים בלבד.

דוגמאות (קונספטואלי)

postgres: שריטה הצהרתית על ידי 'player _ id&fost

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. תוריד את הפיקדון כדי לחתוך (אידמפוטנט).
2. שלח אירוע ”הוסר” = שירות תשלום (שבר-B).
3. אם שלב 2 נכשל, לפצות שלב 1 עם אירוע ”חזרה”.

רשימת בדיקות מימוש

1. הגדר תחומי נתונים ו ־ SLOs (p99, RPO/RTO, רישום העתק).
2. בחר את מודל השכפול (leader/foller, quorum) ואת אסטרטגיית השרינג.
3. תקן את מפתחות ההצגה ואת התרמית (בלתי ניתנת לשינוי!).
4. הקלד מדיניות קריאה לאחר כתיבה וקרא ניתוב.
5. עיצוב מחדש מקוון (רסיסים וירטואליים, כניסה כפולה).
6. ודא אידמפוטנטיות ו תיבת יוצא לאירועים/פקודות.
7. הגדרת גיבויים, PITR, DR ותרגילים רגילים.
8. כולל תצפית: פיגור, מניין, מפתחות חמים, קונפליקטים.
9. דפי מסמכים: כשל, מוח מפוצל, השפלה.
10. לבצע בדיקות עומס/כאוס תחת פסגות התאמה.

אנטי דפוסים

רסיס אחד ענק ”לכל דבר” ו ”אז לחתוך”.
הצטרפות חוצה שברים של בדרך החמה של הבקשה.
אין מדיניות קריאה אחרי כתיבה (באגים צפים).
מזימות ”לשבור” מפתחות חדירה.
רב-מנהיג לחשבונות מזומנים ללא פתרון סכסוכים קפדני.
אין PITR/DR - אין אפשרות להתאושש משגיאה לוגית.

תוצאות

שכפול פותר קריאות והתאוששות, חידוד פותר כתיבה ונפח. הארכיטקטורה המוצלחת ב-iGaming היא פשרות SLO ו-PACELC ברורות, מפתחות שירטוט יציבים, מינימום של קואורדינציה חוצת שברים (סאגה במקום 2PC), דיסציפלינה של קריאה לאחר כתיבה, רישום מחדש של DR ותרגילי DR רגילים. גישה זו מגיעה לשיאה בטורניר, עומדת במגבלות רגולטוריות על מיקום נתונים ונשארת צפויה בפעולה.