דחיסת נתונים ב- Apache Ignite. הניסיון של סבר

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

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

1. תוכן מטמונים
2. כתוב יומן קדימה (להלן פשוט WAL)

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

דחיסת דפי דיסק

אֵיך מַפעִילִים אֶת זֶה

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

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

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

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

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

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

זה הגיוני שכדי לשחרר בלוק של מערכת הקבצים, גודל החור חייב להיות גדול או שווה לבלוק מערכת הקבצים, מה שמטיל מגבלה נוספת על גודל העמוד ו- Apache Ignite: כדי לדחיסה תהיה השפעה כלשהי, גודל העמוד חייב להיות גדול יותר מהגודל של בלוק מערכת הקבצים. אם גודל העמוד שווה לגודל הבלוק, אז לעולם לא נוכל לשחרר בלוק בודד, שכן כדי לשחרר בלוק בודד, העמוד הדחוס חייב לתפוס 0 בתים. אם גודל העמוד שווה לגודל של 2 או 4 בלוקים, כבר נוכל לפנות לפחות בלוק אחד אם הדף שלנו דחוס ל-50% או 75% לפחות, בהתאמה.

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

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

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

השפעת ביצועים

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

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

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

אז ההשפעה על פעולות הקריאה היא:

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

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

כיצד להפעיל ולהגדיר

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

• חייב להיות מודול ignite-compression ב-class-path. כברירת מחדל, הוא ממוקם בהפצת Apache Ignite בספרייה libs/אופציונלית ואינו כלול ב-class-path. אתה יכול פשוט להזיז את הספרייה למעלה רמה אחת ל-libs ואז כאשר תפעיל אותה דרך ignite.sh היא תופעל אוטומטית.
• יש להפעיל את ההתמדה (מופעל באמצעות DataRegionConfiguration.setPersistenceEnabled(true)).
• גודל העמוד חייב להיות גדול יותר מגודל הבלוק של מערכת הקבצים (תוכל להגדיר אותו באמצעות DataStorageConfiguration.setPageSize() ).
• עבור כל מטמון שצריך לדחוס את הנתונים שלו, עליך להגדיר את שיטת הדחיסה ו(אופציונלי) את רמת הדחיסה (שיטות CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

דחיסה של WAL

אֵיך מַפעִילִים אֶת זֶה

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

ערכים ב-WAL מחולקים ללוגיים ופיסיים. אלה בוליאניים הם המפתחות והערכים עצמם. פיזי - משקף שינויים בדפים בחנות הדפים. בעוד שרשומות לוגיות יכולות להיות שימושיות עבור כמה מקרים אחרים, רשומות פיזיות נחוצות רק להתאוששות במקרה של קריסה ורשומות נחוצות רק מאז המחסום המוצלח האחרון. כאן לא נפרט ונסביר מדוע זה עובד כך, אך המעוניינים יכולים להתייחס למאמר שהוזכר כבר על ה- Apache Ignite Wiki: Ignite Persistent Store - מתחת למכסה המנוע.

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

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

השפעת ביצועים

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

כיצד להפעיל ולהגדיר

אתה יכול לאפשר דחיסה של WAL באמצעות המאפיין WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). כמו כן, באמצעות שיטת DataStorageConfiguration.setWalCompactionLevel(), תוכל להגדיר את רמת הדחיסה אם אינך מרוצה מערך ברירת המחדל (BEST_SPEED).

דחיסת תמונת מצב של עמוד WAL

אֵיך מַפעִילִים אֶת זֶה

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

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

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

כמו בדחיסת דפי דיסק, דחיסת תמונת מצב של עמוד WAL יכולה להשתמש באלגוריתמי דחיסה של ZSTD, LZ4, Snappy, כמו גם במצב SKIP_GARBAGE.

השפעת ביצועים

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

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

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

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

כיצד להפעיל ולהגדיר

מינימום גרסת Apache Ignite: 2.8. הפעל והגדר באופן הבא:

• חייב להיות מודול ignite-compression ב-class-path. כברירת מחדל, הוא ממוקם בהפצת Apache Ignite בספרייה libs/אופציונלית ואינו כלול ב-class-path. אתה יכול פשוט להזיז את הספרייה למעלה רמה אחת ל-libs ואז כאשר תפעיל אותה דרך ignite.sh היא תופעל אוטומטית.
• יש להפעיל את ההתמדה (מופעל באמצעות DataRegionConfiguration.setPersistenceEnabled(true)).
• יש להגדיר את מצב הדחיסה בשיטה DataStorageConfiguration.setWalPageCompression(), הדחיסה מושבתת כברירת מחדל (מצב DisABLED).
• לחלופין, אתה יכול להגדיר את רמת הדחיסה באמצעות השיטה DataStorageConfiguration.setWalPageCompression(), עיין ב-javadoc עבור השיטה עבור ערכים חוקיים עבור כל מצב.

מסקנה

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

מקור: www.habr.com