Βελτιστοποίηση των αναλυτικών ερωτημάτων

1) Γιατί βελτιστοποίηση (πλαίσιο iGaming)

Επιχειρηματική ταχύτητα: εκθέσεις GGR/NET, πάροχοι/παιχνίδια, RG/AML και μάρκετινγκ στο p95 SLA.
Κόστος: λιγότερο σαρωμένες ψηφιολέξεις και φρεάτια → κάτω από $/αίτημα.
Αξιοπιστία: σταθερές ώρες αιχμής, χωρίς ΔΑΙ.
Κλίμακα: Δεκάδες μάρκες/αγορές, δισεκατομμύρια γραμμές, λεπτά φρεσκάδας.

2) Προφίλ φορτίου και SLO

Περιγράψτε το «πρώτο 90%» των αιτήσεων: παράθυρα (7/28/90d), φίλτρα ('brand, country, provider, psp, status'), χαρακτηριστικά JSON, κορυφαία K και εκατοστημόρια.
Παραδείγματα SLO: p95 ≤ 1. 2 s για ταμπλό, σαρωμένες ψηφιολέξεις ≤ 256 MB/αίτημα, φρεσκάδα ≤ 5 λεπτά.

3) Ανατομία των σχεδίων: τι να αναζητήσετε

Πρόβλεψη/Προβολή ώθησης - Τα φίλτρα και ο κατάλογος στηλών παραλείπονται στην πηγή.
Κατάτμηση κλαδέματος & παραλείψεων δεδομένων (min-max/ανθοφορία/δηλωτικό).
Διανυσματική σάρωση/καθυστερημένη υλοποίηση: η στήλη διαβάζεται από την JOIN/PROJECT.
Στρατηγική συμμετοχής: Broadcast Hash (BHJ), Sort-Merge (SMJ), Nested Loop (NLJ - избегать).
Spill & shuffle: Ο όγκος του ανακατεύοντας και χύνοντας στο δίσκο είναι ο κύριος εχθρός της SLA.
Προσαρμοστική εκτέλεση ερωτημάτων: αλλαγή στρατηγικής στο χρόνο εκτέλεσης (αλλαγή BHJ↔SMJ, δυναμική ουρά).

Το σχέδιο θα πρέπει να δείξει: πόσες ψηφιολέξεις διαβάζουμε, πού είναι το φλογερό, τι κρύπτουμε.

4) Μέρη, διαλογή, υποθέσεις συνεργατικών σχηματισμών

Μέρη: κατά «ημερομηνία» + 1-2 διαστάσεις πρόσβασης (για παράδειγμα, «εμπορικό σήμα, χώρα»).
Διαλογή/ομαδοποίηση: 'ORDER BY/CLUSTER BY/Z-order' με συχνά φίλτρα/ενώσεις ('πάροχος, game_id, occurred_at').
Ανακατάταξη και συμπίεση: τακτική διαβίβαση για παραλαβή δεδομένων. Το μέγεθος του αρχείου στόχου είναι 128-1024 MB.

5) ΠΡΟΤΥΠΑ ΣΥΝΔΕΣΗΣ

Broadcast Hash Join (BHJ): μικρή διάσταση (≤ εκατοντάδες MB) → μεταδίδεται στην πραγματικότητα.

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

Sort-Merge Joint (SMJ): μεγάλα σύνολα, συμβατές περιπτώσεις διαλογής κλειδιών/συστάδων → ελάχιστος άξονας.
Προ-join/απομαλοποίηση: μετακίνηση σταθερών χαρακτηριστικών από 'dim _' στο πραγματικό στιγμιότυπο (προβολή/υλοποιημένη προβολή) - μείον JOIN στην κρίσιμη διαδρομή.
Αντισημιτικά: ξαναγράψτε το «NOT IN/EXISTS» σε σαφή ημι-/αντι-ενταξιακά σχέδια.
Εξάλειψη της έκρηξης του καρδινάλιου: έλεγχος των διπλών κλειδιών σε διαστάσεις, χρήση υποκατάστατων κλειδιών.

