Уақытша қатарларды сақтау

1) Уақытша қатарлар үшін жеке сәулет не үшін

• Жазбалардың жоғары жылдамдығы (ingest) және кезеңділігі.
• Уақыт ауқымы бойынша оқулар (scan + агрегаттар/терезе функциялары).
• Тегтердің комбинациясынан жарылғыш түбегейлі.
• Ретеншн (сақтау мерзімі бойынша шектеулер) және downsampling (уақыт бойынша қысу) қажеттілігі.
• Осыдан - арнайы сақтау моделі, компрессия форматтары және сұрау хаттамалары.

2) Деректер моделі және метриктер келісімшарты

2. 1 Атау және тегтер

metric_name: есім/есім жалғыз ('http _ requests _ total', 'cpu _ usage _ seconds _ total').
labels: кілт-төлсипаттар ('job', 'instance', 'dc', 'pod', 'status', 'method').
Инварианттар: атаудың семантикасын өзгертпеңіз, сәйкес келмейтін өзгерістер кезінде ('metric _ v2') нұсқаларын қосыңыз.

2. 2 Қатар түрлері

Gauge (сурет), Counter (өспелі жиынтық), Histogram/Summary (үлестірулер/квантильдер), Event/Span (трейс-нүктелер).
Қаржы/тығыздықтар үшін - өлшем бірліктерін және агрегаттылығын белгілеңіз (қосылады/орташаланады).

2. 3 Ретеншн және роллап саясаты

Ыстық егжей-тегжейлі (секунд/1-10 мин) → жылы агрегаттар (5m/1h) → суық (1d/1w).
counter үшін - rate/deriv агрегаттарын сақтау.

3) Жазу жолы: қабылдау, буферлеу, компакт

3. 1 Ingest-paypline

Scrape (pull, Prometheus) немесе push (OTLP/StatsD/Graphite), жиі gateway/agent арқылы.
WAL (write-ahead log) буферлеу, содан кейін сегменттерге/блоктарға компакциялау (LSM-ұқсас сәулет).
Batching және уақыт бойынша сұрыптау қысу мен жылдамдықты арттырады.

3. 2 Out-of-order және қосарларды өңдеу

Рұқсат терезесі (lateness window, мысалы 5-15 мин) + 'drop | upsert | keep-last' саясаты.
'(series_id, timestamp)' нұсқасы бойынша дедупликация немесе «соңғы жазба жеңеді».

3. 3 Компрессия

Уақыт белгілері үшін Delta-of-delta, float үшін Gorilla/XOR, тұтас үшін RLE және varint, тегтер үшін dictionary.
1-8К нүктелер блогының («күбінің») оңтайлы өлшемі - IOPS және CPU арасындағы ымыраға келу.

4) Сақтау схемалары: TSDB vs SQL/бағаншалар

4. 1 Мамандандырылған TSDB

Prometheus (жергілікті, қысқа ретеншн, PromQL, remote_write).
VictoriaMetrics/M3/InfluxDB - көлденең масштабтау, ұзақ ретеншн, remote read.
Блоктардың форматтары range scan + тендингтік агрегацияларға оңтайландырылған.

4. 2 Реляциялық/бағаналық қозғалтқыштар

TimescaleDB (PostgreSQL): гипертаблицалар, уақыт/кеңістік бойынша күбілер, continuous aggregates.
ClickHouse: MergeTree/TTL/материалданған көріністер, тамаша компрессия және уақыт агрегациясы.
Таңдау - сұрау экожүйесі (SQL vs PromQL), join/BI талаптары және команданың операциялық дағдылары бойынша.

5) Схема және мысалдар

5. 1 TimescaleDB: гипертабличасы + 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: агрегаттық сақтау

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) Түбегейлі: қойманы қалай «жаруға» болмайды

6. 1 Ереже

label cardinality (бірегей мәндер санын) шектеңіз. 'user _ id', 'request _ id', 'trace _ id' дегенді қоспаңыз.
Көп мәнді тегтерді (санаттар → кодтар) қалыпқа келтіріңіз.
LowCardinality түрлерін (CH), сөздіктерді/белгілер ағаштарын (TSDB) пайдаланыңыз.

6. 2 Бақылау және тәуекелдер

Өлшемдері: 'series _ count', 'label _ values {label}', top-N «қымбат» қатарлар.
per tenant/job.

6. 3 Тарих/гистограммалар

high-cardinality үшін агрегаттарды (histogram buckets) және pre-rollup; квантилді агрегаттарда онлайн есептеу.

7) Ретеншн, downsampling және tiered-storage

7. 1 Саясат

Hot: 3-30 күн секундтық/минуттық егжей-тегжейлі.
Warm: 90-365 күн 5m/1h агрегаттар.
Cold: күндізгі агрегаттар жылдары, Parquet-пен бірге объектілік қоймадағы (S3/Glacier) мұрағат.

7. 2 Техника

Continuous aggregates (Timescale), материалданған көріністер (CH), retention + rollub tasks (Victoria/M3/Influx).
Tiered storage: «ыстық блоктар» жергілікті, «суық» жергілікті кэші бар объектіде.

8) Сұраулар мен тілдер

8. 1 PromQL (мысал)

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

API бойынша 5xx қателер қарқынын іздейміз.

8. 2 SQL-терезе агрегаттары

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 Аномалиялар (эскиз)

Z-score/ESD терезе статистикасы бойынша, STL-маусымдық декомпозициясы; нәтижелерді жеке қатарда сақтау 'anomaly = 1/0'.

