المتطلبات الأساسية
- أن يكون لديك مثيل عامل من ClickHouse server
- أن يكون
curlمثبّتًا لديك. على Ubuntu أو Debian، شغّلsudo apt install curlأو راجع هذه الوثائق للحصول على إرشادات التثبيت.
نظرة عامة
clickhouse-server على المنافذ التالية:
- المنفذ 8123 لـ HTTP
- يمكن تمكين المنفذ 8443 لـ HTTPS
GET / من دون أي معلمات، فسيُعاد رمز الاستجابة 200 مع السلسلة “Ok.”:
http_server_default_response، ويمكن تغييرها عند الحاجة.
راجع أيضًا: محاذير رموز استجابة HTTP.
واجهة مستخدم الويب
GET /ping. يعيد هذا المعالج دائمًا “Ok.” (مع فاصل سطر في النهاية). وهو متاح بدءًا من الإصدار 18.12.13. انظر أيضًا إلى /replicas_status للتحقق من تأخر النسخة المتماثلة.
الاستعلام عبر HTTP/HTTPS
- إرسال الطلب كمعلمة URL باسم ‘query’
- استخدام طريقة POST.
- إرسال بداية الاستعلام في المعلمة ‘query’، ثم إرسال الباقي باستخدام POST
يكون حجم URL محدودًا افتراضيًا إلى 1 MiB، ويمكن تغيير ذلك باستخدام الإعداد
http_max_uri_size.SELECT 1. لاحظ استخدام ترميز URL للمسافة: %20.
command
Response
-nv (بدون مخرجات تفصيلية) و-O- لطباعة النتيجة في الطرفية.
في هذه الحالة، لا حاجة إلى استخدام ترميز URL للمسافة:
command
command
response
curl غير عملي إلى حدّ ما، إذ يجب ترميز المسافات بصيغة URL.
ورغم أن wget يتولى ترميز كل شيء بنفسه، فإننا لا نوصي باستخدامه لأنه لا يعمل جيدًا عبر HTTP 1.1 عند استخدام keep-alive و Transfer-Encoding: chunked.
TabSeparated.
تُستخدم عبارة FORMAT في الاستعلام لطلب أي تنسيق آخر. على سبيل المثال:
command
Response
default_format لتحديد تنسيق افتراضي بدلاً من TabSeparated. تحدد ترويسة X-ClickHouse-Format تنسيق الاستجابة صراحةً: فهي اسم مستعار للإعداد output_format، لذا تتجاوز أيضاً عبارة FORMAT في الاستعلام. ولا تغيّر مطلقاً كيفية تحليل نص طلب INSERT — استخدم input_format أو format لهذا الغرض.
{name:Type}. وتُمرَّر قيم المعلمات عبر param_name:
الوصول إلى الجداول عبر مسارات URL وإنشاء الاستعلامات
تفعيل التوجيه عبر المسارات
- فعِّل إعداد التكوين
http_allow_path_requestsعلى مستوى الخادم، الذي يتيح لواجهة HTTP توجيه الطلبات ذات نمط المسار إلى معالج الاستعلامات:
- فعّل الإعدادات المطلوبة لكل مستخدم:
يحدث التوجيه قبل المصادقة، لذا لا يمكن أن يعتمد على إعداد خاص بكل مستخدم. عند تعطيل
http_allow_path_requests، يُرجع المسار غير المعروف رمز 404 قبل المصادقة. بعد التوجيه والمصادقة، تحدد الإعدادات الخاصة بكل مستخدم كيفية تفسير المسار، مما يتيح لك تمكين الميزة بشكل انتقائي لمستخدم أو دور أو ملف تعريف.الوصول إلى الجداول كملفات
http_allow_table_as_file، يُعالَج الطلب الموجّه إلى /table.format.compression على أنه SELECT * FROM table. فعّل http_allow_database_as_path لاستخدام /database/table.format.compression.
hits.csv وhits.CSV متكافئان.
تتجاوز معلمة URL الصريحة format أو output_format التنسيق المحدد في المسار. أما default_format فلا يتجاوزه، إذ يوفّر التنسيق المستخدم فقط عندما لا يحدد أي شيء آخر تنسيقًا، ويكون امتداد المسار أكثر تحديدًا. يجب أن تتطابق معلمة compression الصريحة مع الضغط المحدد في المسار؛ وتؤدي القيم المتعارضة إلى استثناء.
إنشاء استعلام
SETTINGS في الاستعلام، أو عبر ملف تعريف المستخدم.
تعديل استعلام موجود
?query=SELECT a, b FROM hits&filter=a > 0&sort=-b&limit=10 على النحو التالي:
predefined_query_handler، أو عميل لا يتيح إلا إلحاق معلمات URL:
FORMAT ومع ORDER BY داخل الاستعلام، ولا تغيّر مطلقًا الصفوف التي يكتبها INSERT: إذ يؤثر إعداد البناء الموضوع في تعليمة INSERT ... SELECT في نتيجة التعليمة نفسها (الفارغة)، وليس في SELECT المصدرية. وللتأثير في المصدر، ضع الإعداد في عبارة SETTINGS الخاصة بـSELECT نفسها:
تجاوز التنسيقات والضغط
تعمل إعدادات التنسيق أيضًا مع بروتوكولات أخرى، بما فيها العميل الأصلي و
clickhouse-local. ويتوافق input_format وoutput_format مع الخيارين --input-format و--output-format. ويرتبط الخيار --format بإعداد format ثنائي الاتجاه في clickhouse-local، بينما يحتفظ في clickhouse-client بمعناه التاريخي المقتصر على الإخراج ويرتبط بـ output_format.
يُستخدم compression خصيصًا لتشكيل استجابة HTTP، وتتم معالجته قبل تنفيذ الاستعلام. حدده عبر معلمة URL في HTTP، أو امتداد مسار، أو ملف تعريف مستخدم. ويُرفض ضمن عبارة SETTINGS داخل الاستعلام.
تتضمن استجابات HTTP الثنائية والمضغوطة ترويسة Content-Disposition: attachment; filename=…. ويُشتق اسم الملف من مسار URL، أو يُستخدم result.<format>.<compression> إذا لم يوفر المسار اسمًا.
استخدام جدول مسار مع استعلام
query، يُتاح جدول المسار عبر implicit_table_at_top_level. تقرأ عبارة SELECT التي لا تحتوي على عبارة FROM من جدول المسار:
FROM، فلا يحدد مكوّن المسار سوى اسم ملف التنزيل.
استعلامات INSERT عبر HTTP/HTTPS
POST لنقل البيانات ضرورية لاستعلامات INSERT. في هذه الحالة، يمكنك كتابة بداية الاستعلام في معلمة URL، واستخدام POST لتمرير البيانات المراد إدراجها. ويمكن أن تكون هذه البيانات، على سبيل المثال، ملف تفريغ من MySQL مفصولًا بعلامات جدولة. وبهذه الطريقة، يحل استعلام INSERT محل LOAD DATA LOCAL INFILE في MySQL.
أمثلة
INSERT المعروف لإدراج البيانات:
INSERT INTO t VALUES:
تظهر البيانات بترتيب عشوائي بسبب معالجة الاستعلام بالتوازي
الضغط
clickhouse-compressor للتعامل معها. ويُثبَّت هذا البرنامج افتراضيًا مع حزمة clickhouse-client.
لزيادة كفاءة إدراج البيانات، عطّل التحقق من checksum من جهة الخادم عند فك الضغط باستخدام الإعداد http_native_compression_disable_checksumming_on_decompress.
إذا حدّدت compress=1 في URL، فسيقوم الخادم بضغط البيانات التي يرسلها إليك. وإذا حدّدت decompress=1 في URL، فسيقوم الخادم بفك ضغط البيانات التي تمرّرها في طريقة POST.
يمكنك أيضًا اختيار استخدام ضغط HTTP. يدعم ClickHouse طرق الضغط التالية:
gzipbrdeflatexzzstdlz4bz2snappy
POST مضغوط، ألحِق ترويسة الطلب Content-Encoding: compression_method.
ولكي يقوم ClickHouse بضغط الاستجابة، ألحِق الترويسة Accept-Encoding: compression_method بالطلب.
يمكنك ضبط مستوى ضغط البيانات باستخدام الإعداد http_zlib_compression_level لجميع طرق الضغط.
قد تقوم بعض عملاء HTTP بفك ضغط البيانات الواردة من الخادم افتراضيًا (مع
gzip وdeflate)، وقد تصلك بيانات مفكوكة الضغط حتى إذا استخدمت إعدادات الضغط بشكل صحيح.أمثلة
gunzip لفك ضغط البيانات المستلَمة:
قاعدة البيانات الافتراضية
database في URL أو الترويسة X-ClickHouse-Database لتحديد قاعدة البيانات الافتراضية.
default. أو يمكنك دائمًا تحديد قاعدة البيانات بوضع نقطة قبل اسم الجدول.
المصادقة
- باستخدام المصادقة الأساسية عبر HTTP.
- في معلمتَي URL
userوpassword
- استخدام ترويستَي ‘X-ClickHouse-User’ و’X-ClickHouse-Key’
default. وإذا لم تُحدَّد كلمة المرور، فستُستخدم كلمة مرور فارغة.
يمكنك أيضًا استخدام معلمات URL لتحديد أي إعدادات لمعالجة استعلام واحد أو ملفات تعريف كاملة للإعدادات.
على سبيل المثال:
استخدام جلسات ClickHouse في بروتوكول HTTP
GET session_id إلى الطلب. ويمكنك استخدام أي سلسلة نصية كمعرّف للجلسة.
افتراضيًا، تُنهى الجلسة بعد 60 ثانية من عدم النشاط. لتغيير هذه المهلة (بالثواني)، عدّل الإعداد default_session_timeout في تهيئة الخادم، أو أضف معلمة GET session_timeout إلى الطلب.
للتحقق من حالة الجلسة، استخدم المعلمة session_check=1. ولا يمكن تنفيذ أكثر من استعلام واحد في الوقت نفسه ضمن الجلسة الواحدة.
يمكنك تلقّي معلومات حول تقدّم الاستعلام في ترويسات الاستجابة X-ClickHouse-Progress. للقيام بذلك، فعّل send_progress_in_http_headers.
فيما يلي مثال على تسلسل الترويسات:
لا تتوقف الطلبات الجارية تلقائيًا إذا فُقد اتصال HTTP. يُجرى التحليل وتنسيق البيانات على جانب الخادم، وقد لا يكون استخدام الشبكة فعّالًا.
تتوفر المعلمات الاختيارية التالية:
تتيح واجهة HTTP تمرير بيانات خارجية (جداول مؤقتة خارجية) لاستخدامها في الاستعلام. لمزيد من المعلومات، راجع “البيانات الخارجية لمعالجة الاستعلامات”.
تخزين الاستجابة مؤقتًا
buffer_sizewait_end_of_query
buffer_size عدد البايتات من النتيجة التي ستُخزَّن مؤقتًا في ذاكرة الخادم. وإذا كان محتوى النتيجة أكبر من هذه العتبة، فستُكتب البيانات المخزنة مؤقتًا إلى قناة HTTP، وتُرسَل البيانات المتبقية مباشرةً إلى قناة HTTP.
ولضمان تخزين الاستجابة كاملةً مؤقتًا، اضبط wait_end_of_query=1. في هذه الحالة، ستُخزَّن البيانات التي لا تُحفَظ في الذاكرة مؤقتًا في ملف مؤقت على الخادم.
على سبيل المثال:
تعيين دور باستخدام معلمات الاستعلام
SET ROLE والتعليمة معًا، لأن العبارات المتعددة غير مسموح بها:
role بدلاً من ذلك:
SET ROLE my_role قبل التعليمة.
بالإضافة إلى ذلك، يمكن تحديد عدة معلمات استعلام باسم role:
?role=my_role&role=my_other_role بشكل مماثل لتنفيذ SET ROLE my_role, my_other_role قبل العبارة.
محاذير رموز استجابة HTTP
Native أو TSV أو JSON؛ إذ ستظهر رسالة الخطأ دائمًا في وسط دفق الاستجابة.
يمكنك التخفيف من هذه المشكلة عبر تمكين wait_end_of_query=1 (تخزين الاستجابة مؤقتًا). في هذه الحالة، يتأخر إرسال ترويسة HTTP إلى أن يُحسَم الاستعلام بالكامل. ومع ذلك، لا يحل هذا المشكلة بالكامل، لأن النتيجة يجب أن تظل ضمن http_response_buffer_size، كما أن إعدادات أخرى مثل send_progress_in_http_headers قد تتداخل مع تأخير الترويسة.
تكون مثل هذه الاستثناءات في 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
استعلامات بمعلمات
مثال
علامات الجدولة في معلمات URL
\N. وهذا يعني أن محرف الجدولة يجب ترميزه على هيئة \t (أو \ ثم علامة جدولة). على سبيل المثال، يحتوي ما يلي على علامة جدولة فعلية بين abc و123، وتُقسَّم سلسلة الإدخال إلى قيمتين:
%09 في مَعلمة URL، فلن يُحلَّل بشكل صحيح:
\t على هيئة %5C%09. على سبيل المثال:
واجهة HTTP المُعرَّفة مسبقًا
http_handlers ليتضمن عدة rule. وسيطابق ClickHouse طلبات HTTP الواردة مع النوع المحدد مسبقًا في rule، وستُشغِّل أول قاعدة تتم مطابقتها المعالج. بعد ذلك، سينفّذ ClickHouse الاستعلام المحدد مسبقًا المقابل إذا نجحت المطابقة.
config.xml
http_handlers كما يلي.
يمكن ضبط rule باستخدام المعلمات التالية:
methodheadersurlfull_urlhandler
-
يكون
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
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
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_write_exception_in_output_format (وهو معطّل افتراضيًا)، الذي يوجّه ClickHouse إلى كتابة الاستثناء بالتنسيق المحدد (وهو مدعوم حاليًا لتنسيقات XML وJSON*).
أمثلة: