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

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

1) למה אתה צריך את זה

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

2) מונחים בסיסיים ומודלים עקביים

Primary/Leader ↔ Replica/Follower: לכתוב על המנהיג, לקרוא על ההעתקים.
שכפול סינכרוני: אישור העסקה לאחר כתיבה על N nodes (RPO נמוך, latency גבוה יותר).
Asynchronous: מנהיג מתחייב ושולח יומן מאוחר יותר (RPO> 0, latency נמוך).
קוורום (רפסודה/פאקסוס): כתיבה לרוב הצמתים; יומן אחד, מוביל אוטומטי.
קריאה לאחר כתיבה: קריאה מובטחת של הרשומות שלה (ראה # 5).

אנו קוראים CAP במכירות כאלה: במקרה של בעיות רשת, אתם בוחרים עקביות (CP) או זמינות (AP) לפעולות קריטיות,

3) שכפול: אפשרויות ופרקטיקות

3. 1 פיזי והגיוני

פיזיקלי (WAL/redo/binlog): קרוב יותר לרישום הבלוקים, פשוט ומהיר; מוגבל לטופולוגיה/גירסה הומוגנית.
לוגי: זרם DML/DDL ברמת השורה/טבלה; מאפשר העתקים חלקיים, נדידת גירסה צולבת, CDC עבור DWH/הזרמה.

3. 2 הגדרות וניהול

צג לאג (זמן/בייטים/LSN).
הגבל משוב המתנה חמה ובקשות ארוכות על העתקים (כדי לא לחסום VACUUM/ניקוי).
עבור MySQL - GTID ותזמור; PostgreSQL - חריצים פטרוני/שכפול, synchronous_standby_names.

sql
-- on leader
ALTER SYSTEM SET synchronous_commit = 'on';
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby_a, standby_b)';
SELECT pg_reload_conf();

sql
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL gtid_mode = ON; -- restart
CHANGE MASTER TO MASTER_AUTO_POSITION=1;

3. 3 טופולוגיות

* 1 N (מנהיג * העתק) + קסקיידס (העתק מתמזג הלאה).
Multi-primary (פעיל-פעיל) - להימנע ב OLTP ללא ניהול קונפליקט קפדני.
אשכול קוורום (רפסודה) - תוספות CoccroachDB/Yugabyte/PG-Raft.

4) קרא/כתוב פיצול וניתוב

תמיד לכתוב כמנהיג; לקרוא מרמזים, אבל לשקול לג.

1. לאחר הקלטה מוצלחת, הלקוח קורא מהמנהיג במהלך ”Tenness T”.

2. שער LSN/GTID: הלקוח אומר ”אני רוצה לא להזדקן LSN = X”, הנתב שולח להעתק, שלו LSN Window.

3. שאילתות מסוימות מאפשרות מידע מעופש (ספריות/קלטות).

כלים: Pigboundser/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (נתב שברי).

דוגמה לשער LSN (רעיון): שמור 'pg _ current _ wal _ lsn () ל-HTTP header/cookie ודורש מהנתב לשכפל עם' pg _ last _ wal _ replay _ lsn '.

5) אסטרטגיות שרידינג

5. בחירת מפתח 1

• Hash by 'terant _ id'/' user _ id' - באופן שווה, אבל מונע סריקות טווח.
• טווח זמן/זיהוי - נהדר לסדרת זמן/ארכיון, אבל סיכון-שבר חם.
• חשיש עקבי - מקל על הוספת/הסרת רסיסים.
• ספרייה/תצפית טבלה - גמישה (כל אלגוריתם), אבל טבלה/מטמון אחר.

5. 2 תבניות

שום דבר משותף: כל שבר הוא מסד נתונים/אשכול נפרד, היישום יודע ניתוב.
Middleware-sharding: Vitess (MySQL), Citus (Postgres), Proxy-level מסתירה טופולוגיה.
פדרציה: הפרדת תחומי מידע באמצעות שירותים (קטלוג, תשלומים, auth).

