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

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

למה אני צריך את זה?

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

תפגשו פשרה

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

פשרה 1: ביצועים

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

פיזור 2: עקביות

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

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

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

חילוץ 3: קריסות

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

חיבור אחד לכל עסקה?

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

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

הבטחת שליטה בפועל

כברירת מחדל, PostgreSQL מספק עקביות. זה נשלט על ידי פרמטר השרת synchronous_commit. כברירת מחדל זה במצב on, אבל יש לו שלוש אפשרויות אחרות: local, remote_write או off.

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

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

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

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

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

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

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

הגדרת PostgreSQL

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

synchronous_commit = local  
synchronous_standby_names='*'

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

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

עוד כמה מילים...

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

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

עם השינוי הקטן הזה בקובץ התצורה, נתנו למשתמשים שליטה על העקביות והביצועים שלהם.

מקור: www.habr.com