חיפוש Sphinx עבור 1C-Bitrix: הגדרה, מורפולוגיה ואינדקס דלתא

מדוע החיפוש הסטנדרטי של ביטריקס נכשל עם קטלוג גדול?

קטלוג של 200,000 פריטים — החיפוש הסטנדרטי של ביטריקס מחזיר עמוד תוך 5 שניות, וסינון לפי מאפיינים לוקח אפילו יותר זמן. מודול החיפוש הסטנדרטי משתמש בטבלאות b_search_*, שאינן מותאמות לסינון מורכב לפי מספר מאפיינים או לחיפוש טקסט מלא עם מורפולוגיה. Sphinx פותר את שתי הבעיות: אינדוקס מצטבר, מורפולוגיה וחיפוש פאקטי. אנו מגדירים אותו במפתח מלא תוך 3–10 ימים. המנוע קורא נתונים ישירות מ-MySQL, מה שמפשט את האינטגרציה: אין צורך לכתוב מייצא — מקור הנתונים מתואר באמצעות שאילתות SQL בקובץ התצורה של Sphinx.

לדוגמה, בפרויקט מסחר אלקטרוני של חלקי רכב עם קטלוג של 350,000 פריטים, לאחר פריסת Sphinx, זמן החיפוש ירד מ-8 שניות ל-50 אלפיות השנייה, וסינון לפי 12 מאפיינים הפך למיידי. יישמנו Sphinx ביותר מ-30 פרויקטים של ביטריקס עם קטלוגים הנעים בין 10,000 ל-500,000 פריטים. אנו מבטיחים פעולה יציבה ותמיכה לאחר ההשקה. צרו קשר — נבנה את ארכיטקטורת החיפוש עבור הפרויקט שלכם.

כיצד להגדיר את מקור הנתונים עבור Sphinx?

Sphinx קורא נתונים באמצעות source — שאילתת SQL המבוצעת במהלך אינדוקס מחדש. דוגמה לתצורה עבור קטלוג מוצרים:

source bitrix_catalog {
  type = mysql
  sql_host = localhost
  sql_user = bitrix
  sql_pass = password
  sql_db = bitrix_db
  sql_port = 3306
  sql_query = \
    SELECT \
      e.ID, \
      e.IBLOCK_ID, \
      e.NAME, \
      e.DETAIL_TEXT, \
      e.CODE, \
      UNIX_TIMESTAMP(e.TIMESTAMP_X) AS updated_at \
    FROM b_iblock_element e \
    WHERE e.IBLOCK_ID IN (5, 6) \
      AND e.ACTIVE = 'Y' \
      AND e.WF_STATUS_ID = 1
  sql_attr_uint = IBLOCK_ID
  sql_attr_uint = updated_at
  sql_field_string = NAME
}

source bitrix_catalog { type = mysql sql_host = localhost sql_user = bitrix sql_pass = password sql_db = bitrix_db sql_port = 3306 sql_query = \ SELECT \ e.ID, \ e.IBLOCK_ID, \ e.NAME, \ e.DETAIL_TEXT, \ e.CODE, \ UNIX_TIMESTAMP(e.TIMESTAMP_X) AS updated_at \ FROM b_iblock_element e \ WHERE e.IBLOCK_ID IN (5, 6) \ AND e.ACTIVE = 'Y' \ AND e.WF_STATUS_ID = 1 sql_attr_uint = IBLOCK_ID sql_attr_uint = updated_at sql_field_string = NAME } מצהיר על מאפיינים מספריים לסינון, sql_attr_uint מצהיר על שדה מחרוזת לחיפוש ותצוגה. Sphinx תומך במאות מאפיינים ללא פגיעה בביצועים.

חיבור מאפייני מוצר לסינון פאקטי

לסינון פאקטי, הוסיפו מאפיינים באמצעות sql_field_string:

sql_attr_multi = uint PROPERTY_COLOR FROM query; \
    SELECT e.ID, p.VALUE_NUM \
    FROM b_iblock_element e \
    JOIN b_iblock_element_prop_s5 p ON p.IBLOCK_ELEMENT_ID = e.ID \
    WHERE e.IBLOCK_ID = 5

הטבלה sql_attr_multi מתאימה למזהה בלוק המידע 5. זו תכונה של ביטריקס: לכל בלוק מידע יש טבלת מאפיינים משלו. בפרויקטים מורכבים, אנו משלבים מספר טבלאות באמצעות UNION. ניתן גם לאינדקס מספר מאפיינים באמצעות sql_attr_multi = uint PROPERTY_COLOR FROM query; \ SELECT e.ID, p.VALUE_NUM \ FROM b_iblock_element e \ JOIN b_iblock_element_prop_s5 p ON p.IBLOCK_ELEMENT_ID = e.ID \ WHERE e.IBLOCK_ID = 5 עם תוחמים, מה שמאפשר סינון לפי מספר ערכים בו-זמנית.

כיצד להגדיר מורפולוגיה רוסית?

Sphinx תומך ברוסית באמצעות גזען מובנה. תצורת אינדקס:

index bitrix_catalog {
  source = bitrix_catalog
  path = /var/lib/manticore/bitrix_catalog
  morphology = stem_ru, stem_en
  min_word_len = 2
  charset_table = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
  min_prefix_len = 3
}

b_iblock_element_prop_s5 מאפשר חיפוש קידומת: "ноут" → "ноутбук". זה מגדיל את האינדקס, אך אנו תמיד מייעלים עבור נפח הנתונים שלכם. עבור קטלוגים גדולים (מעל 300,000 פריטים) אנו ממליצים לוותר על קידומת ולהשתמש בחיפוש אינפיקס. ההגדרה sql_attr_multi מבטיחה טיפול נכון בקירילית וחוסר רגישות לאותיות רישיות.

לקוח PHP ושאילתות מביטריקס

Sphinx משתמש בפרוטוקול MySQL, ולכן אנו ניגשים אליו באמצעות PDO:

$sphinx = new PDO('mysql:host=127.0.0.1;port=9306', '', '');
$stmt = $sphinx->prepare(
    "SELECT id, weight() as w, NAME FROM bitrix_catalog WHERE MATCH(:query) AND IBLOCK_ID = :iblock ORDER BY w DESC LIMIT :offset, :limit OPTION max_matches=1000"
);
$stmt->execute([
    ':query' => $searchQuery,
    ':iblock' => CATALOG_IBLOCK_ID,
    ':offset' => ($page - 1) * $pageSize,
    ':limit' => $pageSize,
]);
$ids = array_column($stmt->fetchAll(), 'id');

לאחר שיש לכם index bitrix_catalog { source = bitrix_catalog path = /var/lib/manticore/bitrix_catalog morphology = stem_ru, stem_en min_word_len = 2 charset_table = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F min_prefix_len = 3 } , טען נתונים מלאים באמצעות min_prefix_len = 3. זהו התבנית הסטנדרטית שאנו משתמשים בה בכל הפרויקטים. כדי להאיץ, ניתן לשמור במטמון את מזהי התוצאות למשך 5–10 דקות. עבור נפחי שאילתות גבוהים, אנו ממליצים על מאגר חיבורי PDO.

כיצד להגדיר אינדוקס דלתא לנתונים עדכניים?

אינדוקס מלא מחדש (charset_table) — עבור משימות cron ליליות. אינדקס דלתא — מאנדקס רק רשומות ששונו מאז האינדוקס האחרון. דורש שדה $sphinx = new PDO('mysql:host=127.0.0.1;port=9306', '', ''); $stmt = $sphinx->prepare( "SELECT id, weight() as w, NAME FROM bitrix_catalog WHERE MATCH(:query) AND IBLOCK_ID = :iblock ORDER BY w DESC LIMIT :offset, :limit OPTION max_matches=1000" ); $stmt->execute([ ':query' => $searchQuery, ':iblock' => CATALOG_IBLOCK_ID, ':offset' => ($page - 1) * $pageSize, ':limit' => $pageSize, ]); $ids = array_column($stmt->fetchAll(), 'id'); ומקור נפרד:

source bitrix_catalog_delta : bitrix_catalog {
    sql_query = \
        SELECT e.ID, ... \
        FROM b_iblock_element e \
        WHERE UNIX_TIMESTAMP(e.TIMESTAMP_X) > (SELECT max_doc_date FROM sph_counter WHERE id=1)
}

מיזוג: $ids. אינדוקס דלתא רץ כל 5–10 דקות באמצעות cron. אנו גם מגדירים CIBlockElement::GetList() כדי לעקוב נכון אחר זמן האינדוקס האחרון. אם cron נכשל, אינדוקס מלא מחדש רץ אוטומטית.

מדוע Sphinx ולא Elasticsearch?

Sphinx מאנדקס נתונים מ-MySQL פי 2–3 מהר יותר בשרתים עם 2 מעבדים ו-4 GB RAM. השוואה עבור קטלוג ביטריקס טיפוסי:

בחרו ב-Sphinx אם לשרת שלכם יש < 4 GB RAM והנתונים מגיעים רק מ-MySQL. Elasticsearch עדיף עבור קלאסטרים ואגרגציות בזמן אמת. ב-80% מפרויקטי הביטריקס שלנו, אנו משתמשים ב-Sphinx. למידע נוסף על Sphinx בויקיפדיה.

אילו שגיאות טיפוסיות מתרחשות בעת הגדרת Sphinx?

הנפוצה ביותר היא charset_table שגוי: אם קירילית לא מוגדרת, חיפושים אחר מילים רוסיות מחזירים תוצאות ריקות. השנייה הנפוצה היא חוסר ב-indexer --all עבור מאפיינים: סינון פאקטי מפסיק לעבוד. השלישית היא updated_at גדול מדי: עבור קטלוגים >500,000 פריטים, האינדקס גדל פי 2–3 וזמן האינדוקס עולה. בכל פרויקט, אנו מבצעים ביקורת על התצורה ומבצעים בדיקות עומס כדי לחסל בעיות אלה.

מה כלול באינטגרציה

• ניתוח מבנה הקטלוג ודרישות החיפוש
• פריסת Sphinx (Manticore) על השרת
• הגדרת מקורות נתונים (בלוקי מידע, מאפיינים, בלוקים ברמה גבוהה)
• הגדרת אינדקסים עם מורפולוגיה וחיפוש קידומת
• פיתוח שער PHP לשאילתות מביטריקס
• אינטגרציה עם רכיב הקטלוג (חיפוש פאקטי, פילטר)
• יישום אינדוקס דלתא (רעננות נתונים)
• בדיקות תחת עומס
• תיעוד והדרכת מנהלים
• אחריות ל-12 חודשים על כל העבודות

לוחות זמנים ומחירים

המחיר מחושב באופן אישי לאחר ניתוח הפרויקט שלכם. אנו מעריכים את נפח הנתונים, מורכבות הפאקטים ודרישות המהירות. הזמינו את האינטגרציה — קבלו ייעוץ על ארכיטקטורת החיפוש. מומחים מוסמכים עם ניסיון של 7+ שנים מבטיחים פעולה יציבה ותמיכה לאחר ההשקה.