RDBMS או NoSQL – איך לבחור?
מאת: ג'נאן דאש, 17.8.14, 16:00
 
ההמלצה לחברות גדולות היא לבחון פתרונות מסד נתונים NoSQL כדי לענות לצרכיהן בעולם עסקי עתיר נתונים. האימוץ המהיר של מסדי נתונים חלופיים אלה בתוך מספר שנים בלבד הוא הוכחה לאטרקטיביות שלהם לעולם החדש של ביג דאטה, בו שולטים זריזות וגמישות, ביצועים וסקלאביליות.

השוק תוסס סביב מושגים כמו NoSQL, Big Data, Database Appliance וכו'. לעתים קרובות עלולים  מקבלי החלטות IT  להתבלבל מכל הרעש. הם אינם מבינים למה עליהם לשקול מסד נתונים חליפי, חדיש יותר, כאשר מסדי נתונים טבלאיים-רלציוניים (RDBMS) קיימים כבר עשרות שנים. עם זאת, ארגונים מובילים רבים כבר משתמשים במסדי נתונים חלופיים וחוסכים כסף, יוצרים מהר יותר חדשנות ומשלימים בעקבות כך פרויקטים, שלא יכלו לבצע קודם לכן.

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

לעומת זאת, נתונים מרחביים על חלקים הנדסיים או מודלים מולקולריים, נוטים להיות מורכבים מאוד. יכולות להיות להם רמות רבות של  nesting (שיבוץ אובייקט בתוך אובייקט אחר מאותו סוג), ומודל הנתונים המלא עלול להיות מסובך. בעבר הוזנו נתונים אלה לתוך טבלאות רלציוניות. אולם, אלה אינם מתאימים באופן טבעי למבנה שורה-טור דו-ממדי. במקרים כאלה יש לשקול מסדי נתונים NoSQL כאופציה.

 nesting מרובה-רמות והיררכיות מיוצג היטב במודל התכנות JSON.

השאלה הבאה, שיש לשאול, היא: "מהי התנודתיות של מודל הנתונים?" האם מודל  הנתונים צפוי להשתנות ולהתפתח או צפוי להישאר ללא שינוי.

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

הגישה של "לעשות את זה נכון מלכתחילה" אולי עבדה בעולם הישן של סכמה סטטית, אך לא תתאים לעולם החדש של סכמה דינמית, בו שינויים צריכים להתבצע מדי יום, אם לא מדי שעה, על מנת להתאים למודל הנתונים המשתנה בהתמדה. אין זה פלא, שמשתמשי NoSQL רבים הם עסקים ממוקדי-אינטרנט הדורשים רמה גדולה יותר של גמישות.
 
