分析存储索引

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解决方桉。