Vaqtinchalik qatorlarni saqlash

1) Nega vaqtinchalik qatorlar uchun alohida arxitektura

• Yozuvlarning yuqori tezligi (ingest) va davriyligi.
• Vaqt diapazoni boʻyicha oʻqishlar (scan + agregatlar/deraza funksiyalari).
• Yorliqlar kombinatsiyasi tufayli portlovchi kardinallik.
• Retenshn (saqlash muddati bo’yicha cheklovlar) va downsampling (vaqt bo’yicha siqilish) zarurati.
• Shu yerdan - maxsus saqlash modeli, kompresssiya formatlari va so’rovnomalar protokollari.

2) Ma’lumotlar modeli va kontrakt metriklari

2. 1 Nomi va teglari

metric_name: feʼl/ot (’http _ requests _ total’,’cpu _ usage _ seconds _ total’).
labels: kalit-atributlar (’job’,’instance’,’dc’,’pod’,’status’,’method’).
Invariantlar: Nomning semantikasini oʻzgartirmaslik, mos kelmaydigan oʻzgarishlarda (’metric _ v2’) versiyasini qoʻshish.

2. 2 Qator turlari

Gauge (rasm), Counter (ortib boruvchi yakun), Histogram/Summary (taqsimot/kvantili), Event/Span (treys-nuqtalar).
Moliya/zichliklar uchun - o’lchov birliklari va agregatsiyalanuvchanlikni qayd qiling (jamlanadi/o’rtacha).

2. 3 Retenshn va rollaplar siyosati

Issiq detalizatsiya (soniya/1-10 min) → issiq agregatlar (5m/1h) → sovuq (1d/1w).
Counter uchun - rate/deriv agregatlarini saqlash.

3) Yozish yo’li: qabul qilish, buferlash, kompakt

3. 1 Ingest-paypline

Scrape (pull, Prometheus) yoki push (OTLP/StatsD/Graphite), koʻpincha gateway/agent orqali.
WAL (write-ahead log) da buferlash, so’ngra segmentlarga/bloklarga kompaksiya (LSM-ga o’xshash arxitektura).
Batching va vaqt boʻyicha saralash siqilish va tezlikni oshiradi.

3. 2 Out-of-order va dubllarni qayta ishlash

Ruxsat oynasi (lateness window, masalan, 5-15 min) +’drop | upsert | keep-last’siyosati.
’(series_id, timestamp)’ ning versiyaligi yoki «oxirgi yozuv g’alaba qozonadi».

3. 3 Siqish

Vaqt belgilari uchun Delta-of-delta, float uchun Gorilla/XOR, butun uchun RLE va varint, teglar uchun dictionary.
Blokning maqbul o’lchami («chanka») 1-8K nuqtalar - IOPS va CPU o’rtasidagi murosadir.

4) Saqlash sxemalari: TSDB vs SQL/kolonochniki

4. 1 Ixtisoslashtirilgan TSDB

Prometheus (lokal, qisqa retenshn, PromQL, remote_write).
VictoriaMetrics/M3/InfluxDB - gorizontal kattalashtirish, uzoq retenshn, remote read.
Bloklarning formatlari range scan + tending agregatsiyalari uchun optimallashtirildi.

4. 2 Relyasion/kolonochnыe dvigatelki

TimescaleDB (PostgreSQL): gipertablitslar, vaqt/boʻshliq boʻyicha chankalar, continuous aggregates.
ClickHouse: MergeTree/TTL/materiallashtirilgan tasavvurlar, ajoyib siqish va vaqt bo’yicha agregatsiyalar.
Tanlash - so’rovlar ekotizimi (SQL vs PromQL), join/BI talablari va jamoaning operatsion ko’nikmalari bo’yicha.

5) Sxema va misollar

5. 1 TimescaleDB: gipertablits + continuous aggregate

sql
CREATE TABLE metrics_cpu(
ts timestamptz NOT NULL,
host text NOT NULL,
dc text NOT NULL,
usage double precision NOT NULL,
PRIMARY KEY (ts, host, dc)
);
SELECT create_hypertable('metrics_cpu', by_range('ts'), chunk_time_interval => interval '1 day');

-- Continuous unit (5 minutes)
CREATE MATERIALIZED VIEW cpu_5m
WITH (timescaledb. continuous) AS
SELECT time_bucket('5 minutes', ts) AS ts5m, host, dc, avg(usage) AS avg_usage
FROM metrics_cpu GROUP BY 1,2,3;

