ذخیره سازی سری زمان

1) چرا معماری جداگانه برای سری زمان

• سرعت ضبط بالا (مصرف) و فرکانس.
• خواندن با محدوده زمانی (اسکن + aggregates/توابع پنجره).
• کاردینالیتی انفجاری به دلیل ترکیب برچسبها.
• نیاز به نگهداری (محدودیت عمر مفید) و downsampling (فشرده سازی زمان).
• از این رو - یک مدل ذخیره سازی ویژه، فرمت های فشرده سازی و پروتکل های درخواست.

2) مدل داده و معیارهای قرارداد

2. 1 نامگذاری و برچسب ها

metric_name: فعل مفرد/اسم ('http _ requests _ total', 'cpu _ usage _ seconds _ total').
برچسب ها: کلیدهای ویژگی («job»، «instance»، «dc»، «pod»، «status»، «method»).
ثابت: معانی نام را تغییر ندهید، نسخه های ('metric _ v2') را با تغییرات ناسازگار اضافه کنید.

2. 2 انواع ردیف

سنج، شمارنده، هیستوگرام/خلاصه، رویداد/دامنه.
برای امور مالی/تراکم - واحد ثابت و تجمع (خلاصه/به طور متوسط).

2. 3 سیاست نگهداری و تجدید نظر

جزئیات داغ (ثانیه/1-10 دقیقه) → واحدهای گرم (5m/1h) → سرد (1d/1w).
برای شمارنده - نرخ فروشگاه/deriv aggregates.

3) مسیر ضبط: پذیرش، بافر، جمع و جور

3. 1 خط لوله را وارد کنید

خراش دادن (کشیدن، Prometheus) یا فشار (OTLP/StatsD/Graphite)، اغلب از طریق دروازه/عامل.
بافر در WAL (نوشتن پیش رو)، سپس فشرده سازی به بخش/بلوک (معماری LSM مانند).
دسته بندی و مرتب سازی زمان باعث افزایش فشرده سازی و سرعت می شود.

3. 2 دست زدن به خارج از نظم و طول می کشد

پنجره تحمل (پنجره تاخیر، به عنوان مثال 5-15 دقیقه) + سیاست: «رها کردن | upsert | نگه داشتن آخرین».
Deduplication توسط «(series_id، برچسب زمانی)» با نسخه یا «آخرین رکورد برنده».

3. 3 فشرده سازی

دلتا دلتا برای برچسب های زمانی، گوریل/XOR برای شناور، RLE و varint برای اعداد صحیح، فرهنگ لغت برای برچسب ها.
اندازه بلوک بهینه («chunk») نقاط 1-8K یک سازش بین IOPS و CPU است.

4) طرح های ذخیره سازی: TSDB در مقابل SQL/ستون

4. 1 TSDB اختصاصی

Prometheus (محلی، احتباس کوتاه، PromQL، remote_write).
VictoriaMetrics/M3/InfluxDB - مقیاس افقی، نگهداری طولانی، خواندن از راه دور.
فرمت های بلوک برای اسکن محدوده + تجمع مناقصه بهینه شده است.

4. 2 موتورهای ارتباطی/ستون

TimescaleDB (PostgreSQL): hypertables، تکه های زمان/فضا، مصالح پیوسته.
ClickHouse: MergeTree/TTL/نمایش های تحقق یافته، فشرده سازی عالی و جمع آوری زمان.
انتخاب - توسط اکوسیستم پرس و جو (SQL در مقابل PromQL)، پیوستن/BI مورد نیاز و مهارت های عملیاتی تیم.

5) طرح و نمونه

5. 1 TimescaleDB: hypertable + مجموع مداوم

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) Cardinality: چگونه به «منفجر کردن» ذخیره سازی

6. 1 قوانین

کاردینالیتی برچسب محدود (تعداد مقادیر منحصر به فرد). «user _ id»، «request _ id»، «trace _ id» را شامل نمی شود.
عادی «چند ارزش» برچسب ها (دسته → کدهای).
از انواع LowCardinality (در CH)، لغت نامه ها/درختان برچسب (در TSDB) استفاده کنید.

6. ۲ کنترلها و هشدارها

معیارها: «series _ count»، «label _ values {label}»، سطرهای «گران» top-N.
نوشتن سیاست های شکست زمانی که حد کاردینالیتی در هر مستاجر/کار بیش از حد است.

6. 3 تاریخچه/تاریخچه

برای کاردینالیتی بالا، بهتر است aggregates (سطل هیستوگرام) و pre-rollup را ذخیره کنید. چندک برای محاسبه آنلاین در aggregates.

7) نگهداری، downsampling و ذخیره سازی سطحی

7. 1 سیاست ها

داغ: 3-30 روز از جزئیات دوم/دقیقه.
گرم: 90-365 روز از 5m/1h aggregates.
سرد: سالها جمع آوری روز، آرشیو در ذخیره سازی شی (S3/Glacier) با پارکت.

7. 2 تکنسین ها

مصالح پیوسته (مقیاس زمانی)، نماهای تحقق یافته (CH)، نگهداری + وظایف رول آپ (Victoria/M3/Influence).
ذخیره سازی چند لایه: «بلوک های گرم» به صورت محلی، «سرد» در شی با حافظه پنهان محلی.

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/clickhouse/object.
آمار/گرافیت: شمارنده ساده/تایمر ؛ پروکسی به لبه، سپس تبدیل به یک فرمت واحد.
Kafka/NATS: بافر برای انفجار مصرف، پخش کننده برای پر کردن ؛ مصرف کنندگان بتچامی می نویسند.

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

10) دسترسی، HA و فدراسیون

