Analitik sorguların optimizasyonu
1) Neden optimize edilir (iGaming bağlamı)
İş hızı: GGR/NET raporları, sağlayıcılar/oyunlar, RG/AML ve p95 SLA'da pazarlama.
Maliyet: Daha az taranmış bayt ve shafl - $/request'in altında.
Güvenilirlik: kararlı pik saatler, BI donma yok.
Ölçek: Düzinelerce marka/pazar, milyarlarca satır, tazelik dakikaları.
2) Yük profili ve SLO
İsteklerin'ilk %90'ını açıklayın: pencereler (7/28/90d), filtreler ('marka, ülke, sağlayıcı, psp, durum'), join'ler, JSON nitelikleri, üst K ve yüzdelikler.
SLO örnekleri: p95 ≤ 1. Pano için 2 s, taranmış bayt ≤ 256 MB/istek, tazelik ≤ 5 dk.
3) Planların anatomisi: ne aramalı
Tahmin/Projeksiyon aşağı itme - Filtreler ve sütun listesi kaynağa atlanır.
Bölüm budama ve veri atlama (min-max/bloom/manifest).
Vektörize tarama/geç materyalizasyon: JOIN/PROJECT tarafından ertelenen sütun okumaları.
Stratejiye katılın: Yayın Hash (BHJ), Sıralama Birleştirme (SMJ), İç İçe Döngü (NLJ - избегать).
Spill & shuffle: Diske karıştırma ve dökülme hacmi SLA'nın ana düşmanıdır.
Uyarlanabilir sorgu yürütme: çalışma zamanında strateji değişikliği (BHJ↔SMJ anahtarlama, dinamik coales).
Plan şunları göstermelidir: kaç bayt okuduğumuzu, şaflim nerede, neyi önbelleğe aldığımızı.
4) Taraflar, sıralama, küme durumları
Taraflar: 'tarih' + 1-2 erişim boyutlarına göre (örneğin, 'marka, ülke').
Sıralama/kümeleme: 'ORDER BY/CLUSTER BY/Z-order' by frequent filters/joins ('sağlayıcı, game_id, occurred_at').
Yeniden sınıflandırma ve sıkıştırma: veri atlama için düzenli aktarım; Hedef dosya boyutu 128-1024 MB'dir.
5) JOIN desenleri
Yayın Hash Join (BHJ): küçük boyut (≤ yüzlerce MB) - gerçek yayın.
sql
/ hint if engine supports/
SELECT /+ BROADCAST(dim_provider) /...Sort-Merge Join (SMJ): büyük kümeler, uyumlu anahtar sıralama/küme örnekleri - minimum şaft.
Ön birleştirme/denormalizasyon: kararlı nitelikleri 'loş'tan gerçek anlık görüntüye _' (projeksiyon/materyalize görünüm) taşıyın - eksi kritik yolda JOIN.
Anti/semijoins: 'NOT IN/EXISTS'i açık yarı/anti-join planlarına yeniden yazın.
Bir kardinal patlamanın ortadan kaldırılması: boyutlardaki yinelenen anahtarları kontrol edin, vekil anahtarları kullanın.
6) GRUP BY, toplamalar ve ön toplamalar
Toplama/Küp/Gruplama Kümeleri: Birden çok toplama yerine bir faz.
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));Materyalize görünümler (MV )/projeksiyonlar: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider _ game'.
Kısmi - Nihai toplama: motorun kısmen işçiler (yerel) ve son olarak koordinatör üzerinde toplanmasına izin verin.
Yaklaşık: 'COUNT (DISTINCT user)' için HLL, yüzdeler için TDigest - BI için çok daha ucuz ve yeterli.
7) Pencere fonksiyonları (düzgün)
Tam olarak yüksek seçiciliğe sahip anahtarlarda PARTITION BY; SIPARIŞ BY - sütun sıralamasına göre.
Ağır pencereleri mümkünse ön agrega ve yarı birleştiricilerle değiştirin.
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) Filtreler, sayfalama ve TOP-K
Filtre sırası CBO için önemli değildir, ancak seçicilik ve indeksler/sıralama önemlidir.
LIMIT... TIES/APPROACH TOP-K ile - taramayı kısaltın.
Pagination: Büyük tablolar için 'OFFSET/LIMIT' yerine 'keyset pagination'.
sql
-- keyset
SELECT FROM t WHERE (date, id) > (:last_date,:last_id) ORDER BY date, id LIMIT 1000;9) JSON/Yarı Yapılandırılmış
Sıcak yolları sütunlara ('aygıtı. os ',' psp. Yöntem ').
Motor destekliyorsa, JSON yollarında ters/GIN indekslerini kullanın.
UDF'den satır satır kaçının: vurgulanan niteliklerle daha iyi projeksiyon.
10) Yaklaşık ve Örnekleme
HLL/Theta Sketch: Ucuz 'COUNT DISTINCT'.
TDiggest/KLL: tam sıralama olmadan persentiller p95/p99.
Rezervuar/tabakalı örnekleme: etkileşimli araştırma ve önizleme.
11) Hafıza, Boğaz ve Concarrency
Spill-guard: join/agg üzerindeki bellek sınırları; Dökülürken - toplu/paralelliği azaltın, anahtara göre sıralamayı artırın.
Eşzamanlılık ve QoS: "sıcak" panolar ve ağır hell-hoc için havuzlar; tarama/zaman sınırları; "unutulmuş" isteklere kill-switch.
Sonuç önbelleği/sorgu önbelleği: tekrarlanabilir BI şablonlarını etkinleştirin, tazelik belirteci ile devre dışı bırakın.
12) Regresyon testleri ve "çift çalışma"
Üst N sorguları için referans profillerini (plan/tarama baytları/zamanı) depolayın.
Dizinleri/kümeleri yayınlamadan önce - A/B çalıştırması: p95'i, taranmış baytları, atlanan paylaşımı, karıştırmayı karşılaştırın.
"Hızlı başarısız" eşikleri oluşturun: p95 yükseldiyse> X % - geri alma.
13) Gözlemlenebilirlik ve SLO
SLI:- P50/p95/p99 gecikme, taranmış bayt/sorgu, atlanmış bayt %, dokunulan dosyalar;
- shuffle baytlar, dökülen baytlar, pik bellek;
- önbellek isabet oranı; Doğruluk yaklaşım kümeleri.
Uyarılar: taranan baytlarda artış, atlanan paylarda düşüş, sık NLJ'ler, dökülme> eşikler.
14) iGaming kılıfları (tarifler)
14. 1 Ödemeler/PSP'ler: "feragat zirveleri"
WHERE: 'ts BETWEEN NOW () -7d AND NOW ()', 'brand, country, psp, status'.
Parti: gün; ORDER/Z-order: '(marka, ülke, ts)'; bitmap: 'psp, durum'; bloom: 'transaction _ id'.
MV: 'payments _ 7d _ by _ brand _ psp (status)'.
Sonuç: P95 - ~ 1s, taranmış baytlar ↓ 5-10 ×, sıfır boğaz.
14. 2 Oyun Turları: En İyi K Oyunları/Saat
ORDER BY/cluster по '(sağlayıcı, game_id, occurred_at)'; Ön agregalar için projeksiyon.
P95 yuvarlak süresi için yaklaşık Top-K + TDiggest.
Alt satır: sıcak önbellekteki ikinci altı grafikler.
14. 3 RG/AML Aktif Limitleri
JSON 'reason' - sütun; Bitmap'rg _ state ',' kyc _ level '; Son devletle yarı birleşme.
Sonuç: "30 gün boyunca" rapor edin - saniye, tam tarama olmadan.
15) Optimizasyon kontrol listesi (günlük)
1. Üst N isteklerinin ve profillerinin toplanması (plan/bayt/shafl).
2. Tarihe göre gruplar + kararlaştırılmış sıralama/küme durumları.
3. Aşağı itme ve projeksiyon budama kontrolü (sadece gerekli sütunlar).
4. JOIN stratejisi: küçük yayın, SMJ için sıralama, NLJ yok.
5. Sıcak panolar için ön toplama/MV.
6. Yaklaşık nerede geçerli (farklı/yüzdelik/üst-k).
7. JSON - sütunlar ve/veya ters endeksler.
8. Sıkıştırma/yeniden sınıflandırma; bayt hedefi %70 ≥ atlandı.
9. Sonuç önbelleği ve ayrı concarrency havuzları.
10. İzleme: p95, taranmış bayt, karıştırma, dökülme, isabet oranı.
16) Şablonlar (kullanıma hazır)
16. 1 Optimizasyon Politikası (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: 12016. 2 Sorgu regresyon testi (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 AYRI yeniden yazma
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 sayfalama
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-desenler
'SELECT' içinde prod; projeksiyon budama eksikliği.
OFSET sayfalama milyonlarca satırda.
Taslaklar olmadan COUNT DISTINCT; Tam sıralama yoluyla yüzdelik dilimler.
Büyük setlerde NLJ; JSON ifadeleri ile katılın.
Küçük gruplar ve dağınık dosyalar (meta veri fırtınası).
Sütunları somutlaştırmak yerine WHERE içindeki UDF dizeleri.
İstatistikleri görmezden gelin/ANALYZE - kör iyileştirici ve tam tarama.
Regresyon testi ve geri dönüş eşiği yok.
18) Uygulama Yol Haritası
0-30 gün (MVP)
1. Üst N isteklerinin ölçümü ve SLO/SLI kurulumu.
2. Tarihe göre gruplar + sıralama/küme durumları; veri atlamasını/açmasını etkinleştirin.
3. Sıcak ödeme raporu başına bir MV; HLL/TDiggest в BI.
4. Sorgu havuzlarını bölün, sonuç önbelleğini etkinleştirin.
30-90 gün
1. Ağır pencereler sayım/JSON - ön toplama/sütunlar.
2. Broadcast-join küçük boyutlar; Büyük için SMJ; NLJ'nin ortadan kaldırılması.
3. Zamanlama sıkıştırma ve yeniden sınıflandırma; Anahtar danışman.
4. Gözlenebilirlik ve bozulma uyarıları, A/B planları, otomatik geri alma.
3-6 ay
1. Sürüm oluşturma ve SLA ile projeksiyon/MV kataloğu.
2. Tüm panolarda farklı/persentil/top-k için yaklaşık çekirdek.
3. Regresyon testleri ve $/request bütçeleri için tek tip şablonlar.
4. JSON ve UDF kalıcı hijyen: materyalizasyon ve indeksler.
19) RACI
Veri Platformu (R): bölümler/kümeleme/sıkıştırma, MV/projeksiyonlar, önbellekler, izleme.
Analytics/BI (R): SQL yeniden yazma, yaklaşık kümeler, regresyon testleri.
Alan Sahipleri (C): bölümler ve doğruluk için gereksinimler.
Güvenlik/DPO (A/R): Gizlilik/PII, kümelerin k-anonimliği.
SRE/Gözlenebilirlik (C): SLO/uyarı, concarrency ve kapasite.
Finans (C): $/talep ve ekonomik etki için bütçeler.
20) İlgili bölümler
Analitik Depolama İndeksleme, Veri Şemaları ve Evrimi, Veri Doğrulama, DataOps Uygulamaları, Veri Kümeleme, Boyut Azaltma, Analitik ve Metrikler API, MLOps: Model Sömürü.
Toplam
Sorgu optimizasyonu bir "sihirli ipucu'değil, bir sistemdir: yetkin veri işaretlemesi (bölümler/kümeler), ön toplama ve yaklaşık algoritmalar, doğru JOIN stratejileri, önbellek/concarrency ve p95 ve taranmış baytların sürekli izlenmesi. IGaming için bu, SLA ve bütçe dahilinde ödemeler, oyunlar ve uyumluluk için hızlı ve istikrarlı metrikler anlamına gelir.