ClickStack - العروض المادية

ضبط الأداء في ClickStack باستخدام العروض المادية

​

المقدمة

يمكن لـ ClickStack الاستفادة من العروض المادية التزايدية (IMV) لتسريع المرئيات التي تعتمد على استعلامات كثيفة التجميع، مثل احتساب متوسط مدة الطلب لكل دقيقة بمرور الوقت. ويمكن لهذه الميزة أن تحسّن أداء الاستعلامات بشكل كبير، وعادةً ما تكون أكثر فائدة في عمليات النشر الأكبر، بحجم يقارب 10 تيرابايت يوميًا فأكثر، مع إتاحة التوسع إلى نطاق بيتابايتات يوميًا. لا تزال العروض المادية التزايدية في مرحلة Beta ويجب استخدامها بحذر.

يمكن للتنبيهات أيضًا الاستفادة من العروض المادية، وستستخدمها تلقائيًا. وقد يقلّل ذلك العبء الحوسبي الناتج عن تشغيل عدد كبير من التنبيهات، لا سيما أنها تعمل عادةً بوتيرة متكررة جدًا. ويمكن أن يكون تقليل زمن التنفيذ مفيدًا من حيث كلٍّ من سرعة الاستجابة واستهلاك الموارد.

​

ما هي العروض المادية التزايدية

تتيح لك العروض المادية التزايدية نقل تكلفة المعالجة من وقت الاستعلام إلى وقت الإدراج، مما يؤدي إلى تسريع استعلامات SELECT بشكل ملحوظ.

على عكس قواعد البيانات المعاملاتية مثل Postgres، لا يكون العرض المادي في ClickHouse لقطة محفوظة. بل يعمل كمُشغِّل ينفّذ استعلامًا على كتل البيانات عند إدراجها في جدول المصدر. ويُكتَب ناتج هذا الاستعلام في جدول هدف منفصل. ومع إدراج المزيد من البيانات، تُلحَق نتائج جزئية جديدة وتُدمَج في الجدول الهدف. وتكون النتيجة المدمجة مكافئة لتنفيذ التجميع على مجموعة البيانات الأصلية بالكامل.

يكمن الدافع الرئيسي لاستخدام العروض المادية في أن البيانات المكتوبة إلى الجدول الهدف تمثل ناتج عملية تجميع أو تصفية أو تحويل. وفي ClickStack، تُستخدم هذه العروض حصريًا لعمليات التجميع. وتكون هذه النتائج عادةً أصغر بكثير من بيانات الإدخال الخام، وغالبًا ما تمثل حالات تجميع جزئية. وإلى جانب سهولة الاستعلام عن الجدول الهدف المجمّع مسبقًا، يؤدي ذلك إلى خفض كبير في زمن استجابة الاستعلام مقارنةً بتنفيذ المعالجة نفسها على البيانات الخام وقت الاستعلام.

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

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

يختلف هذا النموذج جذريًا عن الأنظمة التي تعيد حساب العروض كاملةً عند كل تحديث أو تعتمد على تحديثات مجدولة. ولمزيد من التعمق في كيفية عمل العروض المادية وكيفية إنشائها، راجع الدليل المشار إليه أعلاه.

يضيف كل عرض مادي حملًا إضافيًا وقت الإدراج، لذا ينبغي استخدامه بصورة انتقائية.

أنشئ العروض فقط لأكثر لوحات المعلومات والتصورات شيوعًا. احصر الاستخدام في أقل من 20 عرضًا ما دامت الميزة في المرحلة التجريبية. ومن المتوقع أن يرتفع هذا الحد في الإصدارات المستقبلية.

يمكن لعرض مادي واحد حساب عدة مقاييس لتجميعات مختلفة، مثل الحد الأدنى والحد الأقصى ومدة p95 لكل اسم خدمة ضمن نوافذ زمنية مدتها دقيقة واحدة. وهذا يتيح لعرض واحد خدمة العديد من التصورات بدلًا من تصور واحد فقط. لذلك، فإن توحيد المقاييس في عروض مشتركة مهم لتحقيق أقصى استفادة من كل عرض وضمان إعادة استخدامه عبر لوحات المعلومات وسير العمل.

قبل المتابعة، يُنصح بالتعمق أكثر في فهم العروض المادية في ClickHouse. راجع دليلنا حول العروض المادية التزايدية لمزيد من التفاصيل.

​

اختيار المرئيات المراد تسريعها

قبل إنشاء أي عروض مادية، من المهم فهم المرئيات التي تريد تسريعها وأيّ مسارات العمل تُعدّ الأكثر أهمية لمستخدميك.

في ClickStack، صُمِّمت العروض المادية لتسريع المرئيات التي تعتمد بكثافة على التجميع، أي الاستعلامات التي تحسب مقياسًا واحدًا أو أكثر بمرور الوقت. وتشمل الأمثلة متوسط مدة الطلب لكل دقيقة، وعدد الطلبات لكل خدمة، أو معدلات الخطأ بمرور الوقت. ويجب أن يتضمن العرض المادي دائمًا عملية تجميع وتقسيمًا زمنيًا، لأنه مخصّص لخدمة مرئيات السلاسل الزمنية.

بوجه عام، يُوصى بما يلي:

​

تحديد المرئيات عالية التأثير

عادةً ما تندرج أفضل المرشحين للتسريع ضمن إحدى الفئات التالية:

• مرئيات لوحة المعلومات التي تتحدّث باستمرار وتظل معروضة بشكل دائم، مثل لوحات معلومات Monitoring عالية المستوى المعروضة على شاشات الحائط.
• سير العمل التشخيصي المستخدم في أدلة التشغيل، حيث يُرجع مرارًا إلى مخططات معيّنة أثناء الاستجابة للحوادث، وتحتاج إلى عرض النتائج بسرعة.
• التجارب الأساسية في HyperDX، بما في ذلك:
  • عروض المدرج التكراري في صفحة Search.
  • المرئيات المستخدمة في لوحات المعلومات المُعدّة مسبقًا، مثل عروض APM أو Services أو Kubernetes.

غالبًا ما تُنفَّذ هذه المرئيات بشكل متكرر عبر مستخدمين ونطاقات زمنية مختلفة، ما يجعلها أهدافًا مثالية لنقل المعالجة من وقت تنفيذ الاستعلام إلى وقت الإدراج.

​

وازن بين الفائدة والتكلفة عند الإدراج

