الانتقال إلى المحتوى الرئيسي

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

​
القيم العددية

سيلاحظ المستخدمون الذين ينقلون البيانات بين ClickHouse وSnowflake فورًا أن ClickHouse يوفّر دقة أكثر تفصيلًا عند تعريف القيم العددية. على سبيل المثال، يوفّر Snowflake النوع Number للقيم العددية. وهذا يتطلب من المستخدم تحديد precision (إجمالي عدد الأرقام) وscale (عدد الأرقام إلى يمين الفاصلة العشرية) بحد أقصى إجمالي يبلغ 38. كما أن تعريفات الأعداد الصحيحة تُعد مرادفةً للنوع Number، وهي ببساطة تحدّد precision وscale ثابتين مع بقاء النطاق نفسه. وتعود هذه السهولة إلى أن تعديل precision (حيث تكون قيمة scale مساوية لـ 0 في الأعداد الصحيحة) لا يؤثر في حجم البيانات على القرص في Snowflake، إذ يُستخدم الحد الأدنى المطلوب من البايتات للنطاق العددي عند الكتابة على مستوى micro partition. أما scale، فهو يؤثر في مساحة التخزين، ويُعوَّض ذلك عبر الضغط. ويوفّر النوع Float64 نطاقًا أوسع من القيم مقابل بعض الفقد في الدقة. في المقابل، يوفّر ClickHouse درجات دقة متعددة، موقّعة وغير موقّعة، للأعداد العائمة والأعداد الصحيحة. وباستخدام هذه الأنواع، يمكنك تحديد مقدار الدقة المطلوبة للأعداد الصحيحة بدقة لتحسين استهلاك التخزين والذاكرة. كما أن النوع Decimal، وهو المكافئ للنوع Number في Snowflake، يوفّر أيضًا ضعف precision وscale ليصل إلى 76 رقمًا. وإضافةً إلى النوع Float64 المماثل، يوفّر ClickHouse أيضًا النوع Float32 للحالات التي تكون فيها الدقة أقل أهمية ويكون الضغط فيها أولوية قصوى.

​
السلاسل النصية

يتبع ClickHouse وSnowflake نهجين مختلفين في تخزين بيانات السلاسل النصية. يحتفظ VARCHAR في Snowflake بمحارف Unicode بترميز UTF-8، ما يتيح للمستخدم تحديد حد أقصى للطول. ولا يؤثر هذا الطول في التخزين أو الأداء، إذ يُستخدم دائمًا الحد الأدنى من البايتات لتخزين السلسلة النصية، وهو يفرض فقط قيودًا تفيد الأدوات اللاحقة. أما الأنواع الأخرى، مثل Text وNChar، فهي مجرد أسماء بديلة لهذا النوع. وعلى النقيض من ذلك، يخزّن ClickHouse كل بيانات السلاسل النصية كبايتات خام باستخدام النوع String (من دون الحاجة إلى تحديد الطول)، ويترك مسألة الترميز للمستخدم، مع توفّر دوال وقت الاستعلام للتعامل مع الترميزات المختلفة. ونحيل القارئ إلى “Opaque data argument” للاطلاع على الدافع وراء ذلك. لذلك، فإن String في ClickHouse أقرب من حيث التنفيذ إلى النوع Binary في Snowflake. ويدعم كل من Snowflake وClickHouse ميزة “collation”، بما يتيح للمستخدمين تخصيص كيفية فرز السلاسل النصية ومقارنتها.

​
الأنواع شبه المهيكلة

تدعم Snowflake الأنواع VARIANT وOBJECT وARRAY للبيانات شبه المهيكلة. توفّر ClickHouse الأنواع المكافئة Variant، وObject (وهو الآن مهمل لصالح النوع JSON الأصلي) وArray. بالإضافة إلى ذلك، توفّر ClickHouse النوع JSON الذي يحل محل النوع Object('json') المهمل حاليًا، ويتميّز بأداء عالٍ وكفاءة في التخزين عند مقارنته بأنواع JSON الأصلية الأخرى. تدعم ClickHouse أيضًا Tuples المسمّاة ومصفوفات من Tuples من خلال النوع Nested، مما يتيح للمستخدمين تمثيل البُنى المتداخلة بشكل صريح. ويتيح ذلك تطبيق codecs وتحسينات الأنواع عبر كامل البنية الهرمية، بخلاف Snowflake التي تتطلب من المستخدم استخدام الأنواع OBJECT وVARIANT وARRAY للكائن الخارجي، ولا تسمح بالتحديد الصريح للأنواع الداخلية. كما أن هذا التحديد الداخلي للأنواع يبسّط أيضًا الاستعلامات على القيم العددية المتداخلة في ClickHouse، إذ لا تحتاج إلى تحويل نوع ويمكن استخدامها في تعريفات الفهارس. في ClickHouse، يمكن أيضًا تطبيق codecs والأنواع المُحسّنة على البُنى الفرعية. وهذا يوفّر ميزة إضافية تتمثل في أن الضغط مع البُنى المتداخلة تظل ممتازة ومقاربة لما هي عليه في البيانات المسطّحة. وعلى النقيض، ونتيجة عدم القدرة على تطبيق أنواع محددة على البُنى الفرعية، توصي Snowflake بتسطيح البيانات لتحقيق ضغط أمثل. كما تفرض Snowflake أيضًا قيودًا على الحجم على هذه الأنواع من البيانات.

​
مرجع الأنواع

وأخيرًا، يوفّر ClickHouse قدرة فريدة على تخزين حالة الدوال التجميعية. وهذه الحالة خاصة بالتنفيذ، لكنها تتيح تخزين نتيجة التجميع ثم الاستعلام عنها لاحقًا (باستخدام دوال الدمج المقابلة). وعادةً ما تُستخدم هذه الميزة عبر عرض مادي، وكما هو موضح أدناه، فهي تتيح إمكانية تحسين أداء استعلامات محددة بأقل تكلفة تخزين ممكنة من خلال تخزين النتيجة التزايدية للاستعلامات على البيانات المُدرجة (مزيد من التفاصيل هنا).
آخر تعديل في ٢ يوليو ٢٠٢٦