مقابلة الأنواع

يدعم Elasticsearch وClickHouse مجموعة واسعة من أنواع البيانات، لكن آليات التخزين الأساسية ونماذج الاستعلام فيهما تختلف جذريًا. يوضّح هذا القسم ما يقابل أنواع الحقول الشائعة الاستخدام في Elasticsearch في ClickHouse، حيثما توفّر ذلك، كما يقدّم سياقًا يساعد في توجيه عمليات الترحيل. وعند عدم وجود مقابل مباشر، تُذكر بدائل أو ملاحظات في التعليقات.

نوع Elasticsearch	المقابل في ClickHouse	ملاحظات
`boolean`	`UInt8` أو `Bool`	يدعم ClickHouse النوع `Boolean` كاسم مستعار لـ `UInt8` في الإصدارات الأحدث.
`keyword`	`String`	يُستخدم للتصفية بالمطابقة التامة، والتجميع، والفرز.
`text`	`String`	إمكانات full-text search محدودة في ClickHouse؛ وتتطلب tokenization منطقًا مخصصًا باستخدام دوال مثل `tokens` مع array functions.
`long`	`Int64`	عدد صحيح موقّع 64-بت.
`integer`	`Int32`	عدد صحيح موقّع 32-بت.
`short`	`Int16`	عدد صحيح موقّع 16-بت.
`byte`	`Int8`	عدد صحيح موقّع 8-بت.
`unsigned_long`	`UInt64`	عدد صحيح غير موقّع 64-بت.
`double`	`Float64`	عدد عشري عائم 64-بت.
`float`	`Float32`	عدد عشري عائم 32-بت.
`half_float`	`Float32` أو `BFloat16`	أقرب مكافئ. لا يحتوي ClickHouse على نوع float بحجم 16-بت. يتوفر في ClickHouse النوع `BFloat16`، لكنه يختلف عن Half-float IEE-754: إذ يوفّر half-float دقة أعلى مع نطاق أصغر، بينما يضحّي bfloat16 بالدقة مقابل نطاق أوسع، مما يجعله أنسب لأحمال تعلّم الآلة.
`scaled_float`	`Decimal(x, y)`	لتخزين numeric values ذات الفاصلة الثابتة.
`date`	`DateTime`	أنواع تاريخ مكافئة بدقة الثواني.
`date_nanos`	`DateTime64`	يدعم ClickHouse دقة النانوثانية باستخدام `DateTime64(9)`.
`binary`	`String`, `FixedString(N)`	يتطلب فك ترميز base64 للحقول الثنائية.
`ip`	`IPv4`, `IPv6`	تتوفر أنواع `IPv4` و`IPv6` الأصلية.
`object`	`Nested`, `Map`, `Tuple`, `JSON`	يمكن لـ ClickHouse تمثيل الكائنات الشبيهة بـ JSON باستخدام `Nested` أو `JSON`.
`flattened`	`String`	يخزّن النوع flattened في Elasticsearch كائنات JSON كاملةً كحقول مفردة، ما يتيح وصولًا مرنًا ومن دون schema ثابتة إلى المفاتيح المتداخلة من دون تعيين كامل. وفي ClickHouse، يمكن تحقيق وظيفة مشابهة باستخدام النوع String، لكن ذلك يتطلب تنفيذ المعالجة في materialized views.
`nested`	`Nested`	توفّر أعمدة ClickHouse `Nested` دلالات مشابهة للحقول الفرعية المجمّعة، بافتراض استخدام `flatten_nested=0`.
`join`	NA	لا يوجد مفهوم مباشر لعلاقات الأصل-الفرع. ولا حاجة إليه في ClickHouse لأن joins عبر الجداول مدعومة.
`alias`	`Alias` modifier للعمود	الأسماء المستعارة مدعومة من خلال modifier للحقل. ويمكن تطبيق الدوال على هذا alias، مثل `size String ALIAS formatReadableSize(size_bytes)`
`range` types (`*_range`)	`Tuple(start, end)` أو `Array(T)`	لا يحتوي ClickHouse على نوع range أصلي، لكن يمكن تمثيل النطاقات الرقمية ونطاقات التاريخ باستخدام البنى `Tuple(start, end)` أو `Array`. وبالنسبة إلى نطاقات IP (`ip_range`)، خزّن قيم CIDR كـ `String` وقيّمها باستخدام دوال مثل `isIPAddressInRange()`. وبدلًا من ذلك، يمكن استخدام قواميس lookup المعتمدة على `ip_trie` للحصول على تصفية فعّالة.
`aggregate_metric_double`	`AggregateFunction(...)` و`SimpleAggregateFunction(...)`	استخدم aggregate function states وmaterialized views لنمذجة المقاييس المجمّعة مسبقًا. تدعم جميع دوال aggregation aggregate states.
`histogram`	`Tuple(Array(Float64), Array(UInt64))`	مثّل الحاويات والعدّادات يدويًا باستخدام arrays أو schema مخصصة.
`annotated-text`	`String`	لا يوجد دعم مدمج للبحث المدرك للكيانات أو annotations.
`completion`, `search_as_you_type`	NA	لا يوجد محرّك autocomplete أو suggester أصلي. يمكن محاكاة ذلك باستخدام `String` وsearch functions.
`semantic_text`	NA	لا يوجد semantic search أصلي — أنشئ embeddings واستخدم vector search.
`token_count`	`Int32`	استخدمه أثناء ingestion لحساب عدد الـ token يدويًا، مثلًا عبر الدالة `length(tokens())`، على سبيل المثال مع عمود Materialized
`dense_vector`	`Array(Float32)`	استخدم arrays لتخزين embeddings.
`sparse_vector`	`Map(UInt32, Float32)`	حاكِ المتجهات sparse باستخدام الخرائط. لا يوجد دعم أصلي للمتجهات sparse.
`rank_feature` / `rank_features`	`Float32`, `Array(Float32)`	لا يوجد تعزيز أصلي أثناء الاستعلام، لكن يمكن تمثيله يدويًا ضمن منطق التقييم.
`geo_point`	`Tuple(Float64, Float64)` أو `Point`	استخدم Tuple من (خط العرض، خط الطول). ويتوفر `Point` أيضًا كنوع في ClickHouse.
`geo_shape`, `shape`	`Ring`, `LineString`, `MultiLineString`, `Polygon`, `MultiPolygon`	دعم أصلي للأشكال الجغرافية والفهرسة المكانية.
`percolator`	NA	لا يوجد مفهوم لفهرسة الاستعلامات. استخدم SQL القياسي + العروض المادية التزايدية بدلًا من ذلك.
`version`	`String`	لا يوفّر ClickHouse نوعًا أصليًا للإصدارات. خزّن الإصدارات كسلاسل نصية، واستخدم دوال UDFs مخصصة لإجراء المقارنات الدلالية عند الحاجة. وفكّر في تطبيعها إلى تنسيقات رقمية إذا كانت استعلامات النطاق مطلوبة.

