NoSQL – Not only SQL

[אני שמח לארח שנית את שחר בר (ברזניצקי), ארכיטקט מנוסה בתחום High Scalable Applications.]

ממי לביא העלה בפוסט המצויין שפירסם את הטעות שביצירת סכמת בסיס נתונים "גנרית" על בסיס נתונים רלציוני בעל יכולות ACID. כפי שאני רואה את זה הנושא שממי העלה הוא חלק ממרחב הבעייה הכללי העוסק בשימוש בכלי הנכון למטרה הנכונה. בהקשר של Data bases, או במונח הכללי יותר של data stores, אכן עולה צורך בבסיס נתונים גנרי עבור מערכות. הצורך עצמו לגיטימי בסוגי מערכות רבות ולכן רצוי למצוא עבורו את הפתרון הנכון ביותר. כפי שממי הסביר בצורה נכונה sql server או אף Oracle Database אינם בהכרח מתאימים לסוג כזה של אכסון ואחזור מידע.

אחד הפתרונות הקיימים לצורך זה הינו בקבוצה גדולה של data stores המאוגדים כולם תחת שם נושא כללי של NoSQL. למרות שבתחילה חלק אנשים שונים בתעשייה התייחסו אל הנושא כשלילת המודל הרלציוני בחיפוש אחר מודל חדש "טוב יותר" היום ברור לרוב העוסקים בתחום שמדובר למעשה ב"לא רק SQL".

אז מהו בעצם העולם הזה של NoSQL?

ראשית חשוב לציין שמדובר בתחום עצום, פעיל וגועש בו פעילים מספר רב של פרויקטים שמשתנים ומתעדכנים במהירות. לא ניתן לכסות בפוסט קצר את הרקע התיאורטי/אקדמי ואת הניסיון המעשי הרב שנצבר בשנים האחרונות בעולם בשימוש במוצרים אלו.

בראשית היו לנו אתרי אינטרנט עם פעילות הולכת וגואה שדרשו עוד ועוד שרתי Database מאחוריהם כדי לעמוד בעומס (כמו שרובנו חווינו, בסיס הנתונים הוא צוואר בקבוק קלאסי). חשבו רבים וטובים שניתן בעצם להוציא לcache את המידע ולחסוך חלק ניכר מהעומס מבסיס הנתונים וכך התפתחה ארכיטקטורה מבוססת in memory distributed cache + reverse proxies for data המשתמשת רבים מהאתרים הגדולים בכל אחת מהטכנולוגיות הקיימות בשוק. עם הזמן אנשים התחילו לתהות למה בעצם אנחנו ממשיכים להחזיק מאחורה בסיס נתונים רלציוני חזק ומתוחכם כאשר אנחנו לא באמת צריכים את היכולות שלו עבור חלקים ניכרים מהאפליקציה. תחושה זו היוותה בעצם את הקרקע הפורייה לרעיונות חדשניים ו"חתרניים" שהתפתחו לכדי עולם שלם של פתרונות המאוגדים תחת השם NoSQL.

מדובר באוסף מוצרים, חלקם מוצרים סגורים בתשלום וחלקם במודלים שונים של open source המציעים פתרונות שונים לאכסון נתונים ואחזורם החורגים מהמסגרת הרלציונית המיועדים לסביבות הדורשות ביצועים גבוהים ביותר ועמידה בעומסים יחד עם גישה מקלה לשלמות ונכונות המידע בכל רגע נתון. פתרונות אלו קיימים בשוק כמה שנים וצברו תאוצה בשנה האחרונה בעיקר בתחום של אתרי אינטרנט בעל היקפי מידע עצומים. רבים מהפרויקטים התחילו כפיתוחים פנימיים בצוותי הפיתוח של האתרים הגדולים בעולם ויצאו בהמשך כמוצרי קוד פתוח.

מרבית המוצרים הנ"ל ניתנים להתקנה הן על מערכות הפעלה של Microsoft והן על מערכות הפעלה של חברות מתחרות. כמו כן למרבית המוצרים המאוזכרים במאמר ניתן להתממשק בקלות מקוד .net הן באמצעות APIים וdrivers לעבודה ישירה והן באמצעות כלי ORM הקיימים בשוק.

ניתן לחלק את עולם המוצרים הנ"ל לפי הצורה בה רואים ומתייחסים אל המידע*:

Document stores – בקבוצה זו בולטים MongoDB, ב וcouchDB (ואפילו lotus notes יכול להשתייך לקבוצה זו).

Key value stores – בקבוצה זו מוצרים מבוססי דיסק או זיכרון. מוצרים בולטים בקבוצה זו:

Azure table storage של Microsoft, memcachedb , velocity של Microsoft, Cassandra של facebook המשמש גם את DIGG, Dynamo של amazon (ו-project voldemort שהוא מימוש הopen source לפי הwhite paper של Dynamo), TokyoTyrant ו-berkelyDB.

Multi-dimensional tabular stores – בקבוצה זו ניתן למצוא את BigTable של google (ו-HBase המבוסס על הwhite paper של BigTable) ואת HyperTable

*חשוב לציין שמדובר בחלוקה קשה מאד לביצוע מאחר ולרבים מהמוצרים בקבוצות השונות תכונות חופפות ואף ההגדרות עצמן של הקבוצות נתונות למחלוקת. למשל, רבים מגדירים קבוצה בשם record stores ומכילים בתוכה הן את Cassandra והן את hbase

המאפיינים המרכזיים של מוצרים אלו הינם:

- התייחסות פחות קשיחה למידע. במרביתם אין סכמה קבועה וניתן לשלב באותו data store (המקביל לטבלה רלציונית לצורך העניין) רשומות בעלות מבנה/סכמה שונה. למשל – אם אני מחזיק רשימה של פרופילי משתמש בdocument store לחלקם יהיו ארבעה מאפיינים בלבד ולאחרים יהיו 20 וזאת מבלי להכיל sparse data.

- הימנעות כמעט מוחלטת מנעילות. מאחר ועולם זה של NoSQL התפתח בעיקר מעולם אתרי האינטרנט הענקיים אחת הרעות החולות איתם מנסים להתמודד הינה נעילות מידע הפוגעות בביצועים ובזמינות המידע.

- התאמה קונספטואלית מירבית לעבודה בענן בכך שמרבית הdata stores הנ"ל מיועדים לקונפיגורציה של ריבוי nodes ושל עיבוד מקבילי רחב היקף.

- המידע ברבים מהמקרים אינו מנורמל מאחר ובד"כ אין פעולת join (את פעולת Join נחליף בד"כ בפעולת map-reduce כפי שלמשל עושים באתר MySpace באמצעות פלטפורמת qizmt הכתובה ב .netוזמינה להורדה ושימוש חופשי)

- שימוש רב בbson ו-json כ-DTO.

- ישנו דגש גדול על partition-tolerance שמשמעותו היכולת לבצע חלוקה של המידע למספר nodes בד"כ באופן דינאמי מבלי לאבד מכלל היכולות המוגדרות של הdata store.

- ואולי הכי בולט - מימוש רק חלק ממרכיבי ACID ולא בצורה מלאה. למשל קיים בחלקם מימוש של eventual consistency שמשמעותו הינה "בסופו של דבר המידע שלך יהיה consistent" כאשר סופו של דבר תחום כמובן בתחום זמן מוגדר היטב. בהתייחסות לבעייה המקורית ברור שלא כדאי לתכנת מערכת כספית לATM המבוססת על מודל זה אך אין סיבה שבמימוש של רשת חברתית נתעקש על קונסיסטנטיות מיידית של המידע...

מאחורי נושא זה של מימוש חלקי בלבד של תכונות ACID עומדת תיאורית CAP ולפייה מערכת מחשב מבוזרת לעולם לא תוכל לממש את שלושת התכונות הללו יחדיו:

• קונסיסטנטיות
• זמינות
• עמידות לחלוקה (partition) של המידע

ניתן לסכם ולאמר שמרבית פתרונות NoSQL הינם דרכי התמודדות עם אילוצי תיאורמת CAP תחת דרישות ביצועים גבוהות מאד מחד ודרישות מקלות יותר מאידך בתחום האילוצים המסורתי המאפיין בסיסי נתונים רלציוניים השמים דגש של מימוש מלא וקשיח של ACID.

ואיך כל זה בעצם מתקשר לפוסט של ממי שממנו התחלנו? ברבים מהמקרים הדרישה היא לדינאמיות רבה של ריבוי ומבנה סכמות במערכת עם קשרים מאד רופפים (אם בכלל) בין הסכמות השונות. במקרים רבים אחרים הדרישה היא פשוט לdurable store שמאפשר אכסון ואחזור מידע מהיר ללא כל צורך בתכונות כגון טרנזקציות או נורמליזציה של נתונים. במקרים כאלו כדאי לדעת שיש במדף הכלים עוד סט שלם של כלים שיכולים להתאים למשימה.

ולא פחות חשוב – כדאי להכיר את עולם המוצרים הנ"ל גם כדי לדעת לבחור בחוכמה מתי כן חשוב וחייבים להשתמש בבסיס נתונים רלציוני.