כיצד בדקנו מסדי נתונים מרובים של סדרות זמן

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

נראה שבשנת 2019 מאמר עליו כדאי להשתמש ב-TSDB יהיה מורכב ממשפט אחד בלבד: "פשוט השתמש ב-ClickHouse". אבל... יש ניואנסים.

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

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

הצהרת הבעיה

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

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

הדרישות העיקריות שלנו היו:

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

במאמר זה אנו מתעניינים בנקודה האחרונה.

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

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

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

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

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

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

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

בשנת 2017, בכנס Percona Live בסן חוזה, מפתחי Clickhouse כנראה הכריזו על עצמם בפעם הראשונה. במבט ראשון, המערכת הייתה מוכנה לייצור (טוב, Yandex.Metrica היא מערכת ייצור קשוחה), התמיכה הייתה מהירה ופשוטה, והכי חשוב התפעול היה פשוט. מאז 2018, התחלנו בתהליך המעבר. אבל עד אז, היו הרבה מערכות TSDB "למבוגרים" ונבדקו בזמן, והחלטנו להקדיש זמן רב ולהשוות בין חלופות כדי לוודא שאין פתרונות חלופיים לקליקהאוס, בהתאם לדרישות שלנו.

בנוסף לדרישות האחסון שכבר צוינו, הופיעו חדשות:

• המערכת החדשה צריכה לספק לפחות את אותם ביצועים כמו MySQL על אותה כמות חומרה;
• האחסון של המערכת החדשה אמור לתפוס פחות מקום באופן משמעותי;
• ה-DBMS עדיין חייב להיות קל לניהול;
• רציתי לשנות את האפליקציה באופן מינימלי בעת שינוי ה-DBMS.

אילו מערכות התחלנו לשקול?

Apache Hive/Apache Impala
ערימת Hadoop ישנה שנבדקה בקרב. בעיקרו של דבר, זהו ממשק SQL שנבנה על גבי אחסון נתונים בפורמטים מקוריים ב-HDFS.

מקצוענים.

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

חסרונות.

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

עם זאת:

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

דרואיד/פינו

יש הרבה יותר על TSDB באופן ספציפי, אבל שוב, מחסנית Hadoop.

יש מאמר נהדר המשווה את היתרונות והחסרונות של דרואיד ופינו לעומת קליקהאוס .

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

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

במקרים הפוכים, ClickHouse מתפקד טוב יותר, וזה המקרה שלנו.

קליקהאוס

• דמוי SQL
• קל לניהול.
• אנשים אומרים שזה עובד.

מקבל רשימה קצרה לבדיקה.

InfluxDB

אלטרנטיבה זרה לקליקהאוס. מהחסרונות: זמינות גבוהה קיימת רק בגרסה המסחרית, אבל צריך להשוות אותה.

מקבל רשימה קצרה לבדיקה.

קסנדרה

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

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

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

פרומתאוס

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

מתודולוגיית בדיקה ותוצאות

אז, בדקנו 5 מסדי נתונים ב-6 התצורות הבאות: ClickHouse (צומת אחד), ClickHouse (טבלה מבוזרת ל-1 צמתים), InfluxDB, Mysql 3, Cassandra (8 צמתים) ו-Prometheus. תוכנית הבדיקה היא כדלקמן:

1. העלה נתונים היסטוריים למשך שבוע (840 מיליון ערכים ליום; 208 אלף מדדים);
2. אנו יוצרים עומס הקלטה (נחשבו 6 מצבי עומס, ראה להלן);
3. במקביל להקלטה, אנו מבצעים מדי פעם בחירות, תוך חיקוי בקשות של משתמש שעובד עם תרשימים. כדי לא לסבך את הדברים יותר מדי, בחרנו נתונים עבור 10 מדדים (זה בדיוק כמה שיש בגרף המעבד) למשך שבוע.

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

• המספר הכולל של מדדים שאליהם נכתבים נתונים;
• מרווח לשליחת ערכים למדד אחד;
• גודל אצווה.

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

כמו כן, כדי להבין טוב יותר כיצד לפרש את הנתונים שהתקבלו, בואו נדמיין שאנחנו לא רק שולחים חבורה של מדדים, אלא המדדים מאורגנים בשרתים - 125 מדדים לשרת. כאן השרת הוא פשוט ישות וירטואלית - רק כדי להבין, למשל, 10000 מדדים תואמים כ-80 שרתים.

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

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

תוצאות הבדיקה הן כדלקמן:

מה כדאי לשים לב: דגימות מהירות להפליא מ-Prometheus, דגימות איטיות להחריד מקסנדרה, דגימות איטיות בצורה בלתי מקובלת מ-InfluxDB; מבחינת מהירות הקלטה, קליקהאוס ניצחה את כולם, ופרומתאוס לא משתתפת בתחרות, כי היא מייצרת בעצמה תוספות ואנחנו לא מודדים כלום.

כתוצאה מכך,: ClickHouse ו-InfluxDB הראו את עצמם כטובים ביותר, אבל ניתן לבנות אשכול מ-Influx רק על בסיס גרסת ה-Enterprise, שעולה כסף, בעוד ש-ClickHouse לא עולה כלום ומיוצרת ברוסיה. זה הגיוני שבארה"ב הבחירה היא כנראה בעד inInfluxDB, ובמדינה שלנו היא בעד ClickHouse.

מקור: www.habr.com