-- Politicians
SELECT add_retention_policy('metrics_cpu', INTERVAL '14 days');
SELECT add_retention_policy('cpu_5m',   INTERVAL '180 days');

5. 2 ClickHouse: saqlash

sql
CREATE TABLE metrics_cpu (
ts DateTime,
host LowCardinality(String),
dc LowCardinality(String),
usage Float32
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (host, dc, ts)
TTL ts + INTERVAL 14 DAY
SETTINGS index_granularity = 8192;

-- Rollup in hourly detail
CREATE MATERIALIZED VIEW cpu_1h
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (host, dc, ts)
POPULATE AS
SELECT toStartOfHour(ts) AS ts, host, dc, avg(usage) AS usage
FROM metrics_cpu GROUP BY ts, host, dc;

5. 3 Prometheus/VictoriaMetrics: remote_write

yaml global:
scrape_interval: 15s remote_write:
- url: http://vminsert:8480/insert/0/prometheus/api/v1/write

6) Kardinallik: qanday qilib omborxonani «portlatmaslik»

6. 1 Qoidalar

Label cardinality (noyob qiymatlar soni) ni cheklang. ’user _ id’,’request _ id’,’trace _ id’qoʻshilmaydi.
«Koʻp maʼnoli» teglarni (kategoriyalar → kodlar) normallashtiring.
LowCardinality turlaridan (CH), lugʻat/daraxtlardan (TSDB) foydalaning.

6. 2 Nazorat va alertlar

Metriklar:’series _ count’,’label _ values {label}’, top-N «qimmat» qatorlar.
per tenant/job.

6. 3 Hikoyalar/gistogrammalar

high-cardinality uchun agregatlar (histogram buckets) va pre-rolrupni saqlash yaxshiroqdir; kvantillarni agregatlarda onlayn hisoblash.

7) Retenshn, downsampling va tiered-storage

7. 1 Siyosat

Hot: 3-30 kunlik/daqiqalik tafsilotlar.
Warm: 90-365 kun 5m/1h agregatlar.
Cold: kunduzgi agregatlar yillari, Parquet bilan obyekt saqlovidagi arxiv (S3/Glacier).

7. 2 Texnika

Continuous aggregates (Timescale), materiallashtirilgan tushunchalar (CH), retention + rollub tasks (Victoria/M3/Influx).
Tiered storage: «issiq bloklar» lokal, «sovuq bloklar» lokal keshli obʼektda.

8) So’rovlar va tillar

8. 1 PromQL (misol)

promql rate(http_requests_total{job="api",status=~"5.."}[5m])

API bilan 5xx xato tezligini qidirmoqdamiz.

8. 2 SQL-agregatlar

sql
SELECT time_bucket('1h', ts) AS hour,
dc, avg(usage) AS avg, max(usage) AS pmax
FROM metrics_cpu
WHERE ts >= now() - interval '24 hours'
GROUP BY 1,2 ORDER BY 1;

8. 3 Anomaliyalar (eskiz)

deraza statistikasi bo’yicha Z-score/ESD, mavsumiylik STL-dekompozitsiyasi; natijalarni alohida’anomaly = 1/0’qatorida saqlash.

9) Integratsiya va bayonnomalar

OTLP (OpenTelemetry): metriklar/treyslar/loglar, eksport qiluvchi agentlar (otel-collector) → TSDB/klikxaus/obyekt.
StatsD/Graphite: oddiy hisoblagichlar/taymerlar; edge proksi, keyingi o’rinlarda yagona formatga konvertatsiya qilinadi.
Kafka/NATS: ingest portlashlari uchun bufer, bekfill uchun replayer; konsumerlar batch bilan yozadilar.

text kafka(topic=metrics) -> stream processor (normalize/tags) -> CH INSERT INTO metrics_cpu FORMAT RowBinary

10) Foydalanish imkoniyati, HA va federatsiya

Replica/HA-juftliklar TSDB yoki Prometheus federatsiyasi (mintaqa darajasi → global).
Uzoq muddatli saqlash va markazlashtirilgan dashbordlar uchun Remote read/write.
Shard-by-label/time: ingest, locality’dc/tenant’bo’yicha bir tekis taqsimlanishi.

11) Omborning o’zi kuzatilishi

11. 1 Metrika

Ingest: `samples/sec`, `append_latency`, `wal_fsync_ms`.
Хранение: `blocks_count`, `compaction_queue_len`, `chunk_compression_ratio`.
Запросы: `query_qps`, `scan_bytes`, `p95/p99_latency`, `alloc_bytes`.
Kardinalligi:’series _ count’, top-labels.

11. 2 SLO

