14 דברים שהלוואי שידעתי לפני שהתחלתי עם MongoDB

תרגום המאמר הוכן ערב תחילת הקורס "מאגרי מידע לא יחסיים".

הבהרה:

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

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

יצירת שרת MongoDB ללא אימות

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

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

אל תשכח לאגד את משטח ההתקפה ל-MongoDB

רשימת אבטחה של MongoDB מכיל עצות טובות להפחתת הסיכון לחדירת רשת ולדליפת נתונים. קל לצחצח את זה ולהגיד ששרת פיתוח לא צריך רמת אבטחה גבוהה. עם זאת, זה לא כל כך פשוט וזה חל על כל שרתי MongoDB. בפרט, אם אין סיבה משכנעת להשתמש mapReduce, group או $ איפה, עליך להשבית את השימוש בקוד שרירותי ב-JavaScript על ידי כתיבה בקובץ התצורה javascriptEnabled:false. מכיוון שקובצי נתונים אינם מוצפנים ב-MongoDB הסטנדרטי, הגיוני להפעיל את MongoDB איתו משתמש מסור, בעל גישה מלאה לקבצים, עם גישה מוגבלת רק אליו ויכולת להשתמש בבקרות הגישה לקבצים של מערכת ההפעלה עצמה.

שגיאה בעת פיתוח המעגל

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

מאמר קלאסי"6 כללי אצבע לעיצוב סכמת MongoDB" זה שווה קריאה, ותכונות כמו סייר סכימה בכלי הצד השלישי Studio 3T כדאי להשתמש לבדיקות רגילות של מעגלים.

אל תשכח את סדר המיון

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

צור אוספים עם מסמכים גדולים

MongoDB שמחה לארח מסמכים גדולים עד 16MB באוספים, ו GridFS מיועד למסמכים גדולים יותר מ-16 MB. אבל רק בגלל שניתן למקם שם מסמכים גדולים, לאחסן אותם שם זה לא רעיון טוב. MongoDB יעבוד הכי טוב אם אתה מאחסן מסמכים בודדים בגודל של כמה קילובייטים, ומתייחס אליהם יותר כמו שורות בטבלת SQL רחבה. מסמכים גדולים יהוו מקור לבעיות עם פִּריוֹן.

יצירת מסמכים עם מערכים גדולים

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

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

אל תשכח שסדר השלבים בצבירה חשוב

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

ב-MongoDB אתה מורה לטבח. לדוגמה, עליך לוודא שהנתונים עוברים reduce מוקדם ככל האפשר בצנרת באמצעות $match и $project, והמיון מתרחש רק לאחר reduce, ושהחיפוש מתרחש בדיוק בסדר הרצוי. שימוש במיטוב שאילתות שמבטל עבודה מיותרת, מסדר את השלבים בצורה אופטימלית ובוחר סוגי הצטרפות יכול לקלקל אותך. עם MongoDB, יש לך יותר שליטה במחיר של נוחות.

כלים כמו סטודיו 3T יפשט את הבנייה של שאילתות צבירה ב MongoDB. התכונה Aggregation Editor מאפשרת לך להחיל הצהרות צינור שלב אחד בכל פעם, ולבדוק נתוני קלט ופלט בכל שלב כדי לפשט את ניפוי הבאגים.

שימוש בהקלטה מהירה

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

מנועי האחסון MMAPv1 ו-WiredTiger משתמשים ברישום כדי למנוע זאת, אם כי WiredTiger יכול להתאושש עד האחרון העקבי נקודת שליטה, אם הרישום מושבת.

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

כדי להיות בטוח בערכים, ודא שהרישום מופעל בקובץ התצורה (storage.journal.enabled)ותדירות ההקלטות מתאימה לכמות המידע שאתה יכול להרשות לעצמך לאבד.

מיון ללא אינדקס

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

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

חפש ללא תמיכה באינדקס

שאילתות חיפוש מבצעות פונקציה דומה לפעולת JOIN ב-SQL. כדי לעבוד בצורה הטובה ביותר, הם צריכים את האינדקס של הערך של המפתח המשמש כמפתח הזר. זה לא מובן מאליו כי השימוש לא בא לידי ביטוי explain(). מדדים כאלה מתווספים לאינדקס שנכתב בו explain(), שבתורו משמש את מפעילי הצינורות $match и $sort, כשהם נפגשים בתחילת הצינור. אינדקסים יכולים כעת לכסות כל שלב צינור צבירה.

ביטול הסכמה לשימוש בריבוי עדכונים

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

אל תשכח את החשיבות של סדר המפתחות בטבלת חשיש

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

לרוע המזל, BSON שמה דגש רב על סדר בעת החיפוש. ב-MongoDB, סדר המפתחות בתוך אובייקטים מובנים ענייניםכלומר { firstname: "Phil", surname: "factor" } - זה לא אותו דבר כמו { { surname: "factor", firstname: "Phil" }. כלומר, עליך לאחסן את סדר צמדי השם/ערך במסמכים שלך אם אתה רוצה להיות בטוח למצוא אותם.

אל תבלבל "ריק" и "לא מוגדר"

ערך "לא מוגדר" מעולם לא היה תקף ב-JSON, לפי תקן רשמי JSON (ECMA-404 סעיף 5), למרות שהוא נמצא בשימוש ב-JavaScript. יתר על כן, עבור BSON הוא מיושן והוא מומר ל $null, וזה לא תמיד פתרון טוב. להימנע מלהשתמש "לא מוגדר" ב- MongoDB.

להשתמש $limit() без $sort()

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

מסקנה

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

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

קרא עוד:

• כיצד לטעון נתונים לתוך Google BigQuery

מקור: www.habr.com