🥇خشم، چانه زنی و افسردگی هنگام کار با InfluxDB

اگر از پایگاه داده سری زمانی استفاده می کنید (سری های زمانی db، ویکی) به عنوان ذخیره اصلی برای یک سایت با آمار، به جای حل مشکل، می توانید سردردهای زیادی داشته باشید. من روی پروژه ای کار می کنم که از چنین پایگاه داده ای استفاده می کند، و گاهی اوقات InfluxDB که در مورد آن بحث خواهد شد، به طور کلی شگفتی های غیر منتظره ارائه می دهد.

سلب مسئولیتتوجه: مشکلات نشان داده شده برای InfluxDB 1.7.4 هستند.

چرا سری زمانی؟

این پروژه برای ردیابی تراکنش ها در بلاک چین های مختلف و نمایش آمار است. به طور خاص، ما به انتشار و سوزاندن سکه های پایدار نگاه می کنیم (ویکی). بر اساس این تراکنش ها، باید نمودارهایی بسازید و جداول محوری را نشان دهید.

هنگام تجزیه و تحلیل تراکنش ها، ایده ای مطرح شد: استفاده از پایگاه داده سری زمانی InfluxDB به عنوان ذخیره اصلی. تراکنش ها نقاط زمانی هستند و به خوبی با مدل سری زمانی مطابقت دارند.

توابع تجمع نیز بسیار راحت به نظر می رسید - آنها برای پردازش نمودارها با دوره طولانی ایده آل هستند. کاربر به یک نمودار برای یک سال نیاز دارد و پایگاه داده شامل یک مجموعه داده با بازه زمانی پنج دقیقه است. ارسال تمام صد هزار امتیاز برای او بی معنی است - به جز یک پردازش طولانی، آنها روی صفحه قرار نمی گیرند. شما می توانید پیاده سازی خود را برای افزایش بازه زمانی بنویسید یا از توابع تجمیع ساخته شده در Influx استفاده کنید. با کمک آنها می توانید داده ها را بر اساس روز گروه بندی کنید و 365 امتیاز مورد نظر را ارسال کنید.

کمی خجالت آور بود که معمولاً از چنین پایگاه های داده ای برای جمع آوری معیارها استفاده می شود. نظارت بر سرورها، دستگاه‌های iot، همه چیزهایی که میلیون‌ها نقطه از آن شکل «جریان» دارند: [<زمان> - <مقدار متریک>]. اما اگر پایگاه داده با یک جریان داده بزرگ به خوبی کار می کند، پس چرا حجم کم باید مشکل ایجاد کند؟ با این فکر، InfluxDB را وارد کار کردند.

چه چیز دیگری در InfluxDB راحت است

علاوه بر توابع تجمع ذکر شده، یک چیز عالی دیگر وجود دارد - پرس و جوهای مداوم (توضیحات). این یک زمانبندی است که در پایگاه داده تعبیه شده است که می تواند داده ها را بر اساس یک زمان بندی پردازش کند. به عنوان مثال، شما می توانید تمام رکوردهای روز را هر 24 ساعت گروه بندی کنید، میانگین را محاسبه کنید و یک امتیاز جدید را بدون نوشتن دوچرخه های خود در جدول دیگری بنویسید.

نیز وجود دارد سیاست های نگهداری (توضیحات) - تنظیم برای حذف داده ها پس از یک دوره معین. زمانی مفید است که، برای مثال، شما نیاز به ذخیره بار روی CPU برای یک هفته با اندازه گیری یک بار در ثانیه دارید، اما در فاصله چند ماهه، چنین دقتی لازم نیست. در چنین شرایطی می توانید این کار را انجام دهید:

ایجاد یک پرس و جو پیوسته برای تجمیع داده ها در جدول دیگری.
برای جدول اول، سیاستی برای حذف معیارهایی که از همان هفته قدیمی تر هستند، تعریف کنید.

و Influx حجم داده ها را کاهش می دهد و داده های غیر ضروری را خود به خود حذف می کند.

درباره داده های ذخیره شده

داده های زیادی ذخیره نمی شود: حدود 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 ارائه می دهد که آمار XNUMX ساعت گذشته را برمی گرداند. در طول محاسبات، متد با پرس و جوهای زیر از پایگاه داده سه بار پرس و جو می کند:

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

توضیح:

در اولین درخواست، آخرین امتیاز هر سکه را با داده های بازار دریافت می کنیم. هشت نقطه برای هشت سکه در مورد من.
درخواست دوم یک امتیاز جدید دریافت می کند.
نفر سوم لیستی از تراکنش های XNUMX ساعت گذشته را درخواست می کند، ممکن است چند صد مورد از آنها وجود داشته باشد.

اجازه دهید روشن کنم که در InfluxDB، یک فهرست به طور خودکار توسط برچسب ها و زمان ساخته می شود، که سرعت جستجوها را افزایش می دهد. در اولین درخواست نماد یک برچسب است

من برای این روش API تست استرس انجام دادم. برای 25 RPS، سرور یک بار کامل از شش CPU را نشان داد:

در عین حال، فرآیند NodeJs به هیچ وجه بارگذاری نمی کرد.

سرعت اجرا در حال حاضر 7-10 RPS کاهش یافته است: اگر یک کلاینت بتواند پاسخی را در 200 میلی ثانیه دریافت کند، 10 کلاینت باید برای یک ثانیه منتظر بمانند. 25 RPS - مرزی که از آن ثبات رنج می برد، 500 خطا به مشتریان بازگردانده شد.

با چنین عملکردی، استفاده از Influx در پروژه ما غیرممکن است. علاوه بر این، در پروژه‌ای که نیاز است نظارت به بسیاری از مشتریان نشان داده شود، ممکن است مشکلات مشابهی ظاهر شود و سرور متریک بیش از حد بارگذاری شود.

نتیجه

مهمترین نتیجه از تجربه به دست آمده این است که شما نمی توانید یک فناوری ناشناخته را بدون تجزیه و تحلیل کافی وارد پروژه کنید. یک غربالگری ساده از بلیط های باز در github می تواند اطلاعاتی را برای عدم استفاده از InfluxDB به عنوان ذخیره اصلی داده ارائه دهد.

قرار بود InfluxDB به خوبی با وظایف پروژه من مطابقت داشته باشد، اما همانطور که تمرین نشان داده است، این پایگاه داده پاسخگوی نیازها نیست و خیلی به هم می ریزد.

در حال حاضر می توانید نسخه 2.0.0-بتا را در مخزن پروژه پیدا کنید، باید امیدوار بود که در نسخه دوم پیشرفت های قابل توجهی وجود داشته باشد. در ضمن، من به مطالعه مستندات TimescaleDB خواهم پرداخت.

منبع: www.habr.com

عصبانیت، چانه زنی و افسردگی هنگام کار با InfluxDB