Indexação de armazenamento analítico

1) Por que indexar plataforma iGaming

Velocidade dos analistas: os relatórios de GGR/NET, Conversões, RG/AML e A/B se encaixam na SLA.
Custo: menos bytes escaneados → menor conta de cálculo/armazém.
Confiabilidade p95/p99 estáveis latência e API métricas.
Escala: dezenas de marcas/mercados/PSP/provedores sem «full scan» valor infernal.

2) Modelo de carga (antes de indexar)

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Medidas: 'dim _ user' (sem PII), 'dim _ provider', 'dim _ psp', 'dim _ country'.
Solicitações: «N dias recentes», agregações por 'brand/country/provider/psp', filtros por campo de status, join's por surrogate-keys, busca por atributos JSON (método de pagamento, dispositivo), top-K/percentil.

Escolhemos os índices com base na seletividade, radicalidade e frequência de utilização.

3) Tipos de índice e quando pegá-los

3. 1 Clássico

B-tree: igualdade/faixa em colunas de alto nível ('user _ surrogate _ id', 'accurred _ at', 'amount').
Hash: igualdade pura; menos no analista (contra faixas fracas).
Bitmap: baixa cardealidade e filtros conectados frequentemente ('country', 'kyc _ level', 'rg _ state', 'brand'). Ótimo para somar máscaras.

3. 2 Columnar-especificidades

Min-max (data skipping): Estatísticas automáticas «mínimo/máximo» em parquete-strips/partes → o motor omite blocos. Funciona melhor quando o campo é filtrado.
Índice bloom: testes de probabilidade rápidos para o valor de pertencimento no bloco (útil para 'user _ id', 'direction _ id', 'psp').
BRIN (Block Range Index): «ponteiros» baratos para as faixas de blocos se os dados forem naturalmente ordenados (tempo). Barato, mas eficaz para time-series.

3. 3 Avançados/especializados

GiST/GIN (invertido): JSON/arrays/texto, filtros sobre atributos anexos ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Project (ClickHouse/MPP): Materiais de aceleração de join/agg (pré-join key armazenados ao lado do fato, agregações preliminares).
Vetores (ANN): pesquisa de embeddings semelhantes (recomendação/comportamento antifrod) - IVF/HNSW/Flat como «índice de vizinhos próximos».
Organizar/Z-order (lakehouse/Databricks )/Cluster keys/ORDER BY (ClickHouse): Clusterização de dados em disco multifuncional para melhor data skipping.

4) Particionamento, triagem, clusterização

Partições (data/country/brand): grandes (dia/semana) para evitar «maldição de arquivos pequenos». Selecione campos de alta seletividade no WHERE/permissões.
«ORDER BY (occurred _ at, brand, psp)» ou Z-order por «(brand, country, provider)» - de modo que o min-max e o bloom funcionem melhor.
Cluster/Reluster: Reclasterização periódica para manter a localidade.
TTL e Retensno: remoção automática de partituras/segmentos antigos.

5) Representações e projeções materializadas

MV para cortes quentes: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Suporte modificado (streaming upserts).
Projeções (ClickHouse )/Agregate táveis: agrupamentos preliminares, níveis roll-up (chas→den→nedelya).
Cachê de resultados: query result cache/warehouse result cache para dashboards repetíveis (valendo-se pelo token e pela frescura de dados).

6) Dados semi-estruturados (JSON/VARIANT)

Índice invertido/GIN nas vias json ('$ .device. os`, `$.psp. details. method`).
Materializar atributos importantes em colunas: para filtros estáveis (método de pagamento, dispositivo, versão do aplicativo).
Estatísticas de chave: Coletar distribuições para o plano seletivo.

7) Lagos de dados: Iceberg/Delta/Hudi

Índice de Manifest: metadados de parquinho (min-max, null-count, bloom) → partition pruning + flash skipping.
Compactação/combinação de arquivos: merge arquivos pequenos regularmente em tamanho «ideal» (128-1024 MB).
Clustering/Z-order: Readequação de arquivos para campos de correlação (por exemplo, 'brand, country, occurred _ at').
Índice Delete/Update: delts de posição e bloom para acelerar o merge-on-read.

8) Como escolher os índices: folha de cheque prática

1. Recolha o top N de solicitações (90% da carga) → campos de filtros/join/group.
2. Para cada campo, avalie a seletividade 'seletiva = 1 - distinct (valor )/rows' e a radicalidade.
3. Partição de tempo + 1-2 medição com filtros/acessibilidade estáveis.
4. Ordens/cluster keys concordar com filtros e chaves join.
5. Adicione bloom para ID pontual, bitmap para baixa cardealidade.
6. Agregações quentes → MV/projeções.
7. Caminhos JSON → índices invertidos + materialização.
8. Os lagos são compactados e clustering programados.
9. Digite SLO: p95 latência, bytes/consulta digitalizados, porção de dados skipped.

9) Suporte e manutenção

