הגדרת שארדינג MongoDB להרחבה אופקית

שׁירדינג ב-MongoDB: היכן הקלאסטר נתקל בתקרת העומס

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

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

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

גם סקיילינג אנכי נתקל בתקרה: ניתן להגדיל משאבים של צומת אחת лишь עד מחלקה מסוימת של מכונות, והתפוקה מכל מדרגה נוספת יורדת. שׁירדינג mongodb מפזר נתונים לפי מפתח ומסיר את התלות בשרת אחד — אך זה עובד רק כאשר המפתח נבחר לפי תבניות שאילתות אמיתיות, ולא לפי נוחות הסכימה.

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

מה נותן פיזור הנתונים: תפוקה ומרווח צמיחה

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

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

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

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

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

עמידות בפני עומס שיא נובעת מאותו מרווח: צמתים מתווספים בלי לעצור את השירות, ופיזור מחדש של chunks מתבצע ברקע.

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

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

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

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

היכן עוברים גבולות התחולה

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

הטמעת שׁירדינג ב-MongoDB: מביקורת ועד מסירה

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

הכנה ותכנון

1. איסוף מדדים ופרופיל עומס — אוספים סטטיסטיקת שאילתות, מאתרים את האוספים הגדלים במהירות הרבה ביותר, בודקים את פיזור השדות במסננים ובמיון, נתקלים בדיסק ובזיכרון. בלי הנתונים האלה בחירת המפתח הופכת לניחוש.
2. תכנון סכימת הפיזור — קובעים את המפתח (מגובב או מורכב עם קרדינליות גבוהה), מספר השׁארדים, מיקום הרפליקות, תיוג לפי פיזור גיאוגרפי. בנפרד מתעדים אילו אוספים נשארים ללא שׁירדינג ומדוע.
3. כיוונון רכיבים — פורשים ראוטרים ושרתי תצורה עם רפליקציה, מאחדים את סטי-הרפליקה של השׁארדים לתצורה אחידה, מפעילים את המאזן, יוצרים אינדקסים שתומכים במפתח.

בדיקת עומס ומסירה לתפעול

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

מה נשאר לכם אחרי ההטמעה: תצורות, סכימות, נהלים

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

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

הדרכת הצוות

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

מסירת הרשאות

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

מקרה בוחן: כיצד גדלה התפוקה לאחר פיזור הנתונים

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

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

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

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

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

במה שונה רפליקציה מפיזור נתונים ומה לבחור?

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

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

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

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

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

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

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

ספקות טכניים נפוצים: chunks, מפתחות ועמידות בפני כשלים

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

כיצד לבחור מפתח שׁארד?

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

האם אפשר לבצע מיגרציה בלי לעצור את השירות?

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

מה משתנה בגיבוי ובאפליקציה?

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

נדון בסכימה שלכם: נאסוף מדדים ונחזור עם תוכנית

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

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

מה אתם שולחים:

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

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

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