תארו לעצמכם: לאחר ההשקה, סינון המוצרים לפי מאפיינים מפסיק לעבוד עקב חריגה מזמן ההמתנה, והייבוא מ-1C יוצר כפילויות בכל אלמנט. הסיבה היא תכנון שגוי של בלוקי מידע.
טעויות בשלב הזה יקרות: ארגון מחדש לאחר ההשקה עלול לדרוש העברת אלפי אלמנטים, השבתת הקטלוג למשך מספר ימים ועלויות פיתוח נוספות. איתנו תקבלו מבנה שיחזיק שנים ללא שינויים. ניסיון של 10+ שנים ב-Bitrix, מומחים מוסמכים, שותף 1C-Bitrix. תכנון נכון של מבנה בלוקי המידע של 1C-Bitrix הוא השקעה ביציבות ובביצועים של הקטלוג שלך.
טעות תכנון אופיינית: שימוש בבלוק מידע יחיד עבור כל הישויות — מוצרים, מאמרים, באנרים, ספרי עזר. הדבר מוביל לטבלת b_iblock_element_property מנופחת, לסינון איטי יותר ולבעיות מטמון. הפתרון: הפרדת תחומי נתונים לסוגי בלוקי מידע שונים.
איך לבחור את סוג המאפיין הנכון?
לכל מאפיין של info block יש סוג, והחלטה זו אינה ניתנת לשינוי ללא הגירת נתונים. להלן טבלה עם הסוגים העיקריים והמלצות:
| סוג מאפיין | מטרה | מתי להשתמש |
|---|---|---|
| מחרוזת | ערכי טקסט ללא חזרות | עבור שדות ייחודיים (מק"ט, שם) |
| מספר | ערכים מספריים לסינון לפי טווח | מחיר, משקל, הספק |
| רשימה | קבוצה קבועה של ערכים | סטטוסים, קטגוריות מידות |
| ספרייה (HL-block) | ספריות דינמיות | מותגים, מדינות, מטרו (מרובה) |
| קובץ | תמונות ומסמכים | תמונות נוספות (אם >2) |
| קישור לאלמנטים | קישורי אלמנטים | מוצרים קשורים, ערכות |
על פי תיעוד 1C-Bitrix, בחירת סוג המאפיין הנכון היא הבסיס לביצועי הקטלוג. מחרוזות ללא אינדקסים וכפילויות ב-b_iblock_element_property הן סיבה נפוצה להאטות. אינדקס הפאסט (facet index) פותר את הבעיה, אך רק עבור מאפיינים מספריים, רשימה וספרייה.
מבנה סוגי בלוקי מידע
סוג בלוק מידע הוא קיבוץ ללא משמעות טכנית, אך קריטי ליכולת הניהול. כלל: סוג בלוק מידע אחד = תחום נתונים אחד. "קטלוג", "מאמרים", "באנרים", "מדריכים" הוא קיבוץ נכון. "אתר" כסוג היחיד להכול הוא אנטי-תבנית.
עבור חנות מקוונת, מבנה סוגים אופייני:
catalog— קטלוג מוצרים ובלוקי מידע של מק״טcontent— חדשות, מאמרים, שאלות נפוצותreferences— מדריכים (משמשים כמקור למאפיינים מסוג רשימה, אם לא בלוקי HL)landing— בלוקי נחיתה, באנרים
כיצד עומק המדורים משפיע על הביצועים
מדורים (b_iblock_section) מאוחסנים בעץ המקורי של Bitrix. מגבלה מעשית: עומק קינון של יותר מ-5–6 רמות יוצר בעיות ב-breadcrumbs, בכתובות URL ידידותיות ל-SEO ובניווט.
אם העסק דורש היררכיה עמוקה יותר (למשל, חלקי חילוף לציוד: יצרן → דגם → סדרה → יחידה → חלק), שקלו להחליף את ההיררכיה במאפיינים תוך שימוש בסינון במקום ניווט לפי מדורים.
מאפיינים מרובים וביצועים
מאפיין מרובה מאחסן מספר ערכים ב-b_iblock_element_property — שורה אחת לכל ערך. 10,000 אלמנטים × מאפיין עם 5 ערכים = 50,000 שורות בטבלה רק עבור מאפיין זה. עבור מאפייני ספרייה מרובים, אינדקס ה-facet מטפל בהם כראוי, אך העומס במהלך בנייה מחדש של האינדקס גבוה יותר.
כלל: אם מאפיין ממולא לעיתים רחוקות (ממולא ב-10% מהאלמנטים), רשומות ריקות לא נשמרות, מה שמפחית את גודל הטבלה. אם מאפיין ממולא בכל האלמנטים ומשתנה לעיתים רחוקות, שקול להעביר אותו ל-HL-table נפרד דרך DataManager.
מדוע חשוב לפצל נתונים לסוגי בלוקי מידע שונים?
הפרדה נכונה לפי סוגים מונעת האטה של שאילתות בעת ערבוב נתונים הטרוגניים. לדוגמה, למוצרים ולבאנרים יש מערכי מאפיינים ותדירויות עדכון שונים. אם משלבים אותם, בעת בחירת באנרים נסרקות גם רשומות מוצרים, מה שמגביר את העומס. סוכנויות שמתעלמות מכלל זה נתקלות לעתים קרובות בזמן ביצוע מוגבר של רכיב catalog.
מקרה בוחן: תכנון בלוקי מידע עבור אגרגטור נדל"ן
פלטפורמה לפרסום נכסים למכירה ולהשכרה. פתרון התחלתי: בלוק מידע אחד "נכסים" עם 40 נכסים, כולל כתובת כמחרוזת, מחוז, מטרו.
בעיות תחת עומס:
- סינון לפי מטרו עבד כחיפוש טקסט (LIKE), לא לפי אינדקס
- ערכים כפולים: "m. Arbatskaya", "Arbatskaya", "arbatskaya" — שלוש רשומות שונות
- חיפוש ברדיוס מתחנת מטרו בלתי אפשרי ללא קואורדינטות גיאוגרפיות
סכימה לאחר ארגון מחדש:
- סוג
catalog: בלוק מידע "נכסים" + בלוק מידע "מתחמי מגורים" - בלוק HL
hl_metroעם שדות:UF_NAME,UF_LINE,UF_LAT,UF_LON— 342 רשומות במקום ערכי טקסט - בלוק HL
hl_district— מחוזות עם שיוך לעיר - מאפיינים "שטח", "קומה", "קומות" — סוג "מספר" לסינון לפי טווח
- מאפיין "מטרו" — ספרייה (HL), מרובה (מספר תחנות)
אינדקס פאסטים לאחר ארגון מחדש: נוצר תוך 3 דקות עבור 85,000 אובייקטים, סינון לפי מטרו וסוג — 0.15 שניות. הלקוח שלנו השיג שיפור של למעלה מפי 50 במהירות הסינון. זה חסך בתקציב על משאבי שרת והפחית את זמן ההמתנה של המשתמש. מידע נוסף על אינדקס פאסטים.
מה כלול בתכנון מבנה בלוק מידע
- ניתוח דומיין — רשימת ישויות וקשרים (1–2 ימים).
- תכנון סכימת מאפיינים — בחירת טיפוסים, בלוקי HL, אינדקס פאסטים (1–3 ימים).
- תכנון היררכיית סעיפים — עומק אופטימלי, החלפה במאפיינים במידת הצורך (0.5–1 יום).
- תיעוד — סכימת טבלה עבור כל בלוק מידע (0.5–1 יום).
- אישור — אישור הסכימה עם הלקוח (0.5 יום).
- אופציונלי: מימוש — פריסת מבנה, מיגרציית נתונים (החל מ-2 ימים).
| שלב | משך | תוצאה |
|---|---|---|
| ניתוח דומיין | 1-2 ימים | רשימת ישויות וקשרים |
| תכנון סכימה | 1-3 ימים | מסמך מבנה בלוק מידע |
| אישור | 0.5 יום | סכימה מאושרת |
| מימוש (אופציונלי) | החל מ-2 ימים | מבנה עובד עם מיגרציית נתונים |
לוח זמנים: מ-3 עד 10 ימי עבודה בהתאם למספר בלוקי המידע ומורכבות הדומיין. העלות מחושבת בנפרד לאחר ניתוח המפרט הטכני. קבלו ייעוץ — צרו קשר כדי לדון בפרויקט שלכם. הבטיחו אמינות: ניסיון רב-שנים, אחריות לביצועים על המבנה המתוכנן.
הזמינו את התכנון — והמערכת שלכם תפעל ללא תקלות במשך שנים. מבנה מתוכנן מפחית עלויות תחזוקה ופיתוח תכונות חדשות.