Indizierung analytischer Speicher

1) Warum die Indexierung der iGaming-Plattform

Analysegeschwindigkeit: Berichte zu GGR/NET, Conversions, RG/AML und A/B-Experimenten passen in SLA.
Kosten: Weniger gescannte Bytes → niedrigere Rechnung für Berechnung/Lager.
Zuverlässigkeit: Stabile p95/p99-Latenz von Dashboards und API-Metriken.
Maßstab: Dutzende Marken/Märkte/PSPs/Anbieter ohne „full scan“ höllischen Wert.

2) Lastmodell (vor der Indizierung)

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Maße: 'dim _ user' (ohne PII), 'dim _ provider', 'dim _ psp', 'dim _ country'.
Abfragen: „letzte N Tage“, Aggregationen nach 'brand/country/provider/psp', Filter nach Statusfeld, Join's nach Surrogate-Keys, Suche nach JSON-Attributen (Zahlungsmethode, Gerät), top-K/percentile.

Wir wählen Indizes basierend auf Selektivität, Kardinalität und Häufigkeit der Verwendung.

3) Arten von Indizes und wann sie zu nehmen sind

3. 1 Klassiker

B-Baum: Gleichheit/Bereiche für hochselektive Spalten ('user _ surrogate _ id', 'occurred _ at', 'amount').
Hash: reine Gleichheit; seltener in der Analytik (gegen die Bereiche schwach).
Bitmap: niedrige Kardinalität und häufig verbundene Filter ('country', 'kyc _ level', 'rg _ state', 'brand'). Ausgezeichnet für die Summierung von Masken.

3. 2 Columnar-Spezifität

Min-Max (Data Skipping): Automatische Minimum/Maximum-Statistiken in Parkettstreifen/Teilen → Die Engine überspringt Blöcke. Es funktioniert besser, wenn es nach gefilterten Feldern sortiert wird.
Bloom-Indizes: schnelle probabilistische Tests der Zugehörigkeit des Wertes im Block (nützlich für 'user _ id', 'transaction _ id', 'psp').
BRIN (Block Range Index): billige „Zeiger“ auf Blockbereiche, wenn die Daten natürlich geordnet sind (Zeit). Billig, aber effektiv für die Zeitreihe.

3. 3 Fortgeschritten/spezialisiert

GiST/GIN (invertiert): JSON/arrays/text, Filter nach verschachtelten Attributen ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Projection (ClickHouse/MPP): Materialien zur Beschleunigung von Join/Agg (Pre-Join-Key wird neben dem Fact gespeichert, Voraggregationen).
Vector (ANN): Suche nach ähnlichen Embeddings (Empfehlungen/Anti-Fraud-Verhalten) - IVF/HNSW/Flat als „Index der nächsten Nachbarn“.
Z-Order/Z-Order (Lakehouse/Databricks )/Cluster Keys (Snowflake )/ORDER BY (ClickHouse): Multidimensionales Clustering von Daten auf der Festplatte für besseres Datenkippen.

4) Partitionierung, Sortierung, Clustering

Parteien (Datum/Land/Marke): groß (Tag/Woche), um den „Fluch der kleinen Akten“ zu vermeiden. Wir wählen Felder mit hoher Selektivität in WHERE/Zugriffsrechten aus.
Sortierung innerhalb der Partei: 'ORDER BY (occurred_at, brand, psp)' oder Z-order by'(brand, country, provider)'- so min-max und bloom arbeiten besser.
Cluster/Recluster: Periodische Umlasterungen zur Aufrechterhaltung der Lokalität.
TTL und Retention: Automatisches Löschen von alten Teilen/Segmenten.

5) Materialisierte Darstellungen und Projektionen

MV für Hot Slices: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Wir unterstützen inkrementell (streaming upserts).
Projektionen (ClickHouse )/Aggregate Tabellen: vorläufige Gruppierungen, Roll-up-Ebenen (chas→den→nedelya).
Der Cache der Ergebnisse: query result cache/warehouse result cache für wiederholt daschbordow (walidirujem nach tokenu der Anfrage und der Frische der Daten).

