Skip to main content

الوصف

pg_clickhouse هو امتداد لـ PostgreSQL يتيح تنفيذ الاستعلامات عن بُعد على قواعد بيانات ClickHouse، بما في ذلك [مغلف البيانات الخارجية]. وهو يدعم PostgreSQL 13 والإصدارات الأحدث وClickHouse 23.3 والإصدارات الأحدث.

البدء

أبسط طريقة لتجربة pg_clickhouse هي استخدام [صورة Docker]، والتي تتضمن صورة Docker القياسية لـ PostgreSQL، إلى جانب امتدادي pg_clickhouse وre2:
راجع الدليل التعليمي لبدء استيراد جداول ClickHouse ودفع تنفيذ الاستعلامات إلى المصدر.

الاستخدام

سياسة الإصدارات

يلتزم pg_clickhouse بـ[الإصدار الدلالي] في إصداراته العامة.
  • يُزاد الرقم الرئيسي للإصدار عند إجراء تغييرات على API
  • يُزاد الرقم الثانوي للإصدار عند إجراء تغييرات SQL المتوافقة مع الإصدارات السابقة
  • يُزاد رقم التصحيح عند إجراء تغييرات تقتصر على الملف التنفيذي
بعد التثبيت، يتتبّع PostgreSQL شكلين من أرقام الإصدار:
  • إصدار المكتبة (المعرّف بواسطة PG_MODULE_MAGIC في PostgreSQL 18 والإصدارات الأحدث) يتضمن الإصدار الدلالي الكامل، ويظهر في مخرجات الدالة pgch_version() أو دالة Postgres pg_get_loaded_modules().
  • إصدار الامتداد (المعرّف في ملف التحكم) يتضمن فقط الرقمين الرئيسي والثانوي، ويظهر في الجدول pg_catalog.pg_extension، وفي مخرجات الدالة pg_available_extension_versions()، وفي \dx pg_clickhouse.
عمليًا، يعني ذلك أن الإصدار الذي يزيد رقم التصحيح، على سبيل المثال من v0.1.0 إلى v0.1.1، يفيد جميع قواعد البيانات التي حمّلت v0.1، ولا تحتاج إلى تشغيل ALTER EXTENSION للاستفادة من الترقية. أما الإصدار الذي يزيد الرقم الثانوي أو الرئيسي، فسيكون مصحوبًا بسكربتات ترقية SQL، ويجب على جميع قواعد البيانات الحالية التي تحتوي على الامتداد تشغيل ALTER EXTENSION pg_clickhouse UPDATE للاستفادة من الترقية.

مرجع DDL في SQL

تستخدم تعبيرات DDL التالية في SQL الامتداد pg_clickhouse.

CREATE EXTENSION

استخدم CREATE EXTENSION لإضافة pg_clickhouse إلى إحدى قواعد البيانات:
استخدم WITH SCHEMA لتثبيته في مخطط محدد (يوصى به):

ALTER EXTENSION

استخدم ALTER EXTENSION لتعديل pg_clickhouse. أمثلة:
  • بعد تثبيت إصدار جديد من pg_clickhouse، استخدم العبارة UPDATE:
  • استخدم SET SCHEMA لنقل الامتداد إلى مخطط جديد:

DROP EXTENSION

استخدم DROP EXTENSION لحذف pg_clickhouse من قاعدة بيانات:
يفشل هذا الأمر إذا كانت هناك أي كائنات تعتمد على pg_clickhouse. استخدم عبارة CASCADE لحذفها أيضًا:

CREATE SERVER

استخدم CREATE SERVER لإنشاء خادم خارجي يتصل بخادم ClickHouse. مثال:
الخيارات المدعومة هي:
  • driver: مشغّل اتصال ClickHouse المراد استخدامه، إما “binary” أو “http”. مطلوب.
  • compression: ضغط البروتوكول الأصلي لمشغّل “binary”، ويكون إحدى القيم “none” أو “lz4” أو “zstd”. القيمة الافتراضية هي “lz4”. ويتجاهله مشغّل “http”.
  • dbname: قاعدة بيانات ClickHouse التي ستُستخدم عند الاتصال. القيمة الافتراضية هي “default”.
  • host: اسم مضيف خادم ClickHouse. القيمة الافتراضية هي “localhost”;
  • port: المنفذ المطلوب الاتصال به على خادم ClickHouse. تكون القيم الافتراضية كما يلي:
    • 9440 إذا كان driver هو “binary” وكان host مضيف ClickHouse Cloud
    • 9004 إذا كان driver هو “binary” ولم يكن host مضيف ClickHouse Cloud
    • 8443 إذا كان driver هو “http” وكان host مضيف ClickHouse Cloud
    • 8123 إذا كان driver هو “http” ولم يكن host مضيف ClickHouse Cloud
  • min_tls_version: الحد الأدنى لإصدار بروتوكول TLS الذي يجب التفاوض عليه في الاتصالات التي تستخدم TLS. إحدى القيم TLSv1 أو TLSv1.1 أو TLSv1.2 أو TLSv1.3. القيمة الافتراضية هي الحد الأدنى الذي تعتمده مكتبة TLS نفسها. وينطبق ذلك على كلا المشغّلين.
  • secure: يحدّد استخدام TLS للاتصال. إحدى القيم التالية:
    • auto (الافتراضي): استخدم TLS عندما يكون host مضيف ClickHouse Cloud أو يكون port منفذًا آمنًا؛ وإلا فاستخدم اتصالًا غير مشفّر.
    • on (أو true/yes/1): استخدم TLS دائمًا. وتكون القيمة الافتراضية لـ port هي 8443 (“http”) أو 9440 (“binary”).
    • off (أو false/no/0): لا تستخدم TLS مطلقًا. وتكون القيمة الافتراضية لـ port هي 8123 (“http”) أو 9000 (“binary”).

