Materialized Views: איך חוסכים חישוב חוזר בלי לשבור עדכניות

מאת צוות מדיה דיל · 02.09.2026 · טכנולוגיה · 6 דק׳

ההבדל בין View רגיל ל-Materialized View, REFRESH CONCURRENTLY, אינדוקס נדרש גם על נתון מחושב, ומתי עדיף Read Replica או Cache במקום.

דשבורד שמריץ שאילתת אגרגציה כבדה על טבלת אירועים בת מאות מיליוני שורות בכל טעינת עמוד הוא מתכון בטוח לתלונות על ביצועים. Materialized View פותר את זה בדרך פשוטה למדי: מחשבים את תוצאת השאילתה פעם אחת, שומרים אותה כטבלה, וקוראים ממנה — במחיר שהנתון כבר לא תמיד "עדכני לשנייה".

ההבדל הבסיסי מ-View רגיל

View רגיל הוא בעצם שאילתה שמורה — כל פעם שקוראים ממנו, Postgres מריץ מחדש את השאילתה המלאה מאחוריו. זה נוח לקריאות קוד אבל לא חוסך כלום בביצועים. Materialized View לעומת זאת מחשב את התוצאה פעם אחת ושומר אותה פיזית על הדיסק כמו טבלה רגילה — קריאה ממנו היא Seq Scan פשוט על נתונים כבר מחושבים, לא הרצה מחדש של האגרגציה הכבדה.

המחיר: Staleness שצריך לנהל במודע

היתרון של Materialized View הוא גם החיסרון שלו — הנתון קפוא בזמן החישוב האחרון. עבור דוח מנהלים שמתעדכן פעם בשעה זה בדיוק מה שרוצים; עבור מסך שמראה יתרת חשבון בזמן אמת זו טעות עיצובית חמורה. ההחלטה הראשונה בכל מקרה שימוש היא לשאול בפירוש: כמה Staleness מקובל כאן, ובאיזה יחידות זמן.

REFRESH: מלא מול CONCURRENTLY

REFRESH MATERIALIZED VIEW רגיל נועל את ה-View לחלוטין בזמן הריענון — קריאות ממנו נחסמות עד לסיום. REFRESH ... CONCURRENTLY פותר את זה בכך שהוא בונה עותק חדש ברקע ומחליף אטומית, כך שקוראים ממשיכים לקבל את הגרסה הישנה עד לרגע ההחלפה — אבל זה דורש אינדקס ייחודי (Unique Index) על ה-View כתנאי מוקדם, ומכפיל זמנית את השטח בדיסק בזמן הריענון.

אינדוקס על Materialized View — כן, זה עדיין נדרש

טעות נפוצה היא לחשוב שכיוון ש-Materialized View "כבר טבלה מחושבת" אין צורך באינדקסים. בפועל הוא טבלה לכל דבר, וכל מה שנכון לגבי אינדקס ב-Postgres — B-Tree על עמודות סינון נפוצות, Composite Index לפי סדר סלקטיביות — חל עליו במלואו. Materialized View בלי אינדקס נכון על עמודות ה-WHERE הנפוצות עדיין יכול להיות איטי.

ריענון מלא מול ריענון אינקרמנטלי

Postgres לא תומך באופן מובנה בריענון אינקרמנטלי (Incremental View Maintenance) — כל REFRESH מחשב הכל מחדש. עבור טבלאות ענק זה יקר. הפתרון הנפוץ הוא לתחזק "טבלת סיכום" עם Trigger שמעדכן רק את השורות הרלוונטיות בכל שינוי, או להשתמש בכלים חיצוניים ייעודיים — אבל זה מוסיף מורכבות תפעולית משמעותית ביחס ל-REFRESH פשוט על לוח זמנים.

מתי Materialized View עדיף על Read Replica

Read Replica פותר בעיית עומס קריאה בכך שמפזר את אותה שאילתה על מכונות נוספות — אבל השאילתה הכבדה עצמה עדיין רצה בכל פעם, רק על מכונה אחרת. Materialized View פותר בעיה שונה: את עלות החישוב החוזר של אגרגציה כבדה, לא רק את עלות ה-I/O. הכלים לא תחליפים זה לזה, ולעיתים משתמשים בשניהם יחד — Materialized View על ה-Primary, שנקרא דרך Read Replica.

מתי לוותר על Materialized View לטובת Cache

אם הנתון פשוט (תוצאה יחידה, לא טבלה שלמה) והדרישה היא latency נמוך במיוחד, לרוב עדיף Redis Cache עם Invalidation מבוקר על פני Materialized View בתוך מסד הנתונים — קריאה מ-Redis מהירה יותר מ-Seq Scan גם על טבלה קטנה, והשליטה על תוקף ה-Cache גמישה יותר.

תזמון ריענון: Cron פשוט או Trigger מבוסס אירוע

הגישה הפשוטה ביותר היא REFRESH מתוזמן (למשל כל 15 דקות דרך pg_cron), שמתאימה לרוב דוחות ה-BI. עבור מקרים רגישים יותר אפשר להריץ REFRESH מיד אחרי אירוע כתיבה מסוים דרך התהליך שכתב את הנתון — אבל זה מגדיל את הקישוריות (Coupling) בין הכתיבה לריענון, וצריך לוודא שהריענון עצמו לא הופך לצוואר בקבוק אם הוא מופעל בתדירות גבוהה מדי.

דשבורדים או דוחות כבדים שמאטים את המערכת שלכם? נשמח לבדוק איתכם את הפתרון המתאים בוואטסאפ.

תגיות: Materialized Views · Postgres · Query Performance · Database

← חזרה לבלוג · צור קשר