उच्च प्रदर्शन TSDB बेन्चमार्क VictoriaMetrics बनाम TimescaleDB बनाम InfluxDB

VictoriaMetrics, TimescaleDB र InfluxDB मा तुलना गरिएको थियो अघिल्लो लेख 40K अद्वितीय समय शृङ्खलासँग सम्बन्धित एक अरब डेटा बिन्दुहरू भएको डेटासेटमा।

केही वर्ष पहिले Zabbix को एक युग थियो। प्रत्येक बेयर मेटल सर्भरमा केहि सूचकहरू भन्दा बढी थिएन - CPU उपयोग, RAM उपयोग, डिस्क प्रयोग र नेटवर्क उपयोग। यस तरिकाले, हजारौं सर्भरहरूबाट मेट्रिक्स 40 हजार अद्वितीय समय श्रृंखलामा फिट हुन सक्छ, र Zabbix ले MySQL लाई समय श्रृंखला डेटाको लागि ब्याकइन्डको रूपमा प्रयोग गर्न सक्छ :)

हाल एक्लै node_exporter पूर्वनिर्धारित कन्फिगरेसनहरूसँग औसत होस्टमा 500 भन्दा बढी मेट्रिक्स प्रदान गर्दछ। त्यहाँ धेरै छन् निर्यातकर्ताहरू विभिन्न डाटाबेसहरू, वेब सर्भरहरू, हार्डवेयर प्रणालीहरू, आदिका लागि। तिनीहरू सबैले विभिन्न प्रकारका उपयोगी मेट्रिकहरू प्रदान गर्छन्। सबै अधिक र अधिक आवेदन आफ्नै लागि विभिन्न सूचकहरू सेट गर्न थाल्छन्। त्यहाँ क्लस्टरहरू र पोडहरू भएका कुबर्नेटहरू छन् जसले धेरै मेट्रिकहरू उजागर गर्दछ। यसले सर्भरहरू प्रति होस्ट हजारौं अद्वितीय मेट्रिकहरू उजागर गर्दछ। त्यसैले अद्वितीय 40K समय श्रृंखला अब उच्च शक्ति छैन। यो मुख्यधारा बनिरहेको छ र सजिलै संग एकल सर्भर मा कुनै पनि आधुनिक TSDB द्वारा ह्यान्डल गरिनु पर्छ।

यस समयमा अद्वितीय समय श्रृंखला को ठूलो संख्या के हो? सम्भवतः 400K वा 4M? वा 40m? यी संख्याहरूसँग आधुनिक TSDB हरू तुलना गरौं।

बेन्चमार्क स्थापना गर्दै

TSBS TSDBs को लागि उत्कृष्ट बेन्चमार्किङ उपकरण हो। यसले तपाईंलाई 10 - फ्ल्याग द्वारा विभाजित समय श्रृंखला को आवश्यक संख्या पास गरेर मेट्रिक्स को एक मनमानी संख्या उत्पन्न गर्न अनुमति दिन्छ। - मापन (पूर्व -scale-var)। 10 प्रत्येक होस्ट वा सर्भरमा उत्पन्न मापन (मेट्रिक्स) को संख्या हो। निम्न डेटासेटहरू बेन्चमार्कको लागि TSBS प्रयोग गरेर उत्पन्न गरिएको थियो:

• 400K अद्वितीय समय शृङ्खला, डेटा बिन्दुहरू बीच 60 सेकेन्डको अन्तराल, डेटा पूर्ण 3 दिनमा फैलिएको छ, ~1.7B डेटा बिन्दुहरूको कुल संख्या।
• 4M अद्वितीय समय शृङ्खला, 600 सेकेन्ड अन्तराल, डेटा 3 पूर्ण दिनहरू फैलिएको छ, ~1.7B डेटा बिन्दुहरूको कुल संख्या।
• 40M अद्वितीय समय शृङ्खला, 1 घण्टा अन्तराल, डेटा 3 पूरा दिन फैलिएको छ, ~2.8B डेटा बिन्दुहरूको कुल संख्या।

ग्राहक र सर्भर समर्पित उदाहरणहरूमा चलिरहेको थियो n1-मानक-16 गुगल क्लाउडमा। यी उदाहरणहरूमा निम्न कन्फिगरेसनहरू थिए:

• vCPUs: १६
• र्याम: GB जीबी
• भण्डारण: मानक 1TB HDD। यसले 120 Mbps रिड/राइट थ्रुपुट, 750 रिड अपरेशन प्रति सेकेन्ड र 1,5K राइट प्रति सेकेन्ड प्रदान गर्दछ।

TSDB हरू आधिकारिक डकर छविहरूबाट निकालिएका थिए र निम्न कन्फिगरेसनहरूसँग डकरमा चलाइएको थियो:

• भिक्टोरियामेट्रिक्स:

  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

डाटा लोडर १६ समानान्तर थ्रेडहरूसँग चलाइएको थियो।

यो लेखले सम्मिलित बेन्चमार्कहरूको लागि मात्र परिणामहरू समावेश गर्दछ। छनौट बेन्चमार्कको नतिजा छुट्टै लेखमा प्रकाशित गरिनेछ।

400K अद्वितीय समय श्रृंखला

साधारण तत्वहरूसँग सुरु गरौं - 400K। बेन्चमार्क परिणाम:

• VictoriaMetrics: 2,6M डाटा पोइन्ट प्रति सेकेन्ड; RAM उपयोग: 3 GB; डिस्कमा अन्तिम डाटा साइज: 965 एमबी
• InfluxDB: 1.2M डाटा पोइन्ट प्रति सेकेन्ड; RAM उपयोग: 8.5 GB; डिस्कमा अन्तिम डाटा साइज: 1.6 GB
• टाइमस्केल: 849K डाटा पोइन्ट प्रति सेकेन्ड; RAM उपयोग: 2,5 GB; डिस्कमा अन्तिम डाटा साइज: 50 जीबी

तपाईले माथिको नतिजाबाट देख्न सक्नुहुन्छ, भिक्टोरियामेट्रिक्सले सम्मिलन प्रदर्शन र कम्प्रेसन अनुपातमा जित्छ। टाइमलाइनले RAM को प्रयोगमा जित्छ, तर यसले धेरै डिस्क स्पेस प्रयोग गर्दछ - 29 बाइट प्रति डाटा पोइन्ट।

बेन्चमार्कको समयमा प्रत्येक TSDB हरूका लागि CPU उपयोग ग्राफहरू तल छन्:

माथिको स्क्रिनसट छ: VictoriaMetrics - एक अद्वितीय 400K मेट्रिकको लागि सम्मिलन परीक्षणको समयमा CPU लोड।

माथिको स्क्रिनसट छ: InfluxDB - अद्वितीय मेट्रिक 400K को लागि सम्मिलन परीक्षणको क्रममा CPU लोड।

माथिको स्क्रिनसट छ: TimescaleDB - 400K को एक अद्वितीय मेट्रिकको लागि सम्मिलन परीक्षणको क्रममा CPU लोड।

VictoriaMetrics ले सबै उपलब्ध vCPUs प्रयोग गर्छ, जबकि InfluxDB ले १६ vCPU हरू मध्ये ~2 को कम प्रयोग गर्छ।

Timescale 3 vCPU हरू मध्ये 4-16 मात्र प्रयोग गर्दछ। TimescaleDB टाइमस्केल ग्राफमा iowait र प्रणालीको उच्च अनुपातले इनपुट/आउटपुट (I/O) उपप्रणालीमा अवरोध देखाउँछ। डिस्क ब्यान्डविथ उपयोग ग्राफहरू हेरौं:

माथि एक स्क्रिनसट छ: VictoriaMetrics - अद्वितीय मेट्रिक्स 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 समय श्रृंखला अलि चुनौतीपूर्ण देखिन्छ। तर हाम्रा प्रतिस्पर्धीहरूले यो परीक्षा सफलतापूर्वक पास गर्छन्। बेन्चमार्क परिणाम:

• VictoriaMetrics: 2,2M डाटा पोइन्ट प्रति सेकेन्ड; RAM उपयोग: 6 GB; डिस्कमा अन्तिम डाटा साइज: 3 जीबी।
• InfluxDB: 330K डाटा पोइन्ट प्रति सेकेन्ड; RAM उपयोग: 20,5 GB; डिस्कमा अन्तिम डाटा साइज: 18,4 GB।
• 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 vCPU हरू मध्ये 16 मात्र प्रयोग गर्दछ, जबकि TimsecaleDB ले 4 vCPU हरू मध्ये 16 प्रयोग गर्दछ। तिनीहरूको ग्राफहरू के समान छन्? उच्च शेयर iowait, जसले फेरि I/O बाधालाई संकेत गर्दछ।

TimescaleDB को उच्च साझेदारी छ system। हामी मान्दछौं कि उच्च शक्तिले धेरै प्रणाली कलहरू वा धेरैमा परिणाम दिन्छ साना पृष्ठ त्रुटिहरू.

डिस्क थ्रुपुट ग्राफहरू हेरौं:

माथि एक स्क्रिनसट छ: VictoriaMetrics - 4M अद्वितीय मेट्रिक्स सम्मिलित गर्न डिस्क ब्यान्डविथ प्रयोग गर्दै।

माथिको स्क्रिनसट छ: InfluxDB - 4M अद्वितीय मेट्रिक्स सम्मिलित गर्न डिस्क ब्यान्डविथ प्रयोग गर्दै।

माथिको स्क्रिनसट छ: TimescaleDB - 4M अद्वितीय मेट्रिक्स सम्मिलित गर्न डिस्क ब्यान्डविथ प्रयोग गर्दै।

VictoriaMetrics शिखरमा 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 अद्वितीय समय श्रृंखला

40M अद्वितीय समय श्रृंखला InfluxDB को लागि धेरै ठूलो थियो :)

बेन्चमार्क परिणाम:

• VictoriaMetrics: 1,7M डाटा पोइन्ट प्रति सेकेन्ड; RAM उपयोग: 29 GB; डिस्क स्पेस उपयोग: 17 GB।
• InfluxDB: समाप्त भएन किनभने यसलाई 60GB भन्दा बढी RAM चाहिन्छ।
• TimescaleDB: 330K डाटा पोइन्ट प्रति सेकेन्ड, RAM उपयोग: 2,5 GB; डिस्क स्पेस उपयोग: 84GB।

TimescaleDB ले 2,5 GB मा असाधारण रूपमा कम र स्थिर RAM प्रयोग देखाउँछ - अद्वितीय 4M र 400K मेट्रिक्सको लागि जस्तै।

सबै 100M ट्याग गरिएका मेट्रिक नामहरू प्रशोधन नगरेसम्म VictoriaMetrics ले बिस्तारै 40k डाटा पोइन्ट प्रति सेकेन्डको दरमा मापन गर्यो। त्यसपछि उसले 1,5-2,0M डाटा पोइन्ट प्रति सेकेन्डको निरन्तर सम्मिलन दर हासिल गर्यो, त्यसैले अन्तिम परिणाम प्रति सेकेन्ड 1,7M डाटा पोइन्ट थियो।

40M अद्वितीय समय श्रृंखलाका लागि ग्राफहरू 4M अद्वितीय समय श्रृंखलाका लागि ग्राफहरू जस्तै छन्, त्यसैले तिनीहरूलाई छोडौं।

निष्कर्ष

• आधुनिक TSDB हरू एकल सर्भरमा लाखौं अद्वितीय टाइम शृङ्खलाहरूका लागि इन्सर्टहरू प्रशोधन गर्न सक्षम छन्। अर्को लेखमा, हामी परीक्षण गर्नेछौं कि TSDBs ले लाखौं अद्वितीय समय शृङ्खलाहरूमा चयन कसरी राम्रोसँग प्रदर्शन गर्दछ।
• अपर्याप्त CPU उपयोगले सामान्यतया I/O अवरोधलाई संकेत गर्दछ। यसले यो पनि संकेत गर्न सक्छ कि ब्लकिङ एकदमै मोटो छ, केवल केहि थ्रेडहरू एक पटकमा चल्न सक्षम छन्।
• I/O बटलनेक अवस्थित छ, विशेष गरी गैर-एसएसडी भण्डारणमा जस्तै क्लाउड प्रदायकहरूको भर्चुअलाइज्ड ब्लक उपकरणहरूमा।
• VictoriaMetrics ले ढिलो, कम I/O भण्डारणको लागि उत्तम अनुकूलन प्रदान गर्दछ। यसले उत्तम गति र उत्तम कम्प्रेसन अनुपात प्रदान गर्दछ।

डाउनलोड गर्नुहोस् VictoriaMetrics एकल-सर्भर छवि र आफ्नो डाटा मा प्रयास गर्नुहोस्। सम्बन्धित स्थिर बाइनरी मा उपलब्ध छ GitHub.

यसमा VictoriaMetrics को बारेमा थप पढ्नुहोस् लेख.

अद्यावधिक: प्रकाशित InfluxDB सँग VictoriaMetrics को सम्मिलित प्रदर्शन तुलना गर्ने लेख पुनरुत्पादन योग्य परिणामहरूको साथ।

अपडेट #2: यो पनि पढ्नुहोस् ठाडो स्केलेबिलिटी मा लेख VictoriaMetrics बनाम InfluxDB बनाम TimescaleDB.

अपडेट #3: VictoriaMetrics अब खुला स्रोत हो!

टेलिग्राम च्याट: https://t.me/VictoriaMetrics_ru1

स्रोत: www.habr.com