ანალიტიკური შენახვის ინდექსაცია

1) რატომ არის iGaming პლატფორმის ინდექსირება

ანალიტიკური სიჩქარე: მოხსენებები GGR/NET, კონვერტები, RG/AML და A/B ექსპერიმენტები ჯდება SLA- ში.
ღირებულება: ნაკლები სკანირებული ბაიტი - დაბალი ქულა გაანგარიშების/საწყობისთვის.
საიმედოობა: სტაბილური p95/p99 ლატენტობა დაშბორდებისა და API მეტრიკის.
მასშტაბი: ათობით ბრენდი/ბაზარი/PSP/პროვაიდერები „სრული სკანის“ ჯოჯოხეთის ღირებულების გარეშე.

2) დატვირთვის მოდელი (ინდექსამდე)

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
გაზომვები: 'dim _ user' (PII გარეშე), 'dim _ provider', 'dim _ psp', 'dim _ country'.
მოთხოვნები: „ბოლო N დღე“, აგრეგაციები 'brand/country/provider/psp', სტატუსის ფილტრები, surrogate-keys join, JSON ატრიბუტების ძებნა (გადახდის მეთოდი, მოწყობილობა), ტოპ-K/percentile.

ჩვენ ვირჩევთ ინდექსებს შერჩევითი, კარდინალურობისა და გამოყენების სიხშირის საფუძველზე.

3) ინდექსების ტიპები და როდის უნდა მიიღოთ ისინი

3. 1 კლასიკური

B-tree: თანასწორობა/დიაპაზონი მაღალი სელექციური სვეტების მიხედვით ('user _ surrogate _ id', 'occurred _ at', 'amount').
Hash: სუფთა თანასწორობა; ნაკლებად ხშირად ანალიტიკაში (სუსტი დიაპაზონის საწინააღმდეგოდ).
Bitmap: დაბალი კარდინალობა და ხშირი დაკავშირებული ფილტრები ('country', 'kyc _ level', 'rg _ state', 'brand'). განსხვავებულია ნიღბების შეჯამებისთვის.

3. 2 Columnar სპეციფიკა

Min-max ის უკეთესად მუშაობს ფილტრირებული მინდვრების დახარისხებისას.
Bloom ინდექსები: ბლოკში მნიშვნელობის კუთვნილების სწრაფი სავარაუდო ტესტები (სასარგებლოა 'user _ id', 'transaction _ id', 'psp').
BRIN (Block Range Index): იაფი „მაჩვენებლები“ ბლოკის დიაპაზონებზე, თუ მონაცემები ბუნებრივად რეგულირდება (დრო). იაფი, მაგრამ ეფექტური დროის სერიებისთვის.

3. 3 მოწინავე/სპეციალიზირებული

GiST/GIN (ინვერსიული): JSON/arrays/ტექსტი, ფილტრები ინვერსიული ატრიბუტებისთვის ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Projection (ClickHouse/MPP): join/agg- ის დაჩქარების მასალები (pre-join key ინახება წინასწარი აგრეგაციის გვერდით).
ვექტორი (ANN): მსგავსი ემბედინგის ძებნა (რეკომენდაციები/ანტიფროდიული ქცევა) - IVF/HNSW/Flat, როგორც „უახლოესი მეზობლების ინდექსი“.
Z- მოწესრიგება/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse): დისკზე მონაცემების მრავალგანზომილებიანი კლასტერიზაცია უკეთესი მონაცემთა სკიპინგისთვის.

4) განაწილება, დახარისხება, კლასტერიზაცია

წვეულებები (date/country/brand): დიდი (დღე/კვირა), რათა თავიდან იქნას აცილებული „მცირე ფაილების წყევლა“. შეარჩიეთ მაღალი შერჩევითი ველები WHERE/წვდომის უფლებებში.
პარტიის შიგნით დახარისხება: 'ORDER BY (occurred _ at, brand, psp)' ან Z-order '(brand, country, provider) "- ასე რომ min-max და bloom უკეთესად მუშაობს.
Cluster/Recluster: პერიოდული რეკონსტრუქცია ადგილის შესანარჩუნებლად.
TTL და ჭრელი: ძველი ნაწილების/სეგმენტების ავტომატური მოცილება.

5) მატერიალიზებული წარმოდგენები და პროექციები

MV ცხელი ნაჭრებისთვის: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. ჩვენ ვუჭერთ მხარს (streaming upserts).
პროგნოზები (ClickHouse )/Aggregate tables: წინასწარი ჯგუფები, roll-up დონე (საათი-დღე - კვირა).
შედეგების ქეში: query result cache/warehouse result cache განმეორებითი dashbords- ისთვის (ვალიდაცია მოთხოვნის ნიშნით და მონაცემების ახსნა).

6) ნახევრად სტრუქტურირებული მონაცემები (JSON/VARIANT)

ბილიკების ინდექსები: ინვერსიული/GIN ინდექსი json ბილიკებზე ('$. device. os`, `$.psp. details. method`).
მნიშვნელოვანი ატრიბუტების მატერიალიზაცია სვეტებში: სტაბილური ფილტრებისთვის (გადახდის მეთოდი, მოწყობილობა, პროგრამის ვერსია).
კლასების სტატისტიკა: შერჩევითი გეგმისთვის განაწილების შეგროვება.

7) მონაცემთა ტბები: Iceberg/Delta/Hudi

მანიფესტის ინდექსები: მეტამონაცემები პარკეტის ფაილებზე (min-max, null-count, bloom) - წვეულება pruning + file skipping.
ფაილების კომპაქტური/შერწყმა: მცირე ფაილების რეგულარული მერჯი „ოპტიმალური“ ზომით (128-1024 MB).
Clustering/Z-order: ფაილების გადახდა კორელაციის ველებისთვის (მაგალითად, 'brand, country, occurred _ at').
Delete/განახლება ინდექსები: პოზიციური დელტები და ბლომი, რათა დააჩქაროს მერჯე-on-read.

8) როგორ ავირჩიოთ ინდექსები: პრაქტიკული შემოწმების სია

1. შეაგროვეთ ტოპ N მოთხოვნა (დატვირთვის 90%) ფილტრების ველები/join/ჯგუფი.
2. თითოეული ველისთვის შეაფასეთ სელექციურობა 'sel = 1 - distinct (value )/rows' და კარდინალობა.
3. დროის წვეულება + 1-2 გაზომვები სტაბილური ფილტრებით/წვდომით.
4. Keys- ის დახარისხება/კლასტერის კოორდინაცია ფილტრებთან და join კლავიშებთან.
5. დაამატეთ bloom წერტილოვანი id, bitmap დაბალი კარდინალობისთვის.
6. ცხელი აგრეგაციები - MV/პროექციები.
7. JSON გზები - ინვერსიული ინდექსები + მატერიალიზაცია.
8. ტბებზე - კომპოზიცია და დაგეგმვა გრაფიკით.
9. შეიყვანეთ SLO: p95 ლატენტობა, სკანირებული ბაიტი/მოთხოვნა, skipped მონაცემების წილი.

9) მხარდაჭერა და მოვლა

ANALYZE/სტატისტიკა: განაახლეთ კარდინალობა და ჰისტოგრამა; წინააღმდეგ შემთხვევაში, „ბრმა“ ოპტიმიზატორი.
VACUUM/OPTIMIZE/RECLUSTER: დეფრაგმენტაცია და ხელახალი კლასიფიკაცია.
ინდექსების გამოყენების მონიტორინგი: „შეგროვება“, „ერთიანი ინდექსის სია“, „bytes scanned/bytes skipped“.
მანქანის მრჩევლები: პერიოდული რეკომენდაციები კლასტერული კლავიშებისა და დახარისხების შესახებ, query log- ის საფუძველზე.
რეგრესიის ტესტები: ახალი გასაღებების გადახდამდე - მოთხოვნის პროფილის შედარება და ღირებულება.

10) მეტრიკა და SLO ინდექსაცია

