`)
5. إعدادات الجلسة (من أمر SET)
6. إعدادات الاستعلام (من عبارة SETTINGS)
يمكن تهيئة العمليات الخلفية عبر الإعدادات العامة وإعدادات ملف التعريف 'background'؛ ولا يكون لإعدادات الجلسة والاستعلام أي تأثير في هذه الحالة. وإذا لم يتم تحديد تهيئة صريحة، فسترث التهيئة من السياق العام. اسم ملف التعريف الافتراضي لمثل هذه العمليات هو 'background'، ويمكن تجاوزه عبر إعداد `background_profile` على مستوى الخادم.
## الخيوط والمهام
لتنفيذ الاستعلامات والقيام بالأنشطة الجانبية، يخصّص ClickHouse خيوطًا من أحد تجمعات الخيوط لتجنّب إنشاء الخيوط وإتلافها بشكل متكرر. توجد عدة تجمعات خيوط، ويُختار بينها بحسب الغرض من المهمة وبنيتها:
* تجمع الخادم لجلسات العميل الواردة.
* Global thread pool للمهام العامة، والأنشطة الخلفية، والخيوط المستقلة.
* IO thread pool للمهام التي تكون محجوبة في الغالب على بعض عمليات IO وليست كثيفة الاستهلاك لـ CPU.
* تجمعات Background للمهام الدورية.
* تجمعات للمهام القابلة للمقاطعة التي يمكن تقسيمها إلى خطوات.
تجمع الخادم هو مثيل من الفئة `Poco::ThreadPool` مُعرَّف في الدالة `Server::main()`. ويمكن أن يحتوي على `max_connection` خيطًا كحد أقصى. ويُخصَّص كل خيط لاتصال نشط واحد.
Global thread pool هو الفئة الوحيدة `GlobalThreadPool`. ولتخصيص خيط منه، يُستخدم `ThreadFromGlobalPool`. وله واجهة مشابهة لـ `std::thread`، لكنه يسحب خيطًا من التجمع العام ويجري كل التهيئة اللازمة. ويُضبط بالإعدادات التالية:
* `max_thread_pool_size` - حدّ عدد الخيوط في التجمع.
* `max_thread_pool_free_size` - حدّ عدد الخيوط الخاملة المنتظرة لمهام جديدة.
* `thread_pool_queue_size` - حدّ عدد المهام المجدولة.
التجمع العام شامل، وجميع التجمعات الموصوفة أدناه مبنية فوقه. ويمكن النظر إلى ذلك على أنه تسلسل هرمي من التجمعات. فأي تجمع متخصص يأخذ خيوطه من التجمع العام باستخدام الفئة `ThreadPool`. لذا فإن الغرض الرئيسي لأي تجمع متخصص هو فرض حد على عدد المهام المتزامنة وجدولة المهام. إذا كان عدد المهام المجدولة أكبر من عدد الخيوط في التجمع، فإن `ThreadPool` يكدّس المهام في queue ذات أولويات. ولكل مهمة أولوية عددية صحيحة. والأولوية الافتراضية هي صفر. وتُبدأ جميع المهام ذات قيم الأولوية الأعلى قبل أي مهمة ذات قيمة أولوية أقل. لكن لا يوجد فرق بين المهام التي يجري تنفيذها بالفعل، لذا لا تكون للأولوية أهمية إلا عندما يكون التجمع مثقلاً.
يُنَفَّذ IO thread pool على هيئة `ThreadPool` عادي يمكن الوصول إليه عبر الدالة `IOThreadPool::get()`. ويُضبط بالطريقة نفسها التي يُضبط بها التجمع العام باستخدام الإعدادات `max_io_thread_pool_size` و`max_io_thread_pool_free_size` و`io_thread_pool_queue_size`. والغرض الرئيسي من IO thread pool هو تجنّب استنزاف التجمع العام بمهام IO، وهو ما قد يمنع الاستعلامات من الاستفادة الكاملة من CPU. وتُجري عملية النسخ الاحتياطي إلى S3 قدرًا كبيرًا من عمليات IO، ولتجنّب التأثير في الاستعلامات التفاعلية، يوجد `BackupsIOThreadPool` منفصل يُضبط بالإعدادات `max_backups_io_thread_pool_size` و`max_backups_io_thread_pool_free_size` و`backups_io_thread_pool_queue_size`.
لتنفيذ المهام الدورية، توجد الفئة `BackgroundSchedulePool`. يمكنك تسجيل المهام باستخدام كائنات `BackgroundSchedulePool::TaskHolder`، ويضمن التجمع ألا تُشغِّل أي مهمة مهمتين في الوقت نفسه. كما يتيح لك تأجيل تنفيذ المهمة إلى وقت محدد في المستقبل أو تعطيلها مؤقتًا. يوفّر `Context` العام عدة مثيلات من هذه الفئة لأغراض مختلفة. وبالنسبة إلى المهام العامة، يُستخدم `Context::getSchedulePool()`.
توجد أيضًا تجمعات خيوط متخصصة للمهام القابلة للمقاطعة. يمكن تقسيم مهمة `IExecutableTask` هذه إلى sequence مرتبة من المهام، تُسمى خطوات. ولجدولة هذه المهام بطريقة تسمح بإعطاء أولوية للمهام القصيرة على الطويلة، يُستخدم `MergeTreeBackgroundExecutor`. وكما يوحي الاسم، فإنه يُستخدم لعمليات MergeTree الخلفية ذات الصلة مثل merges وmutations وfetches وmoves. ويمكن الوصول إلى مثيلات التجمع عبر `Context::getCommonExecutor()` ودوال مشابهة أخرى.
بغض النظر عن التجمع المستخدم للمهمة، يُنشأ مثيل `ThreadStatus` لهذه المهمة عند البدء. وهو يغلّف جميع المعلومات الخاصة بكل خيط: معرّف الخيط، ومعرّف query، وعدادات الأداء، واستهلاك الموارد، والعديد من البيانات المفيدة الأخرى. ويمكن للمهمة الوصول إليه عبر مؤشر محلي للخيط من خلال الاستدعاء `CurrentThread::get()`، ولذلك لا نحتاج إلى تمريره إلى كل دالة.
إذا كان الخيط مرتبطًا بتنفيذ query، فإن أهم ما يكون attached بـ `ThreadStatus` هو سياق query `ContextPtr`. لكل query خيطه الرئيسي في تجمع الخادم. ويقوم الخيط الرئيسي بعملية Attach هذه من خلال الاحتفاظ بكائن `ThreadStatus::QueryScope query_scope(query_context)`. كما ينشئ الخيط الرئيسي مجموعة خيوط يمثّلها الكائن `ThreadGroupStatus`. وكل خيط إضافي يُخصَّص أثناء تنفيذ هذا الاستعلام يُربط بمجموعة خيوطه عبر الاستدعاء `CurrentThread::attachTo(thread_group)`. وتُستخدم مجموعات الخيوط لتجميع عدادات أحداث profile وتتبع استهلاك الذاكرة بواسطة جميع الخيوط المخصصة لمهمة واحدة (انظر الفئتَين `MemoryTracker` و`ProfileEvents::Counters` لمزيد من المعلومات).
## التحكم في التزامن
يستخدم الاستعلام القابل للتنفيذ على التوازي الإعداد `max_threads` لتقييد نفسه. وتُختار القيمة الافتراضية لهذا الإعداد بطريقة تسمح لاستعلام واحد بالاستفادة المثلى من جميع أنوية CPU. لكن ماذا لو وُجدت عدة استعلامات متزامنة وكان كلٌّ منها يستخدم القيمة الافتراضية للإعداد `max_threads`؟ عندئذٍ ستتقاسم الاستعلامات موارد CPU. وسيضمن نظام التشغيل العدالة من خلال التبديل المستمر بين خيوط التنفيذ، ما يفرض كلفةً إضافية على الأداء. تساعد `ConcurrencyControl` في التعامل مع هذه الكلفة وتجنّب تخصيص عدد كبير من خيوط التنفيذ. ويُستخدم إعداد التهيئة `concurrent_threads_soft_limit_num` لتقييد عدد خيوط التنفيذ المتزامنة التي يمكن تخصيصها قبل تطبيق نوع من ضغط CPU.
يُقدَّم مفهوم `slot` في CPU. وتمثل الـ `slot` وحدةً للتزامن: فلكي يشغّل الاستعلام خيط تنفيذ، يجب أن يحصل مسبقًا على `slot` ثم يحررها عند توقف الخيط. ويكون عدد الـ `slots` محدودًا على مستوى الخادم ككل. وتتنافس الاستعلامات المتزامنة المتعددة على `CPU slots` إذا تجاوز إجمالي الطلب العدد الإجمالي للـ `slots`. وتتولى `ConcurrencyControl` حل هذا التنافس من خلال جدولة `CPU slots` بطريقة عادلة.
يمكن النظر إلى كل `slot` على أنها آلة حالات مستقلة لها الحالات التالية:
* `free`: الـ `slot` متاحة لتُخصَّص لأي استعلام.
* `granted`: الـ `slot` `allocated` لاستعلام محدد، ولكن لم يكتسبها أي خيط تنفيذ بعد.
* `acquired`: الـ `slot` `allocated` لاستعلام محدد وقد اكتسبها خيط تنفيذ.
لاحظ أن الـ `slot` التي تكون `allocated` يمكن أن تكون في حالتين مختلفتين: `granted` و`acquired`. الأولى حالة انتقالية، ويُفترض عمليًا أن تكون قصيرة (من اللحظة التي تُخصَّص فيها `slot` لاستعلام إلى اللحظة التي يُشغَّل فيها إجراء التوسعة التصاعدية بواسطة أي خيط تنفيذ لذلك الاستعلام).
```mermaid theme={null}
stateDiagram-v2
direction LR
[*] --> free
free --> allocated: allocate
state allocated {
direction LR
[*] --> granted
granted --> acquired: acquire
acquired --> [*]
}
allocated --> free: release
```
تتكوّن واجهة برمجة تطبيقات `ConcurrencyControl` من الدوال التالية:
1. أنشئ تخصيص موارد لاستعلام: `auto slots = ConcurrencyControl::instance().allocate(1, max_threads);`. سيُخصِّص ما لا يقل عن فتحة واحدة وما لا يزيد عن `max_threads` من الفتحات. لاحظ أن الفتحة الأولى تُمنَح فورًا، لكن قد تُمنَح الفتحات المتبقية لاحقًا. لذا فالحدّ مرن، لأن كل استعلام سيحصل على خيط تنفيذ واحد على الأقل.
2. لكل خيط تنفيذ، يجب الحصول على فتحة من التخصيص: `while (auto slot = slots->tryAcquire()) spawnThread([slot = std::move(slot)] { ... });`.
3. حدِّث العدد الإجمالي للفتحات: `ConcurrencyControl::setMaxConcurrency(concurrent_threads_soft_limit_num)`. يمكن تنفيذ ذلك أثناء التشغيل، من دون إعادة تشغيل الخادم.
تتيح واجهة برمجة التطبيقات هذه للاستعلامات أن تبدأ بخيط تنفيذ واحد على الأقل (عند وجود ضغط على CPU)، ثم تتوسع لاحقًا حتى `max_threads`.
## تنفيذ الاستعلامات الموزعة
تكون الخوادم في إعداد العنقود مستقلةً إلى حد كبير. يمكنك إنشاء جدول `Distributed` على خادم واحد أو على جميع خوادم العنقود. ولا يخزّن جدول `Distributed` البيانات بنفسه، بل يوفّر فقط "عرضًا" لجميع الجداول المحلية على عدة عقد في العنقود. وعند تنفيذ SELECT من جدول `Distributed`، يعيد كتابة ذلك الاستعلام، ويختار العقد البعيدة وفقًا لإعدادات موازنة التحميل، ثم يرسل الاستعلام إليها. ويطلب جدول `Distributed` من الخوادم البعيدة معالجة الاستعلام إلى المرحلة التي يمكن عندها دمج النتائج الوسيطة القادمة من خوادم مختلفة. ثم يستقبل هذه النتائج الوسيطة ويقوم بدمجها. ويحاول الجدول الموزع إسناد أكبر قدر ممكن من العمل إلى الخوادم البعيدة، بحيث لا يرسل الكثير من البيانات الوسيطة عبر الشبكة.
تصبح الأمور أكثر تعقيدًا عندما تكون لديك استعلامات فرعية داخل عبارات IN أو JOIN، ويستخدم كلٌّ منها جدول `Distributed`. ولدينا استراتيجيات مختلفة لتنفيذ هذه الاستعلامات.
لا توجد خطة تنفيذ استعلام عامة لتنفيذ الاستعلامات الموزعة. فلكل عقدة خطة تنفيذ استعلام محلية خاصة بها للجزء الذي تنفذه من المهمة. وما لدينا هو فقط تنفيذ موزع بسيط من مرور واحد: نرسل الاستعلامات إلى العقد البعيدة ثم ندمج النتائج. لكن هذا غير عملي للاستعلامات المعقدة ذات `GROUP BY` عالي الكاردينالية أو التي تتضمن قدرًا كبيرًا من البيانات المؤقتة اللازمة لعمليات JOIN. وفي مثل هذه الحالات، نحتاج إلى "إعادة توزيع" البيانات بين الخوادم، وهو ما يتطلب تنسيقًا إضافيًا. ولا يدعم ClickHouse هذا النوع من تنفيذ الاستعلامات، ونحتاج إلى العمل عليه.
## MergeTree
`MergeTree` هي عائلة من محركات التخزين التي تدعم الفهرسة باستخدام المفتاح الأساسي. ويمكن أن يكون المفتاح الأساسي Tuple اعتباطيًا من الأعمدة أو التعبيرات. وتُخزَّن البيانات في جدول `MergeTree` على شكل "أجزاء". ويخزّن كل جزء البيانات بترتيب المفتاح الأساسي، لذا تكون البيانات مرتبة ترتيبًا معجميًا وفق Tuple المفتاح الأساسي. وتُخزَّن جميع أعمدة الجدول في ملفات `column.bin` منفصلة داخل هذه الأجزاء. وتتكوّن الملفات من blocks مضغوطة. ويكون كل block عادةً بين 64 كيلوبايت و1 ميغابايت من البيانات غير المضغوطة، وذلك بحسب متوسط حجم القيم. وتتكوّن الـ blocks من قيم الأعمدة الموضوعة بشكل متجاور، واحدة تلو الأخرى. وتكون قيم الأعمدة بالترتيب نفسه في كل عمود (إذ يحدد المفتاح الأساسي هذا الترتيب)، لذلك عندما تمر عبر عدة أعمدة، تحصل على قيم الصفوف المقابلة.
والمفتاح الأساسي نفسه "sparse". فهو لا يشير إلى كل row على حدة، بل إلى بعض ranges من البيانات فقط. ويحتوي ملف `primary.idx` منفصل على قيمة المفتاح الأساسي لكل صف رقم N، حيث يُسمّى N بـ `index_granularity` (وعادةً ما تكون N = 8192). كذلك، يوجد لكل عمود ملفات `column.mrk` تحتوي على "marks"، وهي offsets لكل صف رقم N داخل ملف البيانات. وكل mark عبارة عن زوج: offset في الملف إلى بداية الـ block المضغوط، وoffset في الـ block غير المضغوط إلى بداية البيانات. وعادةً ما تكون الـ blocks المضغوطة محاذيةً وفق marks، ويكون offset في الـ block غير المضغوط صفرًا. وتقيم بيانات `primary.idx` دائمًا في الذاكرة، بينما تكون بيانات ملفات `column.mrk` مخزنة مؤقتًا.
عندما نريد قراءة شيء من جزء في `MergeTree`، ننظر إلى بيانات `primary.idx` ونحدّد ranges التي قد تحتوي على البيانات المطلوبة، ثم ننظر إلى بيانات `column.mrk` ونحسب offsets الخاصة بموضع بدء قراءة تلك ranges. وبسبب هذه الخاصية المتفرقة، قد تُقرأ بيانات زائدة. لا يُعد ClickHouse مناسبًا للأحمال العالية من الاستعلامات النقطية البسيطة، لأنه يجب قراءة النطاق الكامل الذي يحتوي على `index_granularity` من rows لكل مفتاح، كما يجب فك ضغط الـ block المضغوط بالكامل لكل عمود. وقد جعلنا الفهرس sparse لأننا نحتاج إلى القدرة على إدارة تريليونات من rows على server واحد من دون استهلاك ملحوظ للذاكرة من أجل الفهرس. كذلك، وبما أن المفتاح الأساسي sparse، فهو ليس فريدًا: إذ لا يمكنه التحقق من وجود المفتاح في الجدول وقت `INSERT`. ويمكن أن يحتوي الجدول على العديد من rows بالمفتاح نفسه.
عندما تقوم بـ `INSERT` لمجموعة من البيانات إلى `MergeTree`، تُرتَّب تلك المجموعة وفق ترتيب المفتاح الأساسي وتشكّل جزء جديدًا. وتوجد threads تعمل في الخلفية تختار دوريًا بعض أجزاء وتدمجها في جزء واحد مرتب للحفاظ على عدد أجزاء منخفضًا نسبيًا. ولهذا سُمّي `MergeTree`. وبالطبع، يؤدي الدمج إلى "write amplification". فجميع أجزاء غير قابلة للتغيير: فهي تُنشأ وتُحذف فقط، ولا تُعدَّل. وعند تنفيذ SELECT، فإنه يحتفظ بـ snapshot للجدول (أي مجموعة من أجزاء). وبعد الدمج، نحتفظ أيضًا بالأجزاء القديمة لبعض الوقت لتسهيل recovery بعد الفشل، لذلك إذا رأينا أن merged جزء ما قد يكون معطوبًا، فيمكننا استبداله بـ source أجزاء الخاصة به.
`MergeTree` ليس شجرة LSM لأنه لا يحتوي على MEMTABLE وLOG: إذ تُكتب البيانات المُدرجة مباشرةً إلى filesystem. ويجعل هذا السلوك MergeTree أكثر ملاءمة بكثير لإدراج البيانات على شكل batches. لذلك، فإن إدراج كميات صغيرة من rows بشكل متكرر ليس مثاليًا لـ MergeTree. فعلى سبيل المثال، إدراج صفين كل ثانية أمر مقبول، لكن القيام بذلك ألف مرة في الثانية ليس أمثل لـ MergeTree. ومع ذلك، يوجد وضع async insert لعمليات الإدراج الصغيرة لتجاوز هذا القيد. وقد صممناه بهذه الطريقة حرصًا على البساطة، ولأننا نُدرج البيانات أصلًا على شكل batches في تطبيقاتنا
توجد محركات MergeTree تنفّذ عملًا إضافيًا أثناء merges التي تجري في الخلفية. ومن أمثلتها `CollapsingMergeTree` و`AggregatingMergeTree`. ويمكن اعتبار هذا دعمًا خاصًا للتحديثات. ضع في حسبانك أن هذه ليست تحديثات حقيقية، لأن المستخدمين عادةً لا يملكون أي تحكم في وقت تنفيذ background merges، ولأن البيانات في جدول `MergeTree` تُخزَّن غالبًا في أكثر من جزء واحد، وليس في صورة مدمجة بالكامل.
## النسخ المتماثل
يمكن تهيئة النسخ المتماثل في ClickHouse على مستوى كل جدول على حدة. فيمكن أن يكون لديك بعض الجداول المتماثلة وأخرى غير متماثلة على الخادم نفسه. كما يمكن أيضًا أن تُنسخ الجداول بطرق مختلفة، مثل جدول بنسخ متماثل ثنائي وآخر ثلاثي.
يُنفَّذ النسخ المتماثل في محرك التخزين `ReplicatedMergeTree`. ويُحدَّد المسار في `ZooKeeper` كمعامل لمحرك التخزين. وتصبح جميع الجداول التي لها المسار نفسه في `ZooKeeper` نُسخًا متماثلة لبعضها: فهي تزامن بياناتها وتحافظ على الاتساق. ويمكن إضافة النُسخ المتماثلة وإزالتها ديناميكيًا بمجرد إنشاء جدول أو حذفه.
يستخدم النسخ المتماثل مخططًا غير متزامن متعدد الجهات الرئيسية. يمكنك إدراج البيانات في أي نسخة متماثلة لديها session مع `ZooKeeper`، وتُنسخ البيانات إلى جميع النسخ المتماثلة الأخرى بصورة غير متزامنة. ونظرًا إلى أن ClickHouse لا يدعم UPDATEs، فإن النسخ المتماثل خالٍ من التعارضات. وبما أنه لا يوجد، افتراضيًا، إقرار quorum لعمليات الإدراج، فقد تُفقَد البيانات المُدرجة حديثًا إذا تعطلت إحدى العُقد. ويمكن تمكين quorum الإدراج باستخدام الإعداد `insert_quorum`.
تُخزَّن البيانات الوصفية الخاصة بالنسخ المتماثل في ZooKeeper. ويوجد سجل للنسخ المتماثل يسرد الإجراءات المطلوب تنفيذها. وتشمل هذه الإجراءات: جلب جزء، ودمج أجزاء، وحذف partition، وما إلى ذلك. وتنسخ كل نسخة متماثلة سجل النسخ المتماثل إلى queue الخاصة بها، ثم تنفّذ الإجراءات منها. فعلى سبيل المثال، عند الإدراج، يُنشأ في السجل إجراء "get the جزء"، ثم تقوم كل نسخة متماثلة بتنزيل ذلك الجزء. وتُنسَّق عمليات الدمج بين النسخ المتماثلة للحصول على نتائج متطابقة على مستوى البايت. وتُدمج جميع أجزاء بالطريقة نفسها على جميع النسخ المتماثلة. ويبدأ أحد القادة أولًا عملية دمج جديدة ويكتب إجراءات "merge أجزاء" في السجل. ويمكن أن تكون عدة نسخ متماثلة (أو جميعها) قادة في الوقت نفسه. ويمكن منع نسخة متماثلة من أن تصبح قائدًا باستخدام إعداد `merge_tree` `replicated_can_become_leader`. ويتولى القادة مسؤولية جدولة عمليات الدمج في الخلفية.
النسخ المتماثل فيزيائي: إذ لا تُنقل بين العُقد إلا أجزاء المضغوطة، وليس queries. وتُعالَج عمليات الدمج على كل نسخة متماثلة بصورة مستقلة في معظم الحالات لخفض تكاليف الشبكة من خلال تجنب تضخيم حركة الشبكة. ولا تُرسل أجزاء المدمجة الكبيرة عبر الشبكة إلا في حالات تأخر النسخ المتماثل الكبير.
إضافة إلى ذلك، تخزّن كل نسخة متماثلة حالتها في ZooKeeper على شكل مجموعة من أجزاء وقيم checksums الخاصة بها. وعندما تنحرف الحالة على local filesystem عن الحالة المرجعية في ZooKeeper، تستعيد النسخة المتماثلة اتساقها بتنزيل أجزاء المفقودة والتالفة من النسخ المتماثلة الأخرى. وعندما توجد بيانات غير متوقعة أو تالفة في local filesystem، فإن ClickHouse لا يزيلها، بل ينقلها إلى directory منفصل ويتجاهلها.
تتكوّن مجموعة ClickHouse من shards مستقلة، ويتكوّن كل shard من replicas. وهذه المجموعة **غير مرنة**، لذلك بعد إضافة shard جديدة، لا يُعاد توازن البيانات بين shards تلقائيًا. وبدلًا من ذلك، يُفترض ضبط حمل المجموعة بحيث يكون غير متساوٍ. يمنحك هذا التنفيذ قدرًا أكبر من التحكم، وهو مناسب للمجموعات الصغيرة نسبيًا، مثل تلك التي تضم عشرات العُقد. لكن بالنسبة إلى المجموعات التي تضم مئات العُقد التي نستخدمها في production، يصبح هذا النهج عيبًا كبيرًا. ينبغي أن ننفّذ محرك جدول يمتد عبر المجموعة مع مناطق متماثلة ديناميكيًا يمكن تقسيمها وموازنتها بين clusters تلقائيًا.