ALTER SERVER

استخدم ALTER SERVER لتغيير خادم خارجي. مثال:
الخيارات هي نفسها المذكورة في CREATE SERVER.

DROP SERVER

استخدم DROP SERVER لإزالة خادم خارجي:
يفشل هذا الأمر إذا كانت هناك كائنات أخرى تعتمد على الخادم. استخدم CASCADE لكي تُسقِط هذه التبعيات أيضًا:

CREATE USER MAPPING

استخدم CREATE USER MAPPING لربط مستخدم في PostgreSQL بمستخدم في ClickHouse. على سبيل المثال، لربط مستخدم PostgreSQL الحالي بمستخدم ClickHouse البعيد عند الاتصال بـ خادم خارجي ‏taxi_srv:
الخيارات المدعومة هي:
  • user: اسم مستخدم ClickHouse. والقيمة الافتراضية هي “default”.
  • password: كلمة مرور مستخدم ClickHouse.

ALTER USER MAPPING

استخدم ALTER USER MAPPING لتغيير تعريف تعيين المستخدم:
الخيارات مماثلة لتلك الواردة في CREATE USER MAPPING.

DROP USER MAPPING

استخدم DROP USER MAPPING لحذف تعيين مستخدم:

IMPORT FOREIGN SCHEMA

استخدم IMPORT FOREIGN SCHEMA لاستيراد جميع الجداول المعرَّفة في قاعدة بيانات ClickHouse كجداول خارجية إلى مخطط PostgreSQL:
استخدم LIMIT TO لحصر الاستيراد في جداول محددة:
استخدم EXCEPT لاستثناء الجداول:
سيقوم pg_clickhouse بجلب قائمة بجميع الجداول في قاعدة بيانات ClickHouse المحددة (‘demo’ في الأمثلة أعلاه)، ثم يجلب تعريفات الأعمدة لكل جدول، وينفّذ أوامر CREATE FOREIGN TABLE لإنشاء الجداول الخارجية. ستُعرَّف الأعمدة باستخدام أنواع البيانات المدعومة، وكذلك الخيارات التي يدعمها CREATE FOREIGN TABLE متى أمكن اكتشافها.
الحفاظ على حالة الأحرف في المعرّفات المستوردةيشغّل IMPORT FOREIGN SCHEMA الدالة quote_identifier() على أسماء الجداول والأعمدة التي يستوردها، ما يضع المعرّفات بين علامتَي اقتباس مزدوجتَين إذا كانت تحتوي على أحرف كبيرة أو مسافات. لذلك يجب وضع أسماء هذه الجداول والأعمدة بين علامتَي اقتباس مزدوجتَين في استعلامات PostgreSQL. أمّا الأسماء المكتوبة كلها بأحرف صغيرة والتي لا تحتوي على مسافات، فلا تحتاج إلى وضعها بين علامتَي اقتباس.على سبيل المثال، بالنظر إلى جدول ClickHouse التالي:
ينشئ IMPORT FOREIGN SCHEMA الجدول الخارجي التالي:
لذلك يجب أن تستخدم الاستعلامات علامات الاقتباس على النحو المناسب، مثل:
لإنشاء كائنات بأسماء مختلفة أو بأسماء كلها أحرف صغيرة (وبالتالي غير حساسة لحالة الأحرف)، استخدم CREATE FOREIGN TABLE.

CREATE FOREIGN TABLE

استخدم CREATE FOREIGN TABLE لإنشاء جدول خارجي يتيح الاستعلام عن البيانات من قاعدة بيانات ClickHouse:
خيارات الجدول المدعومة هي:
  • database: اسم قاعدة البيانات البعيدة. تكون القيمة الافتراضية هي قاعدة البيانات المعرّفة للخادم الخارجي.
  • table_name: اسم الجدول البعيد. تكون القيمة الافتراضية هي الاسم المحدد للجدول الخارجي.
  • engine: [محرك الجدول] المستخدم في جدول ClickHouse. بالنسبة إلى CollapsingMergeTree() وAggregatingMergeTree()، يطبّق pg_clickhouse المعلمات تلقائيًا على تعبيرات الدوال التي تُنفَّذ على الجدول.
استخدم نوع البيانات المناسب لنوع بيانات ClickHouse البعيد لكل عمود. خيارات الأعمدة المدعومة هي:
  • column_name: اسم العمود على جهة ClickHouse، ويُستخدم بدلًا من اسم السمة في PostgreSQL عند إعادة توليد الاستعلامات و عمليات الإدراج. وهو مفيد لربط أسماء أعمدة PostgreSQL المكتوبة بأحرف صغيرة وغير الموضوعة بين علامتَي اقتباس بأعمدة ClickHouse الحساسة لحالة الأحرف، على سبيل المثال:
  • AggregateFunction: اسم الدالة التجميعية المطبَّقة على عمود من [نوع AggregateFunction]. اربط نوع البيانات بنوع ClickHouse المُمرَّر إلى الدالة، وحدد اسم الدالة التجميعية عبر خيار العمود المناسب، وسيضيف pg_clickhouse تلقائيًا Merge إلى الدالة التجميعية التي تقيّم العمود.
  • SimpleAggregateFunction: اسم الدالة التجميعية المطبَّقة على عمود من [نوع SimpleAggregateFunction]. اربط نوع البيانات بنوع ClickHouse المُمرَّر إلى الدالة، وحدد اسم الدالة التجميعية عبر خيار العمود المناسب.

