اختيار مفتاح التقسيم

صفحة توضّح كيفية اختيار مفتاح التقسيم

أسلوب لإدارة البيانات

يُعدّ التقسيم بالدرجة الأولى أسلوبًا لإدارة البيانات، وليس أداة لتحسين الاستعلامات. ومع أنه قد يحسّن الأداء في بعض أعباء العمل المحددة، فلا ينبغي أن يكون الخيار الأول لتسريع الاستعلامات. ويجب اختيار مفتاح التقسيم بعناية، مع فهم واضح لتداعياته، وألّا يُستخدم إلا عندما يتوافق مع احتياجات دورة حياة البيانات أو مع أنماط الوصول المفهومة جيدًا.

في ClickHouse، ينظّم التقسيم البيانات في مقاطع منطقية استنادًا إلى مفتاح محدد. ويُعرَّف ذلك باستخدام عبارة PARTITION BY عند إنشاء الجدول، ويُستخدم عادةً لتجميع الصفوف بحسب الفترات الزمنية أو الفئات أو غيرها من الأبعاد ذات الصلة بالأعمال. وتُشكّل كل قيمة فريدة لتعبير التقسيم partition مستقلًا فعليًا على القرص، ويخزّن ClickHouse البيانات في أجزاء بيانات منفصلة لكل قيمة من هذه القيم. ويساعد التقسيم في تحسين إدارة البيانات، وتبسيط سياسات الاحتفاظ، وقد يفيد أيضًا في بعض أنماط الاستعلام.

على سبيل المثال، تأمل جدول مجموعة بيانات أسعار العقارات المدفوعة في المملكة المتحدة التالي، مع مفتاح تقسيم هو toStartOfMonth(date).

CREATE TABLE uk.uk_price_paid_simple_partitioned
(
  date Date,
  town LowCardinality(String),
  street LowCardinality(String),
  price UInt32
)
ENGINE = MergeTree
ORDER BY (town, street)
PARTITION BY toStartOfMonth(date)

كلما أُدرجت مجموعة من الصفوف في الجدول، فبدلاً من إنشاء (على الأقل) جزء بيانات واحد يحتوي على جميع الصفوف المُدرجة (كما هو موضح هنا)، ينشئ ClickHouse جزء بيانات جديدًا لكل قيمة فريدة لمفتاح التقسيم بين الصفوف المُدرجة:

يقوم خادم ClickHouse أولاً بتقسيم الصفوف في مثال الإدراج ذي الصفوف الأربعة الموضَّح في المخطط أعلاه وفقًا لقيمة مفتاح التقسيم toStartOfMonth(date). ثم، لكل قسم تم تحديده، تُعالَج الصفوف كالمعتاد هنا عبر تنفيذ عدة خطوات متسلسلة (① الفرز، ② التقسيم إلى أعمدة، ③ الضغط، ④ الكتابة إلى القرص).

للحصول على شرح أكثر تفصيلاً للتقسيم، نوصي بهذا الدليل.

عند تمكين التقسيم، لا يدمج ClickHouse أجزاء البيانات إلا داخل الأقسام نفسها، وليس عبر الأقسام المختلفة. نوضّح ذلك تخطيطيًا لجدول المثال أعلاه:

​

تطبيقات التقسيم

يُعدّ التقسيم أداة قوية لإدارة مجموعات البيانات الكبيرة في ClickHouse، خاصةً في حالات استخدام Observability والتحليلات. فهو يتيح تنفيذ عمليات فعّالة على دورة حياة البيانات، إذ يسمح بحذف partitionات كاملة أو نقلها أو أرشفتها ضمن عملية metadata واحدة، وغالبًا ما تكون هذه الـ partitionات مرتبطة بالوقت أو business logic. وهذا أسرع بكثير وأقل استهلاكًا للموارد من عمليات الحذف أو النسخ على مستوى الصف. كما يتكامل التقسيم بسلاسة مع ميزات ClickHouse مثل TTL وtiered storage، مما يتيح تطبيق سياسات الاحتفاظ بالبيانات أو استراتيجيات التخزين الساخن/البارد دون الحاجة إلى orchestration مخصص. فعلى سبيل المثال، يمكن الاحتفاظ بالبيانات الحديثة على وحدة تخزين سريعة مدعومة بأقراص SSD، بينما تُنقل الـ partitionات الأقدم تلقائيًا إلى object storage أقل تكلفة.

