אופטימיזציה של Elasticsearch: שארדים, refresh_interval, שאילתות

אופטימיזציה של Elasticsearch: היכן החיפוש נשבר תחת עומס

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

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

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

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

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

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

מה נותנת אופטימיזציה של Elasticsearch: מהירות ויציבות

זמן התגובה לשאילתה ב-Elasticsearch נקבע לא בעוצמת הצמתים, אלא בפריסת הנתונים ובתדירות רענון האינדקס.

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

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

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

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

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

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

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

מה לוקחים בשילוב

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

שלבי העבודה: מהאבחון של הקלאסטר ועד למסירת הנהלים

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

1. אבחון הקלאסטר. מסירים את גודל האינדקסים, את התפלגות השארדים בין הצמתים, את צריכת הזיכרון, התורים וזמן התגובה. קובעים מדדי בסיס לפני כל שינוי — אחרת אין במה להוכיח את התוצאה.
2. פרופיילינג שאילתות. מפרקים את הלוג האיטי ואת תוכניות הביצוע, מאתרים שאילתות עם סריקה מלאה של מסמכים ואגרגציות שמחשבות מחדש את אותם נתונים.
3. סכימת האינדקסים. בונים מחדש סכימות שדות ותבניות: מספר השארדים והעותקים, חלוקה לפי זמן, כללי מחזור חיים לנתונים ישנים.
4. כיוונון מצבי העבודה. מתאימים את מרווח רענון האינדקס לפרופיל העומס: אנליטיקה לא זקוקה לחישוב מחדש תכוף, ולחיפוש הוא קריטי.
5. בדיקה על תעבורה חיה. מריצים את השינויים על חלק מהזרם החי ומשווים זמן תגובה, שיעור כשלים וצריכת משאבים מול מדדי הבסיס.
6. תוכנית נסיגה. מכינים מראש תצלומי מצב, תבניות וסכימות שדות קודמות, וכן את התנאי שבו חוזרים לתצורה המקורית.
7. מסירת נהלים. מוסרים תיעוד על האינדקסים, לוחות ניטור והתראות, ומכשירים את הצוות לתחזק את הקלאסטר בעצמו.

ערכת המסירה: סכימות הקלאסטר, נהלים, לוחות ניטור

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

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

מקרה בוחן: החיפוש בקטלוג הפסיק ליפול בשעות השיא

מה היה צוואר הבקבוק

קטלוג של עשרות אלפי פריטים: בעומס בדיקה החיפוש החזיק מעמד בביטחון, אבל בשעות השיא בערב התגובה ירדה. האחוזון ה-99 חצה כמה שניות, חלק מהשאילתות הסתיימו בשגיאת טיימאאוט, והקלאסטר הפעיל איזון מחדש ממש תחת עומס — כשל של צומת אחד גרר אחריו את השכנים. הקניינים התלוננו שסינון המוצרים «נתקע» בדיוק כשנכנסת ההכנסה העיקרית.

מה שינו ומה זה נתן

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

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

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

ראש התחום מאשר: «החיפוש הפסיק להיות נקודת סיכון בשעות השיא, אין יותר צורך לשמור עליו ידנית».

מה לעשות אם אינדוקס מחדש אינו אפשרי כעת

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

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

דרכי עקיפה עובדות נבדלות זו מזו בעלות ובסיכון:

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

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

ספקות טכניים: סיכונים, נסיגה, תאימות גרסאות

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

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

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

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

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

האם תישמר התאימות לתצורה הנוכחית ולקוד הלקוח?

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

נדון במשימה שלכם: ממה נתחיל

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

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

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

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