ALTER FOREIGN TABLE

استخدم ALTER FOREIGN TABLE لتغيير تعريف جدول خارجي:
خيارات الجدول والعمود المدعومة هي نفسها الواردة في CREATE FOREIGN TABLE.

DROP FOREIGN TABLE

استخدم DROP FOREIGN TABLE لإزالة جدول خارجي:
يفشل هذا الأمر إذا وُجدت أي كائنات تعتمد على الجدول الخارجي. استخدم عبارة CASCADE لحذفها أيضًا:

مرجع SQL لـ DML

قد تستخدم تعبيرات SQL DML الواردة أدناه pg_clickhouse. وتعتمد الأمثلة على جداول ClickHouse التالية:

EXPLAIN

يعمل الأمر EXPLAIN كما هو متوقع، لكن الخيار VERBOSE يؤدي إلى إظهار استعلام ClickHouse “Remote SQL”:
يُنفَّذ هذا الاستعلام على ClickHouse مباشرةً عبر عقدة خطة باسم “Foreign Scan”، باستخدام SQL البعيد.

SELECT

استخدم عبارة SELECT لتنفيذ الاستعلامات على جداول pg_clickhouse، تمامًا كما تفعل مع أي جداول أخرى:
يعمل pg_clickhouse على ترحيل تنفيذ الاستعلام إلى ClickHouse قدر الإمكان، بما في ذلك الدوال التجميعية. استخدم EXPLAIN لتحديد مدى هذا الترحيل. فعلى سبيل المثال، في الاستعلام أعلاه، يُرحَّل التنفيذ بالكامل إلى ClickHouse
يقوم pg_clickhouse أيضًا بتنفيذ عمليات JOIN على الجداول الموجودة على الخادم البعيد نفسه:
سيؤدي الربط بجدول محلي إلى إنشاء استعلامات أقل كفاءة ما لم يُجرَ ضبطه بعناية. في هذا المثال، ننشئ نسخة محلية من الجدول nodes ونربط بها بدلًا من الجدول البعيد:
في هذه الحالة، يمكننا دفع مزيد من عمليات التجميع إلى ClickHouse عبر التجميع حسب node_id بدلًا من العمود المحلي، ثم الربط بجدول البحث لاحقًا:
تقوم عقدة “Foreign Scan” الآن بتمرير التجميع حسب node_id إلى النظام البعيد، مما يقلّل عدد الصفوف التي يجب سحبها مرة أخرى إلى Postgres من 1000 (كلّها) إلى 8 فقط، صف واحد لكل عقدة.

الجداول المُقسَّمة

يمكن أن يضم [جدول مُقسَّم] في PostgreSQL أقسامًا محلية وأخرى خارجية تستند إلى ClickHouse. ومن الأنماط الشائعة نقل البيانات الأقدم إلى ClickHouse، مع إبقاء البيانات الأحدث في PostgreSQL:
للاطلاع على مثال يوضح كيفية نقل البيانات من التقسيمات المحلية إلى التقسيمات الخارجية، راجع offload-partition.sql. تتطلب عمليات التجميع عبر التقسيمات المحلية والخارجية [التجميع حسب التقسيم]، وهو معطّل افتراضيًا في PostgreSQL:
عند تمكين enable_partitionwise_aggregate، ينفّذ PostgreSQL تجميعًا جزئيًا أسفل Append، ثم تدمج عملية التجميع النهائي أعلاه هذه النتائج الجزئية في نتيجة واحدة. ويدفع pg_clickhouse التجميع الجزئي للقسم الأجنبي إلى ClickHouse:

متى يُدفَع التجميع الجزئي إلى المصدر

يمثّل PostgreSQL التجميع الجزئي بوصفه حالة انتقالية تجمعها خطوة الإنهاء عبر الأقسام. لا يستطيع pg_clickhouse دفع التجميع الجزئي لقسم ما إلى المصدر إلا إذا أمكن تمثيله كقيمة في ClickHouse:
  • دوال التجميع القابلة للتفكيك التي تكون حالتها الانتقالية هي القيمة النهائية بالفعل، تُدفَع مباشرةً إلى المصدر: count وsum وmin وmax وbool_and/every وbool_or وbit_and وbit_or وbit_xor.
  • تُدفَع avg على الأعداد الصحيحة إلى المصدر بحالتها {count, sum} على شكل مصفوفة.
  • تُدفَع avg وvar_pop وvar_samp وstddev_pop وstddev_samp على الأعداد ذات الفاصلة العائمة إلى المصدر بحالتها {N, sum, sum of squared deviations} على شكل مصفوفة.
يُدفَع FILTER (WHERE …) إلى المصدر مع دوال التجميع هذه.

الحالات التي تلجأ فيها إلى البديل

لا يتوفر للتجميعات التي تكون حالة انتقالها من نوع PostgreSQL المعتم internal تمثيل قابل للنقل، لذا يجلب القسم الخارجي صفوفها ويجمعها محليًا بدلًا من ذلك. يشمل ذلك كل ما يتعلق بـ numeric، إضافةً إلى avg(bigint) وavg(interval). كما تلجأ تجميعات DISTINCT وتجميعات المجموعات المرتبة والتجميعات متغيرة الوسائط إلى البديل.

PREPARE, EXECUTE, DEALLOCATE

