Indicizzazione dello storage analitico

1) Perché indicizzare la piattaforma iGaming

Velocità di analisi: i rapporti su GGR/NET, conversioni, RG/AML e A/B sono inseriti in SLA.
Costo: meno byte da scansionare, meno fattura da calcolo/magazzino.
Affidabilità p95/p99 stabile latitanza dashboard e API metriche.
Scala: decine di marchi/mercati/PSP/provider senza «full scan» valore infernale.

2) Modello di carico (prima di indicizzare)

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Le misure sono dim _ user (senza PII), dim _ provider, dim _ psp, dim _ country.
Le richieste sono «ultimi N giorni», aggregazioni per «brand/country/provider/psp», filtri per campo di stato, join's per surrogate-keys, ricerca per attributi JSON (metodo di pagamento, dispositivo), top-K/percentile.

Scegliamo gli indici in base alla selettività, alla radicalità e alla frequenza d'uso.

3) Tipi di indici e quando prenderli

3. 1 Classico

B-tree: uguaglianza/intervalli in colonne ad alto livello («user _ surrogate _ id», «occurred _ at», «amount»).
Hash: equità pura; meno frequenti nell'analisi (contro intervalli deboli).
Bitmap: bassa cardinalità e filtri collegati frequenti («country», «kyc _ level», «rg _ state», «brand»). Ottimo per sommare le maschere.

3. 2 Columnar-specificità

Min-max (data skipping) - Le statistiche automatiche «minimo/massimo» nel parquet/parti del motore ignorano i blocchi. Funziona meglio quando si ordina in base ai campi filtrati.
Indici bloom: test rapidi di appartenenza di un valore nel blocco (utili per user _ id, trasmissione _ id, psp).
BRIN (Block Range Index) - Indicatori a basso costo per gli intervalli di blocchi se i dati sono ordinati naturalmente (tempo). Economico ma efficace per le time-series.

3. 3 Avanzati/specializzati

GiST/GIN (invertiti): JSON/arrays/testo, filtri per gli attributi nidificati ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Progection (ClickHouse/MPP) - Materiali per l'accelerazione join/agg (pre-join key memorizzato accanto al dato, aggregazioni preliminari).
Vettoriale (ANN) - Cerca ambedding simili (raccomandazioni/antifrode) - IVF/HNSW/Flat come indice dei vicini più vicini.
Ordinare/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse): clusterizzazione multi-dimensioni dei dati su disco per un miglior data skipping.

4) Partizionamento, ordinamento, clustering

Partizioni (date/country/brand): grandi (giorno/settimana) per evitare la «maledizione dei piccoli file». Seleziona campi ad alta selettività in WHERE/diritti di accesso.
Ordina all'interno della partitura: 'ORDER BY (occurred _ at, brand, psp)' o Z-order per '(brand, country, provider)' - in modo che min-max e bloom funzionino meglio.
Cluster/Recluster - Riclasterizzazione periodica per mantenere la località.
TTL e retensh - Rimozione automatica di partiture/segmenti precedenti.

5) Rappresentazioni e proiezioni materializzate

MV per i tagli hot: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Supporto incrementale (streaming upserts).
Proiezioni (ClickHouse )/Aggregate tabelle: raggruppamenti preliminari, roll-up livelli (chas→den→nedelya).
La cache dei risultati è query result cache/warehouse result cache per i dashboard ripetuti (valutiamo il tocco di query e la freschezza dei dati).

6) Dati semistrutturati (JSON/VARIANT)

Indici percorsi invertiti/GIN sui percorsi json ('$ .device. os`, `$.psp. details. method`).
Materiali degli attributi importanti nelle colonne per filtri stabili (metodo di pagamento, dispositivo, versione dell'applicazione).
Statistiche chiave: raccolta distribuzioni per il piano selettivo.

7) Laghi di dati: Iceberg/Delta/Hudi

Indici manifest: metadati sul parquet (min-max, null-count, bloom) → partition pruning + file skipping.
Compattazione/unione file: merge file di piccole dimensioni regolari in dimensioni «ottimali» (128-1024 MB).
Clustering/Z-order - Rielabora i file per i campi correlati (ad esempio, 'brand, country, occurred _ at').
Indici Delete/Update - Delit di posizione e bloom per accelerare il merge-on-read.

8) Come scegliere gli indici: foglio di assegno pratico

1. Raccogli il top-N delle richieste (90% del carico di lavoro) del campo filtri/join/group.
2. Per ogni campo, valutare la selettività dì sel = 1 - distinct (value )/rows "e la cardinalità.
3. Partizione per tempo + 1-2 misurazioni con filtri/disponibilità stabili.
4. Ordina/cluster keys per concordare con i filtri e le chiavi join.
5. Aggiungi un bloom per gli ID punteggiati, bitmap per la bassa radicalità.
6. Aggregazioni hot MV/proiezione.
7. I percorsi JSON → indici invertiti + materializzazione.
8. I laghi sono compattazione e clustering pianificati.
9. Inserisci SLO: p95 latitanza, byte/query scansionati, quota skipped data.

9) Supporto e manutenzione

ANALYZE/Statistiche - Aggiorna radicalità e istogrammi; Altrimenti l'ottimizzatore è cieco.
VACUUM/OTTIMIZE/RECLUSTER - Deframmentazione e riclasterizzazione.
Monitoraggio dell'utilizzo degli indici: «covering rate», «unused index list», «byts scanned/byties skipped».
Consulenti auto: suggerimenti periodici per cluster e ordinamento basati su query log.
Test di regressione: prima del deposito di nuove chiavi, il confronto tra il profilo delle richieste e il costo.

10) Metriche e SLO indicizzazione

Tecnico: p95/p99 latency, scanned byts/query, skipped byties%, files touched, cache hit-rate.
Economia: $/richiesta, $/dashboard, $/TB scana.
Operazioni: tempo di compilazione, coda di ricasterizzazione, quota di file piccoli.
Qualità dei piani: percentuale di richieste che utilizzano indici/proiezioni, precisione della cardinalità.

11) Case iGaming (prescrizioni pronte)

11. 1 Pagamenti/PSP: caduta/rifiuto

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

11. 2 Giri di gioco: provider/gioco

Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (se Postges è un magazzino simile): «occurred _ at».
Risultato: top K giochi/ora - sub-seconds su cache hot.

11. 3 RG/AML: eventi di restrizione/auto-esclusione

Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: «restrizioni attive in 30 giorni» + materializzazione del livello user senza PII.
Risultato: campionamenti rapidi per la compilazione senza un miliardo di eventi full scan.

11. 4 Antifrode: percorsi e dispositivi

«device». os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Indice vettoriale: embedding «comportamento dei depositi per 7d», rapido k-NN per anomalie simili.

12) Sicurezza e privacy

Zero-PII nei campi e nei fogli di piano indicizzati.
Crittografia su disco: indici/statistiche crittografati come i dati.
K-anonimato unità: MV/proiezioni pubblicano solo gruppi di ≥N.
Isolamento geo/tenant: partenze/chiavi includono «brand/country/license».
Anche gli indici/manivoli finiscono in «congelamento».

13) Anti-pattern

Indicizzare «tutti consecutivi» con un'esplosione di volume e write-amplificazione.
Piccole partenze (ore/minuti), una tempesta di piastrelle e piccoli file.
Chiavi di ordinamento che non corrispondono ai filtri data skipping zero.
La mancanza di statistiche è un pessimo piano, full scan.
JSON senza indici di viaggio e senza materializzare gli attributi hot.
Ignora la compagine e la ricluster per la degradazione in meno di 30 settimane.

14) Modelli (pronto per l'uso)

14. 1 Criteri di clusterizzazione/indicizzazione (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 Piano di compressione 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 Indici per campi 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 di monitoraggio degli indici

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) Road map di implementazione

0-30 giorni (MVP)

1. Raccoglie le richieste Top N e i profili di scansione.
2. Partizionamento per data + ordinamento concordato con i filtri.
3. Abilita data skipping (min-max) e bloom per i campi ID.
4. Un MV per metriche «hot» (payments 7d).
5. Dashboard SLI: p95, scanned byties, skipped share, small files.

30-90 giorni

1. Percorsi JSON - indici invertiti + materializzazione.
2. Lago: compattazione e Z-order/clustering per 2-3 chiavi.
3. Lettore automatico chiavi/proiezioni; ANALYZE regolare.
4. La revisione delle partenze è dove i file sono piccoli.

3-6 mesi

1. Catalogo MV/proiezioni con versioning e SLA.
2. Indici vettoriali per raccomandazioni/antifrode.
3. Un unico criterio SLO e budget $/richiesta; alert di degrado.
4. Controllo della privacy degli indici, isolamento geo/tenant.

16) RACI

Data Platform (R) - Partizioni/indici/compagini, consulenti automatici, monitoraggio.
Analytics/BI (R): MV/proiezioni su dashboard, profilatura delle richieste.
Domain Owners (C) - Criteri di taglio e filtri hot.
Sicurezza/DPO (A/R): privacy, criteri PII, chiavi geo/tenant.
SRE/Osservabilità (C): SLO/alerting, capasiti per compattazioni.
Finanza (C) - Budget $/richiesta e risparmi da indice.

17) Sezioni correlate

Schemi di dati e la loro evoluzione, Validazione dei dati, Utilizzo delle pratiche, Analisi delle anomalie e delle correlazioni, analisi e metriche API, Clustering dei dati, Riduzione delle dimensioni, MLOs: utilizzo dei modelli.

Totale

L'indicizzazione dello storage analitico è una strategia, non un'indice su tutto ". Partiture e ordinamenti corretti, data skipping e bloom, MV/proiezioni elaborate e compattazione regolare offrono richieste rapide e prevedibili a costi controllati e senza rischi per la privacy. Per i clienti, questo significa soluzioni operative per i pagamenti, i provider e RG/AML - entro la SLA e il budget.