تضيف العروض المُجسَّدة عملاً إضافيًا عند الإدراج، لذا ينبغي إنشاؤها بشكل انتقائي ومقصود. ليست كل المرئيات تستفيد من التجميع المسبق، وعادةً لا يستحق تسريع المخططات قليلة الاستخدام هذا العبء الإضافي. ينبغي أن يظل العدد الإجمالي للعروض المُجسَّدة أقل من 20.

قبل الانتقال إلى بيئة الإنتاج، احرص دائمًا على التحقق من عبء الموارد الإضافي الذي تسببه العروض المُجسَّدة، وخصوصًا استخدام CPU وعمليات I/O على القرص ونشاط الدمج. يزيد كل عرض مُجسَّد من العمل عند الإدراج ويسهم في إضافة المزيد من الأجزاء، لذا من المهم التأكد من أن عمليات الدمج قادرة على مواكبة ذلك وأن يظل عدد الأجزاء مستقرًا. يمكن مراقبة ذلك عبر جداول النظام ولوحة معلومات observability المتقدمة المضمّنة في ClickHouse مفتوح المصدر، أو باستخدام المقاييس المضمّنة ولوحات معلومات المراقبة في ClickHouse Cloud. راجع Too many parts للحصول على إرشادات حول تشخيص الزيادة المفرطة في عدد الأجزاء والحد منها.

بمجرد تحديد المرئيات الأكثر أهمية، تكون الخطوة التالية هي الدمج.

​

تجميع المرئيات في عروض مشتركة

يجب أن تُجمِّع جميع العروض المادية في ClickStack البيانات حسب فاصل زمني باستخدام دوال مثل toStartOfMinute. ومع ذلك، تشترك كثير من المرئيات أيضًا في مفاتيح تجميع إضافية مثل اسم الخدمة أو اسم span أو رمز الحالة. وعندما تستخدم عدة مرئيات أبعاد التجميع نفسها، يمكن في كثير من الأحيان خدمتها من خلال عرض مادي واحد.

على سبيل المثال (بالنسبة إلى التتبعات):

• متوسط المدة حسب اسم الخدمة عبر الزمن - SELECT avg(Duration), toStartOfMinute(Timestamp) as time, ServiceName FROM otel_traces GROUP BY ServiceName, time
• عدد الطلبات حسب اسم الخدمة عبر الزمن - SELECT count() count, toStartOfMinute(Timestamp) as time, ServiceName FROM otel_traces GROUP BY ServiceName, time
• متوسط المدة حسب رمز الحالة عبر الزمن - SELECT avg(Duration), toStartOfMinute(Timestamp) as time, StatusCode FROM otel_traces GROUP BY StatusCode, time
• عدد الطلبات حسب رمز الحالة عبر الزمن - SELECT count() count, toStartOfMinute(Timestamp) as time, StatusCode FROM otel_traces GROUP BY StatusCode, time

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

SELECT avg(Duration), max(Duration), count(), quantiles(0.95,0.99)(Duration), toStartOfMinute(Timestamp) as time, ServiceName, StatusCode
FROM otel_traces
GROUP BY time, ServiceName, StatusCode

يؤدي دمج طرق العرض بهذه الطريقة إلى تقليل الحمل الإضافي وقت الإدراج، والحد من العدد الإجمالي للعروض المادية، وتقليل المشكلات المرتبطة بعدد الأجزاء، وتبسيط أعمال الصيانة المستمرة.

في هذه المرحلة، ركّز على الاستعلامات التي ستُنفَّذ بواسطة التصوّرات المرئية التي تريد تسريعها. في القسم التالي، سترى مثالًا يوضّح كيف يمكن دمج عدة استعلامات تجميع في عرض مادي واحد.

​

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

بمجرد تحديد مرئية، أو مجموعة من المرئيات، التي تريد تسريعها، تتمثل الخطوة التالية في تحديد الاستعلامات الأساسية التي تستند إليها. وعمليًا، يعني ذلك فحص إعدادات المرئية ومراجعة SQL المُنشأ، مع إيلاء اهتمام خاص لمقاييس التجميع المستخدمة والدوال المطبقة.

في الحالات التي لا تتوفر فيها لوحة تصحيح داخل HyperDX لأحد المكوّنات، يمكن للمستخدمين فحص وحدة تحكم المتصفح، حيث تُسجَّل جميع الاستعلامات.

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

للمرجع، توفّر ClickHouse في التوثيق نظرة عامة مفصلة وأمثلة على دوال حالات التجميع، ومحرك الجدول المستخدم لتخزينها - AggregatingMergeTree -:

• الدوال المجمِّعة والحالات
• محرك AggregatingMergeTree

يمكنك الاطلاع على مثال يوضح كيفية استخدام AggregatingMergeTree والدوال المجمِّعة في الفيديو أدناه:

يُنصح بشدة بالتعرّف على هذه المفاهيم قبل المتابعة.

​

مثال على عرض مادي

تأمل الاستعلام الأصلي التالي، الذي يحسب متوسط المدة والمدة القصوى وعدد الأحداث والنِّسب المئوية لكل دقيقة، مع التجميع حسب اسم الخدمة ورمز الحالة:

SELECT
    toStartOfMinute(Timestamp),
    ServiceName,
    StatusCode,
    count() AS count,
    avg(Duration),
    max(Duration),
    quantiles(0.95, 0.99)(Duration)
FROM otel_traces
GROUP BY
    time,
    ServiceName,
    StatusCode

لتسريع هذا الاستعلام، أنشئ الجدول الهدف otel_traces_1m، الذي يخزّن حالات التجميع المرتبطة به:

CREATE TABLE otel_traces_1m
(
    `Timestamp` DateTime,
    `ServiceName` LowCardinality(String),
    `StatusCode` LowCardinality(String),
    `count` SimpleAggregateFunction(sum, UInt64),
    `avg__Duration` AggregateFunction(avg, UInt64),
    `max__Duration` SimpleAggregateFunction(max, Int64),
    `quantiles__Duration` AggregateFunction(quantiles(0.95, 0.99), Int64)
)
ENGINE = AggregatingMergeTree
ORDER BY (Timestamp, ServiceName, StatusCode);

ثم يقوم تعريف العرض المادي - otel_traces_1m_mv - بحساب هذه الحالات وكتابتها كلما أُدرجت بيانات جديدة:

CREATE MATERIALIZED VIEW otel_traces_1m_mv TO otel_traces_1m
AS
SELECT
    toStartOfMinute(Timestamp) AS Timestamp,
    ServiceName,
    StatusCode,
    count() AS count,
    avgState(Duration) AS avg__Duration,
    maxSimpleState(Duration) AS max__Duration,
    quantilesState(0.95, 0.99)(Duration) AS quantiles__Duration
