שרדינג Bitrix: היכן נתקע מסד הנתונים של פרויקט בצמיחה
כל עוד הפרויקט חי על צומת מסד נתונים אחד, קריאות וכתיבות חולקות את אותם משאבים. קטלוג, סל ותהליך השלמת הזמנה פונים לטבלאות חמות בו-זמנית: נעילות שורות על מלאי ומחירים נכנסות לתור, והדפים ממתינים לשחרור מאגר הבאפר. מבחוץ זה נראה כמו אתר איטי תחת עומס, אף שהקוד והתבניות אינם הבעיה כאן.
הראשון שנכשל הוא גידול הקטלוג. כל עוד מערך האינדקסים הפעיל נכנס לזיכרון, מסננים ומיון עובדים מהר; ברגע שנפח הפריטים והיסטוריית ההזמנות עולה על הזיכרון, המתכנן מעביר את הקריאה לדיסק — והתגובה גדלה באופן לא ליניארי.
ההידרדרות עם גידול הקטלוג מתרחשת במדרגות: עד גודל מסוים הכול יציב, לאחריו מדורים נפתחים לאט יותר באופן ניכר.
שיא העומס משלים את התמונה: רפליקציה לא עומדת בקצב זרם הכתיבות, הפיגור גדל, וחלק מהקריאות עוברות לצומת שממילא עסוק בכתיבה. תהליך השלמת ההזמנה נשבר בדיוק כאן — הטרנזקציה נכנסת לתור אחרי נעילות, וניסיון חוזר מקבל סל שכבר תפוס.
עומס יתר על מסד הנתונים לא נרפא על ידי אופטימיזציה של שאילתות בודדות, אם צוואר הבקבוק של מסד הנתונים הוא הצומת עצמו. נבחן כיצד זה נסגר: שרדינג ב-Bitrix, בחירת מפתח פיצול, אילו טבלאות נשארות בצומת הראשי ואילו עוברות לשרדים, וכיצד לשמור על עקביות הסל וההזמנות בעת הפיצול.
מה נותן פיצול נתונים: אפקט מדיד עבור הפרויקט
פיצול נתונים נותן אפקט שנראה במספרים. כל עוד הוויטרינה, ההזמנות ויומן האירועים חיים במסד אחד, עומס השיא מכניס את השאילתות שלהם לתור משותף: שליפה כבדה מהיסטוריית הזמנות מחזיקה נעילות ומאטה את הקטלוג, אף שאין לה קשר לקטלוג.
לאחר העברת הקריאה לצמתים נפרדים, זמן התגובה של האתר מפסיק להיות תלוי במשימות רקע — הקטלוג מוגש באותה מהירות גם בשעת מבצע וגם ביום רגיל.
עמידות מסד הנתונים בפני תקלות משתנה באופן איכותי, לא כמותי. בצומת אחד, תקלת חומרה עוצרת גם את הוויטרינה וגם את קליטת ההזמנות, וזמן השחזור נמדד בשעות של פריסת גיבוי.
כאשר הנתונים מפוצלים למקטעים, תקלה מוציאה מכלל פעולה רק חלק מהפונקציות, האחרות ממשיכות לעבוד, והצומת שנפגע עולה מרפליקה תוך דקות.
בנפרד נעלם סוג שלם של תקלות: מילוי דיסק על ידי יומן, נעילות הדדיות על טבלאות משותפות, חוסר זמינות מלא של הסל תחת עומס. שיעור ההזמנות האבודות יורד בדיוק בגלל זה — התקלה מפסיקה להיות כוללת.
גם עלות ההשבתה נעשית צפויה: במקום "האתר שכב עד שהרימו אותו" מופיע חלון של כמה דקות למעבר בין מקטעים. בפרויקטים על 1C-Bitrix זה נעשה ברמת שכבת הגישה לנתונים, ולכן לוגיקת האפליקציה לא נכתבת מחדש.
סכימות שרדינג Bitrix: השוואת גישות לפיצול
שרדינג ב-Bitrix הוא לא סכימה אחת, אלא בחירה של מאפיין שלפיו הנתונים מתפזרים בין צמתים. המאפיין קובע את כל השאר: כיצד האפליקציה מוצאת את הצומת הנכון, אילו שליפות הופכות לחוצות-שרדים, ואיזו עקביות נתונים יהיה צריך לשמור ידנית. להלן ארבע סכימות שאנו משווים בשלב ההתחלה.
| סכימת פיצול | מתי מתאימה | מגבלות |
|---|---|---|
| לפי לקוח או קבוצת משתמשים | פורטל שבו נתוני חברות מבודדים: עסקאות, משימות, מסמכים | דוחות מרוכזים נאספים בנפרד; נדרשת טבלת עזר "לקוח → צומת" |
| לפי פרויקט או אתר | כמה אתרים בלתי תלויים על אותה ליבה | טבלאות עזר ומשתמשים משותפים משוכפלים, ואימות מרכזי דורש סנכרון |
| חלוקת טבלאות לפי זמן | יומנים, סטטיסטיקה, הזמנות — טבלאות גדלות שניגשים אליהן לפי תאריכים | שאילתה חייבת לסנן לפי מפתח המקטע, אחרת נקראים כל המקטעים ברצף |
| העברת טבלאות "חמות" לצומת נפרד | הכתיבה נתקעת בסשנים, בסל או במטמון, ומודל הנתונים העיקרי קטן | האפליקציה עובדת עם שני מקורות, וטרנזקציות ביניהם אינן אטומיות |
ניתוב שאילתות נפתר או באפליקציה — החיבור נבחר לפי הצומת המחושב, או בשכבה מתווכת שמפרקת את השאילתה ובוחרת בעצמה את מסד הנתונים. הדרך השנייה כמעט לא דורשת שינויים בלוגיקת העסק, אך מגבילה את מורכבות השליפות.
עקביות הנתונים בכל פיצול נשארת באחריות הצוות: תיאום בין צמתים מוסיף השהיה, ולכן חלק מהפעולות מועברות לסנכרון רקע.
שלבי הטמעת אחסון מפוצל: מביקורת ועד מסירה
אחסון מפוצל מטמיעים לא במעבר אחד, אלא ברצף שלבים שבו כל שלב נשען על התוצאה של קודמו. זה מאפשר לשנות את סכימת הנתונים בפרויקט 1C-Bitrix פעיל בלי לעצור את העסק: אי-הוודאות מוסרת על עותק, ולא על סביבת הייצור.
-
ביקורת מסד הנתונים ופרופיל העומס. אוספים שאילתות איטיות, נפח טבלאות ואופי הפניות: קריאה מול כתיבה, דוחות כבדים, קטלוג מול הזמנות. בתוצאה — מפת נתונים עם נימוק מה מחלקים ולפי איזה מאפיין.
-
תכנון סכימת הפיצול. בוחרים מפתח שרדינג, הרכב כל חלק, כללים לשליפות חוצות וצבירות. בודקים שההתפלגות אחידה ושאינה נתקעת בחלק חם אחד.
-
הגדרת ניתוב. רושמים כיצד האפליקציה מפנה שאילתה לחלק הנכון, כולל טבלאות עזר שמשוכפלות במלואן. מכסים את הכללים בבדיקות — אחרת שאילתות הולכות למקום הלא נכון ומחזירות שליפות ריקות.
-
בדיקה על סביבת בדיקות. מרימים עותק של מסד הייצור בנפח דומה, מודדים זמן תגובה והתפלגות עומס, ומשווים את התוצאה לאמת מידה. רק לאחר מכן מדברים על מעבר.
-
העברה ללא השבתה. מסנכרנים נתונים, מפעילים כתיבה לסכימה החדשה, בודקים שלמות ומעבירים את התעבורה. חלון ההידרדרות נמדד בדקות ואינו דורש עצירת מכירות.
-
מסירה לתחזוקה. מוסרים סכימת נתונים, כללי ניתוב, נוהל גיבוי והוראות להוספת חלקים חדשים. בנוסף מפת מדדים שמראים שהפיצול הפסיק להתמודד עם העומס.
מה נשאר אצל הלקוח: סכימות, מדיניות, נהלים
איננו משאירים את הלקוח עם מערכת עובדת אך לא מובנת. לאחר העלאת השרדינג לפעילות ייצור, הצוות מקבל ערכת תיעוד שלפיה אפשר לפתח את הסכימה בעצמו: להוסיף צומת לגידול נתונים, להחליף רפליקה בעת תקלה, לבצע איזון מחדש בלי לפנות אלינו בכל שלב.
הארטיפקטים חיים במאגר שלכם ומתעדכנים באותו שינוי כמו הקונפיגורציה — בעת החלפת מפתח שרדינג או הוספת צומת מתקנים את הסכימה העובדת, ולא קובץ נפרד "לצורכי דוח".
- סכימת טופולוגיה — צומתי שרדינג, רפליקות, טבלאות גלובליות, נקודות כשל והתפלגות הנתונים בפועל בין השרדים.
- מפת ניתוב שאילתות — אילו פניות עוברות לשרד מסוים, אילו הולכות לצומת משותף ומדוע נבחר כלל כזה.
- מדיניות גישה — תפקידים של מנהלים, מפתחים ותמיכה, חשבונות נפרדים למשימות שירות וגבולות הרשאות לכל שרד.
- נוהל תחזוקה — חלונות עבודה מתוכננים, סדר פעולות בעת תקלת צומת, תנאים ורצף להחלפת רפליקה.
- הוראות לצוות — נהלים צעד-אחר-צעד להוספת שרד, איזון מחדש וחזרה לאחור של שינוי כושל.
- נוהל גיבוי — תדירות צילומים לפי שרדים, בדיקת שחזור ותקופות שמירת עותקים.
- יומן שינויים ומדדים — היכן מתועדים תיקוני הסכימה ולפי אילו מדדים רואים הידרדרות לפני תקלה.
מקרה בוחן: כיצד פיצול נתונים הסיר הידרדרות תחת עומס
פרויקט — קטלוג גדול עם היסטוריית הזמנות ואזור אישי על 1C-Bitrix. טבלת ההזמנות וטבלת הפריטים גדלו לעשרות מיליוני שורות, ובמבצעים זמן התגובה של כרטיס המוצר עבר 4–5 שניות. חלק מהשאילתות נפלו בגלל פסק זמן, שליפות דוח חושבו בדקות, וצבירת הלילה חסמה כתיבה — המנהלים ראו מלאי מיושן.
מה שינו
טבלאות חמות חולקו למקטעים: הזמנות — לפי תקופה, פריטים — לפי מפתח לקוח, כך ששליפות מהאזור האישי ומהאדמין קוראות מקטע אחד או שניים במקום את כל ההיסטוריה. הקריאה הועברה לרפליקות, הכתיבה נשארה על צומת המאסטר, והחיפוש בהיסטוריית ההזמנות עבר למבנה דנורמליזציה נפרד.
המטמון חולק לרמות: עמודי קטלוג ללא נתונים אישיים נבנים ממטמון מרוכב, ובלוקים אישיים — ממטמון אובייקטים.
מה השתנה
לפני העלייה לאוויר הרצנו בדיקות עומס עם פרופיל של שיא אמיתי. זמן התגובה של הקטלוג תחת עומס — 0.6 שניות במקום 4–5, ושיעור השאילתות שהסתיימו בשגיאה — מ-12% לאפס. שחזור לאחר תקלת צומת — 40 שניות במקום 15 דקות, בנייה מחדש של אינדקס — דקות במקום שעות. צבירת הלילה מתבצעת לפי מקטעים בטרנזקציות נפרדות וכבר אינה חוסמת כתיבה.
סוג שלם של תקלות נעלם — הידרדרות זמן התגובה עם גידול הנתונים. בהמשך, הקיבולת גדלה בהוספת מקטעים, בלי לכתוב מחדש שאילתות ובלי לעצור את השירות.
במה פיצול אופקי שונה מרפליקציה
רפליקציה מעתיקה את אותו מערך נתונים לכמה צמתים: המוביל מקבל כתיבה, והרפליקות משרתות קריאה. זה מסיר עומס מהשליפות — קטלוג, חיפוש, אזורים אישיים — ונותן מרווח בעמידות בפני תקלות. אבל הנפח בכל צומת נשאר מלא, והכתיבה עדיין עוברת דרך צומת אחד.
פיצול אופקי חותך את הנתונים לחלקים בלתי תלויים — לפי חשבון, אזור, תאריך. כל שרד מחזיק את חלקו ומשרת גם קריאה וגם כתיבה, ולכן התקרה זזה בכפולה של מספר הצמתים. המחיר — ניתוב שאילתות, פעולות בין-שרדיות ודוחות חוצי-מערכת שנאספים בנפרד.
| גישה | מה פותרת | מגבלות |
|---|---|---|
| רפליקה של מסד נתונים | עומס קריאה, עמידות בפני תקלות, דוחות על צומת נפרד | הנפח בכל צומת מלא, כתיבה דרך צומת אחד |
| פיצול אופקי | התקרה לכתיבה ולנפח גדלה עם מספר השרדים | ניתוב, פעולות בין-שרדיות, אנליטיקה חוצת-מערכת |
| סכימה משולבת | ישויות כבדות על שרדים משלהן, קריאה — מרפליקות | תחזוקה וגיבוי מורכבים יותר |
הקריטריון לבחירה פשוט: אם הכתיבה לצומת אחד הפסיקה להיכנס לחלונות השיא, רפליקות לא יצילו — אף עותק לא מקבל כתיבה מהר יותר מהמוביל. זה בדיוק הרגע שבו נדרש מערך מפוצל.
בפועל משלבים סכימות: ישויות כבדות — הזמנות, היסטוריית פעולות — מפוזרות בין שרדים, ועל כל שרד שמים רפליקות לקריאה. ב-1C-Bitrix פיצול כזה נבנה בדרך כלל לפי אתרים או חשבונות גדולים, כך שנתוני לקוח אחד חיים על צומת אחד.
סדר העבודה הפוך לאינטואיציה: תחילה ממצים את הרפליקות והמטמון, ורק אחר כך עוברים לשרדינג לפי מפתח שאינו משתנה בישות.
ספקות טכניים נפוצים לפני פיצול נתונים
פיצול נתונים נוגע לא רק בקונפיגורציית השרת, אלא גם בקוד שהצטבר בפרויקט במשך שנים. להלן השאלות שצוותי ההנדסה של הלקוח שואלים לרוב לפני ההתחלה, והתשובות שלנו לכל אחת.
האם יהיה צורך לעצור את האתר בזמן ההעברה?
עצירה מלאה נדרשת רק במעבר של קריאה וכתיבה — דקות, לא שעות. עיקר הנפח מועבר על מערכת פעילה, לאחר מכן מפעילים רפליקציית השלמה, והמעבר מתבצע בחלון תעבורה מינימלי עם תוכנית חזרה מוכנה.
מה עם שלמות הנתונים המצטברים?
לפני הפיצול מחשבים סכומי ביקורת לפי טבלאות ומשווים אותם לאחר ההעברה — לפי שורות, קשרים ומונים. אי-התאמה בטבלה אחת משמעה חזרה לסכימה המקורית, ולא כיוונון נוסף על מסד פעיל.
האם התאמות אישיות ותאימות לאחור יישברו?
מפתחות הניתוב מוציאים לשכבה נפרדת, כך שהקוד פונה לנתונים דרך ממשקים רגילים. מודולים וסוכנים משלנו נבדקים בנפרד: חלקם כותבים ישירות לטבלאות תוך עקיפת השכבה — מקומות כאלה נכתבים מחדש לפני ההעברה.
כיצד משתנה הגיבוי?
הגיבוי נעשה לפי מקטעים: מצלמים תמונת מצב עקבית של כל צומת ובודקים שחזור על סביבת בדיקות, ולא רק את עצם יצירת העותק. החזרה לאחור נשארת צפויה, וזמן השחזור אינו גדל יחד עם נפח מסד הנתונים.
נדון במשימה: מה נדרש להערכת פיצול נתונים
הערכת פיצול נתונים לא נעשית לפי הערכה גסה: לשרדינג אין סכימה אוניברסלית — מפתח הפיצול נבחר לפי מבנה הקטלוג ופרופיל העומס. תנו את הנתונים המקדימים לפי הרשימה שלמטה, ונחזור עם הערכת עבודה, סכימת שרדינג ותוכנית הטמעה עם חלונות הגירה.
- נפח מסד הנתונים והטבלאות המובילות בגודלן: היכן מרוכזות הזמנות, מוצרים, יומני אירועים, סטטיסטיקה;
- פרופיל עומס: שיעור קריאה וכתיבה, מרווחי שיא, אילו דוחות וייצוא מעמיסים על המערך;
- מפתח פיצול שמתאים לכם יותר לפי היגיון העסק: לפי לקוח, לפי פרויקט, לפי אזור או לפי תאריך יצירת הרשומות;
- סכימת עמידות התקלות הנוכחית: מאסטר, רפליקות, רפליקציה, גיבוי וכיצד שחזרתם בפעם האחרונה;
- מודולים ורכיבים מותאמים שניגשים ישירות למסד, כולל החלפות נתונים עם 1С;
- חלון השבתה מותר ודרישות לחזרה לאחור: תוך כמה זמן צריך להחזיר מערך אחיד;
- הרשאות גישה וסביבת בדיקות שבה אפשר להריץ סימולציית העברה בלי סיכון למערך העבודה.
את סדר העבודה נציע בעצמנו: ניתוח שאילתות ותוכניות, בחירת מפתח, סימולציית הגירה על עותק, מעבר מדורג בין צמתים, בקרה לאחר ההפעלה. תארו את המשימה וצרפו נתונים מקדימים — נדון בה לגופו של עניין ונחזור עם הערכה ותוכנית.