אם אתה רוצה "כל ההזמנות של משתמש X בחודש האחרון יחד עם פרטי התשלום" - SQL עושה את זה ביעילות עם join ו-indexes. ב-NoSQL לרוב תכפיל נתונים או תבצע שתי שאילתות ותאחד באפליקציה.
SQL מול NoSQL - ואיפה Redis נכנס לתמונה
בחירה נכונה של DB היא החלטה ארכיטקטונית, לא "טעם אישי". המפתח הוא להבין מודל נתונים, עומסים, עקביות, ושאילתות - ואז לבחור טכנולוגיה מתאימה.
Rule of thumb: אם אתה צריך joins, טרנזקציות מורכבות, ודוחות - SQL (Postgres) הוא ברירת מחדל חזקה. אם הנתונים גמישים מאוד, הסכימה משתנה תדיר, והאפליקציה גדלה מהר - NoSQL (כמו MongoDB) יכול להאיץ פיתוח. Redis הוא כלי אחר: זיכרון מהיר לקאש ונתונים זמניים.
1) SQL - מסד נתונים רלציוני
SQL DB (כמו PostgreSQL, MySQL) מאחסן נתונים בטבלאות עם סכימה מוגדרת מראש. היתרון הגדול הוא עקביות חזקה, טרנזקציות, ויכולת לשאול שאלות מורכבות בצורה יעילה.
יכולות עיקריות
- ACID transactions (אטומיות, עקביות, בידוד, התמדה)
- Joins בין טבלאות
- Indexes מתקדמים, constraints, foreign keys
- Reporting: GROUP BY, aggregates
מתי זה מנצח
- מערכות עם קשרים בין ישויות (Users, Orders, Payments)
- כאשר correctness קריטי (כספים, הרשאות)
- כשיש שאילתות מגוונות ודוחות
- כאשר רוצים סטנדרט תעשייתי
דוגמה: למה joins חשובים?
2) NoSQL - מסדי נתונים לא רלציוניים
NoSQL הוא משפחה של גישות. הנפוצה בקורסי API היא Document DB כמו MongoDB: כל רשומה היא מסמך JSON-like (BSON) עם שדות גמישים.
סוגים נפוצים
- Document: MongoDB
- Key-Value: Redis (כ-DB), DynamoDB
- Wide-column: Cassandra
- Graph: Neo4j
מתי זה מתאים
- סכימה משתנה במהירות (MVP, מוצר בהתהוות)
- אובייקטים "עמוקים" עם מבנה היררכי
- Scaling אופקי מובנה (תלוי מוצר)
- כשאין צורך ב-joins מורכבים
נקודה חשובה: NoSQL לא אומר "אין סכימה". זה אומר שהסכימה נאכפת לרוב ברמת האפליקציה (Pydantic) ולא ברמת ה-DB. בפרודקשן זה דורש משמעת.
3) עקביות ו-CAP - במילים פשוטות
כשמערכת גדלה ומופצת (distributed), קשה לקבל תמיד: Consistency + Availability + Partition tolerance בו זמנית. בפועל, רוב המערכות בוחרות tradeoffs. PostgreSQL נותן עקביות חזקה, חלק ממערכות NoSQL בוחרות זמינות גבוהה עם eventual consistency.
מה המסקנה הפרקטית לקורס?
- למערכת CRUD עם קשרים - Postgres הוא בחירה נכונה.
- לפרוטוטייפ מהיר עם נתונים גמישים - MongoDB יכול לעבוד טוב.
- ל-RAG metadata ולוגים - גם Postgres וגם Mongo עובדים, תלוי שאילתות.
4) Redis - זיכרון מהיר לקאש ונתונים זמניים
Redis הוא in-memory store מהיר מאוד. הוא לא "ה-DB הראשי" של רוב המערכות, אלא שכבה שמאיצה או מפשטת:
- Caching: לשמור תוצאות חישוב/שליפה (למשל תוצאות RAG retrieval או תגובות API).
- Sessions: session tokens, state של משתמש.
- Rate limiting: לספור בקשות לפי משתמש בזמן קצר.
- Queues: תורים פשוטים או pub/sub (תלוי צורך).
למה Redis מתאים לדברים "שלא אכפת לנו אם יימחקו"? כי הוא בזיכרון. אפשר להגדיר TTL לכל מפתח. אם הוא נמחק - המערכת עדיין עובדת, רק קצת איטית יותר או תבקש את הנתון מחדש מהמקור.
# דוגמה רעיונית:
# key: "rag:qhash:{hash(question)}"
# value: JSON עם answer + sources
# TTL: 10 דקות
5) החלטה ארכיטקטונית לפי מקרה שימוש
SQL (Postgres) - מתי לבחור
- נתונים עם קשרים וחוקים (constraints)
- היסטוריה ודוחות
- טרנזקציות
- צוות שרוצה סטנדרט תעשייתי
NoSQL (Mongo) - מתי לבחור
- סכימה גמישה
- מסמכים היררכיים (nested)
- שינויים תכופים במבנה נתונים
- גישה לפי document id או שאילתות פשוטות
Redis - מתי לבחור
- קאש לתוצאות יקרות (LLM, retrieval, aggregation)
- נתונים זמניים עם TTL
- Rate limiting ו-sessions
- תורים קלים או pub/sub
תרגול
שאלות בדיקה (10)
- מה היתרון של ACID transactions ב-SQL?
- מתי joins הופכים לקריטיים?
- למה ב-NoSQL הסכימה "נודדת" לאפליקציה?
- מה tradeoff של eventual consistency?
- תן דוגמה למקרה שבו Mongo עדיף על Postgres.
- תן דוגמה למקרה שבו Postgres עדיף על Mongo.
- למה Redis מתאים לקאש ולא ל-DB ראשי?
- מה זה TTL ולמה הוא חשוב?
- איך Redis יכול לעזור ב-rate limiting?
- למה לא לשמור תמונות כ-BLOB ב-Postgres בדרך כלל?
משימת בית (תכנון דאטה)
קח מוצר קטן של GenAI: משתמשים מעלים תמונה, עושים edit, ושומרים תוצאה בגלריה.
- תכנן מה נשמר ב-Object Storage (S3-like) ומה נשמר ב-DB.
- בחר SQL או NoSQL לניהול הגלריה וההרשאות - ונמק.
- הוסף Redis cache לתוצאה של "list gallery" עם TTL של 60 שניות.
הדגש: לא לכתוב קוד - לכתוב החלטות, סכימות, וזרימת נתונים.
בדיקת פתרון (Checklist)
- הפרדת בבירור בין binary objects לבין metadata.
- הסברת למה SQL/NoSQL מתאים לדרישות שאילתות שלך.
- הצעת Redis רק לדברים זמניים, עם TTL ברור.
- הצעת דרך invalidation לקאש (למשל למחוק מפתח אחרי upload חדש).