FROM otel_v2.otel_traces
GROUP BY
    Timestamp,
    ServiceName,
    StatusCode;

يتكوّن هذا العرض المادي من جزأين:

1. الجدول الهدف، الذي يحدّد المخطط وأنواع حالات التجميع المستخدمة لتخزين النتائج الوسيطة. ويُلزم استخدام المحرك AggregatingMergeTree لضمان دمج هذه الحالات بشكل صحيح في الخلفية.
2. يُنفَّذ استعلام العرض المادي تلقائيًا عند الإدراج. وبالمقارنة مع الاستعلام الأصلي، فإنه يستخدم دوال الحالة مثل avgState وquantilesState بدلًا من دوال التجميع النهائية.

والنتيجة هي جدول صغير الحجم يخزّن حالات التجميع لكل دقيقة لكل اسم خدمة ورمز حالة. وينمو حجمه بصورة متوقعة مع الوقت والتعددية، وبعد عمليات الدمج في الخلفية، يمثّل النتيجة نفسها الناتجة عن تشغيل التجميع الأصلي على البيانات الخام. كما أن الاستعلام عن هذا الجدول أقل تكلفة بكثير من إجراء التجميع مباشرةً من جدول التتبعات المصدر، مما يتيح أداءً سريعًا ومتسقًا لعمليات التصور على نطاق واسع.

​

استخدام العروض المادية في ClickStack

بمجرد إنشاء العروض المادية في ClickHouse، يجب تسجيلها في ClickStack لكي تُستخدم تلقائيًا في المرئيات ولوحات المعلومات والتنبيهات.

​

تسجيل عرض مادي للاستخدام

يجب تسجيل العروض المادية ضمن المصدر في HyperDX الذي يقابل الجدول المصدر الأصلي الذي اشتُقّ منه العرض.

1. ​

   حرّر المصدر

   انتقل إلى المصدر المعني في HyperDX وافتح مربع الحوار تحرير الإعدادات. مرّر إلى قسم العروض المادية.

2. ​

   أضف العرض المادي

   حدّد إضافة عرض مادي، ثم اختر قاعدة البيانات والجدول الهدف اللذين يستندان إليه العرض المادي.

3. ​

   حدّد المقاييس

   في معظم الحالات، سيُستدل تلقائيًا على أعمدة الطابع الزمني والبُعد والمقياس. وإذا لم يحدث ذلك، فحدّدها يدويًا.

   بالنسبة إلى المقاييس، يجب عليك ربط:

   • اسم العمود الأصلي، على سبيل المثال Duration، بـ
   • عمود التجميع المقابل في العرض المادي، على سبيل المثال avg__Duration

   أما بالنسبة إلى الأبعاد، فحدّد جميع الأعمدة، باستثناء الطابع الزمني، التي يُجري العرض التجميع على أساسها.

4. ​

   حدّد درجة الدقة الزمنية

   حدّد درجة الدقة الزمنية للعرض المادي، على سبيل المثال دقيقة واحدة.

5. ​

   حدّد الحد الأدنى للتاريخ

   حدّد الحد الأدنى للتاريخ الذي تتوفر له بيانات في العرض المادي. ويمثّل ذلك أقدم طابع زمني متاح في العرض، ويكون عادةً وقت إنشاء العرض، بافتراض أن الاستيعاب كان مستمرًا.

   العروض المادية لا تُملأ تلقائيًا ببيانات تاريخية عند إنشائها، لذا لن تحتوي إلا على الصفوف الناتجة عن البيانات المُدرجة بعد الإنشاء. يمكن العثور على دليل كامل حول التعبئة بالبيانات التاريخية للعروض المادية ضمن “التعبئة بالبيانات التاريخية.”

   إذا لم يكن وقت البدء الدقيق واضحًا، فيمكنك تحديده عبر الاستعلام عن الحد الأدنى للطابع الزمني من الجدول الهدف، على سبيل المثال:

   SELECT min(Timestamp) FROM otel_traces_1m
   
6. ​

   احفظ المصدر

   احفظ إعدادات المصدر.

بمجرد تسجيل عرض مادي، سيستخدمه ClickStack تلقائيًا كلما كان الاستعلام مؤهلًا لذلك، من دون الحاجة إلى إجراء تغييرات على لوحات المعلومات أو التصوّرات المرئية أو التنبيهات. ويقيّم ClickStack كل استعلام وقت التنفيذ ويحدّد ما إذا كان يمكن تطبيق عرض مادي.

​

التحقق من التسريع في لوحات المعلومات والمرئيات

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

لن يستخدم ClickStack العرض المادي إلا إذا كان الحد الأدنى للطابع الزمني فيه أقل من أو يساوي بداية النطاق الزمني للاستعلام، بما يضمن أن العرض يحتوي على كل البيانات المطلوبة. ومع أن الاستعلامات تُقسَّم داخليًا إلى استعلامات فرعية قائمة على الوقت، فإن العروض المادية تُطبَّق إما على الاستعلام بالكامل أو لا تُطبَّق مطلقًا. وقد تتيح تحسينات مستقبلية استخدام العروض بصورة انتقائية مع الاستعلامات الفرعية المؤهلة.

يوفّر ClickStack مؤشرات مرئية واضحة لتأكيد ما إذا كان العرض المادي قيد الاستخدام.

1. تحقّق من حالة التحسين عند عرض لوحة معلومات أو مرئية، ابحث عن أيقونة الصاعقة أو Accelerated:

• تشير أيقونة الصاعقة الخضراء إلى أن الاستعلام مُسرَّع بواسطة عرض مادي.
• تشير أيقونة الصاعقة البرتقالية إلى أن الاستعلام يُنفَّذ على الجدول المصدر.

2. افحص تفاصيل التحسين انقر على أيقونة الصاعقة لفتح لوحة تفاصيل تعرض ما يلي:

• العرض المادي النشط: العرض المحدد للاستعلام، بما في ذلك العدد التقديري للصفوف.
• العروض المادية التي تم تخطيها: العروض المتوافقة التي لم يتم اختيارها، إلى جانب الأحجام التقديرية للمسح.
• العروض المادية غير المتوافقة: العروض التي تعذّر استخدامها والسبب المحدد لذلك.

3. افهم الأسباب الشائعة لعدم التوافق قد لا يتم استخدام العرض المادي إذا:

• كانت الفترة الزمنية للاستعلام تبدأ قبل الحد الأدنى للطابع الزمني الخاص بالعرض.
• لم تكن دقة المرئية من مضاعفات دقة العرض.
• لم تكن دالة التجميع المطلوبة في الاستعلام موجودة في العرض.
• كان الاستعلام يستخدم تعبيرات count مخصصة، مثل count(if(...))، ولا يمكن اشتقاقها من حالات التجميع الخاصة بالعرض.

تجعل هذه المؤشرات من السهل التأكد مما إذا كانت المرئية مُسرَّعة، وفهم سبب اختيار عرض معيّن، وتشخيص سبب عدم أهلية عرضٍ ما.

​

كيفية اختيار العروض المادية للمرئيات

عند تنفيذ مرئية، قد يتوفر لدى ClickStack عدة خيارات مرشحة، بما في ذلك الجدول الأساسي وعدة عروض مادية. ولضمان أفضل أداء، يقيّم ClickStack تلقائيًا الخيارات المتاحة ويختار الأكثر كفاءة باستخدام آلية ClickHouse EXPLAIN ESTIMATE.

تتبع عملية الاختيار تسلسلاً محددًا بوضوح:

1. التحقق من التوافق يحدد ClickStack أولاً ما إذا كان العرض المادي مناسبًا للاستعلام من خلال التحقق مما يلي:

   • التغطية الزمنية: يجب أن يقع النطاق الزمني للاستعلام بالكامل ضمن نطاق البيانات المتاح في العرض المادي.
   • درجة الدقة: يجب أن تكون حاوية الوقت في المرئية مساوية لدرجة دقة العرض أو أقل تفصيلاً منها.
   • التجميعات: يجب أن تكون المقاييس المطلوبة موجودة في العرض وقابلة للاحتساب من حالات التجميع الخاصة به.

2. تحويل الاستعلام بالنسبة إلى العروض المتوافقة، يعيد ClickStack كتابة الاستعلام بحيث يستهدف جدول العرض المادي:

   • تُطابَق دوال التجميع مع الأعمدة المادية المقابلة.
   • تُطبَّق الموحِّدات -Merge على حالات التجميع.
   • يُضبط تقسيم الوقت إلى حاويات ليتوافق مع درجة دقة العرض.

3. اختيار أفضل خيار مرشح إذا توفرت عدة عروض مادية متوافقة، يُشغّل ClickStack استعلام EXPLAIN ESTIMATE لكل خيار مرشح، ثم يقارن العدد التقديري للصفوف والحبيبات التي سيجري فحصها. ويُختار العرض ذو أقل تكلفة فحص تقديرية.

4. الرجوع الاحتياطي السلس إذا لم يكن أي عرض مادي متوافقًا، يعود ClickStack تلقائيًا إلى الاستعلام عن الجدول المصدر.

يقلل هذا النهج باستمرار حجم البيانات التي يجري فحصها، ويوفر أداءً منخفض الكمون وقابلًا للتنبؤ من دون الحاجة إلى تغيير تعريفات المرئيات.

تظل العروض المادية مؤهلة حتى عندما تتضمن المرئيات عوامل تصفية أو قيود بحث أو تقسيمًا زمنيًا إلى حاويات، شريطة أن تكون جميع الأبعاد المطلوبة موجودة في العرض. ويتيح ذلك للعروض تسريع لوحات المعلومات والمدرجات التكرارية والمخططات المُرشَّحة من دون الحاجة إلى تغيير تعريفات المرئيات.

​

مثال على اختيار العروض المادية

لنفترض وجود عرضين ماديين أُنشِئا على مصدر التتبّع نفسه:

• otel_traces_1m، مُجمَّع حسب الدقيقة وServiceName وStatusCode
• otel_traces_1m_v2، مُجمَّع حسب الدقيقة وServiceName وStatusCode وSpanName

يحتوي العرض الثاني على مفاتيح تجميع إضافية، ولذلك يُنتج عددًا أكبر من الصفوف ويفحص بيانات أكثر.

إذا طلبت مرئية متوسط المدة لكل خدمة بمرور الوقت، فالعرضان صالحان تقنيًا. يُنفِّذ ClickStack استعلام EXPLAIN ESTIMATE لكل مرشّح ويقارن أعداد granule التقديرية، أي:

EXPLAIN ESTIMATE
SELECT
    toStartOfHour(Timestamp) AS hour,
    ServiceName,
    avgMerge(avg__Duration) AS avg__Duration
FROM otel_v2.otel_traces_1m
GROUP BY
    hour,
    ServiceName
ORDER BY hour DESC

┌─database─┬─table──────────┬─parts─┬──rows─┬─marks─┐
│ otel_v2  │ otel_traces_1m │     1 │ 49385 │     6 │
└──────────┴────────────────┴───────┴───────┴───────┘

1 row in set. Elapsed: 0.009 sec.

EXPLAIN ESTIMATE
SELECT
    toStartOfHour(Timestamp) AS hour,
    ServiceName,
    avgMerge(avg__Duration) AS avg__Duration
FROM otel_v2.otel_traces_1m_v2
GROUP BY
    hour,
    ServiceName
ORDER BY hour DESC

┌─database─┬─table─────────────┬─parts─┬───rows─┬─marks─┐
│ otel_v2  │ otel_traces_1m_v2 │     1 │ 212519 │    26 │
└──────────┴───────────────────┴───────┴────────┴───────┘

1 row in set. Elapsed: 0.004 sec.

نظرًا لأن otel_traces_1m أصغر ويفحص عددًا أقل من الحبيبات، يُختار تلقائيًا.

لا يزال كلا العرضين الماديين يتفوّق على الاستعلام عن الجدول الأساسي مباشرةً، لكن اختيار أصغر عرض يفي بالغرض يحقق أفضل أداء.

​

التنبيهات

تستخدم استعلامات التنبيهات العروض المُجسَّدة تلقائيًا عندما تكون متوافقة. وينطبق منطق التحسين نفسه هنا أيضًا، مما يوفّر تقييمًا أسرع للتنبيهات.

​

تعبئة عرض مادي بالبيانات التاريخية

كما ذُكر سابقًا، لا تحتوي العروض المادية التزايدية إلا على البيانات التي أُدرجت بعد إنشاء العرض، ولا تُملأ تلقائيًا بالبيانات التاريخية. يحافظ هذا التصميم على خفة العروض وانخفاض تكلفة صيانتها، لكنه يعني أيضًا أنه لا يمكن استخدامها في الاستعلامات التي تتطلب بيانات أقدم من الحد الأدنى للطابع الزمني في العرض.

