מה ולמה אנחנו עושים במאגרי מידע בקוד פתוח. אנדריי בורודין (Yandex.Cloud)

התרומה של Yandex למאגרי המידע הבאים תיבדק.

• קליקהאוס
• אודיסיאה
• התאוששות לנקודת זמן (WAL-G)
• PostgreSQL (כולל לוגים, Amcheck, heapcheck)
• גרינפלום

וידאו:

שלום עולם! שמי אנדריי בורודין. ומה שאני עושה ב-Yandex.Cloud הוא לפתח מסדי נתונים רלציוניים פתוחים למען האינטרסים של לקוחות Yandex.Cloud ו-Yandex.Cloud.

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

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

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

אילו גישות יש בעבודה על תוכנת קוד פתוח?

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

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

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

ב-Yandex.Cloud, יצרנו את ClickHouse על גבי Yandex Object Storage, כלומר על גבי אחסון בענן.

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

איך אפשר היה לעשות את זה? זו נקודה חשובה בדוח זה.

• נוכל ליישם את ClickHouse על פני MDS. MDS הוא ממשק אחסון ענן פנימי של Yandex. זה מורכב יותר מפרוטוקול S3 הנפוץ, אבל הוא מתאים יותר למכשיר בלוק. עדיף להקליט נתונים. זה דורש יותר תכנות. מתכנתים יתכנתו, זה אפילו טוב, זה מעניין.
• S3 היא גישה נפוצה יותר שהופכת את הממשק לפשוט יותר במחיר של פחות התאמה לסוגים מסוימים של עומסי עבודה.

באופן טבעי, מתוך רצון לספק פונקציונליות לכל המערכת האקולוגית של ClickHouse ולבצע את המשימה הדרושה בתוך Yandex.Cloud, החלטנו לוודא שכל קהילת ClickHouse תרוויח מכך. הטמענו את ClickHouse על S3, לא את ClickHouse על MDS. וזו עבודה רבה.

קישורים:

https://github.com/ClickHouse/ClickHouse/pull/7946 "שכבת הפשטה של ​​מערכת קבצים"
https://github.com/ClickHouse/ClickHouse/pull/8011 "שילוב של AWS SDK S3"
https://github.com/ClickHouse/ClickHouse/pull/8649 "יישום בסיס של ממשק IDisk עבור S3"
https://github.com/ClickHouse/ClickHouse/pull/8356 "שילוב של מנועי אחסון יומנים עם ממשק IDisk"
https://github.com/ClickHouse/ClickHouse/pull/8862 "תמיכה במנועי יומן עבור S3 ו-SeekableReadBuffer"
https://github.com/ClickHouse/ClickHouse/pull/9128 "תמיכה ב-Storage Stripe Log S3"
https://github.com/ClickHouse/ClickHouse/pull/9415 "תמיכה ראשונית של Storage MergeTree עבור S3"
https://github.com/ClickHouse/ClickHouse/pull/9646 "תמיכה מלאה של MergeTree עבור S3"
https://github.com/ClickHouse/ClickHouse/pull/10126 "תמוך ב- ReplicatedMergeTree מעל S3"
https://github.com/ClickHouse/ClickHouse/pull/11134 "הוסף אישורי ברירת מחדל וכותרות מותאמות אישית עבור אחסון S3"
https://github.com/ClickHouse/ClickHouse/pull/10576 "S3 עם תצורת פרוקסי דינמית"
https://github.com/ClickHouse/ClickHouse/pull/10744 "S3 עם פותר פרוקסי"

זוהי רשימת בקשות משיכה להטמעת מערכת קבצים וירטואלית ב-ClickHouse. זהו מספר רב של בקשות משיכה.

קישורים:

https://github.com/ClickHouse/ClickHouse/pull/9760 "DiskS3 Hardlinks יישום אופטימלי"
https://github.com/ClickHouse/ClickHouse/pull/11522 "לקוח HTTP S3 - הימנע מהעתקת זרם תגובה לזיכרון"
https://github.com/ClickHouse/ClickHouse/pull/11561 "הימנע מהעתקת זרם התגובה כולו לזיכרון ב-S3 HTTP
לָקוּחַ"
https://github.com/ClickHouse/ClickHouse/pull/13076 "יכולת לסמן במטמון ולהוסיף קבצים עבור דיסק S3"
https://github.com/ClickHouse/ClickHouse/pull/13459 "העבר חלקים מ-DiskLocal ל-DiskS3 במקביל"

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

קישורים:

https://github.com/ClickHouse/ClickHouse/pull/12638 "הוסף אירועי SelectedRows ו-SelectedBytes"
https://github.com/ClickHouse/ClickHouse/pull/12464 "הוסף אירועי פרופיל מבקשת S3 ל-system.events"
https://github.com/ClickHouse/ClickHouse/pull/13028 "הוסף QueryTimeMicroseconds, SelectQueryTimeMicroseconds ו-InsertQueryTimeMicroseconds"

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

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

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

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

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

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

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

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

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

https://pgconf.ru/2017/92899

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

https://pgconf.ru/media/2017/04/03/20170316H1_V.Borodin.pdf

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

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

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

https://www.pgcon.org/2019/schedule/events/1312.en.html

בשנת 2019, בכנס PgCon, הצגתי את המאגר הזה לקהילת המפתחים. עכשיו יש לנו קצת פחות מ-2 כוכבים ב-GitHub, כלומר הפרויקט חי, הפרויקט פופולרי.

ואם אתה יוצר אשכול Postgres ב-Yandex.Cloud, אז זה יהיה אשכול עם Odyssey מובנה, המוגדר מחדש בעת שינוי קנה המידה של האשכול קדימה או אחורה.

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

