זהירות! נתונים גדולים!

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

קצת היסטוריה: בתחילת שנות ה-70, יבמ (IBMׁׂׂ) המציאה את מסדי הנתונים הרלציוניים ואת ה-SQL, שהפך מהר מאוד לתקן השולט בעולם זה. הוא יעיל, פשוט, קל ללימוד מקודמיו ולא דרש מהמשתמש יכולות פיתוח מיוחדות. עד שנות ה-80 התחילו לצאת לשוק כל אותם מסדי נתונים שאנחנו רגילים אליהם כיום (MsSQL, MySQL, Oracle, DB2 ואחרים). הגישה הייתה שהם אמורים לענות על כל צרכי הנתונים של הארגון. הדבר היה אמנם נכון: כיוון שכמות הנתונים באותם ימים לא הייתה גדולה, לא נדרשה זמינות מידית של ניתוח הנתונים והמבנה שלהם היה אחיד ובשליטת הארגון.

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

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

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

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

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

הפתרון ניתן על ידי גל חדש של מסדי נתונים שנבנו כך שהם מתמקדים בפתרון בעיה מסוימת, וכך יכולים להתגבר על הבעיה במקום להיות פתרון נתונים כולל לארגון. בנוסף, כמעט כל הפתרונות נוקטים בגישת MPP (ר"ת Multi parallel processing), כלומר 0- הנתונים מעובדים במספר שרתים במקביל.

איך עושים המוצרים החדשים הללו את הקסמים שלהם? הנה ה-"טריקים" שלהם לפתרון הבעיות השונות:

Velocity:
•    Sharding – חלוקת הנתונים למקטעים אשר נשמרים בשרתים שונים כך שכל שרת צריך לעבד רק חלק מהנתונים.
•    In memory- טעינת הנתונים מראש לזיכרון כך שהעבודה היא מול הזיכרון ולא מול הדיסק .
•    Memcache- מערכות חכמות ששומרות את הנתונים לצריכה מידית "חמים" בזיכרון.

Volume:
•    Sharding- במטרה לאפשר ביצוע של עיבוד מקבילי
•    Write once- אם טבלאות נכתבת פעם אחת ואין שינוי בנתונים אז נחסך כוח העיבוד המיועד לטיפול בטרנסקציות והוא יכול לשמש לעיבוד נתונים.
•    Column oriented- טבלאות שנשמרות כאשכולות של עמודאו מפתח, כך שבכל שאילתא ניתן לבחור להעלות רק עמודות מסוימות לזיכרון וכך להשתמש בנתונים שמיועדים לעבוד במקום בזיכרון שהיו תופסות העמודות האחרות

Variety:
•    NoSQL- שפות סקריפטים לתשאול נתונים. בדרך כלל הן מאפשרות תשאול של מידע לא מובנה.
•    ויתור של רלציוניות – שמירת הנתונים כקבצים במבנה חופשי (HDFS) או בטבלאות בעולת מבנה גמיש.

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

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