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

تهيئة العميل

استخدم clickhouse_connect.get_client لإنشاء Client متزامن، أو ثبّت الإضافة async واستخدم await مع clickhouse_connect.get_async_client لإنشاء AsyncClient أصلي.

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

تقبل الدالة المُنشِئة غير المتزامنة أيضًا connector_limit=100 وconnector_limit_per_host=20 وkeepalive_timeout=30.0 لتهيئة مجمّع اتصالات aiohttp الخاص بها. ولا تقبل pool_mgr. تقبل الواجهة الخلفية المتزامنة لـ chDB أيضًا path وchdb_options؛ راجع الواجهة الخلفية المضمنة لـ chDB.

وسائط 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.

الواجهة الخلفية المضمّنة لـ chDB

ثبّت clickhouse-connect[chdb] لاستخدام الواجهة الخلفية التجريبية لـ chDB التي تعمل داخل العملية. وهي توفّر طرق العميل المتزامنة للاستعلام والإدراج والتدفّق وArrow:
الإعداد الافتراضي هو قاعدة بيانات داخل الذاكرة. مرِّر path="/data/my_chdb" أو استخدم dsn="chdb:///data/my_chdb" للتخزين الدائم. تسمح الواجهة الخلفية بمسار محرك واحد لكل عملية، ولا تدعم get_async_client أو البيانات الخارجية.

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

يُعَدّ إنشاء عميل 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>}. مرِّر القيم في قاموس بايثون. استخدم None في بايثون للقيم القابلة لأن تكون NULL. القيم المتداخلة None مدعومة داخل معاملات Array وTuple، وداخل القيم الحرفية Map عندما يُضبط dict_parameter_format على "map".
  • الربط من جهة الخادم باستخدام قاموس بايثون، وقيمة DateTime، وقيمة نصية
وهذا يكافئ:
الربط من جهة الخادم مدعوم في استعلامات SELECT فقط. ولا يعمل مع ALTER أو DELETE أو INSERT أو أي نوع آخر من العبارات.

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

يدعم ClickHouse Connect أيضًا ربط المعلمات من جهة العميل، ما يتيح مرونة أكبر عند إنشاء استعلامات SQL المعتمدة على القوالب. بالنسبة إلى الربط من جهة العميل، يجب أن تكون وسيطة parameters قاموسًا أو تسلسلًا. ويستخدم الربط من جهة العميل تنسيق السلاسل بأسلوب “printf” في بايثون لإجراء استبدال المعلمات. لاحظ أنه، بخلاف الربط من جهة الخادم، لا يعمل الربط من جهة العميل مع معرّفات قاعدة البيانات مثل أسماء قواعد البيانات أو الجداول أو الأعمدة، لأن التنسيق بأسلوب بايثون لا يستطيع التمييز بين الأنواع المختلفة من السلاسل، ولأنها تحتاج إلى تنسيق مختلف (backticks أو علامتا الاقتباس المزدوجتان لمعرّفات قاعدة البيانات، وعلامتا الاقتباس المفردتان لقيم البيانات).
  • مثال باستخدام قاموس بايثون، وقيمة DateTime، وإفلات السلاسل
يؤدي ذلك إلى إنشاء الاستعلام التالي على الخادم:
  • مثال على تسلسل في بايثون (Tuple) وFloat64 وIPv4Address
يؤدي ذلك إلى إنشاء الاستعلام التالي على الخادم:
يتعامل ربط Datetime مع القيم غير المزوّدة بمنطقة زمنية على أنها وقت الساعة. ينسّق العميل قيمة datetime غير المزوّدة بمنطقة زمنية حرفيًا. يفسّرها ClickHouse باستخدام المنطقة الزمنية المُعلنة في عنصر نائب من جهة الخادم مثل {dt:DateTime('Europe/Berlin')}، ثم session_timezone عند تعيينها، ثم المنطقة الزمنية للخادم. تُحوَّل قيمة datetime المراعية للمنطقة الزمنية إلى المنطقة الزمنية المُعلنة في العنصر النائب عند وجودها، وإلا فإلى المنطقة الزمنية للخادم المُبلّغ عنها عند الاتصال. إذا كان إعداد session_timezone يختلف عن المنطقة الزمنية للخادم المُبلّغ عنها، فأعلن منطقة زمنية في العنصر النائب للحفاظ على اللحظة المقصودة للقيم المراعية للمنطقة الزمنية.للتوافق المؤقت مع التحويل المحلي للمضيف الأقدم، عيّن common.set_setting("naive_datetime_binding", "legacy") قبل ربط المعلمات. وللحفاظ على لحظة زمنية، أرفق tzinfo المقصودة بقيمة datetime قبل تمريرها كمعلمة. تفسّر عمليات الإدراج عبر client.insert قيم datetime غير المزوّدة بمنطقة زمنية وفق المنطقة الزمنية المحلية للعملية افتراضيًا. عيّن إعداد naive_datetime_insert العام إلى "server" لتفسيرها كوقت الساعة في المنطقة الزمنية للعمود، أو في المنطقة الزمنية للخادم إذا لم تكن للعمود منطقة زمنية. راجع كائنات datetime غير المراعية للمنطقة الزمنية.بالنسبة إلى العنصر النائب {value:DateTime64(precision)} من جهة الخادم، يحافظ النوع المُعلن تلقائيًا على دقة أجزاء الثانية، بما في ذلك داخل تلميحات Array وTuple.لا يحتوي الربط من جهة العميل باستخدام %s على نوع مُعلن. غلّف قيمة datetime داخل DT64Param عندما يجب تنسيقها بدقة أجزاء الثانية:
ولأغراض التوافق مع الإصدارات السابقة، فإن اسم المعلمة في القاموس الذي ينتهي بـ _64 يطلب أيضًا تنسيق DateTime64 عندما لا يكون الاسم المنتهي بهذه اللاحقة موجودًا حرفيًا في الاستعلام.تُنسَّق معلمة datetime.time أو datetime.timedelta كقيمة حرفية [-]HH:MM:SS[.ffffff] لأعمدة ClickHouse Time وTime64، في أسلوبي الربط كليهما وداخل قيم Array وTuple. يضيف العميل علامتي الاقتباس، لذا لا تضع علامات اقتباس حول العنصر النائب في الاستعلام. قد تكون قيمة timedelta سالبة وقد تتجاوز 24 ساعة. تحتفظ قيمة Timedelta من pandas بالنانوثواني الخاصة بها وتُنسَّق بكسر من تسع خانات لـ Time64(9). تُتجاهل معلومات المنطقة الزمنية في قيمة time المراعية للمنطقة الزمنية لأن ClickHouse Time لا يحتوي على منطقة زمنية.

وسيطة 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 مع التعليمات التي لا تُرجِع مجموعة بيانات جدولية، أو مع الاستعلامات التي تُرجِع قيمة بدائية واحدة أو صفًا واحدًا. وبحسب الاستجابة، فإنها تُرجِع سلسلة نصية، أو عددًا صحيحًا، أو تسلسلًا من السلاسل النصية، أو QuerySummary. وتُرجِع عملية القراءة التي تنتج مجموعة نتائج فارغة سلسلةً نصية فارغة.

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

عبارات DDL

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

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

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

طريقة query في Client

تسترجع Client.query مجموعة بيانات جدولية بتنسيق ClickHouse Native وتُرجع QueryResult. تُحمَّل النتيجة الكاملة في الذاكرة عند الوصول إلى إحدى خصائص النتيجة. استخدم طريقة بث للنتائج التي لا ينبغي الاحتفاظ بها في الذاكرة.

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

استعلام بسيط

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

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

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

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

كائن QueryResult

تُرجِع طريقة query الأساسية كائن QueryResult بالخصائص العامة التالية:
  • result_rows — مصفوفة النتائج منظَّمة على شكل صفوف.
  • result_columns — مصفوفة النتائج منظَّمة على شكل أعمدة.
  • result_setresult_rows أو result_columns، بحسب اتجاه الاستعلام.
  • column_namesTuple يضم أسماء أعمدة النتائج.
  • column_typesTuple من كائنات ClickHouseType.
  • row_count — عدد صفوف النتائج المُخزَّنة فعليًا.
  • query_id — معرّف الاستعلام الذي تم الإبلاغ عنه أو إنشاؤه للطلب. وتعني السلسلة الفارغة عدم توفر أي معرّف.
  • summary — قاموس مفكوك الترميز من ترويسة الاستجابة X-ClickHouse-Summary.
  • first_item — الصف الأول على هيئة قاموس، أو None إذا كانت النتيجة فارغة.
  • first_row — الصف الأول على هيئة تسلسل، أو None إذا كانت النتيجة فارغة.
  • column_block_stream وrow_block_stream وrows_stream — سياقات تدفق داخلية. استخدم بدلًا من ذلك طرق البث المقابلة في العميل.
راجع الاستعلامات المتدفقة للتعرّف على واجهات برمجة التطبيقات StreamContext المدعومة.

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

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

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

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

طريقة insert في Client