ANALYZE/estatística: Atualize as radicalidades e histogramas; senão o otimista é cego.
VACUUM/OPTIMIZE/RECLUSTER: Desfragmentação e reclasterização.
Monitorar o uso dos índices: «covering rate», «unused index list», «bytes scanned/bytes skipped».
Conselheiros automáticos: recomendações periódicas sobre chaves de cluster e triagem baseadas em query jobs.
Testes de regressão - Antes do depósito de novas chaves - comparação entre o perfil de solicitação e o custo.

10) Métricas e indexações SLO

Técnico: p95/p99 latency, scanned bytes/query, skipped bytes%, files touched, cachê hit-rate.
Economia: $/consulta, $/dashboard, $/TB scan.
Operações: tempo de compactuação, fila de reposicionamento, proporção de «arquivos pequenos».
Qualidade dos planos: proporção de pedidos que utilizam índices/projeções, precisão de cardealidades.

11) Mala de iGaming (receitas prontas)

11. 1 Pagamentos/PSP: queda/rejeição

«by day». Triagem: '(brand, country, occurred _ at)'.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
Resultado: p95 com 8. 2s a 1. 1s, scanned bytes ↓ на 87%.

11. 2 Rodadas de jogo: provedor/jogo

Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (se Postgres for um armazenamento semelhante): por 'occurred _ at'.
Resultado: Top K de jogos/hora - sub-segundo em disco de armazenamento.

11. 3 RG/AML: eventos de restrição/auto-exclusão

Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: «restrições ativas em 30 dias» + materialização do nível user sem PII.
Resultado: amostras rápidas para complacência sem full scan bilhões de eventos.

11. 4 Antifrode: rotas e dispositivos

Materialização: 'device. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Índice vetorial: embeddings «comportamento de depósito por 7d» → rápido k-NN para anomalias semelhantes.

12) Segurança e privacidade

Zero-PII em campos indexados e logs de planos.
Criptografia em disco: os índices/estatísticas são criptografados da mesma forma que os dados.
O anonimato K das unidades: MV/projeções só é publicado por grupos de ≥N.
Geo/tenant-isolamento: partitações/chaves incluem 'brand/country/license'.
Legal Hold: os índices/manves também entram em «congelamento».

13) Anti-pattern

Indexar «tudo» → explosão de volume e write-amplificação.
Pequenas partições (hora/minuto) → barras de tempestade e «arquivos pequenos».
Chaves de triagem que não correspondem aos filtros de dados de skipping zero.
Falta de estatísticas → planos ruins, full scan.
JSON sem índice de viagem e sem materializar atributos quentes.
Ignorar compactações e reluster → degradação em 2-4 semanas.

14) Modelos (pronto para uso)

14. 1 Políticas de clusterização/indexação (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 Plano de Compacção do 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 de monitoramento 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) Mapa de trânsito de implementação

0-30 dias (MVP)

1. Coleta o top N de solicitações e perfis de digitalização.
2. Particionamento por data + triagem compatível com filtros.
3. Incluir o data skipping (min-max) e o bloom para os campos de ID.
4. Um MV para métricas «quentes» (payments 7d).
5. Dashboard SLI: p95, scanned bytes, skipped share, small files.

30 a 90 dias

1. Caminhos JSON: índices invertidos + materialização.
2. Lago: Compactação e Z-order/clustering a 2-3 chaves.
3. Conselheiro automático de chaves/projeções; ANALYZE regular.
4. Revisão de partituras (day→week) onde «arquivos pequenos».

3-6 meses

1. Catálogo MV/projeções com versioning e SLA.
2. Índices vetoriais para recomendações/antifrode.
3. Política SLO unificada e orçamentos $/consulta; alertas de degradação.
4. Auditoria da privacidade dos índices, geo/tenant-isolamento.

16) RACI

Data Plataforma (R): partitações/índices/compactações, conselheiros automáticos, monitoramento.
Analytics/BI (R): MV/projeções sob dashboard, perfilando solicitações.
Domain Owners (C): critérios de corte e filtros «quentes».
Segurança/DPO (A/R): privacidade, políticas PII, geo/chaves de tenante.
SRE/Observabilidade (C): SLO/alerting, capasiti para compactos.
Finance (C): orçamentos $/consulta e poupança de índice.

17) Seções relacionadas

Os circuitos de dados e sua evolução, Validação de Dados, as Práticas, Análise de Anomalias e Correlações, API Analistas e Métricas, Clusterização de Dados, Redução de Dimensões, MLOs: Operação de modelos.

Resultado

Indexar o armazenamento analítico é uma estratégia, não «criar um índice para tudo». Partituras e triagens corretas, data skipping e bloom, projeções MV elaboradas e compactuação regular oferecem consultas rápidas e previsíveis a um custo controlado e sem risco de privacidade. Para iGaming, isso significa soluções operacionais para pagamentos, provedores e RG/AML - dentro da SLA e do orçamento.