6) ΟΜΑΔΑ ΚΑΤΆ, ΣΥΓΚΕΝΤΡΩΤΙΚΑ ΜΕΓΕΘΗ

Σύνολα Rollup/Cube/Grouping: μία φάση αντί πολλαπλών συγκεντρώσεων.

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'.
Μερική → Τελική συγκέντρωση: αφήστε τον κινητήρα να συγκεντρωθεί εν μέρει στους εργαζόμενους (τοπικό) και τέλος στον συντονιστή.
Κατά προσέγγιση: HLL για 'COUNT (DIFFT χρήστης)', TDiest για εκατοστημόρια - πολλαπλάσια φθηνότερα και αρκετά για BI.

7) Λειτουργίες παραθύρων (καθαρές)

ΔΙΑΧΩΡΙΣΜΟΣ ΜΕ Ακρίβεια σε κλειδιά με υψηλή επιλεκτικότητα. ΚΑΤΆ ΠΑΡΑΓΓΕΛΙΑ - με διαλογή στήλης.
Αντικατάσταση βαρέων παραθύρων με προεγγραφές και ημι-συνδέσεις, όπου είναι δυνατόν.

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, αλλά η επιλεκτικότητα και οι δείκτες/διαλογή είναι.
ΟΡΙΑΚΟ... ΜΕ TIES/APPROX TOP-K - συντόμευση της σάρωσης.
Pagination: «πληκτρολόγηση» αντί για «OFFSET/LIMIT» για μεγάλους πίνακες.

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

9) JSON/Ημικατασκευασμένη

Υλοποίηση θερμών μονοπατιών σε στήλες ('συσκευή. s ',' psp. μέθοδος ").
Χρήση ανεστραμμένων/GIN δεικτών σε διαδρομές JSON εάν ο κινητήρας υποστηρίζει.
Αποφυγή UDF μέσω γραμμής: καλύτερη προβολή με τονισμένα χαρακτηριστικά.

10) Προσέγγιση και δειγματοληψία

HLL/Theta Sketch: Φτηνό 'COUNT DIFFICT'.
TDiest/KLL: εκατοστημόρια p95/p99 χωρίς πλήρη ταξινόμηση.
Δεξαμενή/στρωματοποιημένη δειγματοληψία: διαδραστική έρευνα και προεπισκόπηση.

11) Μνήμη, Στενά και Νομίσματα

Spill-guard: όρια μνήμης για τη σύνδεση/agg. κατά τη διαρροή - μείωση της παρτίδας/παραλληλισμού, αύξηση της διαλογής ανά κλειδί.
Concurrency & QoS: ομάδες για «καυτά» ταμπλό και βαριά κόλαση-hoc. σάρωση/χρονικά όρια· μετάβαση σε «ξεχασμένα» αιτήματα.
Αποτέλεσμα μνήμης/μνήμης ερωτημάτων: ενεργοποίηση επαναλαμβανόμενων προτύπων BI, απενεργοποίηση με ένδειξη φρεσκάδας.

12) Δοκιμές παλινδρόμησης και «διπλή εκτέλεση»

Αποθηκεύεται το προφίλ αναφοράς (σχέδιο/σάρωση ψηφιολέξεων/ώρα) για τα κορυφαία ερωτήματα N.
Πριν από την αποδέσμευση των δεικτών/συστάδων - A/B run: συγκρίνετε p95, σαρωμένες ψηφιολέξεις, παραλειπόμενο μερίδιο, ανακατεύετε.
Δημιουργία κατωφλίων «fail-fast»: εάν το p95 αυξηθεί> X% - rollback.

13) Παρατηρησιμότητα και SLO