5. 3 מפתחות מורכבים

השתמש במרחב המפתח: 'דייר': 'ישות:' ואגור אותו ביישום ובמטמון. POSTGRES - חלוקת חשיש + LIST/RANGE.

sql
CREATE TABLE orders (
tenant_id int,
id     bigint,
created_at timestamptz,
...,
PRIMARY KEY (tenant_id, id)
) PARTITION BY HASH (tenant_id);

CREATE TABLE orders_t0 PARTITION OF orders FOR VALUES WITH (MODULUS 16, REMAINDER 0);
--... t1..t15

6) דור זיהוי

הימנע מגדלים אוטומטיים ”חמים” בשריטה.
השתמש ב ־ Snowflake-like 64-bit ID (זמן + אזור + רסיס + seq) או ULID/KSUID (מונוטוני והפצה).
Postgres - רצף לכל שבר; עבור MySQL- auto_increment_increment/offset (קיזוזים שונים על ראשי שברים).

7) משיכת יתר ונדידה באינטרנט

עקרונות מפתח: כתיבה כפולה, אידמפוטנטיות, ניתוב כפול זמני.

1. הוסף רסיס חדש/אשכול.

2. אפשר קריאה כפולה (בדיקת עקביות).

3. כולל דו-כתיבה (בשני הרסיסים), אי התאמות שיא.

4. Backfill מידע היסטורי (צרור, שכפול לוגי/CDC).

5. העבר את ”מקור האמת” לשבר חדש; השאר סינכרון ”זנב”.

6. כבה את הישן.

כלים: Vitess Resharding, Citus move shards, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change-change (DDL ללא מנעולים).

8) ריבוי אזורים והפצת גיאו

מנהיג-חסיד לכל אזור: קריאה מקומית, כתיבה - באמצעות המוביל הגלובלי (מודל פשוט, אך חוצה-אזור RTT).
Multi-leader: הקלטה בשני האזורים - אתה צריך קונפליקט-mering (חותמת זמן/גרסה/CRDT).
SQL מבוזר אמיתי (רפסודה): CockroachDB/Yugabyte - נתונים ”מודבקים” לאזור, שאילתות מגיעות למניין המקומי.

• כסף/הזמנות - CP (quorum/leader), ספריות/קלטות - AP (מטמון, בסופו של דבר).
• תמיד לתכנן לכתוב גידור (מפתחות ייחודיים/ורסינינג) עם מוח מפוצל אפשרי.

9) עקביות בפועל

קרא-אתה-כותב: המנהיג או הסימן ש ”תפס” עם LSN/GTID.
מונוטוני אומר: ”לא מבוגר יותר מקריאת אל-אס-אן האחרונה”.
בקרת קונפליקט כתיבה: "בחר... לעדכון, גרסאות ('xmin '/' rowersion'), UPSERT עם בדיקת גרסה.
אידמפוטנטיות: מפתחות אידמפוטנטיות על תשלומים/אירועים.

10) יכולת תצפית, SLO והתראות

העתק לאג: זמן (שניות), מרחק LSN (בייטים), seconds_behind_master (MySQL).
גלגולים/קונפליקטים מאולצים, שגיאות שכפול.
p95/p99 latency latency route (קרא מנהיג נגד העתק, כתוב).
דרך: TPS/locks/row-contracted שולחנות.
BLOAT/VACUUM (PG), יחס חיתוך בריכת INNODB (MYSQL).
לוחות מחוונים: לכל שבר, רסיסים ”חמים”, הפצת מפתח.

11) גיבויים, PITR וDR

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

bash pg_basebackup -D/backups/base -X stream -C -S slot_replica_1 WAL archiving via archive_command or pgBackRest/Barman

12) ביטחון וגישה

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

13) כלים ולבנים

