`، فتأكد من استخدام اسم العرض لا اسم الجدول. وإذا كانت قائمة `DEPENDS ON` تتضمن جدولًا عاديًا أو عرضًا غير قابل للتحديث أو تحتوي على خطأ مطبعي، فلن يتم تحديث العرض أبدًا، وستظهر حالته `MissingDependencies` في `system.view_refreshes`. ويمكن تغيير التبعيات أو إزالتها باستخدام `ALTER`، راجع [تغيير معلمات التحديث](#changing-refresh-parameters).
#### استخدام `DEPENDS ON` لتحقيق زمن انتشار متسق
إذا كان كلا العرضين يستخدم `REFRESH EVERY` بالفترة نفسها، فستُطبَّق التبعية في كل فترة زمنية.
على سبيل المثال، افترض أن العرضين X وY يستخدمان كلاهما `REFRESH EVERY 1 HOUR`، وأن Y يقرأ من جدول المخرجات الخاص بـ X. من دون تبعيات، سيرى Y عادةً بيانات X الناتجة عن عملية `refresh` الخاصة بالساعة السابقة. ومع `DEPENDS ON X`، لن تبدأ عملية `refresh` الخاصة بـ Y عند الساعة 11:00 إلا بعد اكتمال عملية `refresh` الخاصة بـ X عند الساعة 11:00.
```text theme={null}
10:00 11:00 12:00
│ │ │
X: [run]┐ [run]┐ [run]┐
│ │ │
Y: └►[run] └►[run] └►[run]
```
قد يتخطّى كلٌّ من التبعية والتابع فتراتٍ زمنيةً بصورة مستقلة إذا استغرقت عمليات التحديث وقتًا أطول من فترة التحديث. ولا يوجد ما يضمن أن يُحدَّث التابع مرةً واحدةً بالضبط لكل تحديث للتبعية.
```text theme={null}
10:00 11:00 12:00 13:00
│ │ │ |
X: [run]┐ [run]┐ [run]┐ [run]┐
│ └────┐ (Y skips 12:00) └───┐
Y: └►[10:00 ru------un]└►[11:00 ru---------------un]└►[13:00 run]
```
#### استخدام `DEPENDS ON` في معالجة التدفق على دفعات
إذا لم يُستخدَم `REFRESH EVERY`، فسيُحدَّث العرض التابع X إذا كانت جميع تبعياته قد تحدّثت مرة واحدة على الأقل منذ آخر تحديث لـ X. ويضيف `REFRESH AFTER T` تأخيرًا: إذ سيبدأ العنصر التابع التحديث بعد مرور مدة T على اكتمال تحديث التبعية.
التبعيات الدائرية مسموح بها ومفيدة. تأمّل هذا الرسم البياني للعروض المادية القابلة للتحديث:
1. يأخذ X دفعة من الصفوف من تدفقٍ ما ويضعها في جدول.
2. ثم يقرأ كلٌّ من Y وZ من ذلك الجدول، ويُجريان عمليات تجميع مختلفة، ويضيفان النتائج إلى جداول أخرى.
3. بعد اكتمال معالجة الدفعة بالكامل، يأخذ X الدفعة التالية، وتتكرر الدورة.
```text theme={null}
source
│
▼
┌─────────┐
┌───►│ X │◄───┐
│ └──┬───┬──┘ │
DEPENDS │ │ DEPENDS
ON ▼ ▼ ON
│ ┌─┐ ┌─┐ │
└──────┤Y│ │Z├──────┘
└─┘ └─┘
```
مثال كامل:
```sql theme={null}
CREATE TABLE current_batch (t UInt64, v Int64) ENGINE ReplicatedMergeTree ORDER BY t;
CREATE TABLE batch_log (max_t UInt64, n Int64, v_sum Int64, processed_at DateTime64) ENGINE ReplicatedMergeTree ORDER BY max_t;
CREATE TABLE stats (h UInt64, n UInt64) ENGINE ReplicatedSummingMergeTree ORDER BY h;
-- (system.numbers stands in for a data source with monotonically increasing timestamps or sequence numbers)
CREATE MATERIALIZED VIEW current_batch_v REFRESH EVERY 10 SECOND DEPENDS ON batch_log_v, stats_v TO current_batch AS SELECT number as t, number * 10 as v FROM system.numbers WHERE number > (SELECT max(max_t) FROM batch_log) LIMIT 100;
CREATE MATERIALIZED VIEW batch_log_v REFRESH DEPENDS ON current_batch_v APPEND TO batch_log AS SELECT max(t) as max_t, count() as n, sum(v) as v_sum, now64() as processed_at FROM current_batch;
CREATE MATERIALIZED VIEW stats_v REFRESH DEPENDS ON current_batch_v APPEND TO stats AS SELECT cityHash64(v) % 20 as h, count() as n FROM current_batch GROUP BY h;
-- Must trigger initial refresh manually.
SYSTEM REFRESH VIEW current_batch_v;
```
تعمل السلاسل الأطول أيضًا.
لا يعمل هذا جيدًا إلا عندما يكون تنسيق التحديث مفعّلًا، أي عندما تكون العروض في قاعدة بيانات Replicated أو Shared. ومن دون التنسيق، تؤدي إعادة تشغيل الخادم إلى كسر الحلقة، مما يتطلب تنفيذ `SYSTEM REFRESH VIEW` يدويًا بعد كل إعادة تشغيل بدلًا من تنفيذه مرة واحدة فقط بعد إنشاء العروض.
### إعدادات التحديث
إعدادات التحديث المتاحة:
* `refresh_retries` - عدد مرات إعادة المحاولة إذا فشل استعلام التحديث بسبب استثناء. إذا فشلت جميع محاولات إعادة المحاولة، فانتقل إلى وقت التحديث المجدول التالي. تعني القيمة 0 عدم إعادة المحاولة، وتعني القيمة -1 إعادة المحاولة بلا حدود. القيمة الافتراضية: 2.
* `refresh_retry_initial_backoff_ms` - مدة التأخير قبل أول إعادة محاولة، إذا لم تكن قيمة `refresh_retries` صفراً. تتضاعف مدة التأخير مع كل إعادة محاولة لاحقة، حتى `refresh_retry_max_backoff_ms`. القيمة الافتراضية: 100 مللي ثانية.
* `refresh_retry_max_backoff_ms` - الحد الأقصى للزيادة الأسية في مدة التأخير بين محاولات التحديث. القيمة الافتراضية: 60000 مللي ثانية (دقيقة واحدة).
* `all_replicas` - في [قاعدة بيانات Replicated](/ar/reference/engines/database-engines/replicated) مع `APPEND`، يحدّد ما إذا كانت جميع النسخ المتماثلة تُحدَّث بشكل مستقل، أو ما إذا كانت نسخة متماثلة واحدة فقط تُجري التحديث في كل وقت مجدول. لا يمكن تغيير هذا الإعداد بعد إنشاء العرض. القيمة الافتراضية: `false`.
### تغيير معلمات التحديث
يمكن تغيير معلمات التحديث لعرض مادي قابل للتحديث موجود باستخدام [`ALTER TABLE ... MODIFY REFRESH`](/ar/reference/statements/alter/view#alter-table--modify-refresh-statement):
```sql theme={null}
ALTER TABLE [db.]name MODIFY REFRESH EVERY|AFTER ... [RANDOMIZE FOR ...] [DEPENDS ON ...] [SETTINGS ...]
```
الجدولة (`EVERY` أو `AFTER`) إلزامية: تستبدل التعليمة دائمًا *جميع* مَعلمات التحديث — الجدولة، و`RANDOMIZE FOR`، و`DEPENDS ON`، وإعدادات التحديث — بما هو محدد. وأي عنصر يُغفَل يُعاد تعيينه إلى قيمته الافتراضية (بالنسبة إلى الإعدادات) أو يُزال (بالنسبة إلى التبعيات والعشوائية).
* لتغيير إعدادات التحديث فقط (مثلًا `refresh_retries`)، أعِد ذكر الجدولة الحالية:
```sql theme={null}
ALTER TABLE rmv MODIFY REFRESH EVERY 1 HOUR SETTINGS refresh_retries = 5;
```
* لا يدعم `ALTER TABLE ... MODIFY SETTING refresh_retries = ...` العروض المادية؛ ويجب تنفيذ ذلك عبر `MODIFY REFRESH`.
* لا تتمّ إضافة `APPEND` أو إزالته.
* لا يمكن تغيير الإعداد `all_replicas` بعد الإنشاء.
أمثلة:
```sql theme={null}
-- Change the schedule, drop existing settings and dependencies.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE;
-- Change the schedule and tune retry behavior.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE
SETTINGS refresh_retries = 5,
refresh_retry_initial_backoff_ms = 500,
refresh_retry_max_backoff_ms = 60000;
-- Keep the dependency while changing the period.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR DEPENDS ON other_rmv;
-- Drop the dependency by omitting `DEPENDS ON`.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR;
```
### عمليات أخرى
تتوفر حالة جميع العروض المادية القابلة للتحديث في الجدول [`system.view_refreshes`](/ar/reference/system-tables/view_refreshes). ويعرض هذا الجدول تحديدًا تقدّم التحديث (إذا كان جاريًا)، ووقت آخر تحديث ووقت التحديث التالي، ورسالة الاستثناء إذا فشل التحديث.
لإيقاف التحديثات أو بدئها أو تشغيلها أو إلغائها يدويًا، استخدم [`SYSTEM STOP|START|REFRESH|WAIT|CANCEL VIEW`](/ar/reference/statements/system#managing-refreshable-materialized-views).
للانتظار حتى يكتمل التحديث، استخدم [`SYSTEM WAIT VIEW`](/ar/reference/statements/system#wait-view). ويكون هذا مفيدًا بشكل خاص عند انتظار التحديث الأولي بعد إنشاء العرض.
معلومة طريفة: يُسمح لاستعلام التحديث بالقراءة من العرض الذي يجري تحديثه، مع الاطّلاع على نسخة البيانات السابقة للتحديث. وهذا يعني أنه يمكنك تنفيذ لعبة الحياة لكونواي: [https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==](https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==)
## Window View
هذه ميزة تجريبية وقد تتغير في الإصدارات القادمة على نحوٍ غير متوافق مع الإصدارات السابقة. لتمكين استخدام Window View واستعلام `WATCH`، استخدم الإعداد [allow\_experimental\_window\_view](/ar/reference/settings/session-settings#allow_experimental_window_view). أدخل الأمر `set allow_experimental_window_view = 1`.
```sql theme={null}
CREATE WINDOW VIEW [IF NOT EXISTS] [db.]table_name [TO [db.]table_name] [INNER ENGINE engine] [ENGINE engine] [WATERMARK strategy] [ALLOWED_LATENESS interval_function] [POPULATE]
AS SELECT ...
GROUP BY time_window_function
[COMMENT 'comment']
```
يمكن لـ window view تجميع البيانات حسب النافذة الزمنية وإخراج النتائج عندما تصبح النافذة جاهزة للإرسال. كما تخزّن نتائج التجميع الجزئية في جدول داخلي (أو محدد) لتقليل زمن الاستجابة، ويمكنها دفع نتيجة المعالجة إلى جدول محدد أو إرسال إشعارات دفع باستخدام الاستعلام `WATCH`.
يشبه إنشاء window view إنشاء `MATERIALIZED VIEW`. وتحتاج window view إلى محرك تخزين داخلي لتخزين البيانات الوسيطة. ويمكن تحديد التخزين الداخلي باستخدام العبارة `INNER ENGINE`، وستستخدم window view المحرك `AggregatingMergeTree` بوصفه المحرك الداخلي الافتراضي.
عند إنشاء window view بدون `TO [db].[table]`، يجب تحديد `ENGINE` — أي محرك الجدول المستخدم لتخزين البيانات.
### دوال النافذة الزمنية
تُستخدم [دوال النافذة الزمنية](/ar/reference/functions/regular-functions/time-window-functions) للحصول على حدَّي النافذة السفلي والعلوي للسجلات. يجب استخدام window view مع إحدى دوال النافذة الزمنية.
### سمات الوقت
يدعم Window view نمطَي **وقت المعالجة** و**وقت الحدث**.
يتيح **وقت المعالجة** لـ Window view إنتاج النتائج استنادًا إلى وقت الجهاز المحلي، ويُستخدم افتراضيًا. وهو أبسط مفهوم للوقت، لكنه لا يوفّر الحتمية. يمكن تعريف سمة وقت المعالجة من خلال تعيين `time_attr` في دالة النافذة الزمنية إلى عمود في جدول، أو باستخدام الدالة `now()`. ينشئ الاستعلام التالي Window view باستخدام وقت المعالجة.
```sql theme={null}
CREATE WINDOW VIEW wv AS SELECT count(number), tumbleStart(w_id) as w_start from date GROUP BY tumble(now(), INTERVAL '5' SECOND) as w_id
```
**وقت الحدث** هو الوقت الذي وقع فيه كل حدث على الجهاز الذي أصدره. وعادةً ما يكون هذا الوقت مضمّنًا في السجلات عند إنشائها. وتتيح معالجة وقت الحدث الحصول على نتائج متسقة حتى عند وصول الأحداث بترتيب غير متسق أو متأخر. وتدعم ميزة window view معالجة وقت الحدث باستخدام صياغة `WATERMARK`.
توفّر window view ثلاث استراتيجيات للعلامة المائية:
* `STRICTLY_ASCENDING`: تُصدر علامة مائية تساوي أكبر طابع زمني تمّت ملاحظته حتى الآن. ولا تُعد الصفوف التي تحمل طابعًا زمنيًا أصغر من أكبر طابع زمني متأخرة.
* `ASCENDING`: تُصدر علامة مائية تساوي أكبر طابع زمني تمّت ملاحظته حتى الآن ناقص 1. ولا تُعد الصفوف التي تحمل طابعًا زمنيًا مساويًا لأكبر طابع زمني أو أصغر منه متأخرة.
* `BOUNDED`: WATERMARK=INTERVAL. تُصدر علامات مائية تساوي أكبر طابع زمني تمّت ملاحظته مطروحًا منه التأخير المحدد.
الاستعلامات التالية أمثلة على إنشاء window view باستخدام `WATERMARK`:
```sql theme={null}
CREATE WINDOW VIEW wv WATERMARK=STRICTLY_ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=INTERVAL '3' SECOND AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
```
افتراضيًا، تُطلق النافذة نتيجتها عند وصول العلامة المائية، وتُسقَط العناصر التي تصل متأخرة عنها. يدعم Window View معالجة الأحداث المتأخرة من خلال ضبط `ALLOWED_LATENESS=INTERVAL`. ومثال على التعامل مع التأخر هو:
```sql theme={null}
CREATE WINDOW VIEW test.wv TO test.dst WATERMARK=ASCENDING ALLOWED_LATENESS=INTERVAL '2' SECOND AS SELECT count(a) AS count, tumbleEnd(wid) AS w_end FROM test.mt GROUP BY tumble(timestamp, INTERVAL '5' SECOND) AS wid;
```
لاحظ أن العناصر المنبعثة من إطلاق متأخر يجب التعامل معها على أنها نتائج محدَّثة لحساب سابق. وبدلًا من الإطلاق عند نهاية النوافذ، سيُطلِق window view فورًا عند وصول الحدث المتأخر. وبالتالي، سيؤدي ذلك إلى ظهور مخرجات متعددة للنافذة نفسها. يحتاج المستخدمون إلى مراعاة هذه النتائج المكررة أو إزالة تكرارها.
يمكنك تعديل استعلام `SELECT` الذي جرى تحديده في window view باستخدام تعليمة `ALTER TABLE ... MODIFY QUERY`. يجب أن تكون بنية البيانات الناتجة عن استعلام `SELECT` الجديد مماثلة لبنية استعلام `SELECT` الأصلي، سواء وُجد بند `TO [db.]name` أم لم يوجد. لاحظ أن البيانات في النافذة الحالية ستُفقد لأن الحالة الوسيطة لا يمكن إعادة استخدامها.
### مراقبة النوافذ الجديدة
تدعم ميزة window view استعلام [WATCH](/ar/reference/statements/watch) لمراقبة التغييرات، أو يمكنك استخدام صياغة `TO` لإخراج النتائج إلى جدول.
```sql theme={null}
WATCH [db.]window_view
[EVENTS]
[LIMIT n]
[FORMAT format]
```
يمكن تحديد `LIMIT` لتعيين عدد التحديثات التي سيتم تلقيها قبل إنهاء الاستعلام. ويمكن استخدام العبارة `EVENTS` للحصول على صيغة مختصرة من استعلام `WATCH`، بحيث ستحصل بدلًا من نتيجة الاستعلام على أحدث علامة مائية للاستعلام فقط.
### الإعدادات
* `window_view_clean_interval`: فاصل تنظيف Window View بالثواني لتحرير البيانات القديمة. سيحتفظ النظام بالنوافذ التي لم تُطلق بالكامل وفقًا لوقت النظام أو إعداد `WATERMARK`، وسيُحذف ما عدا ذلك من البيانات.
* `window_view_heartbeat_interval`: فاصل نبضات الحياة بالثواني للإشارة إلى أن استعلام watch لا يزال نشطًا.
* `wait_for_window_view_fire_signal_timeout`: المهلة الزمنية لانتظار إشارة إطلاق Window View في معالجة وقت الحدث.
### مثال
لنفترض أننا نريد حساب عدد سجلات النقرات كل 10 ثوانٍ في جدول سجلات يُسمى `data`، ويكون هيكل الجدول كما يلي:
```sql theme={null}
CREATE TABLE data ( `id` UInt64, `timestamp` DateTime) ENGINE = Memory;
```
أولًا، ننشئ window view بنافذة متعاقبة ذات interval قدره 10 ثوانٍ:
```sql theme={null}
CREATE WINDOW VIEW wv as select count(id), tumbleStart(w_id) as window_start from data group by tumble(timestamp, INTERVAL '10' SECOND) as w_id
```
ثم نستخدم الاستعلام `WATCH` للحصول على النتائج.
```sql theme={null}
WATCH wv
```
عند إدراج السجلات في الجدول `data`،
```sql theme={null}
INSERT INTO data VALUES(1,now())
```
يجب أن يعرض استعلام `WATCH` النتائج كما يلي:
```text theme={null}
┌─count(id)─┬────────window_start─┐
│ 1 │ 2020-01-14 16:56:40 │
└───────────┴─────────────────────┘
```
بدلًا من ذلك، يمكننا توجيه المخرجات إلى جدول آخر باستخدام صيغة `TO`.
```sql theme={null}
CREATE WINDOW VIEW wv TO dst AS SELECT count(id), tumbleStart(w_id) as window_start FROM data GROUP BY tumble(timestamp, INTERVAL '10' SECOND) as w_id
```
يمكن العثور على أمثلة إضافية ضمن الاختبارات ذات الحالة في ClickHouse (وهي تحمل هناك الاسم `*window_view*`).
### استخدامات Window View
تكون Window View مفيدة في السيناريوهات التالية:
* **المراقبة**: تجميع سجلات المقاييس وحسابها بحسب الوقت، ثم إخراج النتائج إلى جدول الهدف. ويمكن أن تستخدم لوحة المعلومات جدول الهدف بوصفه الجدول المصدر.
* **التحليل**: تجميع البيانات تلقائيًا ومعالجتها مسبقًا ضمن النافذة الزمنية. وقد يكون ذلك مفيدًا عند تحليل عدد كبير من السجلات. وتُلغي المعالجة المسبقة العمليات الحسابية المتكررة عبر استعلامات متعددة وتقلل زمن استجابة الاستعلامات.
## محتوى مرتبط
* مدونة: [العمل مع بيانات السلاسل الزمنية في ClickHouse](https://clickhouse.com/blog/working-with-time-series-data-and-functions-ClickHouse)
* مدونة: [بناء حل Observability باستخدام ClickHouse - الجزء 2 - التتبعات](https://clickhouse.com/blog/storing-traces-and-spans-open-telemetry-in-clickhouse)
## عروض مؤقتة
يدعم ClickHouse **عروض مؤقتة** بالخصائص التالية (على غرار الجداول المؤقتة حيثما ينطبق ذلك):
* **بعمر الجلسة**
لا يوجد عرض مؤقت إلا طوال مدة الجلسة الحالية. وتُحذف تلقائيًا عند انتهاء الجلسة.
* **بدون قاعدة بيانات**
**لا يمكنك** إلحاق عرض مؤقت باسم قاعدة بيانات. فهي توجد خارج قواعد البيانات (ضمن نطاق الجلسة).
* **غير مُكرّرة / بدون ON CLUSTER**
الكائنات المؤقتة محلية بالنسبة إلى الجلسة، و**لا يمكن** إنشاؤها باستخدام `ON CLUSTER`.
* **حلّ الأسماء**
إذا كان لكائن مؤقت (جدول أو طريقة عرض) الاسم نفسه لكائن دائم، وأشار استعلام إلى الاسم **من دون** قاعدة بيانات، فسيُستخدم الكائن **المؤقت**.
* **كائن منطقي (بدون تخزين)**
لا يخزّن عرض مؤقت سوى نص `SELECT` الخاص بها (وتستخدم داخليًا تخزين `View`). وهي لا تحتفظ بالبيانات ولا تقبل `INSERT`.
* **عبارة `ENGINE`**
**لا** تحتاج إلى تحديد `ENGINE`؛ وإذا تم توفيره على هيئة `ENGINE = View`، فسيتم تجاهله أو التعامل معه باعتباره طريقة العرض المنطقية نفسها.
* **الأمان / الامتيازات**
يتطلب إنشاء عرض مؤقت الامتياز `CREATE TEMPORARY VIEW`، والذي يُمنح ضمنيًا بواسطة `CREATE VIEW`.
* **SHOW CREATE**
استخدم `SHOW CREATE TEMPORARY VIEW view_name;` لطباعة DDL الخاص بعرض مؤقت.
### الصيغة
```sql theme={null}
CREATE TEMPORARY VIEW [IF NOT EXISTS] view_name AS
```
`OR REPLACE` **غير مدعوم** للعروض المؤقتة (تماشيًا مع الجداول المؤقتة). إذا كنت بحاجة إلى “استبدال” عرض مؤقت، فاحذفها ثم أنشئها من جديد.
### أمثلة
أنشئ جدولًا مؤقتًا كمصدر، ثم أنشئ فوقه عرضًا مؤقتًا:
```sql theme={null}
CREATE TEMPORARY TABLE t_src (id UInt32, val String);
INSERT INTO t_src VALUES (1, 'a'), (2, 'b');
CREATE TEMPORARY VIEW tview AS
SELECT id, upper(val) AS u
FROM t_src
WHERE id <= 2;
SELECT * FROM tview ORDER BY id;
```
اعرض تعريفه (DDL):
```sql theme={null}
SHOW CREATE TEMPORARY VIEW tview;
```
احذفه:
```sql theme={null}
DROP TEMPORARY VIEW IF EXISTS tview; -- temporary views are dropped with TEMPORARY TABLE syntax
```
### غير المسموح به / القيود
* `CREATE OR REPLACE TEMPORARY VIEW ...` → **غير مسموح** (استخدم `DROP` + `CREATE`).
* `CREATE TEMPORARY MATERIALIZED VIEW ...` / `WINDOW VIEW` → **غير مسموح**.
* `CREATE TEMPORARY VIEW db.view AS ...` → **غير مسموح** (من دون محدِّد قاعدة بيانات).
* `CREATE TEMPORARY VIEW view ON CLUSTER 'name' AS ...` → **غير مسموح** (الكائنات المؤقتة محلية على مستوى الجلسة).
* `POPULATE`, `REFRESH`, `TO [db.table]`, المحركات الداخلية، وجميع البنود الخاصة بـ MV → **لا تنطبق** على العروض المؤقتة.
### ملاحظات حول الاستعلامات الموزعة
إن **العرض** المؤقت ليس سوى تعريف؛ ولا توجد أي بيانات يمكن تمريرها. وإذا كان العرض المؤقت يشير إلى **جداول** مؤقتة (مثل `Memory`)، فيمكن إرسال بياناتها إلى الخوادم البعيدة أثناء تنفيذ الاستعلامات الموزعة، تمامًا كما هو الحال مع الجداول المؤقتة.
#### مثال
```sql theme={null}
-- A session-scoped, in-memory table
CREATE TEMPORARY TABLE temp_ids (id UInt64) ENGINE = Memory;
INSERT INTO temp_ids VALUES (1), (5), (42);
-- A session-scoped view over the temp table (purely logical)
CREATE TEMPORARY VIEW v_ids AS
SELECT id FROM temp_ids;
-- Replace 'test' with your cluster name.
-- GLOBAL JOIN forces ClickHouse to *ship* the small join-side (temp_ids via v_ids)
-- to every remote server that executes the left side.
SELECT count()
FROM cluster('test', system.numbers) AS n
GLOBAL ANY INNER JOIN v_ids USING (id)
WHERE n.number < 100;
```