الانتقال إلى المحتوى الرئيسي

المتطلبات الأساسية

ستحتاج إلى ما يلي للأمثلة الواردة في هذه المقالة:
  • أن يكون لديك مثيل عامل من ClickHouse server
  • أن يكون curl مثبّتًا لديك. على Ubuntu أو Debian، شغّل sudo apt install curl أو راجع هذه الوثائق للحصول على إرشادات التثبيت.

نظرة عامة

تتيح لك واجهة HTTP استخدام ClickHouse على أي منصة ومن أي لغة برمجة عبر واجهة برمجة تطبيقات REST. وتُعد واجهة HTTP أكثر محدودية من الواجهة الأصلية، لكنها توفر دعماً أفضل للغات البرمجة. بشكل افتراضي، يستمع clickhouse-server على المنافذ التالية:
  • المنفذ 8123 لـ HTTP
  • يمكن تمكين المنفذ 8443 لـ HTTPS
إذا أجريت طلب GET / من دون أي معلمات، فسيُعاد رمز الاستجابة 200 مع السلسلة “Ok.”:
“حسنًا.” هي القيمة الافتراضية المعرَّفة في http_server_default_response، ويمكن تغييرها عند الحاجة. راجع أيضًا: محاذير رموز استجابة HTTP.

واجهة مستخدم الويب

يتضمن ClickHouse واجهة مستخدم عبر الويب، ويمكن الوصول إليها من العنوان التالي:
تدعم واجهة الويب عرض التقدّم أثناء تنفيذ الاستعلام، وإلغاء الاستعلام، وبث النتائج. كما تتضمن ميزة غير معلنة لعرض المخططات والرسوم البيانية لخطوط تنفيذ الاستعلام. بعد تنفيذ استعلام بنجاح، يظهر زر تنزيل يتيح لك تنزيل نتائج الاستعلام بتنسيقات مختلفة، بما في ذلك CSV وTSV وJSON وJSONLines وParquet وMarkdown أو أي تنسيق مخصص يدعمه ClickHouse. تستخدم ميزة التنزيل ذاكرة تخزين مؤقت للاستعلامات لاسترداد النتائج بكفاءة من دون إعادة تنفيذ الاستعلام. وستنزّل مجموعة النتائج الكاملة حتى إذا كانت واجهة الويب قد عرضت صفحة واحدة فقط من بين صفحات عديدة. صُممت واجهة الويب للمحترفين مثلك. في النصوص البرمجية الخاصة بفحوصات الحالة، استخدم الطلب GET /ping. يعيد هذا المعالج دائمًا “Ok.” (مع محرف تغذية سطرية في النهاية). وهو متاح بدءًا من الإصدار 18.12.13. انظر أيضًا إلى /replicas_status للتحقق من تأخر النسخة المتماثلة.

الاستعلام عبر HTTP/HTTPS

للاستعلام عبر HTTP/HTTPS، توجد ثلاثة خيارات:
  • إرسال الطلب كمعلمة URL باسم ‘query’
  • استخدام طريقة POST.
  • إرسال بداية الاستعلام في المعلمة ‘query’، ثم إرسال الباقي باستخدام POST
