עם ניסיון של למעלה מ-10 שנים ויותר מ-500 המרות Elasticsearch מוצלחות, אנו מבטיחים אינדוקס מחדש ללא זמן השבתה עבור אשכולות הייצור שלכם. המומחים המוסמכים שלנו טיפלו באינדקסים של עד 500 מיליון מסמכים ללא תקלה אחת.
שיניתם מיפוי שדה בסביבת ייצור — וקיבלתם שגיאה. Elasticsearch אינו מאפשר לשנות שמות שדות, לשנות סוגים או להוסיף מנתחים לאינדקס קיים. הפתרון היחיד הוא אינדוקס מחדש, אך הוא חוסם כתיבה: תצטרכו לעצור את האפליקציה, ולאבד נתונים במהלך ההמרה. אנו פותרים זאת באמצעות אסטרטגיית כחול/ירוק עם כינויים (aliases). האפליקציה פועלת ללא זמן השבתה, והאינדוקס מחדש מתבצע ברקע. כינוי (alias) הוא שכבת הפשטה: האפליקציה כותבת וקוראת דרך הכינוי, מבלי לדעת את שם האינדקס הפיזי. האינדקס הישן נשאר זמין בזמן שהחדש מתמלא. לאחר מכן, הכינוי מוחלף בצורה אטומית — וזהו.
כיצד להשיג אינדוקס מחדש ללא זמן השבתה ב-Elasticsearch?
השוו בין שתי אסטרטגיות:
| פרמטר | כחול/ירוק עם כינוי | אינדוקס ישיר |
|---|---|---|
| זמינות כתיבה | כן (דרך הכינוי) | לא (האינדקס נעול) |
| זמן השבתה | 0 | זמן אינדוקס + אימות |
| יכולת גלגול לאחור | מיידית (החזרת הכינוי) | לא |
| מורכבות יישום | בינונית (2–3 ימים) | נמוכה (יום אחד) |
| בקרת קונפליקטים | סנכרון מצטבר | בלתי אפשרית |
כחול/ירוק עם כינוי מהיר פי 5 וחוסך אלפי דולרים בעלויות זמן השבתה פוטנציאליות.
כיצד פועלת אסטרטגיית כחול/ירוק
כינוי (alias) משמש כמצביע לאינדקס. לפי התיעוד הרשמי של Elasticsearch, כינויים מאפשרים הפשטה של האינדקס הפיזי. האפליקציה עובדת עם הכינוי products, מבלי לדעת את השם הפיזי.
שלב 1 — צרו אינדקס חדש עם המיפוי הרצוי:
PUT /products_v2
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 0,
"refresh_interval": "-1",
"analysis": {
"analyzer": {
"product_analyzer": {
"type": "custom",
"tokenizer": "standard",
"filter": ["lowercase", "russian_stemmer"]
}
}
}
},
"mappings": {
"properties": {
"id": {
"type": "keyword"
},
"title": {
"type": "text",
"analyzer": "product_analyzer",
"fields": {
"keyword": {
"type": "keyword"
}
}
},
"price": {
"type": "scaled_float",
"scaling_factor": 100
},
"new_field": {
"type": "keyword"
}
}
}
}במהלך הטעינה, השביתו רפליקות ו-refresh — זה מאיץ כתיבה בעד 80%.
הפעלת אינדוקס מחדש עם חלוקה מקבילית (slices)
התחילו אינדוקס מחדש עם PUT /products_v2 { "settings": { "number_of_shards": 3, "number_of_replicas": 0, "refresh_interval": "-1", "analysis": { "analyzer": { "product_analyzer": { "type": "custom", "tokenizer": "standard", "filter": ["lowercase", "russian_stemmer"] } } } }, "mappings": { "properties": { "id": { "type": "keyword" }, "title": { "type": "text", "analyzer": "product_analyzer", "fields": { "keyword": { "type": "keyword" } } }, "price": { "type": "scaled_float", "scaling_factor": 100 }, "new_field": { "type": "keyword" } } } } :
POST _reindex?wait_for_completion=false
{
"source": {
"index": "products_v1",
"size": 500
},
"dest": {
"index": "products_v2",
"op_type": "create"
},
"conflicts": "proceed",
"slices": "auto"
}slices: auto מחלק את המשימה למספר חלוקות כמספר השרדים באינדקס המקור. כל חלוקה רצה באופן עצמאי — השגת האצה של פי 5–10 לעומת ביצוע סדרתי.
סנכרון מצטבר
בזמן שהאינדוקס מחדש רץ, האפליקציה ממשיכה לכתוב לאינדקס הישן. כדי לתפוס נתונים חדשים, בצעו סנכרון מצטבר:
POST _reindex?wait_for_completion=false
{
"source": {
"index": "products_v1",
"query": {
"range": {
"updated_at": {
"gte": "now-1h",
"lte": "now"
}
}
}
},
"dest": {
"index": "products_v2",
"op_type": "index",
"version_type": "external"
}
}POST _reindex?wait_for_completion=false { "source": { "index": "products_v1", "size": 500 }, "dest": { "index": "products_v2", "op_type": "create" }, "conflicts": "proceed", "slices": "auto" } משתמש ב-slices: auto כדי לפתור קונפליקטים. זה דורש שדה POST _reindex?wait_for_completion=false { "source": { "index": "products_v1", "query": { "range": { "updated_at": { "gte": "now-1h", "lte": "now" } } } }, "dest": { "index": "products_v2", "op_type": "index", "version_type": "external" } } במיפוי.
כיצד להבטיח מעבר אטומי?
לאחר השלמת האינדוקס והסנכרון, הריצו:
# 1. Восстановить production настройки в новом индексе
PUT /products_v2/_settings
{
"index.number_of_replicas": 1,
"index.refresh_interval": "1s"
}
# 2. Дождаться восстановления реплик
curl -u elastic:pw "localhost:9200/_cluster/health/products_v2?wait_for_status=green&timeout=30s"
# 3. Атомарно переключить алиас
POST _aliases
{
"actions": [
{
"add": {
"index": "products_v2",
"alias": "products",
"is_write_index": true
}
},
{
"remove": {
"index": "products_v1",
"alias": "products"
}
}
]
}הפעולה היא אטומית — אין אובדן בקשות. תוכנית גלגול לאחור: הפוך את החלפת הכינוי. אל תמחקו את האינדקס הישן למשך 24–48 שעות. אם המיפוי החדש מתברר כשגוי, פשוט החזירו את הכינוי. כל הנתונים באינדקס הישן נשארים שלמים. לחלופין, שמרו גיבוי של שני האינדקסים.
מדוע חלוקה מקבילית מאיצה את התהליך באופן דרמטי?
ללא חלוקה, האינדוקס מחדש רץ בחוט יחיד. עם version_type: external, המשימה מתפצלת ל-N תת-משימות (לפי מספר השרדים במקור). באינדקס עם 5 שרדים ו-100 מיליון מסמכים, אינדוקס מחדש אורך 6 שעות ללא חלוקה וכשעה אחת איתה — האצה של פי 5–6. עומס האשכול מתחלק באופן שווה.
טרנספורמציית נתונים באמצעות Painless
אם יש צורך לשנות את מבנה המסמך (פיצול שדות, נרמול מחירים), השתמשו בסקריפט ב-_version:
POST _reindex
{
"source": {
"index": "products_v1"
},
"dest": {
"index": "products_v2"
},
"script": {
"source": """
if (ctx._source.full_name != null) {
def parts = ctx._source.full_name.splitOnToken(' ');
ctx._source.first_name = parts[0];
ctx._source.last_name = parts.length > 1 ? parts[1] : '';
ctx._source.remove('full_name');
}
if (ctx._source.price instanceof String) {
ctx._source.price = Float.parseFloat(ctx._source.price.replace(',', '.'));
}
""",
"lang": "painless"
}
} אינדוקס מחדש שלב-אחר-שלב ללא זמן השבתה
- צרו אינדקס חדש עם הגדרות מותאמות (השביתו רפליקות ו-refresh, הגדירו מנתחים).
- התחילו אינדוקס מחדש עם
updated_at— מאיץ את התהליך עד פי 10. - בצעו סנכרון מצטבר כדי לתפוס נתונים חדשים.
- שחזרו הגדרות ייצור (רפליקות, refresh_interval).
- חכו שהאשכול יגיע לסטטוס ירוק.
- החליפו את הכינוי בצורה אטומית — האינדוקס מחדש הושלם.
שלבי אינדוקס מחדש עם כינויים
| שלב | פעולה | זמן משוער |
|---|---|---|
| 1. הכנה | בדיקת מיפוי קיים, תכנון חדש | יום אחד |
| 2. יצירת אינדקס | יצירת אינדקס חדש עם הגדרות | 10 דקות |
| 3. טעינת נתונים | אינדוקס מחדש עם חלוקה: אוטומטי | 1–6 שעות (תלוי בנפח) |
| 4. סנכרון | סנכרון מצטבר | 10–30 דקות |
| 5. מעבר | החלפת כינוי אטומית | שנייה אחת |
| 6. ניטור | מעקב למשך 48 שעות לאחר ההמרה | יומיים |
מה כלול
- בדיקת מיפוי ונתונים קיימים — זיהוי שדות הדורשים שינוי, ניתוח נפחים ודפוסי גישה.
- עיצוב מיפוי חדש — תוך התחשבות במנתחים, שדות מקוננים וסוגי נתונים.
- פיתוח סקריפטי המרה — הגדרת חלוקה מקבילית, סנכרון מצטבר, סקריפטי טרנספורמציה.
- ביצוע וניטור — מעקב אחר התקדמות, מהירות, שגיאות.
- תיעוד תהליך — תיאור שלבים לשימוש עתידי.
- תמיכה לאחר ההמרה — 48 שעות ניטור לאחר המעבר.
צרו קשר כדי לפתח תוכנית המרה. קבלו ייעוץ לתרחיש שלכם ללא זמן השבתה.