9) Интеграция және хаттамалар

OTLP (OpenTelemetry): метриктер/трейдерлер/логтар, агенттердегі экспорттаушылар (otel-collector) → TSDB/кликхаус/объектілік.
StatsD/Graphite: қарапайым есептегіштер/таймерлер; edge прокси, бұдан әрі - бірыңғай пішімге конверсия.
Kafka/NATS: ingest жарқылдауға арналған буфер, бэкфилге арналған replayer; консьюмерлер батчамен жазады.

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

10) Қолжетімділік, HA және федерация

Replica/HA-жұбы TSDB немесе Prometheus федерациясы (өңір деңгейі → жаһандық).
Ұзақ уақыт сақтау және орталықтандырылған дашбордтар үшін Remote read/write.
Shard-by-label/time: ingest, locality 'dc/tenant' бойынша біркелкі бөлу.

11) Қойманың өзінің бақылануы

11. 1 Өлшемдері

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`.
Түбірлігі: 'series _ count', top-labels.

11. 2 SLO

«QPS ≤ 500 кезінде 1h ≤ 200 мс диапазоны үшін p99 latency».
«Ingest-drop ≤ 0. 01% кезінде burst X samples/sec" дейін.
«Compaction backlog < 10 min».

11. 3 Алерттар

'series _ count'> %/сағ.
Компакция кезегі/flush> табалдырығы.
Доля out-of-order > N%, dedup/late-drops.

12) Қауіпсіздік және мульти-тенанттық

«tenant» бойынша оқшаулау (кілттердегі лейбл, жеке кестелер/базалар, квоталар).
Таңбаларды тазалау (PII тыйым салу), өлшемдерді/мәндерді бақылау.
«Тыныштықта» және көлікте шифрлау, «сезімтал» метриктерге қол жеткізу аудиті.

13) Пайдалану тәжірибелері

Жылыту және суықтай бастау: кэштегі «ыстық» блоктардың pin, соңғы N сағат prefetch.
Backfill: төмен басымдықты жеке пайплайндар, онлайнмен араластыруға болмайды.
Схеманы нұсқалау: қатарлас жазбасы (dual-write) және одан кейінгі свитчі бар көші-қон.
Сақтау бюджеті: бақылау 'cost _ per _ TB _ month' + forecast түбегейлі өсу.

14) Қарсы үлгілер

Жоғары кардинальды тегтер (user_id, uuid) → қатарларды жару.
Ретеншнасыз «мәңгілік» қатарлар → бақылаусыз өсу.
Батчинг/сұрыптаусыз жазба → нашар компрессия және IOPS дауылы.
OLTP және ұзын сканерлерді дискілердің бір пулында араластыру.
out-of-order саясатының болмауы → телнұсқалар және үрлеу.
Жүздеген бакеттері бар гистограммалар → құны × 10 пайдасыз.

15) Енгізу чек-парағы

• Метриктерді, олардың түрлері мен бірліктерін анықтаңыз; атаулар/лейблдер келісімшартын белгілеңіз.
• Қозғалтқышты (TSDB vs SQL/баған) және сұрау тілін (PromQL/SQL) таңдаңыз.
• Ретеншн/роллап (hot/warm/cold) және ILM таспаларын жобалаңыз.
• ingest: WAL/батчи/сұрыптау, out-of-order терезелерін теңшеңіз.
• Компрессияны қосыңыз (delta-of-delta/XOR/RLE), оңтайлы күбілер.
• Түбегейлікті бақылаңыз: квоталар, тәуекелдер, бас тарту саясаты.
• NA/federation және remote-write/reading.
• SLO дашбордтары және сақтау өлшемдері (ingest/query/storage).
• Қауіпсіздік/тенант-оқшаулау саясаты және лейблдерде PII болмауы.
• Тұрақты «game day»: бэкфилл, түйіннің жоғалуы, ingest.

16) FAQ

Q: Инфрақұрылым мониторингі үшін не таңдау керек: Prometheus немесе ClickHouse/Timescale?
А: Ұлттық мониторинг және PromQL үшін - Prometheus + ұзақ storage (Victoria/M3). BI/қойма сценарийлері және SQL үшін - Timescale/ClickHouse.

Q: ауыр summary жоқ квантилді қалай сақтау керек?
A: ұқыпты бакеттермен histogram пайдаланыңыз және сұрау кезінде квантилді есептеңіз; немесе агрегаттардағы t-digest/CKMS.

Q: out-of-order не істеу керек?
A: Рұқсат терезесін (5-15 мин) және determined dedup саясатын енгізіңіз; ұялы/edge телеметриясы үшін - терезе кең.

Q: Rollup қашан қажет?
A: Әрқашан ретеншн кезінде> 30-90 күн: агрегаттар 10-100 × мөлшерін азайтады және талдауды жылдамдатады.

Q: Логтер мен метриканы араластыруға бола ма?
А: Бөлек сақтаңыз (пішімдер/сұраулар әртүрлі). Корреляция үшін Exemplar/TraceID және дэшбордтарды пайдаланыңыз, бірақ бәрін бір кестеге жинамаңыз.

17) Қорытынды

Уақытша қатарлардың тиімді қоймасы - бұл метрикалық келісім-шарт + тегтердің тәртібі, сауатты ingest (WAL/компакция), компрессия және ретеншна/роллап саясаты. Кардиналдықты, NA/федерацияны және стораның бақылауын қосыңыз - сіз болжамды p95, айлар-жылдар үшін ақылға қонымды құн және жарылысқа төзімділік аласыз.