مخازن تحلیلی نمایه سازی

1) چرا نمایه سازی یک پلت فرم iGaming

سرعت تجزیه و تحلیل: گزارش در GGR/NET، تبدیل، RG/AML و A/B آزمایش مناسب به SLA.
هزینه: بایت کمتر برای اسکن → محاسبه کمتر/صورتحساب انبار.
قابلیت اطمینان: پایدار p95/p99 تاخیر داشبورد و معیارهای API.
مقیاس: ده ها مارک/بازار/PSP/ارائه دهندگان بدون «اسکن کامل» ارزش جهنمی.

2) مدل بار (قبل از نمایه سازی)

Факты: 'پرداخت'، 'game _ rounds'، 'sessions'، 'bonus _ events'.
ابعاد: 'dim _ user' (بدون PII)، 'dim _ provider'، 'dim _ psp'، 'dim _ country'.
درخواست ها: «آخرین N روز»، جمع آوری شده توسط «نام تجاری/کشور/ارائه دهنده/PSP»، فیلتر های زمینه وضعیت، پیوستن به کلید های جایگزین، جستجو توسط ویژگی های JSON (روش پرداخت، دستگاه)، بالا K/صدک.

ما شاخص ها را بر اساس انتخابی، کاردینالیتی و فرکانس استفاده انتخاب می کنیم.

3) انواع شاخص ها و زمانی که آنها را می گیرید

3. 1 کلاسیک

B-درخت: برابری/محدوده برای ستون های بسیار انتخابی ('user _ surrogate _ id'، 'رخ داده است _ at'، 'مقدار').
هش: برابری خالص ؛ کمتر در تجزیه و تحلیل (در برابر محدوده ضعیف).

بیت مپ: کاردینالیتی کم و فیلترهای مکرر متصل («کشور»، «kyc _ level»، «rg _ state»، «نام تجاری»). متفاوت برای جمع کردن ماسک ها

3. 2 ویژگی ستون

حداقل حداکثر (پرش داده ها): آمار خودکار «حداقل/حداکثر» در راه راه پارکت/قطعات → موتور پرش بلوک. هنگامی که توسط فیلدهای فیلتر شده مرتب می شود بهتر کار می کند.
شاخص های بلوم: تست های احتمالی سریع متعلق به یک مقدار در یک بلوک (مفید برای 'user _ id'، 'transaction _ id'، 'psp').
BRAIN (Block Range Index): اشاره گرهای ارزان برای مسدود کردن محدوده ها اگر داده ها به طور طبیعی مرتب (زمان) باشند. ارزان اما موثر برای سری زمان.

3. 3 پیشرفته/تخصصی

GiST/GIN (معکوس): JSON/آرایه ها/متن، فیلتر شده توسط ویژگی های تو در تو ("ابرداده. روش = 'Papara'، 'دستگاه. در [...])

Join/Projection (ClickHouse/MPP): مواد برای سرعت بخشیدن به join/agg (کلید قبل از پیوستن در کنار این واقعیت، تجمع اولیه ذخیره می شود).
بردار (ANN): جستجو برای جاسازی های مشابه (توصیه/رفتار ضد تقلب) - IVF/HNSW/Flat به عنوان «نزدیکترین شاخص همسایه».
Z-order/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse): خوشه بندی چند بعدی داده ها بر روی دیسک برای پرش بهتر داده ها.

4) پارتیشن بندی، مرتب سازی، خوشه بندی

احزاب (تاریخ/کشور/نام تجاری): بزرگ (روز/هفته) برای جلوگیری از "نفرین فایل های کوچک. "ما زمینه هایی را با انتخاب بالا در WHERE/Access Rights انتخاب می کنیم.
مرتب سازی در یک حزب: 'ORDER BY (occurred_at، نام تجاری، PSP)' یا Z-order توسط (نام تجاری، کشور، ارائه دهنده) '- این است که چگونه min-max و شکوفه کار بهتر است.
Cluster/Recluster: طبقه بندی مجدد دوره ای برای حفظ محل.
TTL و نگهداری: حذف خودکار قطعات/بخش های قدیمی.

5) دیدگاه ها و پیش بینی های تحقق یافته

MV برای برش های داغ: «پرداخت _ 7d _ by _ brand _ psp»، «دور _ 1d _ by _ provider». ما از افزایش جریان پشتیبانی می کنیم.
ClickHouse/Aggregate tables-Presets, roll-up levels (chas → den → nedelya).
Result cache: query result cache/warehouse result cache برای داشبوردهای قابل تکرار (اعتبار سنجی شده توسط query token و تازگی داده ها).

6) داده های نیمه ساختار یافته (JSON/VARIANT)

شاخصها بر اساس مسیر: شاخص معکوس/GIN در مسیرهای json ('.device $. os ', $ .psp. جزئیات. روش ').
تحقق ویژگی های مهم در ستون ها: برای فیلترهای پایدار (روش پرداخت، دستگاه، نسخه برنامه).
آمار کلیدی: جمع آوری توزیع برای یک برنامه انتخابی.

7) داده ها دریاچه ها: کوه یخ/دلتا/هودی

Manifest indexes: ابرداده در مورد فایل های پارکت (min-max, null-count, bloom) → هرس پارتیشن + پرش فایل.
فشرده سازی فایل/ادغام: ادغام منظم فایل های کوچک به اندازه «بهینه» (128-1024 MB).
خوشه بندی/مرتبه Z: بسته بندی مجدد فایل ها برای زمینه های مرتبط (به عنوان مثال،. 'برند، کشور، رخ داده است در').
حذف/به روز رسانی شاخص: deltas موقعیت و شکوفه برای سرعت بخشیدن به ادغام در خواندن.

8) نحوه انتخاب شاخص ها: چک لیست عملی

1. جمع آوری درخواست های N بالا (90٪ از بار) → فیلدهای فیلتر/join/group.
2. برای هر فیلد، انتخاب «sel = 1 - متمایز (ارزش )/ردیف» و کاردینالیتی را ارزیابی کنید.
3. دسته ای با زمان + 1-2 اندازه گیری با فیلتر پایدار/دسترسی.
4. مرتب سازی/خوشه کلید برای مطابقت با فیلتر و پیوستن به کلید.
5. شکوفه را برای شناسه نقطه، بیت مپ برای کاردینالیتی کم اضافه کنید.
6. تجمع داغ → MV/پیش بینی.
7. مسیرهای JSON → شاخص های معکوس + تحقق.
8. در دریاچه ها - تراکم و خوشه بندی در یک برنامه.
9. SLO را وارد کنید: تاخیر p95، بایت اسکن/درخواست، نرخ داده پرش.

9) پشتیبانی و نگهداری

تجزیه و تحلیل/آمار: به روز رسانی cardinalities و هیستوگرام ؛ در غیر این صورت، بهینه ساز «کور» است.
VACUUM/OPTIMIZE/RECLUSTER: یکپارچه سازی و طبقه بندی مجدد.
نظارت بر استفاده از شاخص: «نرخ پوشش»، «لیست شاخص استفاده نشده»، «بایت اسکن/بایت پرش».
مشاوران خودکار: توصیه های دوره ای برای کلید های خوشه ای و مرتب سازی بر اساس ورود به سیستم پرس و جو.
تست های رگرسیون: قبل از تخلیه کلید های جدید - مقایسه مشخصات درخواست و هزینه.

10) معیارها و نمایه سازی SLO

فنی: p95/p99 تاخیر، بایت اسکن/پرس و جو، پرش بایت٪، فایل های لمس شده، کش نرخ ضربه.
اقتصاد: $/درخواست، $/داشبورد، اسکن $/TB.
عملیات: زمان فشرده سازی، صف طبقه بندی مجدد، به اشتراک گذاری «فایل های کوچک».
کیفیت برنامه ها: نسبت پرس و جو با استفاده از شاخص ها/پیش بینی ها، دقت کاردینالیتی ها.

11) موارد iGaming (دستور العمل های آماده)

11. 1 پرداخت/PSPs: قطره/Refusals

حزب: «به روز». مرتب کردن (نام تجاری، کشور، occurred_at).
بلوم: 'transaction _ id', 'user _ id'. بیت مپ: «psp»، «وضعیت».
MV: «پرداخت _ 7d _ by _ brand _ psp (وضعیت، کاهش)».
نتیجه: p95 ↓ با 8. 2 به 1 1S، بایت اسکن ↓ на 87٪.

11. 2 دور بازی: ارائه دهنده/بازی

Z-ORDER/ORDER BY: '(ارائه دهنده، game_id، occurred_at)'.
Projection/agg: «دور _ 1d _ by _ provider _ game».
BRIN (اگر ذخیرهسازی شبیه Postgres باشد): توسط 'رخ داده _ at'.
نتیجه: بالا K بازی/ساعت - زیر دوم در کش داغ.

11. 3 RG/AML محدودیت/حوادث خود حذفی

بیت مپ: 'rg _ state'، 'kyc _ level'. جین مسیر JSON: «$ .reason».
MV: «محدودیت های فعال برای 30 روز» + تحقق سطح کاربر بدون PII.
نتیجه: نمونه های سریع برای انطباق بدون اسکن کامل میلیارد حوادث.

11. 4 Antifraud: مسیرها و دستگاه ها

تحقق JSON → kolonki: "دستگاه. دستگاه «،». مدل '،' پرداخت. روش '.
بلوم: 'graph _ device _ id'. خوشه: (نام تجاری، کشور، دستگاه. OS).
شاخص برداری: جاسازی «رفتار سپرده 7d» → سریع K-NN برای ناهنجاری های مشابه.

12) امنیت و حریم خصوصی

صفر PII در زمینه های نمایه شده و سیاهههای مربوط به برنامه.
رمزگذاری روی دیسک: شاخص ها/آمار به همان روش داده ها رمزگذاری می شوند.
K-anonymity از aggregates: MV/پیش بینی ها فقط توسط گروه های ≥N منتشر می شود.
Geo/tenant-isolation: احزاب/کلید شامل «نام تجاری/کشور/مجوز».
نگه حقوقی: شاخص/manivests نیز به «یخ» سقوط.

13) ضد الگوهای

نمایه «همه در یک ردیف» → انفجار حجم و تقویت نوشتن.
احزاب کوچک (ساعت/دقیقه) → طوفان تخته و «فایل های کوچک».
مرتبسازی کلیدهایی که با پرش صفر دادهها تطابق ندارند → فیلترها.
فقدان آمار → برنامه های بد, اسکن کامل.
JSON بدون شاخص مسیر و بدون تحقق ویژگی های داغ.
نادیده گرفتن تراکم و انزوا → تخریب در 2-4 هفته.

14) قالب (آماده برای استفاده)

14. 1 سیاست خوشه بندی/نمایه سازی (YAML)

yaml dataset: gold. payments partition_by: ["date"]
order_by: ["brand","country","occurred_at"]
indexes:
bloom: ["transaction_id","user_surrogate_id"]
bitmap: ["psp","status","rg_state"]
materialized_views:
- name: mv_payments_7d_brand_psp group_by: ["brand","psp","status"]
window: "7d"
slo:
p95_latency_ms: 1200 scanned_bytes_per_query_max_mb: 256 maintenance:
compact_small_files: true recluster_cron: "0 /6  "
privacy:
pii_in_index: false

14. 2 طرح تراکم دریاچه (کوه یخ/دلتا)

yaml compaction:
target_file_size_mb: 512 small_file_threshold_mb: 64 zorder_by: ["brand","country","occurred_at"]
run_every: "PT6H"
max_concurrency: 4

14. 3 شاخص برای زمینه های JSON

sql
-- GIN/inverted index on device attributes
CREATE INDEX idx_device_json ON gold. sessions
USING GIN ((device_json));
-- Materialization of critical pathways
ALTER TABLE gold. sessions ADD COLUMN device_os TEXT;
UPDATE gold. sessions SET device_os = device_json->>'os';
CREATE BITMAP INDEX idx_device_os ON gold. sessions(device_os);

14. 4 شاخص نظارت SLOs

yaml monitoring:
skipped_bytes_share_min: 0. 70 index_usage_rate_min: 0. 85 stats_freshness_max_hours: 24 small_files_share_max: 0. 10

15) نقشه راه پیاده سازی

0-30 روز (MVP)

1. جمع آوری N درخواست بالا و اسکن پروفایل.
2. پارتیشن بندی بر اساس تاریخ + مرتب سازی مطابق با فیلترها.
3. پرش داده را فعال کنید) حداکثر حداقل (و برای حوزههای شناسه شکوفه کنید.
4. یک MV برای متریک داغ (پرداخت 7d).
5. SLI داشبورد: p95، بایت اسکن شده، سهم پرش، فایل های کوچک.

30-90 روز

1. مسیرهای JSON: شاخص های معکوس + تحقق.
2. دریاچه: تراکم و Z-سفارش/خوشه بندی توسط 2-3 کلید.

3. مشاور خودکار کلید/پروژکتور ؛ تجزیه و تحلیل منظم

4. تجدید نظر از دسته (روز → هفته) که در آن «فایل های کوچک».

3-6 ماه

1. کاتالوگ MV/پروجکشن با نسخه و SLA.
2. شاخص بردار برای توصیه/ضد تقلب.

3. سیاست SLO یکپارچه و بودجه $/درخواست ؛ هشدار تخریب

4. ممیزی حریم خصوصی شاخص، جداسازی جغرافیایی/مستاجر.

16) RACI

پلت فرم داده (R): احزاب/شاخص ها/کامپکت ها، مشاوران خودکار، نظارت.
Analytics/BI (R): MV/پیش بینی برای داشبورد، پروفایل پرس و جو.
صاحبان دامنه (C): معیارهای برش و فیلتر داغ.
امنیت/DPO (A/R): حریم خصوصی، سیاست های PII، کلید های جغرافیایی/مستاجر.
SRE/مشاهده پذیری (C): SLO/هشدار، kapasiti برای تراکم.
امور مالی (C): بودجه $/پرس و جو و صرفه جویی از شاخص.

17) بخش های مرتبط

طرح ها و تکامل داده ها، اعتبار سنجی داده ها، شیوه های DataOps، تجزیه و تحلیل ناهنجاری و همبستگی، تجزیه و تحلیل و معیارهای API، خوشه بندی داده ها، کاهش ابعاد، MLOps: بهره برداری از مدل.

مجموع

نمایه سازی ذخیره سازی تحلیلی یک استراتژی است، نه «ایجاد یک شاخص در همه چیز». پارتیشن بندی و مرتب سازی صحیح، پرش و شکوفایی داده ها، MV/پیش بینی های متفکر و فشرده سازی منظم، نمایش داده های سریع و قابل پیش بینی را با هزینه کنترل شده و بدون خطر برای حریم خصوصی ارائه می دهد. برای iGaming، این به معنای راه حل های عملیاتی برای پرداخت ها، ارائه دهندگان و RG/AML - در داخل SLA و بودجه است.