دليل ترجمة SQL لـ Amazon Redshift

مرجع ترجمة SQL من Amazon Redshift إلى ClickHouse

​

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

سيلاحظ المستخدمون الذين ينقلون البيانات بين 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 والترميز

_{* يدعم ClickHouse أيضًا الأعداد الصحيحة غير الموقَّعة ذات النطاقات الممتدة، أي 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، فيشير المفتاح الأساسي إلى الأعمدة المستخدمة في إنشاء الفهرس الأساسي المتناثر، الذي يُستخدم لضمان ترتيب البيانات على القرص، بما يزيد الضغط إلى أقصى حد مع تجنب تضخيم الفهرس الأساسي و هدر الذاكرة.