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

تهيئة العميل

توفّر الفئة clickhouse_connect.driver.client الواجهة الرئيسية بين تطبيق بايثون وخادم قاعدة بيانات ClickHouse. استخدم الدالة clickhouse_connect.get_client للحصول على مثيل من Client، والذي يقبل الوسيطات التالية:

وسائط الاتصال

وسائط HTTPS/TLS

وسيطة Settings

أخيرًا، تُستخدم وسيطة settings في get_client لتمرير إعدادات ClickHouse إضافية إلى الخادم مع كل طلب من العميل. لاحظ أنه في معظم الحالات، لا يمكن للمستخدمين الذين لديهم صلاحية وصول readonly=1 تعديل الإعدادات المرسلة مع الاستعلام، لذلك سيُسقط ClickHouse Connect هذه الإعدادات من الطلب النهائي ويسجل تحذيرًا. تنطبق الإعدادات التالية فقط على استعلامات/جلسات HTTP التي يستخدمها ClickHouse Connect، وليست موثقة باعتبارها إعدادات ClickHouse عامة. للاطلاع على إعدادات ClickHouse الأخرى التي يمكن إرسالها مع كل استعلام، راجع وثائق ClickHouse.

أمثلة على إنشاء العميل

  • من دون أي معلمات، سيتصل عميل ClickHouse Connect بمنفذ HTTP الافتراضي على localhost باستخدام المستخدم default ومن دون كلمة مرور:
  • الاتصال بخادم ClickHouse خارجي آمن عبر HTTPS
  • الاتصال باستخدام معرّف جلسة ومعلمات اتصال مخصّصة أخرى وإعدادات ClickHouse.

دورة حياة العميل وأفضل الممارسات

يُعَدّ إنشاء عميل ClickHouse Connect عملية مكلفة، إذ يتضمن إنشاء اتصال، واسترجاع البيانات الوصفية الخاصة بالخادم، وتهيئة الإعدادات. اتبع أفضل الممارسات التالية لتحقيق أفضل أداء:

المبادئ الأساسية

  • أعِد استخدام العملاء: أنشئ العملاء مرة واحدة عند بدء تشغيل التطبيق، وأعِد استخدامهم طوال دورة حياة التطبيق
  • تجنّب الإنشاء المتكرر: لا تُنشئ عميلاً جديدًا لكل query أو طلب (فهذا يهدر مئات المللي ثانية لكل عملية)
  • نظّف الموارد بشكل صحيح: احرص دائمًا على إغلاق العملاء عند إيقاف التشغيل لتحرير موارد مجمع الاتصالات
  • استخدم عميلاً واحدًا عند الإمكان: يمكن لعميل واحد معالجة العديد من الاستعلامات المتزامنة عبر مجمع الاتصالات الخاص به (راجع ملاحظات مؤشرات الترابط أدناه)

أنماط أساسية

✅ جيد: أعِد استخدام عميل واحد
❌ غير مستحسن: إنشاء clients بصورة متكررة

التطبيقات متعددة الخيوط

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

التنظيف الصحيح

أغلق كائنات العميل دائمًا عند إيقاف التشغيل. لاحظ أن client.close() يحرّر العميل ويغلق اتصالات HTTP المجمّعة فقط عندما يكون العميل هو مالك مدير الـ pool الخاص به (على سبيل المثال، عند إنشائه باستخدام خيارات TLS/proxy مخصّصة). أمّا بالنسبة إلى الـ pool المشتركة الافتراضية، فاستخدم client.close_connections() لإغلاق الـ sockets بشكل استباقي؛ وإلا فستُسترد الاتصالات تلقائيًا عند انتهاء مهلة الخمول وعند خروج العملية.
أو استخدم مدير السياق:

متى تستخدم عدة عملاء

يكون استخدام عدة عملاء مناسبًا في الحالات التالية:
  • خوادم مختلفة: عميل واحد لكل ClickHouse server أو عنقود
  • بيانات اعتماد مختلفة: عملاء منفصلون لمستخدمين مختلفين أو لمستويات وصول مختلفة
  • قواعد بيانات مختلفة: عندما تحتاج إلى العمل مع عدة قواعد بيانات
  • جلسات معزولة: عندما تحتاج إلى جلسات منفصلة للجداول المؤقتة أو للإعدادات الخاصة بالجلسة
  • عزل لكل خيط تنفيذ: عندما تحتاج خيوط التنفيذ إلى جلسات مستقلة (كما هو موضح أعلاه)

وسائط الطرق الشائعة

تستخدم عدة طرق في العميل إحدى وسيطتي parameters وsettings الشائعتين أو كلتيهما. وتُشرح وسائط الكلمات المفتاحية هذه أدناه.

وسيطة Parameters

تقبل طرائق query* وcommand في ClickHouse Connect Client وسيطة keyword اختيارية باسم parameters، تُستخدم لربط تعبيرات بايثون بتعبير قيمة في ClickHouse. ويتوفر نوعان من هذا الربط.

الربط من جهة الخادم

يدعم ClickHouse الربط من جهة الخادم لمعظم قيم الاستعلام، حيث تُرسل القيمة المربوطة بشكل منفصل عن الاستعلام على هيئة معلمة استعلام في HTTP. وسيضيف ClickHouse Connect معلمات الاستعلام المناسبة إذا اكتشف تعبير ربط بالصيغة {<name>:<datatype>}. عند استخدام الربط من جهة الخادم، يجب أن تكون الوسيطة parameters قاموسًا في بايثون.
  • الربط من جهة الخادم باستخدام قاموس بايثون، وقيمة DateTime، وقيمة نصية
يولِّد هذا الاستعلام التالي على الخادم:
لا يُدعَم الربط من جهة الخادم (من خلال خادم ClickHouse) إلا في استعلامات SELECT. ولا يعمل مع ALTER أو DELETE أو INSERT أو غيرها من أنواع الاستعلامات. وقد يتغير هذا في المستقبل؛ راجع https://github.com/ClickHouse/ClickHouse/issues/42092.

الربط من جهة العميل

يدعم ClickHouse Connect أيضًا ربط المعلمات من جهة العميل، ما يتيح مرونة أكبر عند إنشاء استعلامات SQL المعتمدة على القوالب. بالنسبة إلى الربط من جهة العميل، يجب أن تكون وسيطة parameters قاموسًا أو تسلسلًا. ويستخدم الربط من جهة العميل تنسيق السلاسل بأسلوب “printf” في بايثون لإجراء استبدال المعلمات. لاحظ أنه، بخلاف الربط من جهة الخادم، لا يعمل الربط من جهة العميل مع معرّفات قاعدة البيانات مثل أسماء قواعد البيانات أو الجداول أو الأعمدة، لأن التنسيق بأسلوب بايثون لا يستطيع التمييز بين الأنواع المختلفة من السلاسل، كما أنها تحتاج إلى تنسيق مختلف (backticks أو علامتا الاقتباس المزدوجتان لمعرّفات قاعدة البيانات، وعلامتا الاقتباس المفردتان لقيم البيانات).
  • مثال باستخدام قاموس في بايثون، وقيمة DateTime، وإفلات السلاسل
يؤدي ذلك إلى إنشاء الاستعلام التالي على الخادم:
  • مثال على تسلسل في بايثون (Tuple) وFloat64 وIPv4Address
ينتج عن ذلك الاستعلام التالي على الخادم:
يتطلب ربط وسيطات DateTime64 (أنواع ClickHouse ذات دقة أجزاء الثانية) إحدى طريقتين مخصصتين:
  • غلّف قيمة بايثون datetime.datetime داخل الفئة الجديدة DT64Param، على سبيل المثال:
    • إذا كنت تستخدم قاموسًا لقيم المعلمات، فألحِق السلسلة _64 باسم المعلمة

وسيطة Settings

تقبل جميع طُرق insert وselect الأساسية في ClickHouse Connect Client وسيطةً اختيارية باسم settings لتمرير إعدادات المستخدم الخاصة بخادم ClickHouse لعبارة SQL المضمَّنة. يجب أن تكون وسيطة settings قاموسًا. ويجب أن يتكوّن كل عنصر من اسم إعداد في ClickHouse والقيمة المرتبطة به. لاحظ أن القيم ستُحوَّل إلى سلاسل نصية عند إرسالها إلى الخادم كمعلمات استعلام. وكما هو الحال مع الإعدادات على مستوى العميل، سيتجاهل ClickHouse Connect أي إعدادات يضع الخادم عليها العلامة readonly=1، مع تسجيل رسالة في السجل بذلك. أما الإعدادات التي تنطبق فقط على الاستعلامات عبر ClickHouse HTTP interface فتكون صالحة دائمًا. وتجد وصف هذه الإعدادات ضمن واجهة برمجة تطبيقات get_client واجهة برمجة تطبيقات. مثال على استخدام إعدادات ClickHouse:

طريقة command في Client

استخدم الطريقة Client.command لإرسال استعلامات SQL إلى خادم ClickHouse التي لا تُرجِع عادةً بيانات، أو التي تُرجِع قيمة بدائية واحدة أو قيمة مصفوفة واحدة بدلًا من مجموعة بيانات كاملة. تأخذ هذه الطريقة المعلمات التالية:

أمثلة الأوامر

عبارات DDL

استعلامات بسيطة تُعيد قيماً مفردة

الأوامر ذات المعلمات

الأوامر ذات الإعدادات

طريقة query في Client

تُعد طريقة Client.query الوسيلة الأساسية لاسترجاع dataset واحدة على شكل “دفعة” من خادم ClickHouse. وهي تستخدم تنسيق ClickHouse الأصلي عبر HTTP لنقل مجموعات البيانات الكبيرة (حتى نحو مليون صف) بكفاءة. تقبل هذه الطريقة المعلمات التالية:

أمثلة على الاستعلامات

استعلام بسيط

الوصول إلى نتائج الاستعلام

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

استعلام باستخدام معلمات على جانب الخادم

الاستعلام مع الإعدادات

كائن QueryResult

تعيد طريقة query الأساسية كائن QueryResult بالخصائص العامة التالية:
  • result_rows — مصفوفة من البيانات المُعادة على هيئة Sequence من الصفوف، حيث يكون كل عنصر صف تسلسلاً من قيم الأعمدة.
  • result_columns — مصفوفة من البيانات المُعادة على هيئة Sequence من الأعمدة، حيث يكون كل عنصر عمود تسلسلاً من قيم الصفوف لذلك العمود
  • column_namestuple من السلاسل النصية يمثّل أسماء الأعمدة في result_set
  • column_typestuple من مثيلات ClickHouseType يمثّل نوع بيانات ClickHouse لكل عمود في result_columns
  • query_id — قيمة query_id الخاصة بـ ClickHouse (وهي مفيدة لفحص الاستعلام في جدول system.query_log)
  • summary — أي بيانات تُعيدها ترويسة استجابة HTTP ‏X-ClickHouse-Summary
  • first_item — خاصية تيسيرية لاسترجاع الصف الأول من الاستجابة على شكل قاموس (تكون المفاتيح فيه أسماء الأعمدة)
  • first_row — خاصية تيسيرية لإرجاع الصف الأول من النتيجة
  • column_block_stream — مولّد لنتائج الاستعلام بتنسيق موجّه بالأعمدة. لا ينبغي استخدام هذه الخاصية مباشرةً (انظر أدناه).
  • row_block_stream — مولّد لنتائج الاستعلام بتنسيق موجّه بالصفوف. لا ينبغي استخدام هذه الخاصية مباشرةً (انظر أدناه).
  • rows_stream — مولّد لنتائج الاستعلام يُرجع صفًا واحدًا في كل استدعاء. لا ينبغي استخدام هذه الخاصية مباشرةً (انظر أدناه).
  • summary — كما هو موضّح ضمن طريقة command، قاموس يحتوي على معلومات موجزة تُعيدها ClickHouse
تعيد الخصائص *_stream كائن Context في بايثون يمكن استخدامه كمكرّر للبيانات المُعادة. ويجب الوصول إليها فقط بشكل غير مباشر باستخدام طرق *_stream الخاصة بـ Client. ترد التفاصيل الكاملة لبثّ نتائج الاستعلام (باستخدام كائنات StreamContext) في الاستعلامات المتقدمة (الاستعلامات المتدفقة).

استهلاك نتائج الاستعلام باستخدام NumPy أو Pandas أو Arrow

يوفّر ClickHouse Connect طرق استعلام متخصصة لتنسيقات بيانات NumPy وPandas وArrow. للحصول على معلومات مفصلة حول استخدام هذه الطرق، بما في ذلك الأمثلة وإمكانات البث والتعامل المتقدم مع الأنواع، راجع الاستعلام المتقدم (استعلامات NumPy وPandas وArrow).

أساليب Client للاستعلامات المتدفقة

لبث مجموعات نتائج كبيرة، يوفّر ClickHouse Connect عدة أساليب للبث المتدفق. راجع الاستعلامات المتقدمة (الاستعلامات المتدفقة) للاطلاع على التفاصيل والأمثلة.

طريقة insert في Client

في حالة الاستخدام الشائعة المتمثلة في إدراج عدة سجلات في ClickHouse، تتوفر الطريقة Client.insert. وتقبل المعلمات التالية: تعيد هذه الطريقة قاموسًا يتضمن “ملخص query” كما هو موضح ضمن طريقة “command”. وسيُرفَع استثناء إذا فشل الإدراج لأي سبب. للاطلاع على طرق الإدراج المتخصصة التي تعمل مع Pandas DataFrames وPyArrow Tables وDataFrames المعتمدة على Arrow، راجع الإدراج المتقدم (طرق الإدراج المتخصصة).
تُعد مصفوفة NumPy أيضًا Sequence of Sequences صالحة، ويمكن استخدامها كوسيط data مع طريقة insert الأساسية، لذلك لا حاجة إلى طريقة متخصصة.

أمثلة

تفترض الأمثلة الواردة أدناه وجود جدول users مسبقًا، بمخطط (id UInt32, name String, age UInt8).

إدراج أساسي موجّه بالصفوف

إدراج موجّه بالأعمدة

إدراج باستخدام أنواع أعمدة صريحة

الإدراج في قاعدة بيانات محددة

الإدراج من الملفات

لإدراج البيانات مباشرةً من الملفات إلى جداول ClickHouse، راجع الإدراج المتقدم (الإدراج من الملفات).

واجهة برمجة التطبيقات الخام

للاطلاع على حالات الاستخدام المتقدمة التي تتطلب وصولًا مباشرًا إلى واجهات HTTP الخاصة بـ ClickHouse من دون تحويلات للأنواع، راجع الاستخدام المتقدم (واجهة برمجة التطبيقات الخام).

فئات ودوال الأدوات المساعدة

تُعد الفئات والدوال التالية أيضًا جزءًا من واجهة برمجة تطبيقات clickhouse-connect “العامة”، وهي، شأنها شأن الفئات والأساليب الموثقة أعلاه، مستقرة عبر الإصدارات الثانوية. ولن تطرأ تغييرات غير متوافقة مع الإصدارات السابقة على هذه الفئات والدوال إلا في إصدار ثانوي (وليس في إصدار تصحيح)، وستظل متاحة بحالة Deprecated لمدة إصدار ثانوي واحد على الأقل.

الاستثناءات

جميع الاستثناءات المخصّصة (بما في ذلك تلك المعرّفة في مواصفة DB API 2.0) معرّفة في الوحدة clickhouse_connect.driver.exceptions. وستكون الاستثناءات التي يكتشفها برنامج التشغيل فعليًا من أحد هذه الأنواع.

أدوات ClickHouse SQL

يمكن استخدام الدوال والفئة DT64Param في الوحدة clickhouse_connect.driver.binding لبناء استعلامات ClickHouse SQL وإفلاتها بشكل صحيح. وبالمثل، يمكن استخدام الدوال في الوحدة clickhouse_connect.driver.parser لتحليل أسماء أنواع بيانات ClickHouse.

حالات الاستخدام متعددة الخيوط، ومتعددة العمليات، وغير المتزامنة أو القائمة على الأحداث

للحصول على معلومات حول استخدام ClickHouse Connect في التطبيقات متعددة الخيوط، ومتعددة العمليات، وغير المتزامنة أو القائمة على الأحداث، راجع الاستخدام المتقدم (حالات الاستخدام متعددة الخيوط، ومتعددة العمليات، وغير المتزامنة أو القائمة على الأحداث).

مغلّف AsyncClient

للاطلاع على معلومات حول استخدام مغلّف AsyncClient في بيئات asyncio، راجع الاستخدام المتقدم (مغلّف AsyncClient).

إدارة معرّفات الجلسات في ClickHouse

للاطلاع على معلومات حول إدارة معرّفات جلسات ClickHouse في التطبيقات متعددة الخيوط أو المتزامنة، راجع الاستخدام المتقدم (إدارة معرّفات الجلسات في ClickHouse).

تخصيص مجمّع اتصالات HTTP

لمزيد من المعلومات حول تخصيص مجمّع اتصالات HTTP للتطبيقات الكبيرة متعددة الخيوط، راجع الاستخدام المتقدم (تخصيص مجمّع اتصالات HTTP).
آخر تعديل في ٢٥ يونيو ٢٠٢٦