אינדוקס מחדש של Elasticsearch ללא זמן השבתה באמצעות aliases

שינוי ה-mapping ב-Elasticsearch עלול לגרום לשגיאות והשבתה אם הגירת הנתונים לא מתוכננת בקפידה. אנחנו מפתחים אסטרטגיית reindexing ללא השבתה באמצעות aliases, המאפשרת לך לעדכן אינדקסים מבלי לעצור את האפליקציה שלך. הצוות שלנו מספק פתרון turnkey, עם מעבר אטומי ותמיכה מתמשכת כדי לשמור על פעילות חלקה של העסק שלך.

פיתוח ותחזוקה של כל סוגי האתרים:

אתרי מידע או יישומי אינטרנט
אתרי תדמית, דפי נחיתה, אתרי חברה, קטלוגים מקוונים, חידונים, אתרי קידום, בלוגים, מקורות חדשות, פורטלי מידע, פורומים, אגרגטורים
אתרי מסחר אלקטרוני או יישומי אינטרנט
חנויות מקוונות, פורטלי B2B, שווקים, בורסות מקוונות, אתרי קאשבק, בורסות, פלטפורמות דרופשיפינג, מנתחי מוצרים
יישומי אינטרנט לניהול תהליכים עסקיים
מערכות CRM, מערכות ERP, פורטלים ארגוניים, מערכות ניהול ייצור, מנתחי מידע
אתרי שירות אלקטרוני או יישומי אינטרנט
פלטפורמות מודעות, בתי ספר מקוונים, בתי קולנוע מקוונים, בוני אתרים, פורטלים לשירותים אלקטרוניים, פלטפורמות אירוח וידאו, פורטלים נושאיים

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
אינדוקס מחדש של Elasticsearch ללא זמן השבתה באמצעות aliases
מורכב
~2-3 ימים

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113
  • פיתוח אתר עבור SBH Partners
    פיתוח אתר עבור SBH Partners
    1201
  • פיתוח אתר עבור Red Pear
    פיתוח אתר עבור Red Pear
    619

עם ניסיון של למעלה מ-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"
  }
}

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

  1. צרו אינדקס חדש עם הגדרות מותאמות (השביתו רפליקות ו-refresh, הגדירו מנתחים).
  2. התחילו אינדוקס מחדש עם updated_at — מאיץ את התהליך עד פי 10.
  3. בצעו סנכרון מצטבר כדי לתפוס נתונים חדשים.
  4. שחזרו הגדרות ייצור (רפליקות, refresh_interval).
  5. חכו שהאשכול יגיע לסטטוס ירוק.
  6. החליפו את הכינוי בצורה אטומית — האינדוקס מחדש הושלם.

שלבי אינדוקס מחדש עם כינויים

שלב פעולה זמן משוער
1. הכנה בדיקת מיפוי קיים, תכנון חדש יום אחד
2. יצירת אינדקס יצירת אינדקס חדש עם הגדרות 10 דקות
3. טעינת נתונים אינדוקס מחדש עם חלוקה: אוטומטי 1–6 שעות (תלוי בנפח)
4. סנכרון סנכרון מצטבר 10–30 דקות
5. מעבר החלפת כינוי אטומית שנייה אחת
6. ניטור מעקב למשך 48 שעות לאחר ההמרה יומיים

מה כלול

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

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