Sharding და მონაცემთა ბაზის რეპლიკაცია

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

IGaming პლატფორმებისთვის, ტრაფიკის ზრდა (განაკვეთები, ანაბრები, PSP ვებჰუკები, თამაშების მოვლენები) და ხელმისაწვდომობის მოთხოვნები (99 ევრო). 9–99. 99%) სწრაფად ეყრდნობა ერთი მონაცემთა ბაზის ზღვარს. რეპლიკაცია იძლევა ჰორიზონტალურ მასშტაბს კითხვისა და უკმარისობის წინააღმდეგობის შესახებ; Sharding არის ჩანაწერისა და მონაცემების ჰორიზონტალური მასშტაბები. გასაღები არის 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 - ები - Coums).
Sync/Semi-sync/Async: შეფერხების ბალანსი vs RPO.
შარდინგი არის ცხრილების/შარდენის გასაღებების ჰორიზონტალური დაყოფა.

Hash sharding (ერთგვაროვნება, უფრო რთული დიაპაზონი).
Range sharding (საკვანძო დიაპაზონი, „ცხელი“ ბოლოების რისკი).
Consistent hashing (რბილი დამატება/შემცირება).
Geo-sharding (რეგიონში/იურისდიქციაში).
ფუნქციური შარდვა (დომენებზე: გადახდა/განაკვეთები/CRM).

როდის და რა უნდა აირჩიოს iGaming- ში

მხოლოდ რეპლიკაცია (შარდენის გარეშე) - როდესაც კითხვის მთავარი პრობლემაა: მოვლენების ფირები, მოხსენებები, საჯარო კატალოგები. ჩანაწერები მოთავსებულია ერთ ლიდერში, კითხვები - რეპლიკებიდან.
შარდინგი - როდესაც ვიწრო ჩაწერის/შენახვის ადგილი: განაკვეთების ნაკადი, ბალანსის გარიგებები, გამომწვევი მოვლენები.

Multi-region:

მოთამაშეთა ლატენტობა/PSP არის ადგილობრივი კითხვის შენიშვნები.
მარეგულირებელი (მონაცემთა ლოკალიზაცია) - geo-sharding.
ინტერრეგიონალური DR - ასინქრონული რეპლიკა + გადართვის გეგმა.

PACELC და საგარანტიო თვისებები

CAP: ქსელის მიწოდებისას ჩვენ ვირჩევთ C (თანმიმდევრულობას) ან A (წვდომას).
PACELC: წარუმატებლობის არარსებობის შემთხვევაში, ჩვენ ვირჩევთ ლატვიას (L) და კონსულტაციას (C) შორის.
ფულადი გზები (ბალანსი, გაუქმება): ჩვეულებრივ, CP- ზე ორიენტირებული (CP/serializable ან Serializable + ბიზნეს idempotence).
ნაკლებად კრიტიკული ქვესისტემები (დაწკაპუნება, კატალოგები): L- ორიენტირებული (AP/EC, წარმოსახვითი).

რეპლიკაცია: პრაქტიკა

Leader–Follower

