HighLoad++, מיכאיל טיולנב (MongoDB): עקביות סיבתית: מהתיאוריה לפרקטיקה

כנס HighLoad++ הבא יתקיים ב-6 וב-7 באפריל 2020 בסנט פטרסבורג.
פרטים וכרטיסים по ссылке. HighLoad++ סיביר 2019. אולם "קרסנויארסק". 25 ביוני, 12:00. תזות ו הצגה.

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

מיכאיל טיולנב (להלן MT): – אני אדבר על עקביות סיבתית - זו תכונה שעבדנו עליה ב- MongoDB. אני עובד בקבוצה של מערכות מבוזרות, עשינו את זה לפני כשנתיים.

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

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

עקביות סיבתית. בואו נגדיר את המושגים

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

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

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

מודלים עקביות

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

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

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

דגם חזק

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

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

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

סיבתי

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

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

בסופו של דבר

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

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

אני רוצה לתת כמה דוגמאות השוואתיות:

מה המשמעות של החצים האלה?

• חֶבִיוֹן. ככל שעוצמת העקביות גדלה, היא נעשית גדולה יותר מסיבות ברורות: עליך לבצע רשומות נוספות, לקבל אישור מכל המארחים והצמתים המשתתפים באשכול שהנתונים כבר נמצאים שם. בהתאם לכך, ל-Eventual Consistency יש את התשובה המהירה ביותר, כי שם, ככלל, אתה אפילו יכול לחייב אותה לזיכרון וזה יספיק, באופן עקרוני.
• זמינות. אם אנו מבינים זאת כיכולת של המערכת להגיב בנוכחות הפסקות רשת, מחיצות או תקלה כלשהי, סובלנות התקלות עולה ככל שמודל העקביות פוחת, שכן מספיק לנו שמארח אחד יחיה ובאותו הזמן. הזמן מייצר נתונים מסוימים. עקביות בסופו של דבר לא מבטיחה שום דבר לגבי הנתונים בכלל - זה יכול להיות כל דבר.
• חריגות. במקביל, כמובן, מספר החריגות עולה. בעקביות חזקה הם כמעט לא צריכים להתקיים בכלל, אבל בעקביות בסופו של דבר הם יכולים להיות כל דבר. נשאלת השאלה: מדוע אנשים בוחרים בעקביות בסופו של דבר אם היא מכילה חריגות? התשובה היא שמודלים של עקביות בסופו של דבר ישימים וחריגות קיימות, למשל, בפרק זמן קצר; אפשר להשתמש באשף כדי לקרוא ופחות או יותר לקרוא נתונים עקביים; לעתים קרובות ניתן להשתמש במודלים של עקביות חזקים. בפועל זה עובד, ולעתים קרובות מספר החריגות מוגבל בזמן.

משפט CAP

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

משפט ה-CAP הוא עיקרון שנוסח בשנות ה-2000 לפיו עקביות, זמינות, מחיצות: קח כל שתיים, ואי אפשר לבחור שלוש. זה היה עיקרון מסוים. זה הוכח כמשפט כמה שנים מאוחר יותר על ידי גילברט ולינץ'. ואז זה התחיל לשמש כמנטרה - מערכות החלו להתחלק ל-CA, CP, AP וכן הלאה.

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

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

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

עקביות סיבתית היא המודל החזק ביותר

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

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

מטבח פנימי של MongoDB

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

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

Sharding ב- MongoDB (לא מסד נתונים רלציוני) מבצע איזון אוטומטי, כלומר כל אוסף מסמכים (או "טבלה" במונחים של נתונים רלציוניים) מחולק לחתיכות, והשרת מעביר אותם אוטומטית בין רסיסים.

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

נקודה חשובה נוספת: MongoDB הוא מאסטר יחיד. יש Primary אחד - הוא יכול לקחת רשומות שתומכות במפתחות שהוא מכיל. אתה לא יכול לכתוב Multi-Master.

עשינו גרסה 4.2 - דברים מעניינים חדשים הופיעו שם. במיוחד, הם הכניסו את Lucene - חיפוש - כלומר java להפעלה ישירות למונגו, ושם התאפשר לבצע חיפושים דרך Lucene, כמו ב- Elastica.

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

מרכיבים עקביות סיבתית

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

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

הגבלות

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

• ראשית, "MongoDB" הוא מאסטר יחיד, כפי שכבר אמרתי (זה מאוד מפשט).
• אנו מאמינים שהמערכת צריכה לתמוך בכ-10 אלף רסיסים. אנחנו לא יכולים לקבל החלטות אדריכליות שיגבילו במפורש את הערך הזה.
• יש לנו ענן, אבל אנחנו מניחים שלאדם עדיין צריכה להיות ההזדמנות כאשר הוא מוריד בינארי, מריץ אותו על המחשב הנייד שלו, והכל עובד מצוין.
• אנחנו מניחים משהו שמחקר מניח רק לעתים רחוקות: לקוחות חיצוניים יכולים לעשות מה שהם רוצים. MongoDB הוא קוד פתוח. בהתאם לכך, לקוחות יכולים להיות כל כך חכמים וכועסים - הם יכולים לרצות לשבור הכל. אנו משערים שמקורם של פיילורים ביזנטיים.
• עבור לקוחות חיצוניים שנמצאים מחוץ לתחום, ישנה מגבלה חשובה: אם תכונה זו מושבתת, אין להבחין בירידה בביצועים.
• נקודה נוספת היא בדרך כלל אנטי-אקדמית: התאימות של גרסאות קודמות ועתידיות. מנהלי התקנים ישנים חייבים לתמוך בעדכונים חדשים, ומסד הנתונים חייב לתמוך במנהלי התקנים ישנים.

באופן כללי, כל זה מטיל מגבלות.

מרכיבי עקביות סיבתית

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

מעקב תלות מלא

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

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

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

מעקב תלות מפורש

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

היא רואה שרשומה 5 תלויה ברשומות 1, 2, 3, 4 - בהתאם, היא ממתינה לפני שתהיה ללקוח גישה לשינויים שנעשו בהחלטת הגישה של פני, כאשר כל השינויים הקודמים כבר עברו במסד הנתונים.

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

שעון למפורט

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

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

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

אתה רואה כיצד זמן המונה בפיד עולה באופן הגיוני:

אז המאפיין העיקרי של שעון Lamport ועקביות סיבתית זה (המוסבר באמצעות Lamport Clock) הוא זה: אם יש לנו אירועים A ו-B, ואירוע B תלוי באירוע A*, אז נובע שהזמן הלוגי של אירוע A קטן מ- LogicalTime מאירוע ב'.

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

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

שעון וקטור

הפיתוח ההגיוני של שעון למפורט הוא השעון הווקטורי. הם שונים בכך שכל צומת שנמצא כאן מכיל שעון נפרד משלו, והוא מועבר כווקטור.
במקרה זה, אתה רואה שהאינדקס האפסי של הווקטור אחראי על Feed, והאינדקס הראשון של הווקטור הוא עבור Friends (כל אחד מהצמתים הללו). ועכשיו הם יגדלו: מדד האפס של "פיד" גדל בעת כתיבה - 1, 2, 3:

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

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

Spanner TrueTime. שעון אטומי

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

מה הרעיון? "Spanner" היא מערכת גוגל שלאחרונה אפילו הפכה זמינה לאנשים (הם הוסיפו לה SQL). לכל עסקה שם יש חותמת זמן מסוימת. מכיוון שהזמן מסונכרן*, ניתן להקצות לכל אירוע זמן מסוים - לשעונים האטומיים יש זמן המתנה, שלאחריו מובטח זמן אחר שיקרה.

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

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

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

שעון היברידי

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

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

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

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

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

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

סנכרון שעון

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

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

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

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

איך הכל עובד ביחד?

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

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

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

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

