分析存儲索引

1）為什麼iGaming平臺索引

分析速度：GGR/NET，轉換，RG/AML和A/B實驗的報告堆疊在SLA中。
成本：掃描字節較少→計算/倉庫費用較低。
可靠性：穩定的p95/p99潛伏的達什伯德和API度量。
規模：數十個品牌/市場/PSP/提供商沒有「全掃描」地獄價值。

2）載荷模型（索引前）

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.

測量：'dim_user'（沒有PII），'dim_provider'，'dim_psp'，'dim_country'。
查詢：「最後N天」，通過「品牌/國家/提供者/psp」進行聚合，通過雕像場進行過濾器，通過surrogate-keys進行協作，搜索JSON屬性（付款方法，設備），top-K/percentile。

我們根據選擇性、基數和使用頻率選擇索引。

3）索引的類型以及何時使用

3.1經典

B樹：高選擇性列（'user_surrogate_id'，'occurred_at'，'amount'）的相等/範圍。
Hash：純正平等；在分析中較少見（相對於弱範圍）。
Bitmap：低基數和頻繁連接的過濾器（「鄉村」，「kyc_level」，「rg_state」，「品牌」）。非常適合總和口罩。

3.2 Columnar特點

Min-max（數據跳過）：→引擎的鑲板/部分中的自動「最低/最大」統計信息會跳過塊。按過濾字段排序時效果更好。
Bloom索引：塊中值的快速概率歸屬測試（對「user_id」，「transaction_id」，「psp」有用）。
BRIN （Block Range Index）：如果數據自然排序（時間）,每個塊範圍的便宜「指針」。便宜，但對時間系列有效。

3.3先進的/專業的

GiST/GIN（反轉）： JSON/arrays/文本，按嵌套屬性篩選器（'metadata.method = 'Papara'`, `device.os in [...]`).

Join/Projection （ClickHouse/MPP）：用於加快join/agg（預加工密鑰存儲在事實旁邊,預聚合）的材料。
矢量（ANN）：搜索相似的embeddings（建議/反親緣行為）-IVF/HNSW/Flat作為「近鄰索引」。
Z 排序/Z順序（lakehouse/Databricks）/群集鍵 （Snowflake）/ORDER BY （ClickHouse）：多維磁盤數據群集,以實現更好的數據跳過。

4）分配，排序，聚類

派對（日期/國家/品牌）：大型（每天/每周），以避免出現「小文件詛咒」。在WHERE/訪問權限中選擇具有高選擇性的字段。
在批次中排序："ORDER BY （occurred_at、品牌、psp）"或Z-order by'（品牌、鄉村、提供者）"--所以min-max和bloom的表現更好。
Cluster/Recluster：定期重構以保持局部性。
TTL和重建：自動刪除舊批次/段。

5）實例化表示和投影

熱切片的MV：「payments_7d_by_brand_psp」，「rounds_1d_by_provider」。支持增量（streaming upserts）。
投影（ClickHouse ）/Aggregate tables：預分組，滾動級別（chas→den→nedelya）。
結果緩存：查詢結果緩存/倉庫結果緩存，用於可重復的行車記錄（通過查詢和新鮮度令牌驗證）。

6）半結構化數據（JSON/VARIANT）

路徑索引： json 路徑上的倒置/GIN索引（'$.device。os`, `$.psp.details.method`).

在列中實現重要屬性：用於穩定過濾器（支付方法、設備、應用程序版本）。
按鍵統計：為選擇性計劃收集分布。

7）數據湖： Iceberg/Delta/Hudi

Manifest索引：關於鑲板文件（min-max, null-count, bloom）的元數據→ partition pruning+file skipping。
編譯/合並文件：將小文件固定為「最佳」大小（128-1024 MB）。
Clustering/Z-order：重新包裝相關字段（例如「品牌、鄉村、occurred_at」）的文件。
Delete/Update索引：位置除法和bloom以加速閱讀。

8）如何選擇索引： 實用支票清單

1.收集前N請求（占負載的90%） → 過濾器/join/組字段。
2.對於每個字段，評估選擇性'sel=1-distinct（value ）/rows'和基數。
3.時間分期+1-2測量,具有穩定的過濾器/可用性。
4.按鍵排序/群集與過濾器和加入鍵一致。
5.將bloom 添加到點id，將bitmap添加到低基數。
6.熱聚合→ MV/投影。
7.JSON路徑→反向索引+實現。
8.在湖泊上-按計劃進行堆肥和聚類。
9.輸入SLO： p95潛伏期、可掃描字節/查詢、分量數據。

9）支持和維護

ANALYZE/統計數據：更新基數和直方圖；否則，優化器「盲目」。
VACUUM/OPTIMIZE/RECLUSTER：碎片整理和重構。
監視索引的使用：「covering rate」、「unused index list」、「bytes scanned/bytes skipped」。
自動顧問：基於查詢日誌的群集密鑰和排序的定期建議。
回歸測試：在丟棄新密鑰之前-比較查詢配置文件和成本。

10）指數化度量和SLO

技術：p95/p99 latency, scanned bytes/query, skipped bytes%, files touched, cache hit-rate。
經濟學：$/查詢，$/dashbord，$/TB掃描。
操作：壓縮時間，重排隊列，「小文件」的比例。
計劃質量：使用索引/投影的查詢比例，基數精度。

11）iGaming Case（現成食譜）

11.1 付款/PSP：跌幅/豁免

派對：「by day」。排序：「（品牌，國家，occurred_at）」。

Bloom: `transaction_id`, `user_id`.Bitmap: `psp`, `status`.

MV: `payments_7d_by_brand_psp(status, declines)`.

結果： p95 ↓ 8。2 s到1。1s, scanned bytes ↓ на 87%.

11.2遊戲回合：提供商/遊戲

Z-order / ORDER BY: `(provider, game_id, occurred_at)`.

Projection/agg: `rounds_1d_by_provider_game`.

BRIN（如果類似於Postgres的存儲）：通過「occurred_at」。
結果：頂級K遊戲/小時在熱緩存中排名第二。

11.3 RG/AML：限制/自我排斥事件

Bitmap: `rg_state`, `kyc_level`.JSON-path GIN: `$.reason`.

MV：「30天的活動限制」+實現沒有PII的用戶級別。
結果：快速采樣無十億個事件的完整掃描。

11.4 Antifrod：路線和設備

JSON→kolonki實現： 'device。os`, `device.model`, `payment.method`.

Bloom: `graph_device_id`.Cluster: `(brand, country, device.os)`.

矢量索引：對於類似的異常，「7 d的存款行為」→快速的k-NN。

12）安全和隱私

索引字段和計劃日誌中的Zero-PII。
磁盤加密：索引/統計信息加密的方式與數據相同。
單位的K匿名：MV/投影僅由 ≥N組發布。
Geo/tenant隔離：分期/密鑰包括「品牌/國家/許可證」。
Legal Hold：指數/躁狂癥也陷入「凍結」。

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湖泊堆肥計劃（Iceberg/Delta）

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 SLO指數監控

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.啟用id字段的data skipping （min-max）和bloom。
4.一個MV用於「熱」度量（payments 7d）。

5.Dashboard SLI： p95, scanned bytes, skipped share, small files.

30-90天

1.JSON路徑：反向索引+實例化。
2.湖泊：2-3鍵的堆積和Z-order/集群。
3.鑰匙/投影自動控制器；常規ANALYZE。
4.在「小文件」處修改批次（day→week）。

3-6個月

1.具有轉換和SLA的MV/投影目錄。
2.建議/對立的矢量索引。
3.單一SLO政策和預算$/請求；降解變異。
4.索引隱私審計，geo/tenant隔離。

16) RACI

數據平臺（R）：批次/索引/復合、自動咨詢、監控。
Analytics/BI （R）： dashbords下的MV/投影,查詢分析。
域所有者（C）：熱切片和過濾器的標準。
安全/DPO（A/R）：隱私，PII政策，geo/tenant密鑰。
SRE/Observability（C）：SLO/alerting，用於復合的capasity。
財務（C）：預算/查詢和指數節省。

17）相關部分

數據模式及其演變，數據驗證，DataOps實踐，異常和相關性分析，分析和度量API，數據聚類，維數降低，MLOps：模型利用。

底線

分析存儲索引是一種策略，而不是「創建所有索引」。正確的批次和排序、數據跳過和流血、經過深思熟慮的MV/投影和定期堆積,以可控制的成本提供快速、可預測的查詢,並且沒有隱私風險。對於iGaming來說，這意味著在SLA和預算範圍內在線支付、提供商和RG/AML解決方案。