ملحق

معلومات إضافية حول الترحيل من PostgreSQL

​

Postgres مقابل ClickHouse: المفاهيم المتكافئة والمختلفة

يجب أن يكون المستخدمون القادمون من أنظمة OLTP والمعتادون على معاملات ACID على دراية بأن ClickHouse يقدّم تنازلات مقصودة بعدم توفير هذه الخصائص بالكامل مقابل الأداء. ويمكن أن توفّر دلالات ClickHouse ضمانات عالية للمتانة ومعدل نقل مرتفعًا لعمليات الكتابة إذا فُهمت جيدًا. ونستعرض أدناه بعض المفاهيم الأساسية التي ينبغي الإلمام بها قبل البدء في استخدام ClickHouse انطلاقًا من Postgres.

​

الشظايا مقابل النسخ المتماثلة

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

وعلى خلاف الشظايا، فإن النسخ المتماثلة هي مثيلات Postgres إضافية تحتوي على كل البيانات من العُقدة الأساسية أو بعضها. تُستخدم النسخ المتماثلة لأسباب متعددة، منها تحسين أداء القراءة وسيناريوهات HA (التوافر العالي). يُعد النسخ المتماثل الفيزيائي ميزة أصلية في Postgres، ويتضمن نسخ قاعدة البيانات بالكامل أو أجزاء كبيرة منها إلى خادم آخر، بما في ذلك جميع قواعد البيانات والجداول والفهارس. ويتضمن ذلك بث مقاطع WAL من العُقدة الأساسية إلى النسخ المتماثلة عبر TCP/IP. في المقابل، يُعد النسخ المتماثل المنطقي مستوى أعلى من التجريد، إذ يبث التغييرات استنادًا إلى عمليات INSERT وUPDATE وDELETE. وعلى الرغم من أن النتائج نفسها قد تنطبق على النسخ المتماثل الفيزيائي، فإنه يوفّر مرونة أكبر لاستهداف جداول وعمليات محددة، وكذلك لإجراء تحويلات على البيانات ودعم إصدارات مختلفة من Postgres.

في المقابل، تُعد الشظايا والنسخ المتماثلة في ClickHouse مفهومين أساسيين مرتبطين بتوزيع البيانات والتكرار. ويمكن النظر إلى النسخ المتماثلة في ClickHouse على أنها مماثلة لنسخ Postgres المتماثلة، مع أن النسخ المتماثل فيها متسق نهائيًا ولا يوجد فيه مفهوم للعُقدة الأساسية. أما التجزئة، فعلى خلاف Postgres، فهي مدعومة أصلاً.

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

النسخة المتماثلة هي نسخة من بياناتك. يحتوي ClickHouse دائمًا على نسخة واحدة على الأقل من بياناتك، ولذلك فإن الحد الأدنى لعدد النسخ المتماثلة هو واحد. وتؤدي إضافة نسخة متماثلة ثانية من بياناتك إلى توفير تحمّل للأعطال وربما قدرة حاسوبية إضافية لمعالجة المزيد من الاستعلامات (يمكن أيضًا استخدام Parallel Replicas لتوزيع القدرة الحاسوبية لاستعلام واحد، مما يقلل زمن الاستجابة). وتتحقق النسخ المتماثلة باستخدام ReplicatedMergeTree table engine، الذي يمكّن ClickHouse من إبقاء نسخ متعددة من البيانات متزامنة عبر خوادم مختلفة. النسخ المتماثل فيزيائي: لا تُنقل بين العُقد إلا الأجزاء المضغوطة، وليس الاستعلامات.

باختصار، النسخة المتماثلة هي نسخة من البيانات توفّر التكرار والموثوقية (وربما المعالجة الموزعة)، بينما الشظية هي مجموعة فرعية من البيانات تتيح المعالجة الموزعة وموازنة الحمل.

