Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them עומסי עבודה של מסדי נתונים כבדים כתיבה מביאים אתגרים שונים באופן ברור מאלה כבדים קריאה. גודל כתיבה יכול להיות יקר, במיוחד אם אתה משלם עבור פעולה וכתובות הם 5 פעמים יותר יקר מאשר קריאה. מנעול יכול להוסיף עיכובים ולהפחית את העברת I/O bottlenecks יכול להוביל לכתוב הרחבה ומסבך התאונה התאוששות מסד נתונים Backpressure יכול להזיז את הטעינה הנכנסת בעוד העלות חשובה - הרבה, במקרים רבים - זה לא נושא שאנחנו רוצים לכסות כאן, במקום זאת, בואו נתמקד המורכבות הקשורה ביצועים שהצוותים נפוצים להתמודד עם ולדון באפשרויות שלך להתמודד איתם. מה המשמעות של "כוח עבודה כבד של כתיבה בזמן אמת"? ראשית, בואו נבהיר מה אנחנו מתכוונים על ידי "עבודה בזמן אמת כתיבה כבדה". כניסה של כמות גדולה של נתונים (למשל, מעל 50K OPS) כותבים יותר מאשר קוראים הם מחויבים על ידי SLAs לעיכוב קפדני (למשל, עיכוב Millisecond P99 יחיד-digit) בטבע, הם מתרחשים בכל דבר מהמשחקים המקוונים לשווקים בזמן אמת, כמה דוגמאות ספציפיות: עומסי העבודה של האינטרנט של הדברים (IoT) נוטים לכלול נתונים קטנים אך תכופים, אך כותבים רק את נתוני סדרת הזמן.כאן, שיעור ההקפאה נקבע בעיקר על ידי מספר נקודות הקצה שאוספות נתונים.חשוב על חיישנים חכמים בבית או ציוד מעקב תעשייתי המשלחים כל הזמן זרימי נתונים לעיבוד ולשמירה. מערכות רישום ומעקב מתמודדות גם עם נטילת נתונים תכופות, אך אין להן שיעור נטילת נתונים קבוע, הן עשויות לא בהכרח להופיע רק, כמו גם להיות נוטות למקומות חמים, כגון כאשר נקודת קצה אחת מתנהגת לא נכון. פלטפורמות משחקים מקוונות צריכות לעבד אינטראקציות משתמשים בזמן אמת, כולל שינויים במצב המשחק, פעולות שחקן והודעות. עומס העבודה נוטה להיות חריף, עם גדלים פתאומיים בפעילות. עומסי העבודה של מסחר אלקטרוני ועסקים קמעונאיים הם בדרך כלל כבדים עדכוניים ולעתים קרובות כוללים עיבוד מנות.מערכות אלה חייבות לשמור על רמות מלאי מדויקות, לעבד ביקורות לקוחות, לעקוב אחר מצב ההזמנות ולנהל פעולות עגלת קניות, אשר בדרך כלל דורשות קריאה של נתונים קיימים לפני ביצוע עדכוניות. מערכות Ad Tech ו- Real-time Bidding דורשות החלטות של שניות חלקיות.מערכות אלה מתמודדות עם עיבוד ההצעות המורכב, כולל מעקב אחר ההדפסה והתוצאות של המכירות, תוך שמירה על אינטראקציות משתמשים כגון קליקים ושינויים. מערכות בורסה בזמן אמת חייבות לתמוך בפעולות מסחר בתדירות גבוהה, עדכוני מחירי מניות קבועים ותהליכים מורכבים של התאמה להזמנות - כל זאת תוך שמירה על עקביות נתונים מוחלטת ועיכוב מינימלי. לאחר מכן, בואו נסתכל על שיקולי ארכיטקטורה ותצורה העיקריים המשפיעים על ביצועי הכתיבה. ארכיטקטורה של מנוע אחסון הבחירה של ארכיטקטורה מנוע אחסון משפיעה באופן יסודי על ביצועי כתיבה במסדי נתונים. מסדי נתונים הידועים להתמודד עם כתיבה ביעילות – כגון ScyllaDB, Apache Cassandra, HBase ו- Google BigTable – משתמשים ב-Log-Structured Merge Trees (LSM). ארכיטקטורה זו אידיאלית לטיפול בכמויות גדולות של כתיבה. מכיוון שהכתיבה מצורפת מיד לזיכרון, זה מאפשר אחסון ראשוני מהיר מאוד. לדוגמה, הנה איך נראית מסלול הכתיבה של ScyllaDB: עם מבנים של עץ B, כל פעולת כתיבה דורשת מיקום ושינוי של כפתור בעץ – וזה כולל שני I/O רצופים ומקבילים.בזכות הגדלת קבוצת הנתונים, העץ עשוי לדרוש כפתורים נוספים ושילוב מחדש, מה שמוביל ליותר I/O דיסק, אשר יכול להשפיע על הביצועים. Payload גודל גודל משקל משפיע גם על הביצועים.עם משקל קטן, עוצמה טובה אבל עיבוד ה-CPU הוא הבקבוק העיקרי.כמו גודל משקל עולה, אתה מקבל עוצמה כללית נמוכה יותר ושימוש הדיסק גם עולה. בסופו של דבר, כתיבה קטנה מתאימה בדרך כלל לכל המקלות וכל דבר יכול להיות מעובד די מהר. זו הסיבה לכך שזה קל לקבל עוצמה גבוהה. עבור מטענים גדולים יותר, אתה צריך להקצות מטענים גדולים יותר או מטענים מרובים יותר. קומפוזיציה שימוש בדיסק הוא משהו לצפות בקפידה עם עומס עבודה כבד כתיבה.אף על פי שהאחסון הוא כל הזמן הופך זול יותר, זה עדיין לא בחינם. דיכוי יכול לעזור לשמור על דברים בשליטה – אז לבחור את אסטרטגיית הדיכוי שלך בחוכמה.מהירות דיכוי מהירות יותר חשובות עבור עומס עבודה כבד כתיבה, אבל גם לשקול את משאבי ה-CPU והזיכרון הזמינים שלך. ודא שאתה מסתכל על דחיסה בעצם מחלקת את הנתונים שלך בלוקים קטנים יותר (או חתיכות) ולאחר מכן דחיסה כל בלוק בנפרד.כשמתאם הגדרה זו, להבין כי חתיכות גדולות יותר הן טובות יותר לקריאה בעוד קטנות יותר הן טובות יותר לכתיבה, ולקחת בחשבון את גודל עומס התועלת שלך. קירור קירור קירור קירור חמלה עבור מסדי נתונים המבוססים על LSM, אסטרטגיית הדחיסה שאתה בוחר משפיעה גם על ביצועי הכתיבה.הדחיסה כוללת שילוב של SSTables מרובים לתוך קבצים פחות, מאורגנים יותר, כדי לייעל ביצועי קריאה, לשחזר שטח דיסק, להפחית את חלוקת הנתונים ולשמור על היעילות הכללית של המערכת. בעת בחירת אסטרטגיות דחיסה, אתה יכול לשאוף להגברת קריאה נמוכה, מה שהופך את קריאות יעילות ככל האפשר. או, אתה יכול לשאוף להגברת כתיבה נמוכה על ידי הימנעות דחיסה להיות אגרסיבי מדי. (אפילו קאסנדרה מציעה דברים דומים): מספר אסטרטגיות התייחסות אסטרטגיית דחיסה בגודל (STCS): מופעלת כאשר למערכת יש מספיק (ארבעה כברירת מחדל) SSTables בגודל דומה. אסטרטגיית דחיסה ברמה (LCS): המערכת משתמשת ב-SSTables קטנים, בגודל קבוע (כברירת מחדל 160 MB) המופצים ברמות שונות. אסטרטגיית חיכוך מוגברת (ICS): משתף את אותם גורמי חיכוך קריאה וכתיבה כמו STCS, אך מתקן את הבעיה של חיכוך מרחב זמני 2x על ידי פירוק סטלים ענקיים ל SSTable Runns, אשר מורכבים ממגוון מסודר של קטנים יותר (1 GB כברירת מחדל), SSTables שאינם מכוסים. אסטרטגיית דחיסת חלון זמן (TWCS): תוכנן עבור נתוני סדרת זמן. עבור עומס עבודה כבד כתיבה, אנו מזהירים משתמשים להימנע דחיסה שווה בכל מחיר.אסטרטגיה זו מיועדת למקרים של שימוש כבד קריאה.השימוש בו יכול להוביל להרחבה כתיבה 40x מצער. Batching במסדי נתונים כגון ScyllaDB ו-Cassandra, סוללה יכולה למעשה להיות מלכודת - במיוחד עבור עומסי עבודה כבדים כתיבה. אם אתה רגיל למסדי נתונים יחסיים, סוללה עשויה להיראות כמו אפשרות טובה לניהול נפח גבוה של כתובות. אבל זה יכול למעשה להאט דברים אם זה לא נעשה בקפידה. בעיקר, זה בגלל סוללות גדולות או לא מבוססות בסופו של דבר ליצור הרבה שיתוף פעולה וחיבור רשת בין ערוצים. הנה איך לחשוב על חטיבה כאשר אתה מתמודד עם כותבים כבדים: Batch by the Partition Key: קבוצה את ההודעות שלך על ידי מפתח המקטעים כך שהמקטע הולך לקוטר שיחזיק גם את הנתונים, ובכך, המנהל לא צריך להגיע לקוטרים אחרים לקבלת נתונים נוספים. שמור על חבילות קטנות וממוקדות: הפרקת חבילות גדולות לחבילות קטנות יותר לפי חלוקה שומרת על דברים יעילים.היא מונעת עומס יתר על הרשת ומאפשרת לכל צומת לעבוד רק על הנתונים שיש לו. שמור על חבילות שלא נרשמו: בהתחשב שאתה עוקב אחר הנקודות הקודמות, עדיף להשתמש בחבילות שלא נרשמו. חבילות שנרשמו להוסיף בדיקות עקביות נוספות, אשר יכול באמת להאט את הכתיבה. אז, אם אתה במצב קשה לכתוב, לארגן את החבילות שלך בקפידה כדי למנוע את העיכובים שגדולים, חבילות בין-קצות יכול להציג. חבילות Up היינו מציעים כמה אזהרות, אבל אל תדאגו.זה היה קל להכין רשימה של שיעורים לומדים כי כל כך הרבה צוותים מצליחים מאוד לעבוד עם עומס עבודה קשה לכתוב בזמן אמת. אם ברצונך ללמוד עוד, הנה כמה נקודות מבט ממקור ראשון מהצוותים שהתמודדו עם אתגרים מעניינים למדי: Zillow: צריכת רשומות ממספר יצרנים של נתונים, וכתוצאה מכך כתיבה לא מסודרת שעלולה להוביל לעדכונים לא נכונים Tractian: התכוננות לצמיחה של 10X בנתונים תדרים גבוהים כותבים ממכשירים IoT פנאטים: פעולות כתיבה כבדות כגון ניהול הזמנות, עגלות קניות ועדכוני מוצרים עבור סוחר ספורט מקוון זה זילבר טרקטוריון פנאטים כמו כן, צפו בסרטון הבא, שבו אנו נכנסים לעומק גדול יותר על האתגרים האלה כותבים כבדים וגם ללכת דרך מה עומסי העבודה האלה נראים על ScyllaDB.
