Title here
Summary here
מערך שיעור: MongoDB Aggregation Pipeline
משך: 2 שעות אקדמיות (90 דקות).
מטרת השיעור: הסטודנטים יבנו Aggregation Pipeline עם match/group/lookup, ויבינו TTL Index.
בסוף השיעור הסטודנטים צריכים: לכתוב Pipeline בסיסי, להסביר את הדמיון ל-Middleware Pipeline, ולהגדיר TTL Index לתרחיש נתונים זמניים.
דגש קריטי: קשרו במפורש למידלוור מיחידת ASP.NET Core — זו לא אנלוגיה מקרית, זה אותו רעיון ארכיטקטוני בדיוק.
מהלך השיעור
| חלק בשיעור | משך | הערות ודגשים |
|---|---|---|
| פתיחה וחיבור | 5 דקות | הזכירו Find מהשיעור הקודם — “מה עם קיבוץ/JOIN?” |
| הרעיון: Pipeline = Middleware | 15 דקות | חיבור מפורש לשיעור Middleware |
| $match | 15 דקות | סינון, מקביל ל-Where |
| $group | 20 דקות | קיבוץ עם sum, מקביל ל-GroupBy |
| $lookup | 20 דקות | JOIN בין Collections, תוצאה מקוננת |
| TTL Index | 10 דקות | sessions/קאש זמני |
| תרגול מודרך | 5 דקות | תרגיל 1 |
דגשים להעברת השיעור
- החיבור ל-Middleware Pipeline הוא הגשר החינוכי הכי חזק בשיעור הזה — פתחו איתו במפורש ולא כהערת אגב.
- $lookup דורש הבהרה מפורשת שהתוצאה מגיעה כמערך מקונן, לא שורה שטוחה — סטודנטים שמכירים SQL JOIN עלולים לצפות להתנהגות זהה.
- TTL Index שווה הדגמה עם timeout קצר (דקה) כדי שסטודנטים יראו בפועל את המסמך נעלם, לא רק יאמינו שזה קורה.
מושגים
Aggregation Pipeline — שרשרת שלבי עיבוד נתונים.
$match/$group/$lookup — סינון/קיבוץ/JOIN.
TTL Index — מחיקה אוטומטית לפי timestamp.
תרגיל חשיבה
שאלת פתיחה: “אם תשימו $group לפני $match בפייפליין (במקום אחרי) — מה עלול להשתבש, מבחינת ביצועים ותוצאה?”
מהלך: הובילו לתובנה: $group לפני $match מקבץ את כל המסמכים, כולל כאלה שיסוננו ממילא — בזבוז עיבוד מיותר, בדיוק כמו Middleware של הרשאה שרץ אחרי לוגיקה עסקית כבדה (מיחידת ASP.NET Core). הסדר לא רק “נכון/לא נכון” — הוא משפיע ישירות על ביצועים.
מה המרצה מראה בסוף: הריצו את אותו Pipeline פעמיים — פעם עם $match ראשון, פעם עם $group ראשון — והראו (אם יש כלי מדידה/כמות מסמכים מעובדים) את ההבדל בכמות העבודה שכל גרסה מבצעת, גם אם התוצאה הסופית זהה.