• p50/p95/p99 καθυστέρηση, σαρωμένες ψηφιολέξεις/ερώτηση, παραλειφθείσες ψηφιολέξεις%, τα αρχεία άγγιξαν;
• ανακατεύοντας ψηφιολέξεις, χυμένες ψηφιολέξεις, μνήμη αιχμής·
• ρυθμός απόκρυψης (hit-rate)· τα συγκεντρωτικά μεγέθη προσέγγισης ακριβείας.

Ειδοποιήσεις: αύξηση των σαρωμένων ψηφιολέξεων, μείωση του μεριδίου που παραλείπεται, συχνές NLJ, διαρροή> κατωφλίων.

14) Περιπτώσεις iGaming (συνταγές)

14. 1 Πληρωμές/ΠΥΠ: «ανώτατα όρια παραίτησης»

WHERE: 'ts BETWING now () -7d AND now ()', 'brand, country, psp, status'.
Μέρος: ημέρα· ORDER/Z-order: '(εμπορικό σήμα, χώρα, ts)', bitmap: 'psp, status', άνθιση: «συναλλαγή _ id».
MV: 'πληρωμές _ 7d _ by _ brand _ psp (status)'.
Αποτέλεσμα: p95 → ~ 1s, σαρωμένες ψηφιολέξεις ↓ 5-10 ×, μηδέν στενά.

14. 2 γύροι παιχνιδιού: Κορυφαία K παιχνίδια/ώρα

ΔΙΑΤΑΞΗ BY/cluster по '(πάροχος, game_id, occurred_at)', προβολή για τα προεγγραφικά στοιχεία.
Περίπου Top-K + TDiest για συνολική διάρκεια p95.
Κάτω γραμμή: διαγράμματα δευτερολέπτου στη θερμή μνήμη.

14. 3 Ενεργά όρια RG/AML

Στήλη JSON 'reason', bitmap 'rg _ state', 'kyc _ level', ημι-ενώνονται με την τελευταία πολιτεία.
Αποτέλεσμα: αναφορά «για 30 ημέρες» - δευτερόλεπτα, χωρίς πλήρη σάρωση.

15) Κατάλογος ελέγχου βελτιστοποίησης (καθημερινά)

1. Συλλογή των κορυφαίων αιτήσεων N και των προφίλ τους (σχέδιο/bytes/shafl).
2. Παρτίδες ανά ημερομηνία + συμφωνηθείσες περιπτώσεις διαλογής/δέσμης.
3. Έλεγχος κλαδέματος ώθησης και προβολής (μόνο οι απαιτούμενες στήλες).
4. Στρατηγική JOIN: μετάδοση μικρού μεγέθους, είδος SMJ, όχι NLJ.
5. Προσομοίωση/MV για θερμό ταμπλό.
6. Περίπου όπου ισχύει (διακριτά/εκατοστημόρια/άνω-k).
7. Στήλες JSON ή/και ανεστραμμένοι δείκτες.
8. Συμπίεση/ανακατάταξη· Στόχος των παραλειπόμενων ψηφιολέξεων ≥ 70%.
9. Αποτελέσματα cache και χωριστές κοινοπραξίες συναλλάγματος.
10. Παρακολούθηση: p95, σαρωμένες ψηφιολέξεις, ανακατωσούρα, διαρροή, ρυθμός επιτυχίας.

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 ΔΙΑΚΡΙΤΗ επαναγραφή

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 Πληκτρολόγηση

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' in prod? έλλειψη κλαδέματος προβολής.
Σελιδοποίηση OFFSET σε εκατομμύρια γραμμές.
ΜΕΤΡΗΣΗ ΔΙΑΚΡΙΤΩΝ χωρίς σκίτσα. εκατοστημόρια μέσω πλήρους ταξινόμησης.
NLJ σε μεγάλα σύνολα· συμμετέχουν με εκφράσεις JSON.
Μικρές παρτίδες και διάσπαρτα αρχεία (καταιγίδα μεταδεδομένων).
Συμβολοσειρές UDF σε WHERE αντί υλοποίησης στηλών.
Αγνοήστε τις στατιστικές/ANALYZE - τυφλός βελτιστοποιητής και πλήρης σάρωση.
Δεν υπάρχουν δοκιμές παλινδρόμησης ούτε κατώφλια ανατροπής.

