מסדי נתונים א-רלציוניים - NoSQL מוסברים בפשטות¶
כל פעם שמישהו שואל אותי "אז מתי משתמשים ב-NoSQL", אני שואל בחזרה שאלה אחת: אתם יודעים למה בכלל צריך אלטרנטיבה למסד נתונים רלציוני? רוב האנשים לא באמת יודעים, ולכן הם או מפחדים מ-NoSQL בלי סיבה, או מנסים להשתמש בו לכל דבר כי שמעו שהוא "מודרני". שני הצדדים טועים. בואו נבין למה NoSQL בכלל קיים.
מאיפה הצורך הגיע¶
מסדי נתונים רלציוניים, כמו שכבר הסברתי בפוסטים קודמים, בנויים סביב טבלאות עם סכמה קבועה - מראש מגדירים אילו עמודות יש ומאיזה סוג. זה מעולה לרוב היישומים, אבל בעשור וחצי האחרונים חברות ענק כמו גוגל ואמזון נתקלו בשני אתגרים שמסד רלציוני מתקשה בהם:
- קנה מידה עצום. מיליארדי משתמשים ומיליארדי רשומות, שקשה לפזר על פני הרבה שרתים כשהמידע קשור חזק בקשרים בין טבלאות.
- מבנה מידע משתנה. לפעמים אין לכם מראש סכמה ברורה וקבועה - כל רשומה יכולה להיראות קצת שונה, ואתם לא רוצים לעדכן את מבנה הטבלה כל פעם שמשהו משתנה.
מכאן נולדו מסדי נתונים א-רלציוניים, שנקראים בקיצור NoSQL, שם שקצת מטעה כי הוא נשמע כמו "בלי SQL", אבל בפועל הכוונה היא "לא רק SQL" - מודלים אחרים לגמרי לארגון מידע.
הסוגים העיקריים של NoSQL¶
זה לא קטגוריה אחת, אלא כמה גישות שונות לגמרי:
- מסדי מסמכים - Document. שומרים כל רשומה כמסמך שלם, בדרך כלל בפורמט דמוי JSON, בלי צורך שכל המסמכים יראו זהים. MongoDB היא הדוגמה הכי מוכרת.
- מסדי מפתח-ערך - Key-Value. הפשוטים ביותר - כל פריט מידע נגיש לפי מפתח ייחודי, בדיוק כמו מילון בפייתון, אבל בקנה מידה ענק. Redis היא דוגמה נפוצה, בעיקר לזיכרון מטמון מהיר.
- מסדי עמודות - Column-family. מותאמים לכתיבה וקריאה מהירה של כמויות ענק של נתונים בעמודות, כמו Cassandra, בשימוש נפוץ במערכות עם קצב כתיבה גבוה מאוד.
- מסדי גרפים - Graph. מתמחים בייצוג קשרים מורכבים בין ישויות, כמו רשתות חברתיות, עם דוגמה כמו Neo4j.
לכל אחד מהם שימושים אחרים לגמרי, ואין דבר כזה "NoSQL" אחיד שאפשר להשוות ישירות למסד רלציוני.
אז מה מוותרים עליו כשעוברים ל-NoSQL¶
הבחירה הזאת לא באה בחינם, ופה נמצא ההבדל האמיתי מרוב ההשוואות השטחיות ברשת.
מסד נתונים רלציוני נותן לכם הבטחות חזקות - עקביות מיידית, קשרים ברורים בין טבלאות שנאכפים על ידי המסד עצמו, ושפת שאילתות עשירה שיודעת לחבר מידע ממקורות שונים בקלות. הרבה מסדי NoSQL מוותרים על חלק מההבטחות האלה בתמורה לקנה מידה וגמישות. חלקם מוותרים על עקביות מיידית לטובת "עקביות סופית" - כלומר יכול לעבור זמן קצר עד שכל השרתים ברשת "מסתנכרנים" לאותו מידע. חלקם לא אוכפים קשרים בין רשומות בכלל, ומשאירים את זה באחריות הקוד שלכם.
זו הסיבה שהמעבר ל-NoSQL הוא לא שדרוג אוטומטי, אלא החלטת פשרה - מוותרים על משהו כדי לקבל משהו אחר.
מתי NoSQL באמת הבחירה הנכונה¶
לא כל אפליקציה עם הרבה משתמשים צריכה NoSQL. רוב הפרויקטים, כולל כאלה עם מיליוני משתמשים, עובדים מצוין על מסד רלציוני טוב שתוכנן נכון. NoSQL מתאים במיוחד כשיש לכם:
- מבנה נתונים שמשתנה כל הזמן ולא נוח לכפות עליו סכמה קבועה.
- צורך אמיתי בקנה מידה שחוצה עשרות שרתים במקביל.
- מקרה שימוש ספציפי כמו מטמון מהיר (Redis) או חיפוש טקסט חופשי.
הטעות הכי נפוצה שאני רואה היא סטארטאפים שבוחרים NoSQL "כי זה מה שגוגל עושה", בלי בכלל להגיע לקנה מידה שבו זה נדרש, ומוצאים את עצמם נלחמים במגבלות בלי לקבל שום תמורה אמיתית על זה.
איך ניגשים לזה בפועל¶
ההמלצה הכי טובה שאני יכול לתת היא ללמוד קודם מסד נתונים רלציוני לעומק, ורק אחר כך להתקדם ל-NoSQL. ברגע שמבינים באמת למה טבלאות וקשרים עובדים כמו שהם עובדים, קל הרבה יותר להבין מה בדיוק NoSQL מוותר ומה הוא מרוויח בתמורה. בקורס צד-שרת בדיוק ככה בונים את הבסיס, ומשם קל להתקדם למודלים נוספים.
יש לכם פרויקט שמתלבט בין רלציוני ל-NoSQL? זה בדיוק סוג הדיון שמתקיים בקהילה שלנו.