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

אם אתה מרגיש שאני מגן על MongoDB, אנא קרא כתב ויתור בסוף המאמר.

טרנד חדש

אני עובד בתעשיית התוכנה יותר שנים ממה שאני יכול לומר, אבל עדיין נחשפתי רק לחלק קטן מהמגמות שפגעו בתעשייה שלנו. הייתי עד לעלייה של 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... הרשימה אינסופית. בכל שנה מופיעים טרנדים חדשים. חלקם מתפוגגים במהירות, בעוד שאחרים משנים מהותית את אופן פיתוח התוכנה.

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

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

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

והמפתחים התנפלו על זה. הרעיון של מסד נתונים חסר סכמות שמתרחב בצורה קסומה כדי לפתור כל בעיה היה די מפתה. בסביבות 2014, נראה היה שבכל מקום שבו השתמשו לפני שנה במסד נתונים רלציוני כמו MySQL, Postgres או SQL Server החלו לפרוס מסדי נתונים של MongoDB. כששואלים אותך למה, אתה יכול לקבל תשובה מ"זהו קנה המידה של האינטרנט" הבנאלי ל"הנתונים שלי מובנים מאוד רופפים ומשתלבים היטב במסד נתונים ללא סכמה".

חשוב לזכור כי MongoDB, ומסדי נתונים של מסמכים בכלל, פותרים מספר בעיות עם מסדי נתונים יחסיים מסורתיים:

• תכנית קפדנית: עם מסד נתונים יחסי, אם יצרת נתונים דינמיים, אתה נאלץ ליצור חבורה של עמודות "שונות" אקראיות של נתונים, לדחוף לשם קוביות נתונים או להשתמש בתצורה EAV... לכל זה יש חסרונות משמעותיים.
• קושי בקנה מידה: אם יש כל כך הרבה נתונים שהם לא מתאימים לשרת אחד, MongoDB הציעה מנגנונים שיאפשרו לה להתאים אותה למספר מכונות.
• שינויים מורכבים במעגל: אין הגירות! במסד נתונים יחסי, שינוי מבנה מסד הנתונים יכול להיות בעיה עצומה (במיוחד כאשר יש הרבה נתונים). MongoDB הצליח לפשט מאוד את התהליך. וזה עשה את זה כל כך קל שאתה יכול פשוט לעדכן את המעגל תוך כדי תנועה ולהמשיך מהר מאוד.
• הקלטת ביצועים: ביצועי MongoDB היו טובים, במיוחד כשהם מוגדרים כראוי. אפילו תצורת ה-Out-of-the-box של MongoDB, שעליה זכתה לביקורת לעתים קרובות, הציגה מספרי ביצועים מרשימים.

כל הסיכונים הם עליך

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

למען ההגינות, אף אחד ב-10gen/MongoDB Inc. לא יגיד שהדברים הבאים אינם נכונים, אלו רק פשרות.

• עסקאות אבודות: עסקאות הן מאפיין ליבה של מסדי נתונים יחסיים רבים (לא כולם, אבל רובם). פירוש הדבר הוא שאתה יכול לבצע מספר פעולות בצורה אטומית ויכול להבטיח שהנתונים יישארו עקביים. כמובן, עם מסד נתונים NoSQL, העסקאות יכולה להיות בתוך מסמך בודד, או שאתה יכול להשתמש בהתחייבויות דו-פאזיות כדי לקבל סמנטיקה של טרנזקציות. אבל תצטרך ליישם את הפונקציונליות הזו בעצמך... מה שעלול להיות משימה קשה וגוזלת זמן. לעתים קרובות אתה לא מבין שיש בעיה עד שאתה רואה שהנתונים במסד הנתונים מגיעים למצבים לא חוקיים מכיוון שלא ניתן להבטיח את האטומיות של הפעולות. הערה: אנשים רבים אמרו לי ש-MongoDB 4.0 הציג עסקאות בשנה שעברה, אבל עם כמה מגבלות. ההנחה מהמאמר נשארה זהה: העריכו עד כמה הטכנולוגיה עונה על הצרכים שלכם.
• אובדן שלמות יחסים (מפתחות זרים): אם לנתונים שלך יש קשרים, תצטרך ליישם אותם באפליקציה. קיום מסד נתונים שמכבד את היחסים הללו ייקח הרבה מהעבודה מהאפליקציה ולכן מהמתכנתים שלך.
• חוסר יכולת ליישם מבנה נתונים: סכימות קפדניות יכולות לפעמים להוות בעיה גדולה, אבל הן גם מנגנון רב עוצמה למבנה נתונים טוב אם נעשה בהם שימוש מושכל. מסדי נתונים של מסמכים כמו MongoDB מספקים גמישות סכימה מדהימה, אך גמישות זו מסירה את האחריות לשמירה על ניקיון הנתונים. אם לא תטפל בהם, בסופו של דבר תכתוב הרבה קוד באפליקציה שלך כדי להתחשב בנתונים שאינם מאוחסנים בצורה שאתה מצפה. כפי שאנו אומרים לעתים קרובות בחברה שלנו Simple Thread... האפליקציה תישכתב מתישהו, אבל הנתונים יחיו לנצח. הערה: MongoDB תומך בבדיקת סכימה: הוא שימושי, אך אינו מספק את אותן הבטחות כמו במסד נתונים יחסי. ראשית, הוספה או שינוי של בדיקת סכימה אינה משפיעה על הנתונים הקיימים באוסף. זה תלוי בך לוודא שאתה מעדכן את הנתונים בהתאם לסכימה החדשה. תחליטו בעצמכם האם זה מספיק לצרכים שלכם.
• שפת שאילתה מקורית / אובדן מערכת אקולוגית של הכלי: הופעת SQL הייתה מהפכה מוחלטת ושום דבר לא השתנה מאז. זו שפה חזקה להפליא, אבל גם די מורכבת. הצורך לבנות שאילתות מסד נתונים בשפה חדשה המורכבת מקטעי JSON נחשב כצעד גדול אחורה על ידי אנשים שיש להם ניסיון בעבודה עם SQL. יש יקום שלם של כלים המקיימים אינטראקציה עם מסדי נתונים של SQL, מ-IDEs ועד כלי דיווח. מעבר למסד נתונים שאינו תומך ב-SQL פירושו שאינך יכול להשתמש ברוב הכלים הללו או שאתה צריך לתרגם את הנתונים ל-SQL כדי להשתמש בהם, מה שעלול להיות קשה יותר ממה שאתה חושב.

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

מה אפשר היה לעשות אחרת?

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

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

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

אם אינך נתקל בבעיה כלשהי, אינך זקוק לכלי חדש. נְקוּדָה.

שאלה 1: אילו בעיות אני מנסה לפתור?

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

שאלה 2: מה אני מפספס?

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

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

אנשים תמיד הורסים הכל

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

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

הערכה אובייקטיבית אינה קלה, אך הבנת ההטיות הקוגניטיביות הבסיסיות תעזור לך לקבל החלטות רציונליות יותר.

תקציר

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

• האם הכלי הזה פותר בעיה אמיתית?
• האם אנחנו מבינים היטב את ההחלפות?

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

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

כתב ויתור

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

מקור: www.habr.com