ملاحظات

المصفوفات: في Elasticsearch، تدعم جميع الحقول المصفوفات دعمًا أصيلًا. أما في ClickHouse، فيجب تعريف المصفوفات صراحةً (مثل Array(String))، مع ميزة إمكانية الوصول إلى مواضع محددة فيها والاستعلام عنها، مثل an_array[1].
الحقول المتعددة: يتيح Elasticsearch فهرسة الحقل نفسه بطرائق متعددة (مثل text وkeyword معًا). أما في ClickHouse، فيجب تمثيل هذا النمط باستخدام أعمدة أو views منفصلة.
نوعا Map وJSON - في ClickHouse، يُستخدم النوع Map عادةً لتمثيل بنى key-value الديناميكية مثل resourceAttributes وlogAttributes. ويتيح هذا النوع إدخال البيانات بمرونة ومن دون مخطط ثابت، إذ يسمح بإضافة مفاتيح عشوائية في وقت التشغيل — وهو ما يشبه من حيث الفكرة JSON objects في Elasticsearch. ومع ذلك، هناك قيود مهمة ينبغي مراعاتها:
- أنواع قيم موحّدة: يجب أن تحتوي أعمدة Map في ClickHouse على نوع قيم متّسق (مثل Map(String, String)). ولا تُدعَم القيم ذات الأنواع المختلطة من دون تحويل قسري.
- تكلفة على الأداء: يتطلب الوصول إلى أي مفتاح في Map تحميل الخريطة بالكامل إلى الذاكرة، وهو ما قد يكون غير مثالي من ناحية الأداء.
- عدم وجود subcolumns: بخلاف JSON، لا تُمثَّل المفاتيح في Map بوصفها subcolumns فعلية، مما يحدّ من قدرة ClickHouse على الفهرسة والضغط والاستعلام بكفاءة.
وبسبب هذه القيود، يتجه ClickStack إلى الاستغناء عن Map لصالح النوع JSON المحسّن في ClickHouse. ويعالج النوع JSON العديد من أوجه القصور في Map:
- تخزين عمودي حقيقي: يُخزَّن كل JSON path بوصفه subcolumn، مما يتيح ضغطًا وترشيحًا وتنفيذًا متجهيًا للاستعلامات بكفاءة.
- دعم الأنواع المختلطة: يمكن لأنواع البيانات المختلفة (مثل الأعداد الصحيحة والسلاسل النصية والمصفوفات) أن تتعايش تحت المسار نفسه من دون تحويل قسري أو توحيد للنوع.
- قابلية التوسع على مستوى نظام الملفات: تمنع الحدود الداخلية للمفاتيح الديناميكية (max_dynamic_paths) والأنواع (max_dynamic_types) حدوث تضخم في عدد column files على القرص، حتى مع مجموعات المفاتيح ذات high cardinality.
- تخزين كثيف: تُخزَّن nulls والقيم المفقودة بشكل sparse لتجنّب overhead غير الضروري.
  
  يُعد النوع JSON مناسبًا بشكل خاص لأعباء observability، إذ يوفّر مرونة الإدخال من دون مخطط ثابت، إلى جانب أداء أنواع ClickHouse الأصلية وقابليتها للتوسع — مما يجعله بديلًا مثاليًا لـ Map في حقول attributes الديناميكية.
  
  ولمزيد من التفاصيل حول نوع JSON، نوصي بالاطلاع على JSON guide و"How we built a new powerful JSON data type for ClickHouse".