الانتقال إلى المحتوى الرئيسي
يرث هذا المحرك من MergeTree، مع تعديل منطق دمج أجزاء البيانات. يستبدل ClickHouse جميع الصفوف التي لها نفس المفتاح الأساسي (أو، على نحو أدق، التي لها نفس مفتاح الفرز) بصف واحد (ضمن جزء بيانات واحد) يخزّن مزيجًا من حالات الدوال التجميعية. يمكنك استخدام جداول AggregatingMergeTree في التجميع التدريجي للبيانات، بما في ذلك العروض المُجسَّدة المُجمَّعة. يمكنك الاطّلاع على مثال لكيفية استخدام AggregatingMergeTree والدوال التجميعية في الفيديو أدناه:
يعالج هذا المحرك جميع الأعمدة ذات الأنواع التالية: يكون استخدام AggregatingMergeTree مناسبًا إذا كان يخفّض عدد الصفوف بعدة مراتب.

إنشاء جدول

للاطلاع على وصف معلمات الطلب، راجع وصف الطلب. بنود الاستعلام عند إنشاء جدول AggregatingMergeTree، تكون البنود نفسها مطلوبة كما عند إنشاء جدول MergeTree.

SELECT and INSERT

لإدراج البيانات، استخدم استعلام INSERT SELECT مع الدوال التجميعية ذات اللاحقة -State. عند تحديد البيانات من جدول AggregatingMergeTree، استخدم عبارة GROUP BY ونفس الدوال التجميعية المستخدمة عند إدراج البيانات، لكن باستخدام اللاحقة -Merge. في نتائج استعلام SELECT، تكون للقيم من النوع AggregateFunction تمثيلات ثنائية خاصة بالتنفيذ في جميع صيغ الإخراج في ClickHouse. على سبيل المثال، إذا فرّغت البيانات إلى صيغة TabSeparated باستخدام استعلام SELECT، فيمكن بعد ذلك إعادة تحميل هذا التفريغ باستخدام استعلام INSERT.

مثال على عرض مادي مجمَّع

يفترض المثال التالي أن لديك قاعدة بيانات باسم test. أنشئها إن لم تكن موجودة بالفعل باستخدام الأمر أدناه:
أنشئ الآن الجدول test.visits الذي يحتوي على البيانات الخام:
بعد ذلك، ستحتاج إلى جدول AggregatingMergeTree يخزّن AggregationFunctions لتتبع إجمالي عدد الزيارات وعدد المستخدمين الفريدين. أنشئ عرضاً مُجسَّداً من نوع AggregatingMergeTree يراقب جدول test.visits، ويستخدم النوع AggregateFunction:
أنشئ طريقة عرض مُجسَّدة تملأ test.agg_visits من test.visits:
أدخل البيانات في جدول test.visits:
يتم إدراج البيانات في كلٍّ من test.visits وtest.agg_visits. للحصول على البيانات المجمَّعة، نفِّذ استعلامًا مثل SELECT ... GROUP BY ... من الـ materialized view test.visits_mv:
أضف سجلَّين آخرَين إلى test.visits، لكن هذه المرة استخدم طابعاً زمنياً مختلفاً لأحد السجلَّين:
شغِّل استعلام SELECT مرةً أخرى، وسيُعيد الناتج الآتي:
في بعض الحالات، قد ترغب في تجنب التجميع المسبق للصفوف عند وقت الإدراج لنقل تكلفة التجميع من وقت الإدراج إلى وقت الدمج. في العادة، يكون من الضروري تضمين الأعمدة التي لا تشكّل جزءًا من التجميع في جملة GROUP BY الخاصة بتعريف الـ materialized view لتفادي حدوث خطأ. غير أنه يمكنك الاستفادة من الدالة initializeAggregation مع الإعداد optimize_on_insert = 0 (وهو مُفعَّل افتراضيًا) لتحقيق ذلك. في هذه الحالة، لم يعد استخدام GROUP BY ضروريًا:
عند استخدام initializeAggregation، تُنشأ حالة تجميع لكل row على حدة من دون إجراء تجميع. وينتج عن كل row مصدر row واحدة في العرض المادي، بينما يحدث التجميع الفعلي لاحقًا عندما يدمج AggregatingMergeTree الأجزاء. ولا يصحّ ذلك إلا إذا كانت optimize_on_insert = 0.

تجميع عناصر Tuple

عند تمكين الإعداد allow_tuple_element_aggregation، تُسطَّح أعمدة Tuple تكراريًا بحيث يشارك كل عنصر نهائي في التجميع بشكل مستقل. وهذا يعني أن الأعمدة الفرعية AggregateFunction أو SimpleAggregateFunction داخل Tuple تُجمَّع وفقًا لوظائفها الخاصة، تمامًا كما لو كانت أعمدة من المستوى الأعلى. تُستبعَد الأعمدة الفرعية التابعة لـ Tuple في مفتاح الفرز من التجميع. أمّا الأعمدة الفرعية غير التجميعية فتُعامَل كأعمدة عادية (تُحتفَظ بقيمتها الأولى).
هذا الإعداد غير قابل للتغيير ويجب تحديده عند إنشاء الجدول.
يُجمَّع total_visits باستخدام sum (100 + 200 = 300)، في حين يُجمَّع unique_users باستخدام max (max(5, 8) = 8).
آخر تعديل في ٢ يوليو ٢٠٢٦