אופטימיזציה לטעינה בפרויקט Highload עם ElasticSearch

היי הבר! שמי מקסים וסילייב, אני עובד כאנליסט ומנהל פרויקטים ב-FINCH. היום ברצוני לספר לכם כיצד, באמצעות ElasticSearch, הצלחנו לעבד 15 מיליון בקשות ב-6 דקות ולייעל את העומס היומי באתר של אחד מלקוחותינו. לצערנו, נצטרך להסתדר בלי שמות, מכיוון שיש לנו NDA, אנו מקווים שתוכן הכתבה לא יסבול מכך. בוא נלך.

איך הפרויקט עובד

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

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

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

רקע קצר

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

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

למען ההבנה, מספר הפעלות השנתי ב-2017 בלבד באתר הדסקטופ עומד על 131 מיליון. בשנת 2018 - 125 מיליון. 2019 שוב 130 מיליון. הוסף עוד 100-200 מיליון מהגרסת המובייל של האתר ומהאפליקציה למובייל, ואתה יקבל מספר עצום של בקשות.

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

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

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

אז בחרנו לעצמנו באלסטיק והתכוננו למעבר.

מעבר לאלסטי

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

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

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

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

3. לאחר מכן העברנו את עיבוד העסקה. משתמשים יכולים לקנות מוצר מסוים באתר ולהשתתף בהגרלת פרסים. לאחר רכישות כאלה, אנו מעבדים כמות גדולה של נתונים, במיוחד בסופי שבוע ובחגים. לשם השוואה, אם בימים רגילים מספר הרכישות הוא איפשהו בין 1,5-2 מיליון, אז בחגים הנתון יכול להגיע ל-53 מיליון.

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

תקופתיות

כעת העדכונים מוגדרים מבוססי אירועים, בהתאם לתנאים הבאים:

1. נקודות מכירה. ברגע שנקבל נתונים ממקור חיצוני, אנו מיד מתחילים בעדכון.
2. חֲדָשׁוֹת. ברגע שעורכים ידיעה כלשהי באתר, היא נשלחת אוטומטית לאלסטיק.

כאן שוב כדאי להזכיר את היתרונות של אלסטיק. ב-Postgres, בעת שליחת בקשה, אתה צריך לחכות עד שהיא תעבד ביושר את כל הרשומות. ניתן לשלוח 10 רשומות לאלסטיק ולהתחיל לעבוד מיד, מבלי לחכות לפיזור הרשומות על פני כל ה-Shards. כמובן, ייתכן שחלק מה-Shard או Replica לא יראו את הנתונים מיד, אבל הכל יהיה זמין בקרוב מאוד.

שיטות אינטגרציה

ישנן 2 דרכים לשילוב עם Elastic:

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

הודות לממשק HTTP, אנו יכולים להשתמש בספריות המספקות יישום אסינכרוני של לקוח ה-HTTP. אנחנו יכולים לנצל את Batch ואת ה-API האסינכרוני, מה שמביא לביצועים גבוהים, שעזרו מאוד בימי הקידום הגדול (עוד על כך בהמשך)

כמה מספרים להשוואה:

• שמירת משתמשי הבאונטי של Postgres ב-20 שרשורים ללא קיבוץ: 460713 רשומות ב-42 שניות
• לקוח אלסטי + תגובתי עבור 10 שרשורים + אצווה עבור 1000 אלמנטים: 596749 רשומות תוך 11 שניות
• לקוח אלסטי + תגובתי עבור 10 חוטים + אצווה עבור 1000 אלמנטים: 23801684 ערכים תוך 4 דקות

כעת כתבנו מנהל בקשות HTTP שבונה JSON בתור Batch / לא Batch ושולח אותו דרך כל לקוח HTTP, ללא קשר לספרייה. אתה יכול גם לבחור לשלוח בקשות באופן סינכרוני או אסינכרוני.

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

קידום גדול

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

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

בתחילת 2019, החלטנו שאנחנו צריכים את ElasticSearch. במשך שנה שלמה ארגנו את עיבוד הנתונים שהתקבלו באלסטיק ואת הנפקתם ב-API של האפליקציה והאתר למובייל. כתוצאה מכך, בשנה הבאה במהלך הקמפיין, עיבדנו 15 כניסות ב-131 דקות.

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

מסקנה/מסקנות

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

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

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

⌘⌘⌘

תודה שקראת. אם החברה שלך משתמשת גם ב- ElasticSearch ויש לה מקרי יישום משלה, ספר לנו. יהיה מעניין לדעת מה שלומם של אחרים 🙂

מקור: www.habr.com