הלו מונגו! [MongoDB מדריך למתחילים]

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

מקור: MongoDB

מקור: MongoDB

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

לא, אני לא מדבר על מה שקרה (וקורה, בעת כתיבת הפוסט) באוקראינה. גם לא על נתח השוק שמאבדת מיקרוסופט בהתמדה, או על החדירה של אינטל ל-high end האמיתי של החומרה. דווקא החברה שמפנה במקרה זה את מקומה היא לא אחרת מאשר הענק הכחול – IBM, והיא עשויה לא-להיות האחרונה.

בסיס נתונים לא-רלציוני, בשם MongoDB תפס את המקום החמישי הנחשק במדד הפופולריות של DB-Engine, ובעצם הפך לבסיס הנתונים הלא-רציונלי הראשון שנכנס לחמישייה הפותחת [א].

מקור: ליאור בר-און

מקור: ליאור בר-און

יש היגיון מסוים בכך שדווקא MongoDB הוא הראשון מבין בסיסי הנתונים מסוג NoSQL לפרוץ לרשימת בסיסי הנתונים הרלציוניים: מבחינות מסוימות הוא קצת יותר דומה להם: יש לו (יחסית ל-NoSQL DB) עושר רב של יכולות, וותק, וזמינות של תמיכה מסודרת (לאחרונה גם בישראל) – הכוללת “גרסאות Enterprise”.

האופן בו אנשי מונגו אוהבים להציג את בסיס הנתונים: מעט פחות יכולות והרבה יותר Scalability מ-RDBMS + הרבה-הרבה יותר יכולות מבסיסי נתונים NoSQL אחרים. מקור: ליאור בר-און

האופן בו אנשי מונגו אוהבים להציג את בסיס הנתונים: מעט פחות יכולות והרבה יותר Scalability מ-RDBMS + הרבה-הרבה יותר יכולות מבסיסי נתונים NoSQL אחרים. מקור: ליאור בר-און

מה זה אומר?

מקור השם של מונגו הוא מהמילה humongous (גדול, אדיר), אולם היכולת לטפל בכמויות גדולות של Data היא כנראה לא התכונה הבולטת, המושכת אליו כ”כ הרבה מפתחים. בעולם ה-Internet Scale דווקא אני שומע קולות שמחשיבים את Mongo כבסיס נתונים בעל יכולות Scale מתונות.

הפופולריות של MongoDB (בקיצור: “מונגו”) נובעת מהקלות שהוא מספק למפתחים בעזרת הסכֶמה (db schema) הגמישה שלו. לא עוד Migrations, או יותר גרוע: תקלות migration על סביבת production (המוכרות כנראה היטב לכל מי שעבד עם SQL בסביבת ה-Enterprise).

מונגו הופך להיות מועמד לקחת את מקומו של MySQL כבסיס נתונים זול ויעיל ל”משימות רגילות” – ויש הרבה מאוד כאלו.

סקר המראה מה מושך מפתחים ב NoSQL: לא, זהו לא ה Scale במקום הראשון - אלא דווקא הגמישות. מקור: ליאור בר-און, דרך Gigaom

סקר המראה מה מושך מפתחים ב NoSQL: לא, זהו לא ה Scale במקום הראשון – אלא דווקא הגמישות. מקור: ליאור בר-און, דרך Gigaom

בפוסט זה אינני מתכוון לגעת בנושאים של Scalability או Availability של מונגו או בכלל ,לא הקדמה כללית ל-NoSQL (נתתי כזו פעם, היא עדיין רלוונטית דייה) ולא דיון על ה-CAP theorem.

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

עוד קיטלוג של בסיסי נתונים NoSql. מקור: ליאור בר-און

עוד קיטלוג של בסיסי נתונים NoSql. מקור: ליאור בר-און

מונגו DB – מי זה הבחור הזה?

ראשית הייתי רוצה להזכיר בכמה מילים את מודל ה-Document-Based Database בכלל, ואת זה של מונגו בפרט. אם נשווה את המודל של Mongo לבסיס נתונים רלציוני ההשוואה תראה בערך כך:

מקור: ליאור בר-און

מקור: ליאור בר-און

