Аналитикалык суроо-талаптарды оптималдаштыруу

1) Эмне үчүн оптималдаштыруу (iGaming контекстинде)

Бизнес ылдамдыгы: GGR/NET отчеттору, провайдерлер/оюндар, RG/AML жана p95 SLA маркетинг.
Баасы: аз сканерден байт жана shafla → төмөн $/суроо.
Ишенимдүүлүк: туруктуу жогорку саат, жок "тоңдурулган" BI.
Масштаб: ондогон бренддер/базарлар, миллиарддаган саптар, мүнөт сергектик.

2) жүктөө жана SLO кароо

Сүрөттөө "биринчи 90%" суроолор: терезелер (7/28/90d), чыпкалар ('brand, country, provider, psp, status'), join's, JSON атрибуттары, жогорку K жана кагаз.
SLO мисалдар: p95 ≤ 1. 2 s dashboard үчүн, scanned bytes ≤ 256 MW/суроо-талап, freshness ≤ 5 мин.

3) Пландардын анатомиясы: эмнени издөө керек

Predicate/Projection pushdown: фильтрлер жана мамычалардын тизмеси булакка түшөт.
Partition pruning & data skipping: ашыкча партияларды/файлдарды кесип (min-max/bloom/manifest).
Vectorized scan/late materialization: JOIN/PROJECT тарабынан кийинкиге калтырылган тилкелерди окуу.
Join strategy: Broadcast Hash (BHJ), Sort-Merge (SMJ), Nested Loop (NLJ — избегать).
Spill & shuffle: аралаштыруу көлөмү жана диск төгүү - негизги душманы SLA.
Adaptive query execution: ижарага стратегиясын өзгөртүү (BHJ SMJ которуу, динамикалык cooles).

План көрсөтүшү керек: канча байт окуйбуз, кайда шафлим кылабыз, эмнени кэшдиребиз.

4) Партиялар, сорттоо, кластер-кейстер

Партия: 'date' + 1-2 жетүү өлчөмдөрү (мисалы, 'brand, country').
Сорттоо/кластерлөө: 'ORDER BY/CLUSTER BY/Z-order' тез-тез чыпкалар/джойндор ('provider, game_id, occurred_at').
Reclasterization жана Compaction: data skipping үчүн үзгүлтүксүз которуу; максаттуу файл өлчөмү 128-1024 MB.

5) JOIN үлгүлөрү

Broadcast Hash Join (BHJ): кичинекей өлчөм (≤ жүздөгөн MB) → чындык үчүн broadcast.

sql
/ hint if engine supports/
SELECT /+ BROADCAST(dim_provider) /...

Sort-Merge Join (SMJ): чоң топтомдор, шайкеш ачкыч сорттоо/кластер учурлары → минималдуу шафл.
Pre-join/denormalization: "dim _" туруктуу атрибуттарды иш жүзүндөгү сүрөткө (projection/materialized view) - минус маанилүү жолдо JOIN.
Anti/semijoins: кайра 'NOT IN/EXISTS' ачык semi-/анти-join пландары.
Кардиналдуу жарылууну жок кылуу: өлчөмдөрдө ачкычтардын кайталанышын текшерүү, surrogate-keys колдонуу.

6) GROUP BY, агрегаттар жана алдын ала агрегаттар

Rollup/Cube/Grouping Sets: бир этап ордуна бир нече топтоо.

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));

Материалдык көз караштар (MV )/проекциялар: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider _ game'.
Partial → Final aggregation: кыймылдаткычты жарым-жартылай воркерлерге (local) жана акыры координаторго бириктирүүгө уруксат бериңиз.
Approximate: HLL үчүн 'COUNT (DISTINCT user)', TDigest - бир нече эсе арзан жана BI үчүн жетиштүү.

7) Терезе функциялары (тыкан)

PARTITION BY так жогорку тандоо менен ачкычтар боюнча; ORDER BY - колонка сорттоо боюнча.
оор терезелерди predagregates жана жарым-joins мүмкүн болгон жерде алмаштыруу.

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) чыпкалар, пагинация жана TOP-K

