إذا كنت تستخدم قاعدة بيانات السلاسل الزمنية (timeseries db ،
wiki ) كمستودع رئيسي لموقع يحتوي على إحصائيات ، فبدلاً من حل المشكلة ، يمكنك الحصول على الكثير من الصداع. أنا أعمل على مشروع يتم فيه استخدام قاعدة البيانات هذه ، وفي بعض الأحيان يقدم InfluxDB ، الذي سيتم مناقشته ، مفاجآت غير متوقعة بشكل عام.
إخلاء المسئولية : هذه المشكلات تخص InfluxDB 1.7.4.
لماذا السلاسل الزمنية؟
يهدف المشروع إلى تتبع المعاملات في مختلف المجموعات وعرض الإحصاءات. على وجه التحديد ، نحن ننظر إلى انبعاث وحرق العملات المستقرة (
ويكي ). بناءً على هذه المعاملات ، تحتاج إلى إنشاء رسوم بيانية وإظهار الجداول المحورية.
عند تحليل المعاملات ، ظهرت الفكرة: لاستخدام قاعدة بيانات سلسلة زمنية InfluxDB كمخزن رئيسي. المعاملات هي نقاط في الوقت المناسب وأنها تنسجم بشكل جيد مع نموذج السلسلة الزمنية.
أيضًا ، بدت وظائف التجميع مريحة للغاية - فهي مثالية لمعالجة الرسوم البيانية لفترة طويلة. يحتاج المستخدم إلى رسم بياني للسنة ، وتحتوي قاعدة البيانات على مجموعة بيانات بإطار زمني مدته خمس دقائق. من غير المجدي إرساله مائة ألف نقطة - باستثناء المعالجة الطويلة ، فلن يتم احتواؤها على الشاشة. يمكنك كتابة تطبيقك الخاص لزيادة الإطار الزمني ، أو استخدام وظائف التجميع المدمجة في Influx. من خلال مساعدتهم ، يمكنك تجميع البيانات حسب اليوم وإرسال 365 نقطة مطلوبة.
كان من المحرج قليلاً أن تستخدم عادةً قواعد البيانات هذه لجمع المقاييس. مراقبة الخوادم وأجهزة iot ، والتي منها "تسكب" ملايين النقاط في النموذج: [<time> - <metric value>]. ولكن إذا كانت قاعدة البيانات تعمل بشكل جيد مع تدفق كبير للبيانات ، فلماذا يتسبب مقدار صغير في حدوث مشاكل؟ مع وضع ذلك في الاعتبار ، أخذوا InfluxDB للعمل.
ماذا مريحة في InfluxDB
بالإضافة إلى وظائف التجميع المذكورة ، هناك شيء رائع آخر -
الاستعلامات المستمرة (
doc ). هذا مجدول مضمن في قاعدة البيانات يمكنه معالجة البيانات في جدول. على سبيل المثال ، يمكنك تجميع جميع السجلات ليوم واحد كل 24 ساعة ، وحساب المتوسط وكتابة نقطة جديدة في جدول آخر دون كتابة الدراجات الخاصة بك.
هناك أيضًا
سياسات الاحتفاظ (
doc ) - إعداد حذف البيانات بعد فترة. من المفيد ، على سبيل المثال ، عندما تحتاج إلى تخزين الحمل على وحدة المعالجة المركزية لمدة أسبوع مع قياسات مرة واحدة في الثانية ، ولكن على مسافة بضعة أشهر ليست هناك حاجة لهذه الدقة. في هذه الحالة ، يمكنك القيام بذلك:
- إنشاء استعلام مستمر لتجميع البيانات في جدول آخر ؛
- بالنسبة للجدول الأول ، حدد سياسة لحذف المقاييس الأقدم من هذا الأسبوع.
وسوف يقلل 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
لا أشاهد الجدول في القائمة ، لكن طلب البيانات الجديد لا يزال يعرض نفس مجموعة المعاملات.
حدثت المشكلة لي مرة واحدة فقط ، لأن حالة الحذف هي حالة معزولة. لكن هذا السلوك لقاعدة البيانات بشكل واضح لا يتلاءم مع إطار العمل "الصحيح". في وقت لاحق على جيثب لقد وجدت
تذكرة مفتوحة منذ عام تقريبا حول هذا الموضوع.
نتيجة لذلك ، ساعدت إزالة قاعدة البيانات بأكملها واستعادتها لاحقًا.
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
التفسير:
- في الاستعلام الأول ، نحصل على النقاط الأخيرة لكل عملة مع بيانات السوق. ثماني نقاط لثماني عملات معدنية في حالتي.
- يتلقى الطلب الثاني واحدة أحدث نقطة.
- الثالث يطلب قائمة من المعاملات لليوم الأخير ، قد يكون هناك عدة مئات.
سأوضح أنه في InfluxDB ، يتم إنشاء فهرس تلقائيًا بواسطة العلامات والوقت ، مما يسرع الاستعلامات. في الاستعلام الأول ،
الرمز هو العلامة.
فعلت اختبار الإجهاد لهذا الأسلوب API. لمدة 25 RPS ، أظهر الخادم حمولة كاملة من ستة وحدات المعالجة المركزية:
في الوقت نفسه ، لم تعطي عملية NodeJs أي حمل على الإطلاق.
لقد انخفضت سرعة التنفيذ بالفعل بنسبة 7-10 RPS: إذا كان بإمكان أحد العملاء تلقي استجابة في 200 مللي ثانية ، فيجب أن ينتظر 10 عملاء ثانية. 25 RPS - الحدود التي عانى منها الاستقرار ، وتم إرجاع 500 خطأ للعملاء.
مع هذا الأداء ، من المستحيل استخدام Influx في مشروعنا. علاوة على ذلك: في مشروع تحتاج فيه إلى إظهار المراقبة للعديد من العملاء ، قد تظهر مشكلات مماثلة وسيحمل الخادم المتري عبئًا زائدًا.
استنتاج
الاستنتاج الأكثر أهمية من التجربة المكتسبة هو أنه لا يمكنك أخذ تقنية غير معروفة في المشروع دون تحليل كاف. يمكن أن يوفر الفحص البسيط للتذاكر المفتوحة على github المعلومات حتى لا يعتبر InfluxDB بمثابة مستودع البيانات الرئيسي.
كان من المفترض أن يكون InfluxDB مناسبًا تمامًا لمهام مشروعي ، ولكن كما أظهرت الممارسة ، فإن قاعدة البيانات هذه لا تلبي الاحتياجات وتعبث كثيرًا.
يمكنك بالفعل العثور على الإصدار 2.0.0 بيتا في مستودع المشروع ، ومن المأمول أنه في الإصدار الثاني سيكون هناك تحسينات كبيرة. في غضون ذلك ، سأدرس وثائق TimescaleDB.