يستخدم ClickHouse Cloud نسخة واحدة من البيانات مخزنة في S3 مع عدة نسخ متماثلة حاسوبية. وتكون البيانات متاحة لكل عُقدة نسخة متماثلة، ولكل منها local SSD cache. ويعتمد ذلك على نسخ البيانات الوصفية فقط عبر ClickHouse Keeper.

​

الاتساق النهائي

يستخدم ClickHouse خدمة ClickHouse Keeper ‏(وهي تنفيذ لـ ZooKeeper بلغة C++، كما يمكن أيضًا استخدام ZooKeeper) لإدارة آلية النسخ المتماثل الداخلية لديه، مع التركيز أساسًا على تخزين البيانات الوصفية وضمان الاتساق النهائي. ويُستخدم Keeper لإسناد أرقام تسلسلية فريدة لكل عملية insert ضمن بيئة موزعة. ويُعد ذلك بالغ الأهمية للحفاظ على الترتيب والاتساق عبر العمليات. كما يتولى هذا الإطار العمليات التي تعمل في الخلفية، مثل عمليات الدمج وعمليات mutation، بما يضمن توزيع العمل بينها مع ضمان تنفيذها بالترتيب نفسه عبر جميع النسخ المتماثلة. وإلى جانب البيانات الوصفية، يعمل Keeper كمركز تحكم متكامل للنسخ المتماثل، بما في ذلك تتبّع checksums لأجزاء البيانات المخزنة، كما يؤدي دور نظام إشعارات موزع بين النسخ المتماثلة.

تبدأ عملية النسخ المتماثل في ClickHouse (1) عندما تُدرَج البيانات في أي نسخة متماثلة. وتُكتَب هذه البيانات، بصيغة insert الخام الخاصة بها، (2) على القرص مع checksums الخاصة بها. وبعد اكتمال الكتابة، تحاول النسخة المتماثلة (3) تسجيل جزء البيانات الجديد هذا في Keeper من خلال تخصيص رقم block فريد وتسجيل تفاصيل الجزء الجديد. ثم تقوم النسخ المتماثلة الأخرى، عند (4) اكتشاف إدخالات جديدة في سجل النسخ المتماثل، (5) بتنزيل جزء البيانات المقابل عبر بروتوكول HTTP داخلي، مع التحقق منه بمطابقته مع checksums المدرجة في ZooKeeper. وتضمن هذه الطريقة أن تمتلك جميع النسخ المتماثلة، في نهاية المطاف، بيانات متسقة ومحدّثة رغم اختلاف سرعات المعالجة أو احتمال حدوث تأخيرات. وعلاوة على ذلك، يستطيع النظام التعامل مع عمليات متعددة بالتوازي، مما يحسّن عمليات إدارة البيانات ويتيح للنظام قابلية التوسع والمتانة في مواجهة تفاوت العتاد.

لاحظ أن ClickHouse Cloud يستخدم آلية نسخ متماثل محسّنة للسحابة ومكيّفة مع معمارية الفصل بين التخزين والحوسبة. ومن خلال تخزين البيانات في تخزين كائني مشترك، تصبح البيانات متاحة تلقائيًا لجميع عقد الحوسبة من دون الحاجة إلى نسخها ماديًا بين العقد. وبدلًا من ذلك، يُستخدم Keeper فقط لمشاركة البيانات الوصفية (أي ما البيانات الموجودة وأين توجد في التخزين الكائني) بين عقد الحوسبة.

يعتمد PostgreSQL استراتيجية مختلفة للنسخ المتماثل مقارنةً بـ ClickHouse، إذ يستخدم أساسًا النسخ المتماثل بالتدفق، الذي يتضمن نموذجًا تكون فيه عقدة أساسية هي المصدر الذي تُبث منه البيانات باستمرار إلى عقدة نسخة متماثلة واحدة أو أكثر. ويضمن هذا النوع من النسخ المتماثل اتساقًا قريبًا من الوقت الفعلي، ويمكن أن يكون متزامنًا أو غير متزامن، مما يمنح المسؤولين تحكمًا في الموازنة بين التوافر والاتساق. وعلى خلاف ClickHouse، يعتمد PostgreSQL على WAL ‏(Write-Ahead Logging) مع النسخ المتماثل المنطقي وdecoding لبث كائنات البيانات والتغييرات بين العقد. ويُعد هذا النهج في PostgreSQL أكثر مباشرة، لكنه قد لا يوفّر المستوى نفسه من قابلية التوسع وتحمل الأعطال في البيئات شديدة التوزيع الذي يحققه ClickHouse من خلال استخدامه المتقدم لـ Keeper في تنسيق العمليات الموزعة وتحقيق الاتساق النهائي.

