מערכות מבוזרות מודרניות הן כולן על פשרות. ביצועים, אמינות, מדרגיות ועקביות לא באים בחינם - אתה תמיד משלם מחיר איפשהו. כאן נכנס לתמונה משפט ה-CAP: זוהי נקודת המוצא להבנת הפשרות הבלתי נמנעות בתכנון מבוזר.  מדוע משפט CAP נכון? מה זה בעצם מסביר? והכי חשוב, האם זה מספיק? בפוסט זה, נחקור את משפט CAP, את מגבלותיו, את הביקורות שהוא התמודד, וכיצד רעיונות חדשים יותר כמו PACELC דוחפים את השיחה קדימה. בואו נצלול פנימה.  משפט CAP  הגרסה הראשונה של משפט CAP התחילה כוויכוח בין   . אבל עם הזמן, הוא התפתח, קיבל הוכחה רשמית, וסיים את לימודיו להיות משפט CAP כפי שאנו מכירים אותו היום. ACID לעומת BASE  משפט CAP קובע   : שמערכת מבוזרת יכולה לספק לכל היותר שניים מתוך שלושה מאפיינים בו זמנית   עֲקֵבִיוּת   זְמִינוּת   סובלנות למחיצות  מגבלה זו מאלצת מהנדסים לבצע פשרות קשות בהתאם למטרות המערכת ולמציאות של הסביבות המבוזרות שלהם.  עֲקֵבִיוּת   עקביות ב-CAP אינה זהה לעקביות בעסקאות   . במשפט CAP זה מתייחס   או   . המשמעות היא שכל   , ללא קשר לאיזה צומת מעבד את הבקשה. המשמעות היא שכל פעולת קריאה משקפת את הכתיבה העדכנית ביותר, לא משנה באיזה צומת אתה מבצע שאילתה. ACID ללינאריזציה עקביות חזקה הצמתים במערכת מבוזרת חייבים תמיד להציג תצוגה אחת ועדכנית של הנתונים  💡 עקביות ב-ACID, לעומת זאת, מתמקדת בהבטחה שעסקה מביאה את מסד הנתונים ממצב חוקי אחד למצב חוקי אחר, בהתאם לכללים שהוגדרו על ידי סכימת מסד הנתונים. זה יותר על אכיפת אילוצי שלמות (כמו מפתחות זרים, אילוצים ייחודיים וכו') והבטחה שמסד הנתונים לא יישאר במצב לא חוקי, אפילו לנוכח קריסות.  זְמִינוּת   זמינות ב-CAP פירושה   . במילים אחרות, אם צומת בריא מקבל בקשה, עליו לעבד ולהגיב לה. עם זאת, CAP   - היא רק מבטיחה שהצומת לא ייכשל בשקט (לדוגמה, במערכת   צמתים עשויים להגיב עם נתונים מיושנים במהלך מחיצה כדי להבטיח זמינות ). שכל צומת שאינו כושל חייב להחזיר תגובה עבור כל בקשה שהוא מקבל, ללא קשר למחיצות הרשת לא מבטיח שהתגובה תהיה תמיד "נכונה" או מעודכנת AP  💡 אריק ברואר (המחבר המקורי של CAP) תיאר במקור את הנכס הזה בצורה קצת יותר גמישה כ: "כמעט כל השאילתות צריכות לקבל תגובה". עם זאת, בהוכחה הרשמית של CAP, הזמינות הוחמרה, ודרשה "כל שאילתה תקבל תגובה כל עוד הצומת המטפל בה תקין".  אולם בפועל, זמינות אינה ערובה מוחלטת - היא תלויה לעתים קרובות באילוצים ספציפיים למערכת, כמו כמה זמן אתה מוכן לחכות לתגובה. עבור מערכות בעולם האמיתי,   ממלא תפקיד קריטי בעיצוב ה-SLA שלך (הסכם רמת שירות), למרות ש-CAP עצמו אינו מתייחס ישירות לזמן האחזור. עוד על זה   . זמן תגובה (או פסק זמן) בפוסט זה בבלוג  סובלנות למחיצות   סובלנות מחיצות היא כולה לשרוד כשלי רשת.   מחיצה מתרחשת כאשר צמתים אינם יכולים לתקשר עקב מנות שנפלו, פסקי זמן או פיצולי רשת. אם צמתים אינם יכולים לתקשר עקב פיצול רשת (מחיצה), המערכת עדיין חייבת לעמוד בהבטחות העקביות או הזמינות שלה, בהתאם לבחירות העיצוב שלה.  מערכות מבוזרות אינן חיות בעולם אגדות עם רשתות מושלמות. מנות נושרות, פסקי זמן מתרחשים, ואינם נמנעים עליות חביון. בשל כך,   - מחיצות יתרחשו במוקדם או במאוחר, כך שאינך יכול "לבחור" להתעלם ממנה, לא משנה כמה מפתה זה נשמע. סובלנות מחיצות אינה ניתנת למשא ומתן בכל מערכת מבוזרת  ב-CAP, סבילות למחיצות לא אומר שהמערכת ממשיכה לפעול כאילו כלום לא קרה. המשמעות היא שהמערכת צריכה להחליט אם לתעדף זמינות (AP) או עקביות (CP) במהלך מחיצה. אם היית מתעלם מסובלנות מחיצות, בעצם היית בונה מערכת מונוליטית לא מבוזרת.  CAP הסביר  הדרך הקלה ביותר להבין CAP היא לשקול   - מצב שבו שני חלקים של מערכת מבוזרת אינם יכולים לתקשר זה עם זה. בתרחיש כזה, המערכת מתמודדת עם שלוש תוצאות אפשריות: מחיצת רשת    בעוד החלק השני מבודד, לשני החלקים יהיו מצבים לא עקביים. זה גורם לאובדן של   . אם חלק אחד של המערכת מקבל עדכונים C (עקביות)    , עליה לחסום עדכונים בחלק אחד או בשני החלקים של המחיצה כדי להבטיח מצב מאוחד בכל הצמתים. זה מוביל לאובדן של   מכיוון שבקשות מסוימות יידחו או יעוכבו ללא הגבלת זמן. אם המערכת בוחרת להישאר עקבית A (זמינות)    ועקבית (C) מבלי לסבול את המחיצה (P), היא לא מופצת באמת. זה ידרוש מהצמתים לקיים אינטראקציה וליישב מצב, דבר בלתי אפשרי במהלך מחיצה. אם המערכת בוחרת להישאר זמינה (A)  לפיכך,   , המערכת יכולה לספק רק   . ברגע שהמחיצה נפתרה (כלומר, הצמתים מקיימים שוב אינטראקציה), המערכת יכולה להחזיר את כל שלושת המאפיינים, אך   , אי אפשר להימנע משינויים. במהלך מחיצה שניים משלושת המאפיינים (C, A או P) במהלך המחיצה עצמה  השלכות המשפט  תוצאה של המשפט עבור מערכות אסינכרוניות היא שרק שלושה שילובים של עקביות, זמינות וסובלנות למחיצות אפשריים:  AP (זמינות + סובלנות למחיצות)  מערכות מסוג זה מגיבות לשאילתות, אך ייתכן שהנתונים המוחזרים לא תמיד מעודכנים, עם עדכונים איטיים יותר של הנתונים אך "תמיד" זמינים. דוגמאות למערכת כזו הן DNS, DynamoDB ו- Cassandra.  CP (עקביות + סובלנות מחיצות)  מערכות מסוג זה תמיד מחזירות נתונים עדכניים, אך ייתכן שחלק מהצמתים במערכת, או אפילו כולם, לא יגיבו אם הם מחולקים למחיצות. זה נותן עדכונים אטומיים אבל יכול להוביל לפסקי זמן. מסדי נתונים של NoSQL כגון Google BigTable, MongoDB, HBase ו-Redis הם כולן מערכות מסוג זה.  CA (עקביות + זמינות)  מערכות מסוג זה תמיד מחזירות נתונים עדכניים כאשר אין מחיצות. בגלל המגבלה האחרונה, בדרך כלל, מערכות כאלה משמשות רק בתוך מכונה אחת. דוגמאות לכך הן מסדי נתונים יחסיים קלאסיים.  במציאות, אנו בוחרים בין CP ל-AP כי CA הוא בעצם מונוליט ללא מחיצות. עבור מערכות בקנה מידה גדול, מעצבים לא יכולים לנטוש את P ולכן יש להם בחירה קשה בין C ל-A.  ב-CA, כשל בצומת פירושו חוסר זמינות מוחלטת של השירות. אבל זה לא משבית את המדרגיות, מכיוון שאנו יכולים לשכפל מונוליטים עצמאיים ולחלק את העומס עליהם  ביקורת על משפט CAP  משפט CAP היה מושג בסיסי במערכות מבוזרות, אבל הוא לא חף ממגבלותיו. עם כל הבהירות שלו בהצגת הרעיון של פשרות, משפט ה-CAP זכה לא פעם לביקורת על כך שהוא מפשט מציאות מורכבת יתר על המידה, מה שהוביל לאי הבנות ויישום שגוי.  1. פשרות חלות רק במהלך מחיצות  אחת הביקורות הנפוצות ביותר היא שההתלבטויות של משפט CAP - בחירה בין     - חלות רק כאשר   מתרחשת בפועל. בפעולה רגילה, כאשר הרשת יציבה ואין מחיצות קיימות, אין פשרה מובנית בין עקביות לזמינות. עקביות (C) לזמינות (A) מחיצת רשת (P)  יתר על כן, הפערים הללו אינם אוניברסליים בכל המערכת. בתוך אותה מערכת מבוזרת:  חלקים שונים של המערכת עשויים לחוות פשרות שונות בהתבסס על הקשר (כמו מיקום המשתמש, סוג הנתונים).  פעולות ספציפיות עשויות לתת עדיפות לעקביות בעוד שאחרות נותנות עדיפות לזמינות.  ההחלטות יכולות להשתנות בזמן הריצה בהתאם לגורמים כמו עומס, זמן אחזור או דרישות המשתמש.  ניואנס זה הולך לאיבוד לעתים קרובות בדיונים ברמה גבוהה על CAP, מה שמוביל לסיווגים מופשטים מדי של מערכות כ"CP" או "AP" בכל רחבי הלוח.  2. CAP מתעלם מהשהייה  ביקורת חשובה נוספת היא שמשפט ה-CAP אינו מסביר את   , למרות שהחביון והחלוקה קשורים באופן עמוק בפועל. לְדוּגמָה: החביון  רשת איטית (שהייה גבוהה) עשויה להיראות בלתי ניתנת להבדלה ממחיצה.  זמני זמן - המשמשים לאיתור כשלים - הם סובייקטיביים ותלויים במידה רבה בתכנון המערכת ובתנאי הרשת. מה שמערכת אחת מגדירה כ"מחיצה" עשוי להיות רק עיכוב חולף עבור אחרת.  במערכות מבוזרות בעולם האמיתי, כאשר מתרחשת מחיצה או זמן השהייה גבוה, המערכת חייבת לקבל החלטה בתוך   : לתעדף זמינות על ידי החזרת תוצאה אולי מיושנת, או לתת עדיפות לעקביות על ידי המתנה ארוכה יותר (ועלולה לא להגיב). ההשקפה הבינארית של CAP אינה תופסת את המורכבות של החלטות אלו. פרק זמן קצוב  3. מאפייני CAP אינם בינאריים  משפט CAP מציג עקביות, זמינות וסובלנות מחיצות כמאפיינים בינארים - או שיש לך אותם או שאין לך. אבל בפועל,   : כל שלושת המאפיינים קיימים על ספקטרום    אינה מאפיין "הפעלה/כיבוי" בינארי - היא נעה בין 0% ל-100%. לדוגמה, מערכת עשויה להבטיח זמינות של 99.99%, אבל זה עדיין מאפשר תקופות קטנות של חוסר זמינות. זמינות    יש רמות משתנות, מעקביות בסופו של דבר לעקביות סיבתית ועד לעקביות חזקה. לא כל יישום דורש יכולת ליניאריזציה מלאה. לעקביות    כשלעצמה אינה אירוע מובהק. מערכות עשויות לא להסכים אם קיימת מחיצה (כמו שצומת אחד רואה בפסק זמן ככשל, בעוד שצומת אחר ממשיך לפעול כרגיל). סובלנות מחיצות  אופי רציף זה של המאפיינים הופך את CAP לפשטני מדי עבור מודלים של המורכבות של מערכות מבוזרות מודרניות.  משפט PACELC  בעוד ש-CAP חולל מהפכה בהבנתנו לגבי פשרות במערכות מבוזרות, זו לא המילה האחרונה בנושא.   נחשב לגישה חלופית לתכנון של מערכות מבוזרות. הוא מבוסס על מודל CAP, אך בנוסף לעקביות, זמינות וסובלנות למחיצות הוא כולל גם חביון והדרה לוגית בין שילובים של מושגים אלו. משפט PACELC שתואר על ידי דניאל ג'יי עבאדי  PACELC מציגה שני מצבי פעולה נפרדים עבור מערכות מבוזרות:    (   ): איזה פשרה עושה המערכת כאשר מתרחשת מחיצה? כאן, אנו בוחנים מחדש את ההחלפה הקלאסי של CAP בין     . מצב מחיצה PAC זמינות (A) לעקביות (C)    (   ): איזה פשרה עושה המערכת כאשר אין מחיצה, והרשת פועלת כרגיל? במצב זה, המערכת מתמודדת עם פשרה שונה - בין     .  מצב אחר ELC זמן השהייה (L) לעקביות (C)  הפשרה בין חביון לעקביות  בעוד שמחיצות הן בלתי נמנעות במערכות מבוזרות, הן נדירות בהשוואה לאתגרים המתעוררים במהלך פעולה רגילה. במערכות מבוזרות מודרניות,   הוא לעתים קרובות צוואר בקבוק גדול יותר ממחיצות רשת, במיוחד עבור יישומים בקנה מידה עולמי. זה המקום שבו   מתמקדת - על ידי התייחסות לשינויים המתרחשים כאשר המערכת פועלת ללא מחיצות. בניגוד ל-CAP, המתמקדת אך ורק בהתנהגות במהלך תרחישי כשל, PACELC מדגישה את ההחלטות שעל האדריכלים לקבל מדי יום כדי לאזן את     : חביון PACELC ההשהיה (L) והעקביות (C)    דורשת תיאום וסנכרון בין צמתים כדי לשמור על תצוגה אחידה של הנתונים. תקורה זו מציגה עיכובים, ומאטה את זמני התגובה. עקביות חזקה    (כמו אלה המאמצות עקביות בסופו של דבר) מתעדפות מהירות על ידי הרפיית ערבויות העקביות. מערכות אלו מגיבות מהר יותר אך עשויות להחזיר מדי פעם נתונים מיושנים או לא עקביים. מערכות עם אחזור נמוך  על ידי הרחבת השיחה מעבר למחיצות כך שתכלול פעולה רגילה, PACELC מבטיחה שהביצועים היומיומיים של מערכות מבוזרות יטופלו בחשיבות הראויה.  עוטף את זה  ניסוח משפט ה-CAP היה אירוע משמעותי בקהילה, ומחקרים על השפעתו על תכנון מערכות מבוזרות הראו שמתכננים של מערכות מבוזרות לא צריכים להגביל את המערכת לשני מאפיינים - עליהם לשאוף למקסם את הערבויות הנדרשות בכל אחת מהן. מקרה מסוים. לצורך כך, סביר לחלק את המערכת למקטעים שלכל אחד מהם דרישות משלו ולתכנן את המערכת בהתאם לדרישות של כל אחד מהמקטעים.  משפט ה-CAP היה אבן יסוד בחשיבת מערכות מבוזרות במשך עשרות שנים. זה נתן לנו מסגרת להנמקה לגבי הפערים המובנים של עקביות, זמינות וסובלנות לחלוקה. אבל במובנים רבים, זה פישוט של המציאות, בהנחה של בחירות בינאריות והתעלמות מגורמים קריטיים כמו חביון.  PACELC מתבססת על CAP, ומכירה בכך:   פשרות קיימות גם כאשר מחיצות לא.    בתכנון מערכות מבוזרות. חביון הוא דאגה ממדרגה ראשונה  גם CAP וגם PACELC הם כלים יקרי ערך, אבל גם לא מתכון שלב אחר שלב לבניית מערכות. במקום זאת, הם מספקים   להערכת פשרות והבנת הגבולות של ארכיטקטורות מבוזרות. מודלים מנטליים  חומרים נוספים   CAP שתים עשרה שנים מאוחר יותר: כיצד "הכללים" השתנו   קסנדרה: המדריך הסופי     נא להפסיק לקרוא למאגרי המידע CP או AP וביקורת על משפט ה-CAP מאת מרטין קלפמן   הערות על מערכות מבוזרות לדמים צעירים   תודה שקראת!   סקרן לגבי משהו או יש לך מחשבות לשתף? השאר את תגובתך למטה! בדוק את   או עקוב אחריי דרך   ,   או   . הבלוג שלי LinkedIn Substack Telegram

Subscribe

Buy My Book

האודיו הזה מופק בשפת המקור של הסיפור!

יותר מדי זמן; לקרוא

Make resilience your competitive advantage

מדוע מערכות מבוזרות לא יכולות להכיל את הכל

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps