אופטימיזציה בכמות גדולה של שאילתות PostgreSQL. קיריל בורוביקוב (טנזור)

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

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

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


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

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

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

כדי להבטיח שכולם יעבדו ויתפתחו כרגיל, יש לנו 10 מרכזי פיתוח ברחבי הארץ, ובהם עוד 1000 מפתחים.

אנו עובדים עם PostgreSQL מאז 2008 וצברנו כמות גדולה ממה שאנו מעבדים - נתוני לקוחות, סטטיסטיים, אנליטיים, נתונים ממערכות מידע חיצוניות - יותר מ-400TB. יש כ-250 שרתים בייצור בלבד, ובסך הכל יש כ-1000 שרתי מסד נתונים שאנחנו מפקחים עליהם.

SQL היא שפה הצהרתית. אתה לא מתאר "איך" משהו צריך לעבוד, אלא "מה" אתה רוצה להשיג. ה-DBMS יודע טוב יותר איך לעשות JOIN - איך לחבר את הטבלאות שלך, אילו תנאים להציב, מה יעבור באינדקס, מה לא...

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

אבל, למרות העובדה ש-PostgreSQL אינו מאפשר ל"חוץ" לשלוט בעצמו, הוא מאפשר באופן מושלם לראות מה קורה בתוכוכאשר אתה מפעיל את השאילתה שלך, והיכן היא נתקלת בבעיות.

באופן כללי, עם אילו בעיות קלאסיות מגיע בדרך כלל מפתח [ל-DBA]? "כאן מילאנו את הבקשה, ו הכל איטי אצלנו, הכל תלוי, משהו קורה... איזו צרות!”

הסיבות כמעט תמיד זהות:

• אלגוריתם שאילתה לא יעיל
  מפתח: "עכשיו אני נותן לו 10 טבלאות ב-SQL דרך JOIN..." - ומצפה שהתנאים שלו באורח פלא "יתירו" ביעילות והוא יקבל הכל במהירות. אבל ניסים לא קורים, וכל מערכת עם שונות כזו (10 טבלאות ב-FROM אחד) תמיד נותנת איזושהי שגיאה. [מאמר]
• סטטיסטיקה מיושנת
  נקודה זו רלוונטית מאוד ספציפית עבור PostgreSQL, כאשר "שפכת" מערך נתונים גדול על השרת, שלח בקשה, והוא "מסקס" את הטאבלט שלך. כי אתמול היו בו 10 רשומות, והיום יש 10 מיליון, אבל PostgreSQL עדיין לא מודע לזה, ואנחנו צריכים לספר את זה על זה. [מאמר]
• "תקע" משאבים
  התקנת מסד נתונים גדול ועמוס בכבדות על שרת חלש שאין לו מספיק ביצועי דיסק, זיכרון או מעבד. וזה הכל... איפשהו יש תקרת ביצועים שמעליה כבר אי אפשר לקפוץ.
• חסימה
  זו נקודה קשה, אבל הן רלוונטיות ביותר עבור שאילתות שינוי שונות (INSERT, UPDATE, DELETE) - זה נושא גדול נפרד.

מקבל תוכנית

...ולכל השאר אנחנו צריך תוכנית! אנחנו צריכים לראות מה קורה בתוך השרת.

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

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

כדי לקבל את תוכנית השאילתות, הדרך הקלה ביותר היא לבצע את ההצהרה EXPLAIN. כדי לקבל את כל התכונות האמיתיות, כלומר לבצע שאילתה על הבסיס בפועל - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

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

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

הכל נראה בסדר עכשיו, אנחנו הולכים ליומן ורואים שם... [טקסט כף רגל]. אבל אנחנו לא יכולים להגיד שום דבר על זה, מלבד העובדה שזו תוכנית מצוינת כי זה לקח 11ms לביצוע.

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

אבל גם אם זה לא ברור, גם אם זה לא נוח, יש בעיות עקרוניות יותר:

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

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

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

תכנון הדמיה

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

קודם כל עברנו "דרך השוק" - בואו נסתכל באינטרנט כדי לראות מה בכלל קיים.

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

• זמן העיבוד של הצומת עצמו
• הזמן הכולל עבור כל המשנה
• מספר הרשומות שאוחזרו שהיו צפויות סטטיסטית
• גוף הצומת עצמו

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

אבל יש גם בעיות קטנות.

ראשית, כמות עצומה של "העתק-הדבק". אתה לוקח חתיכה מהבול, תוקע אותה שם, ושוב, ושוב.

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

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

אבל זה הכל "מילים", איכשהו יכולנו לחיות עם זה, אבל יש דבר אחד שהרחיק אותנו מאוד מהשירות הזה. אלו הן שגיאות בניתוח של Common Table Expression (CTE) וצמתים דינמיים שונים כמו InitPlan/SubPlan.

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

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