«QPS ≤ 500 da 1h ≤ 200 ms diapazoni uchun p99 latency».
«Ingest-drop ≤ 0. 01% da burst to X samples/sek".
«Compaction backlog < 10 min».

11. 3 Alertlar

’series _ count’> %/soat.
Kompaksiya/flush> chegarasi.
Доля out-of-order > N%, dedup/late-drops.

12) Xavfsizlik va ko’p tenantlik

Izolyatsiya bo’yicha’tenant’(kalitlardagi leybl, alohida jadvallar/bazalar, kvotalar).
Belgilarni sanitarlashtirish (PII taqiqlash), o’lchamlarini/qiymatlarini nazorat qilish.
«Tinch» va transportda shifrlash, «sezgir» metriklardan foydalanish auditi.

13) Ekspluatatsiya amaliyotlari

Isitish va sovuq boshlash: keshdagi «issiq» bloklarning pin, oxirgi N soat prefetch.
Backfill: Past ustuvorlikdagi alohida payplaynlarni onlayn bilan aralashtirmaslik.
Sxemani versionlash: parallel yozuv (dual-write) va keyingi svitch bilan migratsiya.
Saqlash budjeti: nazorat’cost _ per _ TB _ month’+ forecast o’sish kardinalligi.

14) Anti-patternlar

Yuqori kardinallikka ega teglar (user_id, uuid) → qator portlashi.
Retenshnasiz «abadiy» qatorlar → nazoratsiz o’sish.
Batching/saralashsiz yozish → yomon siqish va IOPS bo’roni.
OLTP va uzun skanerlarni bitta disk hovuzida aralashtirish.
Out-of-order siyosatining yo’qligi → dublikatlar va shishirish.
Gistogrammalar yuzlab baketalar bilan → qiymati × 10 foydasiz.

15) Joriy etish chek-varaqasi

• Metriklarni, ularning turlari va birliklarini aniqlang; nomlar/yorliqlar shartnomasini tuzing.
• Dvigatel (TSDB vs SQL/ustuncha) va soʻrov tilini (PromQL/SQL) tanlang.
• Retenshn/rollap (hot/warm/cold) va ILM tasmalarini loyihalashtiring.
• Ingest: WAL/batchi/saralash, out-of-order oynalarini moslash.
• Siqishni yoqing (delta-of-delta/XOR/RLE), optimal changlar.
• Kardinallikni nazorat qiling: kvotalar, alertlar, rad etish siyosati.
• NA/federatsiya va remote-write/ni sozlang.
• SLO dashbordlari va saqlash metrikasi (ingest/query/storage).
• Xavfsizlik/tenant-izolyatsiya siyosati va yorliqlarda PII yo’qligi.
• Muntazam «game day»: backfill, tugun yoʻqolishi, ingest koʻtarilishi.

16) FAQ

Q: Infratuzilmani kuzatish uchun nimani tanlash kerak: Prometheus yoki ClickHouse/Timescale?
A: Milliy monitoring va PromQL uchun - Prometheus + uzoq storage (Victoria/M3). BI/ombor stsenariylari va SQL uchun - Timescale/ClickHouse.

Q: Kvantillarni og’ir summarisiz qanday saqlash kerak?
A: histogrammadan toza baketalar bilan foydalaning va so’ralganda kvantillarni hisoblab chiqing; yoki agregatlarda t-digest/CKMS.

Q: out-of-order bilan nima qilish kerak?
A: Kirish oynasini (5-15 daqiqa) va determinatsiyalangan dedup siyosatini kiriting; mobil/edge telemetriya uchun - kengroq oyna.

Q: Rollup qachon kerak?
A: Har doim retenshn bilan> 30-90 kun: agregatlar 10-100 × hajmini kamaytiradi va tahlilni tezlashtiradi.

Q: Loglar va metriklarni aralashtirish mumkinmi?
A: Alohida saqlang (turli formatlar/so’rovlar). Korrelyatsiya uchun Exemplar/TraceID va dashbordlardan foydalaning, lekin hamma narsani bitta jadvalga qoʻshmang.

17) Yakunlar

Vaqtinchalik qatorlarning samarali ombori - bu metrik kontrakt + teglar intizomi, malakali ingest (WAL/kompaksiya), siqish va retenshna/rollaplar siyosati. Kardinallik nazorati, NA/federatsiya va storning o’zi kuzatilishini qo’shing - va siz oldindan aytib bo’ladigan p95, oylar-yillar uchun oqilona qiymat va ko’tarilishlarga chidamlilik olasiz.