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

مقابلة الأنواع في ClickHouse وElasticsearch

يدعم 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”.