ტექნიკური: p95/p99 latency, scanned bytes/query, skipped bytes%, files touched, cache hit-rate.
ეკონომიკა: $/მოთხოვნა ,/დაშბორდი, $/TB სკანი.
ოპერაციები: კომპაქტური დრო, რეკონსტრუქციის ხაზი, „მცირე ფაილების“ წილი.
გეგმის ხარისხი: მოთხოვნების წილი ინდექსების/პროექციის გამოყენებით, კარდინალების სიზუსტე.

11) კეისი iGaming (მზა რეცეპტები)

11. 1 გადახდა/PSP: ვარდნა/მარცხი

წვეულება: 'by day'. დალაგება: '(ბრენდი, ქვეყანა, occurred _ at)'.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
შედეგი: p95 წამი 8. 2s-დან 1-მდე. 1s, scanned bytes ↓ на 87%.

11. 2 თამაშის რაუნდი: პროვაიდერი/თამაში

Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (თუ Postgres მსგავსი საცავი): 'occurred _ at'.
შედეგი: ტოპ K თამაშები/საათი - sub-second ცხელ ქეში.

11. 3 RG/AML: შეზღუდვების/თვითშეფასების მოვლენები

Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: „აქტიური შეზღუდვები 30 დღის განმავლობაში“ + მომხმარებელთა დონის მატერიალიზაცია PII გარეშე.
შედეგი: სწრაფი კომპლექსის ნიმუშები სრული სკანის მილიარდი მოვლენის გარეშე.

11. 4 ანტიფროდიტი: მარშრუტები და მოწყობილობები

JSON მატერიალიზაცია - სვეტები: 'მოწყობილობები. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
ვექტორული ინდექსი: ემბედინგი „დეპოზიტების ქცევა 7d“ - სწრაფი K-NN მსგავსი ანომალიებისთვის.

12) უსაფრთხოება და კონფიდენციალურობა

Zero-PII ინდექსირებულ სფეროებში და გეგმების ლოგოებში.
დისკზე დაშიფვრა: ინდექსები/სტატისტიკა დაშიფრულია მონაცემების მსგავსად.
დანაყოფების K ანონიმურობა: MV/პროექციები ქვეყნდება მხოლოდ ჯგუფების მიერ N.
Geo/tenant იზოლაცია: წვეულებები/გასაღებები მოიცავს 'brand/country/license'.
Legal Hold: ინდექსები/მანივიდებიც მოხვდებიან „გაყინვაში“.

13) ანტი შაბლონები

„ყველა ზედიზედ“ ინდექსირება არის მოცულობის აფეთქება და ტალღოვანი მხარდაჭერა.
მცირე ნაწილები (საათი/წუთი) - ჭრილობის ქარიშხალი და „მცირე ფაილები“.
დახარისხების გასაღებები, რომლებიც არ ემთხვევა ფილტრებს - ნულოვანი მონაცემთა skipping.
სტატისტიკის ნაკლებობა - ცუდი გეგმები, სრული სკანი.
JSON მოგზაურობის ინდექსების გარეშე და „ცხელი“ ატრიბუტების მატერიალიზაციის გარეშე.
კომპაქტისა და ჩანაწერების უგულებელყოფა 2-4 კვირის შემდეგ დეგრადაციაა.

14) შაბლონები (გამოსაყენებლად მზად)

14. 1 კლასტერიზაციის/ინდექსაციის პოლიტიკა (YAML)

yaml dataset: gold. payments partition_by: ["date"]
order_by: ["brand","country","occurred_at"]
indexes:
bloom: ["transaction_id","user_surrogate_id"]
bitmap: ["psp","status","rg_state"]
materialized_views:
- name: mv_payments_7d_brand_psp group_by: ["brand","psp","status"]
window: "7d"
slo:
p95_latency_ms: 1200 scanned_bytes_per_query_max_mb: 256 maintenance:
compact_small_files: true recluster_cron: "0 /6  "
privacy:
pii_in_index: false

14. 2 ტბის კომპაქტური გეგმა (Iceberg/Delta)