פיתוח יישומים (מהירות ואג'יליות של קידוד רב נתונים)
המשתמשים העיקריים במערכת ניהול מסדי נתונים(DBMS)  הם חברי קהילת מפתחי היישומים. בעבר, ניתקה התעשייה את מנהלן מסדי הנתונים (DBA) ממפתח היישום. העולם החדש מטשטש הבדלים כאלה ודורש תלות מועטה מאוד ב-DBA. מפתח התוכנה הופך למשתמש החשוב ביותר.

המפתח דורש מהירות קידוד גבוהה ואג'יליות (זריזות וגמישות) רבה בתהליך בניית היישום. מסדי נתוני NoSQL הוכחו כבחירה טובה יותר בהיבט זה, עם מודל נתונים של עצמים (אובייקטים) כמו JSON, לדוגמא.

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

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

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

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

אם עומדים בפני בעיות כאלה - כדאי לשקול טכנולוגיות NoSQL. זאת, מאחר שרבות מהן תוכננו במיוחד לטפל בבעיות התרחבות (גידול רוחבי או scale-out בשימוש בשרתי קומודיטי) ובעיות ביצועים. ממש כמו ארכיטקטורת הגידול הרוחביHDFS  של גוגל עבור מערכות מבוזרות בעיבודי batch, טכנולוגיות NoSQL חדישות יותר נבנו עבור מסד נתונים מבוזר למערכות מקוונות. יתירות (בשכפול משולש) מוטמעת כאן עבור זמינות גבוהה.

תלונה נפוצה על מסדי נתונים NoSQL היא, שהם זונחים קונסיסטנטיות לטובת זמינות גבוהה. עם זאת, הדבר אינו נכון לגבי כל מסדי נתונים NoSQL. כללית יש לשקול RDBMS אם יש טרנזקציות  מרובות שורות וצירופים (joins) מורכבים. במסד נתונים NoSQL כמו MongoDB, לדוגמא, מסמך (כלומר אובייקט מורכב) יכול להיות שווה הערך של טבלאות רבות, וקונסיסטנטיות מובטחת בתוך האובייקט. מסדי נתונים NoSQL נמנעים בדרך כלל מפונקציות RDBMS כמו צירופים מרובי טבלאות, שיכולים להיות הסיבה לשיהוי ממושך.

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

במקור שימשו DB2 ואורקל בעיקר עבור עומסי עבודה עתירי שאילתות. נתונים ממערכות פרודקשן נשאבים ומוסבים (תהליך ETL) ומוטענים ל-RDBMS עבור פילוח וניתוח.

אפילו בעולם של היום, נתוניHADOOP  מוטענים לעתים בחזרה ל-RDBMS עבור מטרות דיווח. כך, ש-RDBMS הוא בחירה טובה אם צרכי התשאול והדיווח הם קריטיים.

ניתוח אנליטי בזמן אמת עבור נתונים תפעוליים מתאים יותר במערך NoSQL. כמו כן, במקרים בהם נתונים מגיעים ממערכות מזרימות רבות לבניית יישום (לא רק דיווח), NoSQL הוא חובה. היום, תמיכת כלי BI  ב-NoSQL היא חדשה אך גדלה במהירות.
 
דו-קיום של מסדי נתונים RDBMS ו-NoSQL
יבמ הודיעה לאחרונה על ההטמעה של  API MongoDB – ייצוג נתונים, שפת שאילתות ופרוטוקול wire. בכך, היא יוצרת דרך לקישור יישומי מובייל ויישומים אחרים של הדור-הבא עם מערכת מסדי נתונים ארגוניים כמו DB2 של יבמ וגריד הנתונים WebSphere Extreme Scale שלה, מה שיכול להוביל לגל חדש של יישומים גמישים המוסיפים ערך משמעותי ע"י הקפת מערכת נתונים רבות. גם אורקל הציגה מוצר NoSQL בשנה שעברה.

חילופי נתונים ופעילות בין מערכתית ימשיכו להתפתח, כאשר מובילי תעשייה אחרים ילכו בעקבות יבמ והתפקודיות של מסדי נתונים NoSQL תמשיך להתפתח במהלך הזמן.

ההמלצה לחברות גדולות היא לבחון פתרונות מסד נתונים NoSQL כדי לענות לצרכיהן בעולם עסקי עתיר נתונים. האימוץ המהיר של מסדי נתונים חלופיים אלה בתוך מספר שנים בלבד הוא הוכחה לאטרקטיביות שלהם לעולם החדש של ביג דאטה, בו שולטים זריזות וגמישות, ביצועים וסקלאביליות.
 
מאת: ג'נאן דאש, אוגוסט 2014.
דאש הוא חוזה טכנולוגי ויועץ בכיר בעמק הסיליקון - ארה"ב. עבד 10 שנים באורקל והיה סגן נשיא קבוצת ארכיטקטורת וטכנולוגיית מערכות. לפני אורקל הוא עבד 16 שנים ביבמ בתפקידים שונים, כולל פיתוח משפחת מוצרי DB2, ואחראי על ארכיטקטורת וטכנולוגיית מסדי הנתונים של יבמ. הוא מכהן במספר מועצות מנהלים ומועצות מייעצות, כולל כיועץ ב- MongoDB.