الانتقال إلى المحتوى الرئيسي
تُخزَّن البيانات التي تُعالَج في ClickHouse عادةً في نظام الملفات المحلي للجهاز الذي يعمل عليه خادم ClickHouse. ويتطلب ذلك أقراصًا كبيرة السعة، وقد تكون مكلفة. ولتجنّب تخزين البيانات محليًا، تتوفر خيارات تخزين متعددة:
  1. تخزين الكائنات Amazon S3.
  2. Azure Blob Storage.
  3. غير مدعوم: نظام ملفات Hadoop الموزّع (HDFS)

يدعم ClickHouse أيضًا محركات الجداول الخارجية، وهي تختلف عن خيار التخزين الخارجي الموصوف في هذه الصفحة، لأنها تتيح قراءة البيانات المخزّنة بتنسيقات ملفات عامة (مثل Parquet). في هذه الصفحة، نصف إعدادات التخزين لعائلة جداول MergeTree أو لعائلة جداول Log.
  1. للعمل مع البيانات المخزّنة على أقراص Amazon S3، استخدم محرك الجداول S3.
  2. للعمل مع البيانات المخزّنة في Azure Blob Storage، استخدم محرك الجداول AzureBlobStorage.
  3. للعمل مع البيانات الموجودة في نظام ملفات Hadoop الموزّع (غير مدعوم)، استخدم محرك الجداول HDFS.

تهيئة التخزين الخارجي

يمكن لمحركات الجداول من عائلتي MergeTree وLog تخزين البيانات في S3 وAzureBlobStorage وHDFS (غير مدعوم) باستخدام قرص من الأنواع s3، وazure_blob_storage وhdfs (غير مدعوم) على التوالي. يتطلب إعداد القرص ما يلي:
  1. قسم type، وتكون قيمته إحدى القيم s3 أو azure_blob_storage أو hdfs (غير مدعوم) أو local_blob_storage أو web.
  2. تهيئة نوع محدد من التخزين الخارجي.
بدءًا من إصدار ClickHouse 24.1، أصبح من الممكن استخدام خيار تهيئة جديد. ويتطلب ذلك تحديد:
  1. قيمة type مساوية لـ object_storage
  2. object_storage_type، وتكون قيمته إحدى القيم s3 أو azure_blob_storage (أو فقط azure بدءًا من 24.3) أو hdfs (غير مدعوم) أو local_blob_storage (أو فقط local بدءًا من 24.3) أو web.

يمكن اختياريًا تحديد metadata_type (وتكون قيمته local افتراضيًا)، كما يمكن أيضًا ضبطه على plain وweb وبدءًا من 24.4 على plain_rewritable. يُشرح استخدام نوع البيانات الوصفية plain في قسم التخزين البسيط، ولا يمكن استخدام نوع البيانات الوصفية web إلا مع نوع تخزين الكائنات web، بينما يخزن نوع البيانات الوصفية local ملفات البيانات الوصفية محليًا (يحتوي كل ملف بيانات وصفية على ربط بالملفات في تخزين الكائنات، إلى جانب بعض المعلومات الوصفية الإضافية عنها). على سبيل المثال:
يعادل التكوين التالي (بدءًا من الإصدار 24.1):
التهيئة التالية:
يساوي:
سيكون مثال على إعداد التخزين الكامل كما يلي:
اعتبارًا من الإصدار 24.1، يمكن أن يكون أيضًا على النحو التالي:
لجعل نوع محدد من التخزين الخيار الافتراضي لجميع جداول MergeTree، أضِف القسم التالي إلى ملف التهيئة:
إذا كنت تريد تعيين سياسة تخزين محددة لجدول معيّن، فيمكنك تحديدها في الإعدادات عند إنشاء الجدول:
يمكنك أيضًا استخدام disk بدلًا من storage_policy. في هذه الحالة، لا حاجة إلى وجود قسم storage_policy في ملف الإعدادات، ويكفي وجود قسم disk.

refresh_parts_interval and table_disk

