עיצוב מבנה Highload-Block ב-1C-Bitrix

עיצוב מבנה Highload-Block ב-1C-Bitrix

תארו לעצמכם: קטלוג עם 50,000 מוצרים ו-200 מאפיינים — כל פרמטר חדש מוסיף מיליוני שורות ל-b_iblock_element_property. מסד הנתונים מתחיל להאט, האינדקסים תופחים, ואינדקס הפאקטים לוקח שעות לבנייה מחדש. איך מקלים על המערכת בלי לאבד ביצועים? אנחנו רואים את הפתרון בעיצוב נכון של highload-block. זה לא סתם "ליצור טבלה" — זו משימה הנדסית שקובעת את המהירות של כל הקטלוג.

HL-block הוא מחולל של טבלאות מותאמות אישית ב-MySQL/PostgreSQL על גבי D7 ORM. טכנית, זה רשומה ב-b_highload_block, קבוצת שדות ב-b_user_field, וטבלה שנוצרת אוטומטית בשם hl_{XML_ID}. אין כאן קסם — רק דרך ליצור טבלה עם שדות מוגדרי-טיפוס דרך הממשק של ביטריקס בלי לכתוב SQL. אבל בדיוק האופן שבו המבנה הזה מעוצב קובע אם ה-HL-block יעבוד כספריית עזר מהירה או יהפוך לצוואר בקבוק.

מתי HL-block, ומתי אינפובלוק או טבלה מותאמת אישית?

HL-block מחליף אינפובלוק במקרים שבהם אין צורך בסקציות, בשדות SEO (META_TITLE, META_KEYWORDS), בתמונות תצוגה מקדימה/פירוט, ובמנגנוני פרסום מובנים. אלה ספריות עזר: מותגים, מדינות, תגיות, יחידות מידה, מאפיינים לפאקטים.

HL-block מפסיד לטבלת D7 מותאמת אישית (DataManager) כאשר:

• נדרשים אינדקסים מרוכבים (HL תומך רק באינדקסים על שדות בודדים דרך UF_*)
• נדרשים מפתחות זרים ופעולות אשד (cascade)
• סכימת הטבלה משתנה תדיר ודורשת מיגרציות

במקרים אלה עדיף ליצור מחלקה שיורשת מ-\Bitrix\Main\ORM\Data\DataManager ולנהל את הטבלה דרכה.

איך לבחור בין HL-block לטבלה מותאמת אישית?

מסקנה: השתמשו ב-HL-block אם אינדקסים מרוכבים ויחסים אינם נדרשים. אחרת — DataManager.

טיפוסי שדות ב-HL-block והמאפיינים שלהם

HL-blocks משתמשים במערכת שדות המשתמש (UF_*). הטיפוסים הזמינים:

• string / string_formatted — VARCHAR. לשמות, כותרות.
• integer — INT. למזהים מספריים, מיון.
• double — DECIMAL/FLOAT. למחירים, מקדמים.
• boolean — TINYINT(1). דגלי פעילות.
• file — מאחסן מזהה קובץ מ-b_file. לתמונות בספריות עזר.
• enumeration — מקשר ל-b_user_field_enum. לסטטוסים קבועים בתוך רשומת HL.
• datetime / date — DATETIME / DATE.
• iblock_element / iblock_section — מקשר לאלמנט אינפובלוק או לסקציה. יש להשתמש בזהירות: יוצר קישור מרומז בין HL לאינפובלוק.

הבעיה עם טיפוס השדה iblock_element ב-HL-block: כאשר אלמנט אינפובלוק נמחק, רשומת ה-HL לא מתעדכנת אוטומטית — יש צורך במטפל אירועים עבור OnAfterIBlockElementDelete.

איך לתכנן נכון אינדקסים בטבלאות HL?

כברירת מחדל, HL-block יוצר טבלה רק עם PRIMARY KEY על השדה ID. כל שאר השדות הם ללא אינדקסים. אם ה-HL-block משמש כספריית עזר לאינדקס הפאקטים של הקטלוג, בדרך כלל אין צורך באינדקסים נוספים — הפאקט עובד עם b_iblock_{ID}_index, לא ישירות עם טבלת ה-HL.

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

ALTER TABLE hl_loyalty_history ADD INDEX idx_user_id (UF_USER_ID);
ALTER TABLE hl_loyalty_history ADD INDEX idx_date (UF_DATE);

ביטריקס לא מספקת ממשק משתמש לניהול אינדקסים בטבלאות HL — רק SQL ישיר או סקריפט מיגרציה.

מקרה מהפרקטיקה שלנו: HL-block לקטלוג B2B

מפיץ מוצרי אלקטרוניקה. בקטלוג יש 2,200 מאפייני מוצר ייחודיים (פרמטרים טכניים). בתחילה — מאפייני אינפובלוק מטיפוס "מחרוזת", ALTER TABLE hl_loyalty_history ADD INDEX idx_user_id (UF_USER_ID); ALTER TABLE hl_loyalty_history ADD INDEX idx_date (UF_DATE); הכיל 8 מיליון שורות.

הפתרון: העברת מאפייני העזר ל-HL-blocks לפי תחומים:

• b_iblock_element_property — ממשקי חיבור (USB-C, HDMI וכו')
• hl_tech_connectivity — רזולוציות מסך ומטריצה
• hl_tech_resolution — תקנים (Wi-Fi 6, Bluetooth 5.2 וכו')

כל HL-block: שדות hl_tech_standard (VARCHAR 255), UF_NAME (VARCHAR 50, ייחודי), UF_XML_ID (בוליאני), UF_ACTIVE (מספר שלם). אינדקסים על UF_SORT — נוספו ידנית לחיפוש מהיר במהלך ייבוא 1C.

התוצאה: UF_XML_ID הצטמצם מ-8 מיליון ל-1.2 מיליון שורות (נשארו רק מאפיינים מספריים). אינדקס הפאקטים נבנה מחדש תוך 8 דקות במקום 45.

ניהול נתוני HL-block דרך D7

עבודה עם HL-block בקוד — דרך b_iblock_element_property ומחלקה שנוצרת דינמית:

$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getById($id)->fetch();
$entity = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlblock);
$dataClass = $entity->getDataClass();
$rows = $dataClass::getList(['filter' => ['UF_ACTIVE' => true]]);

זו תבנית סטנדרטית — חשוב לקבוע אותה בסגנון הקוד של הפרויקט כך שגישות ל-HL-block לא יתפזרו על פני תבניות בצורה של שאילתות SQL.

מה כוללת עבודת עיצוב HL-block

הזמן המשוער למחזור מלא של 10-15 HL-blocks — בין 2 ל-5 ימי עבודה. העלות מחושבת בנפרד בהתאם למורכבות תחום הנושא ולצורך במיגרציה. כדי לקבל ייעוץ והערכה לפרויקט שלכם — פשוט כתבו לנו. אנחנו שותף מוסמך של 1C-Bitrix עם ניסיון של 10+ שנים ו-50+ פרויקטים מושלמים של אופטימיזציית ביצועים. אנחנו מבטיחים שקיפות בכל שלב.

משאבים שימושיים:

• עוד על HL-blocks: תיעוד 1C-Bitrix
• תקני ORM: Bitrix D7 ORM