NewSQL = NoSQL+ACID

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

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

איך זה עובד ומה קרה - קרא מתחת לכתבה.

כיום, הקהל החודשי של Odnoklassniki הוא יותר מ-70 מיליון מבקרים ייחודיים. אָנוּ אנחנו בחמישייה הראשונה הרשתות החברתיות הגדולות בעולם, ובין עשרים האתרים שבהם המשתמשים מבלים הכי הרבה זמן. תשתית OK מטפלת בעומסים גבוהים מאוד: יותר ממיליון בקשות HTTP/שנייה לכל חזית. חלקים מצי שרתים של יותר מ-8000 חלקים ממוקמים קרוב זה לזה - בארבעה מרכזי נתונים במוסקבה, מה שמאפשר השהיית רשת של פחות מ-1 ms ביניהם.

אנו משתמשים בקסנדרה מאז 2010, החל מגרסה 0.6. כיום פועלים כמה עשרות אשכולות. האשכול המהיר ביותר מעבד יותר מ-4 מיליון פעולות בשנייה, והגדול מאחסן 260 TB.

עם זאת, כל אלה הם אשכולות NoSQL רגילים המשמשים לאחסון מתואם חלש נתונים. רצינו להחליף את האחסון העקבי העיקרי, Microsoft SQL Server, שנמצא בשימוש מאז הקמת Odnoklassniki. האחסון כלל יותר מ-300 מכונות SQL Server Standard Edition, שהכילו 50 TB של נתונים - גופים עסקיים. נתונים אלה משתנים כחלק מעסקאות ACID ודורשים עקביות גבוהה.

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

הודות לריסוק ולזירוז SQL:

• אנו לא משתמשים באילוצים של מפתח זר, שכן בעת ​​פיצול מזהה הישות עשוי להיות ממוקם בשרת אחר.
• אנו לא משתמשים בפרוצדורות מאוחסנות ובטריגרים עקב העומס הנוסף על מעבד ה-DBMS.
• אנחנו לא משתמשים ב-JOIN בגלל כל האמור לעיל והרבה קריאות אקראיות מהדיסק.
• מחוץ לעסקה, אנו משתמשים ברמת הבידוד Read Uncommitted כדי להפחית מבוי סתום.
• אנו מבצעים רק עסקאות קצרות (בממוצע קצרות מ-100 אלפיות השנייה).
• אנחנו לא משתמשים ב-UPDATE ו-DELETE מרובי שורות בגלל המספר הרב של מבוי סתום - אנחנו מעדכנים רק רשומה אחת בכל פעם.
• אנחנו תמיד מבצעים שאילתות רק באינדקסים – שאילתה עם תוכנית סריקת טבלה מלאה עבורנו פירושה עומס יתר על מסד הנתונים וגרימתו לכישלון.

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

בעיות עם SQL

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

אבל הבעיה העיקרית היא

סובלנות לתקלות

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

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

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

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

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

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

עסקה פשוטה

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

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

או בפסאודוקוד:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

דרישות אחרות, לא פחות חשובות, היו:

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

החלטות החלטות

בניתוח פתרונות אפשריים, הגענו לשתי אפשרויות ארכיטקטורה אפשריות:

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

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

קסנדרה ו-CQL

אז מה מעניין בקסנדרה, אילו יכולות יש לה?

ראשית, כאן אתה יכול ליצור טבלאות התומכות בסוגי נתונים שונים; אתה יכול לעשות SELECT או UPDATE על המפתח הראשי.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

הגישה שבה אנו יוצרים קשר עם שלושה צמתים ומקבלים תגובה משניים נקראת ספֵּקוּלָצִיָה: בקשה להעתקים נוספים נשלחת עוד לפני שהיא "נופלת".

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

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

מה שהיה חסר לנו בקסנדרה

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

קוֹנוּס

כך נולד DBMS חדש קוֹנוּס, המורכב משלושה סוגים של צמתי שרת:

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

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

לקוחות

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

C*One רכז עסקה

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

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

מנעולים

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

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

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

לאחר מכן ניתן ליישם מנעולים בצורה של HashMap בנאלי בזיכרון של הרכז.

כשלים של רכז

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

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

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

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

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

הזמנה

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

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

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

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

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

איך העסקה עובדת

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

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

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

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

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

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

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

כתוצאה מהשיפורים לעיל, יישמנו את עקרונות ה-ACID:

• אָטוֹמִיוּת. זוהי ערובה לכך ששום עסקה לא תירשם חלקית במערכת; או שכל פעולות המשנה שלה יושלמו, או שאף אחת לא תושלם. אנו מקפידים על עיקרון זה באמצעות אצווה רשומה בקסנדרה.
• עֲקֵבִיוּת. כל עסקה מוצלחת, בהגדרה, מתעדת רק תוצאות תקפות. אם לאחר פתיחת עסקה וביצוע חלק מהפעולות, מתגלה כי התוצאה אינה חוקית, מתבצע החזרה.
• בידוד. כאשר עסקה מבוצעת, עסקאות במקביל לא אמורות להשפיע על תוצאותיה. עסקאות מתחרות מבודדות באמצעות נעילות פסימיות על הרכז. עבור קריאות מחוץ לעסקה, עקרון הבידוד נשמר ברמת Read Committed.
• קיימות. ללא קשר לבעיות ברמות נמוכות יותר - הפסקת מערכת, כשל בחומרה - שינויים שנעשו על ידי עסקה שהושלמה בהצלחה צריכים להישאר נשמרים כאשר הפעולות יתחדשו.

קריאה לפי אינדקסים

ניקח טבלה פשוטה:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

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

SELECT *
WHERE owner=?
AND modified>?

כדי ששאילתה כזו תעובד במהירות, ב-SQL DBMS קלאסי צריך לבנות אינדקס לפי עמודות (בעלים, שונה). אנחנו יכולים לעשות זאת די בקלות, מכיוון שיש לנו כעת ערבויות ACID!

אינדקסים ב-C*One

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

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

כעת ניתן לשכתב את השאילתה עבור "בעלים ליום האחרון" כבחירה מטבלה אחרת:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

מה קרה

פיתחנו את C*One לפני שלוש שנים והשקנו אותו לפעולה מסחרית.

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

כאשר השתמשנו ב-SQL עם מקדם שכפול = 1 (אבל ב-RAID 10), המטא-מידע של התמונות נשמר באשכול זמין מאוד של 32 מכונות המריצים את Microsoft SQL Server (בתוספת 11 גיבויים). 10 שרתים הוקצו גם לאחסון גיבויים. בסך הכל 50 מכוניות יקרות. במקביל, המערכת פעלה בעומס נקוב, ללא מילואים.

לאחר המעבר למערכת החדשה קיבלנו מקדם שכפול = 3 - עותק בכל מרכז נתונים. המערכת מורכבת מ-63 צמתי אחסון Cassandra ו-6 מכונות רכז, בסך הכל 69 שרתים. אבל המכונות הללו זולות הרבה יותר, העלות הכוללת שלהן היא כ-30% מהעלות של מערכת SQL. במקביל, העומס נשמר על 30%.

עם כניסתו של C*One, גם ההשהיה ירדה: ב-SQL, פעולת כתיבה ארכה כ-4,5 אלפיות השנייה. ב-C*One - כ-1,6 אלפיות השנייה. משך העסקה הוא בממוצע פחות מ-40 אלפיות השנייה, ההתחייבות מסתיימת תוך 2 שניות, משך הקריאה והכתיבה הוא בממוצע 2 מילישניות. האחוזון ה-99 - רק 3-3,1 אלפיות השנייה, מספר פסקי הזמן ירד פי 100 - הכל בגלל השימוש הנרחב בספקולציות.

עד עכשיו, רוב הצמתים של SQL Server הוצאו משימוש; מוצרים חדשים מפותחים רק באמצעות C*One. התאמנו את C*One לעבודה בענן שלנו ענן אחד, שאיפשר להאיץ את הפריסה של אשכולות חדשים, לפשט את התצורה ולהפוך את הפעולה לאוטומטית. ללא קוד המקור, ביצוע זה יהיה הרבה יותר קשה ומסורבל.

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

מקור: www.habr.com