كيف تعمل العروض المادية (Materialized Views) في PostgreSQL؟

Question

Accepted Answer

**العرض المادي** يخزن *نتائج* الاستعلام بشكل فعلي (محسوبة مسبقاً)، بخلاف العرض العادي (الذي يعيد تشغيل استعلامه في كل مرة). هذا يجعل القراءة سريعة للاستعلامات المكلفة، مقابل أن البيانات تكون طازجة فقط حتى آخر **تحديث** — آلية تخزين مؤقت ضمن قاعدة البيانات.

## العرض العادي مقابل العرض المادي

```sql
-- regular VIEW — runs the query EVERY time (always fresh, but recomputed)
CREATE VIEW sales_summary AS SELECT region, SUM(amount) FROM orders GROUP BY region;

-- MATERIALIZED VIEW — stores the RESULTS physically (fast reads, but can be stale)
CREATE MATERIALIZED VIEW sales_summary_mat AS
SELECT region, SUM(amount) AS total FROM orders GROUP BY region;

SELECT * FROM sales_summary_mat;     -- reads STORED results — fast (no recompute)
```

العرض المادي يحسب النتائج مسبقاً ويخزنها، لذا الاستعلام عنها سريع (مثل قراءة جدول) — مثالي للتجميعات المكلفة التي يتم الاستعلام عنها بكثرة.

## التحديث (تحديث البيانات المخزنة)

```sql
-- the data is stale until you refresh it
REFRESH MATERIALIZED VIEW sales_summary_mat;          -- recompute (locks reads during refresh)

-- CONCURRENTLY — refresh WITHOUT blocking reads (requires a unique index)
CREATE UNIQUE INDEX idx_sales_region ON sales_summary_mat(region);
REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_mat;   -- reads continue during refresh
```

يجب عليك **التحديث** لتحديث البيانات. `REFRESH ... CONCURRENTLY` (التي تتطلب فهرس فريد) تحدّث دون حجب القراءات المتزامنة — مهم للبيئة الإنتاجية.

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

```text
✓ EXPENSIVE queries (complex aggregations, joins) queried FREQUENTLY
✓ Data that doesn't need real-time freshness (dashboards, reports, analytics)
✓ Reducing load from repeatedly running the same heavy query
→ Refresh on a schedule (cron / pg_cron) or after data changes.

✗ Data needing real-time accuracy → use a regular view or query directly
```

## المقايضة

```text
Fast reads (precomputed) ⟷ Stale data (until refreshed) + storage cost.
You trade freshness and storage for read speed — a caching decision.
You can also index a materialized view (it's a physical table of results).
```

## لماذا يهم هذا

العروض المادية هي ميزة قيّمة في PostgreSQL لـ **تحسين الأداء** — فهي توفر آلية تخزين مؤقت ضمن قاعدة البيانات للاستعلامات المكلفة، لذا فهم كيفية عملها مفيد لتحسين التطبيقات التي تحتوي على استعلامات مكلفة وتُشغّل بتكرار.

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

فهم **المقايضة** الرئيسية مهم: العروض المادية توفر قراءات سريعة لكن البيانات **قديمة** حتى يتم تحديثها (وتكلف مساحة تخزين)، لذا هي قرار تخزين مؤقت مناسب للبيانات التي لا تحتاج إلى طزاجة في الوقت الفعلي.

معرفة كيفية **تحديثها** — خاصة `REFRESH ... CONCURRENTLY` (التي تحدّث دون حجب القراءات، مهم لتوفر الإنتاج، تتطلب فهرس فريد) — واستراتيجيات التحديث (على جدول زمني عبر cron/pg_cron، أو بعد تغييرات البيانات) هي معرفة عملية لاستخدامها بفعالية.

فهم **متى تستخدمها** (استعلامات مكلفة وتُشغّل بتكرار وتتسامح مع التأخر البسيط — وحات المعلومات، التحليلات) مقابل متى لا تستخدمها (البيانات التي تحتاج دقة في الوقت الفعلي) يعكس حكماً سليماً.

بما أن الاستعلامات المتكررة المكلفة هي مشكلة أداء حقيقية، وبما أن العروض المادية توفر حلاً فعالاً للتخزين المؤقت ضمن قاعدة البيانات (نتائج محسوبة مسبقاً وقابلة للفهرسة) مع مقايضة واضحة بين الطزاجة والسرعة، فإن فهمها — كيفية عملها، التحديث (خاصة المتزامن)، المقايضة، والاستخدام المناسب — هو معرفة PostgreSQL قيّمة وعملية لتحسين أداء استعلامات التحليل والتقارير، وهي حاجة شائعة حيث توفر العروض المادية حلاً نظيفاً ومدمجاً.