في حالة الاستخدام الشائعة المتمثلة في إدراج عدة سجلات في ClickHouse، تتوفر الطريقة Client.insert. وتقبل المعلمات التالية: تعيد هذه الطريقة QuerySummary. ويحتوي قاموس summary الخاص بها على القيم التي يبلّغ عنها الخادم. وتمثل written_rows خاصيةً تيسيرية، بينما تعيد written_bytes() وquery_id() القيم المناظرة. ويؤدي فشل الإدراج إلى رفع استثناء. للاطلاع على طرق الإدراج المتخصصة التي تعمل مع Pandas DataFrames وPyArrow Tables وDataFrames المعتمدة على Arrow، راجع الإدراج المتقدم (طرق الإدراج المتخصصة).
تُعد مصفوفة NumPy أيضًا Sequence of Sequences صالحة، ويمكن استخدامها كوسيط data مع طريقة insert الأساسية، لذلك لا حاجة إلى طريقة متخصصة.

أمثلة

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

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

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

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

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

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

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

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

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

بايثون DB-API 2.0

تُنفِّذ وحدة clickhouse_connect.dbapi واجهة الاتصال والمُؤشِّر وفقًا للمعيار PEP 249. وهي تُعرِّف مستوى واجهة برمجة التطبيقات بأنه 2.0، وthreadsafety=2، وparamstyle="pyformat". وتوفّر الوحدة أيضًا مُنشئات الأنواع وفقًا للمعيار PEP 249، وهي Date وTime وTimestamp وBinary، والدوال DateFromTicks وTimeFromTicks وTimestampFromTicks.
يقبل كلٌّ من Cursor.execute وCursor.executemany وسيطتَي الكلمات المفتاحية الإضافيتين settings وquery_formats. تمرّر settings إعدادات ClickHouse. وتطبّق query_formats تنسيقات القراءة حسب نوع ClickHouse عندما تُرجع العبارة صفوفًا، باستخدام التعيين نفسه المستخدم في Client.query. ويستخدم executemany مسار الإدراج المجمّع Native الخاص ببرنامج التشغيل لعبارات INSERT ... VALUES المتوافقة مع تسلسل صفوف مُجسَّد. وتستهلك fetchone وfetchmany وfetchall النتيجة المُجسَّدة الحالية. يستمدّ Cursor.description القيمة null_ok من نوع كل عمود في النتيجة. وتُرجع الأنواع غير القابلة للقيم الفارغة False، بينما تُرجع الأنواع القابلة للقيم الفارغة True، بما في ذلك أغلفة Nullable وVariant وDynamic. وتعني None أن قابلية القيم الفارغة غير معروفة. عندما لا يُرجع استعلام يبدأ بـ SELECT أو WITH، مع تجاهل التعليقات البادئة، أي صفوف أو بيانات وصفية للأعمدة، يشغّل المؤشّر استعلام بيانات وصفية بـ LIMIT 0 لملء description. وإذا فشل استعلام البيانات الوصفية هذا، يُترك description فارغًا. لا يوفّر ClickHouse معاملات تقليدية عبر واجهة HTTP هذه. وتُعدّ Connection.commit() وConnection.rollback() عمليتَي no-op. ولا تزال قواعد تزامن معرّف الجلسة تنطبق عند مشاركة الاتصال.

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

توفر الوحدات التالية أدوات مساعدة عامة إضافية تستخدمها التطبيقات العميلة. يُعرض إصدار الحزمة المثبتة في السلسلة clickhouse_connect.__version__.

الاستثناءات

تُعرَّف الاستثناءات المخصّصة، بما في ذلك التسلسل الهرمي للاستثناءات في DB-API 2.0، في clickhouse_connect.driver.exceptions. ويوفّر كلٌّ من DatabaseError وOperationalError السمة الرقمية code التي تحمل رمز الخطأ في ClickHouse، والسمة name التي تحمل الاسم الرمزي مثل UNKNOWN_TABLE، بحيث يمكن للتطبيقات التفريع بناءً على exc.code بدلًا من تحليل الرسالة. تُضبط code حتى عند تعطيل show_clickhouse_errors، بينما تتطلب name تفاصيل الخطأ (True أو "scrub"). وتكون كلتاهما None عند عدم توفرهما، كما في أخطاء النقل. استخدم show_clickhouse_errors="scrub" عندما ينبغي للمستخدمين النهائيين رؤية أخطاء SQL دون معلومات عن المضيف أو إصدار الخادم. يتحكم الإعداد أيضًا في رسائل StreamFailureError أثناء التدفق ورسائل النقل العامة. وهو يتحكم في str(exc) فقط. تظل أخطاء النقل مرفقة باعتبارها __cause__، ويمكن أن تحتوي آثار التتبع على نص الخطأ الأصلي للمضيف أو URL أو المكتبة.

أدوات ClickHouse SQL

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

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

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

AsyncClient

للاطلاع على الاستخدام الأصلي لـ asyncio، راجع الاستخدام المتقدم (AsyncClient).

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

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

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

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