هذا الإعداد مخصّص لجداول MergeTree غير المكررة، حيث قد تُكتب الأجزاء خارجيًا ويستلزم الأمر تحديث اكتشاف البيانات الوصفية من التخزين. يتيح إعداد MergeTree refresh_parts_interval تحديثًا دوريًا لقائمة أجزاء البيانات من التخزين الأساسي (على سبيل المثال، لاكتشاف الأجزاء المكتوبة خارجيًا). والتمييز المهم هنا هو بين البيانات الوصفية المشتركة بين النسخ المتماثلة والبيانات الوصفية المحلية لكل نسخة متماثلة (مثل S3 مع بيانات وصفية محلية لكل نسخة): فقط عندما تكون البيانات الوصفية مشتركة تصبح الأجزاء الجديدة مرئية لجميع النسخ المتماثلة. ولا يعني استخدام تخزين الكائنات وحده بالضرورة وجود بيانات وصفية مشتركة.
  • تخزين الكائنات (مثل disk = 's3') لا يعني بالضرورة وجود بيانات وصفية مشتركة. عندما تُخزَّن البيانات الوصفية محليًا لكل نسخة متماثلة (وهو الوضع الافتراضي)، تدير كل نسخة بشكل مستقل مؤشراتِها إلى الكائنات في تخزين الكائنات. ولا تكون التغييرات التي تُجرى على إحدى النسخ مرئية للنسخ الأخرى. وفي هذه الحالة، لا يجعل refresh_parts_interval الأجزاء الجديدة مرئية عبر النسخ المتماثلة، لأن البيانات الوصفية التي تقرؤها كل نسخة محلية لتلك النسخة.
  • يتطلب التحديث التلقائي للأجزاء أن تكون البيانات الوصفية لنظام الملفات مشتركة (أو أن يستخدم الجدول بيانات وصفية يملكها الجدول ومضبوطة للقراءة فقط بحيث يكون التحديث قابلًا للتطبيق). ويُعد ضبط table_disk = true مع قرص محلي على مستوى الجدول (مثل SETTINGS disk = disk(type=object_storage, ...), table_disk = true) إحدى طرق الحصول على السلوك الصحيح: إذ يتحكم الجدول في دورة حياة البيانات الوصفية، ويُتعامل مع التخزين على أنه للقراءة فقط، لذا يعمل refresh_parts_interval ويمكن اكتشاف الأجزاء المضافة خارجيًا.
  • عند استخدام قرص معرّف على مستوى عام (مثل disk = 's3' في storage_configuration) مع البيانات الوصفية المحلية الافتراضية، تكون لكل نسخة متماثلة حالتها الخاصة من البيانات الوصفية. وحتى إذا كانت الكائنات موجودة في S3، فلا يُعدّ التخزين مشتركًا لأغراض refresh_parts_interval، ولن تُكتشف الأجزاء الجديدة التي أُنشئت خارج ClickHouse أو على نسخة متماثلة أخرى.
لتمكين التحديث التلقائي للأجزاء، تأكد من أن البيانات الوصفية مشتركة، أو استخدم قرصًا على مستوى الجدول مع table_disk = true كما هو موضح أعلاه. أما الاعتماد على refresh_parts_interval وحده مع بيانات وصفية محلية لكل نسخة متماثلة، فلن يؤدي إلى تحديث الأجزاء كما هو متوقع.
لا يُستخدم refresh_parts_interval مع جداول ReplicatedMergeTree. فالجداول المكررة تزامن الأجزاء بالفعل عبر آلية النسخ المتماثل. ولا ينطبق هذا الإعداد إلا على جداول MergeTree غير المكررة التي تُكتب أجزاؤها خارجيًا ويكون فيها تحديث البيانات الوصفية مطلوبًا.

التهيئة الديناميكية

يمكن أيضًا تحديد تهيئة التخزين من دون قرص مُعرَّف مسبقًا في ملف التهيئة، على أن تُضبط ضمن إعدادات استعلام CREATE/ATTACH. يعتمد استعلام المثال التالي على تهيئة القرص الديناميكية المذكورة أعلاه، ويوضح كيفية استخدام قرص محلي لتخزين بيانات جدول مخزَّن على URL مؤقتًا.
يضيف المثال أدناه ذاكرةً مؤقتةً إلى التخزين الخارجي.
في الإعدادات المميزة أدناه، لاحظ أن القرص ذي type=web متداخل داخل القرص ذي type=cache.
يستخدم المثال type=web، لكن يمكن تهيئة أي نوع قرص ليكون ديناميكيًا، بما في ذلك القرص المحلي. تتطلب الأقراص المحلية أن تكون وسيطة path ضمن معامل config الخاص بالخادم custom_local_disks_base_directory، والذي لا يملك قيمة افتراضية، لذا اضبطه أيضًا عند استخدام القرص المحلي.
كما يمكن أيضًا الجمع بين إعدادات تستند إلى config وإعدادات مُعرّفة باستخدام SQL:
حيث إن web وارد في ملف تهيئة الخادم:

استخدام S3 للتخزين

المعلمات المطلوبة

المعلمات الاختيارية

يُدعَم أيضًا Google Cloud Storage ‏(GCS) باستخدام النوع s3. راجع GCS backed MergeTree.

استخدام التخزين البسيط

في 22.10 أُضيف نوع قرص جديد s3_plain يوفّر تخزينًا للكتابة مرة واحدة. ومَعلَمات التهيئة الخاصة به هي نفسها الخاصة بنوع القرص s3. وعلى خلاف نوع القرص s3، فإنه يخزّن البيانات كما هي. وبعبارة أخرى، فبدلًا من استخدام أسماء blob مُولَّدة عشوائيًا، يستخدم أسماء ملفات عادية (بالطريقة نفسها التي يخزّن بها ClickHouse الملفات على القرص المحلي)، ولا يخزّن أي بيانات وصفية محليًا. فعلى سبيل المثال، تُستخلص البيانات الوصفية من البيانات الموجودة على s3. يتيح نوع القرص هذا الاحتفاظ بإصدار ثابت من الجدول، لأنه لا يسمح بتنفيذ عمليات الدمج على البيانات الموجودة، كما لا يسمح بإدراج بيانات جديدة. ومن حالات الاستخدام لهذا النوع من الأقراص إنشاء نسخ احتياطية عليه، ويمكن تنفيذ ذلك عبر BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name'). بعد ذلك، يمكنك تنفيذ RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name') أو استخدام ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'. التهيئة:
اعتبارًا من الإصدار 24.1، أصبح من الممكن تهيئة أي قرص تخزين كائني (s3, azure, hdfs (غير مدعوم), local) باستخدام نوع البيانات الوصفية plain. التهيئة:

استخدام تخزين S3 Plain Rewritable

تم تقديم نوع القرص s3_plain_rewritable في 24.4. وكما هو الحال مع نوع القرص s3_plain، فإنه لا يتطلب مساحة تخزين إضافية لملفات البيانات الوصفية. وبدلًا من ذلك، تُخزَّن البيانات الوصفية في S3. وعلى عكس نوع القرص s3_plain، يتيح s3_plain_rewritable تنفيذ عمليات الدمج ويدعم عمليات INSERT. عمليات التعديل ونسخ الجداول متماثلًا غير مدعومين. من حالات الاستخدام المناسبة لهذا النوع من الأقراص جداول MergeTree غير المُكرَّرة. ومع أن نوع القرص s3 مناسب لجداول MergeTree غير المُكرَّرة، فقد تختار نوع القرص s3_plain_rewritable إذا كنت لا تحتاج إلى بيانات وصفية محلية للجدول، وكنت مستعدًا لقبول مجموعة محدودة من العمليات. وقد يكون هذا مفيدًا، على سبيل المثال، لجداول النظام. التهيئة:
يساوي
اعتبارًا من 24.5، أصبح بالإمكان إعداد أي قرص تخزين كائني (s3, azure, local) باستخدام نوع البيانات الوصفية plain_rewritable.

استخدام Azure Blob Storage

يمكن لمحركات الجداول من عائلة MergeTree تخزين البيانات في Azure Blob Storage باستخدام قرص من النوع azure_blob_storage. بنية التهيئة:

معلمات الاتصال

معلمات المصادقة (سيحاول القرص جميع الطرق المتاحة بالإضافة إلى Managed Identity Credential):

معلمات الحد

معلمات أخرى

يمكن العثور على أمثلة لإعدادات صالحة في دليل اختبارات التكامل (انظر مثلًا test_merge_tree_azure_blob_storage أو test_azure_blob_storage_zero_copy_replication).
النسخ المتماثل من دون نسخ ليس جاهزًا لبيئات الإنتاجيكون النسخ المتماثل من دون نسخ معطّلًا افتراضيًا في ClickHouse الإصدار 22.8 وما بعده. لا يُنصح باستخدام هذه الميزة في بيئات الإنتاج.

استخدام مساحة تخزين HDFS (غير مدعوم)

في هذا الإعداد النموذجي:
  • القرص من النوع hdfs (غير مدعوم)
  • توجد البيانات في hdfs://hdfs1:9000/clickhouse/