הערך שכבר נכתב ל-"Oplog" מוחזר - אנחנו יודעים שה-"Oplog" כבר מכיל את הערך הזה, והזמן שלו הוא 12. עכשיו, נניח, הקריאה מתחילה מצומת אחר (Secondary), והוא משדר AfterClusterTime ב- ההודעה. הוא אומר: "אני צריך את כל מה שקרה לפחות אחרי 12 או במהלך שתים עשרה" (ראה תמונה למעלה).

זה מה שנקרא Causal a עקבי (CAT). יש מושג כזה בתיאוריה שזהו פרוסת זמן כלשהי, שהיא עקבית בפני עצמה. במקרה זה, אנו יכולים לומר שזהו מצב המערכת שנצפה בזמן 12.

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

זה פחות או יותר איך הכל עובד. כִּמעַט.

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

למה "מינוס אחד"? מכיוון שהשעון הפנימי יוחלף בערך הזה (כמובן שזה הכי גדול שאפשר וגדול מהשעה הנוכחית), אז תתרחש ערך ב"אופלוג", והשעון יוגדל ביחידה אחרת - וכבר תהיה להיות ערך מקסימלי (פשוט יש את כל היחידות, אין לאן ללכת) , unsaint ints).

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

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

הדרך שלנו היא לחתום על clusterTime

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

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

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

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

עשה את זה מהר!

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

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

מה למדנו?

לקחים שלמדנו מזה:

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

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

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

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

אני אסיים עם זה. תודה!

שאלות

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

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

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

MT: - קל מאוד לסנכרון. Shard, כאשר afterClusterTime מגיע אליו והוא לא מוצא זמן ב"Oplog", לא יוזם שום אישור. כלומר, הוא מעלה את זמנו בידיים לערך הזה. המשמעות היא שאין לו אירועים התואמים את הבקשה הזו. הוא יוצר את האירוע הזה באופן מלאכותי ובכך הופך להיות עקבי סיבתי.

בתוך: – מה אם אחרי זה יבואו לו עוד אירועים שאבדו אי שם ברשת?

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

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

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

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

בתוך: – כאשר אנו יוצרים מופע שמבצע עבורנו רסיסה (לא מאסטר, אלא עבד, בהתאמה), הוא מסתמך על זמן יוניקס של המכונה שלו או על הזמן של ה"מאסטר"; האם זה מסתנכרן בפעם הראשונה או מעת לעת?

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

בתוך: - אז הכל תלוי אך ורק ב"מאסטר"? האם תמיד משתמשים בזמן מאסטר?

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

בתוך: - יש לנו לקוח שמתחבר ולא צריך לדעת כלום על השעה?

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

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

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

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

MT: - שאלה טובה! CRDT הגיוני עבור התנגשויות כתיבה: ב- MongoDB, מאסטר יחיד.

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

MT: – אנשים מרושעים בתוך ההיקף הם כמו סוס טרויאני! אנשים מרושעים בתוך ההיקף יכולים לעשות הרבה דברים רעים.

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

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

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

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

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

בתוך: - תודה על הדיווח. סרגיי (Yandex). יש קבוע במונג שמגביל את מספר החברים המצביעים ב-Replica Set, וקבוע זה הוא 7 (שבעה). למה זה קבוע? למה זה לא איזה פרמטר?

MT: - יש לנו ערכות העתק עם 40 צמתים. תמיד יש רוב. אני לא יודע איזו גרסה...

בתוך: – ב-Replica Set אתה יכול להפעיל חברים שאינם מצביעים, אבל יש מקסימום 7 חברים מצביעים. איך נוכל לשרוד את ההשבתה במקרה זה אם ה-Replica Set שלנו מפוזר על פני 3 מרכזי נתונים? מרכז נתונים אחד יכול לכבות בקלות, ומכונה אחרת יכולה ליפול.

MT: – זה כבר קצת מעבר לתחום הדוח. זו שאלה כללית. אולי אוכל לספר לך על זה מאוחר יותר.

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com