.jpg)
לפני כעשור, החלו להתפרסם בסיסי נתונים אשר חרגו מהמודל הטבלאי ששלט בתחום יותר משני עשורים – בסיסי נתונים אלו זכו לשם הכולל NoSQL. במאמר זה ננסה לסקור את התהליכים והסיבות שהביאו להצלחה ולפופולריות ההולכת וגדלה של בסיסי נתונים אלו.
:נתחיל במעט היסטוריה
בשנת 1979 הוציאה לשוק חברת Oracle את בסיס הנתונים המסחרי הראשון, ומאז ועד היום בסיסי הנתונים הטבלאיים (relational databases) הינם אבן בנין מרכזית כמעט בכל מערכת תוכנה.
המודל הטבלאי שמימשו בסיסי נתונים אלו, היה מבוסס על שמירת רשומות והקשרים ביניהם בטבלאות בעלות סכימה מוגדרת מראש. מודל זה איפשר נורמליזציה של נתונים (מניעה של שכפול נתונים) והחלת כללי וולידציה עליהם.
היות ובסיסי הנתונים הטבלאיים תוכננו בראשית דרכם בעיקר עבור ארגונים פיננסים, תשומת הלב רבה בתכנונם היה על האמינות של הנתונים (כי הרי מדובר בכסף). בסיסי נתונים אלו נבנו לפי עקרונות ה- ACID שעיקרם שמירה על האטומיות והקונסיסטנטיות של הטרנזאקציות השונות.
בשנות האלפיים, עם פריצת האינטרנט לחיינו, החלה תעשיית התוכנה לעבור שינוי עמוק: מתעשייה שהתמקדה ביצור תוכנות מסחריות ״רציניות״ עבור ארגונים וחברות המוכנות לשלם במיטב כספן, לעולם של שירותי אינטרנט ותוכן, רשתות חברתיות ואפליקציות מובייל, המשמשים לעיתים מיליוני משתמשים בו זמנית.
:מהפכת האינטרנט ומהפכת המובייל שהגיעה בעקבותיה הציבו בפני עולם בסיסי הנתונים סדרה של אתגרים ובראשם
• הצורך להתמודד עם כמויות גדולות של דאטה שהיו בסדרי גודל גדולים יותר מאשר באפליקציות קלאסיות (אפילו שירותי אינטרנט בינוניים בגודלם אוגרים כמויות של נתונים שלא היו מביישות בנק גדול).
• הצורך בזמינות גבוהה (High Availability) - היכולת לאפשר גישה לנתונים מכל מקום בעולם ובמהירות רבה. פן נוסף של הזמינות הגבוהה הוא ההבנה שתשתיות האינטרנט לא תמיד עובדות ב-100%, ויש צורך לאפשר שירות גם כאשר חלק מהתשתית אינו עובד (למשל שרת שנופל או בעיות בתקשורת בין השרתים השונים).
הטיפול בריבוי הנתונים מצריך הגדלה משמעותית של משאבי העיבוד, אותה ניתן להשיג באחת משתי הדרכים הבאות:
Vertical Scaling
שימוש בשרתים חזקים יותר - שיטה זו הינה יקרה ומוגבלת, היות ויש גבול לכח החישוב שיש לשרת בודד.
Horizontal Scaling
שימוש ביותר שרתים - שיטה זו הינה יותר זולה (שני מחשבים עולים פחות ממחשב בודד עם יכולת חישוב כפולה) ואינה מוגבלת (תמיד אפשר להוסיף עוד שרתים). שיטה זו מצריכה חלוקה של הנתונים בין השרתים השונים.
בעולם הקלאסי של בסיסי הנתונים, התמיכה בקשרים בין טבלאות והשמירה על עקרונות ה- ACID (שמחייבת תמיכה בטרנזאקציות, נעילות ועוד) מקשים מאוד על חלוקת הנתונים בין שרתים ולכן כמעט תמיד מצריכים שימוש ב Vertical Scaling על מנת לתמוך בכמויות גדולות של נתונים - וכאמור שיטה זו הינה מוגבלת ביכולת העיבוד של שרת בודד.
כדי להגיע לזמינות גבוהה (High Availability) יש לשכפל את המידע על גבי שרתים שונים - כך ניתן גם לקצר את זמני התגובה (על ידי פניה לשרת הקרוב ביותר), להוריד עומסים (על ידי load balancing) ולאפשר פניה לשרתים חלופיים במידה ויש תקלה בשרת מסוים.
גם הזמינות הגבוהה לא חיה בכפיפה אחת עם עקרון הקונסיסטנטיות, משפט ה- CAP Theorem קובע כי בהינתן נתק בתקשורת בין השרתים, אזי לא ניתן לשמור בו-זמנית על קונסיסטנטיות ו- High Availability ויש לבחור ביניהם.
במשך הזמן, התגבשה ההכרה כי המודל שהציעו בסיסי הנתונים הטבלאיים לא תמיד מתאים לכל הצרכים שעלו בעולם האפליקציות המודרניות, וכי לעיתים ניתן ואפילו כדאי לוותר על חלק מהיתרונות של המודל הטבלאי על מנת להרוויח יתרונות אחרים:
• במקרים רבים שמירת נתונים במבנים לא טבלאיים יותר נוחה לשימוש מאשר בצורה טבלאית הסטנדרטית. לדוגמא: שמירת נתונים במסמך json מאפשרת מימוש של רמות היררכיה בצורה פשוטה וקלה שאינה אפשרית בשימוש בטבלה.
• ישנם מקרים בהם נעדיף זמינות גבוהה על קונסיסטנטיות. לדוגמא: באתר המציע מבצעי מכירות עדיף שיוצג ללקוח קטלוג לא מעודכן לחלוטין, מאשר לא להציג ללקוח קטלוג בכלל.
ענקיות האינטרנט ובעקבותיהן חברות רבות אימצו את ההבנות הנ״ל והחלו לפתח בסיסי נתונים המיועדים לנפחי ענק שהציעו מודלים שונים של מבני נתונים, ומודלים מרוככים יותר של קונסיסטנטיות.
החלוצות בתחום היו Google שפיתחה ב- 2004 את BigTable ו- Amazon שפיתחה באותה שנה את בסיס הנתונים Dynamo. כיום ישנם פרוייקטים רבים של בסיסי נתונים לא רלציונים כגון MongoDB,CouchDB,Cassandra,Project Voldemort, Redis ועוד.
אז מה זה בעצם ?NoSQL האם כל בסיס נתונים שלא משתמש במודל נתונים טבלאי יכול להיות מוגדר תחת כותרת זו? במהלך השנים היו מספר ניסיונות לפתח בסיסי נתונים במודלים אחרים
מקובל לכלול במונח NoSQL רק בסיסי נתונים מודרניים, שאינם מממשים מודלים של סכמות וטבלאות, ואשר מאפשרים ריצה ב- Cluster של מספר רב של שרתים (Horizontal Scaling) על מנת לתמוך בנפחי ענק של נתונים.
?האם אנו חוזים בסופם של בסיסי הנתונים הטבלאיים
התשובה היא: ממש לא! האפשרות להגדרת קשרים בין טבלאות, והשמירה על עקרונות ה- ACID עדיין קריטיים לתוכנות רבות ובמקרים רבים הניסיון להגיע לאותן תוצאות בעזרת בסיס נתונים NoSQL נדון לכישלון. הגישה הנכונה היא להתאים לכל צורך את בסיס הנתונים המתאים עבורו ובמידת הצורך לשלב באותה תוכנה מספר בסיסי נתונים שונים.
כיום כל ספקי הענן הגדולים מציעים שירותי DB מנוהלים (גם עבור SQL וגם עבור NoSQL) שהופכים את השילוב לקל וכדאי.
Co-Founder & CTO, DataRails ,מאת: עודד הר-טל
לפני כעשור, החלו להתפרסם בסיסי נתונים אשר חרגו מהמודל הטבלאי ששלט בתחום יותר משני עשורים – בסיסי נתונים אלו זכו לשם הכולל NoSQL. במאמר זה ננסה לסקור את התהליכים והסיבות שהביאו להצלחה ולפופולריות ההולכת וגדלה של בסיסי נתונים אלו.
:נתחיל במעט היסטוריה
בשנת 1979 הוציאה לשוק חברת Oracle את בסיס הנתונים המסחרי הראשון, ומאז ועד היום בסיסי הנתונים הטבלאיים (relational databases) הינם אבן בנין מרכזית כמעט בכל מערכת תוכנה.
המודל הטבלאי שמימשו בסיסי נתונים אלו, היה מבוסס על שמירת רשומות והקשרים ביניהם בטבלאות בעלות סכימה מוגדרת מראש. מודל זה איפשר נורמליזציה של נתונים (מניעה של שכפול נתונים) והחלת כללי וולידציה עליהם.
היות ובסיסי הנתונים הטבלאיים תוכננו בראשית דרכם בעיקר עבור ארגונים פיננסים, תשומת הלב רבה בתכנונם היה על האמינות של הנתונים (כי הרי מדובר בכסף). בסיסי נתונים אלו נבנו לפי עקרונות ה- ACID שעיקרם שמירה על האטומיות והקונסיסטנטיות של הטרנזאקציות השונות.
בשנות האלפיים, עם פריצת האינטרנט לחיינו, החלה תעשיית התוכנה לעבור שינוי עמוק: מתעשייה שהתמקדה ביצור תוכנות מסחריות ״רציניות״ עבור ארגונים וחברות המוכנות לשלם במיטב כספן, לעולם של שירותי אינטרנט ותוכן, רשתות חברתיות ואפליקציות מובייל, המשמשים לעיתים מיליוני משתמשים בו זמנית.
:מהפכת האינטרנט ומהפכת המובייל שהגיעה בעקבותיה הציבו בפני עולם בסיסי הנתונים סדרה של אתגרים ובראשם
• הצורך להתמודד עם כמויות גדולות של דאטה שהיו בסדרי גודל גדולים יותר מאשר באפליקציות קלאסיות (אפילו שירותי אינטרנט בינוניים בגודלם אוגרים כמויות של נתונים שלא היו מביישות בנק גדול).
• הצורך בזמינות גבוהה (High Availability) - היכולת לאפשר גישה לנתונים מכל מקום בעולם ובמהירות רבה. פן נוסף של הזמינות הגבוהה הוא ההבנה שתשתיות האינטרנט לא תמיד עובדות ב-100%, ויש צורך לאפשר שירות גם כאשר חלק מהתשתית אינו עובד (למשל שרת שנופל או בעיות בתקשורת בין השרתים השונים).
הטיפול בריבוי הנתונים מצריך הגדלה משמעותית של משאבי העיבוד, אותה ניתן להשיג באחת משתי הדרכים הבאות:
Vertical Scaling
שימוש בשרתים חזקים יותר - שיטה זו הינה יקרה ומוגבלת, היות ויש גבול לכח החישוב שיש לשרת בודד.
Horizontal Scaling
שימוש ביותר שרתים - שיטה זו הינה יותר זולה (שני מחשבים עולים פחות ממחשב בודד עם יכולת חישוב כפולה) ואינה מוגבלת (תמיד אפשר להוסיף עוד שרתים). שיטה זו מצריכה חלוקה של הנתונים בין השרתים השונים.
בעולם הקלאסי של בסיסי הנתונים, התמיכה בקשרים בין טבלאות והשמירה על עקרונות ה- ACID (שמחייבת תמיכה בטרנזאקציות, נעילות ועוד) מקשים מאוד על חלוקת הנתונים בין שרתים ולכן כמעט תמיד מצריכים שימוש ב Vertical Scaling על מנת לתמוך בכמויות גדולות של נתונים - וכאמור שיטה זו הינה מוגבלת ביכולת העיבוד של שרת בודד.
כדי להגיע לזמינות גבוהה (High Availability) יש לשכפל את המידע על גבי שרתים שונים - כך ניתן גם לקצר את זמני התגובה (על ידי פניה לשרת הקרוב ביותר), להוריד עומסים (על ידי load balancing) ולאפשר פניה לשרתים חלופיים במידה ויש תקלה בשרת מסוים.
גם הזמינות הגבוהה לא חיה בכפיפה אחת עם עקרון הקונסיסטנטיות, משפט ה- CAP Theorem קובע כי בהינתן נתק בתקשורת בין השרתים, אזי לא ניתן לשמור בו-זמנית על קונסיסטנטיות ו- High Availability ויש לבחור ביניהם.
במשך הזמן, התגבשה ההכרה כי המודל שהציעו בסיסי הנתונים הטבלאיים לא תמיד מתאים לכל הצרכים שעלו בעולם האפליקציות המודרניות, וכי לעיתים ניתן ואפילו כדאי לוותר על חלק מהיתרונות של המודל הטבלאי על מנת להרוויח יתרונות אחרים:
• במקרים רבים שמירת נתונים במבנים לא טבלאיים יותר נוחה לשימוש מאשר בצורה טבלאית הסטנדרטית. לדוגמא: שמירת נתונים במסמך json מאפשרת מימוש של רמות היררכיה בצורה פשוטה וקלה שאינה אפשרית בשימוש בטבלה.
• ישנם מקרים בהם נעדיף זמינות גבוהה על קונסיסטנטיות. לדוגמא: באתר המציע מבצעי מכירות עדיף שיוצג ללקוח קטלוג לא מעודכן לחלוטין, מאשר לא להציג ללקוח קטלוג בכלל.
ענקיות האינטרנט ובעקבותיהן חברות רבות אימצו את ההבנות הנ״ל והחלו לפתח בסיסי נתונים המיועדים לנפחי ענק שהציעו מודלים שונים של מבני נתונים, ומודלים מרוככים יותר של קונסיסטנטיות.
החלוצות בתחום היו Google שפיתחה ב- 2004 את BigTable ו- Amazon שפיתחה באותה שנה את בסיס הנתונים Dynamo. כיום ישנם פרוייקטים רבים של בסיסי נתונים לא רלציונים כגון MongoDB,CouchDB,Cassandra,Project Voldemort, Redis ועוד.
אז מה זה בעצם ?NoSQL האם כל בסיס נתונים שלא משתמש במודל נתונים טבלאי יכול להיות מוגדר תחת כותרת זו? במהלך השנים היו מספר ניסיונות לפתח בסיסי נתונים במודלים אחרים
מקובל לכלול במונח NoSQL רק בסיסי נתונים מודרניים, שאינם מממשים מודלים של סכמות וטבלאות, ואשר מאפשרים ריצה ב- Cluster של מספר רב של שרתים (Horizontal Scaling) על מנת לתמוך בנפחי ענק של נתונים.
?האם אנו חוזים בסופם של בסיסי הנתונים הטבלאיים
התשובה היא: ממש לא! האפשרות להגדרת קשרים בין טבלאות, והשמירה על עקרונות ה- ACID עדיין קריטיים לתוכנות רבות ובמקרים רבים הניסיון להגיע לאותן תוצאות בעזרת בסיס נתונים NoSQL נדון לכישלון. הגישה הנכונה היא להתאים לכל צורך את בסיס הנתונים המתאים עבורו ובמידת הצורך לשלב באותה תוכנה מספר בסיסי נתונים שונים.
כיום כל ספקי הענן הגדולים מציעים שירותי DB מנוהלים (גם עבור SQL וגם עבור NoSQL) שהופכים את השילוב לקל וכדאי.
Co-Founder & CTO, DataRails ,מאת: עודד הר-טל
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר