تمت مقارنة VictoriaMetrics و TimescaleDB و InfluxDB في عبر مجموعة بيانات تحتوي على مليار نقطة بيانات تنتمي إلى سلسلة زمنية فريدة تبلغ 40 ألفًا.
قبل بضع سنوات كان عصر Zabbix. لم يكن لكل خادم معدني أكثر من عدد قليل من المقاييس - استخدام وحدة المعالجة المركزية واستخدام ذاكرة الوصول العشوائي واستخدام القرص واستخدام الشبكة. وبالتالي ، يمكن أن تتناسب المقاييس المأخوذة من آلاف الخوادم في 40 ألف سلسلة زمنية فريدة ، ويمكن لـ Zabbix استخدام MySQL كخلفية لبيانات السلاسل الزمنية 🙂
حاليا واحد مع التكوينات الافتراضية يوفر أكثر من 500 مقياس على مضيف متوسط. هناك العديد من لقواعد البيانات المختلفة ، وخوادم الويب ، وأنظمة الأجهزة ، وما إلى ذلك ، توفر جميعها العديد من المقاييس المفيدة. الجميع تبدأ في إظهار مؤشرات مختلفة على أنفسهم. هناك Kubernetes مع المجموعات والقرون التي تعرض الكثير من المقاييس. يؤدي هذا إلى قيام الخوادم بكشف آلاف المقاييس الفريدة لكل مضيف. لذا فإن السلسلة الزمنية الفريدة 40K لم تعد ذات طاقة عالية. لقد أصبح سائدًا ، والذي يجب التعامل معه بسهولة بواسطة أي TSDB حديث على خادم واحد.
ما هو عدد كبير من السلاسل الزمنية الفريدة في الوقت الحالي؟ ربما 400 ألف أو 4 ملايين؟ أم 40 م؟ دعنا نقارن TSDBs الحديثة بهذه الأرقام.
التثبيت المعياري
هي أداة قياس أداء رائعة لأجهزة TSDBs. يسمح لك بإنشاء عدد تعسفي من المقاييس عن طريق تمرير العدد المطلوب من السلاسل الزمنية مقسومًا على 10 - علم (سابق -scale-var). 10 هو عدد القياسات (المقاييس) التي تم إنشاؤها على كل خادم مضيف. تم إنشاء مجموعات البيانات التالية باستخدام TSBS لقياس الأداء:
- 400K سلسلة زمنية فريدة ، فاصل 60 ثانية بين نقاط البيانات ، تمتد البيانات لمدة 3 أيام كاملة ، ~ 1.7 مليار إجمالي نقاط البيانات.
- سلسلة زمنية فريدة 4M ، فاصل زمني 600 ثانية ، تمتد البيانات لمدة 3 أيام كاملة ، ~ 1.7 مليار إجمالي نقاط البيانات.
- 40 مليون سلسلة زمنية فريدة ، فاصل زمني 1 ساعة ، البيانات تمتد 3 أيام كاملة ، ~ 2.8 مليار إجمالي عدد نقاط البيانات.
كان العميل والخادم يعملان على مثيلات مخصصة في سحابة جوجل. تحتوي هذه الحالات على التكوينات التالية:
- وحدات المعالجة المركزية الافتراضية: 16
- الرام: 60 جيجا
- التخزين: قرص صلب قياسي 1 تيرا بايت. يوفر معدل نقل قراءة / كتابة يبلغ 120 ميجابت في الثانية ، و 750 قراءة في الثانية ، و 1,5 كيلوبايت في الثانية.
تم سحب TSDBs من الصور الرسمية لرسو السفن وتشغيلها على عامل الإرساء بالتكوينات التالية:
-
فيكتوريا
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
قيم InfluxDB (-e) مطلوبة لدعم العلاقة الأساسية العالية. انظر التفاصيل في ):
docker run -it --rm -p 8086:8086 -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb -
TimescaleDB (تم أخذ التكوين من ملف):
MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432
--shm-size=${SHARED}MB
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data
timescale/timescaledb:latest-pg10 postgres
-cmax_wal_size=${WAL}MB
-clog_line_prefix="%m [%p]: [%x] %u@%d"
-clogging_collector=off
-csynchronous_commit=off
-cshared_buffers=${SHARED}MB
-ceffective_cache_size=${CACHE}MB
-cwork_mem=${WORK}MB
-cmaintenance_work_mem=${MAINT}MB
-cmax_files_per_process=100بدأ محمل البيانات بـ 16 سنًا متوازيًا.
تحتوي هذه المقالة فقط على نتائج لإدراج المعايير. سيتم نشر نتائج المعيار الانتقائي في مقال منفصل.
400K سلسلة زمنية فريدة من نوعها
لنبدأ بعناصر بسيطة - 400 ألف. نتائج المعيار:
- VictoriaMetrics: 2,6 مليون نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 3 جيجابايت ؛ حجم البيانات النهائية على القرص: 965 ميغا بايت
- InfluxDB: 1.2 مليون نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 8.5 جيجا بايت ؛ حجم البيانات النهائية على القرص: 1.6 جيجا بايت
- مقياس الوقت: 849 ألف نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 2,5 جيجابايت ؛ حجم البيانات النهائية على القرص: 50 جيجابايت
كما ترى من النتائج أعلاه ، فإن VictoriaMetrics تفوز بأداء الإدراج ونسبة الضغط. يفوز المخطط الزمني في استخدام ذاكرة الوصول العشوائي ، لكنه يستخدم مساحة كبيرة على القرص - 29 بايت لكل نقطة بيانات.
فيما يلي الرسوم البيانية لاستخدام وحدة المعالجة المركزية لكل من TSDBs أثناء الاختبار:
أعلى لقطة للشاشة: VictoriaMetrics - أدخل اختبار استخدام وحدة المعالجة المركزية لـ 400 ألف متري فريد.
أعلى لقطة للشاشة: InfluxDB - استخدام وحدة المعالجة المركزية في اختبار الإدراج لمقياس فريد يبلغ 400 ألف.
أعلى لقطة للشاشة: TimescaleDB - استخدام وحدة المعالجة المركزية في اختبار الإدراج لمقياس فريد يبلغ 400 ألف.
تستخدم VictoriaMetrics جميع وحدات المعالجة المركزية الافتراضية المتاحة بينما يقلل InfluxDB من استخدام ~ 2 من أصل 16 وحدة معالجة مركزية كبيرة.
يستخدم مقياس الوقت فقط 3-4 من أصل 16 وحدة معالجة مركزية. تشير النسب العالية من iowait والنظام في الرسم البياني لمقياس الوقت TimescaleDB إلى وجود اختناق في النظام الفرعي للإدخال / الإخراج (I / O). لنلقِ نظرة على الرسوم البيانية لاستخدام عرض النطاق الترددي للقرص:
أعلى لقطة للشاشة: VictoriaMetrics - أدخل استخدام عرض النطاق الترددي للقرص للاختبار لـ 400 ألف من المقاييس الفريدة.
أعلى لقطة للشاشة: InfluxDB - إدراج استخدام عرض النطاق الترددي للقرص التجريبي لـ 400 ألف من المقاييس الفريدة.
أعلى لقطة للشاشة: TimescaleDB - إدراج اختبار النطاق الترددي للقرص لاستخدام 400 ألف من المقاييس الفريدة.
VictoriaMetrics تسجل البيانات بسرعة 20 ميجابت في الثانية مع قمم تصل إلى 45 ميجابت في الثانية. تتوافق القمم مع عمليات الدمج الجزئية الكبيرة في الشجرة .
InfluxDB يكتب البيانات بسرعة 160 ميجابايت / ثانية بينما القرص 1 تيرابايت إرسال عرض النطاق الترددي 120 ميغا بايت / ثانية.
TimescaleDB يقتصر على سرعة الكتابة 120 ميجابت في الثانية ، لكنه في بعض الأحيان يكسر هذا الحد ويبلغ ذروته عند 220 ميجابت في الثانية. تتوافق هذه القمم مع انخفاضات نقص الاستخدام في الرسم البياني السابق.
لنلقِ نظرة على الرسوم البيانية لاستخدام الإدخال / الإخراج:
فوق لقطة الشاشة: VictoriaMetrics - أدخل اختبار استخدام الإدخال / الإخراج لـ 400 ألف من المقاييس الفريدة.
أعلى لقطة الشاشة: InfluxDB - أدخل اختبار استخدام الإدخال / الإخراج لـ 400 ألف من المقاييس الفريدة.
أعلى لقطة الشاشة: TimescaleDB - أدخل اختبار استخدام الإدخال / الإخراج لـ 400 ألف من المقاييس الفريدة.
من الواضح الآن أن TimescaleDB تصل إلى حد الإدخال / الإخراج ، لذا لا يمكنها استخدام الـ 12 وحدة المعالجة المركزية (vCPU) المتبقية.
سلسلة زمنية فريدة من نوعها 4M
تبدو السلاسل الزمنية 4M متحدية بعض الشيء. لكن منافسينا اجتازوا هذا الاختبار بنجاح. نتائج المعيار:
- VictoriaMetrics: 2,2 مليون نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 6 جيجابايت ؛ حجم البيانات النهائية على القرص: 3 جيجابايت.
- InfluxDB: 330 ألف نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 20,5 جيجابايت ؛ حجم البيانات النهائية على القرص: 18,4 جيجابايت.
- مقياس الوقت - DB: 480K نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 2,5 جيجابايت ؛ حجم البيانات النهائية على القرص: 52 جيجابايت.
انخفض أداء InfluxDB من 1,2 مليون نقطة بيانات في الثانية لسلسلة زمنية 400 ألف إلى 330 ألف نقطة بيانات في الثانية لسلسلة زمنية 4M. هذه خسارة كبيرة في الأداء مقارنة بالمنافسين الآخرين. لنلقِ نظرة على الرسوم البيانية لاستخدام وحدة المعالجة المركزية لفهم السبب الجذري لهذه الخسارة:
أعلى لقطة للشاشة: VictoriaMetrics - أدخل اختبار استخدام وحدة المعالجة المركزية لسلسلة زمنية فريدة 4M.
أعلى لقطة للشاشة: InfluxDB - أدخل اختبار استخدام وحدة المعالجة المركزية لمدة 4 ملايين سلسلة زمنية فريدة.
أعلى لقطة للشاشة: TimescaleDB - إدراج اختبار استخدام وحدة المعالجة المركزية لسلسلة زمنية فريدة 4M.
تستخدم VictoriaMetrics تقريبًا كل طاقة المعالجة (CPU). يتوافق الانخفاض في النهاية مع عمليات دمج LSM المتبقية بعد إدخال جميع البيانات.
يستخدم InfluxDB 8 من أصل 16 vCPU بينما يستخدم TimsecaleDB 4 من أصل 16 vCPU. ما هو القاسم المشترك بين الرسوم البيانية الخاصة بهم؟ حصة عالية iowait، مما يشير مرة أخرى إلى عنق الزجاجة في الإدخال / الإخراج.
TimescaleDB لديها حصة عالية system. نعتقد أن القوة العالية أدت إلى العديد من مكالمات النظام أو إلى العديد .
لنلقِ نظرة على الرسوم البيانية لعرض النطاق الترددي للقرص:
أعلى لقطة للشاشة: VictoriaMetrics - استخدام النطاق الترددي للقرص لإدراج 4 مليون مقياس فريد.
أعلى لقطة للشاشة: InfluxDB - استخدام النطاق الترددي للقرص لإدراج 4 مليون مقياس فريد.
أعلى لقطة للشاشة: TimescaleDB - استخدام النطاق الترددي للقرص لإدراج 4 مليون مقياس فريد.
بلغت VictoriaMetrics ذروتها عند 120 ميجابايت / ثانية بينما كان متوسط سرعة الكتابة 40 ميجابايت / ثانية. ربما كان هناك العديد من عمليات الدمج الثقيلة لـ LSM التي تم إجراؤها خلال الذروة.
يقوم InfluxDB مرة أخرى بالضغط على متوسط إنتاجية الكتابة 200 ميجابايت / ثانية مع قمم تصل إلى 340 ميجابايت / ثانية على قرص بحد كتابة 120 ميجابايت / ثانية :)
لم يعد TimescaleDB يقتصر على القرص. يبدو أنه مقيد بشيء آخر متعلق بالنسب المرتفعة системной تحميل وحدة المعالجة المركزية.
لنلقِ نظرة على الرسوم البيانية لاستخدام IO:
فوق لقطة الشاشة: VictoriaMetrics - استخدام الإدخال / الإخراج أثناء اختبار الإدراج لسلسلة زمنية فريدة 4M.
فوق لقطة الشاشة: InfluxDB - استخدام الإدخال / الإخراج أثناء اختبار الإدراج لسلسلة زمنية فريدة 4M.
أعلى لقطة الشاشة: TimescaleDB - استخدام الإدخال / الإخراج أثناء اختبار الإدراج لسلسلة زمنية فريدة 4M.
تعكس الرسوم البيانية لاستخدام IO الرسوم البيانية لاستخدام عرض النطاق الترددي للقرص - InfluxDB محدود IO ، في حين أن VictoriaMetrics و TimescaleDB لديهما موارد IO IO.
40 مليون سلسلة زمنية فريدة من نوعها
40 مليون سلسلة زمنية فريدة كانت كبيرة جدًا بالنسبة لـ InfluxDB
نتائج المعيار:
- VictoriaMetrics: 1,7 مليون نقطة بيانات في الثانية ؛ استخدام ذاكرة الوصول العشوائي: 29 جيجابايت ؛ استخدام مساحة القرص: 17 جيجا بايت.
- InfluxDB: لم ينته لأنه يتطلب أكثر من 60 جيجابايت من ذاكرة الوصول العشوائي.
- DB: 330 ألف نقطة بيانات في الثانية ، استخدام ذاكرة الوصول العشوائي: 2,5 جيجا بايت ؛ استخدام مساحة القرص: 84 جيجابايت.
يُظهر TimescaleDB استخدامًا منخفضًا ومستقرًا بشكل استثنائي لذاكرة الوصول العشوائي (RAM) بحجم 2,5 جيجابايت ، وهو نفس استخدام المقياسين الفريدين 4M و 400K.
زادت VictoriaMetrics ببطء بمعدل 100 ألف نقطة بيانات في الثانية حتى تمت معالجة كل 40 مليونًا من الأسماء المترية ذات العلامات. ثم حقق معدل إدخال ثابتًا يتراوح من 1,5 إلى 2,0 مليون نقطة بيانات في الثانية ، بحيث كانت النتيجة النهائية 1,7 مليون نقطة بيانات في الثانية.
تتشابه المخططات الخاصة بـ 40 مليونًا من السلاسل الزمنية الفريدة لتلك الخاصة بسلسلة زمنية فريدة من نوعها تبلغ 4 ملايين ، لذا دعنا نتخطى ذلك.
النتائج
- إن TSDBs الحديثة قادرة على التعامل مع الإدخالات لملايين السلاسل الزمنية الفريدة على خادم واحد. في المقالة التالية ، سنختبر مدى جودة أداء TSDBs في الاختيار عبر ملايين السلاسل الزمنية الفريدة.
- يشير الاستخدام غير الكافي لوحدة المعالجة المركزية عادةً إلى وجود اختناق في الإدخال / الإخراج. بالإضافة إلى ذلك ، قد يشير ذلك إلى حظر شديد للغاية ، عندما لا يعمل سوى عدد قليل من الخيوط في نفس الوقت.
- إن عنق الزجاجة I / O موجود ، خاصة في التخزين غير SSD مثل أجهزة الكتلة الافتراضية لموفري السحابة.
- توفر VictoriaMetrics أفضل تحسين لتخزين الإدخال / الإخراج البطيء والمنخفض. يوفر أفضل سرعة وأفضل نسبة ضغط.
تحميل وجربه على بياناتك. يتوفر الملف الثنائي الثابت المقابل في .
اقرأ المزيد عن VictoriaMetrics في هذا .
التحديث: تم النشر بنتائج قابلة للتكرار.
التحديث رقم 2: اقرأ أيضًا .
التحديث رقم 3: !
елеграм ат:
المصدر: www.habr.com