Müvəqqəti sıraların saxlanması

1) Niyə zaman sıraları üçün ayrı memarlıq

• Yüksək sürətli qeydlər (ingest) və dövri.
• Zaman diapazonuna görə oxunmalar (scan + aqreqatlar/pəncərə funksiyaları).
• Etiketlərin kombinasiyasına görə partlayıcı kardinallıq.
• Retenshn (saxlama müddəti məhdudiyyətləri) və downsampling (vaxt sıxılması) ehtiyacı.
• Buradan - xüsusi saxlama modeli, sıxılma formatları və sorğu protokolları.

2) Data modeli və metrik müqavilə

2. 1 Ad və etiketlər

metric_name: tək fiil/isim ('http _ requests _ total', 'cpu _ usage _ seconds _ total').
labels: açar atributları ('job', 'instance', 'dc', 'pod', 'status', 'method').
İnvariantlar: Uyğunsuz dəyişikliklər zamanı ad semantikasını dəyişdirməyin, versiyalar əlavə etməyin ('metric _ v2').

2. 2 Sıra növləri

Gauge, Counter, Histogram/Summary, Event/Span.
Maliyyə/sıxlıqlar üçün - ölçü vahidləri və yığılabilirliyi qeyd edin (ümumiləşdirilmiş/orta).

2. 3 Retenshn və Rollap siyasəti

İsti detal (saniyə/1-10 dəq) → isti aqreqatlar (5m/1h) → soyuq (1d/1w).
counter üçün - rate/deriv aqreqatları saxlamaq.

3) Yazma yolu: qəbul, tamponlama, kompakt

3. 1 Ingest-paypline

Scrape (pull, Prometheus) və ya push (OTLP/StatsD/Graphite), tez-tez gateway/agent vasitəsilə.
WAL-da tamponlama (write-ahead log), sonra seqmentlərə/bloklara kompaksiya (LSM-oxşar memarlıq).
Batching və vaxt sıralama sıxılma və sürət artırır.

3. 2 Out-of-order və dubl emalı

Giriş pəncərəsi (məsələn, 5-15 dəq) + siyasət: 'drop | upsert | keep-last'.
'(series_id, timestamp)' versiyasına və ya 'son qeyd qazanır'.

3. 3 Sıxılma

Zaman işarələri üçün Delta-of-delta, float üçün Gorilla/XOR, RLE və bütün üçün varint, etiketlər üçün dictionary.
Optimal blok ölçüsü («tank») 1-8K nöqtələr - IOPS və CPU arasında kompromis.

4) Saxlama sxemləri: TSDB vs SQL/sütunlar

4. 1 Xüsusi TSDB

Prometheus (yerli, qısa retenshn, PromQL, remote_write).
VictoriaMetrics/M3/InfluxDB - üfüqi miqyaslandırma, uzun gecikmə, remote read.
Blokların formatları range scan + tendinq aqreqasiyaları üçün optimallaşdırılmışdır.

4. 2 Relation/sütun mühərrikləri

TimescaleDB (PostgreSQL): hiper tabletlər, zaman/məkan, continuous aggregates.
ClickHouse: MergeTree/TTL/materiallaşdırılmış performans, əla kompressiya və vaxt yığılması.
Seçim - sorğu ekosistemi (SQL vs PromQL), join/BI tələbləri və komandanın əməliyyat bacarıqları.

5) Sxem və nümunələr

5. 1 TimescaleDB: hipertahnaz + 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: yığma saxlama

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) Kardinallıq: anbarı necə «partlatmamaq»

6. 1 Qaydalar

label cardinality (unikal dəyərlərin sayı) məhdudlaşdırın. 'user _ id', 'request _ id', 'trace _ id' daxil etməyin.
«Çoxmənalı» etiketləri normallaşdırın (kateqoriyalar → kodlar).
LowCardinality növləri istifadə edin (CH), lüğət/ağac işarələri (TSDB).

6. 2 Nəzarət və Alertlər

Metriklər: 'series _ count', 'label _ values {label}', top-N «bahalı» sıralar.
per tenant/job.

6. 3 Hekayələr/histoqramlar

High-cardinality üçün aqreqatları (histogram buckets) və pre-rollup saxlamaq daha yaxşıdır; quantiles aqreqatları online hesablamaq.

7) Retenshn, downsampling və tiered-storage

7. 1 Siyasət

Hot: 3-30 gün saniyə/dəqiqə detal.
Warm: 90-365 gün 5m/1h aqreqat.
Cold: Parquet ilə illik gündəlik aqreqatlar, obyekt saxlama arxivi (S3/Glacier).

7. 2 Texnika

Continuous aggregates (Timescale), materiallaşdırılmış performans (CH), retention + rollub tasks (Victoria/M3/Influx).
Tiered storage: «isti bloklar» yerli, yerli cache ilə obyektdə «soyuq».

8) Sorğular və dillər

8. 1 PromQL (nümunə)

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

API ilə 5xx səhv sürətini axtarırıq.

8. Pəncərələrə görə 2 SQL aqreqatları

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)

Z-score/ESD pəncərə statistikası, STL-mövsümi dekompozisiya; nəticələri ayrı bir sırada saxlamaq 'anomaly = 1/0'.

9) Inteqrasiya və protokollar