PgBouncer החל להתפתח מהר יותר.

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

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

ישנם גיבויים רבים וכולם שונים. כמעט לכל ספק של Postgres יש פתרון גיבוי משלו.

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

https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/

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

https://github.com/wal-g/wal-g/graphs/contributors

כעת יש עשרות רבות של מפתחים בפרויקט הזה, אבל 10 התורמים המובילים ל-WAL-G כוללים 6 Yandexoids. הבאנו לשם הרבה מהרעיונות שלנו. וכמובן, יישמנו אותם בעצמנו, בדקנו אותם בעצמנו, גלגלנו אותם לייצור בעצמנו, אנחנו משתמשים בהם בעצמנו, אנחנו בעצמנו מבינים לאן להמשיך הלאה, תוך אינטראקציה עם קהילת WAL-G הגדולה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://commitfest.postgresql.org/23/2171/

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

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

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

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

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

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

https://www.postgresql.org/message-id/flat/[מוגן בדוא"ל]

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

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

https://www.postgresql.org/message-id/flat/[מוגן בדוא"ל]

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

https://commitfest.postgresql.org/29/2667/

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

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

https://www.postgresql.org/message-id/flat/38AF687F-8F6B-48B4-AB9E-A60CFD6CC261%40enterprisedb.com#0e86a12c01d967bac04a9bf83cd337cb

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

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

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

במקומות מסוימים אפילו הגענו למסקנה שיש לנו תוצאות שגויות במערכות הניטור שלנו. לדוגמה, מערכת 1C. בעת שימוש במסד נתונים, Postgres לפעמים כותב לתוכו נתונים שהוא יכול לקרוא, אבל pg_dump לא יכול לקרוא.

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

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

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

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

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

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

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

מסד נתונים מעניין הוא Greenplum. זהו מסד נתונים מקביל ביותר המבוסס על בסיס הקוד Postgres, אותו אני מכיר היטב.

https://greenplum.org/greenplum-database-tables-compression/

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

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

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

https://github.com/greenplum-db/gpdb/commit/179feb77a034c2547021d675082aae0911be40f7

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

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

https://github.com/greenplum-db/gpdb/issues/10150

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

https://github.com/greenplum-db/gpdb/pull/10290

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

https://github.com/greenplum-db/gpdb-postgres-merge/pull/53

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

https://github.com/greenplum-db/gpdb/pull/10565

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

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

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

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

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

זה הכל. נעבור לשאלות.

פגישת שאלות

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

מערכת הגיבוי ב-WAL-G כתובה ב-Go. זה אחד הפרויקטים החדשים שעבדנו עליהם. הוא ממש רק בן 3. ומסד נתונים עוסק לעתים קרובות באמינות. וזה אומר שמסדי הנתונים די ישנים והם כתובים בדרך כלל ב-C. פרויקט Postgres התחיל לפני כ-30 שנה. אז ה-C89 הייתה הבחירה הנכונה. ופוסטגרס כתוב עליו. מסדי נתונים מודרניים יותר כגון ClickHouse נכתבים בדרך כלל ב-C++. כל פיתוח המערכת מבוסס על C ו-C++.

שאלה מהמנהל הפיננסי שלנו, האחראי על ההוצאות ב-Cloud: "מדוע Cloud מוציא כסף על תמיכה בקוד פתוח?"

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

שאלה נוספת: "האם הדרישות של משתמשים חיצוניים שחיים ב-Yandex.Cloud שונות ממשתמשים פנימיים שחיים בענן הפנימי?"

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

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

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

דיברת הרבה על המרתון. אני יודע שרצת מרתון במוסקבה. כתוצאה? עקף את החבר'ה מ-PostgreSQL?

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

אתה אומר שאין רצים בקליקהאוס?

אני יודע בוודאות שהם שם. ClickHouse הוא גם מסד נתונים. אגב, אולג כותב לי עכשיו: "שנצא לרוץ אחרי הדיווח?" זה רעיון נהדר.

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

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

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

זו שאלה מעניינת: "מאיפה להתחיל?" בדרך כלל די קשה להתחיל עם משהו בקרנל. בפוסטגרס, למשל, יש רשימת מטלות. אבל למעשה, זהו דף של מה שהם ניסו לעשות, אך לא הצליחו. אלו דברים מורכבים. ובדרך כלל אתה יכול למצוא כמה כלי עזר במערכת האקולוגית, כמה הרחבות שניתן לשפר, שמושכות פחות תשומת לב ממפתחי ליבה. ובהתאם לכך, יש שם עוד נקודות לצמיחה. בתוכנית Google Summer of code, מדי שנה קהילת postgres מציגה נושאים רבים ושונים שניתן להתייחס אליהם. השנה היו לנו, אני חושב, שלושה תלמידים. אחד אפילו כתב ב-WAL-G על נושאים שחשובים עבור Yandex. ב-Greenplum הכל פשוט יותר מאשר בקהילת Postgres, מכיוון שהאקרים של Greenplum מתייחסים לבקשות משיכה טוב מאוד ומתחילים לסקור מיד. שליחת תיקון ל-Postgres היא עניין של חודשים, אבל גרינפלום יבוא תוך יום ותראה מה עשית. דבר נוסף הוא שגרינפלום צריכה לפתור את הבעיות הנוכחיות. Greenplum אינו נמצא בשימוש נרחב, ולכן קשה למצוא את הבעיה שלך. וקודם כל, אנחנו צריכים לפתור בעיות, כמובן.

מקור: www.habr.com