GH GambleHub

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.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Telegram
@Gamble_GC
Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.