Талдау сұрауларын оңтайландыру

1) Не үшін оңтайландыру (iGaming контексті)

Бизнес жылдамдығы: GGR/NET есептері, провайдерлер/ойындар, RG/AML және p95 SLA маркетингі.
Құны: сканерлеу байт және шафл → төмен $/сұрау.
Сенімділік: тұрақты ең жоғары сағаттар, BI «мұздатудың» болмауы.
Масштабы: ондаған брендтер/нарықтар, миллиардтаған жолдар, минут жаңалық.

2) Жүктеме профилі және SLO

«Алғашқы 90%» сұрауларын сипаттаңыз: терезелер (7/28/90d), сүзгілер ('brand, country, provider, psp, status'), join's, JSON-атрибуттар, топ-K және перцильдер.
SLO мысалдары: p95 ≤ 1. 2 s дашборд үшін, scanned bytes ≤ 256 МВ/сауал, freshness ≤ 5 min.

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 ауыстыру, динамикалық коалиция).

Жоспар қанша байт оқығанымызды, қай жерде шафлим жасағанымызды, кэштегенімізді көрсетуі тиіс.

4) Партиялар, сұрыптаулар, кластер-кейстер

Партиялар: 'date' + 1-2 бойынша қолжетімділікті өлшеу (мысалы, 'brand, country').
Сұрыптау/кластерлеу: 'ORDER BY/CLUSTER BY/Z-order' жиілік сүзгілер/джойндар бойынша ('provider, game_id, occurred_at').
Қайта кластерлеу және компакция: data skipping үшін тұрақты қайта салу; мақсатты файл өлшемі 128-1024 МБ.

5) JOIN-паттерндер

Broadcast Hash Join (BHJ): шағын өлшем (≤ жүздеген МБ) → фактіге broadcast.

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

Sort-Merge Join (SMJ): үлкен жиынтықтар, үйлесімді негізгі сұрыптау/кластер-кейстер → минималды шафл.
Pre-join/денормализация: тұрақты төлсипаттарды 'dim _' -тен факт-суретке (projection/materialized view) - минус JOIN критикалық жолдағы.
Anti/semijoins: 'NOT IN/EXISTS' -ті ашық semi-/anti-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 - бағаналы сұрыптау бойынша.
Ауыр терезелерді мүмкіндігінше алдыңғы агрегаттарға және semi-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 - сканерді қысқартады.
Үлкен кестелер үшін 'OFFSET/LIMIT' орнына 'keyset pagination' пагинациясы.

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: full sort жоқ p95/p99 перценттелген.
Reservoir/stratified sampling: интерактивті зерттеулер және алдын ала.

11) Жады, бұғазы және конкарренси

Spill-guard: join/agg жадының шектері; төгілгенде - batch/parallelism азайтыңыз, кілт бойынша сұрыптауды ұлғайтыңыз.
Concurrency & QoS: «ыстық» дашбордтар мен ауыр ad-hoc үшін пулдар; сканер/уақыт лимиттері; «ұмытылған» сұрауларға kill-switch.
Result cache/query cache: қайталанатын BI үлгілері үшін қосыңыз, жаңалық белгісі бойынша мүгедектік.

12) Регрессия және «қос прогон» тестілері

Топ-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-агрегаттары.

Алерталар: scanned bytes өсуі, skipped share құлдырауы, жиі NLJ, бұғаз> табалдырық.

14) iGaming кейстері (рецептер)

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. Ыстық дашбордтар үшін алдын ала топтау/MV.
6. Approx рұқсат етілген жерде (distinct/percentiles/top-k).
7. JSON → бағандар және/немесе инвертирленген индекстер.
8. Компакция/қайта кластерлеу; skipped bytes бойынша мақсат ≥ 70%.
9. Нәтижелер кэші және конкарренсидің бөлек пулдары.
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 Сұрау регрессия тесті (псевдо-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-пагинация

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 үлкен жиынтықтарда; JSON өрнектері бойынша join.
Ұсақ партиялар және шашыраңқы файлдар (метадеректер дауылы).
Бағандарды материалдандыру орнына UDF-жолдар.
Игнор статистик/ANALYZE - соқыр оңтайландырғыш және full scan.
Регрессиялық тесттер мен қайтару шектерінің болмауы.

18) Енгізу жол картасы

0-30 күн (MVP)

1. Топ-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 жоспарлар, авто-кері қайту.

3-6 ай

1. Нұсқасы және SLA бар/MV проекциялар каталогы.
2. Approx - барлық дашбордтар бойынша distinct/percentile/top-k арналған ядро.
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/алертинг, конкарренси және капасити.
Finance (C): $/сұранысқа арналған бюджеттер және экономикалық әсер.

20) Байланысты бөлімдер

Талдау қоймаларын индекстеу, Деректер схемалары және олардың эволюциясы, Деректерді валидациялау, DataOps-практикалары, Деректерді кластерлеу, Өлшемдерді төмендету, API аналитикасы және метрикасы, MLOps: модельдерді пайдалану.

Жиынтығы

Сұрау салуларды оңтайландыру - бұл «сиқырлы хинт» емес, жүйе: деректерді сауатты белгілеу (партия/кластер), алдын ала топтастыру және approximate-алгоритмдер, дұрыс JOIN-стратегиялар, кэш/конкарренси және p95 және scanned bytes тұрақты мониторингі. iGaming үшін бұл SLA және бюджет шеңберінде - төлемдердің, ойындардың және комплаенстің жылдам және тұрақты өлшемдерін білдіреді.