האצת חיפוש 1C-Bitrix: מדריך אופטימיזציה של אינדוקס

מתי החיפוש הסטנדרטי של 1C-Bitrix מתחיל להאט?

החיפוש המובנה ב-1C-Bitrix משתמש בטבלאות b_search_content, b_search_content_stem ו-b_search_stem. עבור קטלוג של 30,000 פריטים, אינדוקס מחדש מלא אורך 4–12 שעות, הסוכן CSearchIndex::IndexAgent רץ ברציפות, ואיכות החיפוש נשארת נמוכה: גזירת שורשים נכשלת עם מורפולוגיה רוסית, הרלוונטיות לא מתחשבת במכירות. הניסיון שלנו מראה כי כוונון נכון מפחית את זמן האינדוקס ב-50–80% ומשפר את דיוק התוצאות ב-30–40%. אנו עובדים עם Bitrix למעלה מ-10 שנים ומבטיחים תוצאות. הבעיה מחמירה כאשר מודולים מרובים פעילים באתר—כל מודול נוסף מוסיף 15–20% לגודל טבלת האינדוקס. תרחיש טיפוסי: מנהל מפעיל חיפוש עבור פורומים, בלוגים ומסמכים, למרות שמשתמשים צריכים רק את קטלוג המוצרים. האינדוקס מתנפח, השאילתות מואטות, והסוכן לא מצליח לעמוד בקצב השינויים.

אבחון אינדוקס נוכחי

ראשית, אנו בודקים את מצב טבלאות האינדוקס:

SELECT table_name,
       ROUND(data_length / 1024 / 1024, 2) AS data_mb,
       ROUND(index_length / 1024 / 1024, 2) AS index_mb,
       table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
  AND table_name LIKE 'b_search%'
ORDER BY data_length DESC;

טבלת SELECT table_name, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb, table_rows FROM information_schema.TABLES WHERE table_schema = DATABASE() AND table_name LIKE 'b_search%' ORDER BY data_length DESC; בפורטל גדול יכולה לתפוס 2–5 GB. b_search_content_stem עבורה חוסם שאילתות לשעות—אנו עושים זאת רק בחלון תחזוקה.

כיצד להגדיר פרמטרי אינדוקס?

בממשק הניהול (הגדרות → חיפוש → הגדרות), אנו משנים פרמטרים מרכזיים:

1. אורך מילה מינימלי — הגדלה מ-2 ל-3–4. מילים בנות שתי אותיות מעמיסות על האינדוקס ואין להן ערך חיפוש.
2. מילות עצירה — הוספת מילות יחס, חיבורים, מאמרים. עבור אתר בשפה הרוסית, הרשימה הבסיסית כוללת 50–80 מילים.
3. מודולים באינדוקס — השבתת מודולים שחיפושם אינו נחוץ למשתמשים (פורומים, בלוגים, ניהול מסמכים).
4. מספר פריטים לכל ריצת סוכן — אופטימלית 50–100.

// В настройках модуля поиска или через агент CSearch::ReIndex($moduleId, $start, $finish, $step = 50); 

אינדוקס מצטבר לעומת מלא

אינדוקס מחדש מלא (OPTIMIZE TABLE) מיועד רק להגדרה ראשונית או לאחר שינויים מבניים גדולים בקטלוג. בפעולה רגילה, אינדוקס מצטבר דרך סוכן אמור לעבוד. בעיה: הסוכן // В настройках модуля поиска или через агент CSearch::ReIndex($moduleId, $start, $finish, $step = 50); מופעל על כל שינוי ב-ReIndexAll. במהלך סנכרון עם 1C, התאריך משתנה גם אם התוכן לא—הסוכן למעשה מבצע אינדוקס מחדש של כל הקטלוג בכל פעם. פתרון: השוואת hash של שדות משמעותיים לפני ואחרי עדכון. עדכון CSearchIndex::IndexAgent רק על שינוי בפועל:

$oldHash = md5($oldElement['NAME'] . $oldElement['DETAIL_TEXT'] . implode(',', $oldProperties));
$newHash = md5($newElement['NAME'] . $newElement['DETAIL_TEXT'] . implode(',', $newProperties));
if ($oldHash !== $newHash) {
    // Обновляем с изменением DATE_CHANGE
} else {
    // Обновляем остатки/цены без триггера переиндексации
    $DB->Query("UPDATE b_iblock_element SET TIMESTAMP_X = TIMESTAMP_X WHERE ID = {$id}");
}

MySQL FULLTEXT לעומת Elasticsearch: מה לבחור?

אם הקטלוג שלך כולל עד 30,000 פריטים ואתה צריך חיפוש פשוט, אופטימיזציה של FULLTEXT מספיקה. עבור 50,000+ ומסננים מורכבים, עדיף להשתמש ב-Elasticsearch.

ניקוי רשומות אינדוקס מיושנות

באתרים חיים, DATE_CHANGE צוברת רשומות של פריטים שנמחקו. אנו מנקים בקבוצות של 1000 דרך סוכן או cron—לעולם לא מריצים DELETE יחיד על 100,000 בסביבת ייצור:

-- Найти записи удалённых элементов инфоблока
SELECT sc.ID, sc.PARAM1, sc.PARAM2
FROM b_search_content sc
LEFT JOIN b_iblock_element ie ON ie.ID = CAST(sc.PARAM1 AS UNSIGNED)
WHERE sc.MODULE_ID = 'iblock' AND ie.ID IS NULL
LIMIT 10000;

מה כולל אופטימיזציית חיפוש?

• אבחון אינדוקסים נוכחיים והגדרות מודול החיפוש
• הגדרת מילות עצירה, אורך מילה מינימלי, הרחקת מודולים מיותרים
• אופטימיזציה של סוכן האינדוקס המצטבר (hash של שדות)
• כוונון MySQL FULLTEXT (my.cnf: innodb_ft_min_token_size, טבלת מילות עצירה)
• ניקוי זבל מאינדוקסים
• ניטור שאילתות עם אפס תוצאות (b_search_log)
• תיעוד עם המלצות ונהלי תמיכה

ניטור איכות חיפוש

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

מקרה בוחן: הפחתה פי 4 בזמן אינדוקס

לקוח — חנות מקוונת לחלקי רכב (40,000 פריטים). אינדוקס מלא ארך 8 שעות, הסוכן שמר על עומס CPU של 70–90%. לאחר הגדרת אינדוקס מצטבר עם hashing ואופטימיזציה של FULLTEXT, זמן הסריקה המלאה ירד לשעתיים, עומס CPU ל-15–20%. איכות החיפוש השתפרה: שאילתות עם אפס תוצאות ירדו ב-35%. חיסכון תקציבי במשאבי ענן הסתכם בכ-400,000 RUB לשנה.

טעויות נפוצות בהגדרת חיפוש

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

תוצאה

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