PostgreSQL: Patroni (HA), PigBounser (Propoling/RO-Routing), Repmgr, FigRest/Barman (Barman), Citus (Pglogical/Logical rapplication, pgbadger/pg_stat_statements.
MySQL: תזמורת (טופולוגיות/כשל אוטומטי), ProxySQL/MaxStale (ניתוב), Percona XtraBackup (גיבוי), Group Reception/InnodB Cluster, Vitess.
מבוזר SQL: CockroachDB, YugabyteDB (מניין, חדף/גאולוקציה מובנית).
CDC: Debezium + Kafka/Pulsar עבור אירועים/ETL.

14) אנטי דפוסים

אחד ראשי ללא כשל אוטומטי וללא בדיקות ד "ר.
”קסם” לא כולל שגיאות פנטום/חרקים חשודים.
לשדרג ”למען הכיסוי”: סיבוך בטרם עת במקום קנה מידה אנכי/אינדקסים/מטמון.
טווח חם (טווח זמן) ללא דלי-זמן/hash-מלח = שבר אחד נמס.
העסקה הגלובלית 2PC על גבי עשרות רסיסים ב ־ OLTP - P99 גבוה זנבות ומנעולים תכופים.
חוסר בכתיבה כפולה/קריאה כפולה במהלך נדידה = אובדן/מתוך סינכרון.
DDL בדפוס ללא כלים מקוונים וללא תאימות תווי דגלים.

15) רשימת יישומים (0-60 יום)

0-15 ימים

הגדר DB SLO, RPO/RTO.
אפשר שכפול, ניטור פיגור, גיבויים בסיסיים + PITR.
הזן את הנתב (PigBounder/ProxySQL) ואת מדיניות הקריאה לאחר כתיבה.

16-30 ימים

בחר אסטרטגיה חדה, תאר את המפתחות והתוכניות.
הכן כלים טעינת יתר (ויטס/סיטוס/CDC).
ספרייה של שירותים/טבלאות מסומן ”לקרוא-מעופש-ok” נגד ”קפדן”.

31-60 ימים

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

16) מדדי בגרות

העתק לג p95 <המטרה (למשל. 500 ms) לקריאה ביקורתית.
בדיקות DR מוצלחות: 1/רבע (שחזור RTO, אובדן RPO).
הפצת טעינה על ידי רסיסים: חוסר איזון <20% על ידי QPS/אחסון.
אחוז הבקשות עם קפדנות עקבית מנותב נכון = 100%.
אפס-מידע-אובדן בתקריות הדורשות ערבויות CP (כסף/הזמנות).
DDL/הגירה מקוונת ללא השבתה, עם דגלי תאימות.

17) דוגמאות מתכון

sql
-- calculate bucket = hash (user_id)% 16, store (bucket, created_at)
PARTITION BY LIST (bucket) SUBPARTITION BY RANGE (created_at)

python lsn = db. leader_query("SELECT pg_current_wal_lsn()")
ctx. sticky_until = now()+5s ctx. min_lsn = lsn in the read router: select a replica with last_lsn> = ctx. min_lsn, otherwise the leader

json
{
"tables": {
"orders": { "column_vindexes": [{ "column": "tenant_id", "name": "hash" }] }
}
}

18) מסקנה

שרידינג ושכפול הם לא רק טכניקה, אלא גם תהליכים: ניתוב מודע לעקביות, דיסציפלינת נדידה (double-write/read, backfill), מבחני DR רגילים, ותצפית lag/hot bard. התחל עם cray-after-write פשוט מוביל after-write acclection, ולאחר מכן הוסף sharding שבו פרופיל הטעינה באמת דורש זאת. השתמש בפלטפורמות מוכנות (Vitess/Citus/Distributed SQL) ושמור מידע ביקורתי עסקי במצב CP - כך הבסיס יפסיק להיות צוואר בקבוק ויהפוך ליסוד אלסטי צפוי של הפלטפורמה.