أنواع البيانات
سيلاحظ المستخدمون الذين ينقلون البيانات بين ClickHouse وRedshift فورًا أن ClickHouse يوفّر نطاقًا أوسع من الأنواع، كما أنها أقل تقييدًا. فبينما يفرض Redshift على المستخدمين تحديد الأطوال المحتملة للسلاسل النصية، حتى عندما تكون متغيرة، يرفع ClickHouse هذا القيد وهذا العبء عن المستخدم من خلال تخزين السلاسل النصية كبايتات من دون فرض ترميز معيّن. لذلك فإن نوع String في ClickHouse لا يفرض أي حدود أو متطلبات لتحديد الطول.
علاوة على ذلك، يمكنك الاستفادة من Arrays وTuples وEnums - وهي غير متوفرة في
Redshift كأنواع من الدرجة الأولى (مع أنه يمكن محاكاة Arrays/Structs
باستخدام SUPER) - وهو ما يشكّل مصدر إحباط شائعًا للمستخدمين. ويتيح ClickHouse أيضًا
الاحتفاظ بحالات التجميع، سواء في وقت الاستعلام أو حتى داخل
جدول. وهذا يتيح إجراء تجميع مسبق للبيانات، عادةً باستخدام
عرض مادي، ويمكن أن يحسّن أداء الاستعلام
بشكل كبير في الاستعلامات الشائعة.
فيما يلي نبيّن نوع ClickHouse المكافئ لكل نوع في Redshift:
| Redshift | ClickHouse |
|---|---|
SMALLINT |
Int8 * |
INTEGER |
Int32 * |
BIGINT |
Int64 * |
DECIMAL |
UInt128, UInt256, Int128, Int256, Decimal(P, S), Decimal32(S), Decimal64(S), Decimal128(S), Decimal256(S) - (بدقة عالية ونطاقات قيم كبيرة) |
REAL |
Float32 |
DOUBLE PRECISION |
Float64 |
BOOLEAN |
Bool |
CHAR |
String, FixedString |
VARCHAR ** |
String |
DATE |
Date32 |
TIMESTAMP |
DateTime, DateTime64 |
TIMESTAMPTZ |
DateTime, DateTime64 |
GEOMETRY |
أنواع البيانات الجغرافية المكانية |
GEOGRAPHY |
أنواع بيانات Geo (أقل تطورًا، فمثلًا لا تتضمن أنظمة إحداثيات، لكن يمكن محاكاتها باستخدام الدوال) |
HLLSKETCH |
AggregateFunction(uniqHLL12, X) |
SUPER |
Tuple, Nested, Array, JSON, Map |
TIME |
DateTime, DateTime64 |
TIMETZ |
DateTime, DateTime64 |
VARBYTE ** |
String بالاقتران مع دوال Bit والترميز |
UInt8، UInt32، UInt32، وUInt64.
**يكون نوع String في ClickHouse غير محدود افتراضيًا، ولكن يمكن تقييده بأطوال محددة باستخدام القيود.
بنية DDL
مفاتيح الفرز
لكلٍّ من ClickHouse وRedshift مفهوم «مفتاح الفرز»، الذي يحدّد
كيفية ترتيب البيانات عند تخزينها. ويعرّف Redshift مفتاح الفرز باستخدام
البند SORTKEY:
CREATE TABLE some_table(...) SORTKEY (column1, column2)في المقابل، يستخدم ClickHouse عبارة ORDER BY لتحديد ترتيب الفرز:
CREATE TABLE some_table(...) ENGINE = MergeTree ORDER BY (column1, column2)في معظم الحالات، يمكنك استخدام أعمدة مفتاح الفرز نفسها وبالترتيب نفسه في ClickHouse
كما في Redshift، بافتراض أنك تستخدم النوع COMPOUND الافتراضي. عند إضافة البيانات
إلى Redshift، ينبغي تشغيل الأمرين VACUUM وANALYZE لإعادة فرز
البيانات المضافة حديثًا وتحديث الإحصاءات الخاصة بمُخطِّط الاستعلام، وإلا
فستزداد المساحة غير المفروزة. ولا تتطلب ClickHouse أي عملية من هذا النوع.
يدعم Redshift ميزتين عمليتين لمفاتيح الفرز. الأولى هي
مفاتيح الفرز التلقائية (باستخدام SORTKEY AUTO). ومع أن هذا قد يكون مناسبًا
للبدء، فإن مفاتيح الفرز الصريحة تضمن أفضل أداء وأعلى كفاءة في التخزين عندما يكون
مفتاح الفرز مثاليًا. والثانية هي مفتاح الفرز INTERLEAVED،
الذي يمنح وزنًا متساويًا لمجموعة فرعية من الأعمدة ضمن مفتاح الفرز لتحسين
الأداء عندما يستخدم الاستعلام عمود فرز ثانويًا واحدًا أو أكثر. وتدعم ClickHouse
الإسقاطات الصريحة، التي تحقق
النتيجة النهائية نفسها مع اختلاف طفيف في الإعداد.
ينبغي أن تدرك أن مفهوم “المفتاح الأساسي” يمثل أشياء مختلفة في ClickHouse وRedshift. ففي Redshift، يشبه المفتاح الأساسي مفهوم RDBMS التقليدي المخصص لفرض القيود. ومع ذلك، فإن هذه القيود لا تُفرض بشكل صارم في Redshift، بل تعمل بدلًا من ذلك كتلميحات لمُخطِّط الاستعلام ولتوزيع البيانات بين العقد. أما في ClickHouse، فيشير المفتاح الأساسي إلى الأعمدة المستخدمة في إنشاء الفهرس الأساسي المتناثر، الذي يُستخدم لضمان ترتيب البيانات على القرص، بما يزيد الضغط إلى أقصى حد مع تجنب تضخيم الفهرس الأساسي و هدر الذاكرة.