בוט DBA ג'ו. אנטולי סטנסלר (Postgres.ai)

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

וידאו:

שלום לכולם! שמי אנטולי סטנסלר. אני עובד בחברה postgres.ai. אנו מחויבים להאיץ את תהליך הפיתוח על ידי הסרת העיכובים הקשורים לעבודה של Postgres ממפתחים, DBAs ו-QAS.

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

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

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

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

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

זה כואב, זה יקר. כנראה שעדיף שלא.

ומה הדרך הטובה ביותר לעשות זאת?

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

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

מה הבעיות?

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

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

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

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

למי יש מסד נתונים גדול מטרה-בייט? יותר ממחצית החדר.

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

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

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

אבל הם משתמשים בגישה הזו מכיוון שהיא מאפשרת להם לשמור על התוצר אמין.

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

וזה אפשרי.

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

דוגמה אמיתית:

• DB - 4,5 טרה-בייט.

• אנחנו יכולים לקבל עותקים עצמאיים תוך 30 שניות.

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

זה נהדר. כאן אנחנו מדברים על קסם ויקום מקביל.

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

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

ישנן אפשרויות נוספות:

• lvm,

• אחסון (לדוגמה, Pure Storage).

מעבדת מסדי הנתונים שעליה אני מדבר היא מודולרית. ניתן ליישם באמצעות אפשרויות אלו. אבל לעת עתה, התמקדנו ב-OpenZFS, כי היו בעיות ספציפיות עם LVM.

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

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

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

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

כדי לפרוס מערכת כזו בבית, עליך לפתור שתי בעיות:

• הראשון הוא מקור הנתונים, מהיכן אתה תיקח אותם. אתה יכול להגדיר שכפול עם ייצור. אתה כבר יכול להשתמש בגיבויים שהגדרת, אני מקווה. WAL-E, WAL-G או ברמן. וגם אם אתה משתמש בפתרון ענן כלשהו כמו RDS או Cloud SQL, אז אתה יכול להשתמש ב-dumps לוגי. אבל בכל זאת אנחנו ממליצים לכם להשתמש בגיבויים, כי בגישה הזו תשמרו גם על המבנה הפיזי של הקבצים, מה שיאפשר לכם להתקרב אפילו יותר למדדים שהייתם רואים בהפקה על מנת לתפוס את הבעיות הקיימות.

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

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

מערכת כזו יכולה לשמש למקרים שונים.

• אלו מפתחים, DBAs לאימות שאילתה, לאופטימיזציה.

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

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

עם גישה זו:

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

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

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

• יהיה פחות refactoring. פחות באגים יסתיימו בפרוד. נחזיר אותם פחות מאוחר יותר.

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

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

כבר טוב, אבל מה עוד אפשר להאיץ?

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

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

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

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

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

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

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

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

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

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

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

חשוב לציין ש-Shared Buffer Cache מוקצה כאשר Postgres מתחיל, בהתאם לגודל שתציין בתצורה.

והמטמון השני משתמש בכל השטח הפנוי.

וכשאנחנו עושים כמה שיבוטים במכונה אחת, מסתבר שאנחנו ממלאים בהדרגה את הזיכרון. ובצורה טובה, Shared Buffer Cache הוא 25% מכמות הזיכרון הכוללת הזמינה במכשיר.

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

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

לדוגמה, אם יש לנו מטמון גדול ב-prod, אז Postgres יעדיף להשתמש באינדקס. ואם לא, אז יהיה SeqScan. ומה הטעם אם התוכניות שלנו לא היו תואמות?

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

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

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

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

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

• זה תלוי במאפיינים של המכונה עצמה.

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

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

בואו נסתכל על האופן שבו ג'ו עובר אופטימיזציה ספציפית.

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

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

B Joe יראה לך המלצות אוטומטיות על סמך התוכנית והמדדים.

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

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

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

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

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

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

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

סיפור חשוב נוסף הוא שאנחנו רוצים להציג את התוכנית בצורה יותר מובנת. יישמנו ויזואליזציה באמצעות Flame Graphs.

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

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

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

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

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

שיתוף פעולה

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

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

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

כאן אני מסיים. תודה!

שאלות

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

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

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

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

יש כמה ttl עבור כל שיבוט. בעיקרון, יש לנו ttl קבוע.

מה, אם לא סוד?

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

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

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

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

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

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

אבל ZFS זמין לכולם. DelPhix כבר מספיק, יש להם 300 לקוחות. מתוכם, ל-Fortune 100 יש 50 לקוחות, כלומר הם מכוונים לנאס"א וכו'. הגיע הזמן שכולם יקבלו את הטכנולוגיה הזו. ובגלל זה יש לנו Core בקוד פתוח. יש לנו חלק ממשק שאינו קוד פתוח. זו הפלטפורמה שנראה. אבל אנחנו רוצים שזה יהיה נגיש לכולם. אנחנו רוצים לעשות מהפכה כדי שכל הבודקים יפסיקו לנחש במחשבים ניידים. עלינו לכתוב SELECT ולראות מיד שהוא איטי. תפסיק לחכות שה-DBA יספר לך על זה. הנה המטרה העיקרית. ואני חושב שכולנו נגיע לזה. ואנחנו מייצרים את הדבר הזה לכולם. לכן ZFS, כי זה יהיה זמין בכל מקום. תודה לקהילה על פתרון בעיות ועל רישיון קוד פתוח וכו'*

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

והשאלה השנייה היא על השונות בין היציעים. נניח שיש לי כאן ZFS והכל מגניב, אבל ללקוח ב-prod אין ZFS, אלא ext4, למשל. איך במקרה הזה?

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

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

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

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

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

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

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

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

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

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

האינדקס ייווצר בכל פעם?

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

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

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

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

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

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

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

משכבות קודמות שהיו משכפולים קודמים.

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

באופן כללי, כן.

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

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

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

זה ככה. לדוגמה, נוכל לכתוב: "SELECT FROM WHERE email = to that". כלומר, לא נראה את הנתונים עצמם, אבל נוכל לראות כמה סימנים עקיפים. יש להבין זאת. אבל מצד שני, הכל שם. יש לנו ביקורת יומן, יש לנו שליטה על עמיתים אחרים שגם רואים מה המפתחים עושים. ואם מישהו ינסה לעשות את זה, אז שירות הביטחון יבוא אליו ויעבוד על הנושא הזה.

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

עכשיו יש קישור ל-Slack, כלומר אין שליח אחר, אבל אני באמת רוצה לתמוך גם בשליחים אחרים. מה אתה יכול לעשות? אתה יכול לפרוס את DB Lab בלי ג'ו, ללכת בעזרת ה- REST API או בעזרת הפלטפורמה שלנו וליצור שיבוטים ולהתחבר ל-PSQL. אבל זה יכול להיעשות אם אתה מוכן לתת למפתחים שלך גישה לנתונים, כי לא יהיה יותר מסך.

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

אז כן, אפשר לעשות את זה.

מקור: www.habr.com