מדוע הקטלוג נשבר עם גידול במספר הפריטים
קטלוג של 200 פריטים עובד מהר בכל תצורה. הבעיות מתחילות ב-5–10 אלף: עמוד הקטגוריה נטען שניות, מסננים לפי מאפיינים נופלים בגלל timeout, והייצוא מ-1С גדל עם כל סנכרון.
הסיבה כמעט תמיד אחת — תכנון ספונטני של מאפייני אינפובלוקים, כאשר מאפיינים נוספו ככל שעלו משימות, בלי מודל נתונים כולל.
תרחיש אופייני: לכל פרמטר חדש הקימו מאפיין נפרד, חלק — מרובה, חלק — מחרוזת, חלק — קישור למדריך. מופיעים כפילויות של מאפיינים — "צבע" ו"צבע מוצר", "הספק, ואט" ו"הספק (ואט)" — ולצידם מבנה קטלוג מנופח, שבו על מוצר אחד תלויים עשרות ערכים, שחציים ריקים.
שליפת מוצרים לפי אינפובלוק כזה עוברת דרך מספר רב של חיבורי טבלאות מאפיינים, וזמן התגובה גדל לא באופן ליניארי, אלא בשיעור כפול ממספר המסננים בשאילתה.
שגיאות בתכנון אינפובלוקים לעיתים רחוקות נראות כבר בהתחלה — הן מתגלות כאשר מספר הפריטים גדל פי כמה, והשיווק צריך עוד חתך מסנן. שינוי בקטלוג חי יקר יותר: צריך להעביר ערכים, לשמור כתובות עמודים ולא לאבד מיקומים בחיפוש. לכן מודל המאפיינים מתכננים מראש — עבור המגוון הנוכחי ועבור האופן שבו הוא יגדל.
מפרקים כיצד זה נסגר: איזה מבנה מאפיינים מחזיק בעומס, היכן עובר הגבול בין מאפיין למדריך וכיצד הייצוא מ-1С מפסיק לנפח טבלאות.
סכמת מאפיינים של אינפובלוקים: סוגים, קישורים, מצבי אחסון
סוגי מאפיינים והשפעתם על השליפה
מאפיין בודד נשמר בשורה אחת בטבלת הערכים הראשית — השליפה לפיו מתבצעת ישירות, ללא חיבורים intermediarיים. מאפיין מרובה מפורק לרשומות נפרדות, ובעת הצגת רשימת אלמנטים הדבר הופך ל-JOIN נוסף עבור כל מאפיין בסינון.
כלל מעשי: ריבוי מוצדק במקום שבו באמת נדרש סט ערכים (גלריה, מספר טלפונים, תגיות), ומזיק במקום שבו ההיגיון העסקי מתיר ערך אחד — "מרובה ליתר ביטחון" גורם לירידת ביצועים מרובה בקטלוגים של כמה אלפי פריטים.
קישור למדורים ולהצעות מסחר
קישור מאפיינים למדורים מאפשר להחזיק סט שונה של מאפיינים עבור קטגוריות שונות: אצל מחשבים ניידים — אלכסון וסוג מטריצה, אצל אביזרים — תאימות. בלעדיו הכרטיס מתמלא בשדות ריקים, וטפסי העריכה הופכים לבלתי קריאים עבור מנהל התוכן.
מאפיינים של הצעות מסחר יורשים מהמוצר אחרת — יש לעצב אותם כסט נפרד, אחרת סינון לפי צבע או מידה מתחיל לעבוד דרך המוצר ולא דרך ההצעה, והתוצאות נשברות.
מצבי אחסון: מתי מה מתאים
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| טבלת ערכים נפרדת | מאפיינים המוניים, סינונים ומיון תכופים | דורשת אינדקסים, גדלה באופן ליניארי עם מספר הערכים |
| סריאליזציה לשדה אחד | נתונים טכניים נדירים שאינם משתתפים בשליפה | אינה ניתנת לסינון ולמיון באמצעי הליבה |
| ספרייה (קישור לאלמנט) | ערכים חוזרים: מותג, עיר, מחבר | JOIN נוסף, נדרשת סנכרון של הספרייה |
| מאפיין של הצעת מסחר | מאפייני וריאציות: מידה, צבע | ירושה מהמוצר, היגיון הצגה נפרד |
1С-Битрикс מספק מנגנונים מוכנים לכל מצב, אך הבחירה ביניהם — זה החלטה לפי עומס, ולא לפי נוחות העורך. בפרויקטים עם קטלוג של עשרות אלפי פריטים אנו קובעים את מצב האחסון לפני תחילת המילוי: שינוי סכמה בקטלוג חי דורש מיגרציה של ערכים ואינדוקס מחדש של החיפוש.
כיצד אנו מתכננים ומטמיעים מבנה מאפיינים
תכנון מאפייני בלוקי המידע מתחיל לא ביצירת שדות חדשים, אלא במלאי של מה שכבר עובד בפרודקשן. בפרויקטים חיים מאפיינים מצטברים במשך שנים: חלקם משוכפלים, חלקם אינם בשימוש באף תבנית, וחלקם מאחסנים נתונים בפורמט ששובר את הייצוא ל-1С. כל עוד התמונה הזו לא נאספה, כל שינוי במבנה הוא סיכון להפיל את הסנכרון או לאבד תוכן.
- ביקורת בלוקי מידע. אנו ממפים: אילו בלוקי מידע קיימים, אילו מאפיינים באמת מעורבים ברכיבים, בתבניות ובסנכרון עם 1С, ואילו תלויים כנטל מת. אנו מתעדים סוגים, ריבוי, שיוך למדורים וקשרים בין מאפיינים.
- סכמת מאפיינים. אנו מתכננים מבנה יעד בהתאם לצרכי העסק: מגדירים אחידים במקום כפילויות, קודים משמעותיים למאפיינים, הפרדת שדות עבור מסננים ועבור אחסון. הסכמה מאושרת לפני תחילת העבודה — תיקונים בשלב זה זולים יותר מאשר לאחר המיגרציה.
- תוכנית מיגרציית מאפיינים. אנו מפרקים את המעבר לשלבים תוך שמירה על תפקוד האתר: היכן נדרש העברת ערכים, היכן — אינדוקס מחדש, היכן — שכפול זמני של שדות במהלך המעבר.
- הגדרת בלוקי מידע. אנו בונים את המבנה בסביבת בדיקה, מריצים את הסנכרון עם 1С, בודקים ייצוא, מסננים ומדורים. רק לאחר אימות הנתונים מעבירים לפרודקשן.
- בדיקה על נתונים אמיתיים. אנו משווים דגימות לפני ואחרי, בודקים את שלמות ההעברה ואת תקינות הקשרים בין מדורים לרכיבים.
- נהלי תחזוקה. אנו מעבירים כללים: כיצד ליצור מאפיינים חדשים, אילו סוגים מותרים, מי מאשר שינויים, כדי שהמבנה לא יתפרק שוב.
- העברת תיעוד. הסכמה, מפת המאפיינים והנהלים נשארים בידי צוות הלקוח — תיקונים עתידיים מבוצעים ללא ארכיאולוגיה בקוד.
סדר זה מסיר את הסיכון העיקרי — אובדן נתונים בעת בנייה מחדש של המבנה. תארו את המשימה: נחזור עם הערכה ותוכנית לפרויקט שלכם.
במה שונה מאפיין אינפובלוק ממאפיין הצעת מסחר?
מאפיין אינפובלוק הוא תכונה של המוצר עצמו: מק"ט, מותג, ארץ ייצור, הרכב. מאפיין הצעת מסחר הוא מה שמבדיל בין וריאנטים של אותה עמדה: צבע, מידה, נפח, הרכב. ההבדל בין מאפיינים לתכונות מתגלה ברגע שהקונה בוחר וריאנט מסוים: מאפיינים מתארים את הכרטיס כולו, תכונות — כל הצעת מסחר בתוכו. אם תוציאו את הצבע למאפיין של המוצר, תקבלו כרטיס נפרד לכל גוון, והקטלוג יתנפח פי כמה.
הקריטריון המרכזי — לפי איזה סימן הקונה בוחר ומסנן. סימן שמצמצם את הבחירה בתוך דגם אחד עובר להצעת מסחר. סימן שמתאר את המוצר עצמו וזהה לכל הווריאנטים שלו נשאר מאפיין אינפובלוק.
טעות בתכנון מאפייני אינפובלוק עולה ביוקר: פיצול שגוי מוביל לכפילות כרטיסים, שובר ייצוא רציף של תכונות ל-1С ומאלץ לכתוב מחדש את המסננים.
סינון לפי מאפיינים ולפי תכונות עובד אחרת. מאפיין אינפובלוק מסונן ישירות לפי מוצרים, תכונה — דרך הצעות מסחר, ומסנן חכם צריך לדעת לאסוף ערכים משני הרמות. אם הצבע נמצא במאפיין, והמידה — בתכונה, מסנן "צבע + מידה" יחזיר תוצאות ריקות עד שהלוגיקה תרוכז לשאילתה אחת על שני אינפובלוקים.
כאב נפרד — סנכרון עם 1С. תכונות של הצעות מסחר מיוצאות ממאגר הנומנקלטורה אחרת מאשר מאפייני מוצרים: יש להן מבנה משלהן, הצעות מסחר משלהן וכללי התאמה משלהם. כשסימן נשאר בטעות כמאפיין, ייצוא התכונות מגיע ריק או משוכפל, והמנהלים מתקנים את הקטלוג ידנית אחרי כל סנכרון.
כלל מעשי: קודם מדגמים על הנייר לפי איזה סימן יהיה הבחירה והסינון, אחר כך מפרקים לרמות. אנחנו מתכננים את המבנה כך שהמסננים, הייצואים והסנכרון עם 1С יעבדו בלי תיקונים ידניים.
מקרה בוחן: ארגון מחדש של מאפייני הקטלוג ללא עצירת המכירות
קטלוג בן 40,000 פריטים התנהל על סכמה "שטוחה": יותר מ-60 מאפיינים בבלוק מידע אחד, חלק מהמאפיינים שוכפלו בהצעות מסחריות, וחלק — בתיאור המוצר כטקסט. סינון לפי שלושה פרמטרים הניב תוצאות בתוך 4-6 שניות, והמנהלים הוסיפו פריטים חדשים עם סימון שונה — ומכאן פערים במאפיינים של מוצרים זהים. לא ניתן היה לעצור את החנות לצורך אינדוקס מחדש: חלק ההזמנות מהאתר בעונת השיא גבוה מדי.
פיצלנו את הקטלוג לבלוקי מידע מקושרים: מוצר בסיסי, הצעות מסחריות ומדריך מאפיינים נפרד עם המאפיינים שלו. הכפילויות אוחדו למדריך, ובכרטיס המוצר השארנו רק את המאפיינים שמשתתפים בסינון ובייצוא.
את הגירת המאפיינים ללא השבתה ביצענו בארבעה שלבים: הכנו מבנה חדש לצד הישן, העברנו נתונים במנות עם תיעוד פערים, החלפנו תבניות ורכיבי סינון, ולאחר מכן הסרנו מאפיינים מיושנים. כל שלב היה ניתן לחזרה: עד שהסכמה החדשה עברה בדיקת התאמה, התעבורה פנתה לתבניות הקודמות.
תוצאות לפי מדדים: שליפת הסינון הצטמצמה מ-4-6 שניות ל-0.8-1.2, שיעור כפילויות המאפיינים ירד בכ-70%, וזמן הוספת פריט חדש על ידי מנהל הצטמצם בחצי — חלק מהשדות נמשכים מהמדריך.
ארגון מחדש של בלוקי המידע השפיע גם על החלפה עם 1С: הייצוא הפך לצפוי, משום שהתאמת המאפיינים מתבצעת כעת לפי קודים יציבים ולא לפי שמות.
עבדנו על הליבה הסטנדרטית של הפלטפורמה ועל מנגנוני המטמון שלה — ללא תוספות צד שלישי שהיה צריך לתחזק בנפרד. 1С-Битрикс מספקת לכך כלים מוכנים: בלוקי מידע מקושרים, מטמון מנוהל וסוכנים מדורגים, ובהם סגרנו את הארגון מחדש.
אם הקטלוג שלכם גדל, והסינון והייצוא מאטים — תארו את המשימה, ונחזור עם הערכה ותוכנית לארגון מחדש של המאפיינים.
תאימות, שחזור והרשאות: מה יש לדון לפני ההתחלה
תאימות מאפיינים של בלוקי מידע (infoblocks) עם תוכן קיים היא הסיכון העיקרי בתכנון: מאפיינים מותאמים אישית חדשים לא צריכים לשבור תבניות פלט קיימות, מסננים וסנכרון עם 1С.
לכן לפני ההתחלה אנו מקבעים אילו מאפיינים כבר משמשים בשליפות, אילו נכנסים לייצוא, ואילו ניתן להוסיף ללא שינויים בחלק הציבורי. אם מאפיין משתתף בסנכרון, אנו בודקים את המיפוי בצד 1С ואת סדר הסנכרון — אחרת לאחר הסנכרון הראשון הערכים יימחקו.
מה אם יהיה צורך להחזיר הכל כפי שהיה? שחזור שינויים מתוכנן מראש: לפני העריכות אנו יוצרים גיבוי (dump) של בלוק המידע ומבנה המאפיינים, מבצעים את השינויים בשלבים נפרדים כך שכל אחד ניתן לביטול ממוקד, ללא שחזור כל האתר.
ההרשאות לבלוקי מידע מופרדות לפי תפקידים — מנהל תוכן, אינטגרטור, מנהל מערכת — עם יומן פעולות, כדי שעריכות במבנה לא יאבדו ויהיו ניתנות למעקב.
כיצד מועברת סכמת המאפיינים ומה עושים איתה בהמשך?
את הסכמה אנו מוסרים בצורת טבלה: קוד המאפיין, סוג, ריבוי, שיוך למדורים, השתתפות בסנכרון ובמסננים. לפיה המפתח או מנהל התוכן שלכם יוכל להוסיף מאפיין באופן עצמאי, מבלי לשבור את לוגיקת הפלט. התיעוד של המאפיינים מגיע יחד עם הגדרות ההרשאות והוראות השחזור — זה מספיק להעברת הפרויקט לצוות אחר.
בסיום הלקוח מקבל:
- מפת תאימות של מאפייני בלוקי המידע עם התבניות הנוכחיות והסנכרון;
- סכמת מאפיינים מותאמים אישית עם קודים, סוגים וייעוד;
- תקנון הרשאות לבלוקי מידע לפי תפקידים;
- הוראות לשחזור שינויים ונקודות שמירה;
- תיעוד מאפיינים עבור מנהלי תוכן;
- פרוטוקול בדיקת סנכרון עם 1С לאחר העריכות.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה לפרויקט שלכם.
לוחות זמנים של שלבי יישום סכימת המאפיינים החדשה
לוחות הזמנים אינם תלויים בנפח הקוד, אלא במספר בלוקי המידע (infoblocks), בקשרים ביניהם ובמידת הפעילות שבה מנהלי התוכן עורכים נתונים בזמן המיגרציה. להלן קו מנחה לפרויקט טיפוסי: קטלוג עם הצעות מסחריות, מספר מדורי תוכן ואינטגרציה אחת עם מערכת הנה"ח.
עבור פורטלים גדולים עם עשרות בלוקי מידע ומלאי מחסן, הטווחים זזים ימינה באופן פרופורציונלי למספר הישויות.
| שלב | מה קורה | לוח זמנים משוער |
|---|---|---|
| ביקורת הסכימה הנוכחית | מלאי של בלוקי מידע, מאפיינים, קישורים למדורים ולהצעות מסחריות, איתור כפילויות ושדות שאינם בשימוש | 3–5 ימי עבודה |
| תכנון המאפיינים | תיאום סוגים, ריבוי, קישור למדורים, כללי ירושה ותבניות פלט | 4–7 ימי עבודה |
| מיגרציה והעברת נתונים | סקריפטים להעברת ערכים, התאמה בין קודי מאפיינים ישנים לחדשים, הרצה על עותק | 5–10 ימי עבודה |
| בדיקה וחזרה לאחור | השוואת דגימות, בדיקות מסננים ומסנן חכם, בקרת ייצוא למנוע החיפוש, חזרה על החזרה לסכימה הישנה | 3–5 ימי עבודה |
| מסירה והדרכה | תיעוד הסכימה, נוהל להוספת מאפיינים, הוראות למנהלי התוכן | 2–3 ימי עבודה |
משך הביקורת קובע ישירות כמה זמן יידרש למיגרציה: אם בשלב זה מתגלים מאפייני כפילות ושדות שאינם מוצגים בשום מקום, התכנון מקצר מיד את נפח הנתונים המועברים.
את לוח הזמנים לעבודות על בלוקי המידע בונים כך שהמיגרציה תתבצע בגושים — תחילה הקטלוג, אחר כך התוכן, ולאחר מכן ייצוא האינטגרציה — וכל גוש ניתן לבדוק בנפרד, מבלי לעצור את האתר כולו.
לוחות הזמנים המצוינים הם משוערים ואינם קשורים לתאריכים קלנדריים: הם מחושבים מחדש לאחר הביקורת, כאשר נראה הנפח האמיתי של הישויות ואיכות הנתונים הנוכחיים. אם חלק מבלוקי המידע כבר מתוארים כראוי, השלבים המתאימים עוברים מהר יותר.