1.4 מבני נתונים א רלציונים הרצאה

מסדי נתונים א־רלציוניים (NoSQL)¶

הקדמה¶

מסד נתונים א־רלציוני (NoSQL) הוא מסד נתונים שאינו מבוסס על טבלאות וקשרים כמו במסד רלציוני.
במקום סכימה קבועה מראש (columns, foreign keys וכו’), הנתונים נשמרים במבנים גמישים יותר כמו:
- מסמכים (Documents) - ממש JSON-ים.
- מפתח וערך - key and value
- גרפים.
הרעיון המרכזי:
גמישות, סקייל גבוה, ופשטות עבודה- לפעמים על חשבון קשרים מורכבים ו־JOINים.

למה בכלל צריך NoSQL?¶

מסדים רלציוניים מצוינים, אבל יש מקרים שבהם הם פחות מתאימים:

נתונים עם מבנה משתנה (לא כל רשומה נראית אותו הדבר)
מערכות עם עומסים מאוד גבוהים (מאות אלפי בקשות בשנייה)
עבודה עם JSON טבעי.

לדוגמה:
- מערכת משתמשים עם הגדרות שונות לכל משתמש
- מערכת תוכן (CMS)
- מערכת לוגים / אירועים

סוגים נפוצים של מסדי NoSQL¶

1. Document Store (הנפוץ ביותר)¶

מסד נתונים שמאחסן מסמכים, לרוב בפורמט JSON.
דוגמאות:
- MongoDB
- CouchDB
- Firestore
מסמך לדוגמה:

{
  "_id": "trip_123",
  "name": "Trip to Dubai",
  "people": 2,
  "hotels": [
    { "name": "Hamilton", "stars": 5 },
    { "name": "Alexander", "stars": 4 }
  ]
}

אין טבלאות, אין JOIN –
כל המידע שקשור לישות אחת נשמר ביחד.

2. Key-Value Store¶

מבוסס על זוגות של מפתח וערך.
דוגמאות:
- Redis
- DynamoDB (במצב פשוט)

key: user:42
value: { "name": "Amit", "role": "admin" }

משמש בעיקר ל:
- Cache
- Sessions
- Tokens
- Counters

3. Graph Databases¶

מסדים שמתאימים לקשרים מורכבים מאוד.
דוגמאות:
- מסד Neo4j

שימושים:
- רשתות חברתיות
- המלצות (מי מכיר את מי)
- ניתוח קשרים

MongoDB – מסד NoSQL נפוץ¶

מבנה בסיסי¶

ב־MongoDB יש:
- Database
- Collection (בערך כמו טבלה)
- Document (בערך כמו שורה)
אבל:
- אין סכימה קשיחה
- כל מסמך יכול להיראות אחרת

דוגמה לסכמה של trip ב־MongoDB¶

{
  "_id": "trip_1",
  "name": "eilat vacation",
  "people": 5,
  "hotels": [
    {
      "hotel_id": "h1",
      "name": "Hamilton",
      "stars": 5
    }
  ],
  "flights": [
    {
      "from": "TLV",
      "to": "ETH",
      "airline": "ELAL"
    }
  ]
}

שימו לב:
- אין טבלת קשר
- הכל מקונן (embedded)
- קריאה של טיול אחד מחזירה את כל המידע עליו

Embedded vs References¶

אז מה תכלס ההבדל העיקרי בין טבלאות לבין מסמכים (documents)
שבמסמכים יש לנו "קינון" (דמיינו json מורכב) ובטבלאות אנחנו עובדים עם references (קישורים, ומפתחות)

Embedded (קינון)¶

שומרים אובייקטים בתוך אובייקט:

hotels: [{ name, stars }]

יתרונות:
- מהיר
- פשוט
- אין JOIN

חסרונות:
- כפילות מידע
- קשה לעדכן הרבה מסמכים יחד

References (קישור באמצעות ID)¶

{
  "trip_id": "t1",
  "hotel_ids": ["h1", "h2"]
}

יתרונות:
- פחות כפילות
- יותר סדר

חסרונות:
- צריך יותר שאילתות
- אין JOIN אמיתי כמו SQL

עבודה עם MongoDB בפייתון¶

הרצה ב־Docker:¶

docker run --name mongo-test -p 27017:27017 -d mongo:latest

חיבור בפייתון:¶

from pymongo import MongoClient

client = MongoClient("mongodb://localhost:27017")
db = client.trip_db # גישה למסד
trips = db.trips # גישה לcollection

הוספת טיול:¶

trips.insert_one({
    "name": "eilat fun",
    "people": 3,
    "hotels": [
        {"name": "Hamilton", "stars": 5}
    ]
})

שליפה:¶

trip = trips.find_one({"name": "eilat fun"})

SQL vs NoSQL – השוואה¶

נושא	SQL	NoSQL
מבנה	קשיח	גמיש
JOINים	כן	לא
סכימה	חובה	אופציונלי
סקייל	טוב	מצוין
שימוש	מערכות עסקיות	מערכות גדולות ודינמיות

מתי לבחור NoSQL?¶

כשהדאטה משתנה הרבה
כשעובדים עם JSON כל הזמן
כשביצועים וסקייל חשובים יותר ממבנה קשיח
כשאין צורך ב־JOINים מורכבים

מתי לא?¶

מערכות שדורשות עקביות חזקה (Strong Consistency)

סיכום¶

NoSQL ≠ תחליף ל־SQL, אלא כלי נוסף
MongoDB הוא הבחירה הנפוצה ביותר למתחילים
ותרו על JOINים – תכננו את הדאטה מראש
תכנון נכון של מבנה המסמכים קריטי להצלחה
בעולם האמיתי: הרבה מערכות משלבות SQL + NoSQL יחד