Analitik anbarların indeksləşdirilməsi
1) Niyə iGaming-platforma indeksləşdirilməsi
Analitikanın sürəti: GGR/NET, konversiyalar, RG/AML və A/B təcrübələri üzrə hesabatlar SLA-ya uyğunlaşdırılır.
Qiymət: daha az scanning bayt → aşağı hesablama/anbar.
Etibarlılıq: sabit p95/p99 dashboard gecikmə və API metrik.
Miqyaslı: «tam scan» cəhənnəm dəyəri olmadan onlarla marka/bazar/PSP/provayder.
2) Yük modeli (indeksləşdirmədən əvvəl)
Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Ölçülər: 'dim _ user' (PII olmadan), 'dim _ provider', 'dim _ psp', 'dim _ country'.
Sorğular: «Son N gün», 'brand/country/provider/psp' aqreqasiyaları, status sahəsi üzrə filtrlər, surrogate-keys üzrə join's, JSON atributları (ödəmə metodu, cihaz), top-K/percentile.
Seçicilik, kardinallıq və istifadə tezliyinə əsaslanaraq indeksləri seçirik.
3) Indekslərin növləri və onları nə vaxt almaq
3. 1 Klassik
B-tree: yüksək selektiv sütunlar üzrə bərabərlik/diapazonlar ('user _ surrogate _ id', 'occurred _ at', 'amount').
Hash: saf bərabərlik; analitikada daha az (zəif diapazonlara qarşı).
Bitmap: aşağı kardinallıq və tez-tez birləşdirilmiş filtrlər ('country', 'kyc _ level', 'rg _ state', 'brand'). Maskaların cəmlənməsi üçün əladır.
3. 2 Columnar spesifikasiyası
Min-max (data skipping): parket strayps/hissələrində avtomatik «minimum/maksimum» statistikası → mühərrik blokları buraxır. Süzülən sahələr üzrə çeşidlənərkən daha yaxşı işləyir.
Bloom indeksləri: blok dəyərinin sürətli ehtimal testləri ('user _ id', 'transaction _ id', 'psp' üçün faydalıdır).
BRIN (Block Range Index): verilənlər təbii qaydada (vaxt) blok diapazonlarına ucuz «işarələr». Ucuz, lakin time-series üçün təsirli.
3. 3 Qabaqcıl/ixtisaslaşmış
GiST/GIN (tərs): JSON/arrays/mətn, daxili atributlar üzrə filtrlər ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Projection (ClickHouse/MPP): join/agg sürətləndirmək üçün materiallar (pre-join key faktın yanında saxlanılır, əvvəlcədən yığma).
Vektor (ANN): oxşar embeddinqlərin axtarışı (tövsiyələr/antifrod davranışı) - IVF/HNSW/Flat «yaxın qonşuların indeksi» kimi.
Z-sifariş/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse): Daha yaxşı data skipping üçün diskdə çoxölçülü məlumat klasterləşdirilməsi.
4) Partizan, çeşidləmə, klasterləşdirmə
Parties (date/country/brand): böyük (gün/həftə) «kiçik faylları lənətləmək» qarşısını almaq üçün. WHERE/Access Rights yüksək seçicilik sahələri seçin.
Partiya daxilində çeşidləmə: 'ORDER BY (occurred_at, brand, psp)' və ya Z-order '(brand, country, provider)' - belə ki, min-max və bloom daha yaxşı işləyir.
Cluster/Recluster: yerli saxlamaq üçün periodik pereklasterization.
TTL və retenshn: köhnə partiyalar/seqmentlərin avtomatik çıxarılması.
5) Materiallaşdırılmış təsəvvürlər və proyeksiyalar
Qaynar kəsiklər üçün MV: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Biz inkremental dəstək (streaming upserts).
Proyeksiyalar (ClickHouse )/Aggregate tables: qabaqcıl qruplar, roll-up səviyyələri (saat → gün → həftə).
Nəticələr cache: təkrarlanan dashboard üçün query result cache/warehouse result cache (sorğu tokenini və məlumatların təravətini təsdiqləyirik).
6) Yarı strukturlu məlumatlar (JSON/VARIANT)
Yol indeksləri: çevirilmiş/json yollarında GIN indeksi ('$ .device. os`, `$.psp. details. method`).
Dinamiklərdə mühüm atributların materiallaşdırılması: sabit filtrlər üçün (ödəmə metodu, cihaz, proqram versiyası).
Açar statistikası: selektiv plan üçün distribyutorların toplanması.
7) Məlumat gölləri: Iceberg/Delta/Hudi
Manifest indeksləri: parket faylları haqqında metadata (min-max, null-count, bloom) → partition pruning + file skipping.
Kompaksiya/faylların birləşməsi: «optimal» ölçülü (128-1024 MB) kiçik faylların müntəzəm merge.
Clustering/Z-order: korrelyasiya sahələri üçün faylların yenidən doldurulması (məsələn, 'brand, country, occurred _ at').
Delete/Update indeksləri: merge-on-read sürətləndirmək üçün mövqeli deltalar və bloom.
8) Indeksləri necə seçmək olar: praktik yoxlama siyahısı
1. Top N sorğuları toplayın (90% yük) → filter sahələri/join/group.
2. Hər bir sahə üçün selektivliyi qiymətləndirin 'sel = 1 - distinct (value )/rows' və kardinallığı.
3. Partisia + 1-2 sabit filtr/giriş ilə ölçülür.
4. Sıralama/klaster keys filterlər və join-açarları ilə əlaqələndirmək.
5. Aşağı kardinallıq üçün nöqtə id, bitmap üçün bloom əlavə edin.
6. isti aqreqasiya → MV/proyeksiyalar.
7. JSON yolları → invertasiya indeksləri + materiallaşdırma.
8. Göllərdə - cədvəl üzrə kompaksiya və clustering.
9. SLO daxil edin: p95-gizli, taranabilir baytlar/sorğu, pay skipped data.
9) Dəstək və xidmət
ANALYZE/statistika: kardinallıq və histoqramları yeniləyin; əks halda optimizator «kor».
VACUUM/OPTIMIZE/RECLUSTER: defragmentasiya və pereklasterizasiya.
Indekslərin istifadəsinin monitorinqi: «covering rate», «unused index list», «bytes scanned/bytes skipped».
Avtomatik məsləhətçilər: query log əsasında klaster açarları və çeşidləmə üzrə dövri tövsiyələr.
Reqressiya testləri: yeni açarları deploymadan əvvəl - sorğu profili və dəyəri müqayisə.
10) Metrika və SLO indeksləşdirmə
Texniki: p95/p99 latency, scanned bytes/query, skipped bytes%, files touched, cache hit-rate.
İqtisadiyyat: $/sorğu, $/dashboard, $/TB skan.
Əməliyyatlar: kompaksiya vaxtı, pereklasterləşmə növbəsi, «kiçik faylların» payı.
Planların keyfiyyəti: indekslərdən/proyeksiyalardan istifadə edən sorğuların payı, kardinallıqların dəqiqliyi.
11) iGaming Cases (hazır reseptlər)
11. 1 Ödənişlər/PSP: düşmə/uğursuzluqlar
Partiya: 'by day'. Çeşidləmə: '(brand, country, occurred_at)'.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
Nəticə: p95 ↓ 8 ilə. 2s qədər 1. 1s, scanned bytes ↓ на 87%.
11. 2 Oyun raundları: provayder/oyun
Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (Postgres kimi saxlama varsa): 'occurred _ at'.
Nəticə: Top K oyunları/saat - isti cache sub-second.
11. 3 RG/AML: məhdudiyyətlər/özünü istisna hadisələri
Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: «30 gün ərzində aktiv məhdudiyyətlər» + PII olmadan istifadəçi səviyyəsinin materiallaşdırılması.
Nəticə: milyardlarla hadisələrin tam scan olmadan uyğunluq üçün sürətli nümunələr.
11. 4 Antifrod: marşrutlar və qurğular
JSON → sütunlarının materiallaşdırılması: 'device. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Vektor indeksi: oxşar anomaliyalar üçün «7d üçün depozit davranışı» → sürətli k-NN embeddingi.
12) Təhlükəsizlik və məxfilik
Zero-PII indeksləşdirilən sahələrdə və plan loqlarında.
Disk şifrələmə: indekslər/statistik məlumatlar kimi şifrələnir.
Aqreqatların K-anonimliyi: MV/proyeksiyaları yalnız ≥ N qrupları tərəfindən yayımlanır.
Geo/tenant-izolyasiya: partiyalar/açarlar 'brand/country/license' daxildir.
Legal Hold: indekslər/manivestlər də «dondurulur».
13) Anti-nümunələr
«Hər şeyi» indeksləşdirin → həcm partlayışı və write-amplification.
Kiçik partiyalar (saat/dəqiqə) → fırtına zolaqları və «kiçik fayllar».
Filtrlərlə üst-üstə düşməyən çeşidləmə açarları → sıfır data skipping.
Statistikanın olmaması → pis planlar, tam scan.
JSON səyahət indeksləri olmadan və «isti» atributları materiallaşdırmadan.
kompaksiya və recluster → 2-4 həftə sonra deqradasiya ignor.
14) Şablonlar (istifadəyə hazır)
14. 1 Klasterləşdirmə/indeksləşdirmə siyasəti (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: false14. 2 Göl kompaksiya planı (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: 414. 3 JSON sahələri üçün indekslər
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 monitorinq indeksləri
yaml monitoring:
skipped_bytes_share_min: 0. 70 index_usage_rate_min: 0. 85 stats_freshness_max_hours: 24 small_files_share_max: 0. 1015) Tətbiqi yol xəritəsi
0-30 gün (MVP)
1. Top N sorğuları və scan profilləri toplayın.
2. Filtrlərlə razılaşdırılmış + çeşidləmə tarixinə görə partikulyasiya.
3. ID sahələri üçün data skipping (min-max) və bloom daxil edin.
4. «Isti» metrika üçün bir MV (payments 7d).
5. Dashboard SLI: p95, scanned bytes, skipped share, small files.
30-90 gün
1. JSON yolları: invertasiya indeksləri + materiallaşdırma.
2. Göl: kompaksiya və 2-3 açar üzrə Z-order/clustering.
3. Avtomatik açar/proyeksiya məsləhətçisi; müntəzəm ANALYZE.
4. «Kiçik fayllar» harada partiyalar (day → week) yenidən baxın.
3-6 ay
1. Version və SLA ilə MV/proyeksiya kataloqu.
2. Tövsiyələr/antifrod üçün vektor indeksləri.
3. Vahid SLO və büdcə siyasəti $/sorğu; deqradasiya alertləri.
4. İndeks gizlilik auditi, geo/tenant-izolyasiya.
16) RACI
Data Platform (R): partiyalar/indekslər/kompaksiyalar, avto-məsləhətçilər, monitorinq.
Analytics/BI (R): MV/dashboard proyeksiyaları, sorğuların profilləşdirilməsi.
Domain Owners (C): «isti» kəsmə və filtrlərin meyarları.
Security/DPO (A/R): gizlilik, PII siyasəti, geo/tenant açarları.
SRE/Observability (C): SLO/alerting, kompaksiyalar üçün kapasiti.
Finance (C): büdcələr $/sorğu və indekslərdən qənaət.
17) Əlaqəli bölmələr
Verilənlər sxemləri və onların təkamülü, Verilənlərin validasiyası, DataOps-praktikalar, Anomaliyalar və korrelyasiyaların təhlili, API analitikası və metrikası, Verilənlərin klasterləşdirilməsi, Ölçünün azaldılması, MLOps: modellərin istismarı.
Yekun
Analitik anbarın indeksləşdirilməsi «hər şey üçün indeks yaratmaq» deyil, strategiyadır. Düzgün partisiyalar və çeşidləmə, data skipping və bloom, düşünülmüş MV/proyeksiyalar və müntəzəm kompaksiya sürətli və proqnozlaşdırıla bilən sorğular təmin edir. iGaming üçün bu, SLA və büdcə daxilində ödənişlər, provayderlər və RG/AML üçün operativ həllər deməkdir.