סקירה של CockroachDB: מאגר SQL מוגדל שנבנה להישרדות

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

Google Cloud Spanner, שירות מסדי נתונים יחסיים מנוהל באופן מלא, המופעל על ידי Google Compute Engine (GCE), שפורסם בפברואר 2017, כולל יכולת הרחבה של מאגרי מידע NoSQL תוך שמירה על תאימות SQL, סכימות יחס, עסקאות ACID ועקביות חיצונית חזקה. Spanner הוא מסד נתונים יחסי מפוצל ומשוכפל ברחבי העולם המשתמש באלגוריתם של Paxos להשגת הסכמה בין הצמתים שלו.

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

כמו Cloud Spanner, CockroachDB הוא בסיס נתונים מבוזר של SQL שנבנה על גבי חנות ערכי מפתח עסקית ועקבית, במקרה של CockroachDB ב- RocksDB. יעדי התכנון העיקריים של CockroachDB הם תמיכה בעסקאות ACID, מדרגיות אופקית ו (יותר מכל) שרידות, ומכאן השם.

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

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

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

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

איך עובד CockroachDB

כל צומת CockroachDB מורכב מחמש שכבות:

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

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

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

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

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

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

כמו Spanner, CockroachDB תומך בשאילתות נסיעה בזמן (מופעלת על ידי MVCC). אלה יכולים לחזור עד לאוסף האשפה האחרון של מסד הנתונים, שנעשה כברירת מחדל על בסיס יומי.

התקנת ושימוש בתיקן

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

מעבדות מקקים

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

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

ההתקנה ב- Mac קלה brew install cockroachכמו שמוצג לעיל. במקרה שלי, העדכון האוטומטי של Homebrew לקח הרבה יותר זמן (מספיק זמן לחלוט תה) מאשר התקנת CockroachDB בפועל, שנמשכה כמה שניות בלבד.

לאחר התקנת CockroachDB, די קל לסובב אשכול מקומי, אם כי יש את הצעד הנוסף של יצירת אישורי אבטחה באמצעות cockroach certהפקודה אם אתה רוצה שהאשכול יהיה מאובטח. ברגע שיש לך אשכול פועל (באמצעות cockroach startהפקודה פעם אחת לכל צומת, כאשר הצמתים הבאים מוגדרים להצטרף לאשכול הצומת הראשון), אתה יכול להתחבר לדף ניהול האינטרנט בכל צומת עם דפדפן, ולהשתמש cockroach sqlבלקוח המוטבע כדי לשלוח SQL שאילתות לכל צומת. רוב הדפדפנים יתלוננו על אתרים עם אישורים שנוצרו על ידי CockroachDB, אך אתה אמור להיות מסוגל ללחוץ על האזהרה הקשה הזו ולהמשיך לאתר.

הגדרות הייצור המומלצות של CockroachDB שונות מברירות המחדל שהוגדרו למופעי פיתוח ובדיקה. תוכל לפתח באשכול של צומת אחד אם תרצה בכך. לייצור, אתה אמור להיות בעל מינימום שלושה צמתים, להפעיל כל צומת במחשב, VM או מיכל נפרדים ולתת לכל מופע זיכרון מטמון נוסף וזיכרון SQL. הגדרות ברירת המחדל הן 128 מגה בייט עבור זיכרון מטמון וזיכרון SQL; הגדרות הייצור המומלצות הן לתת לכל 25 אחוז זיכרון RAM:

cockroach start --cache=25% --max-sql-memory=25%

ככל שאתה מפעיל יותר צמתים, כך הגמישות תהיה טובה יותר. ככל שהצמתים גדולים ומהירים יותר, כך הביצועים טובים יותר. אם ברצונך לקבל צמתים עם ביצועים המשתווים בערך לצמתים של Google Cloud Spanner, המספקים 2,000 כתובות בשנייה ו -10,000 קריאות בשנייה, אז תרצה משהו כמו מופעי n1-highcpu-8 של GCE, שיש להם שמונה מעבדים ו- 8 GB RAM , עם דיסקי SSD מקומיים (ולא דיסקים מסתובבים).

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

Labs Labs מספקת הוראות מפורטות לפריסה ב- AWS, Digital Ocean, GCE ו- Azure. התצורות המומלצות משתמשות במאזני עומסים, בשירותי איזון העומסים המנוהלים המקומיים או במאזני עומס בקוד פתוח כגון HAProxy.

תזמור יכול להוריד את תקורה ההפעלה של אשכול CockroachDB כמעט לכלום. מעבדות התיקן מתעדות כיצד לעשות זאת לייצור עם Kubernetes ו- Docker Swarm. מאגר CockroachDB-CloudFormation ב- GitHub מראה כיצד להשתמש ב- AWS CloudFormation ו- Kubernetes באזור זמינות יחיד לפיתוח ובדיקה. התאמה זו לייצור תכלול שינוי בתבנית CloudFormation לשימוש באזורי זמינות מרובים.

תכנות ובדיקות מקק DB

CockroachDB תומך בפרוטוקול החוט של PostgreSQL, כך שאתה כותב את הקוד שלך כאילו אתה מתכנת כנגד Postgres, או לפחות קבוצת משנה של Postgres. דף זה מפרט את מנהלי ההתקן שנבדקו עבור כריכות שפות תכנות שונות, כולל השפות הפופולריות ביותר בצד השרת. דף זה מפרט דוגמאות בעשר שפות תכנות ובחמש ORM. לא נתקלתי בהפתעות גדולות כשקראתי את הקוד, אם כי זיהיתי כמה באגים קלים אפשריים ברישומים בתיעוד. אתה יכול גם להריץ את ה- SQL שלך באמצעות הלקוח האינטראקטיבי המובנה בהפעלה cockroach.

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

עובדה נוספת שיש לקחת בחשבון היא שמרבית מאגרי ה- SQL הקונבנציונליים אינם פועלים במצב בידוד SERIALIZABLE כברירת מחדל; במקום זאת הם משתמשים במצב פחות קפדני עם ביצועים טובים יותר. CockroachDB משתמש במצב בידוד סידורי כברירת מחדל. בנוסף, זה יהיה קצת לא הוגן לבדוק את ביצועי ההצטרפות של SQL של ​​CockroachDB, שעדיין מתבצעת עבודה, עם חבילת TPC-C.

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

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

מקק DB SQL 

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

לדוגמא, ב- V1.1 אין תמיכה ב- JSON, המתוכננת ל- V1.2. הוא גם חסר ניתוח XML, שאינו נמצא במפת הדרכים. הוא חסר מפל ברמה שורה, המתוכנן ל- V1.2, וחסר סמנים ומפעילים, שאינם נמצאים במפת הדרכים. אינדקסים גיאו-מרחביים הם תוספות "פוטנציאליות" שעשויות להגיע למפת הדרכים בעתיד.

בעיקר, יישום CockroachDB הראשוני של SQL מצטרף בשנת 2016 היה פשטני בכוונה והציג קנה מידה ריבועי, מה שהופך אותו לחסר תועלת לשאילתת מערכי נתונים גדולים. הגרסה ב- V1.0, שנעשתה על ידי סטודנט לשיתוף פעולה, יישמה צירופי חשיש, מה שגורם להרבה פעולות הצטרפות בקנה מידה לינארי; שקיבלה את CockroachDB לרמה של SQLite. מתישהו בשנת 2018, בהתחשב בסבב המימון האחרון, CockroachDB הייתה צריכה להצטרף לביצועים המשתנים יותר כמו הצטרפות PostgreSQL, כמו גם לעיבוד הצטרפות SQL המופץ על פני האשכול.