დროებითი რიგების შენახვა

1) რატომ არის ცალკეული არქიტექტურა დროებითი რიგებისთვის

• ჩანაწერების მაღალი სიჩქარე და სიხშირე.
• დროის დიაპაზონის კითხვებით (სკან + აგრეგატები/ფანჯრის ფუნქციები).
• ფეთქებადი კარდინალობა ჭდის კომბინაციების გამო.
• retenshna- ს აუცილებლობა (შენახვის ვადის შეზღუდვა) და 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 Retenshny და Rollaps- ის პოლიტიკა

ცხელი დეტალიზაცია (წამები/1-10 წთ) - თბილი აგრეგატები (5m/1h) - ცივი (1d/1w).
Counter- ისთვის - შეინახეთ rate/deriv ერთეულები.

3) ჩაწერის გზა: მიღება, ბუფერიზაცია, CD

3. 1 Ingest pipline

Scrape (pull, Prometheus) ან push (OTLP/StatsD/Graphite), ხშირად gateway/agent საშუალებით.
ბუფერიზაცია WAL- ში (write-ahead log), შემდეგ კომპაქტური სეგმენტები/ბლოკები (LSM მსგავსი არქიტექტურა).
დროის დახარისხება და დახარისხება ზრდის შეკუმშვას და სიჩქარეს.

3. 2 მოწესრიგება და დუბლი

დაშვების ფანჯარა (მაგალითად, 5-15 წუთი) + პოლიტიკა: 'drop | upsert | keep-last'.
დედუპლიკაცია '(სერია _ id, timestamp)' ვერსიით ან „ბოლო ჩანაწერი იმარჯვებს“.

3. 3 კომპრესია

Delta-of-delta დროის ეტიკეტებისთვის, Gorilla/XOR float, RLE და varint მთელი რიცხვებისთვის, ციფრული ტეგებისთვის.
ბლოკის ოპტიმალური ზომა („ჩანკა“) 1-8K წერტილი არის კომპრომისი IOPS- სა და CPU- ს შორის.

4) შენახვის სქემები: TSDB vs SQL/squares

4. 1 სპეციალიზირებული TSDB

Prometheus (ადგილობრივად, მოკლე ჭრიჭინა, PromQL, remote _ write).
VictoriaMetrics/M3/InfluxDB - ჰორიზონტალური სკალირება, გრძელი retenshne, 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 კონტროლი და ალერტები

მეტრიკები: 'სერია _ count', 'label _ values {label}', ტოპ-N „ძვირადღირებული“ რიგები.
ჩაწერის უარის თქმის პოლიტიკოსები, როდესაც გადალახულია per tenant/job კარდინალური ლიმიტი.

6. 3 ისტორია/ჰისტოგრამა

მაღალჩინოსნებისთვის უმჯობესია შეინახოთ დანაყოფები (histogram buckets) და pre-rollup; კვარტალი ონლაინ რეჟიმში გამოთვლა აგრეგატებზე.

7) Retenschn, downsampling და tiered-storage

7. 1 პოლიტიკა

ცხელი: 3-30 დღე წამში/წუთიანი დეტალიზაცია.
Warm: 90-365 დღე 5m/1h ერთეულები.
ცივი: დღის ერთეულების წლები, არქივი ობიექტის საცავში (S3/Glacier) Parquet- ით.

7. 2 ტექნოლოგია

Continuus aggregates (Timescale), მატერიალიზებული წარმოდგენები (CH), retention + rollup tasks (Victoria/M3/Influx).
Tiered storage: „ცხელი ბლოკები“ ადგილობრივად, „ცივი“ ობიექტში ადგილობრივი ქეში.

8) მოთხოვნები და ენები

8. 1 PromQL (მაგალითი)

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

ჩვენ ვეძებთ შეცდომების ტემპს 5xx API- სთვის.

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/clickhous/ობიექტი.
StatsD/Graphite: მარტივი მრიცხველები/ტაიმერები; მარიონეტული edge, შემდეგ - კონვერტაცია ერთ ფორმატში.
Kafka/NATS: bufer ingest flows, replayer for backfill; კონსიუმერები წერენ ბრძოლებს.

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- ის ერთგვაროვანი განაწილება, ადგილმდებარეობა '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`.
კარდინალობა: 'სერია _ count', ტოპ-ლაბორატორია.

11. 2 SLO

„p99 ლატვია 1h-200 ms დიაპაზონისთვის QPS-500“.

«Ingest-drop ≤ 0. 01% burst მდე X samples/sec."

«Compaction backlog < 10 min».

11. 3 ალერტა

ზრდა 'სერია _ count'> %/საათში.
კომპაქტური ხაზი/flush> ბარიერი.
Доля out-of-order > N%, dedup/late-drops.

12) უსაფრთხოება და მრავალ ტენანტობა