מונגו מנהל מספר בסיסי נתונים, ממש כמו RDBMS. יש אוספים של “מסמכים” (ניתן לחשוב עליהם בשלב זה כמחרוזות של JSON). בתוך ה-JSON יש ערכי key:value (= שדות) שמונגו מודע להם (בניגוד לבסיס נתונים K/V – שם הוא לא).

ניתן ליישם הדמייה ל KVDB (בסיסי נתונים מסוג K/V) על גבי RDBMS בכך שמייצרים טבלה עם 2 עמודות: ID ו-BLOB של נתונים (למשל: קובץ JSON).

באופן עקרוני, בסיס הנתונים הרלציוני יספק את היכולת הבסיסית של KVDB, אך ללא הביצועים / Scalability / זמינות שניתן לקבל מבסיס נתונים KVDB. הוא עתיד “להתפרק” אחרי מאות מיליונים ספורים של רשומות והקצב בו הוא ישרת את לקוחותיו לא הולך להיות מרשים במיוחד.

בסיס נתונים מבוסס מסמכים (בקיצור DBDB) הוא כמו[ב] KVDB עם 2 הבדלים משמעותיים נפוצים:

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

אפשר גם “לקמבן” התנהגות כזו בעזרת RDBMS בעזרת כמה stored procedures, מה שעשוי ליצור יישום יעיל אפילו פחות מ”חיקוי ה KVDB” שתארתי למעלה.

דייט ראשון – התקנה וכלים ראשוניים

ההתקנה של מונגו היא פשוטה למדי:

  • פתיחת ZIP הכולל את קבצי ה-exe. לאיזו תיקיה (ב”חלונות”).
  • יצירת תיקיה ריקה בשם data/db/ (יחסית לכונן בו מונגו מותקן) – התיקייה בה מונגו מאכסן את ה-data שלו. ניתן לקנפג תיקיה אחרת, כמובן.

בין קובצי ה-exe ניתן למצוא כמה מעניינים:

  • mongod.exe – השדון החרוץ (deamon [ג]) של בסיס הנתונים. כלומר: התהליך המרכזי.
  • mongo.exe – ה-Admin Shell, דרכו ניתן לבצע פעולות רבות.
  • mongoexport.exe – פעולות import/export של קבצי נתונים (BSON).
  • mongodump.exe/mongorestore.exe – גיבוי / אחזור של בסיס הנתונים (כקובץ בינארי דחוס).
  • mongostat.exe – תהליך שאוסף נתונים על השימוש ב mongo.

בגדול, כדי להפעיל ולנסות את mongo בצורה קלה יש פשוט להפעיל את mongod.exe ואחריו את mogno.exe. דרך ה-console ניתן לבצע / לנסות את רוב הפעולות המשמעותיות של בסיס הנתונים – ולקבל פידבק מהיר. בואו ננסה משהו:

מקור: ליאור בר-און

מקור: ליאור בר-און

  1. ביקשנו לראות אלו בסיסי נתונים קיימים בעזרת פקודת show dbs. בסיס הנתונים היחידי הקיים הוא local, למרות שמונגו חיבר אותנו בכניסה ל-test – בסיס נתונים ריק. מונגו הוא לעתים רבות עצלן, וייצור אובייקטים מבנים רק כאשר יש בהם תוכן ממשי.
  2. השתמשנו ב-use בכדי לעבור לבסיס נתונים חדש (שעדיין לא קיים). מונגו יזכור אותו, אך עדיין לא ייצור אותו.
  3. פקודת db בודקת באיזה בסיס נתונים אנו כעת.
  4. נתחיל בהכנסות: נכניס לתוך אוסף שעדיין לא קיים (people), בבסיס הנתונים שעדיין לא קיים (“db” הוא האובייקט המייצג את בסיס הנתונים הנוכחי) רשומה – כלומר מסמך, המתאר את ג’ון. ברגע זה מונגו ייצור את בסיס הנתונים ואת האוסף (collection) בשם people – ויכניס לתוכו את הרשומה.

שימו לב שמונגו יקצה קובץ בשם data/db/myNewDb.0 בו הוא יאכסן את בסיס הנתונים. למרות שיש לי רק מסמך אחד קטן – מונגו בחר להקצות אצלי כ 200MB בדיסק – מה שעשוי להראות קצת מבהיל. הסברים – בהמשך הפוסט.

