الغضب والمساومة والاكتئاب عند العمل مع InfluxDB

إذا كنت تستخدم قاعدة بيانات سلاسل زمنية (سلاسل زمنية ديسيبل ، ويكي) كمخزن رئيسي لموقع يحتوي على إحصاءات ، فبدلاً من حل المشكلة ، يمكنك الحصول على الكثير من الصداع. أنا أعمل على مشروع يستخدم قاعدة البيانات هذه ، وأحيانًا InfluxDB ، التي ستتم مناقشتها ، قدمت مفاجآت غير متوقعة بشكل عام.

إخلاء المسئوليةملاحظة: المشكلات المعروضة خاصة بـ InfluxDB 1.7.4.

لماذا السلاسل الزمنية؟

يهدف المشروع إلى تتبع المعاملات في مختلف سلاسل الكتل وعرض الإحصائيات. على وجه التحديد ، ننظر إلى انبعاث وحرق العملات المعدنية المستقرة (ويكي). بناءً على هذه المعاملات ، تحتاج إلى إنشاء الرسوم البيانية وإظهار الجداول المحورية.

عند تحليل المعاملات ، ظهرت فكرة: استخدام قاعدة بيانات السلاسل الزمنية InfluxDB كمخزن رئيسي. المعاملات هي نقاط زمنية وتتناسب بشكل جيد مع نموذج السلاسل الزمنية.

بدت وظائف التجميع أيضًا مريحة للغاية - فهي مثالية لمعالجة المخططات ذات الفترة الطويلة. يحتاج المستخدم إلى رسم بياني لمدة عام ، وتحتوي قاعدة البيانات على مجموعة بيانات بإطار زمني مدته خمس دقائق. من غير المجدي إرسال كل مائة ألف نقطة إليه - باستثناء المعالجة الطويلة ، فلن يتم عرضها على الشاشة. يمكنك كتابة التنفيذ الخاص بك لزيادة الإطار الزمني ، أو استخدام وظائف التجميع المضمنة في Influx. بمساعدتهم ، يمكنك تجميع البيانات حسب اليوم وإرسال 365 نقطة المطلوبة.

كان من المحرج قليلاً أن تُستخدم قواعد البيانات هذه عادةً لجمع المقاييس. مراقبة الخوادم ، أجهزة iot ، كل شيء تنطلق منه ملايين النقاط من شكل "تدفق": [<time> - <metric value>]. ولكن إذا كانت قاعدة البيانات تعمل بشكل جيد مع تدفق بيانات كبير ، فلماذا يتسبب الحجم الصغير في حدوث مشكلات؟ مع هذا الفكر ، أخذوا InfluxDB للعمل.

ما هو مناسب في InfluxDB

بالإضافة إلى وظائف التجميع المذكورة ، هناك شيء رائع آخر - استفسارات مستمرة (الوثيقة). هذا هو برنامج جدولة مضمّن في قاعدة البيانات يمكنه معالجة البيانات وفقًا لجدول زمني. على سبيل المثال ، يمكنك تجميع جميع سجلات اليوم كل 24 ساعة ، وحساب المتوسط ​​وكتابة نقطة جديدة إلى جدول آخر دون كتابة دراجاتك الخاصة.

وهناك أيضا سياسات الاحتفاظ (الوثيقة) - الإعداد لحذف البيانات بعد فترة معينة. يكون مفيدًا ، على سبيل المثال ، عندما تحتاج إلى تخزين الحمل على وحدة المعالجة المركزية لمدة أسبوع بقياسات مرة واحدة في الثانية ، ولكن على مسافة شهرين ، لا تكون هذه الدقة مطلوبة. في مثل هذه الحالة ، يمكنك القيام بما يلي:

1. إنشاء استعلام مستمر لتجميع البيانات في جدول آخر ؛
2. بالنسبة للجدول الأول ، حدد سياسة لحذف المقاييس الأقدم من نفس الأسبوع.

وسيقوم Influx بتقليل حجم البيانات وحذف البيانات غير الضرورية من تلقاء نفسه.

حول البيانات المخزنة

لا يتم تخزين الكثير من البيانات: حوالي 70 ألف معاملة ومليون نقطة أخرى بمعلومات السوق. إضافة إدخالات جديدة - ما لا يزيد عن 3000 نقطة في اليوم. هناك أيضًا مقاييس للموقع ، ولكن هناك القليل من البيانات هناك ، ووفقًا لسياسة الاحتفاظ ، يتم تخزينها لمدة لا تزيد عن شهر.

مشاكل

أثناء التطوير والاختبار اللاحق للخدمة ، نشأت المزيد والمزيد من المشاكل الحرجة في تشغيل InfluxDB.

