ઉચ્ચ-પ્રદર્શન TSDB બેન્ચમાર્ક VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB અને InfluxDB માં સરખામણી કરવામાં આવી હતી પાછલો લેખ 40K અનન્ય સમય શ્રેણી સાથે જોડાયેલા અબજ ડેટા પોઈન્ટ સાથેના ડેટાસેટ પર.

થોડા વર્ષો પહેલા ઝબ્બીક્સનો યુગ હતો. દરેક બેર મેટલ સર્વરમાં અમુક સૂચકાંકો કરતાં વધુ નહોતા - 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 Google ક્લાઉડમાં. આ ઉદાહરણોમાં નીચેની ગોઠવણીઓ હતી:

• vCPU: 16
• રેમ: 60 જીબી
• સ્ટોરેજ: સ્ટાન્ડર્ડ 1TB HDD. તે 120 Mbps રીડ/રાઈટ થ્રુપુટ, 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 MB
• InfluxDB: 1.2M ડેટા પોઈન્ટ પ્રતિ સેકન્ડ; રેમ વપરાશ: 8.5 જીબી; ડિસ્ક પર અંતિમ ડેટા કદ: 1.6 GB
• ટાઈમસ્કેલ: 849K ડેટા પોઈન્ટ પ્રતિ સેકન્ડ; રેમ વપરાશ: 2,5 જીબી; ડિસ્ક પર અંતિમ ડેટા કદ: 50 GB

જેમ તમે ઉપરના પરિણામો પરથી જોઈ શકો છો, VictoriaMetrics નિવેશ પ્રદર્શન અને કમ્પ્રેશન રેશિયોમાં જીતે છે. RAM વપરાશમાં સમયરેખા જીતે છે, પરંતુ તે ઘણી બધી ડિસ્ક જગ્યા વાપરે છે - ડેટા પોઇન્ટ દીઠ 29 બાઇટ્સ.

નીચે બેન્ચમાર્ક દરમિયાન દરેક TSDB માટે CPU વપરાશ ગ્રાફ છે:

ઉપર એક સ્ક્રીનશૉટ છે: VictoriaMetrics - અનન્ય 400K મેટ્રિક માટે નિવેશ પરીક્ષણ દરમિયાન CPU લોડ.

ઉપર એક સ્ક્રીનશૉટ છે: અનન્ય મેટ્રિક 400K માટે નિવેશ પરીક્ષણ દરમિયાન InfluxDB - CPU લોડ.

ઉપર એક સ્ક્રીનશૉટ છે: TimescaleDB - 400K ના અનન્ય મેટ્રિક માટે નિવેશ પરીક્ષણ દરમિયાન CPU લોડ.

VictoriaMetrics તમામ ઉપલબ્ધ vCPU નો ઉપયોગ કરે છે, જ્યારે InfluxDB 2 vCPU માંથી ~16 નો ઓછો ઉપયોગ કરે છે.

ટાઇમસ્કેલ 3 માંથી માત્ર 4-16 vCPU નો ઉપયોગ કરે છે. TimescaleDB ટાઇમસ્કેલ ગ્રાફમાં iowait અને સિસ્ટમનું ઉચ્ચ પ્રમાણ ઇનપુટ/આઉટપુટ (I/O) સબસિસ્ટમમાં અવરોધ સૂચવે છે. ચાલો ડિસ્ક બેન્ડવિડ્થ વપરાશ ગ્રાફ્સ જોઈએ:

ઉપર એક સ્ક્રીનશૉટ છે: વિક્ટોરિયામેટ્રિક્સ - યુનિક મેટ્રિક્સ 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 vCPU નો ઉપયોગ કરી શકતું નથી.

4M અનન્ય સમય શ્રેણી

4M સમય શ્રેણી થોડી પડકારરૂપ લાગે છે. પરંતુ અમારા સ્પર્ધકો આ પરીક્ષા સફળતાપૂર્વક પાસ કરે છે. બેન્ચમાર્ક પરિણામો:

• વિક્ટોરિયામેટ્રિક્સ: 2,2M ડેટા પોઈન્ટ પ્રતિ સેકન્ડ; રેમ વપરાશ: 6 જીબી; ડિસ્ક પર અંતિમ ડેટા કદ: 3 જીબી.
• InfluxDB: 330K ડેટા પોઈન્ટ પ્રતિ સેકન્ડ; રેમ વપરાશ: 20,5 જીબી; ડિસ્ક પર અંતિમ ડેટા કદ: 18,4 GB.
• ટાઈમસ્કેલડીબી: 480K ડેટા પોઈન્ટ પ્રતિ સેકન્ડ; રેમ વપરાશ: 2,5 જીબી; ડિસ્ક પર અંતિમ ડેટા કદ: 52 જીબી.

InfluxDB કામગીરી 1,2K સમય શ્રેણી માટે 400M ડેટા પોઈન્ટ પ્રતિ સેકન્ડથી ઘટીને 330M સમય શ્રેણી માટે 4K ડેટા પોઈન્ટ પ્રતિ સેકન્ડ થઈ ગઈ છે. અન્ય સ્પર્ધકોની સરખામણીમાં આ નોંધપાત્ર પ્રદર્શન નુકશાન છે. ચાલો આ નુકસાનના મૂળ કારણને સમજવા માટે CPU વપરાશ ગ્રાફ્સ જોઈએ:

ઉપર એક સ્ક્રીનશૉટ છે: VictoriaMetrics - એક અનન્ય 4M સમય શ્રેણી માટે નિવેશ પરીક્ષણ દરમિયાન CPU વપરાશ.

ઉપર એક સ્ક્રીનશૉટ છે: અનન્ય 4M સમય શ્રેણી માટે નિવેશ પરીક્ષણ દરમિયાન InfluxDB - CPU વપરાશ.

ઉપર એક સ્ક્રીનશૉટ છે: ટાઇમસ્કેલડીબી - એક અનન્ય 4M સમય શ્રેણી માટે નિવેશ પરીક્ષણ દરમિયાન CPU વપરાશ.

VictoriaMetrics લગભગ તમામ પ્રોસેસિંગ યુનિટ (CPU) પાવરનો ઉપયોગ કરે છે. તમામ ડેટા દાખલ કરવામાં આવ્યા પછી અંતે ડ્રોપ બાકીના LSM મર્જને અનુરૂપ છે.

InfluxDB 8 માંથી માત્ર 16 vCPU નો ઉપયોગ કરે છે, જ્યારે TimsecaleDB 4 માંથી 16 vCPU નો ઉપયોગ કરે છે. તેમના આલેખમાં શું સામ્ય છે? ઉચ્ચ શેર 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 નો ઉપયોગ કરવો.

ઉપર એક સ્ક્રીનશોટ છે: અનન્ય 4M સમય શ્રેણી માટે નિવેશ પરીક્ષણ દરમિયાન TimescaleDB - I/O નો ઉપયોગ.

IO વપરાશ પેટર્ન ડિસ્ક બેન્ડવિડ્થની પ્રતિબિંબિત કરે છે - InfluxDB IO મર્યાદિત છે, જ્યારે VictoriaMetrics અને TimescaleDB પાસે ફાજલ IO સંસાધનો છે.

40M અનન્ય સમય શ્રેણી

InfluxDB માટે 40M અનન્ય સમય શ્રેણી ખૂબ મોટી હતી :)

બેન્ચમાર્ક પરિણામો:

• વિક્ટોરિયામેટ્રિક્સ: 1,7M ડેટા પોઈન્ટ પ્રતિ સેકન્ડ; રેમ વપરાશ: 29 જીબી; ડિસ્ક જગ્યા વપરાશ: 17 GB.
• InfluxDB: સમાપ્ત થયું નથી કારણ કે તેને 60GB થી વધુ RAM ની જરૂર છે.
• TimescaleDB: 330K ડેટા પોઈન્ટ પ્રતિ સેકન્ડ, RAM વપરાશ: 2,5 GB; ડિસ્ક જગ્યા વપરાશ: 84GB.

TimescaleDB 2,5 GB પર અપવાદરૂપે ઓછો અને સ્થિર RAM નો ઉપયોગ બતાવે છે - જે અનન્ય 4M અને 400K મેટ્રિક્સ માટે છે.

તમામ 100M ટૅગ કરેલા મેટ્રિક નામો પર પ્રક્રિયા ન થાય ત્યાં સુધી વિક્ટોરિયામેટ્રિક્સે ધીમે ધીમે 40k ડેટા પોઈન્ટ પ્રતિ સેકન્ડના દરે સ્કેલ કર્યું. ત્યારબાદ તેણે 1,5-2,0M ડેટા પોઈન્ટ પ્રતિ સેકન્ડનો સતત નિવેશ દર હાંસલ કર્યો, તેથી અંતિમ પરિણામ 1,7M ડેટા પોઈન્ટ પ્રતિ સેકન્ડ હતું.

40M અનન્ય સમય શ્રેણી માટેના ગ્રાફ 4M અનન્ય સમય શ્રેણી માટેના ગ્રાફ જેવા જ છે, તેથી ચાલો તેમને છોડી દઈએ.

તારણો

• આધુનિક TSDBs એક સર્વર પર લાખો અનન્ય સમય શ્રેણી માટે ઇન્સર્ટ્સ પ્રક્રિયા કરવા સક્ષમ છે. આગલા લેખમાં, અમે ચકાસીશું કે TSDBs લાખો અનન્ય સમય શ્રેણીમાં પસંદગી કેટલી સારી રીતે કરે છે.
• અપર્યાપ્ત CPU ઉપયોગ સામાન્ય રીતે I/O અવરોધ સૂચવે છે. તે એ પણ સૂચવી શકે છે કે અવરોધિત કરવું ખૂબ બરછટ છે, એક સમયે માત્ર થોડા થ્રેડો ચલાવવા માટે સક્ષમ છે.
• I/O અડચણ અસ્તિત્વમાં છે, ખાસ કરીને નોન-એસએસડી સ્ટોરેજમાં જેમ કે ક્લાઉડ પ્રદાતાઓના વર્ચ્યુઅલાઈઝ્ડ બ્લોક ઉપકરણો.
• VictoriaMetrics ધીમા, ઓછા I/O સ્ટોરેજ માટે શ્રેષ્ઠ ઑપ્ટિમાઇઝેશન પ્રદાન કરે છે. તે શ્રેષ્ઠ ગતિ અને શ્રેષ્ઠ કમ્પ્રેશન રેશિયો પ્રદાન કરે છે.

ડાઉનલોડ કરો VictoriaMetrics સિંગલ-સર્વર છબી અને તેને તમારા ડેટા પર અજમાવી જુઓ. અનુરૂપ સ્થિર દ્વિસંગી અહીં ઉપલબ્ધ છે GitHub.

આમાં VictoriaMetrics વિશે વધુ વાંચો લેખ.

અપડેટ: પ્રકાશિત InfluxDB સાથે VictoriaMetrics ના ઇન્સર્ટ પ્રદર્શનની સરખામણી કરતો લેખ પુનઃઉત્પાદન પરિણામો સાથે.

અપડેટ #2: પણ વાંચો વર્ટિકલ સ્કેલેબિલિટી પર લેખ VictoriaMetrics vs InfluxDB vs TimescaleDB.

અપડેટ #3: VictoriaMetrics હવે ઓપન સોર્સ છે!

ટેલિગ્રામ ચેટ: https://t.me/VictoriaMetrics_ru1

સોર્સ: www.habr.com