מתי להשתמש במסד נתונים מבוסס CRDT

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

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

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

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

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

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

מאגרי מידע ליישומים המופצים גיאוגרפית

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

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

מעבדות רדיס

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

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

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

עקביות חזקה

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

עקביות בסופו של דבר

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

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

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

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

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

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

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

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

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

מהם CRDTs?

CRDTs הם סוגי נתונים מיוחדים שמכנסים נתונים מכל העתקי מסד הנתונים. ה- CRDT הפופולרי הם דלפקי G (דלפקים לגידול בלבד), דלפקי PN (דלפקים חיוביים-שליליים), רושמים, ערכות G (סטים לגידול בלבד), ערכות 2P (סטים דו-פאזיים), או ערכות ( קבוצות שנצפו-הסירו) וכו '. מאחורי הקלעים הם מסתמכים על המאפיינים המתמטיים הבאים בכדי לכנס את הנתונים:

  1. רכוש קומוטטיבי: a ☆ b = b ☆ a
  2. רכוש אסוציאטיבי: a ☆ (b ☆ c) = (a ☆ b) ☆ c
  3. אימפוטנציה:  a ☆ a = a

מונה G הוא דוגמה מושלמת ל- CRDT תפעולי שממזג את הפעולות. כאן, a + b = b + a ו- + (b + c) = (a + b) + c. ההעתקים מחליפים רק את העדכונים (התוספות) זה עם זה. ה- CRDT ימזג את העדכונים על ידי הוספתם. ערכת G, למשל, מפעילה אימפוטנציה ({a, b, c} U {c} = {a, b, c}) כדי למזג את כל האלמנטים. אימפוטנציה מונעת שכפול של אלמנטים שנוספו למבנה נתונים תוך כדי נסיעה ומתכנסים דרך נתיבים שונים.

סוגי נתונים CRDT וסמנטיקה לפתרון סכסוכים שלהם

מבני נתונים ללא קונפליקטים: דלפקי G, דלפקי PN, ערכות G

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

מעבדות רדיס

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

רושמים: מיתרים, האש

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

מעבדות רדיס

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

ערכות 2P

סטים דו-פאזיים מקיימים שתי קבוצות של ערכות G- האחת לפריטים שנוספו והשנייה לפריטים שהוסרו. ההעתקים מחליפים את התוספות של ערכת ה- G כשהם מסונכרנים. קונפליקט נוצר כאשר אותו אלמנט נמצא בשתי הערכות. בכמה מאגרי מידע מבוססי CRDT כגון Redis Enterprise מטפלים במדיניות "הוסף מנצח על המחיקה".

מעבדות רדיס

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

כיצד ארכיטקט יישום לשימוש במסד נתונים מבוסס CRDT

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

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

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

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

בדיקת יישומים עם בסיס נתונים מרובה-מאסטר מבוזר

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

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

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