לאחר שלמונגו יש קובץ המייצג את בסיס הנתונים – הוא יכניס במהירות את המסמך השני – לו סכמה דומה אך רחבה יותר.

  1. בשלב זה אני בודק אלו אוספים יש בבסיס הנתונים: מכיוון שבסיס הנתונים נוצר – האוספים כבר קיימים (people ואוסף האינדקסים – שמכיל רשומות ראשוניות בלבד). בדומה ל RDBMS, מונגו משתמש בעצמו כדי לנהל מידע מערכת.
  2. אני אבצע שאילתה (מקבילה ל * SELECT) על אוסף האנשים. הממ… אני לא זוכר שהכנסתי שדה בשם id_, אתם זוכרים?!

סביבת ה-shell, כדרך אגב, היא javaScript לכל דבר – וניתן להשתמש ביכולות ה JavaScript שאתם מכירים (var, פונקציות ועוד). בלינק זה תוכלו למצוא עוד פקודות רבות שניתן להפעיל ב shell. בעיקרון ה-shell הוא כלי מצוין ללמידה, ניסוי, או תפעול של mongoDB.

שדה ה id_

כפי ששמתם לב מונגו הוסיף לנו שדה בתוך המסמך בשם id_. הוא יוסיף שדה זה אם לא הגדרנו אותו בעצמנו (בד”כ נשאיר זאת לו).

מבנה ה-_id. מקור: ליאור בר-און

מבנה ה-_id. מקור: ליאור בר-און

תכונה מעניינת של ה-id_ (נקרא גם object id) היא שה timestamp הוא ראשון, מה שמאפשר לבצע מיון של אובייקטים ע”פ זמן היצירה, בקירוב. הזמן נשמר ע”פ epoch[ה] של unix.

בבסיסי נתונים מסוג KVDB ו DBDB יש חשיבות לא-מעטה לדרך בה בונים את ה ids/keys:

  • ה-key הוא לעתים קרובות המפתח ל-partitioning, ויכול להשפיע רבות על הביצועים.
  • יעילות של ה-hash function יכול להיות משמעותי כאשר מדברים על המון פעולות בשנייה.
  • מה קורה כאשר שני ids מתמפים לאותו key? זה לא סביר כאשר יש אלפי ערכים – אך סביר יותר, כאשר יש מיליארדים.

חיפוש ואינדקסים

במונגו, ניתן לחפש אחר ערכים בתוך collection בעזרת פקודת find, למשל:

db.persons.find({ lastname: 'Smith' });

החיפוש נעשה ע”י “דוגמה” או prototype: אנו מספקים את הערכים שאנו מחפשים ומונגו יחזיר לנו cursor המצביע על האובייקטים שמכילים את הערכים הללו.

ניתן לעשות חיפוש קצת יותר כללי, בעזרת query modifiers המספקים יכולות מספריות / לוגיות, למשל:

db.persons.find( { childrenCount: { $gt: 3 } } );

gt$ הוא קיצור של greater than, כלומר: אנשים בעלי 3 ילדים או יותר. שדה שלא הוגדר באובייקט (כלומר: מסמך) מסוים, יהיה בעל ערך 0 – לצורך העניין. יש גם query modifiers נוספים כגון min$ או or$ ועוד.

אפשר לחפש על אובייקטים מקוננים, למשל address.city או להגדיר שאילותות מורכבות הכוללת מספר רב של שדות או query modifiers לדוגמה:

db.persons.find( { childrenCount: { $gt: 3, $lt 20 } } , 
{ 'address.city': 'Holon' } );

הערה: הסיבה ששמתי את address.city בתוך מכראות נובעת מג’אווהסקריפט. שימוש בנקודה איננו תקני במפתח של אובייקט.

אפשר גם לצמצם את התשובה לשדות מסוים (בדומה ל RDBMS select) בעזרת אובייקט projection – אותו מגדירים בפרמטר השני של הפקודה find:

db.persons.find({ lastname: 'Smith' }, { tile:1, lastname: 1 });