ومع أن التقسيم قد يحسّن query performance لبعض workloads، فقد يؤثر سلبًا أيضًا في response time.

إذا لم يكن مفتاح التقسيم ضمن primary key وكنت تستخدمه في filter، فقد يلاحظ المستخدمون تحسنًا في query performance عند استخدام التقسيم. راجع هنا للاطلاع على مثال.

في المقابل، إذا كانت queries تحتاج إلى الاستعلام عبر partitionات متعددة، فقد يتأثر الأداء سلبًا بسبب ارتفاع العدد الإجمالي من أجزاء البيانات. ولهذا السبب، ينبغي للمستخدمين فهم access patterns لديهم قبل اعتبار التقسيم أسلوبًا من أساليب تحسين الاستعلام.

باختصار، ينبغي للمستخدمين النظر إلى التقسيم في المقام الأول بوصفه أسلوبًا لإدارة البيانات. وللاطلاع على مثال حول إدارة البيانات، راجع “Managing Data” من دليل حالة استخدام Observability و”فيما تُستخدم أقسام الجدول؟” من المفاهيم الأساسية - أقسام الجدول.

​

اختر مفتاح تقسيم منخفض الكاردينالية

من المهم ملاحظة أن زيادة عدد الأجزاء تؤثر سلبًا في أداء الاستعلامات. لذلك، سيردّ ClickHouse على عمليات الإدراج بخطأ “too many parts” إذا تجاوز عدد الأجزاء الحدود المحددة، سواء إجمالًا أو لكل قسم.

إن اختيار الكاردينالية المناسبة لمفتاح التقسيم أمر بالغ الأهمية. فمفتاح التقسيم عالي الكاردينالية — حيث يكون عدد قيم الأقسام المميزة كبيرًا — قد يؤدي إلى تكاثر الأجزاء. وبما أن ClickHouse لا يدمج الأجزاء عبر الأقسام، فإن كثرة الأقسام ستؤدي إلى كثرة الأجزاء غير المدمجة، مما يتسبب في النهاية في ظهور خطأ “Too many parts”. وتُعد عمليات الدمج أساسية لتقليل تجزؤ التخزين وتحسين سرعة الاستعلامات، لكن مع الأقسام عالية الكاردينالية تضيع إمكانية الدمج هذه.

في المقابل، يكون مفتاح التقسيم منخفض الكاردينالية — الذي يحتوي على أقل من 100 إلى 1,000 قيمة مميزة — هو الخيار الأمثل عادةً. فهو يتيح دمج الأجزاء بكفاءة، ويُبقي الحمل الإضافي للبيانات الوصفية منخفضًا، ويتجنب الإنشاء المفرط للكائنات في التخزين. بالإضافة إلى ذلك، ينشئ ClickHouse تلقائيًا فهارس MinMax على أعمدة التقسيم، ما قد يسرّع بدرجة كبيرة الاستعلامات التي تُطبّق عامل تصفية على تلك الأعمدة. على سبيل المثال، يتيح التصفية حسب الشهر عندما يكون الجدول مقسمًا بواسطة toStartOfMonth(date) للمحرّك تخطي الأقسام غير ذات الصلة وأجزائها بالكامل.

ومع أن التقسيم قد يحسّن الأداء في بعض أنماط الاستعلامات، فإنه في الأساس ميزة لإدارة البيانات. ففي كثير من الحالات، قد يكون الاستعلام عبر جميع الأقسام أبطأ من استخدام جدول غير مقسم بسبب زيادة تجزؤ البيانات ومسح عدد أكبر من الأجزاء. استخدم التقسيم بحذر، واحرص دائمًا على أن يكون المفتاح المختار منخفض الكاردينالية ومتوافقًا مع سياسات دورة حياة بياناتك (مثلًا، الاحتفاظ عبر TTL). وإذا لم تكن متأكدًا مما إذا كان التقسيم ضروريًا، فقد يكون من الأفضل أن تبدأ من دونه ثم تُجري التحسين لاحقًا استنادًا إلى أنماط الوصول الفعلية التي تلاحظها.