Skip to main content
جميع أدلة البدء السريع
التحليلات اللحظيةمستودعات البياناتقابلية الرصدالذكاء الاصطناعي/تعلّم الآلةCloudOss

المتطلبات المسبقة

To successfully follow this guide, you’ll need the following: يجب أيضًا أن تكون قد أكملت الدليل التمهيدي السريع إنشاء أول جدول MergeTree، لأن هذا الدليل يعتمد مباشرةً على جدول uk_price_paid الذي تم إنشاؤه هناك.

ما الذي ستبنيه

في الدليل السريع لـ MergeTree، رأيت أن الاستعلام عن uk_price_paid حسب town أو county يتطلب فحصًا كاملًا للجدول، لأن الجدول مُرتَّب وفق (postcode, addr1, addr2). في هذا الدليل السريع، ستحل هذه المشكلة بإنشاء عرض مادي يخزّن البيانات نفسها مرتبةً وفق (town, date)، مما يتيح عمليات بحث سريعة حسب البلدة من دون تغيير جدولك الأصلي. وبنهاية هذا الدليل، ستفهم كيف تعمل العروض المادية كمشغّلات إدراج، وكيفية تنفيذ backfill للبيانات الموجودة، والمفاضلة في مساحة القرص الناتجة عن تخزين البيانات مرتين.
1

افهم سبب حاجتك إلى materialized view

الجدول uk_price_paid لديك مرتّب حسب (postcode, addr1, addr2). وهذا يعني أن ClickHouse يمكنه تخطي كتل كبيرة من البيانات عند التصفية حسب postcode أو addr1 أو addr2، لكن الاستعلامات التي تُصفّي حسب town يجب أن تفحص كل صف — أي الصفوف الثلاثين مليونًا كلها.يمكنك إنشاء جدول ثانٍ باستخدام ORDER BY مختلف، لكنك ستحتاج عندها إلى تذكّر الإدراج في كلا الجدولين كلما وصلت بيانات جديدة. تعمل materialized view على أتمتة ذلك: فهي تراقب عمليات الإدراج إلى جدول مصدر، وتحوّل الصفوف، ثم تكتبها تلقائيًا إلى جدول الوجهة.فكّر في materialized view على أنها insert trigger — ففي كل مرة تُدرَج فيها صفوف في الجدول المصدر، يُشغَّل استعلام SELECT الخاص بـ MV على الكتلة الجديدة من الصفوف، وتُدرَج النتيجة في جدول الوجهة.
2

أنشئ جدول الوجهة

يحتاج العرض المُجسَّد إلى مكان لتخزين مخرجاته. هذا مجرد جدول MergeTree عادي — ولديك تحكّم كامل في مخططه، وORDER BY، وPARTITION BY.أنشئ جدولًا مُرتَّبًا حسب (town, date) ويحتوي فقط على الأعمدة التي تحتاجها للاستعلامات المستندة إلى المدينة:
لا يوجد ما يميّز هذا الجدول - فهو جدول MergeTree عادي. أما العرض المُجسَّد الذي ستنشئه بعد ذلك، فسيقوم ببساطة بتوجيه البيانات إليه.تحقّق من إنشاء الجدول:
3

إنشاء العرض المادي

أنشئ الآن العرض المادي الذي يربط بين جدول المصدر (uk_price_paid) وجدول الوجهة (uk_price_paid_by_town):
يوضّح بند TO uk_price_paid_by_town لـ ClickHouse أن يكتب ناتج SELECT في جدول الوجهة. ومن الآن فصاعدًا، في كل مرة تُدرَج فيها rows في uk_price_paid، يُفعَّل هذا MV ويُدرِج الـ rows المحوَّلة في uk_price_paid_by_town.هناك تحذير مهم: لا تُفعَّل materialized views إلا عند عمليات الإدراج. إذا حذفت rows أو حدّثتها في source table، فلن يكون لدى destination table أي علم بذلك - لأن MVs لا تبقى متزامنة مع عمليات الحذف أو التحديث. وإذا كنت بحاجة إلى هذا النوع من المزامنة، ففكّر في استخدام الإسقاطات بدلًا من ذلك.
4

استكمال البيانات الحالية

يعالج العرض المادي فقط عمليات الإدراج اللاحقة. وقد أُدرجت بالفعل 30 مليون صف في uk_price_paid قبل إنشاء MV، لذا فإن الجدول الهدف فارغ حاليًا.قم باستكمالها يدويًا:
يُدرِج هذا البيانات مباشرةً في الجدول الوجهة - ولا يكون MV ضمن هذه الخطوة. بعد اكتمال ذلك، تحقّق من تطابق أعداد الصفوف:
يجب أن يحتوي الجدولان على العدد نفسه من الصفوف.
5

الاستعلام عن جدول وجهة العرض المُجسَّد

نفّذ الآن استعلامًا يرشّح حسب town على جدول الوجهة، ثم قارنه بالاستعلام على الجدول المصدر مباشرةً.أولًا، استعلم عن الجدول المصدر:
تحقّق من إحصاءات الاستعلام — تُقرأ جميع الصفوف الثلاثين مليونًا لأن town ليس ضمن ORDER BY للجدول المصدر.الآن شغّل الاستعلام نفسه على الجدول الوجهة للعرض المادي:
تحقّق من إحصاءات الاستعلام مرة أخرى - سيُقرأ عدد أقل بكثير من الصفوف لأن جدول الوجهة مرتّب حسب (town, date)، ويمكن لـ ClickHouse تجاوز كل البيانات التي لا تطابق LONDON.شغّل SHOW TABLES لمعرفة ما تم إنشاؤه:
سترى كلاً من uk_price_paid_by_town (جدول الوجهة) وuk_price_paid_by_town_mv (العرض). وبما أنك استخدمت CREATE MATERIALIZED VIEW ... TO، فأنت تتحكم في اسم جدول الوجهة. وإذا حذفت عبارة TO، فسينشئ ClickHouse جدول وجهة باسم ضمني (.inner.xxx) يصعب التعامل معه مباشرةً. لذلك، يُنصح بإنشاء العروض المادية باستخدام عبارة TO.
6

لاحظ أن البيانات تُخزَّن مرتين

تمنحك العروض المادية سرعة قراءة أعلى مقابل استهلاك مساحة إضافية على القرص. نفِّذ استعلامًا على system.parts لمعرفة مقدار المساحة التي يستخدمها كل جدول:
تُخزَّن البيانات فعليًا مرتين: مرة في uk_price_paid مرتبة حسب (postcode, addr1, addr2)، ومرة في uk_price_paid_by_town مرتبة حسب (town, date). وهذه هي المفاضلة الأساسية: تستخدم مساحة أكبر على القرص مقابل عمليات قراءة أسرع لأنماط وصول مختلفة.قد يكون الجدول الوجهة أصغر حجمًا على القرص لأنه يحتوي على أعمدة أقل، وقد يُضغط ترتيب الفرز (town, date) بطريقة مختلفة عن الترتيب الأصلي.

الخطوات التالية

في هذا الدليل السريع، أنشأتَ عرضًا ماديًا لتخزين بيانات مبيعات العقارات في المملكة المتحدة بترتيب فرز مختلف، ما يتيح عمليات بحث سريعة حسب البلدة من دون تعديل الجدول الأصلي. وتعلّمتَ أن العروض المادية تعمل كمشغّلات إدراج، وأنه يجب تعبئة البيانات الموجودة مسبقًا يدويًا، وأن المقابل لذلك هو استخدام مساحة إضافية على القرص. اطّلع بعد ذلك على أدلة البدء السريع التالية: أو تعمّق أكثر من خلال الوثائق المرجعية:
ClickHouse Academy — Master ClickHouse with expert-designed training for every skill level

Check out the ClickHouse academy for on-demand and live training

Last modified on July 2, 2026