בדוגמה זו אנו רוצים לקבל רק “תואר” ושם משפחה. ערכי ה “1” הם דרך מקוצרת לכתוב true – כלומר: החזר לי את השדה הזה. שימו לב: השדות צריכים להיות כולם true או כולם false – לא ניתן לערבב. יוצא הדופן היחיד הוא השדה id_, אותו ניתן להשמיט גם כאשר יש רשימה “פוזיטיבית” של שדות בהם מעוניינים.

מה עוד ניתן לעשות ב queries? ניתן לעשות הרבה. אציין שליפת מספר קבוע-מראש של ערכים מתוך מערך במסמך (נאמר תגובות בבלוג: רק 10 תגובות ראשונות מכל פוסט), או את היכולת לעשות שאילתות קיבוץ מורכבות (db.collection.group) – ולהוסיף להן פונקציות פילטור בג’אווהסקריפט, ad-hoc.

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

בעולם ה NoSQL עושים הפרדה בין “planned Queries” ו “Ad-hoc Queries”.

Planned Queries הן כאלו שהתכוננו אליהן, לרוב בעזרת יצירת אינדקסים (פנימיים או חיצוניים לבסיס הנתונים), בעוד Ad-hoc Queries הן כאלו שעושים בצורה “ספונטנית” – ללא קיום של אינדקסים, pre-fetch או כל הכנה מקדימה.

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

אינדקסים

הגדרה של אינדקסים היא פשוטה למדי, דומה להגדרת החיפוש:

db.persons.ensureIndex( { firstname: 1 } );

ייצור אינדקס לשדה ה firstname.

db.person.ensureIndex( { "address.city" : 1 } );

ייצור אינדקס לשדה city בתוך תת-האובייקט (או המסמך) address. כמו כן:

db.person.ensureIndex( { lastname: 1, firstname: 1} );

ייצור אינדקס של מפתח המורכב מ2 שדות: שם פרטי, ושם משפחה. התחביר ensureIndex מצביע על כך שאם אינדקס קיים – מונגו לא ישכפל אותו.

יש עוד אפשרויות אינדוקס רבות, עליהן ניתן לקרוא בתיעוד הרשמי.

מבני הנתונים המשמשים את מונגו. מקור: Data Story

מבני הנתונים המשמשים את מונגו. מקור: Data Story

אכסון (Persistency)

שאלה שבוודאי מעניינת מאוד את מי שמגיע מרקע והבנה כיצד עובד RDBMS היא “מה קורה שם בתוך מונגו?” או “כיצד ממימשו זאת?”

בחלק זה אנסה לענות על שאלה זו בקיצור. מונגו כתוב ב ++C וש לו הפצות למערכות הפעלה שונות. מערכת ההפעלה אליה הוא תוכנן במקור היא Unix/Linux (כלומר: מערכת POSIX). יוצרי מונגו לקחו כמה החלטות Design מהותיות:

  1. מונגו יעבוד קודם כל עם זיכרון (עבור המהירות). מונגו אוהב זיכרון, והרבה!
    כל בסיס נתונים שמכבד את עצמו מרוויח מזיכרון, אך כשלמונגו חסר זיכרון – נפילת הביצועים היא משמעותית מאוד.
  2. עדכון של הזיכרון לדיסק יינתן (delegated) למערכת ההפעלה. התכנון המקורי התבסס על הדרך בה מערכת Linux עובדת, וספציפית פקודת mmap למיפוי קבצים – ישירות לתוך הזיכרון. המימוש עבור מערכת ההפעלה “חלונות” הוא כנראה דומה (במסגרת הכלים ש”חלונות” מספקת), אך ידוע כפחות יעיל.
    היתרונות של גישה זו היא קלות פיתוח שמונגו הרוויח, ואי שכפול caches בין מערכת ההפעלה למונגו (מה שמנצל את הזיכרון בצורה יעילה יותר). החיסרון: המנגנון מאחורי mmap הוא כללי ואינו האופטימלי-ביותר לצרכים של מונגו.
  3. למונגו יש רמות “durability” שונות הניתנות לקנפוג. האם כתיבה לבסיס הנתונים תכנס לתור של כתיבה לדיסק (“fire and forget” – דומה ל INSERT_DELAYED של MySQL) או האם כל כתיבה נכתבת במקום ל journal על הדיסק (“fully safe”). ברירת המחדל היא “fire and forget”.
