איך יודעים שצריכים NoSQL?

כשהעיבוד במסד הנתונים היחסי נמשך יותר זמן מהאיסוף, הגיעה העת לעבור לטכנולוגיה של Big Data - על פי המשתתפים בדיון שנערך במסגרת אירוע Interop

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

במסגרת אירוע Enterprise Cloud Summit שנערך במסגרת ועידת Interop בלאס וגאס באמצע שנת 2011, התקיים דיון בנושא שבו השתתפו ג'רמי אדברג, מפתח מוצרים בכיר באתר החדשות החברתי Reddit.com (בו נותנים הגולשים ציונים לידיעות כדי לקדם אותן או להוריד אותן), וברדפורד סטיבנס, המייסד והמנכ"ל של Drawn to Scale, פירמת ייעוץ שמתמחה בתחום של Big Data.

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

סטיבנס סיפר כי הניסיון שצבר כמהנדס פלטפורמה ראשי בפירמת Visible Technologies, אשר מפיקה תובנות מאתרים של רשתות חברתיות, הוביל אותו למסקנות דומות לאלה של אדברג. הבעיה העיקרית היא שמסדי נתונים יחסיים פועלים בצורה היעילה ביותר כאשר הם שוכנים בשרת גדול אחד. מערכות יחסיות אינן מאפשרות להעביר מידע בקלות באשכולות של שרתים מבלי ליצור עכבות במסד הנתונים.
סטיבנס ניסה לפתור את הבעיה בשיטה המכונה Sharding - ביזור מערכי משנה של נתונים שפועלים כיחידות נפרדות ברחבי האשכול - אך גם שיטה זו "לא הניבה קצבי קריאה מספיק מהירים. כשתקציב החומרה גדל בקצב מעריכי, אתה יודע שיש לך בעיה של Big Data" אמר סטיבנס.

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

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

סטיבנס ואדברג התנסו בשימוש ב-HBase, מערכת NoSQL שמבוססת על הקוד הפתוח של Hadoop, וב-Cassandra, מערכת NoSQL נוספת בעלת קוד מקור פתוח, ולדבריהם, שתי המערכות מאפשרות לבצע הרחבות בקלות. על פי אדברג, הן מסדי נתונים של Oracle והן מערכות SQL מתקשים להתמודד עם "התרחבות" לשרתים מרובים.

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

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

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

רוצים לדעת עוד? הרשמו לכנס ה-BIG Date הראשון בישראל שייערך ב-6 למרץ 2012. האירוע מיועד למנהלי פיתוח של חברות ISV המייצאות לחו"ל ולמנהלי מחשוב של ארגונים גדולים בישראל.