ჩანაწერები ლიდერია, კითხულობს და ასახავს.
Read-after-write: მომხმარებლის ოპერაციებისთვის წაიკითხეთ ლიდერი ან დაელოდეთ lag (შემოწმება 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
Semi-sync კრიტიკულ გზაზე (RPO- ს შემცირება ლატენტობის ფასად).
Failover: ავტომატური (patroni/raft კოორდინატორი) + fencing (ისე, რომ არ არსებობდეს ორმაგი ლიდერი).

Multi-Leader

შესაფერისია განცალკევებული დომენებისა და დაბალი კონფლიქტისთვის (მაგ., შინაარსი/კონფიგურაცია), მაგრამ არა მოთამაშის ერთი ანგარიშისთვის სპეციალური ზომების გარეშე.
Merge პოლიტიკოსები: last-write-wins, CRDT, კონსოლიდაციის დომენის წესები.

Consensus/Quorome BD

ჩანაწერი კვორუმთან (მაგალითად, 'WRITE ÉRUM'), კითხვა კვორუმთან ('READ ÈRUM') არის ძლიერი/კონფიგურირებული თანმიმდევრულობა.
გაითვალისწინეთ ლატენტობა AZ/რეგიონებს შორის და კვორუმის ღირებულება.

შარდინგი: სტრატეგია და გასაღების არჩევანი

როგორ ავირჩიოთ გასაღები

სტაბილური განაწილება player _ id/account _ id/bet _ id.
თავიდან აიცილეთ ერთფეროვანი ღილაკები (ავტოკატასტროფა) range sharding- ში - „ცხელი“ კუდი.
გადახდებისთვის - ხშირად 'player _ id' ან 'account _ id "; ლოგებისთვის - 'event _ time' + bucketing; შინაარსისთვის - 'tenant _ id'.

სტრატეგია

Hash sharding player _ id: ბალანსი განაკვეთების/ბალანსის ნაკადზე.
Range sharding დროის ანალიტიკისთვის/არქივისთვის.
Geo-sharding: EU მოთამაშეები - EU Shard (შესაბამისობა ადგილობრივ კანონებთან).
ჰიბრიდი: hash რეგიონში + geo იურისდიქციით.

„ცხელი“ გასაღებების წინააღმდეგ ბრძოლა

Key-salting (დაამატეთ მარილი/bucket გასაღები).
არსებითად Write-throttling, რიგის კომენდანტი.
ცალკეულ ჩარჩოში „დანაყოფების“ (ბალანსის) მატერიალიზაცია თანმიმდევრობით.

ჯვარედინი შარდის ოპერაციები

ფულადი გადარიცხვა/ანაზღაურება: ცხელი გზების თავიდან აცილება.
Saga pattern: დაყოფა ადგილობრივ გარიგებებზე + კომპენსაციის მოქმედებები, მკაცრი idempotence და გარედან.
2RS/კომუნალური ოქმები: დასაშვებია წერტილოვანი (დამხმარე ოფისის ბატები), მაგრამ ძვირია ლატენტურობისა და უარის თქმისთვის.
პროგნოზები: მკითხველთა წარმოდგენები შიდა ეკრანებისთვის, რომელიც განახლებულია ნაკადიდან.

სქემები, ინდექსები და ევოლუცია

სქემის ვერსია: მიგრაცია უკუკავშირიდან, კოდით feature-flags.
შარდვის ღილაკების ინდექსები და ხშირი მოთხოვნები; თავიდან აიცილეთ cross-shard join (გააკეთეთ pre-join/denormalization).
JSON/Doc-Dock-Dock - Validire სქემები (JSON-Schema/Protobuf) და TTL „ხმაურიანი“ კოლექციებისთვის.

ონლაინ სკალირება და რეცხვა

დაგეგმეთ N - ვირტუალური შარდების ამჟამინდელი რაოდენობა (slots) და მოქნილი რებალანსი.
Consistent hashing ან „ვირტუალური nods“ კვანძების რბილი დამატებისთვის.

ონლაინ გამაჯანსაღებელი:

ორმაგი ჩანაწერი (ძველი + ახალი ხიბლი), შესაბამისობის შესაბამისობა;
ჩანკების ფონის ასლები (ლოგიკური dump/table move/streaming clone);
გადართვა „მარკერზე“ + სათვალთვალო ფანჯარაზე, შემდეგ ორმაგი ჩანაწერის ამოღება.
ლიდერის გადაადგილება მარტივია: როლების გადართვა, კონუსების დრენაჟი.

SLO, დაკვირვება და ალერტინგი

SLO ჩაწერა/კითხვა: ცხელ ცხრილში p99-X ms, დასაშვები რეპლიკები - Y წამი, ხელმისაწვდომობა - Z.
მეტრიკა: TPS, p95/p99, რეპლიკა lag, კონფლიქტი (მულტი-ლიდერი), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latence დისკი.
ტრეკერი: 'trace _ id' BD- ს მოთხოვნით, მოვლენების ბროკერთან/ავტობუსთან დაკავშირება.
კანარის მოთხოვნები და სინთეზური ტრანსაქტიები დეგრადაციის ადრეული დეტალებისთვის.

უსაფრთხოება და მოთხოვნების დაცვა

დაშიფვრა მარტო და ტრანზიტში (TLS), გასაღების როტაცია.
RBAC/ACL, დომენების/ტენანტების სეგმენტი, ცალკეული კლასტერის გადახდა/CCC.
მონაცემთა ლოკალიზაცია (EU/TR/LATAM) - დააკავშიროთ geo-sharding და პოლიტიკური რეტენციები.
აუდიტი: ვინ და რა წაიკითხა/წესები; შენიღბვა PII; აუდიტის ექსპორტი.

Bacaps, PITR, DR

სავსეა + ინკრეტული ზურგჩანთებით, ოფსეტური საცავით.
PITR (წერტილის დროის რეკონსტრუქცია) ლიდერის მტევნებისთვის.

RPO/RTO:

კრიტიკული დომენები (ბალანსი/გადახდა) - RPO-0-30s (semi-sync ან ხშირი WAL შიპინგი), RTO - წუთი ავტომატური failover- ით.
ნაკლებად კრიტიკული - RPO წუთამდე/საათამდე.
DR სწავლებები (თამაშის დღე) და დოკუმენტირებული რუნბუქი.

პროდუქტიულობა და tuning (მოკლედ)

მეხსიერება/ქეში: გაზარდეთ ბუფერები (innodb buffer აუზი), დააკვირდით cache-hit-95% -ს.
ჟურნალი/ძრავა: სწრაფი NVMe, ცალკე ტომი WAL/redo.
ნაერთების აუზი (PgBouncer/Hikari).
დაგეგმვა/სტატისტიკა: ავტოანალიზი/ავტო-მანქანა (Postgres), კომპაქტური/tuning GC (LSM ძრავები).
კვორუმი/რეპლიკა-ფაქტორი: ბალანსი p99 და წინააღმდეგობას შორის.

ტიპიური ტოპოლოგია iGaming- ისთვის

1) ბალანსები და გადახდები (CP კონტური)

Leader-Follower მოთამაშის რეგიონში, semi-sync ახლო რეპლიკამდე.
Hash sharding 'account _ id'.
წაკითხული „ჩაწერის შემდეგ“ - ლიდერისგან; პროექცია Redis- ში API-latency.
Outbox არის მოვლენების ავტობუსი გაანგარიშებისთვის/ანალიტიკოსებისთვის.

2) ფსონების/თამაშის მოვლენების ისტორია (AP ორიენტირებული ჟურნალი)

Range sharding დროულად ან hash 'player _ id' სვეტში/LSM საცავში.
ასინქრონული საანგარიშო შენიშვნები/OLAP.
ღონისძიების კონცეფცია მისაღებია, გამტარუნარიანობა უფრო მნიშვნელოვანია.

3) პროფილები/CRM (Multi-region read, ლოკალიზაცია)

Geo-sharding იურისდიქციით, ადგილობრივი შენიშვნები კითხვისთვის.
ჩანაწერები უახლოესი ლიდერის მეშვეობით; ჯვარედინი რეგიონი არის ასინქრონული + კონფლიქტების მოგვარება მხოლოდ არაკრიტიკული სფეროებისთვის.

მაგალითები (კონცეპტუალური)

Postgres: დეკლარაციული sharding '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 (იდუმალი).
2. ღონისძიების „ამოღებულია“ გადახდის სერვისი (შარდ-B).
3. თუ ნაბიჯი 2 წარუმატებელია - 1 ნაბიჯის ანაზღაურება „დაბრუნებით“.

განხორციელების შემოწმების სია

1. დაადგინეთ მონაცემთა დომენები და SLO (p99, RPO/RTO, რეპლიკების ლაგი).
2. შეარჩიეთ რეპლიკაციის მოდელი (leader/follower, quorum) და sharding სტრატეგია.
3. ჩაწერეთ შარდინგის გასაღებები და სქემა (უცვლელი!).
4. შეიყვანეთ read-after-write პოლიტიკა და კითხვის მარშრუტიზაცია.
5. შეიმუშავეთ ონლაინ რეცხვა (ვირტუალური შარდები, ორმაგი ჩანაწერი).
6. გარანტირებულია idempotence და outbox მოვლენებისთვის/გუნდებისთვის.
7. კონფიგურაცია bacaps, PITR, DR და რეგულარული წვრთნები.
8. ჩართეთ დაკვირვება: ლაგი, კვორუმი, ცხელი გასაღებები, კონფლიქტები.
9. აღწერეთ runbook: failover, split-brain, დეგრადაცია.
10. ჩაატარეთ დატვირთვა/ქაოსი ტესტები მატჩის მწვერვალებისთვის.

ანტიპატერები

ერთი გიგანტური ხიბლი „ყველაფრისთვის“ და „შემდეგ ჩვენ ვჭრით“.
Cross Shard Join's მოთხოვნის ცხელი გზებისთვის.
Read-after-write (მცურავი შეცდომები) პოლიტიკის არარსებობა.
შარდინგის „გატეხილი“ გასაღებების სქემების მიგრაცია.
Multi-leader ფულადი ანგარიშებისთვის კონფლიქტების მკაცრი რეზოლუციის გარეშე.
არ არსებობს PITR/DR - შეუძლებელია გამოჯანმრთელება ლოგიკური შეცდომის შემდეგ.

შედეგები

რეპლიკაცია წყვეტს კითხვასა და წინააღმდეგობას, შარდინგი - ჩანაწერებსა და მოცულობას. IGaming- ში წარმატებული არქიტექტურა არის მკაფიო SLO და PACELC კომპრომისები, შარდინგის სტაბილური გასაღებები, მინიმალური ჯვარედინი შარდვის კოორდინაცია (საგა 2PC- ს ნაცვლად), read-after-write დისციპლინა, კოორდინირებული ონლაინ რეცენზია და რეგულარული DR R - სწავლებები. ეს მიდგომა ფართომასშტაბიანია ტურნირების მწვერვალებისთვის, გაუძლებს მონაცემთა ლოკალიზაციის მარეგულირებელ შეზღუდვებს და ექსპლუატაციაში პროგნოზირებულია.