אופטימיזציה של שאילתות אנליטיות

1) מדוע לייעל את (הקשר iGaming)

מהירות עסקית: דוחות GGR/NET, ספקים/משחקים, RG/AML ושיווק ב- p95 SLA.
עלות: פחות בייטים סרוקים ושאפל = מתחת לדולר/בקשה.
שעות שיא יציבות, לא קפואות.
קנה מידה: עשרות מותגים/שווקים, מיליארדי קווים, דקות של רעננות.

2) טען פרופיל ו ־ SLO

תאר את ”90% הראשונים” של הבקשות: חלונות (7/28/90d), מסננים ('מותג, מדינה, ספק, psp, סטטוס'), תכונות JSON, K עליון ואחוזון.
דוגמאות: p95 מצולמים 1. 2 אס ללוח מחוונים, סריקה בבתים 256 MB/בקשה, רעננות 5 דקות.

3) אנטומיה של תוכניות: מה לחפש

חיזוי/הקרנה דחיפה - מסננים ורשימת עמודות מושמטים למקור.
גיזום מחיצה ודילוג נתונים (מין-מקס/פריחה/מניפסט).
סריקה וקטורית/התממשות מאוחרת: טור קורא נדחה על ידי JOIN/PROJECT.
אסטרטגיה מצטרפת: Broadcast Hash (BHJ), Mike-Merge (SMJ), Nessed Loop (NLJ - associates).
שפוך & דשדוש: נפח הדשדוש והשפיכה על הדיסק הוא האויב העיקרי של SLA.
ביצוע שאילתה אדפטיבית: שינוי באסטרטגיה בזמן הרצה (החלפת BHJ↔SMJ, פחם דינמי).

התוכנית צריכה להראות: כמה בייטים אנחנו קוראים, איפה השיחים, מה אנחנו מטמונים.

4) צדדים, מיון, מקרי אשכול

מסיבות: ”תאריך” + 1-2 ממדי גישה (לדוגמה, ”מותג, מדינה”).
מיון/התקבצות: ”סדר BY/CLUSTER BY/Z-ORDER” על ידי מסננים/מצטרפים תכופים ('ספק, game_id, occurred_at').
סיווג מחדש וחמלה: העברה רגילה עבור דילוג נתונים; גודל קובץ המטרה הוא 128-1024 MB.

5) צרף תבניות

Broadcast Hash With (BHJ): מימד קטן (מאות MB) משודר לעובדה.

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

מצטרף מיון-מיזוג (SMJ): סטים גדולים, מיון מפתחות תואמים/אשכול מקרים = פיר מינימלי.
טרום הצטרפות/הדנורמליזציה: העבירו תכונות יציבות מ-dim _' לתצלום עצמו (הקרנה/תצוגה ממשית) - פחות JOIN על הנתיב הקריטי.
אנטיביג 'ואנים: לשכתב ”לא ב/קיים” לתוכניות מפורשות חצי-אנטישמיות.
חיסול של פיצוץ קרדינלי: לבדוק מפתחות כפולים בממדים, להשתמש פונדקאית-מפתחות.

6) קבוצה על ידי, אגרגטים והפוגות

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 )/תחזיות: ”תשלומים _ 7d _ by _ brand _ psp”, ”סיבובים _ 1d _ by _ diver _ game”.
* צבירה סופית חלקית: לאפשר למנוע להצטבר באופן חלקי על עובדים (מקומי) ולבסוף על המתאם.
משוער: HLL עבור 'COUNT (Distribute user)', TDInegent עבור אחרונים - זולים יותר ומספיק עבור 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, אבל סלקטיביות ואינדקסים/מיון הם.
הגבלה... עם קשרים/אישור TOP-K - לקצר את הסריקה.
pagination: ”keyset pagination” במקום ”OFSET/LIMIT” עבור שולחנות גדולים.

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

9) JSON/חצי מובנה

התממש נתיבים חמים לעמודות ('התקן. o ',' psp. שיטה ').
השתמש באינדקסים הפוכים/GIN במסלולי JSON אם המנוע תומך.
הימנע מ ־ UDF לפי שורה: השלכה טובה יותר עם תכונות מודגשות.

10) אישור ודגימה

סקיצה HL/תטה: זולה ”COUNT DISTRATT”.
TDiingt/KLL: אחוזון p95/p99 ללא כל סוג.
מאגר/דגימה מסודרת: מחקר אינטראקטיבי ותצוגות מקדימות.

11) זיכרון, מיצר וקונקרנסי

משמר שפיכה: מגבלות זיכרון על הצטרפות/אג; כאשר שופכים - להפחית אצווה/מקביליות, להגדיל מיון על ידי מפתח.
קונקורנסי & QOS: בריכות ללוחות מחוונים ”חמים” ו Hell-Hoc כבד; סריקה/מגבלות זמן; מתג הריגה לבקשות ”נשכחות”.
תוצאה של מטמון/מטמון שאילתה: אפשר לתבניות BI ניתנות לחזרה, מנוטרלות על ידי אסימון רעננות.

12) בדיקות רגרסיה ו ”ריצה כפולה”

פרופילי התייחסות לאחסון (תוכנית/סריקה/זמן) לשאילתות N העליונות.
לפני שחרור אינדקסים/אשכולות - A/B ריצה: השווה p95, סרק בייטים, דילג על שיתוף, דשדוש.
צור סף ”אל-כשל”: אם p95 עלה> X% - rollback.

13) יכולת תצפית ו ־ SLO

• p50/p95/p99 latency, נסרק בייטים/שאילתה, דילג על בייטים%, קבצים נגעו;
• לערבב בייטים, לשפוך בייטים, זיכרון שיא;
• מטמון להיט קצב; גישות דיוק.

התראות: עלייה בבתים סרוקים, נפילה בנתח מדלג, תדירות NLJ, שפכים> סף.

14) תיקי iGaming (מתכונים)

14. 1 תשלומים/PSPs: ”פסגות ויתור”

איפה: זה בין עכשיו () -7d ועכשיו () ”, מותג, מדינה, psp, מעמד”.
מסיבה: יום; סדר/הזמנה: '(מותג, מדינה, ט)'; bitmap: ”psp, סטטוס”; בלום: "transaction _ id'.
MV: 'תשלומים _ 7d _ by _ brand _ psp (סטטוס)'.
תוצאה: p95 = ~ 1, bytes sut5-10 ×, מצר אפס.

14. 2 סיבובי משחק: Top K Games/Hour

הזמנה על ידי/אשכול '(ספק, game_id, occurred_at)'; הקרנה עבור פרגטים.
Exchanx Top-K + TDinegt למשך סיבוב p95.
שורה תחתונה: גרפים תת-שניות על המטמון החם.

14. 3 מגבלות פעילות RG/AML

JSON 'Reason' # טור; bitmap 'rg _ state', 'kyc _ level'; הצטרפות למחצה עם המדינה האחרונה.
התוצאה: דווח ”במשך 30 יום” - שניות ללא סריקה מלאה.

15) רשימת אופטימיזציה (מדי יום)

1. אוסף בקשות טופ N והפרופילים שלהן (תוכנית/בייטים/שאפל).
2. מקבצים לפי תאריך + מוסכם מיון/אשכול מקרים.
3. בדיקת שכיבות שמיכה וגיזום הקרנה (רק העמודות הנדרשות).
4. אסטרטגיה מצטרפת: שידור קטן, סוג עבור SMJ, אין NLJ.
5. קדם צבירה/MV ללוחות מחוונים חמים.
6. Exchanx שבו תקף (different/seconles/top-k).
7. JSON = עמודות ו/או מדדים הפוכים.
8. דחף/סיווג מחדש; דילג על יעד Bytes 70%.
9. תוצאות מטמון ובריכות קונקרטיות נפרדות.
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 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' in prod'; חוסר גיזום השלכה.
קיזוז של עבודת אלילים במיליוני קווים.
הרוזן נבדל ללא סקיצות; אחוריים דרך כל הסוג.
NLJ על סטים גדולים; הצטרפו לביטויי JSON.
חבורות קטנות וקבצים מפוזרים (סופת מטא-נתונים).
מחרוזות UDF במקום לממש עמודות.
התעלם מהסטטיסטיקה/ANALIZE - אופטימיזר עיוור וסריקה מלאה.
אין בדיקות רגרסיה ואין סף גלגול.

18) מימוש מפת דרכים

0-30 ימים (MVP)

1. מדידה של בקשות Top N והתקנה של SLO/SLI.
2. חבורות לפי תאריך + מיון/אשכול מקרים; אפשר דילוג נתונים/פריחה.
3. MV אחד לדו "ח תשלום חם; HLL/TDileget BI.
4. פיצול בריכות שאילתה, לאפשר מטמון תוצאה.

30-90 ימים

1. מפקד אוכלוסין חלונות כבדים/JSON * הגדרה מראש/עמודות.
2. שידור-להצטרף ממדים קטנים; SMJ עבור גדול; חיסול של אן-אל-ג 'יי.
3. לוח זמנים דחף וסיווג מחדש; יועץ מפתח.
4. תצפית והתראות על הידרדרות, תוכניות א/ב, גלגול אוטומטי.

3-6 חודשים

1. קטלוג הקרנה/MV עם versioning ו SLA.
2. גרעין אישור עבור אחוז מובהק/טופ-קיי על כל לוחות המחוונים.
3. תבניות אחידות לבדיקות רגרסיה ותקציבים $/בקשה.
4. היגיינה קבועה של JSON ו-UDF: התממשות ומדדים.

19) ראסי

פלטפורמת נתונים (R): מחיצות/התקבצות/דחיסה, MV/תחזיות, מטמונים, ניטור.
אנליטיקה/BI (R): שכתוב SQL, אישור אגרגטים, בדיקות רגרסיה.
דומיין בעלים (C): דרישות לסעיפים ודיוק.
אבטחה/DPO (A/R): פרטיות/PII, k-אנונימיות של אגרגטים.
SRE/Observability (C): SLO/Adalting, concarrency and cability.
תקציבים עבור $/בקשה והשפעה כלכלית.

20) חלקים קשורים

אינדקס אחסון אנליטי, שרטוטי נתונים ואבולוציה, אימות נתונים, פרקטיקות DataOps, קליטת נתונים, צמצום ממדים, אנליטיקה ומטריצות API, MLOps: ניצול מודל.

סך הכל

אופטימיזציה של שאילתה אינה ”רמז קסם”, אלא מערכת: סימון נתונים כשירים (מחיצות/אשכולות), הגדרה מראש ואלגוריתמים משוערים, אסטרטגיות JOE נכונות, מטמון/קונקרנסי וניטור קבוע של p95 ובתים סרוקים. עבור iGaming, זה אומר מדדים מהירים ויציבים לתשלומים, משחקים וציות - בתוך SLA ותקציב.