Indexación de almacenamiento analítico

1) Por qué la indexación de la plataforma iGaming

Velocidad de análisis: los informes de GGR/NET, conversiones, RG/AML y experimentos A/B se ajustan al SLA.
Costo: menos bytes escaneados → menor factura de cálculo/almacén.
Fiabilidad: p95/p99 estable latencia dashboards y métricas API.
Escala: docenas de marcas/mercados/PSP/proveedores sin «full scan» de valor infernal.

2) Modelo de cargas (antes de indexar)

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Medidas: 'dim _ user' (sin PII), 'dim _ provider', 'dim _ psp', 'dim _ country'.
Consultas: «Últimos N días», agregaciones por 'brand/country/provider/psp', filtros por campo de estado, join's por surrogate-keys, búsqueda por atributos JSON (método de pago, dispositivo), top-K/percentile.

Seleccionamos índices basados en la selectividad, cardinalidad y frecuencia de uso.

3) Tipos de índices y cuándo tomarlos

3. 1 Clásico

B-tree: igualdad/rangos sobre columnas altamente selectivas ('user _ surrogate _ id', 'occurred _ at', 'amount').
Hash: igualdad pura; menos frecuentemente en analítica (frente a rangos débiles).
Bitmap: baja cardinalidad y filtros conectados frecuentes ('country', 'kyc _ level', 'rg _ state', 'brand'). Son excelentes para resumir máscaras.

3. 2 Columnar-especificidad

Min-max (datos skipping): estadísticas automáticas «mínimo/máximo» en parquet stripes/partes → el motor pasa bloques. Funciona mejor cuando se ordena por campos filtrables.
Índices de bloom: pruebas rápidas de probabilidad de pertenencia de un valor en un bloque (útiles para 'user _ id', 'transaction _ id', 'psp').
BRIN (Block Range Index): «punteros» baratos para rangos de bloques si los datos son naturalmente ordenados (tiempo). Barato, pero efectivo para la serie de tiempo.

3. 3 Avanzado/Especializado

GiST/GIN (invertido): JSON/arrays/texto, filtros por atributos anidados ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Projection (ClickHouse/MPP): materiales para acelerar join/agg (la clave pre-join se almacena junto al hecho, agregaciones preliminares).
Vector (ANN): búsqueda de embarques similares (recomendaciones/comportamiento antifraude) - IVF/HNSW/Flat como «índice de vecinos más cercanos».
Z-order/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse): clustering multivariable de datos en disco para un mejor skipping de datos.

4) Partición, clasificación, agrupamiento

Lotes (fecha/país/marca): grandes (día/semana) para evitar la «maldición de los archivos pequeños». Seleccionamos campos de alta selectividad en WHERE/derechos de acceso.
Ordenar dentro de un lote: 'ORDER BY (occurred_at, marca, psp)' o Z-order per '(brand, country, provider)' - así min-max y bloom se practican mejor.
Cluster/Recluster: reclasificación periódica para mantener la localidad.
TTL y retoque: eliminación automática de lotes/segmentos antiguos.

5) Representaciones y proyecciones materializadas

MV para cortes en caliente: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Soporte incremental (streaming upserts).
Proyecciones (ClickHouse )/Tablas de Aggregate: agrupaciones preliminares, niveles de roll-up (chas→den→nedelya).
Caché de resultados: query resultado cache/warehouse resultado cache para dashboards repetibles (validamos el token de consulta y la frescura de los datos).

6) Datos semiestructurados (JSON/VARIANT)

Índices por paths: invertido/índice GIN en paths json ('$ .device. os`, `$.psp. details. method`).
Materialización de atributos importantes en altavoces: para filtros estables (método de pago, dispositivo, versión de la aplicación).
Estadísticas por claves: recogida de distribuciones para el plan selectivo.

7) Lagos de datos: Iceberg/Delta/Hudi

Índices de manifest: metadatos sobre archivos de parquet (min-max, null-count, bloom) → partition pruning + file skipping.
Compacto/combinación de archivos: merge regular de archivos pequeños en un tamaño «óptimo» (128-1024 MB).
Clustering/Z-order: volver a empaquetar archivos para campos de correlación (por ejemplo, 'brand, country, occurred _ at').
Índices Delete/Update: divisiones de posición y bloom para acelerar el merge-on-read.

8) Cómo elegir índices: lista de verificación práctica

1. Recopilar la N superior de solicitudes (90% de carga) → campos de filtro/join/group.
2. Para cada campo, evalúe la selectividad de 'sel = 1 - distinct (value )/rows' y la cardinalidad.
3. Lote en tiempo + 1-2 medidas con filtros/accesos estables.
4. Ordenaciones/clúster de llaves para conciliar con los filtros y las claves join.
5. Agregue bloom para ID de punto, bitmap para cardinalidad baja.
6. Agregaciones en caliente → MV/proyección.
7. Las rutas JSON → índices invertidos + materialización.
8. En los lagos - el compacto y el clustering en el horario.
9. Escriba SLO: latencia p95, bytes escaneados/consulta, proporción de datos skipped.

9) Soporte y mantenimiento

