الأقسام
PARTITION BY. ويمكن أن تتضمن هذه العبارة تعبير SQL على أي عمود أو أعمدة، وتحدِّد نتائج هذا التعبير القسم الذي يُرسَل إليه الصف.
ترتبط أجزاء البيانات منطقيًا (من خلال بادئة مشتركة لاسم المجلد) بكل قسم على القرص، ويمكن الاستعلام عنها بشكل منفصل. في المثال أدناه، يُقسِّم مخطط otel_logs الافتراضي البيانات حسب اليوم باستخدام التعبير toDate(Timestamp). وعند إدراج الصفوف في ClickHouse، سيُقيَّم هذا التعبير على كل صف ويُوجَّه إلى القسم الناتج إذا كان موجودًا (وإذا كان هذا الصف هو الأول لذلك اليوم، فسيُنشأ القسم).
otel_logs لدينا مُقسَّم حسب اليوم. وإذا جرى ملؤه بمجموعة بيانات السجلات المنظَّمة، فسيحتوي على بيانات تمتد لعدة أيام:
otel_logs_archive، نستخدمه لتخزين البيانات الأقدم. ويمكن نقل البيانات إلى هذا الجدول بكفاءة على مستوى الأقسام (إذ إن هذا مجرد تغيير في البيانات الوصفية).
INSERT INTO SELECT وإعادة كتابة البيانات في الجدول الهدف الجديد.
نقل الأقساميتطلب نقل الأقسام بين الجداول استيفاء عدة شروط، من أبرزها أن تتطابق الجداول في البنية ومفتاح التقسيم والمفتاح الأساسي والفهارس/الإسقاطات. ويمكن العثور هنا على ملاحظات مفصلة حول كيفية تحديد الأقسام في
ALTER DDL.تُستغل هذه الميزة بواسطة TTL عند استخدام الإعداد
ttl_only_drop_parts=1. راجع إدارة البيانات باستخدام TTL لمزيد من التفاصيل.التطبيقات
- المعماريات متعددة الطبقات - نقل البيانات بين طبقات التخزين (راجع طبقات التخزين)، مما يتيح بناء معماريات ساخنة-باردة.
- الحذف الفعّال - عند وصول البيانات إلى قيمة TTL محددة (راجع إدارة البيانات باستخدام TTL)
أداء الاستعلامات
إدارة البيانات باستخدام TTL (Time-to-live)
TTL على مستوى الجدول
ttl، على سبيل المثال.
h والتأكد من أن ذلك يتوافق مع فترة التقسيم. على سبيل المثال، إذا كان التقسيم حسب اليوم، فتأكد من أن القيمة تمثل مضاعفات الأيام، مثل 24h و48h و72h. وسيضمن ذلك تلقائيًا إضافة عبارة TTL إلى الجدول، على سبيل المثال إذا كانت ttl: 96h.
TTLs المجدولةلا تُطبَّق TTLs فورًا، بل وفق جدول زمني كما ذُكر أعلاه. يحدّد إعداد جدول MergeTree
merge_with_ttl_timeout الحد الأدنى للتأخير، بالثواني، قبل تكرار عملية دمج مع delete TTL. القيمة الافتراضية هي 14400 ثانية (4 ساعات). لكن هذا مجرد الحد الأدنى للتأخير؛ فقد يستغرق الأمر وقتًا أطول قبل أن يتم تشغيل عملية دمج TTL. وإذا كانت القيمة منخفضة جدًا، فسيؤدي ذلك إلى تنفيذ العديد من عمليات الدمج خارج الجدول الزمني، ما قد يستهلك قدرًا كبيرًا من الموارد. ويمكن فرض انتهاء TTL باستخدام الأمر ALTER TABLE my_table MATERIALIZE TTL.ttl_only_drop_parts=1 ** (المطبّق بواسطة المخطط الافتراضي). عند تمكين هذا الإعداد، يحذف ClickHouse جزءًا كاملًا عندما تكون جميع الصفوف فيه منتهية الصلاحية. إن حذف الأجزاء كاملةً بدلًا من التنظيف الجزئي للصفوف التي انتهت صلاحية TTL الخاصة بها (وهو ما يتم عبر عمليات mutation كثيفة الاستهلاك للموارد عندما تكون قيمة ttl_only_drop_parts=0) يتيح استخدام قيم merge_with_ttl_timeout أقصر وتقليل التأثير في أداء النظام. وإذا كانت البيانات مُقسّمة وفق الوحدة نفسها التي تُطبَّق عندها صلاحية TTL، مثل اليوم، فستحتوي الأجزاء بطبيعتها على بيانات من interval المحدد فقط. وهذا يضمن إمكانية تطبيق ttl_only_drop_parts=1 بكفاءة.
TTL على مستوى العمود
Body تحسبًا لإضافة بيانات وصفية ديناميكية جديدة لم تُستخرج عند وقت الإدراج، مثل وسم Kubernetes جديد. وبعد فترة، مثل شهر واحد، قد يتضح أن هذه البيانات الوصفية الإضافية غير مفيدة، ما يقلل جدوى الاحتفاظ بالعمود Body.
فيما يلي، نوضح كيف يمكن حذف العمود Body بعد 30 يومًا.
يتطلّب تحديد TTL على مستوى العمود من المستخدمين تعريف المخطط الخاص بهم بأنفسهم. ولا يمكن تحديده في OTel collector.
إعادة ضغط البيانات
ZSTD(1) لمجموعات بيانات observability، يمكنك تجربة خوارزميات ضغط مختلفة أو مستويات ضغط أعلى مثل ZSTD(3). وإلى جانب إمكانية تحديد ذلك عند إنشاء المخطط، يمكن أيضًا ضبط إعدادات الضغط بحيث تتغير بعد فترة زمنية محددة. وقد يكون هذا مناسبًا إذا كان codec أو خوارزمية الضغط يحسّن الضغط لكنه يؤدي إلى تراجع في أداء الاستعلام. قد تكون هذه المفاضلة مقبولة للبيانات الأقدم، التي يقل الاستعلام عنها، لكنها قد لا تكون مناسبة للبيانات الحديثة، التي تُستخدَم بوتيرة أكبر في عمليات التحقيق.
يوضح المثال أدناه ذلك، حيث نضغط البيانات باستخدام ZSTD(3) بعد 4 أيام بدلًا من حذفها.
قيِّم الأداءنوصي المستخدمين دائمًا بتقييم أثر مستويات الضغط وخوارزمياته المختلفة على كلٍّ من أداء الإدراج وأداء الاستعلام. على سبيل المثال، قد تكون codecs من نوع delta مفيدة في ضغط الطوابع الزمنية. ومع ذلك، إذا كانت هذه جزءًا من المفتاح الأساسي، فقد يتراجع أداء التصفية.
طبقات التخزين
غير ذي صلة بـ ClickHouse Cloudيستخدم ClickHouse Cloud نسخة واحدة من البيانات مخزنة على S3، مع ذواكر تخزين مؤقت على العقد مدعومة بـ SSD. لذلك، لا تكون طبقات التخزين مطلوبة في ClickHouse Cloud.
ALTER TABLE MOVE PARTITION، فإنه يمكن أيضًا التحكم في نقل البيانات بين وحدات التخزين باستخدام TTLs. يمكن العثور على مثال كامل هنا.
إدارة تغييرات المخططات
استخدام القيم الافتراضية
DEFAULT. ستُستخدم القيمة الافتراضية المحددة إذا لم تُحدَّد أثناء INSERT.
يمكن إجراء تغييرات على المخطط قبل تعديل أي منطق تحويل في العرض المادي أو تهيئة OTel collector، ما يؤدي إلى إرسال هذه الأعمدة الجديدة.
بمجرد تغيير المخطط، يمكنك إعادة تهيئة OTel collectors. على افتراض أن المستخدمين يتبعون العملية الموصى بها الموضحة في “استخراج البنية باستخدام SQL”، حيث ترسل OTel collectors بياناتها إلى محرك الجدول Null، ويتولى عرض مادي استخراج المخطط المستهدف وإرسال النتائج إلى الجدول المستهدف للتخزين، يمكن تعديل العرض باستخدام صيغة ALTER TABLE ... MODIFY QUERY syntax. لنفترض أن لدينا أدناه الجدول المستهدف مع العرض المادي المقابل له (المشابه لما استُخدم في “استخراج البنية باستخدام SQL”) لاستخراج المخطط المستهدف من السجلات المهيكلة الخاصة بـ OTel:
Size من LogAttributes. يمكننا إضافة ذلك إلى المخطط باستخدام ALTER TABLE، مع تحديد القيمة الافتراضية:
size في LogAttributes (وستكون هذه القيمة 0 إذا لم يكن موجودًا). وهذا يعني أن الاستعلامات التي تصل إلى هذا العمود في الصفوف التي لم تُدرَج فيها هذه القيمة ستحتاج إلى الوصول إلى Map، وبالتالي ستكون أبطأ. ويمكننا أيضًا بسهولة تحديدها كثابت، مثل 0، مما يقلّل تكلفة الاستعلامات اللاحقة على الصفوف التي لا تحتوي على هذه القيمة. ويُظهر الاستعلام عن هذا الجدول أن القيمة قد مُلئت من Map كما هو متوقع:
ALTER TABLE كما هو موضح أدناه:
Size يُعبَّأ عند الإدراج.
إنشاء جداول جديدة
ALTER TABLE MODIFY QUERY. المذكور أعلاه. وبهذا النهج، يمكنك إصدار نسخ من جداولك، مثل otel_logs_v3.
يترك هذا النهج المستخدمين أمام عدة جداول للاستعلام عنها. وللاستعلام عبر عدة جداول، يمكنك استخدام الدالة merge، التي تقبل أنماط wildcard لاسم الجدول. نوضح ذلك أدناه من خلال الاستعلام عن الإصدارين v2 وv3 من جدول otel_logs:
merge وتوفير جدول للمستخدمين النهائيين يجمع بين عدة جداول، فيمكن استخدام محرك جدول Merge. نوضح ذلك أدناه:
EXCHANGE للجدول. على سبيل المثال، لإضافة جدول بالإصدار v4، يمكننا إنشاء جدول جديد واستبداله ذرّيًا بالإصدار السابق.