Replica/TSDB HA جفت یا فدراسیون Prometheus (منطقه → سطح جهانی).
خواندن/نوشتن از راه دور برای ذخیره سازی طولانی مدت و داشبورد متمرکز.
Shard-by-label/time: توزیع یکنواخت مصرف، محل توسط «dc/tenant».

11) قابلیت مشاهده خود ذخیره سازی

11. 1 معیارها

مصرف: 'samples/sec', 'append _ latency', 'wal _ fsync _ ms'.
Хранение: 'blocks _ count', 'compaction _ queue _ len', 'chunk _ compression _ ratio'.
Запросы: 'query _ qps', 'scan _ bytes', 'p95/p99 _ latency', '- _ bytes'.
کاردینالیتی: 'series _ count'، برچسبهای بالا.

11. 2 SLO

«P99 تاخیر برای محدوده 1h ≤ 200ms در QPS≤500».

"قطره قطره ≤ 0. 01٪ در پشت سر هم قبل از X نمونه/ثانیه"

«انباشت تراکم <10 دقیقه».

11. 3 هشدار

رشد 'series _ count'> Y ٪/ساعت.
صف فشرده سازی/فلاش> آستانه.
Доля خارج از ترتیب> N٪، dedup/اواخر قطره.

12) ایمنی و چند اجاره ای

جداسازی توسط «مستاجر» (برچسب در کلید، جداول/پایگاه داده های فردی، سهمیه ها).
پاکسازی برچسب ها (ممنوعیت PII)، کنترل اندازه/ارزش.
رمزگذاری «در حالت استراحت» و در حمل و نقل، دسترسی حسابرسی به معیارهای «حساس».

13) شیوه های عملیاتی

گرم کردن و شروع سرد: پین از بلوک های «گرم» در حافظه پنهان، prefetch از آخرین N ساعت.
Backfill: خطوط لوله فردی با اولویت کم، با آنلاین مخلوط نیست.
versioning schema: مهاجرت با نوشتن موازی (نوشتن دوگانه) و سوئیچ بعدی.
بودجه ذخیره سازی: کنترل «cost _ per _ TB _ month» + پیش بینی رشد کاردینالیتی.

14) ضد الگوهای

برچسب ها با کاردینالیتی بالا (user_id، uuid) → انفجار ردیف.
ردیف «ابدی» بدون احتباس → رشد کنترل نشده.
ضبط غیر بوچینگ/مرتب سازی → فشرده سازی ضعیف و طوفان IOPS.
OLTP و اسکن های طولانی را در همان استخر دیسک مخلوط کنید.
عدم وجود سیاست عدم نظم → تکراری و نفخ.
هیستوگرام با صدها سطل → هزینه × 10 بدون سود.

15) چک لیست پیاده سازی

• تعریف معیارها، انواع و واحدهای آنها ؛ قرارداد نام/برچسب را اصلاح کنید.
• موتور را انتخاب کنید (TSDB در مقابل SQL/ستون) و زبان پرس و جو (PromQL/SQL).
• طراحی نگهداری/رول آپ (گرم/گرم/سرد) و ILM.
• پیکربندی مصرف: WAL/دسته/مرتب سازی، پنجره های خارج از سفارش.
• فشرده سازی (delta-of-delta/XOR/RLE)، تکه های بهینه را روشن کنید.
• کنترل کاردینالیتی: سهمیه ها، هشدارها، سیاست های امتناع.
• پیکربندی HA/فدراسیون و از راه دور نوشتن/خواندن.
• داشبورد SLO و معیارهای ذخیره سازی (مصرف/پرس و جو/ذخیره سازی).
• سیاست های جداسازی امنیتی/مستاجر و عدم وجود PII در برچسب ها.
• به طور منظم «روز بازی»: پر کردن، از دست دادن گره، افزایش مصرف.

16) سوالات متداول

س: چه چیزی را برای نظارت بر زیرساخت انتخاب کنید: Prometheus یا ClickHouse/Timescale ؟

A: برای نظارت بومی و PromQL - Prometheus + ذخیره سازی طولانی مدت (Victoria/M3). برای سناریوهای BI/warehouse و SQL - Timescale/ClickHouse.

س: چگونه می توان چندک ها را بدون خلاصه های سنگین ذخیره کرد ؟

A: استفاده از هیستوگرام با سطل شسته و رفته و محاسبه چندک در صورت درخواست ؛ یا t-digest/CKMS در aggregates.

س: چگونه با خارج از نظم برخورد کنیم ؟

A: وارد پنجره تحمل (5-15 دقیقه) و سیاست قطعی قطعی ؛ برای تله متری از تلفن همراه/لبه - پنجره گسترده تر است.

س: هنگامی که یک رول آپ مورد نیاز است ؟

A: همیشه> 30-90 روز: aggregates کاهش اندازه × 10-100 و سرعت بخشیدن به تجزیه و تحلیل.

س: آیا امکان ترکیب سیاهههای مربوط و معیارها وجود دارد ؟

A: فروشگاه به طور جداگانه (فرمت/نمایش داده شد متفاوت است). برای همبستگی، از Exemplar/TraceID و داشبورد استفاده کنید، اما همه چیز را به یک جدول اضافه نکنید.

17) مجموع

ذخیره سازی سری زمانی موثر قرارداد متریک + نظم و انضباط برچسب، مصرف صالح (WAL/تراکم)، فشرده سازی، و سیاست های حفظ/rollup است. اضافه کردن کنترل cardinality، NA/فدراسیون و مشاهده از فروشگاه خود را - و شما P95 قابل پیش بینی، هزینه مناسب برای ماه تا سال و مقاومت در برابر افزایش است.