אופטימיזציית ריינדקס של Elasticsearch עבור 1C-Bitrix

אופטימיזציה של אינדוקס מחדש ב-Elasticsearch עבור 1C-Bitrix

בפרויקט עם קטלוג של 800,000 פריטי SKU, אינדוקס מחדש מלא של Elasticsearch מ-1C-Bitrix ארך 14 שעות. במהלך זמן זה, נצברה תור של שינויים, החיפוש החזיר תוצאות מיושנות, והיבוא מ-1C התחרה עם האינדוקס על משאבי השרת. יתר על כן, בכל רענון במהלך האינדוקס, החיפוש ננעל למילישניות, מה שגרם לעיכובים של עד 3 שניות בחנות מסחר אלקטרוני עם עומס שיא של 10,000 בקשות בדקה. המטרה שלנו הייתה לקצר את האינדוקס המלא ל-1–2 שעות עם אפס זמן השבתה בחיפוש. לאחר האופטימיזציה, עלויות תשתית השרת ירדו ב-$2,000 לחודש, והחיסכון בפרויקט החזיר את ההשקעה תוך 3 חודשים. הניסיון שלנו עם קטלוגים של עד 2 מיליון פריטים מבטיח תוצאה זו. מצב זה מוכר לרבים: ככל שהקטלוג גדול יותר, כך המנגנונים הסטנדרטיים איטיים יותר. אבל הפתרון טמון בתצורה נכונה של Elasticsearch ובאופטימיזציה של קוד האינדוקס.

מדוע האינדוקס מחדש מאט?

גורמים אופייניים לאינדוקס איטי: בקשות PUT רציפות בודדות עבור כל מסמך, רענון כפוי לאחר כל אצווה, וברירת המחדל של refresh_interval של שנייה אחת. כל רענון יוצר סגמנט Lucene חדש, אשר לאחר מכן חייב להתמזג. בקטלוג של 800k SKU, זה יוצר מאות אלפי סגמנטים קטנים, ו-Elasticsearch משקיע משאבים במיזוגם.

אסטרטגיית אינדוקס מחדש ללא זמן השבתה

הטכניקה המרכזית היא לאינדקס לתוך אינדקס חדש במקום על פני האינדקס הפעיל. האינדקס הנוכחי bitrix_catalog_v1 משרת חיפוש דרך alias bitrix_catalog. במקביל, אנו בונים את bitrix_catalog_v2. לאחר השלמת האינדוקס מחדש, אנו מעבירים את ה-alias בצורה אטומית—החיפוש עובר לאינדקס החדש ללא הפרעה.

אילו הגדרות Elasticsearch מאיצות את האינדוקס?

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

PUT /bitrix_catalog_v2/_settings
{
  "index": {
    "refresh_interval": "-1",
    "number_of_replicas": 0,
    "translog.durability": "async",
    "translog.sync_interval": "30s"
  }
}

השבתת רענון (PUT /bitrix_catalog_v2/_settings { "index": { "refresh_interval": "-1", "number_of_replicas": 0, "translog.durability": "async", "translog.sync_interval": "30s" } } ) מאיצה את האינדוקס פי 3–5 מכיוון שמסמכים לא מופיעים בחיפוש עד לרענון מפורש. השבתת רפליקות (-1) מפחיתה את עומס האשכול. שטיפת translog אסינכרונית לדיסק כל 30 שניות במקום לאחר כל פעולה. לאחר האינדוקס, אנו משחזרים הגדרות סטנדרטיות ומריצים number_of_replicas: 0 כדי לאחד סגמנטים לאחד.

כיצד לייעל את אינדוקס ה-PHP?

אנו משתמשים ב-Bulk API עם אצוות של 500 מסמכים (5–15 MB). זה מהיר פי 10–20 מבקשות בודדות. Bulk API הוא הנוהג הסטנדרטי לטעינת כמויות גדולות.

$batchSize = 500;
$bulk = [];
foreach ($products as $product) {
    $bulk[] = ['index' => ['_index' => 'bitrix_catalog_v2', '_id' => $product['ID']]];
    $bulk[] = buildDocument($product);
    if (count($bulk) >= $batchSize * 2) {
        $client->bulk(['body' => $bulk]);
        $bulk = [];
    }
}
if (!empty($bulk)) {
    $client->bulk(['body' => $bulk]);
}

אינדוקס מקבילי באמצעות תהליכים מרובים: פיצול הקטלוג לפי טווחי ID. שלושה תהליכים על אשכול של שלושה צמתים נותנים האצה לינארית. צוואר הבקבוק הוא מהירות הקריאה של MySQL.

מה משיג אינדוקס מקבילי?

שילוב של Bulk API ואינדוקס מקבילי מאיץ את האינדוקס פי 10–20 בהשוואה לבקשות רציפות בודדות. בפרויקט שלנו, האינדוקס המלא ירד מ-14 שעות לשעה ו-20 דקות.

העברת ה-Alias

לאחר האינדוקס, אנו מעבירים את ה-alias בצורה אטומית:

POST /_aliases
{
  "actions": [
    {
      "remove": {
        "index": "bitrix_catalog_v1",
        "alias": "bitrix_catalog"
      }
    },
    {
      "add": {
        "index": "bitrix_catalog_v2",
        "alias": "bitrix_catalog"
      }
    }
  ]
}

הפעולה אורכת מילישניות, והחיפוש ממשיך ללא הפרעה.

לפני לעומת אחרי אופטימיזציה

היקף השירות והתמחור

שירות האופטימיזציה המפתח-ביד שלנו מסופק בדרך כלל תוך 3–10 ימי עסקים. הוא כולל:

• ביקורת על תצורת Elasticsearch הנוכחית ואינדוקס ה-PHP
• הגדרת אינדקס ו-mapping המותאמים לשאילתות טיפוסיות
• אופטימיזציה של Bulk API ועיבוד מקבילי
• יישום של אפס זמן השבתה עם aliases
• תיעוד תחזוקה
• ייעוץ והדרכה לצוות שלך

עלות השירות נקבעת באופן אישי לאחר הביקורת. אנו מספקים הערכה מדויקת תוך 2 ימי עסקים. כתבו לנו להערכת פרויקט חינמית וקבלו תוכנית אופטימיזציה מפורטת.

תוצאה מובטחת

לצוות שלנו יש מעל 10 שנות ניסיון בפיתוח Bitrix וביצע 500+ אופטימיזציות ביצועי חיפוש עבור קטלוגים הנעים בין 10k ל-2M SKU. עבור כל פרויקט, אנו מבצעים בדיקות עומס ומבטיחים מהירות אינדוקס. Elasticsearch הוא התקן דה-פקטו עבור קטלוגים בעומס גבוה. צרו קשר כדי להעריך את הפרויקט שלכם—נכין תוכנית אופטימיזציה והצעת מחיר קבועה. הזמינו את שירות האופטימיזציה שלנו והשיגו אינדוקס מהיר פי 7+ עם אפס זמן השבתה.

ציר זמן לאופטימיזציה

משך פרויקט טיפוסי הוא 3 עד 10 ימי עסקים, תלוי במורכבות הקטלוג ובהגדרות הנוכחיות. צירי זמן מדויקים נקבעים לאחר הביקורת הראשונית. חיסכון במשאבי שרת והפחתת עלויות תשתית מחזירים לעיתים קרובות את ההשקעה תוך מספר חודשים.