اعتبارًا من الإصدار v0.1.2، يدعم pg_clickhouse الاستعلامات المعلَّمة بمعلمات، ويُنشأ معظمها باستخدام الأمر PREPARE:
استخدم EXECUTE كالمعتاد لتنفيذ عبارة مُحضَّرة:
يمنع التنفيذ المعلَّم http driver من تحويل المناطق الزمنية لنوع DateTime بشكل صحيح في إصدارات ClickHouse الأقدم من 25.8، حيث [أُصلِح الخلل الأساسي] [هناك]. لاحظ أن PostgreSQL قد يستخدم أحيانًا خطة query معلَّمة حتى من دون استخدام PREPARE. بالنسبة إلى أي query تتطلب تحويلًا دقيقًا للمنطقة الزمنية، وعندما لا يكون من الممكن الترقية إلى 25.8 أو إصدار أحدث، فاستخدم binary driver بدلًا من ذلك.
يقوم pg_clickhouse، كالمعتاد، بتمرير aggregations إلى النظام البعيد، كما يظهر في مخرجات EXPLAIN verbose:
لاحظ أنه أرسل قيم التاريخ الكاملة، وليس العناصر النائبة للمعلمات. وينطبق ذلك على الطلبات الخمسة الأولى، كما هو موضح في [ملاحظات PREPARE في PostgreSQL]. وعند التنفيذ السادس، يرسل ClickHouse [معلمات الاستعلام] بالنمط {param:type}: المعلمات:
استخدم DEALLOCATE لإلغاء تخصيص تعليمة مُعَدّة:

INSERT

استخدم الأمر INSERT لإدراج القيم في جدول ClickHouse موجود على خادم بعيد:

COPY

استخدم الأمر COPY لإدراج دفعة من الصفوف في جدول ClickHouse على خادم بعيد:
⚠️ قيود Batch API لم يوفّر pg_clickhouse بعد دعم واجهة insert الدُفعية الخاصة بـ PostgreSQL FDW. لذلك يستخدم COPY حاليًا عبارات INSERT من أجل إدراج السجلات. وسيُحسَّن ذلك في إصدار مستقبلي.

LOAD

استخدم LOAD لتحميل المكتبة المشتركة pg_clickhouse:
لا تكون هناك حاجة عادةً إلى استخدام LOAD، لأن Postgres سيحمّل pg_clickhouse تلقائيًا عند استخدام أيٍ من وظائفه (الدوال، والجداول الخارجية، وما إلى ذلك) للمرة الأولى. الحالة الوحيدة التي قد يكون فيها LOAD‏ pg_clickhouse مفيدًا هي عند SET معلمات pg_clickhouse قبل تنفيذ الاستعلامات التي تعتمد عليها.

SET

استخدم SET لتعيين معلمات الإعداد المخصّصة لـ pg_clickhouse.

pg_clickhouse.session_settings

تُستخدم المعلمة pg_clickhouse.session_settings لتحديد [إعدادات ClickHouse] التي ستُطبَّق على الاستعلامات اللاحقة. مثال:
القيمة الافتراضية هي
عيّنه إلى سلسلة فارغة للعودة إلى إعدادات خادم ClickHouse — لكن لاحظ أن صحة تمرير إلى النظام البعيد تعتمد على بعض هذه الإعدادات الافتراضية: join_use_nulls لعمليات الربط الخارجي وtransform_null_in لفئة IN (راجع دلالات IN وNULL).
البنية هي قائمة مفصولة بفواصل من أزواج المفتاح/القيمة، تفصل بينها مسافة واحدة أو أكثر. يجب أن تتوافق المفاتيح مع [إعدادات ClickHouse]. استخدم الشرطة المائلة العكسية قبل المسافات، والفواصل، والشرطات المائلة العكسية في القيم:
أو استخدم قيَمًا محاطة بعلامات اقتباس مفردة لتجنّب الحاجة إلى استخدام محارف الهروب للمسافات والفواصل؛ وفكّر في استخدام [الاقتباس بالدولار] لتجنّب الحاجة إلى وضع علامات اقتباس مزدوجة:
إذا كنت تهتم بوضوح النص وتحتاج إلى تعيين الكثير من الإعدادات، فاستخدم عدة أسطر، على سبيل المثال:
سيتم تجاهل بعض الإعدادات في الحالات التي قد تتداخل فيها مع عمل pg_clickhouse نفسه. وتشمل ما يلي:
  • date_time_output_format: يتطلب http driver أن تكون قيمته “iso”
  • format_tsv_null_representation: يتطلب http driver القيمة الافتراضية
  • output_format_tsv_crlf_end_of_line يتطلب http driver القيمة الافتراضية
بخلاف ذلك، لا يتحقق pg_clickhouse من صحة الإعدادات، بل يمررها إلى ClickHouse مع كل استعلام. وبالتالي فهو يدعم جميع الإعدادات لكل إصدار من ClickHouse. لاحظ أنه يجب تحميل pg_clickhouse قبل تعيين pg_clickhouse.session_settings؛ إما باستخدام [التحميل المسبق للمكتبة المشتركة] أو ببساطة باستخدام أحد الكائنات في الامتداد لضمان تحميله.

pg_clickhouse.pushdown_regex

تتحكم المعلمة pg_clickhouse.pushdown_regex في ما إذا كان pg_clickhouse يقوم بتمرير دوال التعبيرات النمطية والعوامل إلى النظام البعيد. ويحدث ذلك افتراضيًا؛ اضبط هذه المعلمة على false لمنع تمريرها إلى النظام البعيد:
راجع التعبيرات النمطية لمزيد من التفاصيل.

ALTER ROLE

استخدم الأمر SET في ALTER ROLE لإجراء التحميل المسبق لـ pg_clickhouse و/أو SET معلماته لأدوار محددة:
استخدم الأمر RESET في ALTER ROLE لإعادة ضبط التحميل المسبق لـ pg_clickhouse و/أو المعلمات:

التحميل المسبق

إذا كان كل اتصال بـPostgres أو يكاد كل اتصال يحتاج إلى استخدام pg_clickhouse، ففكّر في استخدام [التحميل المسبق للمكتبات المشتركة] لتحميله تلقائيًا:

session_preload_libraries

يُحمِّل المكتبة المشتركة مع كل اتصال جديد بـ PostgreSQL:
يفيد ذلك في الاستفادة من التحديثات دون إعادة تشغيل الخادم: ما عليك سوى إعادة الاتصال. ويمكن أيضًا ضبطه لمستخدمين أو أدوار محددة عبر ALTER ROLE.

shared_preload_libraries

يحمّل المكتبة المشتركة إلى العملية الرئيسية لـ PostgreSQL عند بدء التشغيل:
مفيد لتوفير الذاكرة وتقليل العبء الإضافي لكل جلسة، لكنه يتطلب إعادة تشغيل الكتلة عند تحديث المكتبة.

أنواع البيانات

يربط pg_clickhouse أنواع بيانات ClickHouse التالية بأنواع بيانات PostgreSQL. يستخدم IMPORT FOREIGN SCHEMA النوع الأول في عمود PostgreSQL عند استيراد الأعمدة؛ ويمكن استخدام أنواع إضافية في تعليمات CREATE FOREIGN TABLE: يمكن أيضاً قراءة أي عمود كنوع text أو varchar أو أي نوع سلسلة آخر. تأخذ القيمة نوع PostgreSQL المذكور أعلاه، ثم تُعرَض عبر دالة الإخراج الخاصة بذلك النوع. تظل قيم UInt64 التي تتجاوز الحد الأقصى لـ bigint تُنتج خطأً، لذا اعرضها باستخدام دالة ClickHouse toString(). ترد أدناه ملاحظات وتفاصيل إضافية.

BYTEA

لا يوفر ClickHouse ما يعادل النوع BYTEA في PostgreSQL، غير أنه يتيح تخزين أي بايتات في النوع String. بوجه عام، ينبغي ربط سلاسل ClickHouse بالنوع TEXT في PostgreSQL، أما عند استخدام البيانات الثنائية فيُربط بالنوع BYTEA. مثال:
سيُخرج استعلام SELECT الأخير:
تجدر الإشارة إلى أنه في حال وجود أي بايتات فارغة (nul) في أعمدة ClickHouse، فلن يُخرج الجدول الأجنبي الذي يستخدم أعمدة TEXT القيم الصحيحة:
سيُخرج:
لاحظ أن الصفين الثاني والثالث يحتويان على قيم مبتورة. ويعود ذلك إلى أن PostgreSQL يعتمد على السلاسل المنتهية بـ nul ولا يدعم أحرف nul داخل سلاسله. ستنجح محاولة إدراج القيم الثنائية في أعمدة TEXT وتعمل كما هو متوقع:
ستكون أعمدة النص صحيحة:
لكن قراءتها على أنها BYTEA لن تنجح:
كقاعدة عامة، استخدم أعمدة TEXT فقط للسلاسل المشفّرة، واستخدم أعمدة BYTEA فقط للبيانات الثنائية، ولا تبدّل بينهما أبدًا.

مرجع الدوال والعوامل

الدوال

توفّر هذه الدوال واجهةً للاستعلام عن قاعدة بيانات ClickHouse.

clickhouse_raw_query

متوقفة: تُصدر clickhouse_raw_query() تحذيرًا بأنها متوقفة وسيجري إزالتها في الإصدار التالي. استخدم clickhouse_query لقراءة الصفوف وclickhouse_perform لتنفيذ العبارات التي لا تُرجع شيئًا. تعيد كلتاهما استخدام برنامج التشغيل وبيانات الاعتماد وقاعدة البيانات وذاكرة التخزين المؤقت للاتصالات الخاصة بالخادم المُهيأ بدلًا من سلسلة اتصال مخصصة.
اتصل بخدمة ClickHouse، ونفّذ استعلامًا واحدًا ثم افصل الاتصال. يحدّد الوسيط الاختياري الثاني سلسلة اتصال تكون قيمتها الافتراضية host=localhost port=8123. معاملات الاتصال المدعومة هي:
  • driver: برنامج تشغيل الاتصال المراد استخدامه، إما “http” أو “binary”؛ والقيمة الافتراضية هي “http”
  • host: المضيف المراد الاتصال به؛ مطلوب.
  • port: المنفذ المراد الاتصال به. القيمة الافتراضية هي 8123 لبرنامج التشغيل “http” أو 9000 لبرنامج التشغيل “binary”، وتتغير إلى 8443 أو 9440 على التوالي عندما يكون host مضيف ClickHouse Cloud
  • dbname: اسم قاعدة البيانات المراد الاتصال بها.
  • username: اسم المستخدم الذي سيتم الاتصال باسمه؛ القيمة الافتراضية default
  • password: كلمة المرور المستخدمة للمصادقة؛ والقيمة الافتراضية هي عدم استخدام كلمة مرور