في معظم الحالات، يكون هذا مقبولًا. إذ تركز أعباء عمل ClickStack الشائعة على البيانات الحديثة، مثل آخر 24 ساعة، ما يعني أن العرض الذي أُنشئ حديثًا يصبح قابلًا للاستخدام الكامل خلال يوم من إنشائه. ومع ذلك، في الاستعلامات التي تمتد عبر نطاقات زمنية أطول، قد يظل العرض غير قابل للاستخدام إلى أن يمر وقت كافٍ.

في هذه الحالات، قد يفكر المستخدمون في تعبئة العرض المادي بالبيانات التاريخية.

قد تكون التعبئة بالبيانات التاريخية مكلفة حسابيًا. ففي التشغيل المعتاد، تُملأ العروض المادية تدريجيًا مع وصول البيانات، ما يوزع تكلفة المعالجة بالتساوي بمرور الوقت.

أما التعبئة بالبيانات التاريخية فتضغط هذا العمل في فترة أقصر بكثير، مما يزيد بشكل كبير من استخدام CPU والذاكرة لكل وحدة زمنية.

واعتمادًا على حجم مجموعة البيانات ونافذة الاحتفاظ، قد يتطلب ذلك توسيع العنقود مؤقتًا، رأسيًا أو أفقيًا في ClickHouse Cloud، لإكمال التعبئة خلال إطار زمني معقول.

وإذا لم تُوفَّر موارد إضافية، فقد تؤثر التعبئة بالبيانات التاريخية سلبًا في أعباء عمل بيئة الإنتاج، بما في ذلك زمن استجابة الاستعلامات ومعدل استيعاب البيانات. وبالنسبة إلى مجموعات البيانات الكبيرة جدًا أو النطاقات التاريخية الطويلة، قد تكون التعبئة بالبيانات التاريخية غير عملية، أو حتى غير ممكنة تمامًا.

وباختصار، غالبًا لا تستحق التعبئة بالبيانات التاريخية التكلفة والمخاطر التشغيلية. ولا ينبغي اللجوء إليها إلا في الحالات الاستثنائية التي يكون فيها تسريع الوصول إلى البيانات التاريخية أمرًا بالغ الأهمية. وإذا اخترت المتابعة، فيُوصى باتباع النهج المنضبط الموضح أدناه لتحقيق توازن بين الأداء والتكلفة والأثر على بيئة الإنتاج.

​

أساليب التعبئة التاريخية

تجنّب POPULATE

لا يُنصح باستخدام الأمر POPULATE للتعبئة التاريخية للعروض المادية إلا مع مجموعات البيانات الصغيرة التي يكون فيها الإدخال متوقفًا مؤقتًا. فقد يفوّت هذا الإجراء بعض الصفوف المُدرجة في الجدول المصدر، إذا أُنشئ العرض المادي بعد اكتمال عملية populate. بالإضافة إلى ذلك، يعمل هذا الخيار على جميع البيانات، ويكون عرضةً للانقطاعات أو لقيود الذاكرة عند التعامل مع مجموعات بيانات كبيرة.

لنفترض أنك تريد إجراء تعبئة تاريخية لعرض مادي يقابل عملية التجميع التالية، والتي تحسب المقاييس لكل دقيقة، مجمّعة حسب اسم الخدمة ورمز الحالة:

SELECT
    toStartOfMinute(Timestamp),
    ServiceName,
    StatusCode,
    count() AS count,
    avg(Duration),
    max(Duration),
    quantiles(0.95, 0.99)(Duration)
FROM otel_traces
GROUP BY
    time,
    ServiceName,
    StatusCode

كما ناقشنا سابقًا، لا تُملأ العروض المادية التزايدية بالبيانات التاريخية تلقائيًا. وتُوصى بالعمليات التالية لإضافة البيانات التاريخية بأمان مع الحفاظ على السلوك التزايدي للبيانات الجديدة.

​

التحميل بأثر رجعي مباشرةً باستخدام INSERT INTO SELECT

يُعد هذا النهج الأنسب لمجموعات البيانات الأصغر أو لاستعلامات التجميع الخفيفة نسبيًا، حيث يمكن إكمال التحميل بأثر رجعي بالكامل خلال مدة معقولة من دون استنزاف موارد المجموعة. ويكون مناسبًا عادةً عندما يمكن تشغيل استعلام التحميل بأثر رجعي في غضون دقائق، أو بحد أقصى بضع ساعات، وعندما تكون الزيادات المؤقتة في استخدام CPU وI/O مقبولة. أما بالنسبة إلى مجموعات البيانات الأكبر أو عمليات التجميع الأعلى كلفة، ففكّر بدلًا من ذلك في نهج التحميل بأثر رجعي التدريجي أو المعتمد على الكتل الموضّحين أدناه.

1. حدّد نطاق التغطية الحالي للعرض

   قبل محاولة أي تحميل بأثر رجعي، حدّد أولًا البيانات التي يحتوي عليها العرض المادي بالفعل. ويتم ذلك عبر الاستعلام عن الحد الأدنى للطابع الزمني الموجود في الجدول الهدف:

   SELECT min(Timestamp)
   FROM otel_traces_1m;
   

   يمثّل هذا الطابع الزمني أقدم نقطة يمكن للعرض تلبية الاستعلامات انطلاقًا منها. وأي استعلام من ClickStack يطلب بيانات أقدم من هذا الطابع الزمني سيعود إلى الجدول الأساسي.

2. قرّر ما إذا كان التحميل بأثر رجعي ضروريًا

   في معظم عمليات نشر ClickStack، تركّز الاستعلامات على البيانات الحديثة، مثل آخر 24 ساعة. في هذه الحالات، تصبح العروض المُنشأة حديثًا قابلة للاستخدام بالكامل بعد وقت قصير من إنشائها، ولا تكون هناك حاجة إلى التحميل بأثر رجعي.

   إذا كان الطابع الزمني الذي أُعيد في الخطوة السابقة قديمًا بما يكفي لحالات الاستخدام لديك، فلا حاجة إلى تحميل بأثر رجعي. ولا ينبغي النظر في التحميل بأثر رجعي إلا عندما:

   • تمتد الاستعلامات كثيرًا عبر نطاقات تاريخية طويلة.
   • يكون العرض بالغ الأهمية للأداء عبر تلك النطاقات.
   • يكون حجم مجموعة البيانات وكلفة التجميع مما يجعل التحميل بأثر رجعي ممكنًا عمليًا.
3. حمّل البيانات التاريخية المفقودة بأثر رجعي

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

   قد يعالج هذا الاستعلام كميات كبيرة من البيانات وقد يستهلك موارد كثيرة. تحقّق دائمًا من سعة CPU والذاكرة وI/O المتاحة قبل تشغيل تحميل بأثر رجعي. ومن الأساليب المفيدة تنفيذ الاستعلام أولًا باستخدام FORMAT Null لتقدير زمن التشغيل واستهلاك الموارد.

   إذا كان من المتوقع أن يستغرق الاستعلام نفسه ساعات طويلة، فإن هذا النهج غير موصى به.

   لاحظ كيف يضيف الاستعلام التالي عبارة WHERE لقصر التجميع على البيانات الأقدم من أقدم طابع زمني موجود في العرض:

   INSERT INTO otel_traces_1m
   SELECT
       toStartOfMinute(Timestamp) AS Timestamp,
       ServiceName,
       StatusCode,
       count() AS count,
       avgState(Duration) AS avg__Duration,
       maxSimpleState(Duration) AS max__Duration,
       quantilesState(0.95, 0.99)(Duration) AS quantiles__Duration
   FROM otel_traces
   WHERE Timestamp < (
       SELECT min(Timestamp) FROM otel_traces_1m
   )
   GROUP BY
       Timestamp,
       ServiceName,
       StatusCode;
   

​

التحميل بأثر رجعي التدريجي للبيانات التاريخية باستخدام جدول Null

بالنسبة إلى مجموعات البيانات الكبيرة أو استعلامات التجميع الأعلى استهلاكًا للموارد، قد يكون تنفيذ تحميل بأثر رجعي مباشر باستخدام تعليمة INSERT INTO SELECT واحدة غير عملي أو غير آمن. في هذه الحالات، يُنصح باتباع أسلوب التحميل بأثر رجعي التدريجي. تحاكي هذه الطريقة بشكل أوثق آلية عمل العروض المادية التدريجية عادةً، إذ تُعالَج البيانات على شكل كتل يمكن التحكم فيها بدلًا من تجميع كامل البيانات التاريخية دفعة واحدة.

يكون هذا الأسلوب مناسبًا في الحالات التالية:

• إذا كان استعلام التحميل بأثر رجعي سيستغرق ساعات طويلة للتنفيذ.
• إذا كانت ذروة استخدام الذاكرة عند تنفيذ تجميع كامل مرتفعة جدًا.
• إذا كنت تريد التحكم بدقة في استهلاك CPU والذاكرة أثناء التحميل بأثر رجعي.
• إذا كنت بحاجة إلى عملية أكثر تحمّلًا يمكن إعادة تشغيلها بأمان عند انقطاعها.

تتمثل الفكرة الأساسية في استخدام جدول Null كمخزن مؤقت للإدخال. ورغم أن جدول Null لا يخزّن البيانات، فإن أي عروض مادية مرتبطة به ستظل تُنفَّذ، مما يتيح احتساب حالات التجميع تدريجيًا أثناء مرور البيانات عبره.

1. إنشاء جدول Null للتحميل بأثر رجعي

   أنشئ جدول Null خفيفًا يحتوي فقط على الأعمدة المطلوبة لتجميع العرض المادي. وهذا يقلّل من استخدام عمليات الإدخال/الإخراج والذاكرة.

   CREATE TABLE otel_traces_backfill
   (
       Timestamp DateTime64(9),
       ServiceName LowCardinality(String),
       StatusCode LowCardinality(String),
       Duration UInt64
   )
   ENGINE = Null;
   
2. إرفاق عرض مادي بجدول Null

   بعد ذلك، أنشئ عرضًا ماديًا على جدول Null يستهدف جدول التجميع نفسه الذي يستخدمه العرض المادي الأساسي لديك.

   CREATE MATERIALIZED VIEW otel_traces_1m_mv_backfill
   TO otel_traces_1m
   AS
   SELECT
       toStartOfMinute(Timestamp) AS Timestamp,
       ServiceName,
       StatusCode,
       count() AS count,
       avgState(Duration) AS avg__Duration,
       maxSimpleState(Duration) AS max__Duration,
       quantilesState(0.95, 0.99)(Duration) AS quantiles__Duration
   FROM otel_traces_backfill
   GROUP BY
       Timestamp,
       ServiceName,
       StatusCode;
   

   سيُنفَّذ هذا العرض المادي تدريجيًا مع إدراج الصفوف في جدول Null، مولّدًا حالات التجميع في كتل صغيرة.

3. تحميل البيانات التاريخية تدريجيًا

   أخيرًا، أدرِج البيانات التاريخية في جدول Null. سيعالج العرض المادي البيانات كتلةً تلو الأخرى، ويُنتج حالات التجميع في الجدول الهدف من دون تخزين الصفوف الخام.

   INSERT INTO otel_traces_backfill
   SELECT
       Timestamp,
       ServiceName,
       StatusCode,
       Duration
   FROM otel_traces
   WHERE Timestamp < (
       SELECT min(Timestamp) FROM otel_traces_1m
   );
   

   وبما أن البيانات تُعالَج تدريجيًا، يظل استخدام الذاكرة محدودًا وقابلًا للتنبؤ، بما يشبه إلى حد كبير سلوك الإدخال المعتاد.

   لمزيد من الأمان، فكّر في توجيه العرض المادي الخاص بالتحميل بأثر رجعي إلى جدول هدف مؤقت (على سبيل المثال، otel_traces_1m_v2). وبعد اكتمال التحميل بأثر رجعي بنجاح، يمكن نقل الأقسام إلى الجدول الهدف الأساسي، مثل ALTER TABLE otel_traces_1m_v2 MOVE PARTITION '2026-01-02' TO otel_traces_1m. يسهّل ذلك الاسترداد إذا انقطع التحميل بأثر رجعي أو فشل بسبب حدود الموارد.

   للاطلاع على مزيد من التفاصيل حول ضبط هذه العملية، بما في ذلك تحسين أداء INSERT وتقليل استهلاك الموارد والتحكم فيه، راجع “التحميل بأثر رجعي.”

​

التوصيات

تلخّص التوصيات التالية أفضل الممارسات لتصميم العروض المادية وتشغيلها في ClickStack. وسيساعد اتباع هذه الإرشادات على ضمان أن تكون العروض المادية فعّالة ومتوقعة وموفّرة من حيث التكلفة.

​

اختيار مستوى التحبّب والمواءمة

لا تُستخدم العروض المادية إلا عندما يكون مستوى تحبّب المرئيات أو التنبيه مضاعفًا صحيحًا تمامًا لمستوى تحبّب العرض. وتعتمد طريقة تحديد مستوى التحبّب هذا على نوع المخطط:

• المخططات الزمنية (المخططات الخطية أو الشريطية التي يكون فيها الوقت على المحور السيني): يجب أن يكون مستوى التحبّب المحدد صراحةً للمخطط مضاعفًا لمستوى تحبّب العرض المادي. على سبيل المثال، يمكن لمخطط مدته 10 دقائق استخدام عروض مادية بمستوى تحبّب 10 دقائق أو 5 دقائق أو دقيقتين أو دقيقة واحدة، ولكن ليس عروضًا بمستوى تحبّب 20 دقيقة أو 3 دقائق.

• المخططات غير الزمنية (مخططات الرقم أو الجدول أو الملخص): يُشتق مستوى التحبّب الفعلي على النحو التالي: (time range / 80)، مع التقريب للأعلى إلى أقرب مستوى تحبّب يدعمه HyperDX. ويجب أيضًا أن يكون مستوى التحبّب المشتق هذا مضاعفًا لمستوى تحبّب العرض المادي.

وبسبب هذه القواعد:

• لا تنشئ عروضًا مادية بمستوى تحبّب 10 دقائق. يدعم ClickStack مستوى تحبّب 15 دقيقة للمخططات والتنبيهات، لكنه لا يدعم 10 دقائق. لذلك سيكون العرض المادي ذو مستوى التحبّب 10 دقائق غير متوافق مع المرئيات والتنبيهات الشائعة ذات 15 دقيقة.
• فضّل مستويات التحبّب دقيقة واحدة أو ساعة واحدة، لأنها تتوافق بسلاسة مع معظم إعدادات المخططات والتنبيهات.

ينتج عن مستوى التحبّب الأعلى (على سبيل المثال، ساعة واحدة) عروض أصغر وعبء تخزين أقل، بينما يوفّر مستوى التحبّب الأقل (على سبيل المثال، دقيقة واحدة) مرونة أكبر لإجراء تحليل أدق. اختر أصغر مستوى تحبّب يدعم مسارات العمل الأساسية لديك.

​

الحد من العروض المادية ودمجها

يضيف كل عرض مادي عبئًا إضافيًا وقت الإدراج، ويسهم في زيادة الضغط على الأجزاء وعمليات الدمج. توصى بالإرشادات التالية:

• ألا يتجاوز العدد 20 عرضًا ماديًا لكل مصدر.
• يكون نحو 10 عروض مادية عادةً هو العدد الأمثل.
• ادمج عدة تصورات في عرض واحد عندما تشترك في الأبعاد نفسها.

حيثما أمكن، احسب عدة مقاييس وادعم عدة مخططات من العرض المادي نفسه.

​

اختر الأبعاد بعناية

ضمّن فقط الأبعاد التي تُستخدم عادةً في التجميع أو التصفية:

• كل عمود تجميع إضافي يزيد من حجم العرض.
• وازن بين مرونة الاستعلام وتكلفة التخزين وتكلفة وقت الإدراج.
• ستؤدي عوامل التصفية على الأعمدة غير الموجودة في العرض إلى تراجع ClickStack تلقائيًا إلى الجدول المصدر.

نصيحة

من خطوط الأساس الشائعة والمفيدة في معظم الحالات عرض مادي مُجمَّع حسب اسم الخدمة مع مقياس count، ما يتيح مدرجات تكرارية سريعة وعروضًا عامة على مستوى الخدمة في Search ولوحات المعلومات.

​

اصطلاحات تسمية أعمدة التجميع

يجب أن تلتزم أعمدة التجميع في العرض المادي باصطلاح تسمية صارم لتمكين الاستنتاج التلقائي:

• النمط: <aggFn>__<sourceColumn>
• أمثلة:
  • avg__Duration
  • max__Duration
  • count__ لعدّ الصفوف

يعتمد ClickStack على هذا الاصطلاح لمطابقة الاستعلامات مع أعمدة العرض المادي بشكل صحيح.

​

الكوانتايلات واختيار الـ sketch

تختلف دوال الكوانتايل في خصائص الأداء والتخزين:

• تنتج quantiles ‏sketches أكبر على القرص، لكنها أقل كلفةً حسابيًا وقت الإدراج.
• تكون quantileTDigest أعلى كلفةً حسابيًا وقت الإدراج، لكنها تنتج ‏sketches أصغر، ما يؤدي غالبًا إلى استعلامات أسرع على الـ view.

