kodkod DATA
Docs
kodkod DATA

מערך שיעור: Query Service

משך: 2.5 שעות אקדמיות (113 דקות).

מטרת השיעור: הסטודנטים יבנו Query Service שמאחד Polyglot Persistence, עם Pagination ו-Cache Invalidation.

בסוף השיעור הסטודנטים צריכים: לממש שליפה עם Pagination, קאש עם Invalidation יזום, ולהסביר את היתרון של Polyglot Persistence בפרויקט זה.

דגש קריטי: זהו שיעור-סיכום לכל נושאי ה-DB בקורס (SQL/EF Core, MongoDB, Redis) — הדגישו זאת במפורש כרגע איסוף.

מהלך השיעור

חלק בשיעורמשךהערות ודגשים
פתיחה וחיבור5 דקותהציגו: Query הוא הפנים היחידות ללקוח — לא Kafka/DB ישירות
Polyglot Persistence15 דקותסיכום: Postgres/Mongo/Redis, כל אחד למה שמתאים
הבעיה: שליפה בלי Pagination10 דקותהדגימו קריסה/איטיות על נתונים רבים
הרעיון: Pagination20 דקותSkip/Limit, page+pageSize
הבעיה: קאש מיושן10 דקותTTL לבד לא מספיק
הרעיון: Cache Invalidation יזום25 דקותinvalidate-cache endpoint
תרגול מודרך28 דקותתרגיל 1+2 + התחלת פרויקט מסכם

דגשים להעברת השיעור

  • זהו רגע טבעי לחזור ולסכם “איזה DB מתי” מכל הקורס — SQL לעקביות/קשרים, NoSQL Document לגמישות, Redis למטמון — טבלת סיכום קצרה שווה זמן.
  • ההדגמה של שליפה בלי Pagination (איטיות/קריסה על נתונים רבים) חשובה לביסוס ה"למה" — אל תסתפקו בהצגת הפתרון בלבד.
  • Cache Invalidation יזום מול TTL בלבד שווה דוגמה קונקרטית עם ציר זמן (מתי הנתון משתנה, מתי TTL פג, מתי המשתמש רואה עדכון).

מושגים

Polyglot Persistence — כמה DB שונים, כל אחד למה שמתאים. Pagination — שליפה בעמודים, לא הכל בבת אחת. Cache Invalidation — ניקוי קאש יזום כשנתונים משתנים.

תרגיל חשיבה

שאלת פתיחה: “יש לכם 2 מיליון רשומות ב-MongoDB. אם GET /records היה מחזיר את כולן בבת אחת, מה קורה ללקוח שקורא ל-API הזה מהדפדפן?”

מהלך: הובילו לתובנה: זמן תגובה ארוך מאוד, גודל תגובה עצום (עלול לקרוס דפדפן/אפליקציה), ועומס מיותר על השרת ועל הרשת. Pagination לא “נוחות” — היא הכרחית לתפקוד תקין בקנה מידה אמיתי.

מה המרצה מראה בסוף: אם אפשר, מלאו MongoDB בכמות נתונים משמעותית (אלפי רשומות) והריצו שליפה בלי Pagination מול שליפה עם Pagination — מדדו זמן תגובה (Stopwatch) בשתי הגרסאות. ההבדל המספרי הוא ההוכחה.