1. حذف البيانات

هناك سلسلة من البيانات مع المعاملات:

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

النتيجة:

أرسل أمرًا لحذف البيانات:

DELETE FROM transactions WHERE symbol=’USDT’

علاوة على ذلك ، أطلب الحصول على البيانات المحذوفة بالفعل. ويقوم التدفق ، بدلاً من الرد الفارغ ، بإرجاع جزء من البيانات يجب إزالته.

أحاول حذف الجدول بأكمله:

DROP MEASUREMENT transactions

أتحقق من حذف الجدول:

SHOW MEASUREMENTS

لا أرى الجدول في القائمة ، لكن استعلام البيانات الجديد لا يزال يُرجع مجموعة المعاملات نفسها.

نشأت المشكلة بالنسبة لي مرة واحدة فقط ، لأن حالة الحذف حالة منعزلة. لكن من الواضح أن سلوك قاعدة البيانات هذا لا يتناسب مع إطار العمل "الصحيح". في وقت لاحق وجدت جيثب مفتوحة تذكرة ما يقرب من عام في هذا الموضوع.

ونتيجة لذلك ، ساعدت إزالة قاعدة البيانات بأكملها واستعادتها لاحقًا.

2. أرقام الفاصلة العائمة

تعطي الحسابات الرياضية باستخدام وظائف InfluxDB المضمنة أخطاء دقيقة. لا يعني ذلك أنه كان شيئًا غير عادي ، ولكنه غير سار.

في حالتي ، تحتوي البيانات على مكون مالي وأود معالجتها بدقة عالية. لهذا السبب ، نخطط للتخلي عن الاستعلامات المستمرة.

3. لا يمكن تكييف الاستعلامات المستمرة مع مناطق زمنية مختلفة

تحتوي الخدمة على جدول بإحصائيات المعاملات اليومية. لكل يوم ، تحتاج إلى تجميع جميع المعاملات لذلك اليوم. لكن اليوم لكل مستخدم سيبدأ في وقت مختلف ، لذلك تختلف مجموعة المعاملات. التوقيت العالمي هو 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

التفسير:

1. في الطلب الأول ، نحصل على أحدث النقاط لكل عملة مع بيانات السوق. ثماني نقاط لثماني عملات في حالتي.
2. الطلب الثاني يحصل على نقطة واحدة جديدة.
3. أما الثالث فيطلب قائمة بالمعاملات خلال الـ XNUMX ساعة الماضية، وقد يكون هناك عدة مئات منها.

اسمحوا لي أن أوضح أنه في InfluxDB ، يتم إنشاء فهرس تلقائيًا بالعلامات وبمرور الوقت ، مما يؤدي إلى تسريع الاستعلامات. في الطلب الأول رمز هي علامة.

لقد أجريت اختبار تحمّل لطريقة API هذه. بالنسبة لـ 25 RPS ، أظهر الخادم حمولة كاملة من ست وحدات معالجة مركزية:

في الوقت نفسه ، لم تعط عملية NodeJs أي عبء على الإطلاق.

انخفضت سرعة التنفيذ بالفعل بمقدار 7-10 RPS: إذا كان بإمكان عميل واحد تلقي استجابة في 200 مللي ثانية ، فسيتعين على 10 عملاء الانتظار لمدة ثانية. 25 RPS - الحد الذي عانى منه الاستقرار ، تم إرجاع 500 خطأ للعملاء.

مع هذا الأداء ، من المستحيل استخدام Influx في مشروعنا. علاوة على ذلك ، في المشروع الذي تحتاج فيه المراقبة إلى إظهار للعديد من العملاء ، قد تظهر مشكلات مماثلة وسيتم تحميل خادم المقاييس بشكل زائد.

إنتاج

الاستنتاج الأكثر أهمية من التجربة المكتسبة هو أنه لا يمكنك استخدام تقنية غير معروفة في مشروع بدون تحليل كافٍ. يمكن أن يوفر الفحص البسيط للتذاكر المفتوحة على github معلومات عن عدم اعتبار InfluxDB بمثابة مخزن البيانات الرئيسي.

كان من المفترض أن يتناسب InfluxDB مع مهام مشروعي جيدًا ، ولكن كما أظهرت الممارسة ، فإن قاعدة البيانات هذه لا تلبي الاحتياجات وتعبث كثيرًا.

يمكنك بالفعل العثور على الإصدار 2.0.0-beta في مستودع المشروع ، ولا يزال من المأمول أن تكون هناك تحسينات كبيرة في الإصدار الثاني. في غضون ذلك ، سأذهب لدراسة وثائق TimescaleDB.

المصدر: www.habr.com