يكون حجم URL محدودًا افتراضيًا إلى 1 MiB، ويمكن تغيير ذلك باستخدام الإعداد http_max_uri_size.
إذا نجح الطلب، فستتلقى رمز الاستجابة 200 والنتيجة في جسم الاستجابة. وإذا حدث خطأ، فستتلقى رمز الاستجابة 500 ونصًا يصف الخطأ في جسم الاستجابة. تكون الطلبات التي تستخدم GET من النوع ‘readonly’. وهذا يعني أنه بالنسبة إلى الاستعلامات التي تعدّل البيانات، لا يمكنك استخدام سوى طريقة POST. ويمكنك إرسال الاستعلام نفسه إما في body الخاص بـ POST أو في معلمة URL. لنلقِ نظرة على بعض الأمثلة. في المثال أدناه، يُستخدم curl لإرسال الاستعلام SELECT 1. لاحظ استخدام ترميز URL للمسافة: %20.
command
Response
في هذا المثال، يُستخدَم wget مع الخيارين -nv (بدون مخرجات تفصيلية) و-O- لطباعة النتيجة في الطرفية. في هذه الحالة، لا حاجة إلى استخدام ترميز URL للمسافة:
command
في هذا المثال، نمرّر طلب HTTP خامًا إلى netcat:
command
response
كما ترى، فإن الأمر curl غير عملي إلى حدّ ما، إذ يجب ترميز المسافات بصيغة URL. ورغم أن wget يتولى ترميز كل شيء بنفسه، فإننا لا نوصي باستخدامه لأنه لا يعمل جيدًا عبر HTTP 1.1 عند استخدام keep-alive و Transfer-Encoding: chunked.
إذا أُرسل جزء من الاستعلام في المعلَمة، وأُرسل جزء آخر في طلب POST، فسيُدرَج فاصل سطر بين جزأَي البيانات هذين. على سبيل المثال، لن يعمل هذا:
افتراضيًا، تُعاد البيانات بتنسيق TabSeparated. تُستخدم عبارة FORMAT في الاستعلام لطلب أي تنسيق آخر. على سبيل المثال:
command
Response
يمكنك استخدام معلمة URL ‏default_format أو ترويسة X-ClickHouse-Format لتحديد تنسيق افتراضي بدلاً من TabSeparated.
يمكنك استخدام طريقة POST مع الاستعلامات المُعلَّمة باستخدام المعاملات. تُحدَّد المعاملات باستخدام الأقواس المعقوفة مع اسم المعامل ونوعه، مثل {name:Type}. وتُمرَّر قيم المعاملات عبر param_name:

استعلامات INSERT عبر HTTP/HTTPS

تُعد طريقة POST لنقل البيانات ضرورية لاستعلامات INSERT. في هذه الحالة، يمكنك كتابة بداية الاستعلام في معلمة URL، واستخدام POST لتمرير البيانات المراد إدراجها. ويمكن أن تكون هذه البيانات، على سبيل المثال، ملف تفريغ من MySQL مفصولًا بعلامات جدولة. وبهذه الطريقة، يحل استعلام INSERT محل LOAD DATA LOCAL INFILE في MySQL.

أمثلة

لإنشاء جدول:
لاستخدام استعلام INSERT المعروف لإدراج البيانات:
لإرسال البيانات منفصلة عن الاستعلام:
يمكن تحديد أي صيغة بيانات. على سبيل المثال، يمكن تحديد صيغة ‘Values’، وهي الصيغة نفسها المستخدمة عند كتابة INSERT INTO t VALUES:
لإدراج البيانات من ملف تفريغ مفصول بعلامات جدولة، حدِّد التنسيق المقابل:
لقراءة محتويات الجدول:
تظهر البيانات بترتيب عشوائي بسبب معالجة الاستعلام بالتوازي
لحذف الجدول:
في الطلبات الناجحة التي لا تُرجع جدول بيانات، يُعاد جسم الاستجابة فارغًا.

الضغط

يمكن استخدام الضغط لتقليل حركة مرور الشبكة عند نقل كميات كبيرة من البيانات، أو لإنشاء ملفات تفريغ مضغوطة مباشرةً. يمكنك استخدام تنسيق الضغط الداخلي في ClickHouse عند نقل البيانات. تكون البيانات المضغوطة بتنسيق غير قياسي، وستحتاج إلى برنامج clickhouse-compressor للتعامل معها. ويُثبَّت هذا البرنامج افتراضيًا مع حزمة clickhouse-client. لزيادة كفاءة إدراج البيانات، عطّل التحقق من checksum من جهة الخادم عند فك الضغط باستخدام الإعداد http_native_compression_disable_checksumming_on_decompress. إذا حدّدت compress=1 في URL، فسيقوم الخادم بضغط البيانات التي يرسلها إليك. وإذا حدّدت decompress=1 في URL، فسيقوم الخادم بفك ضغط البيانات التي تمرّرها في طريقة POST. يمكنك أيضًا اختيار استخدام ضغط HTTP. يدعم ClickHouse طرق الضغط التالية:
  • gzip
  • br
  • deflate
  • xz
  • zstd
  • lz4
  • bz2
  • snappy