يعيد كلا برنامجي التشغيل صفوفًا مفصولة بعلامات الجدولة (مع تمثيل القيم الخالية كـ \N)، لكن تختلف طريقة تمثيل كل قيمة: يعيد برنامج التشغيل “http” تنسيق TSV الخاص بـ ClickHouse حرفيًا، بينما يمرر برنامج التشغيل “binary” كل قيمة عبر دالة الإخراج في PostgreSQL. بشكل افتراضي، لا يملك أي دور صلاحية EXECUTE لهذه الدالة؛ لذا احرص على GRANT صلاحية الوصول فقط للأدوار التي تحتاج فعليًا إلى تنفيذ استعلامات ClickHouse مخصّصة، مثل دور Admin مخصّص في ClickHouse: وهي مفيدة للاستعلامات التي لا تُرجع أي سجلات، لكن الاستعلامات التي تُرجع قيمًا ستُعاد على هيئة قيمة نصية واحدة:

clickhouse_server_version

أبلِغ عن إصدار خادم ClickHouse، بصيغة major.minor.patch، للخادم الخارجي المُسمّى، مع الاتصال به عند الضرورة باستخدام خيارات الخادم وتعيين المستخدم الخاص بالمستخدم الحالي:
يقرأ الإصدار من مصافحة الاتصال عبر البروتوكول الأصلي، أو عبر HTTP باستخدام استعلام واحد هو SELECT version()، ويخزّنه مؤقتًا طوال مدة الاتصال.

clickhouse_query

نفّذ استعلامًا على خادم خارجي مُهيّأ مسبقًا وأعِد صفوفه في صورة علاقة، مع تعيين كل عمود في نتائج ClickHouse إلى نوع PostgreSQL المسمّى في قائمة تعريف الأعمدة. ويُعاد استخدام driver الخاص بالخادم، وبيانات الاعتماد وقاعدة البيانات وذاكرة التخزين المؤقت للاتصال. الوسيط الأول هو اسم خادم أُنشئ باستخدام CREATE SERVER. يجب توفير قائمة تعريف أعمدة (AS name(col type, ...)): يحتاج PostgreSQL إلى معرفة بنية النتيجة قبل جلب الصفوف، ويجب أن تطابق الأعمدة التي يعيدها الاستعلام. تُحوَّل القيم من ClickHouse إلى الأنواع المعلنة بالطريقة نفسها التي يُحوَّل بها عمود في جدول أجنبي. أما العبارات التي لا تعيد نتائج، مثل DDL، فلا تتطلب تعريفًا؛ نفّذها باستخدام clickhouse_perform بدلًا من ذلك. لا يملك أي دور صلاحية EXECUTE افتراضيًا؛ استخدم GRANT لمنح دور إمكانية استخدام الدالة.

clickhouse_perform

نفّذ عبارةً على خادم خارجي مُهيّأ مسبقًا وتجاهل أي نتيجة. استخدمها للعبارات التي لا تُرجع صفوفًا، مثل DDL، حيث لا يملك clickhouse_query شكل نتيجة ليُصرَّح عنه. وتحدّد الخادم بالطريقة نفسها التي يستخدمها clickhouse_query، مع إعادة استخدام driver، وبيانات الاعتماد، وقاعدة البيانات، وذاكرة التخزين المؤقت للاتصال. وبوصفها إجراءً، يجب استدعاؤها باستخدام CALL، وليس SELECT، ولا تُرجع صفوفًا. لا يملك أي دور صلاحية EXECUTE افتراضيًا؛ استخدم GRANT لمنح دورٍ ما صلاحية استخدام الإجراء.

دوال Pushdown

يقوم pg_clickhouse بتمرير مجموعة فرعية من دوال PostgreSQL المضمّنة المستخدمة في الشروط (البندين HAVING وWHERE). وتتوافق هذه المجموعة الفرعية مع مكافئاتها في ClickHouse كما يلي:

معاملات Pushdown

  • شريحة Array (arr[L:U]): arraySlice
  • @> (تحتوي المصفوفة على): hasAll
  • <@ (المصفوفة محتواة في): hasAll
  • && (تداخل المصفوفات): hasAny
  • ~ (مطابقة تعبير نمطي): match
  • !~ (عدم مطابقة تعبير نمطي): match
  • ~* (عدم مطابقة تعبير نمطي دون مراعاة حالة الأحرف): match
  • !~* (عدم مطابقة تعبير نمطي دون مراعاة حالة الأحرف): match
  • ->> (استخراج عنصر من JSON/JSONB كنص): sub-column syntax
  • -> (استخراج من JSON/JSONB): toJSONString + sub-column syntax

دلالات IN وNULL