18) Χάρτης πορείας για την εφαρμογή

0- 30 ηµέρες (MVP)

1. Μέτρηση των κορυφαίων αιτήσεων N και εγκατάσταση SLO/SLI.
2. Παρτίδες ανά ημερομηνία + περιπτώσεις διαλογής/δέσμης· ενεργοποίηση παράκαμψης/άνθησης δεδομένων.
3. ένα MV ανά αναφορά θερμής πληρωμής· HLL/TDiest в BI.
4. Διαίρεση δεξαμενών ερωτήσεων, ενεργοποίηση μνήμης αποτελεσμάτων.

30- 90 ηµέρες

1. Απογραφή βαρέων παραθύρων/JSON → προσυναρμολόγηση/στήλες.
2. Μικρές διαστάσεις ενώσεων ραδιοτηλεοπτικών εκπομπών· SMJ για μεγάλες επιχειρήσεις· εξάλειψη του NLJ.
3. Συμπίεση και ανακατάταξη του χρονοδιαγράμματος· Βασικός σύμβουλος.
4. Παρατηρησιμότητα και προειδοποιήσεις υποβάθμισης, σχέδια A/B, αυτόματη ανατροπή.

3-6 μήνες

1. Κατάλογος προβολής/MV με έκδοση και SLA.
2. Περίπου πυρήνας για διακριτό/εκατοστημόριο/πάνω-k σε όλα τα ταμπλό.
3. Ομοιόμορφα πρότυπα για δοκιμές παλινδρόμησης και προϋπολογισμούς $/αίτημα.
4. JSON και UDF μόνιμη υγιεινή: υλοποίηση και δείκτες.

19) RACI

Πλατφόρμα δεδομένων (R): χωρίσματα/συστάδες/συμπίεση, MV/προβολές, κρύπτες, παρακολούθηση.
Analytics/BI (R): επαναγραφή SQL, περίπου συγκεντρωτικά στοιχεία, δοκιμές παλινδρόμησης.
Ιδιοκτήτες τομέα (C): απαιτήσεις για τμήματα και ακρίβεια.
Ασφάλεια/ΥΠΔ (A/R): προστασία της ιδιωτικής ζωής/PII, k-ανωνυμία των συγκεντρωτικών στοιχείων.
SRE/Παρατηρησιμότητα (C): SLO/ειδοποίηση, κωδικοποίηση και χωρητικότητα.
Χρηματοδότηση (Γ): προϋπολογισμοί για $/αίτημα και οικονομικές επιπτώσεις.

20) Συναφή τμήματα

Αναλυτική ευρετηρίαση αποθήκευσης, σχήματα δεδομένων και εξέλιξη, επικύρωση δεδομένων, πρακτικές DataOps, συσπείρωση δεδομένων, μείωση διάστασης, ανάλυση και μέτρηση API, MLOp: εκμετάλλευση μοντέλου.

Σύνολο

Η βελτιστοποίηση ερωτημάτων δεν είναι μια «μαγική υπόδειξη», αλλά ένα σύστημα: ικανή σήμανση δεδομένων (κατατμήσεις/συστάδες), προκατασκευή και κατά προσέγγιση αλγόριθμοι, σωστές στρατηγικές JOIN, cache/concarrency και συνεχής παρακολούθηση των p95 και σαρωμένων ψηφιολέξεων. Για το iGaming, αυτό σημαίνει γρήγορες και σταθερές μετρήσεις για πληρωμές, παιχνίδια και συμμόρφωση - εντός του SLA και του προϋπολογισμού.