נבחן כיצד Zabbix עובד עם מסד הנתונים TimescaleDB בתור ה-backend. נראה לך איך להתחיל מאפס וכיצד לעבור מ-PostgreSQL. אנו נספק גם מבחני ביצועים השוואתיים של שתי התצורות.
HighLoad++ סיביר 2019. אולם טומסק. 24 ביוני, 16:00. תזות ו . כנס HighLoad++ הבא יתקיים ב-6 וב-7 באפריל 2020 בסנט פטרסבורג. פרטים וכרטיסים .
אנדריי גושצ'ין (להלן - AG): – אני מהנדס תמיכה טכנית של ZABBIX (להלן "Zabbix"), מאמן. אני עובד בתמיכה טכנית יותר מ-6 שנים ויש לי ניסיון ישיר בביצועים. היום אדבר על הביצועים ש-TimescaleDB יכול לספק בהשוואה ל-PostgreSQL 10 רגיל. כמו כן, חלק מבוא על איך זה עובד באופן כללי.
אתגרי הפרודוקטיביות המובילים: מאיסוף נתונים ועד ניקוי נתונים
מלכתחילה, ישנם אתגרי ביצועים מסוימים שעומדים בפני כל מערכת ניטור. אתגר הפרודוקטיביות הראשון הוא איסוף ועיבוד נתונים במהירות.
מערכת ניטור טובה צריכה לקבל במהירות ובזמן את כל הנתונים, לעבד אותם לפי ביטויי טריגר, כלומר לעבד אותם לפי כמה קריטריונים (זה שונה במערכות שונות) ולשמור אותם במסד נתונים כדי להשתמש בנתונים האלה ב- עתיד.
אתגר הביצועים השני הוא אחסון היסטוריה. אחסן במסד נתונים לעתים קרובות וקבל גישה מהירה ונוחה למדדים אלו שנאספו לאורך תקופה. הדבר החשוב ביותר הוא שהנתונים האלה נוחים להשגה, להשתמש בהם בדוחות, גרפים, טריגרים, בכמה ערכי סף, להתראות וכו'.
אתגר הביצועים השלישי הוא ניקוי ההיסטוריה, כלומר, כאשר אתה מגיע לנקודה שבה אתה לא צריך לאחסן שום מדדים מפורטים שנאספו במשך 5 שנים (אפילו חודשים או חודשיים). חלק מהצמתי רשת נמחקו, או חלק מהמארחים, המדדים אינם נחוצים עוד מכיוון שהם כבר מיושנים וכבר לא נאספים. את כל זה צריך לנקות כדי שבסיס הנתונים שלך לא יגדל מדי. באופן כללי, ניקוי היסטוריית הוא לרוב מבחן רציני לאחסון - לרוב יש לה השפעה חזקה מאוד על הביצועים.
כיצד לפתור בעיות שמירה במטמון?
עכשיו אדבר ספציפית על Zabbix. ב-Zabbix, הקריאה הראשונה והשנייה נפתרות באמצעות מטמון.
איסוף ועיבוד נתונים - אנו משתמשים בזיכרון RAM כדי לאחסן את כל הנתונים הללו. נתונים אלה יידונו כעת ביתר פירוט.
גם בצד מסד הנתונים יש קצת מטמון לבחירות עיקריות - לגרפים ודברים אחרים.
שמירה במטמון בצד שרת Zabbix עצמו: יש לנו ConfigurationCache, ValueCache, HistoryCache, TrendsCache. מה זה?
ConfigurationCache הוא המטמון הראשי בו אנו מאחסנים מדדים, מארחים, פריטי נתונים, טריגרים; כל מה שאתה צריך כדי לעבד עיבוד מקדים, לאסוף נתונים, מאיזה מארחים לאסוף, באיזו תדירות. כל זה מאוחסן ב-ConfigurationCache כדי לא לעבור לבסיס הנתונים וליצור שאילתות מיותרות. לאחר הפעלת השרת, אנו מעדכנים את המטמון הזה (יוצרים אותו) ומעדכנים אותו מעת לעת (בהתאם להגדרות התצורה).
מטמון ב-Zabix. איסוף נתונים
כאן התרשים די גדול:
העיקריים בתוכנית הם האספנים האלה:
אלו הם תהליכי ההרכבה עצמם, "פולרים" שונים שאחראים על סוגים שונים של מכלולים. הם אוספים נתונים באמצעות icmp, ipmi ופרוטוקולים שונים ומעבירים את הכל לעיבוד מקדים.
PreProcessing HistoryCache
כמו כן, אם יש לנו רכיבי נתונים מחושבים (מי שמכיר את Zabbix יודע), כלומר רכיבי נתוני צבירה מחושבים, אנחנו לוקחים אותם ישירות מ-ValueCache. אני אגיד לך איך זה מתמלא אחר כך. כל האספנים האלה משתמשים ב-ConfigurationCache כדי לקבל את העבודות שלהם ואז להעביר אותם לעיבוד מקדים.
עיבוד מוקדם משתמש גם ב-ConfigurationCache כדי להשיג שלבי עיבוד מקדים ומעבד נתונים אלה בדרכים שונות. החל מגרסה 4.2, העברנו אותו ל-proxy. זה מאוד נוח, כי העיבוד המקדים עצמו הוא פעולה קשה למדי. ואם יש לך Zabbix מאוד גדולה, עם מספר רב של רכיבי נתונים ותדירות איסוף גבוהה, אז זה מאוד מפשט את העבודה.
בהתאם לכך, לאחר שעיבדנו את הנתונים הללו בדרך כלשהי באמצעות עיבוד מקדים, אנו שומרים אותם ב- HistoryCache על מנת לעבד אותם הלאה. בכך מסתיים איסוף הנתונים. נעבור לתהליך העיקרי.
עבודתו של סנכרון ההיסטוריה
התהליך העיקרי ב-Zabbix (מכיוון שמדובר בארכיטקטורה מונוליטית) הוא סינכרון ההיסטוריה. זהו התהליך העיקרי העוסק ספציפית בעיבוד האטומי של כל אלמנט נתונים, כלומר כל ערך:
- הערך מגיע (הוא לוקח אותו מההיסטוריהCache);
- בודק בסינכרון Configuration: האם ישנם טריגרים לחישוב - מחשב אותם;
אם יש - יוצר אירועים, יוצר הסלמה על מנת ליצור התראה, במידת הצורך לפי התצורה; - רשומות טריגרים לעיבוד עוקב, צבירה; אם אתה מצטבר במהלך השעה האחרונה וכן הלאה, הערך הזה נזכר על ידי ValueCache כדי לא לעבור לטבלת ההיסטוריה; לפיכך, ה-ValueCache מתמלא בנתונים הדרושים הדרושים לחישוב טריגרים, אלמנטים מחושבים וכו';
- אז סינכרון ההיסטוריה כותב את כל הנתונים למסד הנתונים;
- מסד הנתונים כותב אותם לדיסק - כאן מסתיים תהליך העיבוד.
מאגר מידע. שמירה במטמון
בצד מסד הנתונים, כאשר אתה רוצה להציג גרפים או כמה דוחות על אירועים, ישנם מטמונים שונים. אבל בדוח הזה לא אדבר עליהם.
עבור MySQL יש Innodb_buffer_pool, וחבורה של מטמונים שונים שניתן גם להגדיר.
אבל אלה העיקריים שבהם:
- מאגר_משותף;
- גודל_מטמון יעיל;
- בריכה משותפת.
עבור כל מסדי הנתונים, אמרתי שיש מטמונים מסוימים המאפשרים לך לאחסן ב-RAM את הנתונים הדרושים לרוב עבור שאילתות. יש להם טכנולוגיות משלהם בשביל זה.
על ביצועי מסד נתונים
בהתאם לכך, קיימת סביבה תחרותית, כלומר שרת Zabbix אוסף נתונים ורושם אותם. כאשר הוא מופעל מחדש, הוא גם קורא מההיסטוריה כדי למלא את ValueCache וכן הלאה. כאן תוכלו לקבל סקריפטים ודוחות המשתמשים ב-Zabbix API, שבנוי על ממשק אינטרנט. Zabbix API נכנס למסד הנתונים ומקבל את הנתונים הדרושים כדי להשיג גרפים, דוחות, או איזושהי רשימה של אירועים, בעיות אחרונות.
כמו כן, פתרון הדמיה פופולרי מאוד הוא Grafana, שבו משתמשים המשתמשים שלנו. מסוגל להתחבר ישירות הן דרך ה-API של Zabbix והן דרך מסד הנתונים. זה גם יוצר תחרות מסויימת להשגת נתונים: יש צורך בכוונון עדין וטוב יותר של מסד הנתונים כדי לעמוד במשלוח המהיר של תוצאות ובדיקות.
ניקוי היסטוריה. לזאביקס יש עוזרת בית
השיחה השלישית שבה נעשה שימוש ב- Zabbix היא ניקוי היסטוריה באמצעות Housekeeper. עוזרת בית עוקבת אחר כל ההגדרות, כלומר, רכיבי הנתונים שלנו מציינים כמה זמן לאחסן (בימים), כמה זמן לאחסן מגמות ודינמיקה של שינויים.
לא דיברתי על TrendCache, אותו אנו מחשבים תוך כדי תנועה: מגיעים נתונים, אנו צוברים אותם לשעה אחת (לרוב אלו מספרים של השעה האחרונה), הכמות היא ממוצעת/מינימלית ואנחנו רושמים אותה פעם בשעה ב- טבלת הדינמיקה של שינויים ("מגמות"). "עוזר בית" מתחיל ומוחק נתונים ממסד הנתונים באמצעות בחירות רגילות, מה שלא תמיד יעיל.
איך להבין שזה לא יעיל? אתה יכול לראות את התמונה הבאה על גרפי הביצועים של תהליכים פנימיים:
סנכרון ההיסטוריה שלך עסוק כל הזמן (גרף אדום). והגרף ה"אדום" שהולך למעלה. זהו "עוזר בית" שמתחיל וממתין לבסיס הנתונים כדי למחוק את כל השורות שהוא ציין.
בואו ניקח כמה מזהה פריט: אתה צריך למחוק את 5 האחרונים; כמובן לפי אינדקסים. אבל בדרך כלל מערך הנתונים הוא די גדול - מסד הנתונים עדיין קורא אותו מהדיסק ומכניס אותו למטמון, וזו פעולה מאוד יקרה עבור מסד הנתונים. בהתאם לגודלו, זה יכול להוביל לבעיות ביצועים מסוימות.
אתה יכול להשבית את Housekeeper בצורה פשוטה - יש לנו ממשק אינטרנט מוכר. הגדרות בניהול כללי (הגדרות עבור "עוזר בית") אנו משביתים את ניהול הבית הפנימי להיסטוריה ומגמות פנימיות. לפיכך, עוזרת הבית כבר לא שולטת בזה:
מה אתה יכול לעשות הלאה? כיבית את זה, הגרפים שלך התיישרו... אילו בעיות נוספות עלולות להתעורר במקרה הזה? מה יכול לעזור?
חלוקה למחיצות (חתך)
בדרך כלל זה מוגדר בצורה שונה בכל מסד נתונים יחסי שרשמתי. ל-MySQL יש טכנולוגיה משלה. אבל בסך הכל הם דומים מאוד כשמדובר ב-PostgreSQL 10 ו-MySQL. כמובן, יש הרבה הבדלים פנימיים באופן שבו הכל מיושם ובאופן שבו הכל משפיע על הביצועים. אבל באופן כללי, יצירת מחיצה חדשה מובילה לעתים קרובות גם לבעיות מסוימות.
בהתאם להגדרה שלך (כמה נתונים אתה יוצר ביום אחד), הם בדרך כלל מגדירים את המינימום - זה יום אחד / אצווה, ועבור "טרנדים", דינמיקה של שינויים - חודש / אצווה חדשה. זה עשוי להשתנות אם יש לך הגדרה גדולה מאוד.
בואו נגיד מיד על גודל ההגדרה: עד 5 ערכים חדשים לשנייה (מה שנקרא nvps) - זה ייחשב ל"התקנה" קטנה. ממוצע - מ 5 עד 25 אלף ערכים לשנייה. כל מה שלמעלה זה כבר התקנות גדולות וגדולות מאוד הדורשות הגדרה זהירה מאוד של מסד הנתונים.
בהתקנות גדולות מאוד, ייתכן שיום אחד לא יהיה אופטימלי. אני אישית ראיתי מחיצות ב-MySQL של 1 גיגה-בייט ליום (ואולי יש יותר). מדובר בכמות גדולה מאוד של נתונים, שעלולה להוביל לבעיות מסוימות. צריך לצמצם.
למה צריך חלוקה למחיצות?
מה ש- Partitioning מספק, אני חושב שכולם יודעים, הוא חלוקת שולחן. לעתים קרובות מדובר בקבצים נפרדים בדיסק ובקשות טווח. הוא בוחר מחיצה אחת בצורה אופטימלית יותר אם היא חלק מחלוקה רגילה.
עבור Zabbix, במיוחד, הוא משמש לפי טווח, לפי טווח, כלומר, אנו משתמשים בחותמת זמן (מספר רגיל, זמן מאז תחילת העידן). אתה מציין את תחילת היום/סוף היום, וזו המחיצה. בהתאם לכך, אם אתם מבקשים נתונים בני יומיים, הכל מאוחזר מהמסד מהר יותר, כי צריך רק לטעון קובץ אחד למטמון ולהחזיר אותו (ולא טבלה גדולה).
מסדי נתונים רבים גם מאיצים את ההוספה (הוספה לטבלה צאצאית אחת). אני מדבר באופן מופשט לעת עתה, אבל זה גם אפשרי. חלוקה לרוב עוזרת.
Elasticsearch עבור NoSQL
לאחרונה, ב-3.4, הטמענו פתרון NoSQL. נוספה את היכולת לכתוב ב- Elasticsearch. אתה יכול לכתוב סוגים מסוימים: אתה בוחר - או לכתוב מספרים או כמה סימנים; יש לנו טקסט מחרוזת, אתה יכול לכתוב יומנים ל- Elasticsearch... בהתאם, ממשק האינטרנט ייגש גם ל- Elasticsearch. זה עובד מצוין במקרים מסוימים, אבל כרגע ניתן להשתמש בו.
TimescaleDB. היפר טבלאות
עבור 4.4.2 שמנו לב לדבר אחד כמו TimescaleDB. מה זה? זוהי הרחבה עבור PostgreSQL, כלומר, יש לה ממשק PostgreSQL מקורי. בנוסף, הרחבה זו מאפשרת לך לעבוד בצורה יעילה הרבה יותר עם נתוני סדרות זמן ולבצע חלוקה אוטומטית. כמו מה זה נראה:
זה hypertable - יש מושג כזה ב-Timescale. זהו היפרטבל שאתה יוצר, והוא מכיל נתחים. נתחים הם מחיצות, אלה שולחנות ילדים, אם אני לא טועה. זה ממש יעיל.
TimescaleDB ו-PostgreSQL
כפי שיצרני TimescaleDB מבטיחים, הם משתמשים באלגוריתם נכון יותר לעיבוד שאילתות, במיוחד תוספות, מה שמאפשר ביצועים קבועים בערך עם גודל גדל והולך של הוספת הנתונים. כלומר, אחרי 200 מיליון שורות של Postgres, הרגילה מתחילה לצנוח מאוד ומאבדת ביצועים ממש לאפס, בעוד Timescale מאפשרת להכניס תוספות בצורה יעילה ככל האפשר עם כל כמות נתונים.
כיצד להתקין את TimescaleDB? זה פשוט!
זה בתיעוד, זה מתואר - אתה יכול להתקין את זה מחבילות לכל... זה תלוי בחבילות הרשמיות של Postgres. ניתן להרכיב באופן ידני. כך קרה שנאלצתי לבצע קומפילציה עבור בסיס הנתונים.
ב-Zabbix אנחנו פשוט מפעילים Extention. אני חושב שמי שהשתמש ב-Extention ב-Postgres... אתה פשוט מפעיל את Extention, יוצר אותה עבור מסד הנתונים של Zabbix שבו אתה משתמש.
והשלב האחרון...
TimescaleDB. הגירה של טבלאות היסטוריה
אתה צריך ליצור היפרטבל. יש פונקציה מיוחדת לכך - צור היפרטבל. בו, הפרמטר הראשון הוא הטבלה הדרושה במסד נתונים זה (שעבורו אתה צריך ליצור hypertable).
השדה שלפיו ליצור, ו-chunk_time_interval (זהו המרווח של chunks (מחיצות שצריך להשתמש בהן). 86 זה יום אחד.
פרמטר Migrate_data: אם תוסיף ל-true, זה יעביר את כל הנתונים הנוכחיים לנתחים שנוצרו מראש.
השתמשתי בעצמי ב-migrate_data - זה לוקח הרבה זמן, תלוי בגודל בסיס הנתונים שלך. היה לי יותר מטרה-בייט - לקח יותר משעה ליצור. בחלק מהמקרים, במהלך הבדיקה, מחקתי נתונים היסטוריים עבור טקסט (history_text) ו-string (history_str) כדי לא להעביר אותם - הם לא ממש עניינו אותי.
ואנחנו מבצעים את העדכון האחרון ב-db_extention שלנו: אנחנו מתקינים את timescaledb כך שבסיס הנתונים ובמיוחד Zabbix שלנו יבינו שיש db_extention. הוא מפעיל אותו ומשתמש בתחביר הנכונים ובשאילתות למסד הנתונים, תוך שימוש באותן "תכונות" הנחוצות עבור TimescaleDB.
תצורת שרת
השתמשתי בשני שרתים. השרת הראשון הוא מכונה וירטואלית קטנה למדי, 20 מעבדים, 16 גיגה-בייט של זיכרון RAM. הגדרתי בו את Postgres 10.8:
מערכת ההפעלה הייתה דביאן, מערכת הקבצים הייתה xfs. ביצעתי הגדרות מינימליות לשימוש במסד הנתונים המסוים הזה, פחות מה Zabbix עצמה תשתמש. על אותה מכונה היה שרת Zabbix, PostgreSQL וסוכני עומס.
השתמשתי ב-50 סוכנים פעילים המשתמשים ב-LoadableModule כדי ליצור במהירות תוצאות שונות. הם אלו שיצרו את המחרוזות, המספרים וכו'. מילאתי את מסד הנתונים בהרבה נתונים. בתחילה, התצורה הכילה 5 רכיבי נתונים לכל מארח, ובערך כל אלמנט נתונים הכיל טריגר - על מנת שזו תהיה הגדרה אמיתית. לפעמים אתה אפילו צריך יותר מטריגר אחד לשימוש.
הסדרתי את מרווח העדכון ואת העומס עצמו על ידי שימוש לא רק ב-50 סוכנים (הוספת עוד), אלא גם באמצעות רכיבי נתונים דינמיים והפחתת מרווח העדכון ל-4 שניות.
מבחן ביצועים. PostgreSQL: 36 אלף NVPs
ההשקה הראשונה, ההגדרה הראשונה שהייתה לי הייתה על PostreSQL 10 טהור בחומרה זו (35 אלף ערכים לשנייה). באופן כללי, כפי שניתן לראות על המסך, הכנסת נתונים אורכת שברירי שנייה - הכל טוב ומהיר, כונני SSD (200 גיגה-בייט). הדבר היחיד הוא ש-20 GB מתמלא די מהר.
יהיו די הרבה גרפים כאלה בעתיד. זהו לוח מחוונים סטנדרטי לביצועי שרת Zabbix.
הגרף הראשון הוא מספר הערכים לשנייה (כחול, שמאל למעלה), 35 אלף ערכים במקרה זה. זו (במרכז למעלה) הטעינה של תהליכי בנייה, וזו (מימין למעלה) הטעינה של תהליכים פנימיים: מסנכרני היסטוריה ועוזרת בית, שכאן (במרכז למטה) פועלת כבר די הרבה זמן.
גרף זה (במרכז התחתון) מציג את השימוש ב-ValueCache - כמה כניסות של ValueCache לטריגרים (כמה אלפי ערכים בשנייה). גרף חשוב נוסף הוא הרביעי (למטה משמאל), שמראה את השימוש ב- HistoryCache, עליו דיברתי, שהוא חוצץ לפני ההכנסה למסד הנתונים.
מבחן ביצועים. PostgreSQL: 50 אלף NVPs
לאחר מכן, העליתי את העומס ל-50 אלף ערכים לשנייה על אותה חומרה. בעת טעינה על ידי עוזרת הבית, נרשמו 10 אלף ערכים תוך 2-3 שניות בחישוב. מה, למעשה, מוצג בצילום המסך הבא:
"סוכנת בית" כבר מתחילה להפריע לעבודה, אבל באופן כללי, העומס על לוכדי ההיסטוריה עדיין ברמה של 60% (גרף שלישי, למעלה מימין). HistoryCache כבר מתחיל להתמלא באופן פעיל בזמן שה-Housekeeper פועל (משמאל למטה). זה היה בערך חצי גיגה-בייט, 20% מלא.
מבחן ביצועים. PostgreSQL: 80 אלף NVPs
ואז הגדלתי את זה ל-80 אלף ערכים לשנייה:
זה היה בערך 400 אלף רכיבי נתונים, 280 אלף טריגרים. האינסרט, כפי שניתן לראות, מבחינת עומס שוקעי ההיסטוריה (היו 30 כאלה) כבר היה די גבוה. לאחר מכן הגדלתי פרמטרים שונים: שוקעי היסטוריה, מטמון... בחומרה זו, העומס על שוקעי היסטוריה החל לעלות למקסימום, כמעט "על המדף" - בהתאם, HistoryCache נכנס לעומס גבוה מאוד:
כל הזמן הזה עקבתי אחר כל פרמטרי המערכת (איך משתמשים במעבד, RAM) וגיליתי שניצול הדיסק היה מקסימלי – השגתי את הקיבולת המקסימלית של הדיסק הזה בחומרה הזו, במכונה הוירטואלית הזו. "פוסטגרס" החל לזרוק נתונים די פעיל בעוצמה כזו, ולדיסק כבר לא היה זמן לכתוב, לקרוא...
לקחתי שרת אחר שכבר היה לו 48 מעבדים ו-128 גיגה-בייט של זיכרון RAM:
גם "כינתי" אותו - התקנתי את היסטוריית סינכרון (60 חלקים) והשגתי ביצועים מקובלים. למעשה, אנחנו לא "על המדף", אבל זה כנראה גבול התפוקה, שבו כבר צריך לעשות משהו בנידון.
מבחן ביצועים. TimescaleDB: 80 אלף NVPs
המשימה העיקרית שלי הייתה להשתמש ב-TimescaleDB. כל גרף מציג צניחה:
כשלים אלה הם בדיוק העברת נתונים. לאחר מכן, בשרת Zabbix, פרופיל הטעינה של שוקעי היסטוריה, כפי שאתה יכול לראות, השתנה מאוד. זה מאפשר לך להכניס נתונים כמעט פי 3 מהר יותר ולהשתמש בפחות HistoryCache - בהתאם, הנתונים יסופקו בזמן. שוב, 80 אלף ערכים לשנייה הם שיעור גבוה למדי (כמובן, לא עבור Yandex). בסך הכל מדובר בהגדרה די גדולה, עם שרת אחד.
מבחן ביצועים של PostgreSQL: 120 אלף NVPs
לאחר מכן, הגדלתי את ערך מספר רכיבי הנתונים לחצי מיליון וקיבלתי ערך מחושב של 125 אלף לשנייה:
וקיבלתי את הגרפים האלה:
באופן עקרוני, מדובר בהגדרה עובדת, היא יכולה לעבוד די הרבה זמן. אבל מכיוון שהיה לי רק דיסק של 1,5 טרה-בייט, ניצלתי אותו תוך כמה ימים. הדבר החשוב ביותר הוא שבמקביל נוצרו מחיצות חדשות ב-TimescaleDB, וזה לא היה מורגש לחלוטין מבחינת הביצועים, מה שלא ניתן לומר על MySQL.
בדרך כלל, מחיצות נוצרות בלילה, מכיוון שבדרך כלל זה חוסם הכנסה ועבודה עם טבלאות ועלול להוביל לפגיעה בשירות. במקרה הזה זה לא המקרה! המשימה העיקרית הייתה לבדוק את היכולות של TimescaleDB. התוצאה הייתה הנתון הבא: 120 אלף ערכים לשנייה.
יש גם דוגמאות בקהילה:
האדם גם הפעיל את TimescaleDB והעומס על השימוש ב-io.weight ירד על המעבד; וגם השימוש ברכיבי תהליך פנימיים ירד עקב הכללת TimescaleDB. יתרה מכך, מדובר בדיסקים פנקייק רגילים, כלומר, מכונה וירטואלית רגילה על דיסקים רגילים (לא SSD)!
עבור כמה הגדרות קטנות המוגבלות על ידי ביצועי דיסק, TimescaleDB, לדעתי, הוא פתרון טוב מאוד. זה יאפשר לך להמשיך לעבוד לפני המעבר לחומרה מהירה יותר עבור מסד הנתונים.
אני מזמין את כולכם לאירועים שלנו: כנס במוסקבה, פסגה בריגה. השתמש בערוצים שלנו - טלגרם, פורום, IRC. אם יש לך שאלות, בוא לשולחן שלנו, נוכל לדבר על הכל.
שאלות קהל
שאלה מהקהל (להלן - א'): - אם TimescaleDB כל כך קל להגדיר, והוא נותן דחיפה כזו לביצועים, אז אולי זה צריך לשמש כדרך מומלצת להגדרת Zabbix עם Postgres? והאם יש מלכודות וחסרונות של הפתרון הזה, או שאחרי הכל, אם החלטתי לעשות את Zabbix לעצמי, אני יכול בקלות לקחת את Postgres, להתקין שם Timescale מיד, להשתמש בו ולא לחשוב על בעיות?
AG: – כן, הייתי אומר שזו המלצה טובה: השתמש ב-Postgres מיד עם הרחבה TimescaleDB. כפי שכבר אמרתי, הרבה ביקורות טובות, למרות העובדה שה"פיצ'ר" הזה הוא ניסיוני. אבל למעשה בדיקות מראות שזה פתרון מצוין (עם TimescaleDB) ואני חושב שהוא יתפתח! אנו עוקבים אחר האופן שבו הרחבה זו מתפתחת ונבצע שינויים במידת הצורך.
גם במהלך הפיתוח, הסתמכנו על אחת ה"פיצ'רים" הידועים שלהם: אפשר היה לעבוד עם נתחים קצת אחרת. אבל אז הם גזרו את זה במהדורה הבאה, והיינו צריכים להפסיק להסתמך על הקוד הזה. אני ממליץ להשתמש בפתרון זה בהגדרות רבות. אם אתה משתמש ב-MySQL... עבור הגדרות ממוצעות, כל פתרון עובד היטב.
וגם: - בגרפים האחרונים מהקהילה היה גרף עם "עוזר בית":
הוא המשיך לעבוד. מה עושה עוזרת בית עם TimescaleDB?
AG: - עכשיו אני לא יכול לומר בוודאות - אני אסתכל על הקוד ואספר לך בפירוט רב יותר. הוא משתמש בשאילתות TimescaleDB לא כדי למחוק נתחים, אלא כדי איכשהו לצבור אותם. אני עדיין לא מוכן לענות על השאלה הטכנית הזו. עוד היום או מחר נגלה בדוכן.
וגם: – יש לי שאלה דומה – לגבי ביצוע פעולת המחיקה ב-Timescale.
ת (תשובה מהקהל): – כאשר אתה מוחק נתונים מטבלה, אם אתה עושה זאת באמצעות Delete, אז אתה צריך לעבור על הטבלה - למחוק, לנקות, לסמן הכל לשואקום עתידי. ב-Timescale, מכיוון שיש לך נתחים, אתה יכול לרדת. באופן גס, אתה פשוט אומר לקובץ שנמצא ב-Big Data: "מחק!"
סקאלת זמן פשוט מבינה שחלק כזה כבר לא קיים. ומכיוון שהוא משולב במתכנן השאילתות, הוא משתמש ב-hooks כדי לתפוס את התנאים שלך בפעולות נבחרות או אחרות ומיד מבין שהנתח הזה כבר לא קיים - "אני לא הולך לשם יותר!" (לא נתונים זמינים). זה הכל! כלומר, סריקת טבלה מוחלפת במחיקת קובץ בינארי, כך שהיא מהירה.
וגם: – כבר נגענו בנושא הלא-SQL. למיטב הבנתי, Zabbix לא באמת צריך לשנות את הנתונים, וכל זה הוא משהו כמו יומן. האם אפשר להשתמש בבסיסי נתונים מיוחדים שלא יכולים לשנות את הנתונים שלהם, אבל במקביל לשמור, לצבור ולהפיץ הרבה יותר מהר - קליקהאוס, למשל, משהו דמוי קפקא?.. קפקא הוא גם יומן! האם אפשר איכשהו לשלב אותם?
AG: - ניתן לבצע פריקה. יש לנו "תכונה" מסוימת מאז גרסה 3.4: אתה יכול לכתוב את כל הקבצים ההיסטוריים, האירועים, כל השאר לקבצים; ולאחר מכן שלח אותו לכל מסד נתונים אחר באמצעות מטפל כלשהו. למעשה, אנשים רבים עובדים מחדש וכותבים ישירות למסד הנתונים. תוך כדי תנועה, שוקעי היסטוריה כותבים את כל זה לקבצים, מסובבים את הקבצים האלה, וכן הלאה, ואתה יכול להעביר את זה לקליקהאוס. אני לא יכול לומר על תוכניות, אבל אולי תמיכה נוספת בפתרונות NoSQL (כגון Clickhouse) תימשך.
וגם: – בכלל, מסתבר שאפשר להיפטר לגמרי מפוסטגרס?
AG: – כמובן, החלק הקשה ביותר ב-Zabix הוא הטבלאות ההיסטוריות, שיוצרות הכי הרבה בעיות ואירועים. במקרה זה, אם אתה לא מאחסן אירועים במשך זמן רב ולאחסן את ההיסטוריה עם טרנדים באחסון מהיר אחר, אז באופן כללי, אני חושב, לא יהיו בעיות.
וגם: – האם אתה יכול להעריך כמה מהר יותר הכל יעבוד אם תעבור ל- Clickhouse, למשל?
AG: - לא בדקתי את זה. אני חושב שלפחות ניתן להשיג את אותם מספרים בפשטות, בהתחשב בכך של-Clickhouse יש ממשק משלה, אבל אני לא יכול לומר בוודאות. עדיף לבדוק. הכל תלוי בתצורה: כמה מארחים יש לך וכן הלאה. הכנסה היא דבר אחד, אבל אתה צריך גם לאחזר את הנתונים האלה - Grafana או משהו אחר.
וגם: – אז אנחנו מדברים על מאבק שווה, ולא על היתרון הגדול של מאגרי המידע המהירים האלה?
AG: - אני חושב שכאשר נשתלב, יהיו בדיקות מדויקות יותר.
וגם: – לאן נעלם RRD הישן והטוב? מה גרם לך לעבור לבסיסי נתונים של SQL? בתחילה, כל המדדים נאספו ב-RRD.
AG: – לזאביקס היה RRD, אולי בגרסה עתיקה מאוד. מאז ומתמיד היו מסדי נתונים של SQL – גישה קלאסית. הגישה הקלאסית היא MySQL, PostgreSQL (הם קיימים הרבה מאוד זמן). כמעט אף פעם לא השתמשנו בממשק משותף עבור מסדי נתונים של SQL ו-RRD.
כמה מודעות 🙂
תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, , אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).
Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על
מקור: www.habr.com