Фильтрлердин тартиби CBO үчүн маанилүү эмес, бирок тандоо жана индекстер/сорттоо маанилүү.
LIMIT … WITH TIES/APPROX TOP-K - сканер кыскартуу.
Пагинация: 'keyset pagination' ордуна 'OFFSET/LIMIT' чоң таблицалар үчүн.

sql
-- keyset
SELECT FROM t WHERE (date, id) > (:last_date,:last_id) ORDER BY date, id LIMIT 1000;

9) JSON/жарым структураланган

Тилкелерге ысык жолдорду ('device. os`, `psp. method`).
Эгерде кыймылдаткыч колдосо, JSON жолдорунда тескери индекстерди/GIN колдонуңуз.
Саптарда UDFден качыңыз: атрибуттарды бөлүп көрсөтүү менен жакшы проекция.

10) Approx жана орнотуу

HLL/Theta Sketch: арзан 'COUNT DISTINCT'.
TDigest/KLL: толук sort жок p95/p99 чапталган.
Reservoir/stratified sampling: өз ара изилдөө жана алдын ала.

11) Эстутум, кысыгы жана конкарренси

Spill-guard: join/agg үчүн эс чектери; төгүлгөндө - батч/параллелизмди азайтып, ачкыч боюнча сорттоону көбөйтүңүз.
Concurrency & QoS: "ысык" дашборддор жана оор ad-hoc үчүн бассейндер; сканер/убакыт чеги; "унутулган" суроо боюнча kill-switch.
Result cache/query cache: кайталануучу BI үлгүлөрү үчүн күйгүзүү, сергектик белгиси боюнча майып.

12) Регрессия жана "Double Running" тесттер

Top-N суроолор үчүн эталондук профилдерди (план/скан-байт/убакыт) сактаңыз.
Индекстерди/кластерлерди чыгаруудан мурун - A/B прогону: p95 салыштыруу, scanned bytes, skipped share, shuffle.
"Fail-fast" босогосун түзүү: p95 өскөн болсо> X% - артка.

13) Байкоо жана SLO

• p50/p95/p99 latency, scanned bytes/query, skipped bytes %, files touched;
• shuffle bytes, spilled bytes, peak memory;
• cache hit-rate; accuracy approx агрегаттары.

Alerts: scanned bytes өсүшү, skipped бөлүшүү, тез-тез NLJ, кысыгы> босого.

14) iGaming учурларда (Recipes)

14. 1 Төлөмдөр/PSP: "баш тартуу чокулары"

WHERE: `ts BETWEEN now()-7d AND now()`, `brand,country,psp,status`.
Партия: day; ORDER/Z-order: `(brand,country,ts)`; bitmap: `psp,status`; bloom: `transaction_id`.
MV: `payments_7d_by_brand_psp(status)`.
Жыйынтык: p95 → ~ 1s, scanned bytes ↓ 5-10 ×, нөл кысыгы.

14. 2 Оюн раунддар: Top K оюндар/саат

ORDER BY / cluster по `(provider, game_id, occurred_at)`; pre-агрегаттар үчүн projection.
Approx Top-K + TDigest үчүн p95 тегерек узактыгы.
Жыйынтык: ысык кэште суб-секунддук графиктер.

14. 3 RG/AML: активдүү чектөөлөр

JSON 'reason' → тилкеси; bitmap `rg_state`, `kyc_level`; акыркы абалы менен semi-join.
Жыйынтык: отчет "30 күн үчүн" - секунд, жок full scan.

15) оптималдаштыруу чек тизмеси (күн сайын)