​

آثار ذلك على المستخدم

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

في المقابل، يمكن لنموذج النسخ المتماثل بالتدفق في PostgreSQL عادةً منع القراءات المتسخة من خلال استخدام خيارات النسخ المتماثل المتزامن، حيث تنتظر العقدة العقدة الأساسية تأكيد استلام البيانات من نسخة متماثلة واحدة على الأقل قبل commit Transactions. وهذا يضمن أنه بمجرد commit معاملة، تكون البيانات متاحة أيضًا على نسخة متماثلة أخرى. وفي حال تعطل العقدة العقدة الأساسية، تضمن النسخة المتماثلة أن ترى queries البيانات التي تم commit لها، مما يحافظ على مستوى أكثر صرامة من الاتساق.

​

توصيات

ينبغي للمستخدمين الجدد في ClickHouse أن يكونوا على دراية بهذه الاختلافات، إذ ستظهر بوضوح في البيئات المعتمدة على النسخ المتماثل. وعادةً ما يكون الاتساق النهائي كافيًا في التحليلات التي تتعامل مع مليارات، إن لم يكن تريليونات، من نقاط البيانات، حيث تكون المقاييس أكثر استقرارًا أو يكون التقدير كافيًا مع استمرار إدخال بيانات جديدة بمعدلات مرتفعة.

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

​

التوجيه المتسق

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

يمكن تحقيق ذلك بعدة أساليب، بحسب معمارية نظامك وما إذا كنت تستخدم ClickHouse OSS أو ClickHouse Cloud.

​

ClickHouse Cloud

يستخدم ClickHouse Cloud نسخةً واحدة من البيانات مخزّنة على S3 مع عدة نُسخ متماثلة للحوسبة. وتكون البيانات متاحة لكل عقدة replica لديها local SSD cache. لذلك، ولضمان الحصول على نتائج متسقة، لا يحتاج المستخدمون إلا إلى ضمان توجيه الطلبات باستمرار إلى العقدة نفسها.

يتم التواصل مع عقد خدمة ClickHouse Cloud عبر proxy. وتُوجَّه اتصالات HTTP واتصالات البروتوكول الأصلي إلى العقدة نفسها طوال المدة التي تظل فيها مفتوحة. وفي حالة اتصالات HTTP 1.1 القادمة من معظم clients، يعتمد ذلك على فترة Keep-Alive. ويمكن ضبط هذا في معظم clients، مثل Node Js. ويتطلب ذلك أيضًا config من جهة server تكون قيمتها أعلى من جهة client، وهي مضبوطة على 10s في ClickHouse Cloud.

ولضمان توجيه متسق عبر connections، مثلًا عند استخدام connection pool أو عند انتهاء صلاحية connections، يمكنك إما التأكد من استخدام connection نفسها (وهذا أسهل مع native) أو طلب إتاحة endpoints مثبتة. ويوفر ذلك مجموعة من endpoints لكل عقدة في cluster، مما يتيح للعملاء ضمان توجيه queries بشكل deterministic.

تواصل مع الدعم للحصول على إمكانية الوصول إلى endpoints المثبتة.

​

ClickHouse OSS

يعتمد تحقيق هذا السلوك في OSS على طوبولوجيا الشظية والنسخة المتماثلة لديك، وعلى ما إذا كنت تستخدم جدولًا موزعًا للاستعلام.

عندما تكون لديك شظية واحدة فقط مع نسخ متماثلة (وهذا شائع لأن ClickHouse يتوسع رأسيًا)، يختار المستخدمون العقدة على مستوى العميل ويستعلمون من نسخة متماثلة مباشرةً، مع ضمان أن يتم هذا الاختيار بشكل حتمي.

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

في هذه الحالة، ينبغي أن تضمن تنفيذ توجيه متسق للعقد استنادًا إلى خاصية مثل session_id أو user_id. يجب ضبط الإعدادات على مستوى الاستعلام prefer_localhost_replica=0، load_balancing=in_order. سيضمن ذلك تفضيل أي نسخ متماثلة محلية للشظايا، وإلا فستُفضَّل النسخ المتماثلة بحسب ترتيبها في الإعداد، ما دامت تملك العدد نفسه من الأخطاء — أما إذا كان عدد الأخطاء أعلى فسيحدث التحويل التلقائي عند الفشل مع اختيار عشوائي. ويمكن أيضًا استخدام load_balancing=nearest_hostname كبديل لهذا الاختيار الحتمي للشظية.

عند إنشاء جدول موزع، ستحدّد cluster. وسيعرض تعريف هذا الـ cluster، المحدد في config.xml، الشظايا (ونسخها المتماثلة) — مما يتيح للمستخدمين التحكم في الترتيب الذي تُستخدم به من كل عقدة. وباستخدام ذلك، يمكنك ضمان أن يكون الاختيار حتميًا.

​

الاتساق التسلسلي

في حالات استثنائية، قد تحتاج إلى الاتساق التسلسلي.

يعني الاتساق التسلسلي في قواعد البيانات أن العمليات على قاعدة البيانات تبدو كما لو أنها تُنفَّذ وفق ترتيب تسلسلي معيّن، وأن هذا الترتيب يظل متسقًا عبر جميع العمليات التي تتفاعل مع قاعدة البيانات. وهذا يعني أن كل عملية تبدو وكأن مفعولها يسري فورًا بين لحظة استدعائها واكتمالها، وأن هناك ترتيبًا واحدًا متفقًا عليه تُرصَد ضمنه جميع العمليات من قِبل أي عملية.

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

1. القراءة/الكتابة إلى العقدة نفسها - إذا كنت تستخدم البروتوكول الأصلي، أو جلسة لإجراء الكتابة/القراءة عبر HTTP، فينبغي حينها أن تكون متصلًا بالنسخة المتماثلة نفسها: في هذا السيناريو، أنت تقرأ مباشرةً من العقدة التي تكتب إليها، وبالتالي ستكون قراءتك متسقة دائمًا.
2. مزامنة النسخ المتماثلة يدويًا - إذا كنت تكتب إلى نسخة متماثلة وتقرأ من أخرى، فيمكنك استخدام الأمر SYSTEM SYNC REPLICA LIGHTWEIGHT قبل القراءة.
3. تفعيل الاتساق التسلسلي - عبر إعداد الاستعلام select_sequential_consistency = 1. في OSS، يجب أيضًا تحديد الإعداد insert_quorum = 'auto'.

راجع هنا لمزيد من التفاصيل حول تفعيل هذه الإعدادات.

يؤدي استخدام الاتساق التسلسلي إلى زيادة الحمل على ClickHouse Keeper. وقد تكون النتيجة تباطؤًا في عمليات الإدراج والقراءة. أما SharedMergeTree، المستخدم في ClickHouse Cloud بوصفه محرك الجدول الرئيسي، فإن الاتساق التسلسلي فيه يفرض حملًا إضافيًا أقل ويتوسع بصورة أفضل. وفي OSS، ينبغي استخدام هذا النهج بحذر وقياس الحمل على Keeper.

​

دعم المعاملات (ACID)

قد يكون المستخدمون الذين ينتقلون من PostgreSQL معتادين على دعمه القوي لخصائص ACID ‏(الذرية، والاتساق، والعزل، والديمومة)، ما يجعله خيارًا موثوقًا لقواعد بيانات المعاملات. تضمن الذرية في PostgreSQL التعامل مع كل معاملة كوحدة واحدة، بحيث تنجح بالكامل أو يُتراجع عنها بالكامل، مما يمنع التحديثات الجزئية. ويُحفَظ الاتساق من خلال فرض القيود والمشغلات والقواعد التي تضمن أن جميع معاملات قاعدة البيانات تؤدي إلى حالة صحيحة. كما يدعم PostgreSQL مستويات العزل، من Read Committed إلى Serializable، مما يتيح تحكمًا دقيقًا في مدى ظهور التغييرات التي تُجريها المعاملات المتزامنة. وأخيرًا، تتحقق الديمومة من خلال التسجيل المسبق للكتابة (WAL)، بما يضمن أن المعاملة، بمجرد اعتمادها، تظل كذلك حتى في حال حدوث فشل في النظام.

تُعد هذه الخصائص شائعة في قواعد بيانات OLTP التي تمثل المصدر الموثوق للبيانات.

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

يوفّر ClickHouse خصائص ACID ضمن تهيئات محدودة — وأبسطها عند استخدام مثيل غير مكرّر من محرك الجداول MergeTree مع partition واحدة. ولا ينبغي أن تتوقع توفّر هذه الخصائص خارج هذه الحالات، لذا تأكد من أنها ليست من متطلباتك.

​

الضغط

يعني التخزين الموجّه بالأعمدة في ClickHouse أن الضغط يكون غالبًا أفضل بدرجة كبيرة مقارنةً بـ Postgres. ويوضح ما يلي ذلك عند مقارنة متطلبات التخزين لجميع جداول Stack Overflow في كلتا قاعدتي البيانات:

Query (Postgres)

SELECT
    schemaname,
    tablename,
    pg_total_relation_size(schemaname || '.' || tablename) AS total_size_bytes,
    pg_total_relation_size(schemaname || '.' || tablename) / (1024 * 1024 * 1024) AS total_size_gb
FROM
    pg_tables s
WHERE
    schemaname = 'public';

Query (ClickHouse)

SELECT
        `table`,
        formatReadableSize(sum(data_compressed_bytes)) AS compressed_size
FROM system.parts
WHERE (database = 'stackoverflow') AND active
GROUP BY `table`

Response

┌─table───────┬─compressed_size─┐
│ posts       │ 25.17 GiB       │
│ users       │ 846.57 MiB      │
│ badges      │ 513.13 MiB      │
│ comments    │ 7.11 GiB        │
│ votes       │ 1.28 GiB        │
│ posthistory │ 40.44 GiB       │
│ postlinks   │ 79.22 MiB       │
└─────────────┴─────────────────┘

يمكنك الاطّلاع على مزيد من التفاصيل حول تحسين الضغط وقياسه هنا.

​

تعيينات أنواع البيانات

يوضح الجدول التالي أنواع البيانات المكافئة في ClickHouse لأنواع بيانات Postgres.

نوع بيانات Postgres	نوع ClickHouse
DATE	Date
TIMESTAMP	DateTime
REAL	Float32
DOUBLE	Float64
DECIMAL, NUMERIC	Decimal
SMALLINT	Int16
INTEGER	Int32
BIGINT	Int64
SERIAL	UInt32
BIGSERIAL	UInt64
TEXT, CHAR, BPCHAR	String
INTEGER	Nullable(Int32)
ARRAY	Array
FLOAT4	Float32
BOOLEAN	Bool
VARCHAR	String
BIT	String
BIT VARYING	String
BYTEA	String
NUMERIC	Decimal
GEOGRAPHY	Point, Ring, Polygon, MultiPolygon
GEOMETRY	Point, Ring, Polygon, MultiPolygon
INET	IPv4, IPv6
MACADDR	String
CIDR	String
HSTORE	Map(K, V), Map(K,Variant)
UUID	UUID
ARRAY<T>	ARRAY(T)
JSON	String, Variant, Nested, Tuple
JSONB	String