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