מקור: ליאור בר-און

מקור: ליאור בר-און

מונגו מאכסן כל Database בסדרת קבצים. הקבצים מתחילים בקובץ בגודל 64MB (למשל db.0) ומכפילים את עצמם בכל פעם (128MB – עבור db.1 ואז 256MB עבור db.2) וכו’ עד שמגיעים לגודל של 2GB – ונשארים שם. מונגו מקצה יותר מקום ממה שנדרש למידע בפועל – כדי לא “להתקע” באמצע רצף של כתיבות. במערכת ההפעלה שלי הוא מקצה 200MB לכל בסיס נתונים שרק נוצר.

את הקבצים עצמם מונגו מחלק ל-Extents – מן בלוקים הכוללים data או אינדקסים של collection מסוים (לא מערבבים סוגים ולא מערבבים collections). גם בתוך extent של data, מונגו שומר לכל document מעט Padding – כלומר: יותר מקום ממה שנדרש, במידה והמסמך יגדל במעט. לדוגמה: עדכון של שדה לערך ארוך יותר או הוספה של שדה. המסמכים וה extents הם רציפים בדיסק / זכרון.

db.collection.dataSize();

יספק לנו מידע מה גודל ה collection בבתים, עבור המסמכים וה paddings שלהם.

db.collection.storageSize();

יספק לנו את גודל ה data extents של ה collection. כלומר ()dataSize ועוד מקום שהוקצה בדיסק ועדיין לא בשימוש.

db.collection.totalIndexSize();

יספק לנו את גודל ה index extents של ה collection, כולל שטחים ב extents שעדיין לא בשימוש.

סטטיסטיקות נוספות ניתן לקבל בעזרת אובייקט ה dbStat.

מונגו משתמש בפקודת mmap של לינוקס בכדי למפות extents (בלוקים בקבצים) לזיכרון. הקבצים הם כמו “גדר הגנה” בפני fragmentation שיכולה להיווצר באופן טבעי במערכת הקבצים.

כאשר מסמכים גדלים מעבר ל padding הקיים – הם מועברים למקום חדש עם padding חדש. מונגו לומד את קצב השינויים ב collection ולפיו מבסס את ה padding factor לפיו יקבע גודל padding חדש. גדילות תכופות של מסמכים –> paddings גדולים יותר.

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

fragments בתוך extents של מונגו. מקור: blog: mongolab

fragments בתוך extents של מונגו. מקור: blog: mongolab

הפתרון בעיקרון הוא לבצע de-fragmantation בעזרת פקודת compact.

הקושי: למונגו יש thread יחיד לכתיבות, ופעולת compact תתקע את בסיס הנתונים כולו לזמן מה (כלומר: down time). אפשר לתזמן פעולות תחזוקה אלו או אפשר, בעזרת replication של nodes של מונגו – לעשות את זה offline. זה כנראה לא מה שהייתם מצפים מ”בסיס הנתונים מהדור החדש” – אבל ככה זה.

עוד נקודה כואבת במונגו היא נעילות (לצורך consistency): נעילות הן ברמה של בסיס נתונים (database). עד גרסה 2.1 – נעילות בכלל היו ברמת כל ה instance של מונגו. ישנן תוכניות לעתיד לשפר את רמת הנעילה במונגו.

המשמעות היא כמובן מגבלה משמעותית לביצוע כתיבות ב scale, לפחות כאשר אנו עובדים ברמת durability (או safety) גבוהה. הברירה היא בין לוותר על מידה מסוימת של durability, לצמצם כתיבות, או להשתמש ב very-high-end SSD עם IOPS (פעולות IO בשנייה) גבוה במיוחד: איזה חצי מיליון IOPS, הייתי אומר. האפשרות השלישית – חסומה בחומרה הקיימת כיום, כמובן.

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

מה קורה כאשר רוצים לבצע שינוי במסמך ב’ על בסיס של נתונים ממסמך א’? לבעיה זו אין למונגו פתרון מובנה, ויש כל מיני פתרונות מקובלים / “design patterns” כיצד לפתור את הבעיה. בגדול סט הפתרונות מתבסס על יצירת מסמך שלישי זמני בשם (מפתיע:) transaction שמסייע לנהל את הפעולה.

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