للعلم، HDFS غير مدعوم، لذلك قد تواجه بعض المشكلات عند استخدامه. إذا ظهرت أي مشكلة، فلا تتردد في تقديم طلب سحب يتضمن الإصلاح.
ضع في اعتبارك أن HDFS قد لا يعمل في بعض الحالات النادرة.

استخدام تشفير البيانات

يمكنك تشفير البيانات المخزنة على الأقراص الخارجية S3، أو HDFS (غير مدعوم)، أو على قرص محلي. لتفعيل وضع التشفير، يجب عليك في ملف الإعدادات تعريف قرص من النوع encrypted واختيار القرص الذي ستُحفَظ عليه البيانات. يقوم قرص encrypted بتشفير جميع الملفات المكتوبة لحظيًا، وعند قراءة الملفات من قرص encrypted يفك تشفيرها تلقائيًا. لذلك يمكنك التعامل مع قرص encrypted كما لو كان قرصًا عاديًا. مثال على إعدادات القرص:
على سبيل المثال، عندما يكتب ClickHouse البيانات من أحد الجداول إلى الملف store/all_1_1_0/data.bin على disk1، فإن هذا الملف سيُكتَب فعليًا على القرص الفعلي في المسار /path1/store/all_1_1_0/data.bin. وعند كتابة الملف نفسه على disk2، فسيُكتَب فعليًا على القرص الفعلي في المسار /path1/path2/store/all_1_1_0/data.bin بصيغة مشفّرة.

المعلمات المطلوبة

المعلمات الاختيارية

مثال على تهيئة القرص:

استخدام ذاكرة التخزين المؤقت المحلية

يمكن تهيئة ذاكرة تخزين مؤقت محلية فوق الأقراص في إعدادات التخزين بدءًا من الإصدار 22.3. بالنسبة إلى الإصدارات من 22.3 إلى 22.7، لا تكون ذاكرة التخزين المؤقت مدعومة إلا لنوع القرص s3. وبالنسبة إلى الإصدارات >= 22.8، تكون ذاكرة التخزين المؤقت مدعومة لأي نوع من الأقراص: S3 وAzure وLocal وEncrypted وغيرها. بالنسبة إلى الإصدارات >= 23.5، لا تكون ذاكرة التخزين المؤقت مدعومة إلا لأنواع الأقراص البعيدة: S3 وAzure وHDFS (غير مدعوم). تستخدم ذاكرة التخزين المؤقت سياسة LRU. مثال على الإعداد للإصدارات الأحدث من 22.8 أو المساوية له:
مثال على إعدادات الإصدارات الأقدم من 22.8:
إعدادات تهيئة القرص لـ File Cache: يجب تعريف هذه الإعدادات في قسم تهيئة القرص.
ملاحظة: تدعم قيم الحجم وحدات مثل ki وMi وGi وغيرها (مثل 10Gi).

إعدادات الاستعلام/الملف التعريفي لـ File Cache

تتوافق إعدادات تهيئة cache وإعدادات استعلام cache مع أحدث إصدار من ClickHouse، وقد لا تكون بعض هذه الميزات مدعومة في الإصدارات الأقدم.

جداول النظام لذاكرة التخزين المؤقت لنظام الملفات

أوامر ذاكرة التخزين المؤقت

SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER)ON CLUSTER
هذا الأمر مدعوم فقط عند عدم تحديد <cache_name>
SHOW FILESYSTEM CACHES
اعرض قائمة بذاكرات التخزين المؤقت لنظام الملفات التي تم إعدادها على الخادم. (في الإصدارات الأقدم من 22.8 أو المساوية له، يكون اسم الأمر SHOW CACHES)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
اعرض إعدادات ذاكرة التخزين المؤقت لنظام الملفات وبعض الإحصاءات العامة لذاكرة تخزين مؤقت محددة. يمكن أخذ اسم ذاكرة التخزين المؤقت من الأمر SHOW FILESYSTEM CACHES. (بالنسبة إلى الإصدارات الأقدم أو المساوية لـ 22.8، يُسمّى الأمر DESCRIBE CACHE)
Query
Response

استخدام تخزين Web الثابت (للقراءة فقط)

