Zaman serisinin depolanması

1) Neden zaman serisi için ayrı bir mimari

• Yüksek kayıt hızı (yutmak) ve frekans.
• Zaman aralıklarına göre okur (scan + aggregates/window functions).
• Etiket kombinasyonları nedeniyle patlayıcı kardinalite.
• Tutma ihtiyacı (raf ömrü kısıtlamaları) ve altörnekleme (zaman sıkıştırması).
• Bu nedenle - özel bir depolama modeli, sıkıştırma formatları ve istek protokolleri.

2) Veri modeli ve sözleşme metrikleri

2. 1 Adlandırma ve Etiketler

metric_name: tekil fiil/isim ('http _ requests _ total', 'cpu _ usage _ seconds _ total').
label: öznitelik tuşları ('job', 'instance', 'dc', 'pod', 'status', 'method').
Değişmezler: adın semantiğini değiştirmeyin, uyumsuz değişikliklerle sürümler ('metric _ v2') ekleyin.

2. 2 Satır türleri

Ölçer, Sayaç, Histogram/Özet, Olay/Span.
Finansal/yoğunluklar için - Fix birimleri ve toplanabilirlik (özetlenmiş/ortalama).

2. 3 Tutma ve Toplama Politikası

Sıcak detay (saniye/1-10 dk) - sıcak birimler (5m/1h) - soğuk (1d/1w).
Karşı - mağaza oranı/deriv agregaları için.

3) Kayıt yolu: alım, tamponlama, kompakt

3. 1 Ingest-pipeline

Kazıma (çekme, Prometheus) veya itme (OTLP/StatsD/Grafit), genellikle ağ geçidi/ajan aracılığıyla.
WAL'de arabelleğe alma (ileride yazma günlüğü), ardından segmentlere/bloklara sıkıştırma (LSM benzeri mimari).
Gruplama ve zaman sıralama sıkıştırmayı ve hızı artırır.

3. 2 Sıra dışı ve alır

Tolerans penceresi (gecikme penceresi, örneğin 5-15 dakika) + ilke: 'bırak | upsert | keep-last'.
'(series_id, timestamp)'tarafından veri tekilleştirme, sürüm oluşturma veya "son kayıt kazanır'ile.

3. 3 Sıkıştırma

Zaman damgaları için delta-of-delta, float için Gorilla/XOR, tam sayılar için RLE ve varint, etiketler için sözlük.
1-8K noktalarının en uygun blok boyutu ("yığın"), IOPS ve CPU arasında bir uzlaşmadır.

4) Depolama şemaları: TSDB vs SQL/sütunlar

4. 1 Adanmış TSDB

Prometheus (yerel, kısa tutma, PromQL, remote_write).
VictoriaMetrics/M3/InfluxDB - yatay ölçekleme, uzun tutma, uzaktan okuma.
Blok formatları, aralık tarama + ihale toplama için optimize edilmiştir.

4. 2 İlişkisel/sütun motorları

TimescaleDB (PostgreSQL): hipertabller, zaman/mekana göre parçalar, sürekli agregalar.
ClickHouse: MergeTree/TTL/materyalize görünümler, mükemmel sıkıştırma ve zaman toplama.
Seçim - sorgu ekosistemine göre (SQL vs PromQL), katılma/BI gereksinimleri ve ekip operasyonel becerileri.

5) Şema ve örnekler

5. 1 TimescaleDB: Hypertable + sürekli agrega

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: Depolama Toplama

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) Kardinalite: Depolamayı "havaya uçurmamak"

6. 1 Kurallar

Etiket kardinalitesini sınırlayın (benzersiz değerlerin sayısı). 'User _ id', 'request _ id', 'trace _ id' dahil etmeyin.
"Çok değerli" etiketleri normalleştirin (kategoriler - kodlar).
LowCardinality türlerini (CH'de), sözlükleri/etiket ağaçlarını (TSDB'de) kullanın.

6. 2 Kontroller ve uyarılar

Metrikler: 'Series _ count', 'label _ values {label}', üst-N "pahalı" satırlar.
Kiracı/iş başına kardinalite sınırı aşıldığında başarısızlık politikaları yazın.

6. 3 Tarihler/Histogramlar

Yüksek kardinalite için, agregaları (histogram kovaları) ve ön toplamayı saklamak daha iyidir; Kümeler üzerinde çevrimiçi hesaplamak için niceler.

7) Tutma, altörnekleme ve katmanlı depolama

7. 1 Politikalar

Sıcak: 3-30 gün saniye/dakika detay.
Sıcak: 90-365 gün 5m/1h agrega.
Soğuk: Gün agrega yıl, Parquet ile nesne depolama (S3/Glacier) arşiv.

7. 2 Teknisyenler

Sürekli kümeler (Zaman Ölçeği), maddeleşmiş görünümler (CH), tutma + toplama görevleri (Victoria/M3/Etki).
Katmanlı depolama: Yerel olarak "sıcak bloklar", yerel önbelleğe sahip nesnede "soğuk".

8) Sorgular ve diller

8. 1 PromQL (örnek)

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

5xx API hata oranı aranıyor.

8. Pencerelere göre 2 SQL toplaması

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 Anomaliler (eskiz)

Pencere istatistiklerine göre Z-skoru/ESD, mevsimselliğin STL ayrışması; Sonuçları ayrı bir 'anomali = 1/0' satırında saklayın.

9) Entegrasyonlar ve protokoller

OTLP (OpenTelemetry): metrikler/yollar/günlükler, ajanlar üzerindeki ihracatçılar (otel-toplayıcı) - TSDB/clickhouse/object.
StatsD/Grafit: basit sayaçlar/zamanlayıcılar; Proxy'den kenara, sonra tek bir formata dönüştürme.
Kafka/NATS: yutulan patlamalar için tampon, geri doldurma için replayer; Tüketiciler batchami yazıyor.

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

10) Erişilebilirlik, HA ve Federasyon

Replica/TSDB HA çiftleri veya Prometheus federasyonu (bölge - küresel seviye).
Uzun süreli depolama ve merkezi panolar için uzaktan okuma/yazma.
Shard-by-label/time: 'dc/tenant'tarafından lokalite, yutmak tekdüze dağılımı.

11) Depolamanın kendisinin gözlemlenebilirliği

11. 1 Metrikler

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'.
Cardinality: 'series _ count', üst etiketler.

11. 2 SLO

"1h aralığı için p99 gecikme süresi ≤ QPS≤500 anda 200ms".

"Ingest-drop ≤ 0. X örnekleri/sn öncesi patlamada %01"

"Sıkıştırma birikimi <10 dk".

11. 3 Uyarılar

Büyüme 'series _ count'> Y %/saat.
Sıkıştırma kuyruğu/floş> eşiği.
Доля sıra dışı> N %, dedup/late-drops.

12) Güvenlik ve çoklu kiracılık

'Kiracı'ile izolasyon (anahtarlarda etiket, bireysel tablolar/veritabanları, kotalar).
Etiketlerin sterilizasyonu (PII yasağı), boyut/değer kontrolü.
"Dinlenme've taşıma sırasında şifreleme," hassas "metriklere erişimi denetleme.

13) İşletme uygulamaları

Isınma ve soğuk başlangıç: önbellekteki "sıcak" blokların pimi, son N saatlerinin prefetch'i.
Dolgu: düşük öncelikli bireysel boru hatları, çevrimiçi ile karıştırmayın.
Şema sürüm oluşturma: paralel yazma (çift yazma) ve sonraki anahtarlama ile geçişler.
Depolama bütçesi: 'cost _ per _ TB _ month' kontrolü + kardinalite artışı tahmini.

14) Anti-desenler

Yüksek kardinaliteye sahip etiketler (user_id, uuid) - satırların patlaması.
"Sonsuz" tutmadan sıralar - kontrolsüz büyüme.
Butching/sıralama kaydı - zayıf sıkıştırma ve IOPS fırtınası.
OLTP ve uzun taramaları aynı disk havuzunda karıştırın.
Sıra dışı politika eksikliği - kopyalar ve şişkinlikler.
Yüzlerce kova ile histogramlar - fayda olmadan 10 × maliyet.

15) Uygulama kontrol listesi

• Metrikleri, türlerini ve birimlerini tanımlayın; İsim/etiket sözleşmesini düzeltin.
• Motor (TSDB vs SQL/Column) ve Sorgu Dili (PromQL/SQL) seçin.
• Bir tutma/toplama (sıcak/sıcak/soğuk) ve ILM tasarlayın.
• Alımları yapılandır: WAL/partiler/sıralama, sıra dışı pencereler.
• Sıkıştırmayı açın (delta-of-delta/XOR/RLE), optimal parçalar.
• Kontrol kardinalitesi: kotalar, uyarılar, devre dışı bırakma politikaları.
• HA/federasyon ve uzaktan yazma/okuma yapılandırın.
• SLO panoları ve depolama metrikleri (ingest/query/storage).
• Güvenlik/kiracı izolasyon politikaları ve etiketlerde PII eksikliği.
• Düzenli "oyun günü": doldurma, düğüm kaybı, alım dalgalanması.

16) SSS

S: Altyapı izleme için ne seçilir: Prometheus veya ClickHouse/Timescale?
C: Yerel izleme ve PromQL için - Prometheus + uzun süreli depolama (Victoria/M3). BI/depo senaryoları ve SQL - Timescale/ClickHouse için.

S: Ağır özetler olmadan nicelikler nasıl saklanır?
C: Düzgün kovalarla histogram kullanın ve istendiğinde nicelikleri hesaplayın; veya t-digest/CKMS agregalarda.

S: Sıra dışı ile nasıl başa çıkılır?
C: Tolerans penceresini (5-15 dk) ve deterministik dedup politikasını girin; Mobil/kenardan telemetri için - pencere daha geniştir.

S: Bir toplama ne zaman gereklidir?
C: Her zaman> 30-90 gün: Toplamlar 10-100 × boyutunu azaltır ve analitiği hızlandırır.

S: Günlükleri ve metrikleri karıştırmak mümkün mü?
A: Ayrı olarak saklayın (formatlar/sorgular farklıdır). Korelasyon için, Exemplar/TraceID ve panoları kullanın, ancak her şeyi bir tabloya eklemeyin.

17) Toplam

Etkili zaman serisi depolama, metrik sözleşme + etiket disiplini, yetkin alım (WAL/sıkıştırma), sıkıştırma ve tutma/toplama politikalarıdır. Kardinalite kontrolü, NA/federasyon ve mağazanın kendisinin gözlemlenebilirliğini ekleyin - ve tahmin edilebilir p95, aylarca yıllarca makul maliyet ve dalgalanma direnci elde edersiniz.