OTLP (OpenTelemetry): metriklər/treys/log, agent ixracatçıları (otel-collector) → TSDB/klikhaus/obyekt.
StatsD/Graphite: sadə sayğaclar/zamanlayıcılar; edge proxy, sonra - vahid formata çevirmək.
Kafka/NATS: ingest sıçrama tamponu, backfill üçün replayer; konsumerlər batch yazırlar.

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

10) Əlçatanlıq, HA və federasiya

Replica/HA-cüt TSDB və ya Prometheus Federasiyası (region → global səviyyəsi).
Uzunmüddətli saxlama və mərkəzləşdirilmiş daşbordlar üçün Remote read/write.
Shard-by-label/time: vahid paylanması ingest, locality 'dc/tenant'.

11) Anbarın özünün müşahidə edilməsi

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`.
Kardinallıq: 'series _ count', top-labels.

11. 2 SLO

«QPS ≤ 500-də 1h ≤ 200 ms diapazonu üçün p99 latency».
«Ingest-drop ≤ 0. 01% X samples/sec qədər burst ilə".
«Compaction backlog < 10 min».

11. 3 Alertlər

Artım 'series _ count'> %/saat.
kompaksiya növbəsi/flush> eşik.
Доля out-of-order > N%, dedup/late-drops.

12) Təhlükəsizlik və çox tenant

'tenant' ilə izolyasiya (açar etiketi, ayrı-ayrı cədvəllər/bazalar, kvotalar).
Etiketlərin sanitarlaşdırılması (PII qadağası), ölçülərə/dəyərlərə nəzarət.
«Rahat» və nəqliyyatda şifrələmə, «həssas» metriklərə giriş auditi.

13) Əməliyyat təcrübələri

Isınma və soyuq başlanğıc: pin «isti» blokları cache, son N saat prefetch.
Backfill: aşağı prioritet fərdi paylaynlar, online ilə qarışdırmaq deyil.
Sxemin versiyalaşdırılması: paralel yazma (dual-write) və sonrakı yazma ilə miqrasiya.
Saxlama büdcəsi: nəzarət 'cost _ per _ TB _ month' + kardinallıq artımının forecast.

14) Anti-nümunələr

Yüksək kardinallığı ilə Tags (user_id, uuid) → sıra partlayış.
Retenshna → nəzarətsiz böyümə olmadan «əbədi» sıralar.
Heç bir batching/sıralama → pis sıxılma və IOPS fırtına qeyd.
OLTP və uzun skanları bir hovuz diskində qarışdırın.
Out-of-order siyasətinin olmaması → dublikatlar və şişirtmə.
Yüzlərlə bahalı histoqramlar → dəyəri × 10 faydasız.

15) Giriş çek siyahısı

• Metrikləri, onların növlərini və vahidlərini müəyyən edin; ad/etiket müqaviləsini qeyd edin.
• Mühərriki seçin (TSDB vs SQL/sütun) və sorğu dili (PromQL/SQL).
• Retrenshn/rollap (hot/warm/cold) və ILM daşları dizayn edin.
• ingest konfiqurasiya: WAL/batches/çeşidləmə, out-of-order pəncərələri.
• Sıxılma daxil edin (delta-of-delta/XOR/RLE), optimal çantalar.
• Kardinallığa nəzarət edin: kvotalar, risklər, imtina siyasəti.
• ON/Federation və remote-write/read.
• SLO Dashboard və saxlama metrikası (ingest/query/storage).
• Təhlükəsizlik siyasəti/tenant izolyasiya və etiketlərdə PII olmaması.
• Müntəzəm «game day»: backfill, düyün itkisi, ingest sıçrayışı.

16) FAQ

Q: infrastruktur monitorinqi üçün nə seçmək lazımdır: Prometheus və ya ClickHouse/Timescale?
A: Native monitorinq və PromQL üçün - Prometheus + uzunmüddətli storage (Victoria/M3). BI/anbar ssenariləri və SQL üçün - Timescale/ClickHouse.

Q: ağır summary olmadan kvantilləri necə saxlamaq olar?
A: Histogramı səliqəli baxetlərlə istifadə edin və tələb edildikdə kvantilləri hesablayın; və ya t-digest/CKMS aqreqatlarında.

Q: out-of-order ilə nə etmək olar?
A: Giriş pəncərəsini (5-15 dəq) və dedup siyasətini daxil edin; mobil/edge telemetriya üçün - daha geniş pəncərə.

Q: Rollup nə vaxt lazımdır?
A: Həmişə 30-90 gün davam edir: aqreqatlar 10-100 × ölçüsünü azaldır və analitikanı sürətləndirir.

S: Log və metrləri qarışdırmaq olarmı?
A: Ayrı saxlayın (formatlar/sorğular fərqlidir). Korrelyasiya üçün Exemplar/TraceID və dashboard istifadə edin, lakin hər şeyi bir cədvələ yığmayın.

17) Nəticələr

Effektiv müvəqqəti sıraların saxlanması metrik müqavilə + etiketlərin nizam-intizamı, səriştəli ingest (WAL/kompaksiya), sıxılma və retenşn/rollap siyasətidir. Kardinallıq nəzarətini, NA/federasiya və storun özünü müşahidə etməsini əlavə edin - və proqnozlaşdırıla bilən p95, aylar və illər üçün münasib dəyər və sıçrayışlara qarşı müqavimət əldə edəcəksiniz.