6) Halbstrukturierte Daten (JSON/VARIANT)

Indizes nach Pfad: invertiert/GIN-Index auf json-Pfaden ('$ .device. os`, `$.psp. details. method`).
Materialisierung wichtiger Attribute in Spalten: für stabile Filter (Zahlungsmethode, Gerät, App-Version).
Schlüsselstatistiken: Sammlung von Verteilungen für einen selektiven Plan.

7) Datenseen: Iceberg/Delta/Hudi

Manifest-Indizes: Metadaten zu Parkettdateien (min-max, null-count, bloom) → partition pruning + file skipping.
Dateikompression/-zusammenführung: regelmäßig kleine Dateien in „optimaler“ Größe zusammenführen (128-1024 MB).
Clustering/Z-Order: Umpacken von Dateien für korrelierende Felder (z.B. 'brand, country, occurred _ at').
Delete/Update-Indizes: Positions-Delts und Bloom zur Beschleunigung von Merge-on-Read.

8) Wie man Indizes auswählt: eine praktische Checkliste

1. Sammeln Sie Top-N-Abfragen (90% der Last) →/join/group-Filterfelder.
2. Bewerten Sie für jedes Feld die Selektivität 'sel = 1 - distinct (value )/rows' und die Kardinalität.
3. Partitur nach Zeit + 1-2 Messungen mit stabilen Filtern/Zugängen.
4. Sortieren/Clusterschlüssel mit Filtern und Join-Schlüsseln koordinieren.
5. Fügen Sie Blüte für Punkt-IDs, Bitmap für niedrige Kardinalität hinzu.
6. Heiße Aggregation → MV/Projektion.
7. JSON-Pfade → invertierte Indizes + Materialisierung.
8. An den Seen gibt es Kompakt- und Clustering nach Fahrplan.
9. Geben Sie SLO ein: p95-Latenz, gescannte Bytes/Abfrage, Anteil der übergebenen Daten.

9) Unterstützung und Service

ANALYZE/Statistik: Aktualisieren Sie Kardinalitäten und Histogramme; Ansonsten ist der Optimierer „blind“.
VACUUM/OPTIMIZE/RECLUSTER: Defragmentierung und Umlasterung.
Überwachung der Verwendung von Indizes: „covering rate“, „unused index list“, „bytes scanned/bytes skipped“.
Auto-Advisors: Regelmäßige Empfehlungen zu Clusterschlüsseln und Sortierungen basierend auf dem Abfrageprotokoll.
Regressionstests: Vor dem Deploy neuer Schlüssel - Vergleich des Anforderungsprofils und der Kosten.

10) Indizierungsmetriken und SLOs

Technische Daten: p95/p99 Latenz, gescannte Bytes/Query, Skipped Bytes%, Dateien berührt, Cache-Hit-Rate.
Wirtschaft: $/Anfrage, $/Dashboard, $/TB Scan.
Operationen: Kompressionszeit, Splasterwarteschlange, Anteil an „kleinen Dateien“.
Qualität der Pläne: Anteil der Abfragen, die Indizes/Projektionen verwenden, Genauigkeit der Kardinalitäten.

11) iGaming-Fälle (fertige Rezepte)

11. 1 Zahlungen/PSP: Stürze/Ausfälle

Partei: „durch den Tag“. Sortierung: „(Marke, Land, occurred_at)“.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
Ergebnis: p95 ↓ mit 8. 2s bis 1. 1s, scanned bytes ↓ на 87%.

11. 2 Spielrunden: Anbieter/Spiel

Z-order / ORDER BY: `(provider, game_id, occurred_at)`.
Projection/agg: `rounds_1d_by_provider_game`.
BRIN (falls Postgres-ähnlich): durch „occurred _ at“.
Das Ergebnis: Top-K-Spiele/Stunde - Sub-Sekunde auf dem heißen Cache.

11. 3 RG/AML: Beschränkungs-/Selbstausschlussereignisse

Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: „aktive Einschränkungen in 30 Tagen“ + User-Level-Materialisierung ohne PII.
Das Ergebnis: Schnelle Stichproben für Compliance ohne vollständigen Scan einer Milliarde Ereignisse.

