Аналитикалык сактагычтарды индекстөө

1) Эмне үчүн iGaming-платформа индекстөө

Аналитиканын ылдамдыгы: GGR/NET, конверсиялар, RG/AML жана A/B эксперименттери боюнча отчеттор SLAга туура келет.
Баасы: аз сканерлөө байт → эсептөө үчүн төмөнкү эсеп/кампа.
Ишенимдүүлүк: туруктуу p95/p99 жашыруун dashboard жана API метр.
Масштаб: ондогон бренддер/базарлар/PSP/провайдерлер жок "full scan" тозок наркы.

2) жүк модели (индекстөө алдында)

Факты: `payments`, `game_rounds`, `sessions`, `bonus_events`.
Өлчөө: 'dim _ user' (PII жок), 'dim _ provider', 'dim _ psp', 'dim _ country'.
Суроолор: "Акыркы N күн", топтоо 'brand/country/provider/psp', статус талаасы боюнча чыпкалар, surrogate-keys боюнча join's, JSON атрибуттары боюнча издөө (төлөм ыкмасы, түзмөк), top-K/percentile.

Биз тандоо, кардиналдуулугу жана пайдалануу жыштыгына жараша индекстерди тандап.

3) Индекстердин түрлөрү жана аларды алуу үчүн качан

3. 1 классикалык

B-tree: теңдик/жогорку селективдүү колонкалар боюнча диапазондор ('user _ surrogate _ id', 'occurred _ at', 'amount').
Hash: таза теңдик; аз талдоо (алсыз диапазондорго каршы).
Bitmap: төмөн кардиналдуулук жана тез-тез бириктирилген чыпкалар ('country', 'kyc _ level', 'rg _ state', 'brand'). маскаларды жалпылоо үчүн сонун.

3. 2 Columnar өзгөчөлүгү

Min-max (data skipping): паркет-stripes/бөлүктөрүндө автоматтык "минимум/максимум" статистикасы → кыймылдаткыч блокторду өткөрөт. чыпкалоочу талаалар боюнча сорттоо жакшы иштейт.
Bloom-индекстер: тез ыктымалдуулук сыноолорду бирдиги баалуулуктар (үчүн пайдалуу 'user _ id', 'transaction _ id', 'psp').
BRIN (Block Range Index): маалыматтар табигый тартипте болсо, блоктордун диапазондоруна арзан "көрсөткүчтөр" (убакыт). Арзан, бирок убакыт сериясы үчүн натыйжалуу.

3. 3 Advanced/адистештирилген

GiST/GIN (тескери): JSON/arrays/текст, ички атрибуттар боюнча чыпкалар ('metadata. method = 'Papara'`, `device. os in [...]`).
Join/Projection (ClickHouse/MPP): join/agg тездетүү үчүн материалдар (pre-join key чындыкка жакын сакталат, алдын ала топтоо).
Вектордук (ANN): окшош эмбеддингдерди издөө (сунуштар/антифрод жүрүм-туруму) - IVF/HNSW/Flat катары "жакынкы кошуналардын индекси".
Z-иреттөө/Z-order (lakehouse/Databricks )/Cluster keys (Snowflake )/ORDER BY (ClickHouse): мыкты data skipping үчүн көп өлчөмдөгү дисктеги маалыматтарды кластерлөө.

4) Партиялаштыруу, сорттоо, кластерлештирүү

Parties (date/country/brand): ири (күн/жума) "кичинекей файлдарды каргыш" качуу үчүн. WHERE/кирүү укугу жогорку тандоо менен талааларды тандоо.
Партиянын ичиндеги сорттоо: 'ORDER BY (occurred_at, brand, psp)' же Z-order '(brand, country, provider)' - ошентип, min-max жана bloom жакшы иштейт.
Cluster/Recluster: жергиликтүү сактоо үчүн мезгил-мезгили менен кайра.
TTL жана retenshn: эски партияларды/сегменттерди автоматтык түрдө алып салуу.

5) Материалдык түшүнүктөр жана проекциялар

MV ысык кесип үчүн: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider'. Биз инкременталдык колдоо (streaming upserts).
Проекциялар (ClickHouse )/Aggregate tables: алдын ала топтор, roll-up деңгээл (саат → күн → жума).
Натыйжаларды кэш: query result cache/warehouse result cache үчүн кайталануучу дашборддор (суроо-талап токени жана маалыматтардын сергектиги боюнча валидация).

6) Жарым структуралык маалыматтар (JSON/VARIANT)

Жолдор боюнча индекстер: json жолдорунда тескери/GIN-индекси ('$ .device. os`, `$.psp. details. method`).
Маанилүү атрибуттарды колонкаларга материалдаштыруу: туруктуу чыпкалар үчүн (төлөм ыкмасы, аппарат, тиркеменин версиясы).
ачкычтар боюнча статистика: тандоо планы үчүн бөлүштүрүү чогултуу.

7) Маалымат көлдөрү: Iceberg/Delta/Hudi

Манифест-индекстер: паркет-файлдар жөнүндө метадеректер (min-max, null-count, bloom) → partition pruning + file skipping.
Компакция/файлдарды бириктирүү: "оптималдуу" өлчөмдө (128-1024 МБ) чакан файлдарды үзгүлтүксүз сатуу.
Clustering/Z-order: корреляциялоочу талаалар үчүн файлдарды кайра таңгактоо (мисалы, 'brand, country, occurred _ at').
Delete/Update индекстер: чекене-на-окууну тездетүү үчүн positional deltalar жана bloom.

8) Индекстерди кантип тандоо керек: практикалык чек тизмеси

1. Top N суроо чогултуу (90% жүктөө) → чыпкалар талаасы/join/group.
2. Ар бир талаа үчүн 'sel = 1 - distinct (value )/rows' жана кардиналдуулугун баалаңыз.
3. Убакыт боюнча партия + 1-2 туруктуу чыпкалар/жетүү менен өлчөө.
4. сорттоо/кластер keys чыпкалар жана join-ачкычтар менен шайкеш келет.
5. Төмөнкү кардиналдуулук үчүн чекит ID, bitmap үчүн bloom кошуу.
6. Hot агрегациялар → MV/проекциялар.
7. JSON жолдору → тескери индекстер + материалдык.
8. көлдөрдө - compaction жана clustering тартиби боюнча.
9. SLO киргизүү: p95-жашыруун, сканерден байт/суроо, skipped маалыматтар үлүшү.

9) Колдоо жана тейлөө

ANALYZE/статистика: кардиналдык жана гистограммаларды жаңыртуу; болбосо "сокур" оптимизатор.
VACUUM/OPTIMIZE/RECLUSTER: дефрагментация жана кайра кластерлөө.
"covering rate", "unused index list", "bytes scanned/bytes skipped".
Auto-насаатчылар: query log негизинде кластер-ачкычтар жана сорттоо боюнча мезгилдүү сунуштар.
Регрессия сыноолору: жаңы ачкычтарды сактоо алдында - суроо-талаптардын профилин жана наркын салыштыруу.

10) Метрика жана SLO индекстөө

Техникалык: p95/p99 latency, scanned bytes/query, skipped bytes%, files touched, cache hit-rate.
Экономика: $/суроо-талап, $/dashboard, $/TB сканер.
Операциялар: компакция убактысы, кайра кластерлештирүү кезеги, "чакан файлдардын" үлүшү.
Пландардын сапаты: индекстерди/проекцияларды колдонгон суроо-талаптардын үлүшү, кардиналдуулуктун тактыгы.

11) iGaming учурларда (даяр Recipes)

11. 1 төлөмдөр/PSP: кулап/ийгиликсиз

Партия: 'by day'. Сорттоо: '(brand, country, occurred_at)'.
Bloom: `transaction_id`, `user_id`. Bitmap: `psp`, `status`.
MV: `payments_7d_by_brand_psp(status, declines)`.
натыйжасы: p95 ↓ 8 менен. 2s чейин 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' боюнча.
натыйжасы: Top K оюндар/саат - ысык кэш боюнча sub-second.

11. 3 RG/AML: чектөө/өзүн-өзү четтетүү окуялар

Bitmap: `rg_state`, `kyc_level`. JSON-path GIN: `$.reason`.
MV: "30 күндүн ичинде активдүү чектөөлөр" + PII жок user-деңгээл материалдаштыруу.
Натыйжасы: complayens үчүн тез үлгүлөрү жок full scan миллиард окуялар.

11. 4 Антифрод: жолдор жана аппараттар

JSON → колонка материалдык: 'device. os`, `device. model`, `payment. method`.
Bloom: `graph_device_id`. Cluster: `(brand, country, device. os)`.
Вектордук индекс: "7d үчүн депозиттердин жүрүм-туруму" эмбеддингдери → окшош аномалиялар үчүн тез k-NN.

12) Коопсуздук жана купуялык

Zero-PII индекстелген талаалар жана пландардын логдору.
Дисктеги шифрлөө: индекстер/статистика маалыматтар сыяктуу эле шифрленген.
K-жашыруун агрегаттар: MV/проекцияларды ≥ N. топтору гана жарыялайт.
Geo/tenant-изоляция: партия/ачкычтар 'brand/country/license' кирет.
Legal Hold: индекстер/манивесттер да "тоңдурууга" кирет.

13) Анти-үлгүлөрү

индекстөө "баары катары" → жарылуу көлөмү жана write-amplification.
Small Parties (саат/мүнөт) → бороон тилкелери жана "чакан файлдар".
Фильтрлер менен дал келбеген сорттоо ачкычтары → нөл data skipping.
Статистика жоктугу → жаман пландары, толук scan.
JSON жол индекстери жок жана "ысык" атрибуттарды материалдык жок.
Ignor compaction жана recluster → 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. Top N суроолор жана сканерлөө профилдерин чогултуу.
2. Filters менен макулдашылган + сорттоо датасы боюнча партиялаштыруу.
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/clustering.
3. Автоматтык ачкычтар/проекциялар кеңешчиси; үзгүлтүксүз ANALYZE.
4. Партияларды кайра карап чыгуу (day → week) жерде "майда файлдар".

3-6 ай

1. Версиялоо жана SLA менен MV/проекциялардын каталогу.
2. Сунуштар/антифрод үчүн вектордук индекстер.
3. Бирдиктүү SLO саясаты жана бюджеттер $/суроо; деградация аллергиясы.
4. Жеке индекстер аудит, geo/tenant-изоляция.

16) RACI

Маалымат платформасы (R): партиялар/индекстер/компакциялар, авто кеңешчилер, мониторинг.
Analytics/BI (R): MV/дашборддор үчүн проекциялар, суроо-талаптарды кароо.
Domain Owners (C): "ысык" кесип жана чыпкалар критерийлери.
Security/DPO (A/R): купуялык, PII саясаты, geo/tenant ачкычтары.
SRE/Observability (C): SLO/alerting, compaction үчүн capacity.
Finance (C): бюджеттер $/суроо-талап жана индекстерден үнөмдөө.

17) Байланыштуу бөлүмдөр

Маалымат схемалары жана алардын эволюциясы, Маалыматтарды валидациялоо, DataOps-практикалары, Аномалияларды жана корреляцияларды талдоо, Аналитика жана метрика API, Маалыматтарды кластерлөө, Өлчөмдү азайтуу, MLOps: моделдерди иштетүү.

Жыйынтык

Аналитикалык сактоо индекстөө - бул стратегия эмес, "бардыгы үчүн индекс түзүү". Туура партия жана сорттоо, data skipping жана bloom, ойлонулган MV/проекциялары жана үзгүлтүксүз компакция контролдонуучу наркта жана купуялык үчүн тобокелчиликсиз тез жана болжолдуу суроо-талаптарды берет. iGaming үчүн бул төлөмдөр, провайдерлер жана RG/AML боюнча оперативдүү чечимдерди билдирет - SLA жана бюджеттин чегинде.