تخزين السلاسل الزمنية

1) لماذا بنية منفصلة للسلسلة الزمنية

• سرعة تسجيل عالية (ابتلاع) وتردد.
• يقرأ حسب النطاقات الزمنية (مسح + مجاميع/وظائف النافذة).
• كاردينالية متفجرة بسبب تركيبات العلامات.
• الحاجة إلى الاحتفاظ (قيود مدة الصلاحية) وتقليص الحجم (ضغط الوقت).
• ومن ثم - نموذج تخزين خاص وتنسيقات ضغط وبروتوكولات طلب.

2) نموذج البيانات ومقاييس العقود

2. 1 التسمية والعلامات

metric_name: الفعل المفرد/الاسم («http _ assists _ total»، «cpu _ usage _ seconds _ total»).
التسميات: مفاتيح السمات ('وظيفة'، 'حالة'، 'dc'، 'pod'، 'حالة'، 'طريقة').
الثوابت: لا تغير دلالات الاسم، أضف إصدارات ('metric _ v2') مع تغييرات غير متوافقة.

2. 2 أنواع الصفوف

المقياس، العداد، Histogram/Summary، Event/Span.
بالنسبة للشؤون المالية/الكثافة - إصلاح الوحدات وقابلية التجميع (مجمل/متوسط).

2. 3 سياسة الاحتفاظ والرولب

التفاصيل الساخنة (ثوانٍ/1-10 دقائق) → وحدات دافئة (5 م/1 ساعة) → باردة (1d/1w).
لمجاميع سعر التخزين/ديريف.

3) مسار التسجيل: الاستقبال، التخزين المؤقت، المضغوط

3. 1 Intest-pipline

كشط (سحب، بروميثيوس) أو دفع (OTLP/StatsD/Graphite)، غالبًا عبر البوابة/الوكيل.
التخزين المؤقت في WAL (سجل الكتابة المسبق)، ثم الضغط إلى شرائح/كتل (بنية تشبه LSM).
يزيد الدفع وفرز الوقت من الضغط والسرعة.

3. 2 التعامل مع خارج النظام ويستغرق

نافذة التسامح (نافذة التأخير، على سبيل المثال 5-15 دقيقة) + السياسة: «إسقاط | اضطراب | الاحتفاظ به أخيرًا».
التفريغ بواسطة «(series_id، timestamp)» مع الإصدار أو «آخر انتصارات قياسية».

3. 3 الضغط

Delta-of-delta للطوابع الزمنية، Gorilla/XOR للعوامة، RLE و varint للأعداد الصحيحة، قاموس للعلامات.
حجم الكتلة الأمثل («الجزء») للنقاط 1-8K هو حل وسط بين IOPS ووحدة المعالجة المركزية.

4) مخططات التخزين: TSDB مقابل SQL/أعمدة

4. 1 مخصص TSDB

Prometheus (محلي، احتفاظ قصير، PromQL، remote_write).
VictoriaMetrics/M3/InfluxDB - القياس الأفقي، والاحتفاظ الطويل، والقراءة عن بعد.
يتم تحسين تنسيقات الكتلة لمسح النطاق + تجميعات المناقصة.

4. 2 محركات علائقية/عمودية

TimescaleDB (PostgreSQL): جداول تشعبية، قطع حسب الزمان/المكان، مجاميع مستمرة.
ClickHouse: MergeTree/TTL/المشاهدات المجسدة والضغط الممتاز وتجميع الوقت.
الاختيار - حسب النظام البيئي للاستعلام (SQL vs PromQL)، متطلبات الانضمام/BI والمهارات التشغيلية للفريق.

5) المخطط والأمثلة

5. 1 TimescaleDB: Hypertable + continuous compregate

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 القواعد

الحد من كاردينالية التسمية (عدد القيم الفريدة). لا تشتمل على «مستخدم _ معرف»، «طلب _ معرف»، «تتبع _ معرف».
تطبيع العلامات «متعددة القيمة» (فئات → الرموز).
استخدام أنواع الكاردينالية المنخفضة (في CH)، القواميس/الأشجار الملصقة (في TSDB).

6. 2 ضوابط وتنبيهات

المقاييس: "series _ count'," label _ values {label} ", top-N" expensive "rows'.
اكتب سياسات الفشل عندما يتم تجاوز حد الكاردينالية لكل مستأجر/وظيفة.

6. 3 التواريخ/التواريخ

بالنسبة للكاردينالية العالية، من الأفضل تخزين المجاميع (دلاء histogram) وما قبل rollup ؛ كميات للحساب على الإنترنت على المجاميع.

7) الاحتفاظ والتجزئة والتخزين المتدرج

7. 1 السياسات

ساخن: 3-30 يومًا من التفاصيل الثانية/الدقيقة.
دافئ: 90-365 يومًا من 5 أمتار/1 ساعة.
بارد: سنوات من التجمعات اليومية، أرشيف في تخزين الكائنات (S3/Glacier) مع Parquet.

7. 2 فنيين

التجميعات المستمرة (Timescale)، الآراء المجسدة (CH)، الاحتفاظ + مهام rollup (Victoria/M3/Influence).
التخزين المتدرج: «كتل ساخنة» محليًا، «باردة» مع مخبأ محلي.

8) الاستفسارات واللغات

8. 1 PromQL (مثال)

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

يبحث عن معدل خطأ واجهة برمجة التطبيقات 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 للموسمية ؛ تخزن النتائج في صف منفصل «شذوذ = 1/0».

9) التكامل والبروتوكولات

OTLP (OpenTelemetry): المقاييس/المسارات/السجلات، والمصدرون على العوامل (otel-collector) → TSDB/clickhouse/object.
StatsD/Graphite: عدادات/أجهزة توقيت بسيطة ؛ الوكيل إلى الحافة، ثم التحويل إلى تنسيق واحد.
Kafka/NATS: حاجز لابتلاع رشقات نارية، إعادة ردم ؛ المستهلكون يكتبون باتشامي.

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

10) إمكانية الوصول، HA والاتحاد

أزواج نسخ طبق الأصل/TSDB HA أو اتحاد Prometheus (منطقة → مستوى عالمي).
قراءة/كتابة عن بعد للتخزين الطويل الأجل ولوحات القيادة المركزية.
Shard-by-label/time: توزيع موحد للمبتلع، الموقع حسب 'dc/المستأجر'.

11) إمكانية رصد التخزين نفسه

11. 1 مقاييس

Inster: "apples/sec"، "append _ latency"، "wal _ fsync _ ms'.
Хранение: "blocks _ count'," compaction _ queue _ len "," chunk _ compression _ rato ".
Запросы: "query _ qps'," scan _ bytes "," p95/p99 _ latency "," alloc _ bytes ".
الكاردينالية: "series _ count'، أعلى الملصقات.

11. 2 SLO

«p99 latency for 1h range ≤ 200ms at QPS≤500».

"Intest-drop ≤ 0. 01٪ عند الانفجار قبل عينات X/ثانية"

«Compaction backlog <10 min».

11. 3 تنبيهات

Growth 'series _ count'> Y %/ساعة.
طابور الضغط/التدفق> العتبة.
Доля خارج الطلب> N٪، التخلص/القطرات المتأخرة.

12) السلامة وتعدد الحيازات

العزل حسب «المستأجر» (توسيم في المفاتيح، جداول/قواعد بيانات فردية، حصص).
تطهير الملصقات (حظر PII)، ومراقبة الحجم/القيمة.
التشفير «في الراحة» والنقل، ومراجعة الوصول إلى المقاييس «الحساسة».

13) ممارسات التشغيل

بداية دافئة وباردة: دبوس من الكتل «الساخنة» في المخبأ، مقدمة آخر ساعات N.
الردم: خطوط أنابيب فردية ذات أولوية منخفضة، لا تختلط بالإنترنت.
إصدار المخطط: الهجرات مع الكتابة الموازية (ثنائية الكتابة) والتبديل اللاحق.
ميزانية التخزين: التحكم في «السداد _ لكل _ سل _ شهر» + توقعات نمو الكاردينالية.

14) الأنماط المضادة

العلامات ذات الكاردينالية العالية (user_id، uuid) → انفجار الصفوف.
صفوف «أبدية» بدون احتفاظ → نمو غير منضبط.
تسجيل عدم التجزئة/الفرز → ضغط ضعيف وعاصفة IOPS.
امزج OLTP والمسح الطويل على نفس حوض القرص.
عدم وجود سياسة خارجة عن النظام → تكرار وانتفاخ.
تكلف المخططات النسيجية التي تحتوي على مئات الدلاء → 10 × دون فائدة.

15) قائمة التنفيذ المرجعية

• تحديد المقاييس وأنواعها ووحداتها ؛ تثبيت عقد الاسم/التسمية.
• حدد المحرك (TSDB vs SQL/Column) ولغة الاستعلام (PromQL/SQL).
• تصميم الاحتفاظ/rollup (ساخن/دافئ/بارد) و ILM.
• تكوين تناول: WAL/دفعات/فرز، نوافذ خارج الطلب.
• تشغيل الضغط (دلتا الدلتا/XOR/RLE)، القطع المثلى.
• التحكم في الكاردينالية: الحصص، التنبيهات، سياسات إلغاء الاشتراك.
• تكوين HA/Federation والكتابة/القراءة عن بعد.
• لوحات معلومات SLO ومقاييس التخزين (ابتلاع/استعلام/تخزين).
• سياسات العزل الأمني/المستأجر والافتقار إلى مؤشر الاستثمار الدولي في العلامات.
• «يوم اللعبة» العادي: ردم، فقدان العقدة، زيادة الابتلاع.

16) الأسئلة الشائعة

س: ما الذي يجب اختياره لمراقبة البنية التحتية: Prometheus أو ClickHouse/Timescale ؟

ج: للمراقبة المحلية و PromQL - Prometheus + التخزين طويل الأجل (Victoria/M3). لسيناريوهات BI/المستودعات و SQL - Timescale/ClickHouse.

س: كيف يتم تخزين الكميات بدون ملخصات ثقيلة ؟

ج: استخدم مخطط النسيج مع الدلاء الأنيقة وحساب الكميات عند الطلب ؛ أو t-digest/CKMS في المجموع.

س: كيف تتعامل مع الخروج عن النظام ؟

ج: أدخل نافذة التسامح (5-15 دقيقة) وسياسة التخلص الحتمية ؛ للقياس عن بعد من الهاتف المحمول/الحافة - النافذة أوسع.

س: متى تكون هناك حاجة إلى rollup ؟

ج: دائمًا> 30-90 يومًا: تقلل المجاميع × حجم 10-100 وتسرع التحليلات.

س: هل من الممكن مزج السجلات والمقاييس ؟

ج: تخزين بشكل منفصل (الأشكال/الاستفسارات مختلفة). للارتباط، استخدم نموذج/TraceID ولوحات القيادة، ولكن لا تضيف كل شيء إلى جدول واحد.

17) المجاميع

التخزين الفعال للسلسلة الزمنية هو عقد المقاييس + نظام العلامة، والابتلاع الكفء (WAL/compaction)، وسياسات الضغط والاحتفاظ/rollup. أضف التحكم في الكاردينالية و NA/Federation وإمكانية ملاحظة المتجر نفسه - وستحصل على p95 يمكن التنبؤ به، وتكلفة معقولة لأشهر إلى سنوات وزيادة المقاومة.