لإرسال طلب POST مضغوط، ألحِق ترويسة الطلب Content-Encoding: compression_method. ولكي يقوم ClickHouse بضغط الاستجابة، ألحِق الترويسة Accept-Encoding: compression_method بالطلب. يمكنك ضبط مستوى ضغط البيانات باستخدام الإعداد http_zlib_compression_level لجميع طرق الضغط.
قد تقوم بعض عملاء HTTP بفك ضغط البيانات الواردة من الخادم افتراضيًا (مع gzip وdeflate)، وقد تصلك بيانات مفكوكة الضغط حتى إذا استخدمت إعدادات الضغط بشكل صحيح.

أمثلة

لإرسال البيانات المضغوطة إلى الخادم:
لتسلُّم أرشيف البيانات المضغوط من الخادم:
لتلقّي البيانات المضغوطة من الخادم، استخدم gunzip لفك ضغط البيانات المستلَمة:

قاعدة البيانات الافتراضية

يمكنك استخدام المعلمة database في URL أو الترويسة X-ClickHouse-Database لتحديد قاعدة البيانات الافتراضية.
افتراضيًا، تُستخدم قاعدة البيانات المسجَّلة في إعدادات الخادم كقاعدة البيانات الافتراضية. وبشكل افتراضي عند التثبيت، تكون هذه هي قاعدة البيانات المسماة default. أو يمكنك دائمًا تحديد قاعدة البيانات بوضع نقطة قبل اسم الجدول.

المصادقة

يمكن إدخال اسم المستخدم وكلمة المرور بإحدى الطرق الثلاث التالية:
  1. باستخدام المصادقة الأساسية عبر HTTP.
على سبيل المثال:
  1. في معلمتَي URL user وpassword
لا نوصي باستخدام هذه الطريقة، لأن المعلَمة قد تُسجَّل عبر وكيل ويب وتُخزَّن مؤقتًا في المتصفح
على سبيل المثال:
  1. استخدام ترويستَي ‘X-ClickHouse-User’ و’X-ClickHouse-Key’
على سبيل المثال:
إذا لم يُحدَّد اسم المستخدم، فسيُستخدم الاسم default. وإذا لم تُحدَّد كلمة المرور، فستُستخدم كلمة مرور فارغة. يمكنك أيضًا استخدام معلمات URL لتحديد أي إعدادات لمعالجة استعلام واحد أو ملفات تعريف كاملة للإعدادات. على سبيل المثال:
لمزيد من المعلومات، راجع:

استخدام جلسات ClickHouse في بروتوكول HTTP