אמנם JSON הוא מבנה נתונים יחסית יעיל, וכאשר מונגו שולח / מאכסן מסמכים – הוא בעצם משתמש בצורה בינרית יותר יעילה שנקראתBSON [ד] (קיצור של Binary JSON), אך עדיין מדובר בבזבוז.

סיכום

מונגו הוא לא בסיס נתונים מושלם, אך כנראה שהוא מספיק טוב למערכות רבות, ויכול לסייע בקיצור זמני פיתוח ותחזוקה. ב-technology stacks כמו MEAN (קיצור של Mongo, Express, Angular and Node.js) – השימוש הטבעי של מונגו ב-javaScript ו JSON מאפשר לכתוב פתרון קצה-אל-קצה בשפה יחידה: javaScript.

למרות שמונגו יחסית עשיר ביכולות, יש לא מעט ספריות ODM (קיצור של Object-Document Mapping), כגון mongoose או doctrine, המסייעות במידול הנתונים או בהעשרת היכולות בשימוש במונגו.

מונגו, ומודל ה-documents בכלל, טבעי מאוד לפיתוח מערכות בהן היינו משתמשים בכלי ORM: מסמך (document) הוא סוג של אובייקט, ועבודת התרגום בין שפת התכנות לשפת בסיס הנתונים, ובחזרה – נחסכת מאיתנו. ביוחד כאשר יש לפרק/להרכיב “אובייקט” יחיד מטבלאות רבות.

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

כשאתם ניגשים לעבוד במונגו – אל תצפו ל-Internet Scale. הוא כנראה טוב ב-Scale בהרבה מ-RDBMS – אך לא טוב כמו Riak או Cassandra. כמו כן אל תצפו לבגרות של RDBMS – המבוססים על מודל שכבר בעבודה במשך עשרות שנים.

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

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

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

מצגת מעניינת על מידול נתונים במונגו

השוואה (מעט פרובוקטיבית) בין הביצועים של מונגו ו MS SQL

—-

[א] DB-Engines קיים “כולו” שנתיים ומשהו, אבל ע”פ כל מדד מקובל – לא נראה שבסיס נתונים לא-רלציוני היה איפשהו ברשימה הפותחת ב 30 שנה האחרונות.

עוד הערה: Cassandra ומונגו נמצאים ברשימת ה top10 מאז המדד החל, אולם Sybase ASE “נדחף” ל Cassandra באמצע והחזיר אותו למקום העשירי. הסיבה היא כנראה החיזוק ש ASE קיבל מרכישת SAP את Sybase, אולם אין בכך לגרוע מהמגמה הכללית: ASE צמח בעיקר על חשבון אורקל.

[ב] ב-NoSQL, כמו ב-NoSQL – אין הגדרות מוסכמות או חד-משמעיות. התייחסו לכל הגדרה כ “נקודת מבט אפשרית”.

[ג] מקור המונח deamon הוא מניסוי מחשבתי בתחום התרמודינמיקה בשם Maxwell’s demon בו יש שדון שעובד ללא הפסקה ברקע ופותח דלת קטנה לחלקיקים שיעברו דרכה… deamon היא צורת כתיבה עתיקה של המילה demon (שד).

[ד] פורמט BSON גם מאפשר ניהול טיפוסים שלא קיימים ב-javaScript כגון object id או date כפרמיטיב.

[ה] epoch (תאריך בסיס) הוא נקודת ייחוס ממנה שומרים תאריך בצורה מספרית, בדרך כלל בשניות. MS DOS, היתה מערכת 16bit ולא רצו לשמור תאריך, בשניות, משנת 0 (או אפילו מ 1970, כמו unix) – ולכן ה-epoch הוא 1/1/1980.

כדי לתאר את התאריך 2/1/1980 (יום אחרי) – יש לשמור בשדה התאריך את המספר 24*60*60 = 86,400.

במערכת הקבצים NTFS (חלונות NT) זמן הייחוס הוא שנת 1601 – השנה הראשונה במחזור 400-השנים של לוח השנה הגרוגאני בו, שימו לב: שוחררה חלונות NT!. אפל (כתגובה?) קבעה את ה epoch של OS X לשנת 2001 – השנה בה יצאה מערכת ההפעלה OS X.

בגרסאות קודמות של MAC OS, ה epoch היה שנת 1904 – שנקבעה בגלל שזו הייתה “השנה המעוברת הראשונה במאה ה-20”, ואולי כדי להתבשם בעובדה שזו הייתה מערכת שרצה על מעבדי 24 ביט (בזמן ש DOS הייתה תלויה בעבדי 16 ביט, ו epoch כזה היה מגביל אותה).

הפוסט פורסם לראשונה בבלוג ארכיטקטורת תוכנה.

Avatar

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

7 תגובות על "הלו מונגו! [MongoDB מדריך למתחילים]"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
מישהו
Guest
זה שטויות להגיד ש mongo הוא טוב יותר בscale בהרבה מRDBMS. הסיבה שמסדי נתונים ״לא רלציונים״ הם ״טובים יותר״ בscale היא שאין פעולות join. אם תעבוד עם mysql ללא join תוכל להשיג תוצאות דומות להרבה מאוד מקרים. אפשר לעשות אופטימיזציות לכל מסד נתונים. facebook לדוגמא משתמשים ״רק״ בmysql. פשוט יש להם צוות מוכשר שיודע לעשות אופטימיזציות כמו שצריך. אני השתמשתי בmysql עבור פרוייקטים עם המון נפח והמון נתונים והמון inserts ובשורה התחתונה זה עניין של קונפיגורציה נכונה ותכנון מערכת נכון. אין לי שום דבר נגד מסדי נתונים לא רלציונים, אבל בעקרון לרוב המערכות שיש כיום מתאים יותר מסד נתונים רצליוני.… Read more »
מישהו
Guest

ואני מתנצל שנתפסתי על ההערה הזו. חוץ מזה, אחלה כתבה :)

שין
Guest
קודם כל פייסבוק לא משתמשים רק בMySQL אלא בערך בכל מסד נתונים פופולרי שקיים היום, כמו גם בMONGO. לגבי SCALE אתה צודק. הקונספט הגדול של NoSQL הוא לא MongoDB שהוא בסה”כ DB סביר (אני משתמש בו לפרויקט גדול מאוד). התחלתי להשתמש בו בגלל הבאז ובגלל שהוא חינם ורק באמצע הפרויקט הבנתי שאין לו שום יתרון על MsSQL נניח או כל DB רלציוני אחר חוץ מהיתרון הקטנטן של חוסר סכימה (אותו ניתן לעקוף בקלות בDB רלציוני). הקונספט הגדול בNoSQL הוא לחזור לצורת החשיבה של פעם, לשכפל נתונים מהסיבה הפשוטה שדיסק הוא משאב זול – לעומת CPU וזכרון שהם משאבים יקרים ומוגבלים,… Read more »
aviv
Guest
בתור אחד שעובד עם מונגו כבר למעלה מ3 שנים ניכר כי הכותב לא עשה שימוש רציני בDB אם בכלל ורק כמו חננה העתיק נתונים שטחיים בעיקר ולא הביא נקודות וטיפים מהשטח. אז למי שמתעניין, הנה כמה נקודות מעניינות: 1.הסיבה העיקרית שמונגו הוא הNOSQL הנפוץ ביותר היא בגלל שהוא פשוט להתקנה,ללמידה ויש לו אחלה אתר שגם קוף יכולה להבין איך לעבוד עם זה. יש עוד הרבה NoSQL טובים לא פחות אבל מה לעשות שרובנו עצלנים(ובצדק) ואנחנו תמיד נוטים לפתרון הפשוט והברור ביותר. 2.לעבוד עם מונגו משמע שאין join ובגלל זה 99% מהחברות הישראליות שעושות שימוש בו, עובדות בו בצורה היברדית משמע… Read more »
Oded Shafran
Guest

It’s Daemon and not Deamon

אריק
Guest

אחלה והכל אבל ממה שאני רואה בפועל mongo הוא טכנית די מעאפן, אולי הוא קל להתקנה ונותן sharding out of the box אבל בscale גדול זה לא ממש יסחוב, בגלל הצורה שבה הוא בנוי, השוק הולך יותר ויותר לכיוון של cassandra

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

רוברטו
Guest

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

wpDiscuz

תגיות לכתבה: