מפתחים נוספים צריכים לדעת זאת על מסדי נתונים

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

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

1. יש לך מזל אם 99,999% מהמקרים הרשת לא גורמת לבעיות.
2. חומצה פירושה דברים רבים ושונים.
3. לכל מסד נתונים יש מנגנונים משלו להבטחת עקביות ובידוד.
4. חסימה אופטימית באה לעזרה כאשר קשה לשמור על הרגיל.
5. ישנן חריגות נוספות מלבד קריאות מלוכלכות ואובדן נתונים.
6. המאגר והמשתמש לא תמיד מסכימים על דרך הפעולה.
7. ניתן להעביר פיצול ברמת היישום אל מחוץ ליישום.
8. הגדלה אוטומטית יכולה להיות מסוכנת.
9. נתונים מיושנים יכולים להיות שימושיים ואין צורך לנעול אותם.
10. עיוותים אופייניים לכל מקורות זמן.
11. לעיכוב משמעויות רבות.
12. יש להעריך את דרישות הביצועים עבור עסקה ספציפית.
13. עסקאות מקוננות יכולות להיות מסוכנות.
14. אין לקשור עסקאות למצב יישום.
15. מתכנני שאילתות יכולים לספר לך הרבה על מסדי נתונים.
16. הגירה מקוונת היא קשה, אבל אפשרית.
17. עלייה משמעותית במאגר הנתונים גוררת עלייה באי-חיזוי.

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

יש לך מזל אם 99,999% מהמקרים הרשת לא גורמת לבעיות.

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

עם שיעור זמינות של 99,999% עבור Spanner (מסד הנתונים המופץ בעולם של גוגל), גוגל טוענת שרק 7,6% בעיות קשורות לרשת. במקביל, החברה מכנה את הרשת המתמחה שלה "העמוד הראשי" של זמינות גבוהה. לימוד בייליס וקינגסברי, שנערך בשנת 2014, מאתגר את אחד ה"תפיסות שגויות לגבי מחשוב מבוזר", אותו ניסח פיטר דויטש ב-1994. האם הרשת באמת אמינה?

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

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

ACID אומר הרבה דברים שונים

ראשי התיבות ACID מייצגים Atomicity, Consistency, Isolation, Reliability. מאפיינים אלו של עסקאות נועדו להבטיח את תקפותן במקרה של תקלות, שגיאות, תקלות חומרה וכו'. ללא ACID או תוכניות דומות, יהיה קשה למפתחי יישומים להבדיל בין מה שהם אחראים לו למה שמסד הנתונים אחראי. רוב מסדי הנתונים של העסקאות ההתייחסותיות מנסים להיות תואמי ACID, אך גישות חדשות כמו NoSQL הולידו מסדי נתונים רבים ללא עסקאות ACID מכיוון שהן יקרות ליישום.

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

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

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

תרשים הממחיש את התרחיש. MongoDB קורס לפני שהוא יכול לכתוב נתונים לדיסק

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

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

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

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

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

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

תקן SQL מזכיר את רמות הבידוד הבאות:

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

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

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

סקירה של חריגות במקביל ברמות בידוד שונות עבור DBMSs שונים

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

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

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

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

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

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

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

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

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

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

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

מסד הנתונים והמשתמש לא תמיד מסכימים מה לעשות

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

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

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

result1 = T1() // תוצאות אמיתיות הן הבטחות
תוצאה2 = T2()

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

ניתן להעביר פיצול ברמת היישום אל מחוץ ליישום

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

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

דוגמה לארכיטקטורה שבה שרתי יישומים מופרדים משירות הרסיסים

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

הגדלה אוטומטית יכולה להיות מסוכנת

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

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

לפני שתחליט על גישה, שקול את ההשפעה של מזהים ו-UUID הגדלים אוטומטית על הוספה לאינדקס, חלוקה וחלוקה.

נתונים מיושנים יכולים להיות שימושיים ולא דורשים נעילה

Multiversion Concurrency Control (MVCC) מיישמת רבות מדרישות העקביות שנדונו בקצרה לעיל. מסדי נתונים מסוימים (לדוגמה, Postgres, Spanner) משתמשים ב-MVCC כדי "להזין" עסקאות עם תמונות מצב - גרסאות ישנות יותר של מסד הנתונים. ניתן גם לבצע עסקאות תמונת מצב בסידרה כדי להבטיח עקביות. בעת קריאה מתמונת מצב ישנה, ​​קוראים נתונים מיושנים.

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

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

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

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

כל מקורות זמן נתונים לעיוותים

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

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

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

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

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

• TrueTime משתמש בשני מקורות שונים: GPS ושעונים אטומיים. לשעונים אלה יש מצבי כשל שאינם מתואמים. [ראה עמוד 5 לפרטים כאן - משוער. תרגום), כך שהשימוש המשותף שלהם מגביר את האמינות.
• ל-TrueTime יש API יוצא דופן. הוא מחזיר זמן כמרווח עם שגיאות מדידה ואי ודאות מובנים בתוכו. הרגע האמיתי בזמן הוא איפשהו בין הגבול העליון והתחתון של המרווח. Spanner, מסד הנתונים המבוזר של גוגל, פשוט ממתין עד שיהיה בטוח לומר שהשעה הנוכחית מחוץ לטווח. שיטה זו מכניסה חביון מסוים למערכת, במיוחד אם אי הוודאות אצל המאסטרים גבוהה, אך מבטיחה תקינות גם במצב מבוזר גלובלי.

רכיבי Spanner משתמשים ב-TrueTime, כאשר TT.now() מחזיר מרווח, כך שה-Spann פשוט ישן עד לנקודה שבה הוא יכול להיות בטוח שהזמן הנוכחי עבר נקודה מסוימת

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

לעיכוב משמעויות רבות

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

יש להעריך את דרישות הביצועים עבור עסקה ספציפית

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

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

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

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

עסקאות מקוננות יכולות להיות מסוכנות

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

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

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

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

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

אין לקשור עסקאות למצב יישום

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

מתכנני שאילתות יכולים לספר לך הרבה על מסד נתונים

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

SELECT * FROM articles where author = "rakyll" order by title;

ניתן לאחזר את התוצאות בשתי דרכים:

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

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

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

הגירה מקוונת היא קשה אך אפשרית

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

ישנם מודלים שונים של הגירה מקוונת. הנה אחד מהם:

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

למידע נוסף, אני ממליץ ליצור קשר статье, המפרטת את אסטרטגיית ההגירה של Stripe המבוססת על מודל זה.

עלייה משמעותית במאגר הנתונים גוררת עלייה באי-חיזוי

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

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

...

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

נ.ב.

קרא גם בבלוג שלנו:

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

מקור: www.habr.com