يقيّم ClickHouse التعبير IN وفق منطق ثنائي القيم: فعندما لا يجد الفحص تطابقاً، يعيد 0 حتى عند وجود NULL، بينما يحسب PostgreSQL NULL. وللحفاظ على دلالات PostgreSQL، يدفع pg_clickhouse عائلة IN إلى المصدر عند استخدامها مع قائمة أو مصفوفة ثابتة (IN، NOT IN، = ANY، = ALL، <> ANY، <> ALL) دون استثناء: إما الصيغة الأصلية أو منخفضة التكلفة عندما يمكنه إثبات أن لا قيمة الفحص ولا أي عنصر في المصفوفة يمكن أن يكون NULL، أو صيغة CASE محمية في الحالات الأخرى تتحقق من قيم NULL وقت التشغيل، وتحسب الإجابة الدقيقة ثلاثية القيم في PostgreSQL (TRUE، FALSE، NULL) في جميع السياقات، بما في ذلك مواضع القيم مثل قائمة SELECT أو GROUP BY. يُدفع أيضاً عامل التصفية NOT IN (SELECT ...) المستخدم مع الأعمدة القابلة لـNULL إلى المصدر، ويُعاد تحويله إلى نص مع حواجز تعويضية تحافظ على سلوك PostgreSQL: فالمجموعة التي تحتوي على NULL تستبعد كل صف، ولا تنجح قيمة فحص NULL إلا مع مجموعة فارغة. يُحذف كل حاجز عندما يثبت تعريف NOT NULL عدم الحاجة إليه. وعلى خلاف صيغ المصفوفة أعلاه، لا ينطبق هذا الحاجز إلا في شرط تصفية عادي (أو تحت NOT)؛ وما زلنا لا ندفع IN (SELECT ...) إلى المصدر (في موضع قيمة)، ولا أجسام الاستعلامات الفرعية المجمّعة أو المجمّعة تجميعياً. يؤدي تعريف الأعمدة بأنها NOT NULL إلى زيادة الدفع إلى المصدر إلى أقصى حد، إذ يتيح إرسال الصيغة الأرخص غير المحمية بدلاً من ذلك؛ ويطبّق IMPORT FOREIGN SCHEMA هذا تلقائياً على أعمدة ClickHouse غير Nullable. ويتتبع الإثبات الثوابت غير NULL، وأعمدة NOT NULL، والعمليات الحسابية الأساسية (+، -، *، و- الأحادية) عليها. تفترض هذه القواعد الإعداد الافتراضي في ClickHouse، وهو transform_null_in = 0، الذي يضبطه pg_clickhouse لكل استعلام عبر القيمة الافتراضية للمعلمة pg_clickhouse.session_settings حتى لا يتمكن ملف تعريف خادم ClickHouse من تغييره بصمت. يؤدي ضبط transform_null_in = 1 إلى الإخلال بدلالات كل تعبير IN مدفوع إلى المصدر.

الدوال المخصصة

توفّر هذه الدوال المخصصة التي أنشأها pg_clickhouse دعم pushdown للاستعلامات الخارجية لبعض دوال ClickHouse التي لا يوجد لها ما يكافئها في PostgreSQL. وإذا تعذّر تطبيق pushdown على أيٍّ من هذه الدوال، فسيُرفع استثناء.

Pushdown الامتدادات

يتعرّف pg_clickhouse على الدوال في بعض الامتدادات الأساسية وامتدادات الجهات الخارجية، ويُمرِّر تنفيذها إلى ما يقابلها في ClickHouse.

re2

تُمرَّر جميع معاملات ودوال [امتداد re2] مباشرةً إلى ClickHouse بنسبة 1:1:

intarray

تُنفَّذ إحدى دوال intarray مباشرةً في ClickHouse:

fuzzystrmatch

يمكن تمرير دالتين من fuzzystrmatch إلى ClickHouse:

عمليات CAST ذات pushdown

يقوم pg_clickhouse بتنفيذ pushdown لعمليات CAST مثل CAST(x AS bigint) عند استخدام أنواع بيانات متوافقة. أما مع الأنواع غير المتوافقة، فستفشل عملية الـ pushdown؛ فإذا كانت x في هذا المثال من نوع ClickHouse UInt64، فسيرفض ClickHouse تحويل القيمة. ولتنفيذ pushdown لعمليات CAST لأنواع البيانات غير المتوافقة، يوفّر pg_clickhouse الدوال التالية. وهي تثير استثناءً في PostgreSQL إذا لم يُنفَّذ لها pushdown.

دوال التجميع التي تدعم pushdown

تدعم دوال التجميع التالية في PostgreSQL آلية pushdown إلى ClickHouse.

دوال التجميع المخصصة

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

Pushdown دوال التجميع المرتبة حسب المجموعة

تُطابِق دوال [دوال التجميع للمجموعات المرتبة] هذه دوال [دوال التجميع ذات المعلمات] في ClickHouse، وذلك بتمرير المعامل المباشر الخاص بها كـ parameter، وتمرير تعبيرات ORDER BY الخاصة بها على أنها arguments. على سبيل المثال، query PostgreSQL هذه:
يقابله استعلام ClickHouse التالي:
لاحظ أن اللاحقتين غير الافتراضيتين DESC وNULLS FIRST في ORDER BY غير مدعومتين، وستؤديان إلى ظهور خطأ.

دوال التجميع المخصصة للمجموعات المرتبة

توفر دوال [دوال التجميع للمجموعات المرتبة] المخصصة هذه، التي أنشأها pg_clickhouse، إمكانية pushdown الاستعلامات الخارجية لبعض دوال [دوال التجميع ذات المعلمات] في ClickHouse. إذا تعذر pushdown أي من هذه الدوال، فستُطلق استثناءً.

دوال التجميع المخصصة للمجموعات المرتبة

توفّر دوال [دوال التجميع للمجموعات المرتبة] المخصصة هذه، التي أنشأتها pg_clickhouse، ميزة pushdown الاستعلامات الخارجية لتنفيذ دوال ClickHouse [دوال التجميع ذات المعلمات]. وإذا تعذّر pushdown أي من هذه الدوال، فستُطلق استثناءً.

دوال النافذة pushdown

تخضع دوال النافذة التالية في PostgreSQL لـ pushdown إلى ClickHouse باستخدام عبارات OVER (PARTITION BY ... ORDER BY ...)، بما في ذلك مواصفات الإطار عند الاقتضاء. تُهمل دوال الترتيب (row_number وrank وdense_rank وntile وcume_dist وpercent_rank) عبارة الإطار الخاصة بها عند pushdown، لأن ClickHouse لا يقبل مواصفات الإطار لهذه الدوال.

ملاحظات حول التوافق

التعبيرات النمطية

مع أن pg_clickhouse يحوّل التعبيرات النمطية إلى ما يكافئها في ClickHouse عندما تكون pg_clickhouse.pushdown_regex مضبوطة على true (وهو الإعداد الافتراضي)، ويسعى إلى ضمان حدٍّ أساسي من التوافق، فاحرص على فهم الاختلافات بينهما وكيفية تعامل pg_clickhouse معها.
  • يدعم PostgreSQL [التعبيرات النمطية وفق POSIX] بينما يدعم ClickHouse التعبيرات النمطية وفق RE2. انتبه إلى اختلافات السلوك: استخدم RE2 عندما يتولى ClickHouse تقييم التعبير النمطي (على سبيل المثال، في عبارة WHERE) واستخدم POSIX عندما يتولى Postgres تقييمه (على سبيل المثال، في عبارة SELECT).
  • يقوم pg_clickhouse بتمرير [مُعدِّلات Postgres] إلى التعبير النمطي في ClickHouse عبر إضافتها في بدايته داخل (?). على سبيل المثال:
    يصبح
  • خيارات سطر الأوامر الوحيدة التي يدعمها كلاهما، والتي يمكن بالتالي استخدامها عند تقييمها من قِبل ClickHouse، هي: لا يدعم RE2 سوى هذه العلامات؛ لا تستخدم أيًا من [علامات Postgres] الأخرى.
  • يلخّص هذا الجدول تأثير العلامات المختلفة (وكذلك عدم استخدام أي علامة، وهو ما يعادل s) عند مطابقة الأسطر الجديدة ونهايات الأسطر. لاحظ أنه في Postgres، تمنع m وp فئات المحارف المنفية ([^xyz]) من مطابقة سطر جديد، بينما لا تفعل نظيراتها في ClickHouse ذلك. وبخلاف ذلك، فإن السلوكيات في ClickHouse وPostgres متماثلة:
  • أي خيارات أخرى تُمرَّر إلى دوال التعبيرات النمطية ستمنع تنفيذ الدالة على المصدر البعيد.
  • الاستثناء هو regexp_replace()، إذ يدعم أيضًا الخيار g. وعندما يكون g مفعّلًا، يستخدم pg_clickhouse replaceRegexpAll() بدلًا من replaceRegexpOne() ويزيل هذا الخيار قبل إضافة الخيارات الأخرى كبادئة.
  • تدعم وسيطة الاستبدال في regexp_replace() في Postgres الرمز \& للإشارة إلى المطابقة بالكامل، بينما يدعم ClickHouse الرمز \0 للمطابقة بالكامل. احرص على استخدام \0 عندما تُنفَّذ الدالة في ClickHouse.
  • تعيد regexp_match في Postgres القيمة NULL عند عدم وجود أي تطابقات، بينما تعيد التعبيرات التي يُدفَع تنفيذها إلى النظام البعيد مصفوفة فارغة. استخدم COALESCE() لإرجاع مصفوفة فارغة بدلًا من NULL حتى تتمكن من مقارنة القيم المعادة بشكل متوافق. على سبيل المثال:
لتجنّب أي لبس تمامًا، فكّر في ضبط pg_clickhouse.pushdown_regex لمنع pushdown التعبيرات النمطية في Postgres إلى ClickHouse، واستخدام [امتداد re2]، الذي يدعم معه pg_clickhouse pushdown المباشر لـ التعبيرات النمطية RE2 المتوافقة مع ClickHouse.

to_char()

لا يُجرى pushdown لـ PostgreSQL to_char() الخاص بـ timestamp وtimestamp with time zone إلى ClickHouse formatDateTime إلا عندما تكون وسيطة التنسيق ثابتًا نصيًا غير NULL، ويكون لكل keyword في PostgreSQL مكافئ مماثل تمامًا على مستوى البايت في ClickHouse. وإذا كان التنسيق ديناميكيًا (أي ليس Const)، أو كان يحتوي على أي keyword أو modifier غير مدعوم، فإن الاستدعاء يعود إلى التقييم المحلي في PostgreSQL — ولا تُجرى مطلقًا محاولة لـ pushdown مع ترجمة جزئية، بحيث يظل الناتج متوافقًا مع PG. أما صيغ to_char() ذات الوسيطتين المطبَّقة على numeric وinterval وأنواع أخرى غير timestamp، فلا يُجرى لها pushdown مطلقًا؛ إذ إن ClickHouse formatDateTime لا ينسّق إلا قيم التاريخ والوقت.

الرموز المترجمة

النصوص المقتبسة والقيم الحرفية

النص المحاط بـ "..." يُمرَّر كما هو حرفيًا، مع مضاعفة أي % حرفية إلى %% لتحييد بادئة المحدِّد في ClickHouse. كذلك، فإن \" خارج علامات الاقتباس يُمرَّر أيضًا باعتباره " حرفيًا. وداخل "..."، لا يُستخدم backslash إلا لإلغاء المعنى الخاص لـ "؛ أما تسلسلات backslash الأخرى فتُعامَل كنص حرفي.

المؤلفون

David E. Wheeler حقوق الطبع والنشر (c) 2025-2026، ClickHouse
آخر تعديل في ١٨ أغسطس ٢٠٢٦