כתיבה ב-PostgreSQL ב-sublight: מארח אחד, יום אחד, 1TB

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

#1. חתך

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

"דברים של ימים עברו..."

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

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

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

• הוכרזה טבלת אב ריקה של "כותרת", שתיארה את הכל אינדקסים וטריגרים נחוצים.
• הרישום מנקודת מבטו של הלקוח נעשה בטבלת "שורש", ובשימוש פנימי טריגר ניתוב BEFORE INSERT הרשומה הוכנסה "פיזית" לסעיף הנדרש. אם עדיין לא היה דבר כזה, תפסנו חריגה ו...
• … על ידי שימוש ב CREATE TABLE ... (LIKE ... INCLUDING ...) נוצר על סמך התבנית של טבלת האב סעיף עם הגבלה על התאריך הרצויכך שכאשר נתונים מאוחזרים, הקריאה מתבצעת רק בו.

PG10: ניסיון ראשון

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

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

כפי שהתברר לאחר חפירה במדריך, הטבלה המחולקת המקורית בגרסה זו היא:

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

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

PG10: הזדמנות שנייה

אז, התחלנו לפתור את הבעיות שהתעוררו בזו אחר זו:

1. כי מעורר ו ON CONFLICT גילינו שאנחנו עדיין צריכים אותם פה ושם, אז עשינו שלב ביניים כדי לפתור אותם טבלת פרוקסי.
2. נפטר מ"ניתוב" בטריגרים - כלומר מ EXECUTE.
3. הם הוציאו את זה בנפרד טבלת תבניות עם כל האינדקסיםכך שהם אפילו לא נמצאים בטבלת ה-proxy.

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

מילוני "ניסור".

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

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

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

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

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

כתוצאה מכל מכלול האמצעים עומס המעבד ירד בכ-30%, עומס הדיסק בכ-50%:

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

#2. אבולוציה של מסדי נתונים ושחזור

אז הסתפקנו במה שיש לנו לכל יום יש קטע משלו עם נתונים. בעצם, CHECK (dt = '2018-10-12'::date) - ויש מפתח חלוקה ותנאי שרשומה תיפול לקטע מסוים.

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

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

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

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

#3. "פיזור" עומס השיא

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

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

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

setInterval(sendToDB, interval)

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

למרבה המזל, זה די קל לתקן, הוספת ריצה "אקראית". בזמן:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. אנחנו מאחסנים את מה שאנחנו צריכים

בעיית העומס הגבוה השלישית היא אין מטמון איפה הוא יכול להיות.

לדוגמה, אפשרנו לנתח במונחים של צמתי תוכנית (כל אלה Seq Scan on users), אבל מיד חושבים שהם, לרוב, אותו דבר - הם שכחו.

לא, כמובן, שום דבר לא נכתב שוב למסד הנתונים, זה מנתק את ההדק עם INSERT ... ON CONFLICT DO NOTHING. אבל הנתונים האלה עדיין מגיעים למסד הנתונים, וזה מיותר קריאה כדי לבדוק אם יש קונפליקט חייב לעשות. אופס מספר 3...

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

וזו הירידה הנלווית בעומס האחסון:

בסך הכל

"טרה-בייט ליום" פשוט נשמע מפחיד. אם אתה עושה הכל נכון, אז זה פשוט 2^40 בתים / 86400 שניות = ~12.5MB/sשאפילו ברגי IDE שולחניים החזיקו. 🙂

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

מקור: www.habr.com