იზოლაცია 'tenant' (ეტიკეტი კლავიშებში, ცალკეული ცხრილები/ბაზები, კვოტები).
ეტიკეტების მოწყობა (აკრძალვა PII), ზომების/მნიშვნელობების კონტროლი.
დაშიფვრა „მარტო“ და ტრანსპორტში, აუდიტი „მგრძნობიარე“ მეტრიკებზე წვდომისთვის.

13) ოპერაციული პრაქტიკა

გაათბეთ და ცივი დასაწყისი: ქეში „ცხელი“ ბლოკები, ბოლო N საათების პრეფექტი.
Backfill: ინდივიდუალური პრიორიტეტები დაბალი პრიორიტეტით, არ აურიოთ ონლაინ.
სქემის ვერსია: მიგრაცია პარალელური ჩაწერით (ორმაგი ჩაწერით) და შემდგომი გრაგნილი.
შენახვის ბიუჯეტი: კონტროლი 'cost _ per _ TB _ month' + forecast დრამატული ზრდა.

14) ანტი შაბლონები

მაღალი კარდინალური ჭდეები (user _ id, uuid) - რიგების აფეთქება.
„მარადიული“ რიგები ჭრის გარეშე, უკონტროლო ზრდა.
ჩაწერა ბატარეის/დახარისხების გარეშე - ცუდი კომპრესია და IOPS ქარიშხალი.
OLTP და გრძელი სკანების შერევა ერთ აუზზე.
out-of-order- ის პოლიტიკის არარსებობა არის დუბლიკატები და გაბრაზება.
ჰისტოგრამები ასობით ბაკეტით - × 10 ღირებულება სარგებლის გარეშე.

15) განხორციელების სია

• განსაზღვრეთ მეტრიკა, მათი ტიპები და ერთეულები; დააფიქსირეთ სახელების/ეტიკეტის კონტრაქტი.
• შეარჩიეთ ძრავა (TSDB vs SQL/Clayer) და მოთხოვნის ენა (PromQL/SQL).
• შეიმუშავეთ retenshn/rollap (hot/warm/cold) და ILM tasks.
• ingest პარამეტრები: WAL/batch/დახარისხება, out-of-order ფანჯრები.
• ჩართეთ კომპრესია (delta-of-delta/XOR/RLE), ოპტიმალური მონეტები.
• გააკონტროლეთ კარდინალობა: კვოტები, ალერტები, უარის თქმის პოლიტიკოსები.
• კონფიგურაცია NA/ფედერაცია და remote-write/read.
• Dashbords SLO და საცავის მეტრიკა (ingest/query/storage).
• უსაფრთხოების პოლიტიკა/ჩრდილოვანი იზოლაცია და PII- ის არარსებობა ეტიკეტებში.
• რეგულარული „თამაშის დღე“: ზურგჩანთა, კვანძის დაკარგვა, ინჯესტის ზრდა.

16) FAQ

Q: რა უნდა აირჩიოთ ინფრასტრუქტურის მონიტორინგისთვის: Prometheus ან ClickHouse/Timescale?
A: ზოგადი მონიტორინგისთვის და PromQL - Prometheus + გრძელი სცენა (Victoria/M3). BI/საწყობის სკრიპტებისთვის და SQL - Timescale/ClickHouse.

Q: როგორ უნდა შეინახოთ კვანძები მძიმე მოცულობის გარეშე?
A: გამოიყენეთ histogram სისუფთავე ბაკეტებით და გამოთვალეთ მეოთხეული თხოვნით; ან t-digest/CKMS ერთეულებში.

Q: როგორ მოვიქცეთ out-of-order?
A: შეიყვანეთ დაშვების ფანჯარა (5-15 წთ) და დეტერმინისტული dedup პოლიტიკა; მობილური/edge ტელემეტრიისთვის - ფანჯარა უფრო ფართოა.

Q: როდის გჭირდებათ rollup?
A: ყოველთვის ჭრილში> 30-90 დღის განმავლობაში: აგრეგატები ამცირებენ ზომას × 10-100 და აჩქარებენ ანალიტიკას.

Q: შესაძლებელია თუ არა ლოგებისა და მეტრიკების შერევა?
A: შეინახეთ ცალკე (ფორმატები/მოთხოვნები განსხვავებულია). კორელაციისთვის, გამოიყენეთ Exemplar/TraceID და deschbords, მაგრამ არ ჩადოთ ყველაფერი ერთ ცხრილში.

17) შედეგები

დროებითი მწკრივების ეფექტური შესანახად არის მეტრული + დისციპლინის კონტრაქტი, კომპეტენტური ინგესტი (WAL/Compaction), retenshne/rollaps- ის კომპრესია და პოლიტიკა. დაამატეთ კარდინალობის კონტროლი, NA/ფედერაცია და თავად stor- ის დაკვირვება - და მიიღებთ პროგნოზირებულ p95, გონივრულ ღირებულებას თვეების და წლების განმავლობაში და გამძლეობის წინააღმდეგობას.