يمكنك أيضًا استخدام جلسات ClickHouse ضمن بروتوكول HTTP. للقيام بذلك، عليك إضافة معلمة GETsession_id إلى الطلب. ويمكنك استخدام أي سلسلة نصية كمعرّف للجلسة. افتراضيًا، تُنهى الجلسة بعد 60 ثانية من عدم النشاط. لتغيير هذه المهلة (بالثواني)، عدّل الإعداد default_session_timeout في تهيئة الخادم، أو أضف معلمة GETsession_timeout إلى الطلب. للتحقق من حالة الجلسة، استخدم المعلمة session_check=1. ولا يمكن تنفيذ أكثر من استعلام واحد في الوقت نفسه ضمن الجلسة الواحدة. يمكنك تلقّي معلومات حول تقدّم الاستعلام في ترويسات الاستجابة X-ClickHouse-Progress. للقيام بذلك، فعّل send_progress_in_http_headers. فيما يلي مثال على تسلسل الترويسات:
حقول الترويسة المحتملة هي:
Header fieldDescription
read_rowsعدد الصفوف المقروءة.
read_bytesحجم البيانات المقروءة بالبايت.
total_rows_to_readالعدد الإجمالي للصفوف المطلوب قراءتها.
written_rowsعدد الصفوف المكتوبة.
written_bytesحجم البيانات المكتوبة بالبايت.
elapsed_nsوقت تشغيل الاستعلام بالنانوثانية.
memory_usageمقدار الذاكرة بالبايت التي يستخدمها الاستعلام. (متاح بدءًا من v25.11)
لا تتوقف الطلبات الجارية تلقائيًا إذا فُقد اتصال HTTP. يُجرى التحليل وتنسيق البيانات على جانب الخادم، وقد لا يكون استخدام الشبكة فعّالًا. تتوفر المعلمات الاختيارية التالية:
ParametersDescription
query_id (optional)يمكن تمريره بصفته معرّف الاستعلام (أي سلسلة نصية). replace_running_query
quota_key (optional)يمكن تمريره بصفته مفتاح الحصة (أي سلسلة نصية). “Quotas”
تتيح واجهة HTTP تمرير بيانات خارجية (جداول مؤقتة خارجية) لاستخدامها في الاستعلام. لمزيد من المعلومات، راجع “البيانات الخارجية لمعالجة الاستعلامات”.

تخزين الاستجابة مؤقتًا

يمكن تمكين تخزين الاستجابة مؤقتًا على جانب الخادم. تُوفَّر معلمات URL التالية لهذا الغرض:
  • buffer_size
  • wait_end_of_query
يمكن استخدام الإعدادات التالية: يحدِّد buffer_size عدد البايتات من النتيجة التي ستُخزَّن مؤقتًا في ذاكرة الخادم. وإذا كان محتوى النتيجة أكبر من هذه العتبة، فستُكتب البيانات المخزنة مؤقتًا إلى قناة HTTP، وتُرسَل البيانات المتبقية مباشرةً إلى قناة HTTP. ولضمان تخزين الاستجابة كاملةً مؤقتًا، اضبط wait_end_of_query=1. في هذه الحالة، ستُخزَّن البيانات التي لا تُحفَظ في الذاكرة مؤقتًا في ملف مؤقت على الخادم. على سبيل المثال:
استخدم التخزين المؤقت لتجنّب الحالات التي يقع فيها خطأ في معالجة الاستعلام بعد إرسال رمز الاستجابة ورؤوس HTTP إلى العميل. في هذه الحالة، تُكتب رسالة الخطأ في نهاية جسم الاستجابة، وعلى جهة العميل لا يمكن اكتشاف الخطأ إلا في مرحلة التحليل.

تعيين دور باستخدام معلمات الاستعلام

أُضيفت هذه الميزة في ClickHouse 24.4. في حالات معيّنة، قد يلزم تعيين الدور الممنوح أولًا قبل تنفيذ التعليمة نفسها. ومع ذلك، لا يمكن إرسال SET ROLE والتعليمة معًا، لأن العبارات المتعددة غير مسموح بها:
ينتج عن الأمر أعلاه خطأ:
لتجاوز هذا القيد، استخدم معلَمة الاستعلام role بدلاً من ذلك:
هذا يعادل تنفيذ SET ROLE my_role قبل التعليمة. بالإضافة إلى ذلك، يمكن تحديد عدة معلمات استعلام باسم role:
في هذه الحالة، يعمل ?role=my_role&role=my_other_role بشكل مماثل لتنفيذ SET ROLE my_role, my_other_role قبل العبارة.

محاذير رموز استجابة HTTP

نظرًا لقيود بروتوكول HTTP، فإن رمز الاستجابة HTTP 200 لا يضمن نجاح الاستعلام. إليك مثالًا:
يرجع سبب هذا السلوك إلى طبيعة بروتوكول HTTP. إذ تُرسَل ترويسة HTTP أولًا مع رمز HTTP بقيمة 200، ثم يُرسَل جسم HTTP، وبعد ذلك يُحقَن الخطأ في الجسم كنص عادي. هذا السلوك مستقل عن التنسيق المستخدم، سواء كان Native أو TSV أو JSON؛ إذ ستظهر رسالة الخطأ دائمًا في وسط دفق الاستجابة. يمكنك التخفيف من هذه المشكلة عبر تمكين wait_end_of_query=1 (تخزين الاستجابة مؤقتًا). في هذه الحالة، يتأخر إرسال ترويسة HTTP إلى أن يُحسَم الاستعلام بالكامل. ومع ذلك، لا يحل هذا المشكلة بالكامل، لأن النتيجة يجب أن تظل ضمن http_response_buffer_size، كما أن إعدادات أخرى مثل send_progress_in_http_headers قد تتداخل مع تأخير الترويسة.
الطريقة الوحيدة لالتقاط جميع الأخطاء هي تحليل جسم HTTP قبل parse له باستخدام التنسيق المطلوب.
تكون مثل هذه الاستثناءات في ClickHouse ذات تنسيق متسق للاستثناءات كما هو موضح أدناه، بغض النظر عن التنسيق المستخدم (مثل Native وTSV وJSON وغيرها) عندما تكون http_write_exception_in_output_format=0 (الافتراضي). وهذا يسهّل تحليل رسائل الخطأ واستخراجها من جهة العميل.
حيث يكون <TAG> وسمًا عشوائيًا بطول 16 بايت، وهو نفس الوسم المُرسَل في ترويسة الاستجابة X-ClickHouse-Exception-Tag. أما <error message> فهي رسالة الاستثناء الفعلية (يمكن العثور على طولها الدقيق في <message_length>). ويمكن أن يصل حجم كتلة الاستثناء الكاملة الموضحة أعلاه إلى 16 KiB. فيما يلي مثال بتنسيق JSON
فيما يلي مثال مشابه ولكن بصيغة CSV

استعلامات بمعلمات

يمكنك إنشاء استعلام بمعلمات وتمرير قيمها عبر معلمات طلب HTTP المقابلة. لمزيد من المعلومات، راجع الاستعلامات بمعلمات في CLI.

مثال

علامات الجدولة في معلمات URL

تُحلَّل معلمات الاستعلام من صيغة “escaped”. ولهذا بعض المزايا، مثل إمكانية تحليل قيم NULL دون لبس على أنها \N. وهذا يعني أن محرف الجدولة يجب ترميزه على هيئة \t (أو \ ثم علامة جدولة). على سبيل المثال، يحتوي ما يلي على علامة جدولة فعلية بين abc و123، وتُقسَّم سلسلة الإدخال إلى قيمتين:
ومع ذلك، إذا حاولت ترميز محرف جدولة فعلي باستخدام %09 في مَعلمة URL، فلن يُحلَّل بشكل صحيح:
إذا كنت تستخدم معلمات URL، فستحتاج إلى ترميز \t على هيئة %5C%09. على سبيل المثال:

واجهة HTTP المُعرَّفة مسبقًا

يدعم ClickHouse استعلامات محددة عبر واجهة HTTP. على سبيل المثال، يمكنك إدخال البيانات في جدول كما يلي:
يدعم ClickHouse أيضًا واجهة HTTP المحددة مسبقًا، والتي يمكن أن تساعدك على التكامل بسهولة أكبر مع أدوات خارجية مثل Prometheus exporter. لنلقِ نظرة على مثال. أولًا، أضِف هذا القسم إلى ملف تهيئة الخادم. تمت تهيئة http_handlers ليتضمن عدة rule. وسيطابق ClickHouse طلبات HTTP الواردة مع النوع المحدد مسبقًا في rule، وستُشغِّل أول قاعدة تتم مطابقتها المعالج. بعد ذلك، سينفّذ ClickHouse الاستعلام المحدد مسبقًا المقابل إذا نجحت المطابقة.
config.xml
يمكنك الآن طلب URL مباشرةً للحصول على البيانات بتنسيق Prometheus:
تعمل خيارات التكوين الخاصة بـ http_handlers كما يلي. يمكن ضبط rule باستخدام المعلمات التالية:
  • method
  • headers
  • url
  • full_url
  • handler