yaml compaction:
target_file_size_mb: 512 small_file_threshold_mb: 64 zorder_by: ["brand","country","occurred_at"]
run_every: "PT6H"
max_concurrency: 4

14. 3 ინდექსები JSON მინდვრებისთვის

sql
-- GIN/inverted index on device attributes
CREATE INDEX idx_device_json ON gold. sessions
USING GIN ((device_json));
-- Materialization of critical pathways
ALTER TABLE gold. sessions ADD COLUMN device_os TEXT;
UPDATE gold. sessions SET device_os = device_json->>'os';
CREATE BITMAP INDEX idx_device_os ON gold. sessions(device_os);

14. 4 SLO ინდექსების მონიტორინგი

yaml monitoring:
skipped_bytes_share_min: 0. 70 index_usage_rate_min: 0. 85 stats_freshness_max_hours: 24 small_files_share_max: 0. 10

15) გზის განხორციელების რუკა

0-30 დღე (MVP)

1. ტოპ N მოთხოვნებისა და სკანირების პროფილების შეგროვება.
2. განაწილება თარიღით + დახარისხება, რომელიც შეთანხმებულია ფილტრებთან.
3. ჩართეთ data skipping (min-max) და bloom id- ველებისთვის.
4. ერთი MV ცხელი მეტრიკისთვის (payments 7d).
5. Dashboard SLI: p95, scanned bytes, skipped share, small files.

30-90 დღე

1. JSON მარშრუტები: ინვერსიული ინდექსები + მატერიალიზაცია.
2. ტბა: კომპაქტური და Z-order/clustering 2-3 გასაღებით.
3. მანქანის საკვანძო/პროგნოზები; რეგულარული ANALYZE.
4. წვეულებების გადასინჯვა (დღე - კვირა) სადაც არის „მცირე ფაილები“.

3-6 თვე

1. MV/პროგნოზების კატალოგი ვერსიით და SLA.
2. ვექტორული ინდექსები რეკომენდაციებისთვის/ანტიფროდისთვის.
3. SLO და ბიუჯეტების ერთიანი პოლიტიკა/მოთხოვნა; დეგრადაციის ალერტები.
4. ინდექსების კონფიდენციალურობის აუდიტი, geo/tenant იზოლაცია.

16) RACI

Data Platform (R): წვეულებები/ინდექსები/კომპაქტები, მანქანის მრჩევლები, მონიტორინგი.
ანალიზები/BI (R): MV/პროგნოზები დაშბორდებისთვის, მოთხოვნის პროფილირება.
დომენის ობნერები (C): „ცხელი“ ჭრის და ფილტრების კრიტერიუმები.
უსაფრთხოება/DPO (A/R): კონფიდენციალურობა, PII პოლიტიკა, geo/tenant გასაღებები.
SRE/Observability (C): SLO/Alerting, კაპასიტი კომპაქტებისთვის.
Finance (C): ბიუჯეტები/მოთხოვნა და დაზოგვა ინდექსებისგან.

17) დაკავშირებული მონაკვეთები

მონაცემთა სქემები და მათი ევოლუცია, მონაცემთა შესაბამისობა, DataOps პრაქტიკა, ანომალიების და კორელაციების ანალიზი, API ანალიტიკოსები და მეტრიკა, მონაცემთა კლასტერიზაცია, განზომილების შემცირება, MLOps: მოდელების ექსპლუატაცია.

შედეგი

ანალიტიკური საცავის ინდექსაცია არის სტრატეგია და არა „ყველაფრის ინდექსის შექმნა“. სწორი წვეულებები და დახარისხება, მონაცემთა სკიპინგი და ბლოკი, გააზრებული MV/პროექციები და რეგულარული კომპონენტი იძლევა სწრაფ და პროგნოზირებულ მოთხოვნებს კონტროლირებადი ღირებულებით და კონფიდენციალურობის რისკის გარეშე. IGaming- ისთვის, ეს ნიშნავს ოპერატიულ გადაწყვეტილებებს გადახდების, პროვაიდერების და RG/AML- ის შესახებ - SLA და ბიუჯეტის ფარგლებში.