يدعم ClickHouse نوعين من العروض المادية: التزايدية والقابلة للتحديث. ورغم أن كلاهما مُصمَّم لتسريع الاستعلامات من خلال الحساب المسبق للنتائج وتخزينها، فإنهما يختلفان اختلافًا كبيرًا في كيفية تنفيذ الاستعلامات الأساسية وتوقيت تنفيذها، وأي أحمال العمل تناسب كلًّا منهما، وكيفية التعامل مع حداثة البيانات.
ينبغي التفكير في استخدام العروض المادية لأنماط استعلامات محددة تحتاج إلى تسريع، على افتراض أنه قد جرى مسبقًا تطبيق أفضل الممارسات المتعلقة بنوع البيانات وتحسين المفتاح الأساسي.
العروض المادية التزايدية تُحدَّث في الوقت الفعلي. فعند إدراج بيانات جديدة في الجدول المصدر، يطبّق ClickHouse تلقائيًا استعلام العرض المادي على كتلة البيانات الجديدة ويكتب النتائج في جدول هدف منفصل. ومع مرور الوقت، يدمج ClickHouse هذه النتائج الجزئية لإنتاج عرض كامل ومحدَّث باستمرار. ويُعد هذا النهج عالي الكفاءة لأنه ينقل الكلفة الحسابية إلى وقت الإدراج ولا يعالج إلا البيانات الجديدة. ونتيجة لذلك، تكون استعلامات SELECT على الجدول الهدف سريعة وخفيفة. وتدعم العروض التزايدية جميع دوال التجميع، كما أنها تتوسع بكفاءة — حتى إلى بيتابايتات من البيانات — لأن كل استعلام يعمل على مجموعة فرعية صغيرة وحديثة من مجموعة البيانات الجاري إدراجها.
العروض المادية القابلة للتحديث، في المقابل، تُحدَّث وفق جدول زمني. إذ تعيد هذه العروض تنفيذ استعلامها الكامل دوريًا وتستبدل النتيجة في الجدول الهدف. وهذا يشبه العروض المادية في قواعد بيانات OLTP التقليدية مثل Postgres.
يعتمد الاختيار بين العروض المادية التزايدية والقابلة للتحديث إلى حد كبير على طبيعة الاستعلام، ومعدل تغيّر البيانات، وما إذا كان يجب أن تعكس تحديثات العرض كل صف عند إدراجه، أو ما إذا كان التحديث الدوري مقبولًا. ويُعد فهم هذه المفاضلات أمرًا أساسيًا لتصميم عروض مادية عالية الأداء وقابلة للتوسع في ClickHouse.
متى تستخدم العروض المادية التزايدية
- تحتاج إلى نتائج استعلام في الوقت الفعلي تُحدَّث مع كل عملية إدراج.
- تُجري عمليات تجميع أو تصفية لكميات كبيرة من البيانات بشكل متكرر.
- تتضمن استعلاماتك تحويلات مباشرة أو عمليات تجميع على جداول مفردة.
للاطلاع على أمثلة للعروض المادية التزايدية، راجع هنا.
متى تستخدم العروض المادية القابلة للتحديث
- تحتاج إلى نتائج استعلام مخزنة مؤقتًا ومتاحة فورًا، ويكون التأخير الطفيف في حداثة البيانات مقبولًا.
- تحتاج إلى أعلى N من مجموعة نتائج استعلام.
- لا ينمو حجم مجموعة النتائج بلا حدود مع مرور الوقت. إذ سيؤدي ذلك إلى تدهور أداء العرض المستهدف.
- تُجري عمليات JOIN معقدة أو إزالة تطبيع تشمل جداول متعددة، وتتطلب تحديثات كلما تغيّر أي جدول مصدر.
- تنشئ مسارات عمل على دفعات، أو مهام إزالة تطبيع، أو تبعيات للعروض مشابهة لـ DBT DAGs.
للاطلاع على أمثلة للعروض المادية القابلة للتحديث، راجع هنا.
تدعم العروض المادية القابلة للتحديث وضعين لكتابة البيانات إلى الجدول الهدف: APPEND وREPLACE. ويحددان هذان الوضعان كيفية كتابة نتيجة استعلام العرض عند تحديثه.
يُعد REPLACE السلوك الافتراضي. ففي كل مرة يُحدَّث فيها العرض، تُستبدل المحتويات السابقة للجدول الهدف بالكامل بأحدث نتيجة للاستعلام. وهذا مناسب لحالات الاستخدام التي يجب أن يعكس فيها العرض دائمًا أحدث حالة، مثل التخزين المؤقت لمجموعة نتائج.
أما APPEND، فيسمح بإضافة صفوف جديدة إلى نهاية الجدول الهدف بدلًا من استبدال محتوياته. ويتيح ذلك حالات استخدام إضافية، مثل التقاط لقطات دورية. ويكون APPEND مفيدًا بشكل خاص عندما يمثّل كل تحديث نقطة زمنية مستقلة، أو عندما يكون الاحتفاظ بتراكم تاريخي للنتائج أمرًا مطلوبًا.
اختر وضع APPEND عندما:
- تريد الاحتفاظ بسجل لعمليات التحديث السابقة.
- كنت تنشئ لقطات دورية أو تقارير.
- كنت بحاجة إلى جمع النتائج المُحدَّثة تدريجيًا بمرور الوقت.
اختر وضع REPLACE عندما:
- كنت تحتاج فقط إلى أحدث نتيجة.
- يجب التخلّص من البيانات القديمة بالكامل.
- كان العرض يمثّل حالة حالية أو عملية lookup.
يمكنك الاطلاع على أحد استخدامات APPEND عند بناء بنية الميدالية. آخر تعديل في ٢ يوليو ٢٠٢٦