ANALYZE/estadísticas: actualizar cardinalidades e histogramas; de lo contrario, el optimizador es «ciego».
VACUUM/OPTIMIZE/RECLUSTER: desfragmentación y reclasificación.
Monitoreo del uso de índices: «covering rate», «unused index list», «bytes scanned/bytes skipped».
Asesores automáticos: recomendaciones periódicas sobre llaves de clúster y clasificaciones basadas en query log.
Pruebas de regresión: antes de que se desbloqueen nuevas claves - comparación de perfil de consulta y costo.

10) Métricas y SLO de indexación

Técnicos: p95/p99 latency, bytes/query scanned, bytes skipped%, files touched, cache hit-rate.
Economía: $/solicitud, $/dashboard, $/TB escaneado.
Operaciones: tiempo de compresión, cola de reclasificación, fracción de «archivos pequeños».
Calidad de los planos: proporción de consultas que utilizan índices/proyecciones, precisión de cardinalidades.

11) Casos de iGaming (recetas terminadas)

11. 1 Pagos/PSP: caídas/fallos

Fiesta: 'por día'. Ordenar: '(marca, país, occurred_at)'.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
Resultado: p95 ↓ con 8. 2s a 1. 1s, scanned bytes ↓ на 87%.

11. 2 rondas de juego: proveedor/juego

Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (si el almacenamiento es similar a Postgres): por 'occurred _ at'.
Resultado: los mejores juegos K/hora - sub-segundo en la caché caliente.

11. 3 RG/AML: eventos de restricciones/autoexclusiones

Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: «restricciones activas en 30 días» + materialización de nivel de usuario sin PII.
Resultado: muestras rápidas para el cumplimiento sin un análisis completo de mil millones de eventos.

11. 4 Antifraude: rutas y dispositivos

Materialización JSON→kolonki: 'device. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Índice vectorial: embeddings "comportamiento de depósitos por 7d' → k-NN rápido para anomalías similares.

12) Seguridad y privacidad

Zero-PII en campos indexados y logotipos de planes.
Cifrado en disco: los índices/estadísticas se cifran de la misma manera que los datos.
K-anonimato de las unidades: MV/proyecciones sólo publican grupos de ≥N.
Geo/tenant-aislamiento: los lotes/llaves incluyen 'brand/country/license'.
Legal Hold: los índices/manivelas también caen en la «congelación».

13) Anti-patrones

Indexar «todo en fila» → explosión de volumen y amplificación de escritura.
Lotes pequeños (hora/minutos) → una tormenta de listones y «archivos pequeños».
Claves de ordenación que no coinciden con los filtros de → de skipping de datos cero.
Falta de estadísticas → malos planes, full scan.
JSON sin índices de ruta y sin materializar atributos «calientes».
Ignorar compacciones y recluster → degradación en 2-4 semanas.

14) Plantillas (listas para usar)

14. 1 Política de agrupamiento/indexación (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 Plan de Compacción del Lago (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 Índices para campos 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 monitoreo de índices

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) Hoja de ruta para la implementación

0-30 días (MVP)

1. Recopilar el N superior de consultas y perfiles de escaneo.
2. Lotes por fecha + ordenaciones acordadas con los filtros.
3. Habilitar datos skipping (min-max) y bloom para campos de identificación.
4. Un MV para la métrica «caliente» (payments 7d).
5. Dashboard SLI: p95, scanned bytes, skipped share, pequeños archivos.

30-90 días

1. Rutas JSON: índices invertidos + materialización.
2. Lago: Compactación y Z-order/clustering en 2-3 llaves.
3. Autocompletador de llaves/proyecciones; ANALYZE regular.
4. Revisión de lotes (day→week) donde «archivos pequeños».

3-6 meses

1. Catálogo de MV/proyecciones con versionados y SLA.
2. Índices vectoriales para recomendaciones/antifraude.
3. Política única de SLO y presupuestos $/solicitud; alertas de degradación.
4. Auditoría de la privacidad de los índices, aislamiento geo/tenant.

16) RACI

Plataforma de datos (R): lotes/índices/compacciones, asesores automáticos, monitoreo.
Analytics/BI (R): MV/proyecciones para dashboards, perfiles de consultas.
Dominios (C): criterios para los cortes y filtros «calientes».
Seguridad/DPO (A/R): privacidad, políticas PII, claves geo/tenant.
SRE/Observabilidad (C): SLO/alerting, capacity para compacciones.
Finanzas (C): presupuestos de $/solicitud y ahorros de índices.

17) Secciones relacionadas

Esquemas de datos y su evolución, Validación de datos, Prácticas de DataOps, Análisis de anomalías y correlaciones, API de análisis y métricas, Clusterización de datos, Reducción de dimensión, MLOps: explotación de modelos.

La indexación del almacenamiento analítico es una estrategia en lugar de «crear un índice para todo». Lotes y ordenamientos correctos, skipping de datos y bloom, MV/proyecciones pensadas y un compacto regular proporcionan consultas rápidas y predecibles a un costo controlado y sin riesgos para la privacidad. Para iGaming, esto significa soluciones operativas de pago, proveedores y RG/AML, dentro de los límites de SLA y presupuesto.