כעס, מיקוח ודיכאון בעבודה עם InfluxDB

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

כתב ויתור: הבעיות המפורטות חלות על InfluxDB גרסה 1.7.4.

למה סדרות זמן?

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

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

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

זה היה קצת מבלבל שמאגרי מידע כאלה משמשים בדרך כלל למטרת איסוף מדדים. ניטור שרתים, מכשירי iot, כל מה שממנו "זורמים" מיליוני נקודות של הצורה: [<time> - <ערך מטרי>]. אבל אם מסד הנתונים עובד היטב עם זרימת נתונים גדולה, אז למה נפח קטן צריך לגרום לבעיות? עם זה בחשבון, לקחנו את InfluxDB לעבודה.

מה עוד נוח ב-InfluxDB

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

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

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

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

לגבי נתונים מאוחסנים

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

בעיות

במהלך הפיתוח והבדיקה שלאחר מכן של השירות, התעוררו עוד ועוד בעיות קריטיות בתפעול של InfluxDB.

1. מחיקת נתונים

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

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

תוצאה:

אני שולח פקודה למחיקת נתונים:

DELETE FROM transactions WHERE symbol=’USDT’

בשלב הבא אני מבקש לקבל את הנתונים שכבר נמחקו. ובמקום תגובה ריקה, Influx מחזירה חלק מהנתונים שאמורים להימחק.

אני מנסה למחוק את כל הטבלה:

DROP MEASUREMENT transactions

אני בודק את מחיקת הטבלה:

SHOW MEASUREMENTS

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

הבעיה עלתה לי רק פעם אחת, שכן מקרה המחיקה היה מקרה בודד. אבל התנהגות זו של מסד הנתונים בבירור אינה מתאימה למסגרת של פעולה "נכונה". מאוחר יותר מצאתי את זה פתוח ב-github כַּרְטִיס לפני כמעט שנה בנושא זה.

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

2. מספרי נקודה צפה

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

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

3. לא ניתן להתאים שאילתות רציפות לאזורי זמן שונים

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

ב-InfluxDB, בעת קיבוץ לפי זמן, אתה יכול בנוסף לציין תזוזה, למשל עבור זמן מוסקבה (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

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

כדי לעקוף את הבעיה הזו, העברנו את השירות באופן זמני ל-UTC+0.

4. ביצועים

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

אני אספר לך את המקרה שלי.

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

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

הֶסבֵּר:

1. בבקשה הראשונה, אנו מקבלים את הנקודות האחרונות עבור כל מטבע עם נתוני שוק. שמונה נקודות עבור שמונה מטבעות במקרה שלי.
2. הבקשה השנייה מקבלת את אחת הנקודות החדשות ביותר.
3. השלישית מבקשת רשימה של עסקאות עבור XNUMX השעות האחרונות; עשויות להיות כמה מאות מהן.

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

הפעלתי מבחן מאמץ על שיטת ה-API הזו. עבור 25 RPS, השרת הדגים עומס מלא של שישה מעבדים:

יחד עם זאת, תהליך NodeJs לא סיפק עומס כלל.

מהירות הביצוע כבר ירדה ב-7-10 RPS: אם לקוח אחד יכול לקבל תגובה תוך 200 אלפיות השנייה, אז 10 לקוחות נאלצו להמתין שנייה. 25 RPS הוא הגבול שבו סבלה היציבות; 500 שגיאות הוחזרו ללקוחות.

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

פלט

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

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

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

מקור: www.habr.com