@clickhouse/client- Node.js only@clickhouse/client-web- المتصفحات (Chrome/Firefox)، Cloudflare workers
مهارات AI Agentيأتي عميل JS مزودًا بمهارات AI Agent يمكن أن تساعد وكلاء البرمجة على العمل مع العميل. ثبّتها باستخدام:
متطلبات البيئة (node.js)
متطلبات البيئة (الويب)
التثبيت
التوافق مع ClickHouse
من المرجّح أن يعمل العميل أيضًا مع الإصدارات الأقدم؛ ومع ذلك، فهذا الدعم يُقدَّم على أساس بذل أفضل جهد وليس مضمونًا. إذا كان لديك إصدار من ClickHouse أقدم من 23.3، فيُرجى الرجوع إلى سياسة الأمان في ClickHouse والنظر في الترقية.
أمثلة
واجهة برمجة تطبيقات العميل
إنشاء مثيل للعميل
createClient:
التهيئة
معلمات التكوين الخاصة بـ Node.js
إعداد URL
http[s]://[username:password@]hostname:port[/database][?param1=value1¶m2=value2]. في معظم الحالات، يعكس اسم معلمة معيّنة مسارها في واجهة خيارات config، مع بعض الاستثناءات القليلة. المعلمات التالية مدعومة:
- (1) بالنسبة إلى القيم المنطقية، تكون القيم الصالحة
true/1وfalse/0. - (2) أي معلمة تبدأ بـ
clickhouse_setting_أوch_ستُزال منها هذه البادئة، وسيُضاف الباقي إلىclickhouse_settingsالخاص بالعميل. على سبيل المثال،?ch_async_insert=1&ch_wait_for_async_insert=1سيكون مماثلًا لما يلي:
clickhouse_settings بصيغة 1/0 في عنوان URL.
- (3) مماثل لـ (2)، ولكن لإعداد
http_header. على سبيل المثال، يُعد?http_header_x-clickhouse-auth=foobarمكافئًا لـ:
الاتصال
جهّز تفاصيل الاتصال الخاصة بك
تتوفر تفاصيل خدمة ClickHouse Cloud الخاصة بك في ClickHouse Cloud console.
حدِّد خدمة ثم انقر على Connect:

curl.

