Monitoring: מבוא ל Graphite ושימוש ב Time-Series

Graphite היא מערכת Open Source פופולארית למדי לניטור (Monitoring).
בצורה המקוצרת ביותר, היא מבצעת 2 פעולות בסיסיות:

  • אוספת מספרים שמשתנים לאורך זמן (להלן \"time-series\").
  • מציגה אותם כגרף.
המערכת מבוססת על עקרונות פשוטים למדי, ומסוגלת לטפל במליוני data points בשנייה.
Graphite זכתה לאימוץ נרחב בתעשייה, ככלי Monitoring חשוב. רבים משתמשים בה (ומספרים על זה): Github, Etsy, אובר, Electronic Arts, ועוד.

הקהילה הגדולה הרחיבה את Graphite עם מרחב של פונקציות סטטיסטיות בעזרתן ניתן להגדיר את הגרפים: החל מממוצע או median, דרך ניתוח אחוזונים או סטיית תקן, ועד אלגוריתמים לחיזוי מסוג Holt-Winters.

 מצד שני – צצו גם תלונות שונות על המערכת:

  • ניהול הנתונים כקבצים אינו יעיל כאשר מתשאלים הרבה מטריקות (metrics) במקביל. בהמשך נראה שזה מצב כמעט ובלתי נמנע…
  • ה UI הוא לא כ\"כ יפה…
  • יש פונקציונליות חסרה, למשל: aggregation של נתונים, alerts, וגילוי אנומליות…
  • ההתקנה של Graphite היא לא פשוטה (הרבה תלויות), והתפעול השוטף שלה – גם עשוי להיות לא כ\"כ פשוט.
מכיוון ש Graphite היא מערכת המורכבת ממודולים נפרדים עם APIs מוגדרים היטב – הצרכנים שהתלוננו פשוט החליפו חלקים שונים במערכת. בלי לשם לב, נוצרה אסופה גדולה של מודולים להחלפה, כאשר ה APIs שהגדירה Graphite  – הפכו לסוג של \"סטנדרט\" בתעשייה, אליו מתממשקים כלים רבים.

כיום כבר ניתן לראות הרבה תצורות בהן החליפו חלק מהרכיבים של ה \"Graphite Stack\", ואפילו תצורות ללא אף אחד מהרכיבים המקוריים. Graphite הוא עדיין אחד כלי ה Monitoring הנפוצים ביותר שקיימים.

אם אתם קוראים אדוקים של הבלוג, אתם בוודאי יודעים שאני מאוד אוהב כלי Monitoring בשם New Relic- בעבר כתבתי עליו פוסט.

מה הטעם להשתמש ב Graphite כאשר יש לנו כלי monitoring נהדר כמו New Relic?

  1. New Relic הוא כלי יקר [א], וייתכן שיש מערכות שלא משתלם לשלם עבורן את ה premium של New Relic.
  2. New Relic מגיש סט מאוד שימושי של מדדים וניתוחים, אבל לעתים אנו רוצים מדדים ש New Relic לא מספק.
    1. דוגמה קלאסית: מדדים עסקיים.
      בעולם של Gett: כמה הזמנות יש, כמה נהגים פנויים, כמה נוסעים שממתינים למונית כבר רבע שעה?
    2. ב New Relic קיימת פונקציונליות שדומה ל Graphite (עבור מערכות שמנוטרות ברישיון).
      New Relic מקשר את הנתונים בצורה קשיחה לאפליקציה, מה שעלול להקשות. אנחנו במקרה מסוים עזבנו אותו בנקודה זו לטובת Graphite, אם כי לא התאמצנו יותר מדי להשתמש בו. ייתכן ויש לזה פתרון.

Graphana – ה Dashboard ה\"חם\" בעולם ה Graphite כיום.

הארכיטקטורה של Graphite

בצורה פשטנית משהו, ניתן לתאר את הארכיטקטורה של Graphite בצורה הבאה:

  • ניתן לזהות ב Graphite שלושה רכיבי-על מרכזיים: whisper, carbon ו graphite-web.
  • המערכת (Application) שולחת נתונים של מטריקות (metrics) שונות ל carbon מעל tcp (פורט ברירת-מחדל: 2003).
    • הפורמט בו מועברים הנתונים הוא מאוד פשוט: some metric name : some value : timestamp.
  • קרבון שומר את הנתונים בבסיס הנתונים whisper, בסיס נתונים שמבוסס על קבצים ודומה לכלי ישן, יחסית, שנקרא RRD [ב].
    • whisper מנהל קובץ נפרד לכל מטריקה, הוא למעשה סוג של Time Series Database (פרטים בהמשך).
  • Graphite-web יודע לקבל קריאת GET (בעזרת endpoint בשם render/) כשהפרמטרים על ה URL מתארים query על מטריקה או מספר מטריקות.
    • למשל: הפרמטר הבא סוכם את כמות ה logins היומית:
target=summarize(my.metric.logins, \"1d\")
    • Graphite-web מרנדר PNG אותו הוא מגיש לדפדפן.
      הערה: זהו אלמנט של חוסר יעילות: היום קל יותר לקבל נתונים ולרנדר אותם ב javaScript – כך גם העבודה מתפזרת בין ה clients השונים.
Graphite כתובה ב Python, כאשר carbon ממומש ע\"ג twisted (שהוא framework ל event-driven I/O) ו graphite-web כתוב ב django – ספריית MVC מפורסמת שדומה באופייה ל Rails.

Time Series Databases (להלן TSDB)

בשלב זה, ולפני שאנו צוללים לתמונת-מבט עמוקה יותר על הארכיטקטורה של Graphite, כדאי להבין מהם time-series – מכיוון שהם נמצאים בבסיסה של הארכיטקטורה של Graphite.

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

  1. לדחוס את הנתונים בצורה יעילה יותר.
  2. איתור מגמות (trends), מחזורים (cyclical fluctuation), ועונתיות (seasonal fluctuation) בנתונים.
  3. לנתח חריגות בנתונים (אנומליות).
  4. לנסות לחזות את המשך הסדרה.
  5. להיות מסוגלים לחשב (בדיוק כזה או אחר) את ההסתברות להתנהגויות עתידיות של הסדרה. למשל: הסבירות לקטסטרופה עתידית.
סדרות עתיות הן טובות לתאר מדדים של מזג אוויר, ונתונים כלכליים – מצד אחד, אך גם metrics של סביבת הפרודקשיין שלנו, וביצועים של מדדים עסקיים – מצד שני. ישנן טכניקות מתמטיות משמעותיות לניתוח נתונים של סדרות עתיות.

מקור: Sabbir Rehman

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

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

  • ניצור טבלה לכל מדד (למשל: צריכת זכרון של שרת A, צריכת זכרון של שרת B, כמות פעולות IO של שרת A,… וכו\')
  • בכל טבלה יהיו שתי עמודות: זמן, וערך המדד.
כאשר יש לנו *הרבה* נתונים (מה שקורה לעתים קרובות ב Monitoring), ניתן לבצע אחת מ-2 אופטימיזציות מקובלות:
  1. ליצור טבלה לא רק לכל מדד, אלא גם לכל מדד וטווח זמן – למשל מדד + תאריך (יום מסוים). כל יום יהיה טבלה חדשה.
    1. אם הטבלה מייצגת תאריך – אז שדה הזמן יכול עתה להיות מצומצם לשעה ביום (ברזולוציה הנדרשת: שניות או מילי-שניות, למשל), וכך לחסוך מקום רב של אכסון, בעיקר באינדקסים.
    2. התוצאה כמובן יכולה להיות שבמערכת יהיו לנו מאות או אלפי טבלאות שונות.
    3. לרוב מקובל לשמור את הערכים לטווח מוגדר (נאמר: 30 יום), ולמחוק טבלאות ישנות יותר.
  2. לצמצם את מספר השורות ע\"י אכסון של טווח ערכים בכל שורה. למשל: יש לנו הרבה מדידות בשנייה (או בדקה), ואנו הופכים את הסכמה של כל שורה להיות: זמן, כמות דגימות, ממוצע דגימות, פיזור דגימות, ערך מקסימום, ערך מינימום ו BLOB עם כל ערכי הדגימות הספציפיים ומרכיב הזמן המתאים (שניה או מילי-שניה).
    1. אם עבור הרוב הגדול של השאילתות הרזולוציה אליה צמצמנו את הנתונים (נאמר: דקה) היא מספיק טובה, אז רוב השאילתות יוכלו לרוץ על סיכמוי הביניים (למשל: \"ממוצע דגימות\" ו \"כמות דגימות\") – מה שירוץ הרבה יותר מהר.
      1. צמצום שמצדיק את הטרחה הוא לרוב צמצום של כמה עשרות או מאות ערכים שונים או יותר – לתוך שורה בודדת.
      2. אם נרצה לגשת לכל הערכים המדויקים (כנראה שנרצה לעשות זאת ברזולוציה קטנה, למשל – כמה דקות) – כל הנתונים עדיים שם. לא יצרנו איבוד מידע.

דוגמה לדחיסה של נתוני סדרה עתית לרשומה / אובייקט יחיד. מקור: O\'Rielly, באדיבות MapR.

כמובן שבמקום לנהל את הסדרה העתית בעצמנו – ניתן לבחור בבסיס נתונים שזו ההתמחות שלהם (ועושים בערך מה שתיארנו למעלה). בסיסי הנתונים העתיים המדוברים ביותר כיום הם:

  • Splunk (מוצר proprietary)
    • משמש בעיקר לאינדוקס וניתוח נתונים (לא ממש monitoring), יותר נכון להשוות אותו ל ELK Stack מאשר ל Graphite Stack (למרות שהוא נחשב מוצר TSDB).
  • InfluxDB (כתוב ב Go, יכול לחבר אותו ל Storage Engines שונים כמו LevelDB או RockDB).
    • ניתן לאפיין אותו בפשטות התקנה / תפעול. הוא מתיימר להחליף את כל ה Graphite Stack בעתיד, ובנוסף הוא תומך במודל של time-events, שהוא רחב יותר ממודל ה time-series הקלאסי (מה שבא קצת על חשבון יעילות אכסון וביצועים). אולי שווה להקדיש לו פוסט בעתיד…
  • OpenTSDB (הממומש מעל Hadoop HBase)
    • ניתן לאפיין אותו ביכולת לטפל בכמויות גדולות מאוד של נתונים, ובמהירות. הוא מהיר בסדר גודל מ InfluxDB – כאשר כמות הנתונים גדולה מאוד.
TSDB כוללים לרוב עוד כמה פונקציות מסביב למודל של סדרות עתיות:

  • downsampling – היכולת לשלוף נתונים ביעילות ברזולוציה קטנה יותר מזו שנשמרה (למשל: אנו שומרים מדד כל שניה, אך רוצים לשלוף את הערכים של פעם בחמש דקות).
  • ביצוע פעולות השוואה / חישוב בין סדרות עתיות שונות, או מקטעים שונים באותה סדרה עתית. למשל: מה ההבדל בין התנהגות המדד היום, להתנהגותו באותו היום – לפני שבוע?
  • אינדוקס הערכים ושליפה מהירה שלהם. למשל: שלוף את כל מקטעי הזמן בחודש האחרון בהם ה CPU utilization היה גבוה מ 70% – בצורה יעילה (ובהנחה שזה אירוע דיי נדיר).

סה\"כ TSDBs כוללים tradeoff מאוד ברור: מודל נתונים פשוט ובסיסי של סדרות עתיות, עבורן ה TSDB יעיל בצורה לא-רגילה.

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

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

סיכום

בפוסט זה הכרנו את Graphite, כלי (או אולי Stack) טכנולוגיות פופולארי מאוד, בקוד פתוח – לניטור מערכות. הכח שלו – הוא ביכולת ה customization: ניתן להשתמש בו ל System Monitoring, ל Application Monitoring ואף ל Business Performance Monitoring. הבסיס שלו הוא דיי פשוט ויעיל – מה שתרם לפופולאריות הרבה שלו.

תמונת הארכיטקטורה שהצגתי היא פשטנית, ואנסה לכתוב פוסט המשך בו אסביר קצת יותר על Graphite, כיצד הוא עובד, ועם אילו בעיות / trade-offs יש להתמודד עם סוג כזה של מערכת.

בינתיים, אתם יכולים לגשת ל-2 הלינקים העוסקים בארכיטקטורה למטה – הם לא-רעים.

שיהיה בהצלחה!

—-

[א] ע\"פ מקורות זרים: כ 100$ לחודש לשרת. ע\"פ מקורות זרים: ניתן להוריד את המחיר הנ\"ל לבערך חצי – אם אתם צרכנים כבדים (יש לכם מאות שרתים מנוטרים). מה המחיר לאלפים? לרוב אם יש לכם יותר מכמה מאות שרתים – אתם לא תשלמו כבר ל NR, אלא תשתמשו ב open source כמו nagios עם הרחבות שלכם…

[ב] RRD הוא קיצור של Round Robin Database – על שם כך ששמר על קבצים בגודל קבוע בדיסק, ועשה שימוש חוזר בשטח שלהם.

—-

לינקים רלוונטיים

רשימת כלי 3rd-party שעובדים עם Graphite:
http://graphite.readthedocs.org/en/latest/tools.html

הארכיטקטורה של Graphite, כפי שמתוארת ע\"י היוצר שלה, כריס דיוויס:
http://aosabook.org/en/graphite.html
תיאור טוב ממקור אחר:
https://grey-boundary.io/the-architecture-of-clustering-graphite/

דרכים למימוש סדרות עתיות על גבי בסיס נתונים רלציוני:
https://academy.datastax.com/demos/getting-started-time-series-data-modeling
http://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql

ספר מבית O\'Reilly על TSDB, ו openTSDB בעיקר. ניתן לקבל בחינם במימון MapR (שמשקיעה ב OpenTSDB):
https://www.mapr.com/time-series-databases-new-ways-store-and-access-data

השוואה של 10 TSDBs:
https://blog.outlyer.com/top10-open-source-time-series-databases

Splunk vs. ELK
https://riskfocus.com/splunk-vs-elk-part-1-cost/ (והמשכים…)

מנוע מבני-נתונים: Redis

ישנן משימות תכנות פשוטות למדי. למשל:

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

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

כאשר הצרכנים של השירות נמצאים על מחשבים אחרים (פיסית) – יש לחשוף להם את השירות:

  • לחשוף גישה ברשת (למשל Java Servlet).
  • להגדיר פרוטוקול/פורמט (למשל מבוסס REST, שיהיה פשוט) כיצד מבצעים קריאה לשירות ואיזה תשובה מקבלים.
  • לדאוג לטיפול במקביליות / בעיות consistency של הנתונים.
כל אלו יכולים להפוך משימה של דקות – למשימה של כמה שעות, ולדרוש תחזוקה גדולה יותר לאורך הזמן.
אם נתבונן במערכות מבוזרות, ניתן לראות שפעמים רבות החלק הגדול של הקוד הוא קוד שרץ מקומית – עם נקודות סנכרון בין מספר שרתים / שירותים מרוחקים. נקודות הסנכרון הללו דורשות לא מעט עבודה (יחסית לקוד מקומי דומה).הסנכרון נעשה לרוב ע"י מבני נתונים או ע"י הודעות (שגם הודעות לרוב מנהלים בעזרת מבני נתונים).

Redis (קיצור מעט מוזר של REmote DIrectory Server) הוא "מנוע מבני-נתונים" המספק לנו שירות של מספר מבני נתונים עם גישה מרוחקת, אטומיות ואפשרות של שמירת מבני-הנתונים לדיסק (Persistence). ל Redis יש ספריות client המאפשרות גישה קלה למדי במגוון רחב מאוד של שפות תכנות.
אם אתם משתמשים בשפת נישה שאינה ברשימה (למשל שפת Boo), פרוטוקול הגישה ל Redis הוא פשוט מספיק על מנת לממש Client בקלות יחסית.

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

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

—-

התקנה (למי שמוכן "ללכלך" מעט את הידיים)

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

Redis תומכת רשמית ב OS X, Linux ו BSD Unix. מכיוון שאני עובד על "חלונות" אני משתמש בגרסה לא רשמית – אך טובה מספיק עבור פיתוח: https://github.com/MSOpenTech/redis.

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

הנה הסבר כיצד להתקין את Redis על "חלונות" במהירות:

קולאג' הפעולות להתקנה מהירה של רדיס על "חלונות"
  1. הורידו את קובץ ה ZIP של כל ה Repository מתוך github (כפתור ה download הוא בפאנל הימני).
  2. פתחו את קובץ ה ZIP שירד.
  3. בתוך ה ZIP, עברו לתת-התיקיה redis-2.6/bin/release.
  4. פתחו את הקובץ redisbin64.zip (מכונות 64 ביט) או הקובץ השני (32 ביט) ו"שפכו" את תוכנו לאיזו תיקיה.
  5. הפעילו את השרת של redis.
  6. הפעילו את הלקוח CLI של redis.

—-

ניסיון ראשון עם רדיס

Redis בנוי כ Dictionary (כלומר "Hash Table") ענק של צמדי .

מנקודת מבט מסוימת ניתן לומר שזהו בסיס נתונים NoSql-י, מסוג Key/Value (בעצם Key/Data Structure) שפועל In-Memory. מנקודת מבט זו Redis הוא מהיר בצורה קיצונית[א] וקצת חריג בנוף של NoSQL Databases.

בדוגמה למעלה פתחתי 2 clients של Redis ובצעתי בהם מספר פעולות על מבנה הנתונים הפשוט ביותר: String.

  1. הכנסתי ערך של "!hello world" למפתח "messages:hello". הסימן ":" הוא קונבנציה מקובלת ל namespacing של ערכים, בדומה ל סימן "." לסימון packages בג'אווה.
  2. קראתי את הערך – ערך ההחזרה מוצג בשורה הבאה.
  3. ניסיתי לקרוא מפתח שלא הושם בו ערך – וקיבלתי nil.
  4. קראתי את הערך מה client השני – והערך זמין לו.
    אם זה לא היה קורה –  לא היה הרבה טעם ב Redis, כאשר אני מקבל את זה בקלות בג'אווה : )

את הפקודות, אגב, אני מקליד ב Capital letters לצורך ההדגשה, הפרוטוקול של redis מקבל אותן בכל case.
המפתחות הם (כמובן) Case Sensitive.

Lists

בואו נעבור למבנה נתונים מעט יותר מורכב: List.
המקביל בג'אווה (עולם מוכר?) ל List של Redis הוא <LinkedList<String, בערך. מדובר ברשימה משורשת עם השלכות הסיבוכיות הידועות (זול להכניס, יקר לחפש). היא מנהלת רק מחרוזות. בתיעוד של Redis מצוינת על כל פקודה הסיבוכיות שלה, למשל (O(n + הסבר מהו n.

במה List שונה מ <LinkedList<String של ה JDK? הנה 2 דוגמאות:

  • המימוש מעט שונה. למשל פקודת LINDEX (האות L עבור List) סורקת את הרשימה משני הכיוונים: פעם מימין, ופעם משמאל – מה שאומר שאם האיבר שאנו מחפשים הוא האחרון ברשימה – ניתן לצפות לזמן של (O(1.
  • בג'אווה יש רשימה "מסונכרנת" או רשימה "לא מסונכרנת". ב Redis זו אותה רשימה כאשר יש פעולת שליפה "מסונכרנת" או "לא מסונכרנת". הגישה של Redis היא מאוד לא-דפנסיבית (כמו ג'אווה), אלא יותר כמו של Unix ("אתה אחראי למה שאתה עושה").

בואו נשחק מעט עם List:

  1. גיא יוצר רשימה בשם guyList. הדרך ליצור רשימה ברדיס – היא פשוט להתחיל ולהכניס לה ערכים, במקרה זה: בעזרת פקודת LPUSH = "דחוף לרשימה" וגם "דחוף משמאל".
    ניתן לראות את ערך ההחזרה – 3, 3 ערכים נוספו לרשימה.
  2. עכשיו נדחוף ערך אחד מימין בעזרת RPUSH.
  3. LLEN בודק את אורך הרשימה. כצפוי: הוא 4.
  4. ניתן לקבל טווח של ערכים ברשימה ע"פ האינדקס שלהם, במקרה הזה – כל הרשימה שלנו.עכשיו נוסיף לסיטואציה את בן, שמעביר פריטים מהרשימה של גיא לרשימה משלו.
    הכוונה שלי היא לייצר מעט "דרמה", והיא לא לעסוק בנושאי אבטחה. מבחינת אבטחה: יש לנהל ניהול גישה (authentication) בצורה אפליקטיבית על שרת האפליקציה (ג'אווה, Haskell, רובי, Whatever) [ב].
  5. בן בוחר דווקא להשתמש בפקודות רדיס ב lower case – מותר.
    מכיוון שהוא הולך לבצע פקודה הנוגעת ל2 מבני נתונים שונים (כל פקודות רדיס אטומיות כל עוד מדובר במבנה נתונים אחד) – עליו לשמור על consistency והוא עושה זאת ע"י הפעלת transaction – פקודת multi, ומקבל אישור.
  6. הוא מסיר מצד ימין (rpop) את האבר האחרון ברשימה של גיא.
  7. הוא "דוחף" את ערך האיבר ("itemD") לרשימה חדשה משלו. ניתן לציין את הערכים עם או בלי מירכאות. מכיוון שאלו מחרוזות – התוצאה תהיה זהה.
  8. בעזרת exec בן מנסה לבצע "commit" לטרנזקציה – והוא מצליח.
  9. בעצם, מכיוון שתהליך העברת ערכים בין רשימות הוא נפוץ ברדיס, יש פקודה מקוצרת שעושה את 2 הפעולות הנ"ל בצורה אטומית (כלומר: לא צריך להפעיל טרנזקציה). הפקודה נקראת… (מפתיע!): rpoplpush ומקבלת את המקור והיעד. הערך שעכשיו יעבור הוא "itemA". ייתרון נוסף בפקודה ישירה הוא ביצוע roundtrip יחיד ברשת – ולא ארבעה.
    האם יש גם פקודת lpoprpush או lpoplpush ברדיס? בכן… לא. רדיס שומר על פשטות, לעתים במחיר הקלות למשתמש: לעתים צריך מעט יצירתיות בכדי למצוא את הדרך עם הפקודות המובנות של רדיס (או שאפשר להרחיב את הקיים בעזרת LUA – על כך בהמשך). זה, לטעמי, מעט חסרון של רדיס – והייתי שמח שתצוץ ספריית הרחבה (למי שמעוניין) שמשכללת את סט הפקודות שרדיס מכיר.
  10. אנו בוחנים את הרשימות ורואים את התוצאה הסופית.

מבני נתונים נוספים

Redis תומך בחמישה טיפוסים:

  • String (עד 512MB) – יכול להכיל כל אובייקט מקודד למחרוזת (json, תמונה וכו'). מכיוון של Redis אין indexing – אין טעם "לפרק" אובייקטים מורכב לחלקים קטנים יותר. אני מניח שניתן ליישם אינדוקס חיצוני – אם צריכים.
    ניתן לאכסן ב strings גם ערכים מספריים ולבצע עליהם פעולות אטומיות כגון INC (קיצור של increase – כמו בשפת פאסקל), INCBY ו INCBYFLOAT.
  • List שהוא בעצם <LinkedList<String, עליו דיברנו למעלה. ל List יש גם פעולות blocking שאם יבוצעו על רשימה ריקה "יתקעו" את ה client עד שיהיה ערך מסוים או שיעבור timeout שהוגדר בפעולה.
  • Sets שהוא בעצם <Set<String (כל איבר יכול להופיע פעם אחד בלבד). מאפשר לעשות פעולות יעילות על קבוצות כגון Union או intersection. פקודות של Set מתחילות באות "S".
  • SortedSet שהוא בעצם <SortedSet<String ומחזיק את הרשימה באופן ממוין-תמידית, מה שמאפשר לבצע פעולת Range (שליפה של טווח של איברים) בצורה יעילה. לכל ערך ב SortedSet יש ערך מספרי (score) וערך מחרוזת (value). הערך המספרי קובע את הסדר. על מבני נתונים אלו ניתן גם לעשות פעולות על קבוצות (כמו union) ואפילו לבצע פעולות חישוביות על ה scores (פקודת ZUIONSTORE). פקודות של SortedSets מתחילות באות "Z".
  • Hash – שהוא בעצם <Map<String (או <Dictionary<String למי שבא מ #C). כלומר: value של ה K/V store שלנו הוא K/V בעצמו. לא ניתן לקנן Hash מעבר לרמה אחת. פקודות של Hash מתחילות באות "H".

בעיות נפוצות לדוגמה שנפתרות בעזרת Redis:

  1. Cache מבוזר, המשותף לכמה שרתים. שיתוף זה מאפשר ששרת אחד יחדש את ה cache – וכל השאר יהנו מחידוש זה.
  2. ניהול State אשר מצד אחד הוא בזיכרון (כמו server session state) ומצד שני הוא משותף (כמו db session state) כך שאם המשתמש אינו יכול לחזור ל node האחרון שטיפל בו, ה node החדש יכול לגשת ל session של המשתמש ולא לרסט אותו. אם הנושא לא מוכר – ניתן ללמוד עליו מהספר של מרטין פאוולר שבקישורים.
  3. Pub/Sub – מערכת הודעות בין כמה שרתים.
  4. Job Queue לחלוקת עבודה במערכת מבוזרת.
  5. ספירה וניהול מבוזר של counters.
  6. פתרון בעיות של מערכות מבוזרות כגון Leader Election, בעיות הצבעה ובעיות שעון / סנכרון זמנים. ניתן למצוא בלינק הבא כמה רמזים / המלצות למימוש.

לבעיית ה Pub/Sub החליטו להציע פתרון מובנה – הנוח מאוד לשימוש.
לבעיות ה Cache ישנן פקודות כמו EXPIRE (מחיקת ערך לאחר זמן נקוב), TTL (לבדוק כמה זמן קצוב נותר לאיבר) או PERSIST (ביטול הקצבת הזמן).
לבעיית ה counting יש את משפחת פקודות ה INC.
וכו'

דוגמה לשימוש ב Redis בעזרת client (או driver) לג'אווה הנקרא Jedis

יכולות אחרות

ל Redis יש עוד כמה יכולות משמעותיות שכדאי להכיר:

Persistency
היכולת לשמור את מבני הנתונים לדיסק.
ברדיס יש שני מנגנוני שמירה:

  • RDB (קיצור של Redis Database) – שמירת כל מבני הנתונים בזיכרון ביחד לדיסק, ע"פ מדיניות קבועה / פעולה יזומה של המשתמש.
  • AOF (קיצור של Append Only File) – שמירת פעולות אחרונות ל Log file לצורך התאוששות במקרה של קריסה.
כדאי לציין זאת עכשיו: Redis הוא לא פתרון בסטנדרט גבוה של durability בשמירה לדיסק. אם אתם שומרים (בקיצוניות) מידע פיננסי – השתמשו במנגנון אחר בכדי לשמור אותו, לא ברדיס. ניתן להגיע עם רדיס לאמינות לא-רעה שמתאימה לשימושים רבים.
AOF ניתן להפעיל אותו עבור כל שינוי של מפתח (פגיעה קשה בביצועים) או כל שנייה (tradeoff סביר בין אמינות וביצועים – ברירת המחדל). ניתן גם לכבות יכולת זו בכלל או להשאיר את ה flushing למדיניות של מערכת ההפעלה, שזה סוג של כתיבה מדי זמן-מה.
RDB ניתן להפעלה ע"י פקודות (SAVE או BGSAVE) או קונפיגורציה. קונפיגורציה נעשית בקובץ redis.conf, בואו נתבונן ב section המתאים:
ברירת המחדל היא סבירה למדי:
  • שמירה לאחר 15 דקות לאחר שינוי של מפתח כלשהו.
  • שמירה לאחר 5 דקות אם השתנו 10 מפתחות או יותר.
  • שמירה לאחר דקה אם השתנו 10,000 מפתחות.
אם המערכת שלכם עובדת בעומסים נמוכים – ניתן לצמצם, נאמר, לשמירה לאחר דקה לאחר שינוי כלשהו (קרי save 60 1).
ניתן לקרוא עוד בנושא בתיעוד הרשמי של רדיס.

Transactions
כפי שהראנו למעלה בעזרת פקודות כמו MULTI ו EXEC ניתן לייצר טרנזקציות בצורה פשוטה.
ניתן לקרוא עוד בנושא בתיעוד הרשמי של רדיס.

Scripts
ניתן לכתוב בשפת LUA סקריפטים המבצעים סדרת פקודות – וכך להרחיב את סט הפקודות הזמין. הסקריפטים יכולים להישלח בכל קריאה (הפעלה של פקודת EVAL) או להישמר בקובץ ה redis.conf.
יתרונות ה Scripts דומים למחשבה על Stored Procedure ב Database – אנו חוסכים את ה latency בין קריאה לקריאה ובפקודה אחת ניתן לבצע את סט הפקודות ישירות ב DB (במקרה שלנו: Redis).

ניתן לקרוא עוד על סקריפטים בתיעוד של רדיס.

Clustering
Redis הוא כמעט-single-threaded. כל הפקודות יבוצעו ע"י thread יחיד ורק פעולות של שמירה לדיסק עשויות להיעשות ב thread נפרד. משמעות אחת היא שאם יש לכם שרת עם שמונה cores – יש להפעיל 8 תהליכים שונים של redis (ב multiplexing) על מנת לנצל את כח החישוב של המכונה כראוי.
שכפול מנועים הוא תסריט אפשרי לניהול cache – אבל בעייתי לכמעט כל תסריט אחר. לצורך כך יש ברדיס מנגנון של Partitioning ויש גם מנגנון של master/slave cluster.

מנגנונים אלו דורשים התעמקות על מנת להבין אותם היטב ולהגיע בעזרתם לביצועים מיטביים.

סיכום

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

כשתהיה לכם בעיה שכרוכה במספר מחשבים ("מבוזרת") – חשבו על Redis.

שיהיה בהצלחה!

לינקים מעניינים

הארכיטקטורה של רדיס: http://www.enjoythearchitecture.com/redis-architecture ו http://pauladamsmith.com/articles/redis-under-the-hood.html

תבניות שימוש ברדיס: http://www.slideshare.net/dvirsky/kicking-ass-with-redis

רדיס בטוויטר: http://bit.ly/1pm7PsV

עוד פרטים על ה Persistency של רדיס: http://oldblog.antirez.com/post/redis-persistence-demystified.html

redsmin – כלי monitoring לרדיס: https://redsmin.com

[א] נו – הכל רץ בזיכרון. זה לא רציני לזרוק סתם כך מספרים ללא Use-case מדויק וחומרה עליה הבדיקה רצה, אבל בהערת צד אפשר לספר שמדברים על מספרים כגון "100,000tps" – מספר שמשאיר באבק כל "בסיס נתונים" אחר, בערך.
tps = transactions per seconds שאילתות בשנייה. ברור שקל יותר לשלוף ערך מתא בזיכרון מלבצע join על מידע ששמור על הדיסק.

[ב] יותר ספציפית, כן יכול להיות מצב שבו מישהו חדר ל Data Center – ואז רדיס הוא "פרוץ" לגישה. לרדיס יש אפשרות לבצע אימות גישה (Authentication) על בסיס ססמה שנקבעה מראש – לא פרדיגמה קשיחה במיוחד, אלא כזו שתחסום את התוקף המזדמן. כאשר זקוקים ליותר הגנה – מתקינים לרוב Firewall מקומי על השרת של רדיס שיאפשר תקשורת נכנסת רק מכתובות ה IP של שרתי האפליקציה. אם שרתי האפליקציה נפרצו… לא ברור עם הגנה קשיחה יותר על רדיס תעזור.

מה הביג-דיל ב 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 יקרוס אחרי כמה עשרות דקות.