VictoriaMetrics، TimescaleDB و InfluxDB در مقایسه شدند روی یک مجموعه داده با یک میلیارد نقطه داده متعلق به 40K سری زمانی منحصر به فرد.
چند سال پیش دوره Zabbix وجود داشت. هر سرور فلزی لخت بیش از چند نشانگر نداشت - استفاده از CPU، استفاده از RAM، استفاده از دیسک و استفاده از شبکه. به این ترتیب، معیارهای هزاران سرور می توانند در 40 هزار سری زمانی منحصر به فرد قرار بگیرند و Zabbix می تواند از MySQL به عنوان پشتیبان برای داده های سری زمانی استفاده کند :)
در حال حاضر تنها با پیکربندی های پیش فرض، بیش از 500 معیار را در میزبان متوسط ارائه می دهد. بسیاری وجود دارد برای پایگاه داده های مختلف، سرورهای وب، سیستم های سخت افزاری و غیره. همه آنها معیارهای مفیدی را ارائه می دهند. همه شروع به تنظیم شاخص های مختلف برای خود می کنند. Kubernetes با خوشه‌ها و غلاف‌ها وجود دارد که معیارهای زیادی را نشان می‌دهد. این باعث می شود که سرورها هزاران معیار منحصر به فرد را در هر میزبان نشان دهند. بنابراین سری زمانی منحصر به فرد 40K دیگر قدرت بالایی ندارد. در حال تبدیل شدن به جریان اصلی است و باید به راحتی توسط هر TSDB مدرن روی یک سرور واحد مدیریت شود.
تعداد زیادی سری زمانی منحصر به فرد در حال حاضر چقدر است؟ احتمالا 400K یا 4M؟ یا 40 متر؟ بیایید TSDB های مدرن را با این اعداد مقایسه کنیم.
نصب بنچمارک
یک ابزار معیار عالی برای TSDB ها است. این امکان را به شما می دهد تا با عبور از تعداد مورد نیاز سری های زمانی تقسیم بر 10، تعداد دلخواه متریک ایجاد کنید. (سابق -scale-var). 10 تعداد اندازه گیری ها (متریک ها) تولید شده در هر میزبان یا سرور است. مجموعه داده های زیر با استفاده از TSBS برای معیار تولید شدند:
- 400K سری زمانی منحصر به فرد، فاصله 60 ثانیه بین نقاط داده، داده ها 3 روز کامل را شامل می شود، ~1.7B تعداد کل نقاط داده.
- سری زمانی منحصر به فرد 4M، فاصله زمانی 600 ثانیه، داده ها 3 روز کامل را در بر می گیرد، ~1.7B تعداد کل نقاط داده.
- 40 میلیون سری زمانی منحصر به فرد، فاصله زمانی 1 ساعت، داده ها 3 روز کامل را در بر می گیرد، ~ 2.8 میلیارد تعداد کل نقاط داده.
کلاینت و سرور بر روی نمونه های اختصاصی در حال اجرا بودند در ابر گوگل این نمونه ها دارای تنظیمات زیر بودند:
- vCPU: 16
- رم: 60 گیگابایت
- فضای ذخیره سازی: استاندارد 1 ترابایت HDD. سرعت خواندن/نوشتن 120 مگابیت بر ثانیه، 750 عملیات خواندن در ثانیه و 1,5 هزار نوشتن در ثانیه را فراهم می کند.
TSDB ها از تصاویر رسمی docker استخراج شده و در docker با تنظیمات زیر اجرا می شوند:
-
VictoriaMetrics:
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 سری زمانی منحصر به فرد
بیایید با عناصر ساده شروع کنیم - 400K. نتایج محک:
- VictoriaMetrics: 2,6 میلیون نقطه داده در ثانیه. میزان مصرف رم: 3 گیگابایت; حجم اطلاعات نهایی روی دیسک: 965 مگابایت
- InfluxDB: 1.2M نقطه داده در ثانیه. میزان مصرف رم: 8.5 گیگابایت; اندازه نهایی اطلاعات روی دیسک: 1.6 گیگابایت
- مقیاس زمانی: 849 هزار نقطه داده در ثانیه. میزان مصرف رم: 2,5 گیگابایت; اندازه نهایی اطلاعات روی دیسک: 50 گیگابایت
همانطور که از نتایج بالا می بینید، VictoriaMetrics در عملکرد درج و نسبت فشرده سازی برنده است. تایم لاین در استفاده از رم برنده است، اما از فضای دیسک زیادی استفاده می کند - 29 بایت در هر نقطه داده.
در زیر نمودارهای استفاده از CPU برای هر یک از TSDB ها در طول معیار آورده شده است:
تصویر بالا یک عکس از صفحه نمایش است: VictoriaMetrics - بارگیری CPU در حین تست درج برای یک متریک منحصر به فرد 400K.
تصویر بالا یک عکس از صفحه نمایش است: InfluxDB - بارگیری CPU در حین تست درج برای متریک منحصر به فرد 400K.
تصویر بالا یک اسکرین شات است: TimescaleDB - بارگیری CPU در طول تست درج برای یک متریک منحصر به فرد 400K.
VictoriaMetrics از تمام vCPU های موجود استفاده می کند، در حالی که InfluxDB از 2 از 16 vCPU کمتر استفاده می کند.
Timescale فقط از 3-4 از 16 vCPU استفاده می کند. نسبت های بالای iowait و سیستم در نمودار مقیاس زمانی TimescaleDB نشان دهنده یک تنگنا در زیرسیستم ورودی/خروجی (I/O) است. بیایید به نمودارهای استفاده از پهنای باند دیسک نگاه کنیم:
در بالا یک اسکرین شات وجود دارد: VictoriaMetrics - استفاده از پهنای باند دیسک در تست درج برای Unique Metrics 400K.
در بالا یک اسکرین شات وجود دارد: InfluxDB - استفاده از پهنای باند دیسک در تست درج برای Unique Metrics 400K.
تصویر بالا یک اسکرین شات است: TimescaleDB - استفاده از پهنای باند دیسک در تست درج برای Unique Metrics 400K.
VictoriaMetrics داده ها را با سرعت 20 مگابیت در ثانیه با حداکثر سرعت 45 مگابیت در ثانیه ضبط می کند. قله ها مربوط به ادغام جزئی بزرگ در درخت است .
InfluxDB داده ها را با سرعت 160 مگابایت بر ثانیه می نویسد، در حالی که یک درایو 1 ترابایتی سرعت نوشتن 120 مگابایت بر ثانیه
TimescaleDB محدود به سرعت نوشتن 120 مگابیت در ثانیه است، اما گاهی اوقات این محدودیت را می شکند و در مقادیر پیک به 220 مگابیت در ثانیه می رسد. این پیک ها مربوط به دره های استفاده ناکافی از CPU در نمودار قبلی است.
بیایید به نمودارهای استفاده از ورودی/خروجی (I/O) نگاه کنیم:
در بالا یک اسکرین شات وجود دارد: VictoriaMetrics - استفاده آزمایشی I/O را برای 400K معیارهای منحصر به فرد درج کنید.
در بالا یک اسکرین شات وجود دارد: InfluxDB - استفاده آزمایشی I/O را برای معیارهای منحصر به فرد 400K درج کنید.
در بالا یک اسکرین شات وجود دارد: TimescaleDB - استفاده آزمایشی I/O را برای معیارهای منحصر به فرد 400K درج کنید.
اکنون مشخص است که TimescaleDB به محدودیت ورودی/خروجی خود رسیده است، بنابراین نمی تواند از 12 vCPU باقیمانده استفاده کند.
سری زمانی منحصر به فرد 4M
سری زمانی 4M کمی چالش برانگیز به نظر می رسد. اما رقبای ما این آزمون را با موفقیت پشت سر می گذارند. نتایج محک:
- VictoriaMetrics: 2,2 میلیون نقطه داده در ثانیه. میزان مصرف رم: 6 گیگابایت; اندازه نهایی اطلاعات روی دیسک: 3 گیگابایت.
- InfluxDB: 330 هزار نقطه داده در ثانیه. میزان مصرف رم: 20,5 گیگابایت; اندازه نهایی اطلاعات روی دیسک: 18,4 گیگابایت.
- TimescaleDB: 480K نقطه داده در ثانیه. میزان مصرف رم: 2,5 گیگابایت; حجم اطلاعات نهایی روی دیسک: 52 گیگابایت.
عملکرد InfluxDB از 1,2 میلیون نقطه داده در ثانیه برای یک سری زمانی 400K به 330K نقطه داده در ثانیه برای یک سری زمانی 4M کاهش یافت. این کاهش عملکرد قابل توجهی در مقایسه با سایر رقبا است. بیایید به نمودارهای استفاده از CPU نگاه کنیم تا علت اصلی این از دست دادن را بفهمیم:
تصویر بالا یک اسکرین شات است: VictoriaMetrics - استفاده از CPU در طول تست درج برای یک سری زمانی منحصر به فرد 4M.
تصویر بالا یک اسکرین شات است: InfluxDB - استفاده از CPU در طول تست درج برای سری های زمانی منحصر به فرد 4M.
تصویر بالا یک اسکرین شات است: TimescaleDB - استفاده از CPU در طول تست درج برای یک سری زمانی منحصر به فرد 4M.
VictoriaMetrics تقریباً از تمام توان واحد پردازش (CPU) استفاده می کند. افت در پایان مربوط به ادغام LSM باقی مانده پس از درج تمام داده ها است.
InfluxDB تنها از 8 مورد از 16 vCPU استفاده می کند، در حالی که TimsecaleDB از 4 از 16 vCPU استفاده می کند. نمودار آنها چه وجه مشترکی دارد؟ سهم بالا iowait، که باز هم گلوگاه ورودی/خروجی را نشان می دهد.
TimescaleDB سهم بالایی دارد system. ما فرض می کنیم که قدرت بالا منجر به بسیاری از تماس های سیستمی یا بسیاری از آنها شده است .
بیایید به نمودارهای خروجی دیسک نگاه کنیم:
تصویر بالا یک اسکرین شات است: VictoriaMetrics - استفاده از پهنای باند دیسک برای درج معیارهای منحصر به فرد 4M.
در بالا یک اسکرین شات وجود دارد: InfluxDB - استفاده از پهنای باند دیسک برای درج معیارهای منحصر به فرد 4M.
تصویر بالا یک تصویر است: TimescaleDB - استفاده از پهنای باند دیسک برای درج معیارهای منحصر به فرد 4M.
VictoriaMetrics در اوج به حداکثر 120 مگابایت بر ثانیه رسید، در حالی که میانگین سرعت نوشتن 40 مگابایت بر ثانیه بود. این احتمال وجود دارد که چندین فیوژن سنگین LSM در طول اوج انجام شده باشد.
InfluxDB دوباره میانگین توان نوشتن 200 مگابایت بر ثانیه را با حداکثر سرعت 340 مگابایت بر ثانیه روی دیسکی با محدودیت نوشتن 120 مگابایت بر ثانیه کاهش می دهد :)
TimescaleDB دیگر محدود به دیسک نیست. به نظر می رسد که توسط چیز دیگری مربوط به نسبت بالا محدود شده است системной بار CPU
بیایید به نمودارهای استفاده از IO نگاه کنیم:
تصویر بالا یک اسکرین شات است: VictoriaMetrics - استفاده از I/O در طول تست درج برای یک سری زمانی منحصر به فرد 4M.
در بالا یک اسکرین شات وجود دارد: InfluxDB - استفاده از I/O در طول تست درج برای یک سری زمانی منحصر به فرد 4M.
تصویر بالا یک اسکرین شات است: TimescaleDB - استفاده از I/O در طول تست درج برای سری های زمانی منحصر به فرد 4M.
الگوهای استفاده از IO منعکس کننده پهنای باند دیسک هستند - InfluxDB دارای IO محدود است، در حالی که VictoriaMetrics و TimescaleDB منابع IO اضافی دارند.
40M سری زمانی منحصر به فرد
40 میلیون سری زمانی منحصر به فرد برای InfluxDB خیلی بزرگ بود :)
نتایج محک:
- VictoriaMetrics: 1,7 میلیون نقطه داده در ثانیه. میزان مصرف رم: 29 گیگابایت; فضای مصرفی دیسک: 17 گیگابایت.
- InfluxDB: تمام نشد زیرا به بیش از 60 گیگابایت رم نیاز داشت.
- TimescaleDB: 330 هزار نقطه داده در ثانیه، میزان مصرف رم: 2,5 گیگابایت؛ فضای مصرفی دیسک: 84 گیگابایت
TimescaleDB استفاده از رم فوق‌العاده کم و پایدار را در 2,5 گیگابایت نشان می‌دهد - مانند معیارهای منحصر به فرد 4M و 400K.
VictoriaMetrics به آرامی با سرعت 100k نقطه داده در ثانیه افزایش یافت تا اینکه تمام 40M نام متریک برچسب‌گذاری شده پردازش شدند. او سپس به نرخ درج ثابت 1,5-2,0M نقطه داده در ثانیه دست یافت، بنابراین نتیجه نهایی 1,7M نقطه داده در ثانیه بود.
نمودارهای سری زمانی منحصر به فرد 40M مشابه نمودارهای سری زمانی منحصر به فرد 4M است، پس بیایید از آنها بگذریم.
یافته ها
- TSDB های مدرن قادر به پردازش درج ها برای میلیون ها سری زمانی منحصر به فرد در یک سرور هستند. در مقاله بعدی، بررسی خواهیم کرد که TSDBs چقدر انتخاب را در میلیون‌ها سری زمانی منحصر به فرد انجام می‌دهد.
- استفاده ناکافی از CPU معمولاً نشان دهنده تنگنای ورودی/خروجی است. همچنین ممکن است نشان‌دهنده این باشد که مسدود کردن بیش از حد درشت است و تنها چند رشته می‌توانند در یک زمان اجرا شوند.
- گلوگاه I/O وجود دارد، مخصوصاً در فضای ذخیره‌سازی غیر SSD مانند دستگاه‌های بلوک مجازی ارائه‌دهندگان ابری.
- VictoriaMetrics بهترین بهینه سازی را برای ذخیره سازی ورودی/خروجی آهسته و کم ارائه می دهد. بهترین سرعت و بهترین نسبت تراکم را فراهم می کند.
بارگیری و آن را روی داده های خود امتحان کنید. باینری استاتیک مربوطه در این آدرس موجود است .
بیشتر در مورد VictoriaMetrics در این مطلب بخوانید .
به روز رسانی: منتشر شد با نتایج قابل تکرار
به روز رسانی شماره 2: همچنین بخوانید .
به روز رسانی شماره 3: !
چت تلگرام:
منبع: www.habr.com