نظرة عامة على الاتصال
url (بما في
ذلك البروتوكول والمنفذ) وpassword محددتان عبر متغيرات البيئة، وأن المستخدم default هو المستخدم المعتمد.
مثال: إنشاء مثيل العميل في Node.js باستخدام متغيرات البيئة للتهيئة.
مجمع الاتصالات (لـ Node.js فقط)
10، ولكن يمكنك تغييره باستخدام خيار الإعداد max_open_connections.
لا يوجد ما يضمن استخدام الاتصال نفسه من مجمع الاتصالات في الاستعلامات اللاحقة، ما لم يضبط المستخدم max_open_connections: 1. نادرًا ما تكون هناك حاجة إلى ذلك، لكنه قد يكون مطلوبًا في الحالات التي يستخدم فيها المستخدمون الجداول المؤقتة.
انظر أيضًا: إعداد Keep-Alive.
معرّف الاستعلام
command, exec, insert, select) قيمة query_id في النتيجة. يُسنِد العميل هذا المعرّف الفريد لكل استعلام، وقد يكون مفيدًا لاسترجاع البيانات من system.query_log،
إذا كان ذلك مفعّلًا في إعدادات الخادم، أو لإلغاء الاستعلامات طويلة التشغيل (راجع المثال). وإذا لزم الأمر، يمكن للمستخدم تجاوز query_id ضمن params لطرق command/query/exec/insert.
المعلمات الأساسية لجميع طرق العميل
طريقة الاستعلام
SELECT، أو لإرسال عبارات DDL مثل CREATE TABLE، ويجب انتظار اكتمالها. ويُفترض أن يستهلك التطبيق مجموعة النتائج المُعادة.
تجريدات مجموعة النتائج والصفوف
ResultSet عدة طرق ميسّرة لمعالجة البيانات في تطبيقك.
يعتمد تنفيذ ResultSet في Node.js على Stream.Readable داخليًا، بينما يستخدم إصدار الويب واجهة Web API ReadableStream.
يمكنك استهلاك ResultSet باستدعاء الطريقة text أو json على ResultSet، ما يحمّل مجموعة الصفوف كاملةً التي أعادها الاستعلام إلى الذاكرة.
يجب أن تبدأ في استهلاك ResultSet في أسرع وقت ممكن، لأنه يُبقي تدفّق الاستجابة مفتوحًا، وبالتالي يُبقي الاتصال الأساسي مشغولًا. ولا يَخزّن العميل البيانات الواردة مؤقتًا، تجنبًا لاحتمال استهلاك التطبيق قدرًا مفرطًا من الذاكرة.
بدلًا من ذلك، إذا كانت البيانات كبيرة جدًا بحيث لا يمكن تحميلها في الذاكرة دفعةً واحدة، يمكنك استدعاء الطريقة stream ومعالجة البيانات في وضع البث. في هذه الحالة، سيُحوَّل كل جزء من أجزاء الاستجابة إلى مصفوفات صغيرة نسبيًا من الصفوف، جزءًا تلو الآخر (ويعتمد حجم هذه المصفوفة على حجم الجزء الذي يستقبله العميل من الخادم، والذي قد يختلف، وكذلك على حجم الصف الواحد).
يُرجى الرجوع إلى قائمة تنسيقات البيانات المدعومة لتحديد أفضل تنسيق للبث في حالتك. على سبيل المثال، إذا كنت تريد بث كائنات JSON، فيمكنك اختيار JSONEachRow، وسيُحلَّل كل صف على أنه كائن JS، أو ربما التنسيق الأكثر إحكامًا JSONCompactColumns، الذي سيجعل كل صف مصفوفةً مضغوطة من القيم. انظر أيضًا: بث الملفات.
JSONEachRow، مع استهلاك التدفّق بالكامل وتحليل المحتويات على هيئة كائنات JavaScript.
الشيفرة المصدرية.
JSONEachRow باستخدام النهج التقليدي on('data'). ويمكن استخدامه بالتبادل مع صيغة for await const. الشيفرة المصدرية.
CSV باستخدام الأسلوب التقليدي on('data'). ويمكن استخدامه بالتبادل مع بنية for await const.
الشيفرة المصدرية
JSONEachRow، ويُتعامل معها باستخدام صياغة for await const. ويمكن استخدام ذلك بدلًا من الأسلوب التقليدي on('data').
الشيفرة المصدرية.
تستخدم صياغة
for await const شيفرة أقل قليلًا من نهج on('data')، لكنها قد تؤثر سلبًا في الأداء.
راجع هذه المشكلة في مستودع Node.js لمزيد من التفاصيل.ReadableStream من الكائنات.
طريقة insert
insert، فلن تُرسَل عبارة insert إلى الخادم؛ وبدلًا من ذلك، ستُعاد الطريقة فورًا بالقيمة { query_id: '...', executed: false }. وإذا لم يُمرَّر query_id ضمن معلمات الطريقة في هذه الحالة، فستكون قيمته في النتيجة سلسلة فارغة، لأن إرجاع معرّف UUID عشوائي يولّده العميل قد يكون مُربِكًا، إذ إن الاستعلام ذي query_id هذا لن يكون موجودًا في جدول system.query_log.
إذا أُرسلت عبارة insert إلى الخادم، فستكون العلامة executed هي true.
طريقة insert والدفق في Node.js
Stream.Readable أو مع Array<T> عادي، وذلك بحسب تنسيق البيانات المحدد لطريقة insert. راجع أيضًا هذا القسم حول دفق الملفات.
من المفترض استخدام await مع طريقة insert؛ ومع ذلك، يمكن تحديد دفق إدخال ثم انتظار عملية insert لاحقًا، عند اكتمال الدفق فقط (وسيؤدي ذلك أيضًا إلى اكتمال الوعد الخاص بـ insert). قد يكون هذا مفيدًا في بعض الحالات، مثل مستمعات الأحداث والسيناريوهات المشابهة، لكن معالجة الأخطاء قد تكون معقدة بسبب كثرة الحالات الطرفية في جهة العميل. بدلًا من ذلك، فكّر في استخدام عمليات insert غير المتزامنة كما هو موضح في هذا المثال.
قيود إصدار الويب
@clickhouse/client-web إلا مع التنسيقات Array<T> وJSON*.
ولا يزال إدراج التدفقات غير مدعوم في إصدار الويب بسبب ضعف التوافق مع المتصفحات.
وبناءً على ذلك، تبدو واجهة InsertParams في إصدار الويب مختلفة قليلًا عن إصدار Node.js،
إذ تقتصر values على النوع ReadonlyArray<T> فقط:
طريقة command
format قابلة للتطبيق، أو عندما لا تكون مهتمًا بالاستجابة على الإطلاق. ومن أمثلة هذه العبارات CREATE TABLE أو ALTER TABLE.
يجب استخدام await معها.
يتم إتلاف تدفق الاستجابة فورًا، ما يعني تحرير socket الأساسي.
طريقة Exec
query/insert،
وكانت النتيجة تهمّك، فيمكنك استخدام exec كبديل لـ command.
تعيد exec دفقًا قابلاً للقراءة ويجب استهلاكه أو إغلاقه من جانب التطبيق.
Ping
ping المخصّصة للتحقق من حالة الاتصال القيمة true إذا أمكن الوصول إلى الخادم.
إذا تعذّر الوصول إلى الخادم، فستتضمن النتيجة أيضًا الخطأ الأساسي.
Ping أداة مفيدة للتحقق مما إذا كان الخادم متاحًا عند بدء تشغيل التطبيق، لا سيما مع ClickHouse Cloud، حيث قد يكون المثيل في وضع الخمول ويستيقظ بعد إجراء ping. في هذه الحالة، قد ترغب في إعادة المحاولة بضع مرات مع تأخير بين كل محاولة وأخرى.
لاحظ أنه افتراضيًا، يستخدم إصدار Node.js نقطة النهاية /ping، بينما يستخدم إصدار الويب استعلام SELECT 1 لتحقيق نتيجة مماثلة، لأن نقطة النهاية /ping لا تدعم CORS.
مثال: (Node.js/Web) إجراء ping بسيط على مثيل خادم ClickHouse. ملاحظة: في إصدار الويب، ستكون الأخطاء التي يتم التقاطها مختلفة.
الشيفرة المصدرية.
ping، أو تمرير معاملات إضافية مثل query_id، فيمكنك استخدامها كما يلي:
query القياسية - راجع تعريف النوع PingParamsWithSelectQuery.
Close (Node.js فقط)
تدفّق الملفات (Node.js فقط)
query (JSONEachRow وCSV وما إلى ذلك) واسم ملف الإخراج.
تنسيقات البيانات المدعومة
format كأحد التنسيقات التابعة لعائلة JSON (JSONEachRow وJSONCompactEachRow وما إلى ذلك)، فسيقوم العميل بتسلسل البيانات وإلغاء تسلسلها أثناء نقلها عبر الشبكة.
تُرسل البيانات المقدَّمة بتنسيقات النص “الخام” (CSV وعائلتا TabSeparated وCustomSeparated) عبر الشبكة كما هي، من دون أي تحويلات إضافية.
بالنسبة إلى Parquet، يُرجَّح أن تكون حالة الاستخدام الرئيسية لعمليات SELECT هي كتابة التدفق الناتج إلى ملف. راجع المثال في مستودع العميل.
JSONEachRowWithProgress هو تنسيق مخصّص للإخراج فقط ويدعم الإبلاغ عن التقدم ضمن التدفق. راجع هذا المثال لمزيد من التفاصيل.
تتوفر القائمة الكاملة لتنسيقات الإدخال والإخراج في ClickHouse
هنا.
أنواع بيانات ClickHouse المدعومة
ينطبق نوع JS المرتبط على أي تنسيقات
JSON*، باستثناء التنسيقات التي تمثل كل شيء كسلسلة نصية (مثل JSONStringEachRow)
القائمة الكاملة لتنسيقات ClickHouse المدعومة متاحة
هنا.
انظر أيضًا:
محاذير أنواع Date/Date32
Date/Date32 إلا
كسلاسل نصية.
مثال: أدرج قيمة من النوع Date.
الشيفرة المصدرية
DateTime أو DateTime64، يمكنك استخدام كلٍّ من السلاسل النصية وكائنات JS Date. ويمكن تمرير كائنات JS Date إلى insert كما هي مع ضبط date_time_input_format على best_effort. راجع هذا المثال لمزيد من التفاصيل.
محاذير أنواع Decimal*
JSON*. بافتراض أن لدينا جدولًا معرّفًا كما يلي:
JSON*، سيُرجع ClickHouse قيم Decimal على شكل أرقام افتراضيًا، مما قد يؤدي إلى فقدان الدقة. لتجنّب ذلك، يمكنك تحويل قيم Decimal إلى سلسلة نصية في الاستعلام:
الأنواع العددية الصحيحة: Int64, Int128, Int256, UInt64, UInt128, UInt256
JSON* لتجنب
overflow للأعداد الصحيحة، لأن القيم القصوى لهذه الأنواع أكبر من Number.MAX_SAFE_INTEGER.
ومع ذلك، يمكن تعديل هذا السلوك
باستخدام إعداد output_format_json_quote_64bit_integers
.
مثال: اضبط تنسيق إخراج JSON للأرقام ذات 64 بت.
إعدادات ClickHouse
موضوعات متقدمة
الاستعلامات ذات المعلمات
name— معرّف العنصر النائب.data_type- نوع البيانات لقيمة مَعلمة التطبيق.
الضغط
GZIP باستخدام zlib.
response: trueيوجّه ClickHouse server لإرسال جسم الاستجابة مضغوطًا. القيمة الافتراضية:response: falserequest: trueيفعّل الضغط في جسم طلب العميل. القيمة الافتراضية:request: false
التسجيل (Node.js فقط)
stdout عبر الطريقتين console.debug/info، وإلى stderr عبر الطريقتين console.warn/error.
يمكنك تخصيص منطق التسجيل من خلال توفير LoggerClass، واختيار مستوى السجل المطلوب عبر المعامل level (القيمة الافتراضية هي WARN):
TRACE- معلومات منخفضة المستوى عن دورة حياة مقابس Keep-AliveDEBUG- معلومات الاستجابة (من دون رؤوس التفويض ومعلومات المضيف)INFO- غير مستخدم في الغالب، ويطبع مستوى السجل الحالي عند تهيئة العميلWARN- أخطاء غير فادحة؛ يُسجَّل طلبpingالفاشل كتحذير، لأن الخطأ الأساسي يكون مضمنًا في النتيجة المعادةERROR- أخطاء فادحة من الطرقquery/insert/exec/command، مثل فشل الطلب
شهادات TLS (Node.js فقط)
certs
وأن اسم ملف CA هو CA.pem:
إعداد Keep-Alive (Node.js فقط)
Connection: keep-alive. وتبقى المقابس الخاملة ضمن مجموعة الاتصالات لمدة 2500 مللي ثانية افتراضيًا (راجع الملاحظات حول ضبط هذا الخيار).
يُفترض أن تكون قيمة keep_alive.idle_socket_ttl أقل بفارق ملحوظ من إعدادات الخادم/موازن التحميل. والسبب الرئيسي هو أنه، نظرًا لأن HTTP/1.1 يسمح للخادم بإغلاق المقابس من دون إخطار العميل، فإذا أغلق الخادم أو موازن التحميل الاتصال قبل أن يغلقه العميل، فقد يحاول العميل إعادة استخدام مقبس مغلق، ما يؤدي إلى الخطأ socket hang up.
إذا كنت تعدّل keep_alive.idle_socket_ttl، فضع في اعتبارك أنه يجب أن يظل متوافقًا دائمًا مع إعدادات Keep-Alive الخاصة بالخادم/موازن التحميل، وأن يكون أقل منها دائمًا، بما يضمن ألا يغلق الخادم الاتصال المفتوح أولًا.
ضبط idle_socket_ttl
keep_alive.idle_socket_ttl على 2500 ملّي ثانية، إذ يمكن اعتبارها القيمة الافتراضية الأكثر أمانًا؛ وعلى جانب الخادم، قد يُضبط keep_alive_timeout على قيمة منخفضة تصل إلى 3 ثوانٍ في إصدارات ClickHouse الأقدم من 23.11 من دون أي تعديلات على config.xml.
يمكنك العثور على قيمة مهلة Keep-Alive الصحيحة في ترويسات استجابة الخادم بتشغيل الأمر التالي:
Connection وKeep-Alive في الاستجابة. على سبيل المثال:
keep_alive_timeout 10 ثوانٍ، ويمكنك محاولة زيادة keep_alive.idle_socket_ttl إلى 9000 أو حتى 9500 مللي ثانية للإبقاء على المقابس الخاملة مفتوحة لفترة أطول قليلًا من الوضع الافتراضي. راقب أي أخطاء محتملة من نوع “Socket hang-up”، إذ تشير إلى أن الخادم يغلق الاتصالات قبل أن يغلقها العميل، وخفِّض القيمة حتى تختفي الأخطاء.
استكشاف الأخطاء وإصلاحها
socket hang up حتى عند استخدام أحدث إصدار من العميل، فهناك الخيارات التالية لحل هذه المشكلة:
-
فعِّل السجلات بمستوى
WARNعلى الأقل (وهو المستوى الافتراضي). يتيح ذلك التحقق مما إذا كان هناك دفق غير مستهلك أو دفق معلّق في شيفرة التطبيق؛ إذ ستسجّله طبقة النقل عند مستوىWARN، لأن ذلك قد يؤدي إلى إغلاق المقبس من جانب الخادم. يمكنك تفعيل التسجيل في إعدادات العميل كما يلي: -
تأكد من أن الإعداد المطلوب مُطبَّق على مثيل العميل الصحيح. إذا كان لديك عدة مثيلات للعميل في تطبيقك، فتحقق مرة أخرى من أن المثيل الذي تستخدمه للاستعلامات لديه القيمة الصحيحة لـ
keep_alive.idle_socket_ttl. -
خفِّض إعداد
keep_alive.idle_socket_ttlفي إعدادات العميل بمقدار 500 مللي ثانية. في بعض الحالات، مثل ارتفاع كمون الشبكة بين العميل والخادم، قد يكون هذا مفيدًا لتجنّب الحالة التي يحصل فيها طلب صادر على مقبس على وشك أن يغلقه الخادم. -
إذا كان هذا الخطأ يحدث أثناء الاستعلامات طويلة التشغيل من دون وجود بيانات داخلة أو خارجة (على سبيل المثال،
INSERT FROM SELECTطويل التشغيل)، فقد يكون السبب موازن تحميل أو مكونات شبكة أخرى تغلق الاتصالات طويلة الأمد أو الطلبات طويلة التشغيل. يمكنك محاولة فرض وصول بعض البيانات أثناء الاستعلامات طويلة التشغيل باستخدام مجموعة إعدادات ClickHouse التالية:ومع ذلك، ضع في اعتبارك أن الحجم الإجمالي للترويسات المستلمة له حد أقصى قدره 16KB في الإصدارات الحديثة من Node.js؛ وبعد تلقّي عدد معيّن من ترويسات التقدم، وكان ذلك نحو 70-80 في اختباراتنا، سيجري إنشاء استثناء. ومن الممكن أيضًا استخدام نهج مختلف تمامًا، مع تجنّب وقت الانتظار في تنسيق النقل بالكامل؛ ويمكن فعل ذلك بالاستفادة من “الميزة” في واجهة HTTP التي تقضي بعدم إلغاء عمليات mutation عند فقدان الاتصال. راجع هذا المثال (الجزء 2) لمزيد من التفاصيل. -
يمكن تعطيل ميزة Keep-Alive بالكامل. في هذه الحالة، سيضيف العميل أيضًا ترويسة
Connection: closeإلى كل طلب، ولن يعيدHTTP agentالأساسي استخدام الاتصالات. سيتم تجاهل إعدادkeep_alive.idle_socket_ttl، إذ لن تكون هناك مقابس خاملة. سيؤدي هذا إلى كلفة إضافية، لأن اتصالًا جديدًا سيُنشأ لكل طلب. -
استبعد المشكلات المحتملة في بقية مكدس الشبكة، بما في ذلك Node.js نفسه، عن طريق تشغيل اختبار بسيط من سطر الأوامر باستخدام مثيل ClickHouse نفسه ومسار الشبكة نفسه (أي من الجهاز نفسه أو من مقطع الشبكة نفسه، مثل pod في Kubernetes)، على سبيل المثال باستخدام
curl:قد ترغب في تشغيله ضمن حلقة لعدة دقائق. إذا رأيت أخطاء مشابهة فيcurl، فمن المرجح أن المشكلة لا تتعلق بإعدادات العميل، بل بمكدس الشبكة أو إعدادات الخادم. -
لاختبار الاتصال باستخدام وظائف Node.js الأساسية، يمكنك محاولة إنشاء HTTP request بسيطة إلى ClickHouse server باستخدام واجهة
fetchAPI المدمجة:
-
في بعض الحالات، قد تضيف شيفرة التطبيق أو موائمات إطار العمل
ping()استباقية قبل تنفيذ الاستعلام الفعلي، ما قد يؤدي إلى وضع ينجح فيه طلبping()، لكن يفشل طلب الاستعلام اللاحق بخطأ “socket hang up” بسبب المشكلة الأساسية نفسها المرتبطة بالاتصالات الخاملة. إذا لاحظت هذا النمط في السجلات، فحاول التحقق مما إذا كان هناك خيار لتعطيل عملياتping()الاستباقية في إطار العمل أو في شيفرة التطبيق. ومن المفترض أن يساعد ذلك أيضًا في تقليل احتمال التعرّض لتقييد المعدّل من أي من مكوّنات الشبكة الوسيطة. - تأكد من أن التطبيق نفسه يحصل على وقت CPU كافٍ، وأن الشبكة لا يقيّد موفّر الاستضافة معدلها. وقد تكون أيضًا وسائل المراقبة المختلفة، مثل مقاييس توقّف GC المؤقت، ومقاييس تأخر حلقة الأحداث، وما شابهها، مفيدة في استبعاد المشكلات المحتملة الناتجة عن شحّ الموارد.
- جرّب فحص شيفرة التطبيق مع تفعيل قاعدة ESLint no-floating-promises، إذ يساعد ذلك في تحديد الوعود غير المُعالجة التي قد تؤدي إلى تدفقات ومقابس معلّقة.
المستخدمون ذوو صلاحية القراءة فقط
readonly=1، لا يمكن تمكين ضغط الاستجابة، لأنه يتطلب الإعداد enable_http_compression. سيؤدي التكوين التالي إلى حدوث خطأ:
readonly=1.
وكيل مع اسم مسار
clickhouse_server كخيار الإعداد pathname (مع أو بدون شرطة مائلة في البداية)؛ وإلا، فإذا أُدرج مباشرةً في url فسيُعامل على أنه الخيار database. كما أن أسماء المسارات متعددة المقاطع مدعومة، مثل /my_proxy/db.
وكيل عكسي مع المصادقة
http_headers لتوفير الترويسات اللازمة هناك:
وكيل HTTP/HTTPS مخصص (تجريبي، Node.js فقط)
max_open_connections وkeep_alive.enabled وtls)، ليتولى إدارة الاتصالات مع خادم ClickHouse. بالإضافة إلى ذلك، إذا استُخدمت شهادات TLS، فسيُهيَّأ الوكيل الأساسي بالشهادات اللازمة، وستُفرض ترويسات مصادقة TLS الصحيحة.
بعد الإصدار 1.2.0، أصبح من الممكن تزويد العميل بوكيل HTTP أو HTTPS مخصص ليحل محل الوكيل الأساسي الافتراضي. وقد يكون ذلك مفيدًا في حالات تهيئة الشبكة المعقدة. تنطبق الشروط التالية عند توفير وكيل مخصص:
- لن يكون للخيارين
max_open_connectionsوtlsأي تأثير، وسيتجاهلهما العميل، لأنهما جزء من تهيئة الوكيل الأساسي. - سيقتصر
keep_alive.enabledعلى تحديد القيمة الافتراضية لترويسةConnection(true->Connection: keep-alive،false->Connection: close). - مع أن إدارة مقابس keep-alive الخاملة ستستمر في العمل (لأنها لا ترتبط بالوكيل، بل بالمقبس نفسه)، فقد أصبح من الممكن الآن تعطيلها بالكامل بضبط قيمة
keep_alive.idle_socket_ttlعلى0.
أمثلة على استخدام وكيل مخصّص
set_basic_auth_header (أُضيف في الإصدار 1.2.0)، لأنها تتعارض مع ترويسات TLS. ويجب توفير جميع ترويسات TLS يدويًا.
القيود المعروفة (Node.js/web)
- لا توجد مُحوِّلات بيانات لمجموعات النتائج، لذا لا تُستخدم سوى الأنواع البدائية في اللغة. ومن المخطط إضافة بعض مُحوِّلات أنواع البيانات مع دعم RowBinary format.
- توجد بعض الملاحظات المتعلقة بأنواع البيانات Decimal* وDate* / DateTime*.
- عند استخدام تنسيقات عائلة JSON*، تُمثَّل الأرقام الأكبر من Int32 كسلاسل نصية، لأن القيم القصوى لأنواع Int64+ أكبر من
Number.MAX_SAFE_INTEGER. راجع قسم Integral types لمزيد من التفاصيل.
القيود المعروفة (الويب)
- يعمل التدفّق مع استعلامات select، لكنه معطّل لعمليات insert (وعلى مستوى النوع أيضًا).
- ضغط الطلبات معطّل، ويتم تجاهل الإعدادات. أما ضغط الاستجابة فيعمل.
- لا يتوفر دعم للتسجيل حتى الآن.
نصائح لتحسين الأداء
- لتقليل استهلاك ذاكرة التطبيق، يُنصح باستخدام التدفقات في عمليات الإدراج الكبيرة (مثلًا من الملفات) واستعلامات
SELECTعند الحاجة. وبالنسبة إلى مستمعي الأحداث وحالات الاستخدام المشابهة، قد تكون الإدراجات غير المتزامنة خيارًا جيدًا آخر، إذ تتيح تقليل التجميع على جهة العميل أو حتى الاستغناء عنه تمامًا. تتوفر أمثلة على الإدراج غير المتزامن في مستودع العميل، حيث تأتي أسماء الملفات بالبادئةasync_insert_. - لا يفعّل العميل ضغط الطلبات أو الاستجابات افتراضيًا. ومع ذلك، عند تنفيذ استعلامات
SELECTأو إدراج مجموعات بيانات كبيرة، يمكنك التفكير في تفعيله عبرClickHouseClientConfigOptions.compression(إما لـrequestفقط أوresponseفقط أو لكليهما). - يفرض الضغط أثرًا ملحوظًا على الأداء. فتفعيله لـ
requestأوresponseسيؤثر سلبًا في سرعة استعلاماتSELECTأو عمليات الإدراج، على التوالي، لكنه سيقلل حجم حركة مرور الشبكة التي ينقلها التطبيق.
تواصل معنا
#clickhouse-js) أو عبر GitHub issues.