1. Топ-N суроо-талаптарды жана алардын профилдерин чогултуу (план/байт/шафл).
2. Күн боюнча партиялар + макулдашылган сорттоо/кластер-кейстер.
3. Текшерүү pushdown жана projection pruning (гана керектүү мамычалар).
4. JOIN стратегиясы: чакан broadcast, SMJ үчүн сорттоо, NLJ жок.
5. Hot дашбордддор үчүн алдын ала агрегация/MV.
6. Approx жол бар жерде (distinct/percentiles/top-k).
7. JSON → мамычалар жана/же тескери индекстер.
8. Компакция/кайра кластерлештирүү; skipped bytes боюнча максат ≥ 70%.
9. Cache натыйжалары жана өзүнчө пулдар concarrensi.
10. Мониторинг: p95, scanned bytes, shuffle, spill, hit-rate.

16) Үлгүлөр (колдонууга даяр)

16. 1 Оптималдаштыруу саясаты (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 Сурам регрессия сыноо (Pseudo-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 кайра жазуу

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-Pagination

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) Анти-үлгүлөрү

'SELECT' деген продукт; projection pruning жок.
OFFSET-пагинация миллиондогон саптар.
COUNT DISTINCT эскиз жок; толук sort аркылуу бурчу.
чоң топтому боюнча NLJ; join JSON сөз айкаштары боюнча.
Майда партиялар жана чачыранды файлдар (метадеректер бороону).
Колонналарды материалдаштыруунун ордуна WHERE UDF-саптары.
Ignor статистика/ANALYZE - сокур оптималдаштыруучу жана толук сканер.
Регрессиялык тесттердин жана кайтаруу босоголорунун жоктугу.

18) Ишке ашыруунун жол картасы

0-30 күн (MVP)

1. Top-N суроо-талап жана SLO/SLI орнотуу.
2. Партиялар + сорттоо/кластер-кейс датасы боюнча; data skipping/bloom кирет.
3. "Ысык" төлөмдөр боюнча отчет боюнча бир MV; HLL/TDigest в BI.
4. Сурам бассейндерин бөлүү, result cache киргизүү.

30-90 күн

1. оор терезелер/JSON → алдын-ала агрегаттар/мамычалар.
2. Broadcast-join чакан өлчөмдөрү; чоң үчүн SMJ; NLJ жоюу.
3. График боюнча компакция жана кайра кластерлештирүү; автоматтык ачкыч кеңешчиси.
4. Байкоо жана Алерт деградация, A/B пландары, auto-артка.

3-6 ай

1. Нускалоо жана SLA менен проекциялардын/MV каталогу.
2. Approx ядро distinct/percentile/top-k бардык dashboard боюнча.
3. Бирдиктүү регресс тесттердин жана бюджеттердин шаблондору $/суроо.
4. Туруктуу гигиена JSON жана UDF: материалдык жана индекстер.

19) RACI

Data Platform (R): партия/кластерлештирүү/компакция, MV/проекциялар, кэш, мониторинг.
Analytics/BI (R): SQL кайра жазуу, approx агрегаттар, регрессия тесттер.
Domain Owners (C): кесүү жана тактык үчүн талаптар.
Security/DPO (A/R): купуялык/PII, k-жашыруун агрегаттар.
SRE/Observability (C): SLO/alerting, concarrensi жана capacity.
Finance (C): $/суроо-талап жана экономикалык таасири боюнча бюджеттер.

20) Байланыштуу бөлүмдөр

Аналитикалык кампаларды индекстөө, Маалыматтар схемалары жана алардын эволюциясы, Маалыматтарды валидациялоо, DataOps-практикалары, Маалыматтарды кластерлөө, Өлчөмдү азайтуу, API аналитика жана метрика, MLOps: моделдерди иштетүү.

Жыйынтык

Суроо-талаптарды оптималдаштыруу "сыйкырдуу хинт" эмес, система: маалыматтарды компетенттүү белгилөө (партия/кластер), алдын ала агрегациялоо жана approximate-алгоритмдер, туура JOIN стратегиялары, кэш/конкарренси жана p95 жана scanned bytes туруктуу мониторинг. iGaming үчүн бул төлөмдөрдүн, оюндардын жана комплаенстин тез жана туруктуу көрсөткүчтөрүн билдирет - SLA жана бюджеттин алкагында.