فيما يلي شرح لكلٍّ من هذه العناصر:
  • يكون method مسؤولًا عن مطابقة جزء method في طلب HTTP. ويتوافق method بالكامل مع تعريف [method] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) في HTTP protocol. وهو إعداد اختياري. إذا لم يكن معرّفًا في configuration file، فلن يطابق جزء method من طلب HTTP.
  • يكون url مسؤولًا عن مطابقة جزء URL (المسار وquery string) من طلب HTTP. إذا كانت url مسبوقة بـ regex:، فإنه يتوقع regular expression بصيغة RE2. وهو إعداد اختياري. إذا لم يكن معرّفًا في configuration file، فلن يطابق جزء URL من طلب HTTP.
  • full_url مثل url، لكنه يتضمن URL كاملًا، أي schema://host:port/path?query_string. ملاحظة: لا يدعم ClickHouse “virtual hosts”، لذا يكون host عنوان IP (وليس قيمة header ‏Host).
  • empty_query_string — يضمن عدم وجود query string (?query_string) في الطلب
  • تكون headers مسؤولة عن مطابقة جزء header من طلب HTTP. وهي متوافقة مع regular expression الخاصة بـ RE2. وهي إعداد اختياري . إذا لم تكن معرّفة في configuration file، فلن تطابق جزء header من طلب HTTP.
  • يحتوي handler على جزء processing الرئيسي. ويمكن أن يكون له type التالي: والمعلمات التالية:
    • query — يُستخدم مع النوع predefined_query_handler، وينفّذ استعلام عند استدعاء handler.
    • query_param_name — يُستخدم مع النوع dynamic_query_handler، ويستخرج وينفّذ القيمة المقابلة لقيمة query_param_name في معلمات طلب HTTP.
    • status — يُستخدم مع النوع static، وهو رمز حالة الاستجابة.
    • content_type — يُستخدم مع أي type، وهو content-type للاستجابة.
    • http_response_headers — يُستخدم مع أي type، وهو map لـ headers الخاصة بالاستجابة. ويمكن استخدامه أيضًا لتعيين نوع المحتوى.
    • response_content — يُستخدم مع النوع static، وهو محتوى الاستجابة المُرسَل إلى client. وعند استخدام البادئة ‘file://’ أو ‘config://’، يُؤخذ المحتوى من الملف أو config ويُرسَل إلى client.
    • user - المستخدم الذي يُنفَّذ الاستعلام باسمه (default user هو default). ملاحظة، لا تحتاج إلى تحديد password لهذا المستخدم.
ستُناقش إعدادات الأنواع type المختلفة بعد ذلك.

predefined_query_handler

يدعم predefined_query_handler تعيين قيم Settings وquery_params. ويمكنك ضبط query ضمن النوع predefined_query_handler. تمثل قيمة query استعلامًا محددًا مسبقًا لـ predefined_query_handler، ويُنفَّذ بواسطة ClickHouse عند مطابقة طلب HTTP ثم تُعاد نتيجة الاستعلام. وهذا إعداد مطلوب. يوضح المثال التالي قيم إعدادَي max_threads وmax_final_threads، ثم يستعلم جدول النظام للتحقق مما إذا كانت هذه الإعدادات قد ضُبطت بنجاح.
للاحتفاظ بـ handlers الافتراضية مثل query وplay وping، أضف القاعدة <defaults/>.
على سبيل المثال:

المعلمة الافتراضية _request_body

بالإضافة إلى معلمات URL والترويسات ومعلمات الاستعلام، يدعم predefined_query_handler معلمة افتراضية خاصة باسم _request_body. وتحتوي هذه المعلمة على جسم طلب HTTP الخام على هيئة سلسلة نصية. يتيح لك ذلك إنشاء واجهات برمجة تطبيقات REST مرنة يمكنها قبول تنسيقات بيانات متنوعة ومعالجتها داخل استعلاماتك. على سبيل المثال، يمكنك استخدام _request_body لإنشاء نقطة نهاية REST تقبل بيانات JSON في طلب POST وتُدرجها في جدول:
يمكنك بعد ذلك إرسال البيانات إلى نقطة النهاية التالية:
في كل predefined_query_handler، لا يُدعَم إلا query واحد.