11. 4 Fraud: Routen und Geräte

Materialisierung der JSON→kolonki: "device. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Vektorindex: Embeddings „Einzahlungsverhalten für 7d“ → schnelles k-NN für ähnliche Anomalien.

12) Sicherheit und Privatsphäre

Zero-PII in indizierten Feldern und Planprotokollen.
Verschlüsselung auf Festplatte: Indizes/Statistiken werden wie Daten verschlüsselt.
K-Anonymität der Aggregate: MV/Projektionen werden nur von Gruppen von ≥N veröffentlicht.
Geo/tenant-Isolation: Parties/keys include' brand/country/license'.
Legal Hold: Indizes/Manivests fallen ebenfalls in den „Freeze“.

13) Anti-Muster

Indizieren „alles in einer Reihe“ → eine Explosion von Volumen und write-amplification.
Kleine Parteien (Stunde/Minute) → ein Sturm von Balken und „kleine Dateien“.
Sortierschlüssel, die nicht mit den Filtern übereinstimmen → Zero Data Skipping.
Mangel an Statistiken → schlechte Pläne, voller Scan.
JSON ohne Wegindizes und ohne Materialisierung von „heißen“ Attributen.
Ignorieren Sie die Kompositionen und Recluster → Abbau nach 2-4 Wochen.

14) Vorlagen (gebrauchsfertig)

14. 1 Clustering/Indizierungsrichtlinie (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 Lakes Compaction Plan (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 Indizes für JSON-Felder

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 SLOs zur Indexüberwachung

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) Fahrplan für die Umsetzung

0-30 Tage (MVP)

1. Sammeln Sie Top-N-Abfragen und Scanprofile.
2. Partitionierung nach Datum + Sortierung, abgestimmt auf Filter.
3. Aktivieren Sie data skipping (min-max) und bloom für ID-Felder.
4. Ein MV für „heiße“ Metrik (Zahlungen 7d).
5. SLI-Dashboard: p95, gescannte Bytes, gespickte Aktie, kleine Dateien.

30-90 Tage

1. JSON-Pfade: invertierte Indizes + Materialisierung.
2. Lake: Compaction und Z-Order/Clustering mit 2-3 Schlüsseln.
3. Schlüssel/Projektions-Auto-Berater; regelmäßige ANALYSE.
4. Revision der Parteien (day→week), wo „kleine Dateien“.

3-6 Monate

1. Katalog MV/Projektionen mit Versionierung und SLA.
2. Vektorindizes für Empfehlungen/Anti-Fraud.
3. Einheitliche SLO Politik und Budgets $/Anfrage; Alerts von Degradationen.
4. Index Privacy Audit, Geo/Tenant-Isolation.

16) RACI

Data Platform (R): Parteien/Indizes/Kompositionen, Auto-Berater, Überwachung.
Analytics/BI (R): MV/Projektionen für Dashboards, Anforderungsprofile.
Domain Owners (C): Kriterien für „heiße“ Schnitte und Filter.
Sicherheit/DSB (A/R): Datenschutz, PII-Richtlinien, Geo/Tenant-Schlüssel.
SRE/Observability (C): SLO/Alerting, Capacity für Compactions.
Finanzen (C): Budgets $/Anfrage und Einsparungen aus Indizes.

17) Verwandte Abschnitte

Datenschemata und ihre Entwicklung, Datenvalidierung, DataOps-Praktiken, Analyse von Anomalien und Korrelationen, Analyse und metrische APIs, Datenclustering, Dimensionsreduktion, MLOps: Modellauswertung.

Summe

Die Indexierung eines analytischen Tresors ist eine Strategie, nicht „einen Index für alles zu erstellen“. Die richtigen Parties und Sortierungen, Daten-Skipping und Bloom, durchdachte MV/Projektionen und regelmäßige Compaction liefern schnelle und vorhersehbare Anfragen zu kontrollierten Kosten und ohne Risiko für die Privatsphäre. Für iGaming bedeutet dies operative Entscheidungen über Zahlungen, Anbieter und RG/AML - innerhalb von SLA und Budget.