يمكنك تحديد حجم الـ sketch (على سبيل المثال، quantile(0.5) وقت الإدراج لكلتا الدالتين. وسيظل بإمكانك لاحقًا الاستعلام عن الـ sketch الناتج لقيم كوانتايل أخرى، مثل quantile(0.95). نوصي بالتجربة للعثور على أفضل توازن يناسب عبء العمل لديك.

​

تحقّق من الفعالية باستمرار

تحقّق دائمًا من أن العروض المادية تحقق فوائد حقيقية:

• تأكّد من استخدامها عبر مؤشرات التسريع في واجهة المستخدم.
• قارِن أداء الاستعلامات قبل تفعيل العرض وبعده.
• راقب استخدام الموارد وسلوك الدمج.

يجب التعامل مع العروض المادية باعتبارها تحسينات للأداء تتطلب مراجعة دورية وتعديلًا مع تطور أنماط الاستعلامات.

​

الإعدادات المتقدمة

بالنسبة إلى أعباء العمل الأكثر تعقيدًا، يمكن استخدام عدة عروض مادية لدعم أنماط وصول مختلفة. ومن الأمثلة على ذلك:

• بيانات حديثة عالية الدقة مع عروض تاريخية أقل دقة
• عروض على مستوى الخدمة لتقديم نظرة عامة، وعروض على مستوى نقطة النهاية لإجراء تشخيصات معمقة

يمكن لهذه الأنماط أن تحسّن الأداء بشكل كبير عند تطبيقها بصورة انتقائية، ولكن ينبغي عدم اعتمادها إلا بعد التحقق من فعالية الإعدادات الأبسط.

سيساعد اتباع هذه التوصيات على ضمان بقاء العروض المادية فعالة، وقابلة للصيانة، ومتوافقة مع نموذج تنفيذ ClickStack.

​

القيود

​

أسباب شائعة لعدم التوافق

لن يُستخدَم العرض المادي إذا تحقّق أيّ من الشروط التالية:

• النطاق الزمني للاستعلام إذا كانت بداية النطاق الزمني للاستعلام تسبق الحد الأدنى للطابع الزمني في العرض المادي. ونظرًا إلى أن العروض لا تُملأ بالبيانات التاريخية تلقائيًا، فلا يمكنها خدمة الاستعلامات إلا ضمن النطاقات الزمنية التي تغطيها بالكامل.

• عدم تطابق مستوى التحبّب يجب أن يكون مستوى التحبّب الفعّال في التصور مضاعفًا صحيحًا تمامًا لمستوى تحبّب العرض المادي. وبالتحديد:

  • بالنسبة إلى المخططات الزمنية (المخططات الخطية أو الشريطية التي يكون فيها الوقت على المحور x)، يجب أن يكون مستوى التحبّب المحدد للمخطط مضاعفًا لمستوى تحبّب العرض. على سبيل المثال، يمكن لمخطط مدته 10 دقائق استخدام عروض مادية بدقة 10 دقائق أو 5 دقائق أو دقيقتين أو دقيقة واحدة، لكن لا يمكنه استخدام عروض بدقة 20 دقيقة أو 3 دقائق.
  • بالنسبة إلى المخططات غير الزمنية (المخططات الرقمية أو الجدولية)، يُحسَب مستوى التحبّب الفعّال على أنه (time range / 80)، مع التقريب للأعلى إلى أقرب مستوى تحبّب يدعمه HyperDX، ويجب أيضًا أن يكون مضاعفًا لمستوى تحبّب العرض.

• دوال تجميع غير مدعومة يطلب الاستعلام تجميعًا غير موجود في العرض المادي. ولا يمكن استخدام سوى التجميعات التي حُسِبت وخُزِّنت صراحةً في العرض.

• تعبيرات count مخصّصة لا يمكن اشتقاق الاستعلامات التي تستخدم تعبيرات مثل count(if(...)) أو غيرها من عمليات العدّ الشرطي من حالات التجميع القياسية، ولذلك لا يمكنها استخدام العروض المادية.

​

قيود التصميم والتشغيل

• عدم وجود تعبئة تاريخية تلقائية لا تحتوي العروض المادية التزايدية إلا على البيانات المُدرجة بعد إنشائها. ويتطلب تسريع البيانات التاريخية تعبئة تاريخية صريحة، وقد يكون ذلك مكلفًا أو غير عملي لمجموعات البيانات الكبيرة.

• مفاضلات مستوى التحبّب تؤدي العروض ذات مستوى التحبّب الدقيق جدًا إلى زيادة حجم التخزين والحمل الإضافي وقت الإدراج، بينما تقلل العروض ذات مستوى التحبّب الخشن من المرونة. ويجب اختيار مستوى التحبّب بعناية ليتوافق مع أنماط الاستعلام المتوقعة.

• تضخم الأبعاد تؤدي إضافة عدد كبير من أبعاد التجميع إلى زيادة حجم العرض بشكل كبير، وقد تقلل من فعاليته. ويجب ألا تتضمن العروض إلا أعمدة التجميع والتصفية شائعة الاستخدام.

• قابلية توسع محدودة لعدد العروض يضيف كل عرض مادي حملًا إضافيًا وقت الإدراج، ويساهم في ضغط الدمج. وقد يؤثر إنشاء عدد كبير جدًا من العروض سلبًا في إدخال البيانات وعمليات الدمج في الخلفية.

يساعد إدراك هذه القيود على ضمان استخدام العروض المادية حيث تحقق فائدة فعلية، وتجنب الإعدادات التي تنتقل بصمت إلى استعلامات أبطأ على الجداول المصدرية.

​

استكشاف الأخطاء وإصلاحها

​

عدم استخدام العرض المادي

التحقق 1: نطاق التاريخ

• افتح نافذة التحسين لمعرفة ما إذا كانت تعرض “نطاق التاريخ غير مدعوم.”
• تأكد من أن نطاق تاريخ الاستعلام يبدأ بعد الحد الأدنى لتاريخ العرض المادي.
• أزل الحد الأدنى للتاريخ إذا كان العرض المادي يتضمن جميع البيانات التاريخية.

التحقق 2: مستوى التحبّب

• تحقّق من أن مستوى تحبّب المخطط هو مضاعف لمستوى تحبّب MV.
• جرّب ضبط المخطط على “Auto” أو حدّد يدويًا مستوى تحبّب متوافقًا.

التحقق 3: التجميعات

• تحقّق مما إذا كان المخطط يستخدم تجميعات موجودة في MV.
• راجع “الأعمدة المجمّعة المتاحة” في نافذة التحسين.

التحقق 4: الأبعاد

• تأكد من أن أعمدة Group By موجودة ضمن أعمدة الأبعاد في MV.
• تحقّق من “أعمدة التجميع/التصفية المتاحة” في نافذة التحسين.

​

بطء استعلامات العرض المادي

المشكلة 1: مستوى تحبّب العرض المادي أدق من اللازم

• يحتوي MV على عدد كبير جدًا من الصفوف بسبب صِغَر مستوى التحبّب (مثلًا، ثانية واحدة).
• الحل: أنشئ MV بمستوى تحبّب أكبر (مثلًا، دقيقة واحدة أو ساعة واحدة).

المشكلة 2: عدد كبير جدًا من الأبعاد

• يحتوي MV على عدد كبير من القيم الفريدة بسبب كثرة أعمدة الأبعاد.
• الحل: قلّل أعمدة الأبعاد إلى الأكثر استخدامًا.

المشكلة 3: عدة MVs بعدد صفوف كبير

• يشغّل النظام EXPLAIN على كل MV.
• الحل: أزل MVs التي نادرًا ما تُستخدم أو التي يتم تخطيها دائمًا.

​

أخطاء الإعداد

خطأ: “مطلوب عمود مُجمَّع واحد على الأقل”

• أضِف عمودًا مُجمَّعًا واحدًا على الأقل إلى إعداد MV.

خطأ: “عمود المصدر مطلوب لعمليات التجميع غير الخاصة بـ count”

• حدِّد العمود المطلوب تجميعه (يمكن فقط لـ count عدم تحديد عمود مصدر).

خطأ: “تنسيق مستوى التحبّب غير صالح”

• استخدم أحد مستويات التحبّب المحددة مسبقًا من القائمة المنسدلة.
• يجب أن يكون التنسيق interval صالحًا في SQL (مثلًا: 1 hour، وليس 1 h).