Tahliliy so’rovlarni optimallashtirish
1) Nima uchun optimallashtirish kerak (iGaming konteksti)
Biznes tezligi: GGR/NET hisobotlari, provayderlar/o’yinlar, RG/AML va marketing p95 SLA.
Narxi: skan qilinadigan bayt va shafladan kam → $/so’rovdan past.
Ishonchlilik: barqaror eng yuqori soatlar, BI «muzlatish» yo’qligi.
Ko’lami: o’nlab brend/bozorlar, milliardlab satrlar, bir daqiqalik yangilik.
2) Yuk profili va SLO
So’rovlarning «birinchi 90%» ni tavsiflang: derazalar (7/28/90d), filtrlar (’brand, country, provider, psp, status’), join’lar, JSON atributlari, top-K va muhrlangan.
SLO misollar: p95 ≤ 1. 2 s dashbord uchun, scanned bytes ≤ 256 MV/so’rov, freshness ≤ 5 min.
3) Rejalar anatomiyasi: nimani izlash kerak
Predicate/Projection pushdown: filterlar va ustunlar roʻyxati manbaga tushadi.
Partition pruning & data skipping: ortiqcha partiyalar/fayllarni kesish (min-max/bloom/manifest).
Vectorized scan/late materialization: JOIN/PROJECT tomonidan qoʻyilgan ustunlar boʻyicha oʻqish.
Join strategy: Broadcast Hash (BHJ), Sort-Merge (SMJ), Nested Loop (NLJ — избегать).
Spill & shuffle: aralashtirish va diskga quyish hajmi - SLAning asosiy dushmani.
Adaptive query execution: rantaymda strategiyani o’zgartirish (BHJ SMJ almashtirish, dinamik koalits).
Reja shuni ko’rsatishi kerak: qancha bayt o’qiymiz, qayerda shaflim qilamiz, nimani keshlaymiz.
4) Partiyalar, saralash, klaster-keyslar
Partitsii:’date’+ 1-2 o’lchovi (masalan,’brand, country’).
Saralash/klasterlash:’ORDER BY/CLUSTER BY/Z-order’tez filtrlar/joyinlar bo’yicha (’provider, game_id, occurred_at').
Reklasterlash va kompaksiya: data skipping uchun muntazam qayta joylashtirish; 128-1024 MB fayllarning maqsadli o’lchami.
5) JOIN-patternlar
Broadcast Hash Join (BHJ): kichik o’lchov (≤ yuzlab MB) → faktga broadcast.
sql
/ hint if engine supports/
SELECT /+ BROADCAST(dim_provider) /...
Sort-Merge Join (SMJ): katta toʻplamlar, mos keladigan asosiy saralash/klaster-keyslar → minimal shafl.
Pre-join/denormalizatsiya: barqaror atributlarni «dim _» dan «fakt-rasm» ga (projection/materialized view) chiqaring - kritik yo’lda minus JOIN.
Anti/semijoins:’NOT IN/EXISTS’ni aniq semi-/anti-join rejalariga qayta yozing.
Keskin portlashni bartaraf etish: Oʻlchamdagi kalitlarning dublikatlarini tekshiring, surrogate-keys yordamida.
6) GROUP BY, agregatlar va oldindan agregatsiyalar
Rollub/Cube/Grouping Sets: bir nechta agregatsiyalar oʻrniga bir faza.
sql
SELECT brand, country, DATE(ts) d, SUM(amount)
FROM gold. payments
WHERE ts >= NOW() - INTERVAL '7 days'
GROUP BY GROUPING SETS ((brand,country,d),(brand,d),(d));
Materiallashtirilgan tasavvurlar (MV )/proyeksiyalar:’payments _ 7d _ by _ brand _ psp’,’rounds _ 1d _ by _ provider _ game’.
Partial → Final aggregation: dvigatelni qisman vorkyerda (local) va yakuniy koordinatorda birlashtirishga ruxsat bering.
Approximate: HLL uchun’COUNT (DISTINCT user)’, TDigest uchun - bir necha baravar arzon va BI uchun yetarli.
7) Deraza funksiyalari (ehtiyotkorlik bilan)
PARTITION BY aynan yuqori selektivlikka ega kalitlar bo’yicha; ORDER BY - ustunli saralash bo’yicha.
Ogʻir oynalarni iloji boricha pre-agregatlar va semi-joins bilan almashtiring.
sql
-- Instead of window distinct
SELECT brand, COUNT() users
FROM (SELECT DISTINCT brand, user_id FROM gold. sessions WHERE d>=CURRENT_DATE-7) t
GROUP BY brand;
8) Filtrlar, paginatsiya va TOP-K
Filtrlar tartibi CBO uchun muhim emas, lekin selektivlik va indekslar/saralash muhimdir.
LIMIT … WITH TIES/APPROX TOP-K - skanerni qisqartiradi.
Paginatsiya: katta jadvallar uchun’OFFSET/LIMIT’oʻrniga’keyset pagination’.
sql
-- keyset
SELECT FROM t WHERE (date, id) > (:last_date,:last_id) ORDER BY date, id LIMIT 1000;
9) JSON/yarim strukturalangan
Ruknlarga (’device. os`, `psp. method`).
Agar vosita qoʻllab-quvvatlasa, JSON yoʻllaridagi invertlangan indekslar/GIN dan foydalaning.
Quyidagi satrlarda UDFdan qoching: atributlarni tanlash bilan yaxshiroq proyeksiya.
10) Approx va semplash
HLL/Theta Sketch: arzon’COUNT DISTINCT’.
TDigest/KLL: full sort’siz p95/p99.
Reservoir/stratified sampling: interaktiv tadqiqotlar va prevyu.
11) Xotira, bo’g "oz va konkarrensi
Spill-guard: join/agg uchun xotira limitlari; to’kilganda - batch/parallelizmni kamaytiring, kalit bo’yicha saralashni ko’paytiring.
Concurrency & QoS: «issiq» dashbordlar va og’ir ad-hoc uchun pullar; skan/vaqt limitlari; «unutilgan» soʻrovlarga kill-switch.
Result cache/query cache: takrorlanadigan BI-shablonlarni yoqing, yangilik tokenini nogironlashtiring.
12) Regressiya va «ikki marta yugurish» testlari
Top-N so’rovlar uchun etalon profillarini (reja/skan-bayt/vaqt) saqlang.
Indekslar/klasterlar chiqarilishidan oldin: p95, scanned bytes, skipped share, shuffle.
«fail-fast» chegaralarini yarating: agar p95 ortib ketsa> X% - orqaga qaytish.
13) Kuzatuv va SLO
SLI:- p50/p95/p99 latency, scanned bytes/query, skipped bytes %, files touched;
- shuffle bytes, spilled bytes, peak memory;
- cache hit-rate; accuracy approx-agregatlar.
Alertlar: oʻsish scanned bytes, tushish skipped share, tez-tez NLJ, boʻgʻoz> chegara.
14) iGaming keyslari (retseptlar)
14. 1 To’lovlar/PSP: «rad etish cho’qqilari»
WHERE: `ts BETWEEN now()-7d AND now()`, `brand,country,psp,status`.
Partiya: day; ORDER/Z-order: `(brand,country,ts)`; bitmap: `psp,status`; bloom: `transaction_id`.
MV: `payments_7d_by_brand_psp(status)`.
Natija: p95 → ~ 1s, scanned bytes ↓ 5-10 ×, nol bo’g "ozda.
14. 2 O’yin raundlari: top-K o’yinlar/soat
ORDER BY / cluster по `(provider, game_id, occurred_at)`; Pre-agregatlar uchun projection.
Approx Top-K + TDigest p95 raund davomiyligi uchun.
Natija: issiq keshdagi subsoniya grafiklari.
14. 3 RG/AML: aktiv cheklovlar
JSON’reason’→ ustun; bitmap `rg_state`, `kyc_level`; semi-join oxirgi holati bilan.
Yakun: «30 kun uchun» hisoboti - soniyalarda, full scansiz.
15) Maqbullashtirish chek-varaqasi (har kuni)
1. Top-N so’rovlar va ularning profillarini yig’ish (reja/bayt/shafl).
2. Sanasi bo’yicha partiyalar + kelishilgan saralash/klaster-keyslar.
3. pushdown va projection pruning (faqat kerakli ustunlar) ni tekshirish.
4. JOIN strategiyasi: kichik broadcast, SMJ uchun saralash, NLJ yo’q.
5. Issiq dashbordlar uchun oldindan agregatsiya/MV.
6. Approx mumkin boʻlgan joyda (distinct/percentiles/top-k).
7. JSON → ustunlar va/yoki invertatsiya qilingan indekslar.
8. Kompaksiya/reklasterlashtirish; skipped bytes maqsadi ≥ 70%.
9. Natijalar keshi va konkarrensining alohida pullari.
10. Monitoring: p95, scanned bytes, shuffle, spill, hit-rate.
16) Shablonlar (foydalanishga tayyor)
16. 1 Optimallashtirish siyosati (YAML)
yaml workload: bi_hot slo:
p95_latency_ms: 1200 scanned_bytes_max_mb: 256 skipped_bytes_share_min: 0. 70 storage:
partition_by: ["date"]
cluster_by: ["brand","country","occurred_at"]
indexes:
bloom: ["transaction_id","user_surrogate_id"]
bitmap: ["psp","status","rg_state"]
aggregation:
mv:
- name: mv_payments_7d_brand_psp window: "7d"
group_by: ["brand","psp","status"]
approx:
count_distinct: "hll"
percentile: "tdigest"
concurrency:
pools: {bi_hot: 50, adhoc: 10}
timeout_s: 120
16. 2 So’rov regressiyasi testi (psevdo-SQL)
sql
-- baseline: p95<=1200ms, scanned_bytes<=256MB
EXPLAIN ANALYZE
SELECT brand, psp, status, COUNT() cnt, SUM(amount) amt
FROM gold. payments
WHERE ts >= NOW() - INTERVAL '7 days'
AND brand =:brand AND country =:country
GROUP BY brand, psp, status;
16. 3 DISTINCT qayta yozish
sql
-- Bad: Heavy COUNT (DISTINCT user_id)
SELECT COUNT(DISTINCT user_id) FROM gold. sessions WHERE d>=CURRENT_DATE-7;
-- Better: HLL sketch/preaggregate
SELECT hll_union(user_hll) FROM agg. sessions_7d_user_hll WHERE d>=CURRENT_DATE-7;
16. 4 Keyset-paginatsiya
sql
SELECT
FROM gold. game_rounds
WHERE (occurred_at, round_id) > (:ts,:rid)
AND brand=:brand AND country=:country
ORDER BY occurred_at, round_id
LIMIT 1000;
17) Anti-patternlar
«SELECT» prodda; projection pruning yo’qligi.
millionlab satrlarda OFFSET-paginatsiya.
COUNT DISTINCT sketchsiz; to’liq sort.
katta to’plamlarda NLJ; join JSON iboralari bo’yicha.
Mayda partiyalar va tarqoq fayllar (meta ma’lumotlar bo’roni).
Ustunlarni materiallashtirish o’rniga, WHERE’dagi UDF satrlari.
Ignor statistik/ANALYZE - koʻr optimizator va full scan.
Regression testlar va orqaga qaytish chegaralarining yo’qligi.
18) Joriy etishning yo’l xaritasi
0-30 kun (MVP)
1. Top-N soʻrovlarini oʻlchash va SLO/SLI oʻrnatish.
2. Partitsiyalar + saralash/klaster-keyslar sanasi bo’yicha; data skipping/bloom.
3. To’lovlar bo’yicha «issiq» hisobotga bitta MV; HLL/TDigest в BI.
4. Soʻrov pullarini ajratish, result cache qoʻshish.
30-90 kun
1. Og’ir oynalarni ro’yxatga olish/JSON → pre-agregatsiya/kolonka.
2. Broadcast-join kichik o’lchovlar; katta uchun SMJ; NLJni bartaraf etish.
3. Jadval bo’yicha kompaksiya va reklasterlashtirish; avto kalitlar maslahatchisi.
4. Tanazzulning kuzatilishi va alertlari, A/B rejalar, avto-qaytish.
3-6 oy
1. / MV proyeksiya katalogi va SLA.
2. Approx-yadro distinct/percentile/top-k uchun barcha dashbordlar bo’yicha.
3. Regress-testlar va byudjetlarning yagona namunalari $/so’rov.
4. JSON va UDF doimiy gigiyenasi: materiallashtirish va indekslar.
19) RACI
Data Platform (R): partiyalar/klaster/kompaksiya, MV/proyeksiyalar, keshlar, monitoring.
Analytics/BI (R): SQLni qayta yozish, approx agregatlar, regressiya testlari.
Domain Owners (C): kesish va aniqlik talablari.
Security/DPO (A/R): agregatlarning maxfiyligi/PII, k-anonimligi.
SRE/Observability (C): SLO/alerting, konkarrensi va kapasiti.
Finance (C): $/so’rov uchun budjetlar va iqtisodiy samara.
20) Bog’liq bo’limlar
Tahliliy omborlarni indekslash, Ma’lumotlar sxemalari va ularning evolyutsiyasi, Ma’lumotlarni validatsiya qilish, DataOps-amaliyotlar, Ma’lumotlarni klasterlash, O’lchamni pasaytirish, Analitik va metrik API, MLOps: modellardan foydalanish.
Jami
So’rovlarni optimallashtirish «sehrli xint» emas, balki ma’lumotlarning malakali belgilanishi (partitsiyalar/klaster), oldindan agregatsiya qilish va approximate-algoritmlar, to’g’ri JOIN-strategiyalar, kesh/konkarrensi va doimiy monitoring p95 va scanned bytes tizimidir. iGaming uchun bu SLA va byudjet doirasida toʻlovlar, oʻyinlar va komplayensning tezkor va barqaror metrikasini anglatadi.