sql, noSql and polyglot persistence

היום נשתמש בתכונה קטנה בגרסה החדשה של grails כדי להדגים כמה מגמות עדכניות בתחום בסיסי הנתונים.

אחת התכונות שמתחבאת בפרק persistence של תיעוד הגרסה החדשה של grails, היא היכולת להגדיר מספר מקורות מידע (data source) לסביבה מסוימת, ולאחר מכן לשייך מחלקות מתחם (domain classes) או אפילו פעולות מסוימות לאחד ממקורות המידע הזמינים. לכאורה זו נראית תכונה טכנית ואפילו איזוטרית. בואו נראה מה הקשר בין התכונה הזו לטרנדים העדכניים בטיפול בנתונים, ולמה היא חשובה.

הצדעה לDBA  האלמוני

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

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

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

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

שילוב פתרונות noSql באפליקציות

אחד הדברים החיוניים ביותר לאימוץ פתרונות של noSql היה הזמינות שלהם לסביבות הפיתוח הנפוצות דרך driver שחוסך את ההתעסקות בשכבות נמוכות, ומאפשר לעבוד מול בסיסי הנתונים הללו בצורה יותר אבסטרקטית. אבל הרמה הגבוהה של אתמול היא הרמה הנמוכה של היום – בעבודה מול בסיסי נתונים יחסיים ראינו איך ORM מאפשר לעבוד עם אובייקטים דרך מודל תכנותי עם פעולות כגון save, find ודואג לתרגום הפעולות האלה לפקודות בדיאלקט של בסיס הנתונים תוך שהוא חוסך את זה מהאפליקציה.

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

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

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s