לקחנו ערימה אופיינית לשירותי אינטרנט: ליבה המבוססת על Node.js + Express, עמוסה ב-Bootstrap ו-D3.js עבור דיאגרמות יפות. והציפיות שלנו היו מוצדקות לחלוטין - קיבלנו את אב הטיפוס הראשון תוך שבועיים:

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

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

זהו הייצוג המקוצר שאנו קוראים לו תבנית תוכנית.

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

אנחנו מצביעים על הצומת ורואים - מסתבר ש-Seq Scan לקח פחות מרבע מהזמן הכולל, ואת ה-3/4 הנותרים צולמו על ידי CTE Scan. חֲרָדָה! זוהי הערה קטנה לגבי "קצב האש" של CTE Scan אם אתה משתמש בהם באופן פעיל בשאילתות שלך. הם לא מהירים במיוחד - הם נחותים אפילו מסריקת שולחן רגילה. [מאמר] [מאמר]

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

באופן טבעי, היו מעורבים כמה "מגרפות".

הדבר הראשון שנתקלנו בו היה בעיית העיגול. הזמן של כל צומת בודד בתוכנית מצוין בדיוק של 1 מיקרוסופט. וכאשר מספר מחזורי הצומת עולה על, למשל, 1000 - לאחר ביצוע PostgreSQL מחולקת "בדיוק", אז כשמחשבים בחזרה נקבל את הזמן הכולל "איפשהו בין 0.95ms ל-1.05ms". כשהספירה עוברת למיקרו-שניות, זה בסדר, אבל כשזה כבר [מילי]שניות, אתה צריך לקחת את המידע הזה בחשבון כשאתה "מפרק" משאבים לצמתים של תוכנית "מי צרך כמה".

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

זה די קל לקבל סוג כזה של בעיה - אנחנו עושים CTE וכביכול קוראים בו משהו. למעשה, PostgreSQL הוא "חכם" ולא יקרא שום דבר ישירות שם. ואז ניקח ממנו את הרשומה הראשונה, ואליו את המאה והראשון מאותו CTE.

אנחנו מסתכלים על התוכנית ומבינים - זה מוזר, יש לנו 3 מאגרים (דפי נתונים) "נצרכים" ב-Seq Scan, 1 נוסף ב-CTE Scan, ועוד 2 בסריקת CTE השנייה. כלומר, אם פשוט נסכם הכל נקבל 6, אבל מהטאבלט נקרא רק 3! CTE Scan לא קורא שום דבר מכל מקום, אלא עובד ישירות עם זיכרון התהליך. כלומר, ברור שמשהו כאן לא בסדר!

למעשה, מסתבר שהנה כל אותם 3 עמודי נתונים שהתבקשו מ-Seq Scan, תחילה 1 ביקש את סריקת ה-CTE ה-1, ולאחר מכן הוקראו לו את ה-2, ועוד 2. כלומר, סך הכל 3 עמודים נקראו נתונים, לא 6.

והתמונה הזו הובילה אותנו להבנה שביצוע תכנית אינו עוד עץ, אלא פשוט איזה גרף א-ציקלי. וקיבלנו תרשים כזה, כדי שנבין "מה בא מאיפה מלכתחילה". כלומר, כאן יצרנו CTE מ-pg_class, וביקשנו אותו פעמיים, וכמעט כל הזמן שלנו הושקע בסניף כשביקשנו אותו בפעם ה-2. ברור שקריאת הערך ה-101 היא הרבה יותר יקרה מסתם קריאת הערך ה-1 מהטאבלט.

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

איחוד יומנים

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

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

ראשית, הוא מקצה לאותן שאילתות באמצעות סכמות שונות בתוך אותו מסד נתונים QueryIds שונים. כלומר, אם תעשה זאת קודם SET search_path = '01'; SELECT * FROM user LIMIT 1;ואז SET search_path = '02'; ובאותה בקשה, אז לסטטיסטיקה של מודול זה יהיו רשומות שונות, ולא אוכל לאסוף נתונים סטטיסטיים כלליים ספציפית בהקשר של פרופיל בקשה זה, מבלי לקחת בחשבון את הסכמות.

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

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

לכן, החלטנו להילחם בהעתק-הדבק והתחלנו לכתוב אספן.

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

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

בהתאם, אנו "מותחים" שני קשרים: הראשון "להקשיב" ליומן עצמו ולקחת אותו לעצמנו, והשני לשאול מעת לעת את הבסיס. "אבל היומן מראה שהסימן עם oid 123 חסום", אבל זה לא אומר כלום למפתח, וזה יהיה נחמד לשאול את מסד הנתונים, "מה זה OID = 123 בכלל?" ולכן אנחנו שואלים מדי פעם את הבסיס מה אנחנו עדיין לא יודעים על עצמנו.

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

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

אבל פשוט "לשפוך" נתונים זה לא באמת הטכנולוגיה שלנו. כי אם יש לך בערך 50 בקשות לשנייה במאה שרתים, אז זה יפיק 100-150GB של יומנים ליום. לכן, היינו צריכים בזהירות "לחתוך" את הבסיס.

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

שנית, למדנו (נאלצנו) מאוד מאוד מהיר לכתוב באמצעות COPY. כלומר, לא רק COPYכי הוא מהיר יותר מ INSERT, ואפילו מהר יותר.

הנקודה השלישית - הייתי חייבת לנטוש טריגרים, בהתאמה, ומפתחות זרים. כלומר, אין לנו כלל שלמות התייחסותית. כי אם יש לך טבלה שיש לה זוג FKs, ואתה אומר במבנה מסד הנתונים ש"הנה רשומת יומן שמפנה על ידי FK, למשל, לקבוצת רשומות", אז כשאתה מכניס אותה, PostgreSQL לא נשאר דבר מלבד איך לקחת את זה ולעשות את זה ביושר SELECT 1 FROM master_fk1_table WHERE ... עם המזהה שאתה מנסה להכניס - רק כדי לבדוק שהרשומה הזו קיימת שם, שלא "תנתק" את המפתח הזר הזה עם הכנסתך.

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

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

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

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

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

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

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

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

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

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

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

כדי להיפטר מחריגות כאלה, פשוט אל תצבור שום דבר, לא לחצץ בכלל. ואם אכן מתרחש חציצה לדיסק (למרבה המזל, ה-Stream API ב-Node.js מאפשר לך לגלות זאת) - דחו את החיבור הזה. כשתקבלו אירוע שהוא שוב בחינם, כתבו לו מהתור שנצבר. ובזמן שהוא עמוס, קח את הפנוי הבא מהבריכה וכתוב לו.

לפני שהצגנו גישה זו לרישום נתונים, היו לנו פעולות כתיבה של כ-4K, ובדרך זו הורדנו את העומס פי 4. כעת הם גדלו עוד פי 6 בגלל מסדי נתונים מנוטרים חדשים - עד 100MB/s. וכעת אנו מאחסנים יומנים ל-3 החודשים האחרונים בנפח של כ-10-15TB, בתקווה שתוך שלושה חודשים בלבד כל מפתח יוכל לפתור כל בעיה.

אנחנו מבינים את הבעיות

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

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

זיהינו שלוש נקודות מפתח:

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

כדי להבין "מי" שלח לנו בקשה, אנו משתמשים בכלי סטנדרטי - הגדרת משתנה הפעלה: SET application_name = '{bl-host}:{bl-method}'; - אנו שולחים את שם מארח ההיגיון העסקי ממנו מגיעה הבקשה, ואת שם השיטה או האפליקציה שיזמו אותה.

לאחר שעברנו את "הבעלים" של הבקשה, יש להוציא אותה ללוג - לשם כך אנו מגדירים את המשתנה log_line_prefix = ' %m [%p:%v] [%d] %r %a'. למעוניינים, אולי תסתכל במדריךמה כל זה אומר. מסתבר שאנו רואים ביומן:

• זמן
• מזהי תהליך ועסקאות
• שם בסיס הנתונים
• IP של האדם ששלח בקשה זו
• ושם השיטה

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

אז הנה הגזרה "שרת אחד - יום אחד" התברר שזה הספיק לנו לכל ניתוח.

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

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

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

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

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

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

ומיד אתה יכול לראות אפליקציות שונות שמגיעות עם אותה תבנית מתוך בקשה כמו SELECT * FROM users WHERE login = 'Vasya'. Frontend, Backend, Processing... ואתה תוהה מדוע העיבוד יקרא את המשתמש אם הוא לא יוצר איתו אינטראקציה.

הדרך ההפוכה היא לראות מיד מהאפליקציה מה היא עושה. לדוגמה, ה-frontend הוא זה, זה, זה, וזה פעם בשעה (ציר הזמן עוזר). ומיד נשאלת השאלה: נראה שזה לא התפקיד של ה-frontend לעשות משהו פעם בשעה...

לאחר זמן מה, הבנו שחסר לנו מצטבר סטטיסטיקה לפי צמתי תוכנית. בודדנו מהתוכניות רק את אותם צמתים שעושים משהו עם הנתונים של הטבלאות עצמן (קוראים/כותבים אותם לפי אינדקס או לא). למעשה, רק היבט אחד נוסף יחסית לתמונה הקודמת - כמה שיאים הצומת הזה הביא לנו?, וכמה נמחקו (שורות הוסרו על ידי מסנן).

אין לך אינדקס מתאים על הצלחת, אתה מגיש בקשה אליו, הוא עף על פני האינדקס, נופל ל-Seq Scan... סיננת את כל הרשומות מלבד אחת. למה אתה צריך 100 מיליון רשומות מסוננות ביום? האם לא עדיף להעלות את האינדקס?

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

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

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

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

מקור: www.habr.com