מה הביג-דיל ב Big Data? (או NoSQL)

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

פעם (לפני כעשור), מערכות ה High Scale היו בעיקר מערכות ה Enterprise המיועדות לארגונים גדולים. לחברת Siemens יש 120,000 משתמשים (users)? וואהו - אתגר ארכיטקטוני מרשים. מערכת המסחר של וול סטריט מבצעת מאות פעולות (transactions) בשנייה אחת? - בלתי נתפס!
חברות ענק כמו SAP, Oracle ו IBM הן אלו שבד"כ התמודדו עם אותם scales , בעיקר בזכות העובדה שאותם לקוחות-ענק קנו מערכות מורכבות שיצרנים אלו סיפקו. יצרן קטן - scale קטן, יצרן גדול - scale גדול.

מאז שנת 2000 האינטרנט פרץ למיינסטרים. מוצרים כמו MySpace ו SecondLife ואח"כ Facebook ו Youtube עקפו בסיבוב את חברות הענק וטיפלו במיליוני משתמשים, petabytes של שטחי אחסון ואלפי (tps (transactions per second. בהדרגה, עוד ועוד חברות קטנות נאלצו להתמודד עם scales אדירים. הכלים להתמודד עם כמויות גדולות של נתונים (כמו פתרונות של Teradata וOracle) גם היו יקרים מדי עבור אותן חברות קטנות, וגם לעתים לא עמדו בקיבולת המבוקשת - וכך אותם ארגונים החלו לייצר חלופות זולות ויעילות להתמודדות עם scale ענק. לא סתם Facebook, Amazon או Twitter שרדו מבין חברות דומות (שלעולם לא שמענו או נשמע עליהן). מלבד הרעיון המגניב, היה צריך להתמודד עם אתגרים טכנולוגיים יוצאי-דופן. רעיון מגניב + ניהול נכון + מצוינות טכנולוגית הוא שילוב נדיר אשר היה דרוש להצלחה.
בסולם ה Scale הוגדר ערך חדש הגבוה מהערך הגבוה הקודם ("High Scale"). מעתה, אמרו "Internet Scale".

הבעיות
הערה:כמו שצוין למעלה, ב Big Data יש עניין מוצהר - טיפול בכמויות אדירות של נתונים, ועניין לא מוצהר, אך לא פחות חשוב - פתרון זול המתאים גם לחברות קטנות. עדיף Open Source, עדיף מאוד Commodity Hardware (שרתים במחיר של, נאמר, עד 10K$ כל אחד)

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

הגדילה בתעבורה של אתר Netflix כמו שדווח על ידם

כאשר יש לכם כמויות גדולות של נתונים, אתם צריכים:

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

למרות ש MySql (או כל בסיס נתונים רלציוני) הוא מוצלח, ישנו גבול של נתונים שהוא יכול לטפל בו. הגדילה הראשונה היא כנראה לקנות שרת יותר חזק (vertical scalability הקרוי גם scale-up). השרת יטפל בפי n כמויות מידע ויעלה לרוב משמעותית יותר מפי-n.
השלב הבא, ברוב בסיסי הנתונים, הוא ליצור cluster של בסיסי נתונים (horizontal scalability הקרוי גם scale-out), בחוות שרתים שלכם או ב Cloud.
איך מטפלים בכפילות מידע? דרך אחת היא ששרת אחד מוגדר לכתיבה בלבד (ומעדכן את השאר) ושאר השרתים רק מבצעים שאילתות קריאה ומשחררים עומס מהכותב. כמו שאתם מבינים זהו בסה"כ קצת אוויר לנשימה.
Partitioning של המידע: לאחסן על כל בסיס נתונים (או cluster כמתואר למעלה) פלח מידע שונה, לדוגמה: פילוח ע"פ מדינות, אות ראשונה בשם המשתמש וכו"
offloading to data warehouse - מדי כמה זמן להעביר את המידע שאליו ניגשים פחות (לרוב מידע ישן) לבסיס נתונים אחר ("מחסן") כדי לגרום לבסיס הנתונים עליו המידע החשוב להיות זמין יותר.

בשיטת ה Partitioning יש שתי בעיות עקרוניות:
א. אם מפצלים נתונים לשרתים שונים, יש להתפשר או על זמינות (availability) או על עקביות הנתונים (consistency) - עקרון הידוע כ CAP Theorem (כלומר - ללא ACID).
ב. שאילתות הכוללות מספר בסיסי נתונים אחד הן מורכבות למימוש ואיטיות במיוחד (במיוחד אם דורשות נעילות). למרות שלספקי בסיסי הנתונים היו שנים רבות ללא תחרות קשה בתחום - הם לא פיתחו את התחום בצורה משמעותית.

Big Data
אותן חברות סטארט-אפ שלא יכלו לשלם על פתרונות יקרים ונזקקו לכלים לטפל בכמויות אדירות של נתונים פיתחו כמה מהפלטפורמות הבאות שרובן הגדול זמין כיום כ Open Source (מסודר ע"פ תחום):

• CPU - לרוב אין צורך בפתרון מיוחד. מקימים Cluster עם שרתים זהים ובעזרת Load Balancer מחלקים לכל אחד מנה מהתעבורה. פתרון שקיים כבר שנים.
• אחסון פיזי: S3 של אמזון, GFS של גוגל או HDFS* של אפאצ'י (היחידי שזמין לקהל הרחב).
• אחסון לוגי: אלו בסיסי הנתונים המפורסמים (הסבר בהמשך) השייכים לאחת מארבע קטגוריות:
• Document Oriented
• Columnar DB
• Graph Database
• Key-Value DB
• יכולת לבצע שאילתות מבוזרות: Hive, Hadoop Map-Reduce, Cascading, MrJob ועוד.

בסיסי נתונים NoSQL

פירוש השם NoSql התחיל כ "לא צריך SQL", אולם עם הזמן התפכחו הדוברים והבינו שאין כאן Silver Bulltet - לרוב המקרים בסיס נתונים רלציוני עדיין מתאים. היום ההסבר השגור לשם הוא: "Not Only SQL". 

הרעיון פשוט למדי: בסיסי הנתונים הרלציונים הם עשירים ומורכבים: הם מאפשרים שאילתות SQL מורכבות (שאילתות מקוננות, סיכומים סטטיסטים ועוד), הבטחת פעולות ACID**, אכיפה של constraints, טריגרים ו Stored Procedures ועוד. מה היה קורה אם היינו מוותרים על רוב היכולות ומתמקדים רק במערכת היכולה לטפל ב Scale מרבי למקרה הספציפי? 

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

Document Oriented DB

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

אם נלך לפי העיקרון האקדמי של בסיס נתונים רלציוני ומנורמל תהיה לנו כנראה טבלת סניפים (נאמר 20) המקושרת לטבלת עסקאות (נאמר מיליון בשנה, עשר שנים = 10 מיליון), המקושרת לטבלת פריטים בעסקה (Line Item), נאמר 20 בממוצע בעסקה.

טבלת הפריטים של כל המערכת תהיה בגודל של 4 מיליארד רשומות. כלל האצבע בבסיסי נתונים הוא שמעל 10 מיליון רשומות בטבלה - בסיס הנתונים מתחיל להגיב לאט. כלומר-  לא מעשי. בנוסף הכנסה מקבילית של הרבה קופאיות לאותן טבלאות (מקושרות) ייצור רצף נעילות שיגביל מאוד את המערכת (עוד קצת על מקביליות ונעילות - בתחתית הפוסט) מצד שני אנחנו יכולים לקחת את ההנחות המקלות:

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

פיתרון קיים (יצא לי פעם להתנסות בו) הוא במקום טבלת הפריטים - לייצר בטבלת העסקאות עמודה מסוג "string" המכילה XML או JSON עם פרטי העסקה. זהו שיפור משמעותי ב scale, מכיוון שיש לנו פחות rows, פחות אינדקסים לתחזק ופחות joins להריץ. מצד שני יש יותר custom code שצריך לכתוב - עבור דברים שהיינו מקבלים קודם בשאילתה. יתרונות אחרים של גישת ה Document Oriented DB הן שניתן לשנות את הסכמה מבלי לבצע Alter table יקר ואם ישנן עמודות דלילות ב DB - לא נבזבז עליהן מקום מיותר (מה שנקרא Semi-structured data).

בסיסי נתונים Document Oriented נותנים פיתרון מובנה לעקרון זה שכולל לרוב API פשוט לשימוש וכלי שאילתות מבוזר נוסח Map-Reduce. דוגמאות הן MongoDB ו CouchDB. במקום להמציא את הגלגל - קחו Open Source.

Columnar DB

קטגוריה זו, הידועה גם כ Vertical DB פותרת בעיקר בעיות של Data Warehousing: איך לבצע שאילתות יעילות על מחסני נתונים. דמיינו טבלת ענק עם 10 עמודות בגודל x בתים (bytes) כל אחת.
לרוב בשליפות ה SQL אנו שולפים עמודות בודדות. אם הרצתי שאילתה על 3 עמודות, בסיס הנתונים עדיין צריך לקרוא מהדיסק לזיכרון את כל עשרת העמודות - כלומר פי 3 מידע ממה שנדרש. הקריאה מהדיסק היא הפעולה היקרה. אם הייתי מאחסן כל עמודה בקובץ נפרד בדיסק, אולי הייתי מוגבל בשאילתות מורכבות מאוד, אולם השאילתות הפשוטות היו דורשות משמעותית פחות עבודה של הדיסק.
במחסני נתונים, לעתים קרובות, רוצים לבצע חישוב ממוצע / התפלגות ערכים / whatever על עמודה בודדת (ומספרית) מתוך טבלה הכוללת הרבה עמודות שחלקן הגדול הוא מחרוזות (התופסות נפח גדול בהרבה). היכולת לטעון מהדיסק עמודה בודדת יכולה להאיץ את ביצוע השאילתה בעשרות מונים.

דוגמאות בולטות הן Vertica או InfoBright. חברת SAP זכתה לתשואות כאשר באופן מפתיע הצטרפה לחגיגה עם HANA - גרסה In-Memory של בסיס נתונים columnar. כולם פתרונות שאינם open source.

Graph DB

בסיסי נתונים רלציונים הם גרועים במיוחד בתיאור גרפים. נניח שהייתם מפתחים אפליקציה כמו LinkedIn והייתם רוצים לדעת מה הקשר בין שני אנשים, מתוך מאגר של 100 מיליון משתמשים.
ישנו כלל מקל האומר שכל שני אנשים מקושרים ע"י שרשרת של 6 הכרויות. מה נעשה? Join משושה של 100 מיליון משתמשים?? קחו טיול חצי שנה לדרום אמריקה לפני שהשאילתה תסתיים***.

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

Key-Value DB

האם הייתם רוצים להשתמש ב HashTable בגודל של מיליארדי רשומות - שגם יאפשר מקביליות גבוהה? כמה נוח. Key-Value DB יספקו זאת, רק אל תבנו על (O(1 בזיכרון. זוהי פרדיגמה פופולרית במיוחד בקרב חברות אינטרנט:

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

פרויקט Hadoop מימש את התכנון של גוגל ויצר את HBase ו LinkedIn מימשו את התכנון של אמזון ויצרו את Voldemort (כן, הנבל מהארי פוטר).

פייסבוק ערבבה רעיונות של גוגל ואמזון ויצרה את Cassandra שזוכה להצלחה רבה. יש גם את Redis שהוא In-Memory Database המבוסס על אותה פרדיגמה.

סיכום

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

עדכון 1: תודה ליקיר שהזכיר את RavenDB, בסיס נתונים Document Oriented עבור פלטפורמת .NET שפותח בארץ ע"י אורן עיני - מפתח ישראלי בולט.

עדכון 2: ripper234 העיר ובצדק (בפרסום ב newsgeek): "מה שהייתי שם בפתיחה למאמר כזה שאסור להתאהב בטכנולוגיות וב-"Big data". פגשתי יותר מדי אנשים שהחלום הרטוב שלהם זה Big Data / NoSql / Technology Buzzwords, אבל שוכחים בדרך את האג'יליות ואת העבודה שבסטארט-אפ עובדים בשביל ליצור value אמיתי, כמה שיותר מהר, ולא מערכת מטורפת שתחזיק 100 מיליון יוזרים 5 שנים קדימה אבל תיקח שנתיים לפתח."

במאמר זה ניסיתי להתמקד בטעות נפוצה אחרת: המחשבה ש Big Data הוא Silver Bullet, שהוספת בסיס נתונים NoSQL תפתור תכנון בסיסי לקוי. ניסיתי להציג את אותם בסיסי נתונים ולהסביר "מה הטריק שלהם", כי לפעמים בצורה מאוד נקודתית ניתן לממש את הטריק הזה לבד ללא מעבר full-fledged לבסיס נתונים שכזה.

* Hadoop Distributed File System השייך לפרויקט העל Hadoop. השם Hadoop הוא שמו של פיל-הצעצוע האהוב של בנו הקטן של מפתח הפרויקט - ומכאן לוגו הפילון.

**  ACID - Atomic, Consistent, Isolated and Durable הרי הן ה transactions.

*** סתם. ה DB יקרוס אחרי כמה עשרות דקות.