هذا قرص للقراءة فقط. تُقرأ بياناته فقط ولا تُعدَّل مطلقًا. يُحمَّل جدول جديد إلى هذا القرص عبر استعلام ATTACH TABLE (انظر المثال أدناه). ولا يُستخدم القرص المحلي فعليًا، إذ يؤدي كل استعلام SELECT إلى طلب http لجلب البيانات المطلوبة. وسيؤدي أي تعديل في بيانات الجدول إلى استثناء، أي إن الأنواع التالية من الاستعلامات غير مسموح بها: CREATE TABLE, ALTER TABLE, RENAME TABLE, DETACH TABLE وTRUNCATE TABLE. يمكن استخدام تخزين Web لأغراض القراءة فقط. ومن أمثلة استخدامه استضافة بيانات نموذجية أو ترحيل البيانات. توجد أداة باسم clickhouse-static-files-uploader، تُعِدّ دليل بيانات لجدول معيّن (SELECT data_paths FROM system.tables WHERE name = 'table_name'). ولكل جدول تحتاج إليه، ستحصل على دليل من الملفات. ويمكن رفع هذه الملفات إلى، على سبيل المثال، خادم ويب يقدّم ملفات ثابتة. بعد هذا الإعداد، يمكنك تحميل هذا الجدول إلى أي خادم ClickHouse باستخدام DiskWeb. في هذا الإعداد النموذجي:
  • القرص من النوع web
  • تُستضاف البيانات على http://nginx:80/test1/
  • يُستخدم cache على التخزين المحلي
يمكن أيضًا تهيئة التخزين مؤقتًا داخل استعلام، إذا لم يكن من المتوقّع استخدام مجموعة بيانات الويب بشكل معتاد، فراجع التهيئة الديناميكية وتجاوز تحرير ملف التكوين.تتم استضافة مجموعة بيانات تجريبية على GitHub. ولإعداد جداولك الخاصة لتخزين الويب، راجع الأداة clickhouse-static-files-uploader
في استعلام ATTACH TABLE هذا، يطابق UUID المقدَّم اسم دليل البيانات، وتكون نقطة النهاية هي URL الخاص بمحتوى GitHub الخام.
مثال اختبار جاهز. تحتاج إلى إضافة هذا الإعداد إلى config:
ثم نفّذ الاستعلام التالي:

المعلمات المطلوبة

المعلمات الاختيارية

إذا فشل استعلام مع الاستثناء DB:Exception Unreachable URL، فيمكنك محاولة ضبط الإعدادات التالية: http_connection_timeout، وhttp_receive_timeout، وkeep_alive_timeout. للحصول على الملفات المراد رفعها، شغّل: clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir> (يمكن العثور على --metadata-path في الاستعلام SELECT data_paths FROM system.tables WHERE name = 'table_name'). عند تحميل الملفات عبر endpoint، يجب تحميلها إلى المسار <endpoint>/store/، لكن يجب أن يحتوي config على endpoint فقط. إذا تعذر الوصول إلى URL عند تحميل القرص أثناء بدء الخادم للجداول، فستُلتقط جميع الأخطاء. وإذا حدثت أخطاء في هذه الحالة، فيمكن إعادة تحميل الجداول (لتصبح مرئية) عبر DETACH TABLE table_name -> ATTACH TABLE table_name. وإذا جرى تحميل البيانات الوصفية بنجاح عند بدء تشغيل الخادم، فستكون الجداول متاحة مباشرةً. استخدم الإعداد http_max_single_read_retries لتقييد الحد الأقصى لعدد retries أثناء عملية قراءة HTTP واحدة.

النسخ المتماثل دون نسخ (غير جاهز لبيئة الإنتاج)

يمكن استخدام النسخ المتماثل دون نسخ، لكنه غير موصى به، مع الأقراص S3 وHDFS (غير مدعومة). ويعني النسخ المتماثل دون نسخ أنه إذا كانت البيانات مخزنة عن بُعد على عدة أجهزة وتحتاج إلى المزامنة، فلا تُنسخ متماثلًا إلا البيانات الوصفية (مسارات أجزاء البيانات)، وليس البيانات نفسها.
النسخ المتماثل دون نسخ غير جاهز لبيئة الإنتاجيُعطَّل النسخ المتماثل دون نسخ افتراضيًا في ClickHouse الإصدار 22.8 والإصدارات الأحدث. هذه الميزة غير موصى بها للاستخدام في بيئة الإنتاج.
آخر تعديل في ١ يوليو ٢٠٢٦