محرك الجدول SharedMergeTree

وصف لمحرك الجدول SharedMergeTree

تُعد عائلة محرك الجداول SharedMergeTree بديلاً سحابيًا أصليًا لمحركات ReplicatedMergeTree، وقد صُممت للعمل فوق التخزين المشترك (مثل Amazon S3 وGoogle Cloud Storage وMinIO وAzure Blob Storage). ويوجد نظير من SharedMergeTree لكل نوع محدد من محركات MergeTree، أي إن SharedReplacingMergeTree يحل محل ReplicatedReplacingMergeTree.

تعتمد ClickHouse Cloud على عائلة محرك الجداول SharedMergeTree. وبالنسبة إلى المستخدم النهائي، لا حاجة إلى تغيير أي شيء للبدء في استخدام عائلة محركات SharedMergeTree بدلًا من المحركات المستندة إلى ReplicatedMergeTree. وهي توفّر المزايا الإضافية التالية:

• معدل insert أعلى
• تحسين معدل نقل عمليات الدمج في الخلفية
• تحسين معدل نقل عمليات mutation
• عمليات scale-up وscale-down أسرع
• اتساق قوي أخف وزنًا لاستعلامات select

ومن أبرز التحسينات التي يقدّمها SharedMergeTree أنه يوفّر فصلًا أعمق بين compute وStorage مقارنةً بـ ReplicatedMergeTree. ويمكنك أن ترى أدناه كيف يفصل ReplicatedMergeTree بين compute وStorage:

كما ترى، رغم أن البيانات المخزنة في ReplicatedMergeTree موجودة في object storage، فإن البيانات الوصفية لا تزال موجودة على كل خادم من خوادم clickhouse-server. وهذا يعني أنه في كل عملية replicated، يجب أيضًا نسخ البيانات الوصفية إلى جميع replicas.

وعلى عكس ReplicatedMergeTree، لا يتطلب SharedMergeTree أن تتواصل replicas مع بعضها البعض. وبدلًا من ذلك، تتم جميع الاتصالات عبر التخزين المشترك وclickhouse-keeper. ويعتمد SharedMergeTree على replication غير متزامن ومن دون leader، ويستخدم clickhouse-keeper لأغراض coordination وmetadata storage. وهذا يعني أن البيانات الوصفية لا تحتاج إلى replication مع توسع خدمتك أو تقليصها. ويؤدي ذلك إلى تسريع replication وmutation وmerges وعمليات scale-up. كما يتيح SharedMergeTree وجود مئات replicas لكل table، مما يجعل التوسع الديناميكي ممكنًا من دون shards. ويُستخدم نهج distributed query execution في ClickHouse Cloud للاستفادة من مزيد من موارد compute للاستعلام.

​

الاستبطان

تتوفّر في SharedMergeTree معظم جداول النظام المستخدمة لاستبطان ReplicatedMergeTree، باستثناء system.replication_queue وsystem.replicated_fetches، إذ لا يحدث فيها أي replication للبيانات أو البيانات الوصفية. ومع ذلك، يوفّر SharedMergeTree بدائل مقابلة لهذين الجدولين.

system.virtual_parts

يُعد هذا الجدول البديل عن system.replication_queue في SharedMergeTree. وهو يخزّن معلومات عن أحدث مجموعة من الأجزاء الحالية، بالإضافة إلى الأجزاء المستقبلية قيد المعالجة، مثل عمليات الدمج وعمليات mutations والأقسام المحذوفة.

system.shared_merge_tree_fetches

يُعد هذا الجدول البديل عن system.replicated_fetches في SharedMergeTree. ويحتوي على معلومات عن عمليات الجلب الجارية حاليًا للمفاتيح الأساسية وقيم التحقّق إلى الذاكرة.

​

تمكين SharedMergeTree

يكون SharedMergeTree مفعّلًا افتراضيًا.

بالنسبة إلى الخدمات التي تدعم محرك الجداول SharedMergeTree، لا تحتاج إلى تفعيل أي شيء يدويًا. يمكنك إنشاء الجداول بالطريقة نفسها كما في السابق، وسيُستخدم تلقائيًا محرك جداول يستند إلى SharedMergeTree ويتوافق مع المحرك المحدد في استعلام CREATE TABLE الخاص بك.

CREATE TABLE my_table(
 key UInt64,
 value String
)
ENGINE = MergeTree
ORDER BY key

سيؤدي هذا إلى إنشاء الجدول my_table باستخدام محرك الجدول SharedMergeTree.

لا تحتاج إلى تحديد ENGINE=MergeTree لأن default_table_engine=MergeTree هو الإعداد الافتراضي في ClickHouse Cloud. الاستعلام التالي مطابق للاستعلام أعلاه.

CREATE TABLE my_table(
 key UInt64,
 value String
)
ORDER BY key

إذا كنت تستخدم Replacing أو Collapsing أو Aggregating أو Summing أو VersionedCollapsing أو جداول Graphite MergeTree، فستُحوَّل تلقائيًا إلى محرك الجدول المقابل المستند إلى SharedMergeTree.

CREATE TABLE myFirstReplacingMT
(
    `key` Int64,
    `someCol` String,
    `eventTime` DateTime
)
ENGINE = ReplacingMergeTree
ORDER BY key;

لجدول معيّن، يمكنك التحقق من محرك الجدول المستخدم في عبارة CREATE TABLE باستخدام SHOW CREATE TABLE:

SHOW CREATE TABLE myFirstReplacingMT;

CREATE TABLE default.myFirstReplacingMT
( `key` Int64, `someCol` String, `eventTime` DateTime )
ENGINE = SharedReplacingMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}')
ORDER BY key

​

الإعدادات

تغيّر سلوك بعض الإعدادات بشكل ملحوظ:

• insert_quorum — جميع عمليات insert إلى SharedMergeTree هي quorum inserts (تُكتب إلى التخزين المشترك)، لذا لا حاجة إلى هذا الإعداد عند استخدام محرك الجدول SharedMergeTree.
• insert_quorum_parallel — جميع عمليات insert إلى SharedMergeTree هي quorum inserts (تُكتب إلى التخزين المشترك)، لذا لا حاجة إلى هذا الإعداد عند استخدام محرك الجدول SharedMergeTree.
• select_sequential_consistency — لا يتطلب quorum inserts، لكنه يفرض حملاً إضافيًا على clickhouse-keeper عند تنفيذ استعلامات SELECT

​

الاتساق

يوفّر SharedMergeTree اتساقًا lightweight أفضل من ReplicatedMergeTree. عند إجراء insert في SharedMergeTree، لا تحتاج إلى تحديد إعدادات مثل insert_quorum أو insert_quorum_parallel. تكون عمليات الإدراج من نوع quorum inserts، ما يعني أن البيانات الوصفية ستُخزَّن في ClickHouse-Keeper، وستُكرَّر إلى ما لا يقل عن النصاب من مثيلات ClickHouse-Keeper. وسيجلب كل replica في الـ cluster لديك المعلومات الجديدة بشكل غير متزامن من ClickHouse-Keeper.

في معظم الحالات، لا ينبغي أن تحتاج إلى استخدام select_sequential_consistency أو SYSTEM SYNC REPLICA LIGHTWEIGHT. إذ إن replication غير المتزامنة تغطي معظم السيناريوهات وتتميّز بزمن latency منخفض جدًا. وفي الحالات النادرة التي تحتاج فيها فعلًا إلى منع reads المتقادمة، اتبع هذه التوصيات بالترتيب التالي حسب الأفضلية:

1. إذا كنت تنفّذ queries ضمن session نفسها أو على العقدة نفسها لعمليات reads وعمليات الكتابة، فلا حاجة إلى استخدام select_sequential_consistency لأن الـ replica لديك ستكون لديها بالفعل أحدث البيانات الوصفية.

2. إذا كنت تكتب إلى replica وتقرأ من أخرى، فيمكنك استخدام SYSTEM SYNC REPLICA LIGHTWEIGHT لإجبار الـ replica على جلب البيانات الوصفية من ClickHouse-Keeper.

3. استخدم select_sequential_consistency كإعداد ضمن query الخاصة بك.

​

ALTER ومدى ظهور عمليات التعديل

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

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

في ClickHouse Cloud، تكون القيمة الافتراضية للإعداد alter_sync هي 0؛ لذا اضبطه عندما يحتاج العميل إلى انتظار اكتمال عمليات البيانات الوصفية، أو عمليات إعادة الكتابة الناتجة عن MODIFY COLUMN التي لا تقتصر على البيانات الوصفية. أما عمليات UPDATE وDELETE وMATERIALIZE ...، فاستخدم معها mutations_sync للتحكم في الانتظار، وتابع تقدّمها في system.mutations.