שדרוג לעצלנים: כיצד PostgreSQL 12 משפר את הביצועים

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

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

אבל PostgreSQL 12 לא עוצר שם: עם תכונות חדשות ושיפורים, יישומים יעבדו טוב יותר, וכל מה שאתה צריך לעשות זה לשדרג!

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

יהיה נהדר לשדרג את PostgreSQL וליהנות מיד משיפורים משמעותיים ללא התעסקות מיותרת. לפני כמה שנים, סקרתי שדרוג מ-PostgreSQL 9.4 ל-PostgreSQL 10 וראיתי איך האפליקציה האצה הודות לשיפור המקביליות של השאילתות ב-PostgreSQL 10. והכי חשוב, כמעט שום דבר לא נדרש ממני (רק הגדר פרמטר תצורה max_parallel_workers).

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

אז איך שדרוג פשוט ל-PostgreSQL 12 יכול לשמח אותך? אני אגיד לך עכשיו.

שיפורים גדולים באינדקס

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

אנחנו פשוט משתמשים באופרטור CREATE INDEX ON some_table (some_column), ו-PostgreSQL עושה עבודה רבה כדי לשמור על האינדקס מעודכן בזמן שאנו כל הזמן מכניסים, מעדכנים ומוחקים ערכים. הכל עובד לבד, כמו בקסם.

אבל לאינדקסים של PostgreSQL יש בעיה אחת - הם הם מנופחים ותופסים שטח דיסק נוסף ומפחיתים את הביצועים של אחזור ועדכון נתונים. ב"נפיחות" אני מתכוון לשמירה לא יעילה על מבנה האינדקס. זה עשוי - או לא - קשור לטפולות האשפה שהיא מסירה לִשְׁאוֹב (תודה לפיטר גאגאן על המידע)פיטר ג'וגהגן)). נפיחות האינדקס בולטת במיוחד בעומסי עבודה שבהם האינדקס משתנה באופן אקטיבי.

PostgreSQL 12 משפר מאוד את הביצועים של אינדקסים של עץ B, וניסויים עם אמות מידה כמו TPC-C הראו שבממוצע נעשה שימוש ב-40% פחות מקום. כעת אנו מבלים פחות זמן לא רק בשמירה על אינדקסים של B-tree (כלומר, בפעולות כתיבה), אלא גם בשליפת נתונים, מכיוון שהאינדקסים הרבה יותר קטנים.

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

אסטרטגיות שדרוג מסוימות דורשות בנייה מחדש של אינדקסי B-tree כדי לנצל את היתרונות הללו (למשל. pg_upgrade לא יבנה מחדש אינדקסים באופן אוטומטי). בגרסאות קודמות של PostgreSQL, בנייה מחדש של אינדקסים גדולים בטבלאות הובילה לזמן השבתה משמעותי מכיוון שלא ניתן היה לבצע שינויים בינתיים. אבל ל-PostgreSQL 12 יש עוד תכונה מגניבה: עכשיו אתה יכול לבנות מחדש אינדקסים במקביל לפקודה ציין מחדש במקבילכדי למנוע זמן השבתה לחלוטין.

ישנם שיפורים נוספים לתשתית האינדקס ב-PostgreSQL 12. עוד משהו שהיה בו קסם - יומן כתיבה קדימה, aka WAL (יומן כתיבה קדימה). יומן כתיבה קדימה מתעד כל עסקה ב-PostgreSQL במקרה של כשל ושכפול. יישומים משתמשים בו לארכיון ו התאוששות בנקודת זמן. כמובן, יומן הכתיבה קדימה נכתב לדיסק, מה שיכול להשפיע על הביצועים.

PostgreSQL 12 הפחית את התקורה של רשומות WAL שנוצרות על ידי האינדקסים GiST, GIN ו-SP-GiST במהלך בניית האינדקס. זה מספק מספר יתרונות מוחשיים: רשומות WAL תופסות פחות מקום בדיסק, והנתונים מושמעים מהר יותר, כגון במהלך התאוששות מאסון או התאוששות בנקודת זמן. אם אתה משתמש באינדקסים כאלה באפליקציות שלך (למשל, אפליקציות גיאו-מרחביות מבוססות PostGIS משתמשות רבות באינדקס GiST), זו עוד תכונה שתשפר משמעותית את החוויה ללא כל מאמץ מצידך.

חלוקה - גדולה יותר, טובה יותר, מהירה יותר

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

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

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

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

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

עם שאילתות פשוט השתפר בהרבה

כאשר הוחל תיקון עבור ביטויי טבלה נפוצים מובנים (aka CTE, aka WITH queries), לא יכולתי לחכות לכתוב על מאמר כמה שמחים היו מפתחי אפליקציות עם PostgreSQL. זו אחת מאותן תכונות שיאיצו את היישום. אלא אם כן, כמובן, אתה משתמש ב-CTE.

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

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

יתר על כן, PostgreSQL 12 מייעל את ביצוע SQL בעצמו, מבלי שתצטרך לעשות דבר. ולמרות שכנראה לא אצטרך לבצע אופטימיזציה של שאילתות כאלה עכשיו, זה נהדר ש-PostgreSQL ממשיך לעבוד על אופטימיזציה של שאילתות.

Just-in-Time (JIT) - כעת ברירת מחדל

במערכות PostgreSQL 12 עם תמיכה Llvm הידור JIT מופעל כברירת מחדל. קודם כל, אתה מקבל תמיכה JIT עבור כמה פעולות פנימיות, ושנית, שאילתות עם ביטויים (הדוגמה הפשוטה ביותר היא x + y) ברשימות בחירה (שיש לך אחרי SELECT), אגרגטים, ביטויים עם פסקאות WHERE ואחרים יכולים להשתמש ב-JIT כדי לשפר את הביצועים.

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

מה לגבי שאר התכונות החדשות ב-PostgreSQL 12?

ל-PostgreSQL 12 יש המון תכונות חדשות ומגניבות, החל מהיכולת לבחון נתוני JSON באמצעות ביטויי מסלול סטנדרטיים של SQL/JSON ועד לאימות מרובה גורמים עם פרמטר clientcert=verify-full, יצרו עמודות ועוד הרבה יותר. מספיק לפוסט נפרד.

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

מקור: www.habr.com