dynamic_query_handler

في dynamic_query_handler، يُكتب الاستعلام على شكل مُعامل في طلب HTTP. والفرق هو أنه في predefined_query_handler، يُكتب الاستعلام في ملف الإعدادات. ويمكن تهيئة query_param_name في dynamic_query_handler. يستخرج ClickHouse القيمة المقابلة لـ query_param_name من URL الخاص بطلب HTTP ثم ينفّذها. والقيمة الافتراضية لـ query_param_name هي /query . وهذا إعداد اختياري. وإذا لم يكن هناك تعريف له في ملف الإعدادات، فلن يتم تمرير المُعامل. لتجربة هذه الوظيفة، يحدّد المثال التالي قيم max_threads وmax_final_threads، ثم ينفّذ استعلامات للتحقق مما إذا كانت الإعدادات قد ضُبطت بنجاح. مثال:

static

يمكن لـ static إرجاع content_type وstatus وresponse_content. ويمكن أن يعيد response_content المحتوى المحدد. على سبيل المثال، لإرجاع الرسالة “Say Hi!”:
يمكن استخدام http_response_headers لتحديد نوع المحتوى بدلًا من content_type.
اعثر على المحتوى في الإعداد المُرسَل إلى العميل.
للعثور على محتوى الملف المُرسَل إلى العميل:

redirect

سيؤدي redirect إلى إعادة توجيه 302 إلى location على سبيل المثال، إليك كيفية إضافة set user تلقائيًا إلى play في ClickHouse play:

ترويسات استجابة HTTP

يتيح لك ClickHouse تهيئة ترويسات استجابة HTTP مخصّصة يمكن تطبيقها على أي نوع من المعالجات القابلة للتهيئة. ويمكن ضبط هذه الترويسات باستخدام الإعداد http_response_headers، الذي يقبل أزواج مفتاح-قيمة تمثل أسماء الترويسات وقيمها. وتُعد هذه الميزة مفيدة بشكل خاص لتطبيق ترويسات أمان مخصّصة، أو سياسات CORS، أو أي متطلبات أخرى خاصة بترويسات HTTP عبر واجهة ClickHouse HTTP. على سبيل المثال، يمكنك تهيئة ترويسات من أجل:
  • نقاط نهاية الاستعلام العادية
  • واجهة الويب
  • فحص الحالة.
ومن الممكن أيضًا تحديد common_http_response_headers. وسيتم تطبيقها على جميع معالجات HTTP المعرّفة في التهيئة. ستُضمَّن هذه الترويسات في استجابة HTTP لكل معالج تم تكوينه. في المثال أدناه، ستحتوي كل استجابة من الخادم على ترويستين مخصّصتين: X-My-Common-Header و X-My-Custom-Header.

استجابة JSON/XML صالحة عند حدوث استثناء أثناء HTTP streaming

أثناء تنفيذ استعلام عبر HTTP، قد يحدث استثناء بعد إرسال جزء من البيانات بالفعل. وعادةً ما يُرسَل الاستثناء إلى client كنص عادي. وقد يحدث ذلك حتى عند استخدام format بيانات محدد لإخراج البيانات، مما قد يجعل الإخراج غير صالح وفقًا لتنسيق البيانات المحدد. ولتجنّب ذلك، يمكنك استخدام الإعداد http_write_exception_in_output_format (وهو معطّل افتراضيًا)، الذي يوجّه ClickHouse إلى كتابة الاستثناء بالتنسيق المحدد (وهو مدعوم حاليًا لتنسيقات XML وJSON*). أمثلة:
آخر تعديل في ٣ يوليو ٢٠٢٦