ഉയർന്ന പ്രകടനമുള്ള TSDB ബെഞ്ച്മാർക്ക് വിക്ടോറിയമെട്രിക്സ് vs ടൈംസ്കെയിൽDB vs InfluxDB

VictoriaMetrics, TimescaleDB, InfluxDB എന്നിവ താരതമ്യം ചെയ്തു മുമ്പത്തെ ലേഖനം 40K അദ്വിതീയ സമയ ശ്രേണിയിൽ പെട്ട ഒരു ബില്യൺ ഡാറ്റാ പോയിന്റുകളുള്ള ഒരു ഡാറ്റാസെറ്റിൽ.

കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് സാബിക്സിന്റെ ഒരു യുഗമുണ്ടായിരുന്നു. ഓരോ ബെയർ മെറ്റൽ സെർവറിനും കുറച്ച് സൂചകങ്ങളിൽ കൂടുതലുണ്ടായിരുന്നില്ല - സിപിയു ഉപയോഗം, റാം ഉപയോഗം, ഡിസ്ക് ഉപയോഗം, നെറ്റ്‌വർക്ക് ഉപയോഗം. ഈ രീതിയിൽ, ആയിരക്കണക്കിന് സെർവറുകളിൽ നിന്നുള്ള മെട്രിക്‌സിന് 40 ആയിരം അദ്വിതീയ സമയ ശ്രേണിയിലേക്ക് യോജിക്കാൻ കഴിയും, കൂടാതെ Zabbix-ന് ടൈം സീരീസ് ഡാറ്റയ്ക്കുള്ള ഒരു ബാക്കെൻഡായി MySQL ഉപയോഗിക്കാൻ കഴിയും :)

നിലവിൽ തനിച്ചാണ് node_exporter സ്ഥിരസ്ഥിതി കോൺഫിഗറേഷനുകൾക്കൊപ്പം ശരാശരി ഹോസ്റ്റിൽ 500-ലധികം മെട്രിക്കുകൾ നൽകുന്നു. നിരവധിയുണ്ട് കയറ്റുമതിക്കാർ വിവിധ ഡാറ്റാബേസുകൾ, വെബ് സെർവറുകൾ, ഹാർഡ്‌വെയർ സിസ്റ്റങ്ങൾ മുതലായവയ്ക്ക്. അവയെല്ലാം ഉപയോഗപ്രദമായ വിവിധ അളവുകൾ നൽകുന്നു. എല്ലാം കൂടുതൽ കൂടുതൽ ആപ്ലിക്കേഷനുകൾ അവർക്കായി വിവിധ സൂചകങ്ങൾ സജ്ജമാക്കാൻ തുടങ്ങുന്നു. നിരവധി അളവുകൾ വെളിപ്പെടുത്തുന്ന ക്ലസ്റ്ററുകളും പോഡുകളുമുള്ള കുബർനെറ്റസ് ഉണ്ട്. ഇത് ഓരോ ഹോസ്റ്റിനും ആയിരക്കണക്കിന് അദ്വിതീയ മെട്രിക്കുകൾ വെളിപ്പെടുത്തുന്ന സെർവറുകളിൽ കലാശിക്കുന്നു. അതിനാൽ അദ്വിതീയമായ 40K സമയ ശ്രേണി മേലിൽ ഉയർന്ന പവർ ആയിരിക്കില്ല. ഇത് മുഖ്യധാരയായി മാറിക്കൊണ്ടിരിക്കുന്നു, ഒരൊറ്റ സെർവറിൽ ഏത് ആധുനിക ടിഎസ്ഡിബിയും എളുപ്പത്തിൽ കൈകാര്യം ചെയ്യണം.

ഇപ്പോഴുള്ള അദ്വിതീയ സമയ ശ്രേണികളുടെ വലിയ സംഖ്യ എന്താണ്? ഒരുപക്ഷേ 400K അല്ലെങ്കിൽ 4M? അതോ 40 മീ? ആധുനിക TSDB-കളെ ഈ സംഖ്യകളുമായി താരതമ്യം ചെയ്യാം.

ഒരു ബെഞ്ച്മാർക്ക് ഇൻസ്റ്റാൾ ചെയ്യുന്നു

ടി.എസ്.ബി.എസ് TSDB-കൾക്കുള്ള ഒരു മികച്ച ബെഞ്ച്മാർക്കിംഗ് ഉപകരണമാണ്. ആവശ്യമായ സമയ ശ്രേണിയെ 10 കൊണ്ട് ഹരിച്ചുകൊണ്ട് അനിയന്ത്രിതമായ മെട്രിക്കുകൾ സൃഷ്ടിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു - ഫ്ലാഗ് - സ്കെയിൽ (മുൻ -scale-var). 10 എന്നത് ഓരോ ഹോസ്റ്റിലോ സെർവറിലോ ജനറേറ്റ് ചെയ്യുന്ന അളവുകളുടെ (മെട്രിക്‌സ്) എണ്ണമാണ്. ബെഞ്ച്മാർക്കിനായി ടിഎസ്ബിഎസ് ഉപയോഗിച്ച് ഇനിപ്പറയുന്ന ഡാറ്റാസെറ്റുകൾ സൃഷ്ടിച്ചു:

• 400K അദ്വിതീയ സമയ ശ്രേണി, ഡാറ്റാ പോയിന്റുകൾക്കിടയിലുള്ള 60 സെക്കൻഡ് ഇടവേള, ഡാറ്റ മുഴുവൻ 3 ദിവസം, ~1.7B ഡാറ്റാ പോയിന്റുകളുടെ ആകെ എണ്ണം.
• 4M അദ്വിതീയ സമയ ശ്രേണി, 600 സെക്കൻഡ് ഇടവേള, ഡാറ്റ 3 മുഴുവൻ ദിവസങ്ങൾ, ~1.7B ഡാറ്റാ പോയിന്റുകളുടെ ആകെ എണ്ണം.
• 40M അദ്വിതീയ സമയ ശ്രേണി, 1 മണിക്കൂർ ഇടവേള, ഡാറ്റ 3 മുഴുവൻ ദിവസങ്ങൾ, ~2.8B ഡാറ്റാ പോയിന്റുകളുടെ ആകെ എണ്ണം.

ക്ലയന്റും സെർവറും സമർപ്പിത സന്ദർഭങ്ങളിൽ പ്രവർത്തിക്കുന്നു n1-സ്റ്റാൻഡേർഡ്-16 Google ക്ലൗഡിൽ. ഈ സന്ദർഭങ്ങളിൽ ഇനിപ്പറയുന്ന കോൺഫിഗറേഷനുകൾ ഉണ്ടായിരുന്നു:

• vCPU-കൾ: 16
• റാം: 60 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

16 സമാന്തര ത്രെഡുകൾ ഉപയോഗിച്ചാണ് ഡാറ്റ ലോഡർ പ്രവർത്തിപ്പിച്ചത്.

ഈ ലേഖനത്തിൽ ഉൾപ്പെടുത്തൽ ബെഞ്ച്മാർക്കുകൾക്കുള്ള ഫലങ്ങൾ മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ. തിരഞ്ഞെടുത്ത ബെഞ്ച്മാർക്കിന്റെ ഫലങ്ങൾ ഒരു പ്രത്യേക ലേഖനത്തിൽ പ്രസിദ്ധീകരിക്കും.

400K അദ്വിതീയ സമയ ശ്രേണി

ലളിതമായ ഘടകങ്ങളിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം - 400K. ബെഞ്ച്മാർക്ക് ഫലങ്ങൾ:

• വിക്ടോറിയമെട്രിക്സ്: സെക്കൻഡിൽ 2,6M ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 3 ജിബി; ഡിസ്കിലെ അവസാന ഡാറ്റ വലുപ്പം: 965 MB
• InfluxDB: സെക്കൻഡിൽ 1.2M ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 8.5 GB; ഡിസ്കിലെ അവസാന ഡാറ്റ വലുപ്പം: 1.6 GB
• ടൈംസ്കെയിൽ: സെക്കൻഡിൽ 849K ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 2,5 GB; ഡിസ്കിലെ അവസാന ഡാറ്റ വലുപ്പം: 50 GB

മുകളിലെ ഫലങ്ങളിൽ നിന്ന് നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഉൾപ്പെടുത്തൽ പ്രകടനത്തിലും കംപ്രഷൻ അനുപാതത്തിലും VictoriaMetrics വിജയിക്കുന്നു. റാം ഉപയോഗത്തിൽ ടൈംലൈൻ വിജയിക്കുന്നു, പക്ഷേ ഇത് ധാരാളം ഡിസ്ക് സ്പേസ് ഉപയോഗിക്കുന്നു - ഓരോ ഡാറ്റാ പോയിന്റിനും 29 ബൈറ്റുകൾ.

ബെഞ്ച്മാർക്ക് സമയത്ത് ഓരോ TSDB-കൾക്കുമുള്ള CPU ഉപയോഗ ഗ്രാഫുകൾ ചുവടെയുണ്ട്:

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: വിക്ടോറിയമെട്രിക്സ് - ഒരു അദ്വിതീയ 400K മെട്രിക്കിനുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് CPU ലോഡ്.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: InfluxDB - അതുല്യമായ മെട്രിക് 400K-നുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് CPU ലോഡ്.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: ടൈംസ്‌കെയിൽഡിബി - 400കെയുടെ അദ്വിതീയ മെട്രിക്കിനുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് സിപിയു ലോഡ്.

VictoriaMetrics ലഭ്യമായ എല്ലാ vCPU-കളും ഉപയോഗിക്കുന്നു, അതേസമയം InfluxDB 2 vCPU-കളിൽ ~16 ഉപയോഗപ്പെടുത്തുന്നില്ല.

ടൈംസ്‌കെയിൽ 3 vCPU-കളിൽ 4-16 എണ്ണം മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ. ടൈംസ്‌കെയിൽഡിബി ടൈംസ്‌കെയിൽ ഗ്രാഫിലെ iowait-ന്റെയും സിസ്റ്റത്തിന്റെയും ഉയർന്ന അനുപാതങ്ങൾ ഇൻപുട്ട്/ഔട്ട്‌പുട്ട് (I/O) സബ്‌സിസ്റ്റത്തിലെ തടസ്സത്തെ സൂചിപ്പിക്കുന്നു. ഡിസ്ക് ബാൻഡ്‌വിഡ്ത്ത് ഉപയോഗ ഗ്രാഫുകൾ നോക്കാം:

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട് ആണ്: വിക്ടോറിയമെട്രിക്സ് - 400കെ യുണീക് മെട്രിക്സിനായുള്ള ഇൻസെർഷൻ ടെസ്റ്റിലെ ഡിസ്ക് ബാൻഡ്വിഡ്ത്ത് ഉപയോഗം.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: InfluxDB - 400K തനതായ മെട്രിക്‌സിനായുള്ള ഇൻസേർഷൻ ടെസ്റ്റിലെ ഡിസ്‌ക് ബാൻഡ്‌വിഡ്ത്ത് ഉപയോഗം.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: ടൈംസ്‌കെയിൽഡിബി - 400കെ യുണീക് മെട്രിക്‌സിനായുള്ള ഇൻസേർഷൻ ടെസ്റ്റിലെ ഡിസ്‌ക് ബാൻഡ്‌വിഡ്ത്ത് ഉപയോഗം.

VictoriaMetrics 20 Mbps വേഗതയിൽ 45 Mbps വരെ ഉയർന്ന ഡാറ്റ രേഖപ്പെടുത്തുന്നു. മരത്തിലെ വലിയ ഭാഗിക ലയനങ്ങളുമായി കൊടുമുടികൾ യോജിക്കുന്നു എൻ‌ജി‌ഒ.

InfluxDB 160 MB/s-ൽ ഡാറ്റ എഴുതുന്നു, അതേസമയം 1 TB ഡ്രൈവ് പരിമിതപ്പെടുത്തണം ത്രോപുട്ട് 120 MB/s എഴുതുക.

ടൈംസ്‌കെയിൽഡിബി 120 എംബിപിഎസ് ത്രോപുട്ട് എഴുതാൻ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, എന്നാൽ ചിലപ്പോൾ ഇത് ഈ പരിധി ലംഘിക്കുകയും പീക്ക് മൂല്യങ്ങളിൽ 220 എംബിപിഎസിൽ എത്തുകയും ചെയ്യുന്നു. ഈ കൊടുമുടികൾ മുമ്പത്തെ ഗ്രാഫിലെ അപര്യാപ്തമായ സിപിയു ഉപയോഗത്തിന്റെ താഴ്വരകളുമായി പൊരുത്തപ്പെടുന്നു.

നമുക്ക് ഇൻപുട്ട്/ഔട്ട്പുട്ട് (I/O) ഉപയോഗ ഗ്രാഫുകൾ നോക്കാം:

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: വിക്ടോറിയമെട്രിക്സ് - 400K അദ്വിതീയ മെട്രിക്കുകൾക്കായി ടെസ്റ്റ് I/O ഉപയോഗം ചേർക്കുക.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: InfluxDB - 400K തനത് മെട്രിക്കുകൾക്കായി ടെസ്റ്റ് I/O ഉപയോഗം ചേർക്കുക.

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: TimescaleDB - 400K അദ്വിതീയ മെട്രിക്കുകൾക്കായി ടെസ്റ്റ് I/O ഉപയോഗം ചേർക്കുക.

TimescaleDB അതിന്റെ I/O പരിധിയിൽ എത്തുന്നുവെന്ന് ഇപ്പോൾ വ്യക്തമാണ്, അതിനാൽ അതിന് ശേഷിക്കുന്ന 12 vCPU-കൾ ഉപയോഗിക്കാൻ കഴിയില്ല.

4M അദ്വിതീയ സമയ ശ്രേണി

4M സമയ ശ്രേണി അൽപ്പം വെല്ലുവിളി നിറഞ്ഞതായി തോന്നുന്നു. എന്നാൽ ഞങ്ങളുടെ മത്സരാർത്ഥികൾ ഈ പരീക്ഷയിൽ വിജയിക്കുന്നു. ബെഞ്ച്മാർക്ക് ഫലങ്ങൾ:

• വിക്ടോറിയമെട്രിക്സ്: സെക്കൻഡിൽ 2,2M ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 6 ജിബി; ഡിസ്കിലെ അവസാന ഡാറ്റ വലുപ്പം: 3 GB.
• InfluxDB: സെക്കൻഡിൽ 330K ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 20,5 GB; ഡിസ്കിലെ അവസാന ഡാറ്റ വലുപ്പം: 18,4 GB.
• TimescaleDB: സെക്കൻഡിൽ 480K ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 2,5 GB; ഡിസ്കിലെ അവസാന ഡാറ്റ വലുപ്പം: 52 GB.

InfluxDB പ്രകടനം 1,2K ടൈം സീരീസിന് സെക്കൻഡിൽ 400M ഡാറ്റ പോയിന്റിൽ നിന്ന് 330M ടൈം സീരീസിന് സെക്കൻഡിൽ 4K ഡാറ്റ പോയിന്റായി കുറഞ്ഞു. മറ്റ് എതിരാളികളെ അപേക്ഷിച്ച് ഇത് കാര്യമായ പ്രകടന നഷ്ടമാണ്. ഈ നഷ്ടത്തിന്റെ മൂലകാരണം മനസ്സിലാക്കാൻ CPU ഉപയോഗ ഗ്രാഫുകൾ നോക്കാം:

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: വിക്ടോറിയമെട്രിക്സ് - ഒരു അദ്വിതീയ 4M ടൈം സീരീസിനുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് CPU ഉപയോഗം.

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: InfluxDB - അതുല്യമായ 4M ടൈം സീരീസിനുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് CPU ഉപയോഗം.

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: TimescaleDB - ഒരു അദ്വിതീയ 4M ടൈം സീരീസിനുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് CPU ഉപയോഗം.

വിക്ടോറിയമെട്രിക്സ് മിക്കവാറും എല്ലാ പ്രോസസ്സിംഗ് യൂണിറ്റ് (സിപിയു) പവറും ഉപയോഗിക്കുന്നു. എല്ലാ ഡാറ്റയും ചേർത്തതിന് ശേഷം ശേഷിക്കുന്ന LSM ലയനങ്ങളുമായി അവസാനത്തെ ഡ്രോപ്പ് യോജിക്കുന്നു.

InfluxDB 8 vCPU-കളിൽ 16 എണ്ണം മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ, TimsecaleDB 4 vCPU-കളിൽ 16 എണ്ണം ഉപയോഗിക്കുന്നു. അവരുടെ ഗ്രാഫുകൾക്ക് പൊതുവായി എന്താണുള്ളത്? ഉയർന്ന പങ്ക് iowait, ഇത് വീണ്ടും ഒരു I/O തടസ്സത്തെ സൂചിപ്പിക്കുന്നു.

TimescaleDB-ക്ക് ഉയർന്ന പങ്കുണ്ട് system. ഉയർന്ന പവർ നിരവധി സിസ്റ്റം കോളുകൾക്ക് കാരണമായോ അല്ലെങ്കിൽ പലതിനും കാരണമായെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു ചെറിയ പേജ് തെറ്റുകൾ.

ഡിസ്ക് ത്രൂപുട്ട് ഗ്രാഫുകൾ നോക്കാം:

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: വിക്ടോറിയമെട്രിക്സ് - 4M അദ്വിതീയ മെട്രിക്സ് ചേർക്കാൻ ഡിസ്ക് ബാൻഡ്വിഡ്ത്ത് ഉപയോഗിക്കുന്നു.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: InfluxDB - 4M അദ്വിതീയ മെട്രിക്‌സ് ചേർക്കാൻ ഡിസ്‌ക് ബാൻഡ്‌വിഡ്ത്ത് ഉപയോഗിക്കുന്നു.

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: TimescaleDB - 4M അദ്വിതീയ മെട്രിക്സ് ചേർക്കാൻ ഡിസ്ക് ബാൻഡ്വിഡ്ത്ത് ഉപയോഗിക്കുന്നു.

VictoriaMetrics ഏറ്റവും ഉയർന്ന സമയത്ത് 120 MB/s എന്ന പരിധിയിലെത്തി, ശരാശരി എഴുത്ത് വേഗത 40 MB/s ആയിരുന്നു. പീക്ക് സമയത്ത് നിരവധി കനത്ത എൽഎസ്എം ഫ്യൂഷനുകൾ നടത്തിയിരിക്കാൻ സാധ്യതയുണ്ട്.

200 MB/s റൈറ്റ് ലിമിറ്റ് ഉള്ള ഒരു ഡിസ്‌കിൽ 340 MB/s വരെ പീക്കുകളോടെ InfluxDB വീണ്ടും 120 MB/s എന്ന ശരാശരി റൈറ്റ് ത്രൂപുട്ട് പുറത്തെടുക്കുന്നു :)

TimescaleDB ഇനി ഡിസ്ക് പരിമിതമല്ല. ഉയർന്ന അനുപാതവുമായി ബന്ധപ്പെട്ട മറ്റെന്തെങ്കിലും കൊണ്ട് ഇത് പരിമിതപ്പെടുത്തിയതായി തോന്നുന്നു системной സിപിയു ലോഡ്.

നമുക്ക് IO ഉപയോഗ ഗ്രാഫുകൾ നോക്കാം:

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: വിക്ടോറിയമെട്രിക്സ് - ഒരു അദ്വിതീയ 4M ടൈം സീരീസിനായി ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് I/O ഉപയോഗിക്കുന്നു.

മുകളിൽ ഒരു സ്ക്രീൻഷോട്ട്: InfluxDB - ഒരു അദ്വിതീയ 4M ടൈം സീരീസിനായി ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് I/O ഉപയോഗിക്കുന്നു.

മുകളിൽ ഒരു സ്‌ക്രീൻഷോട്ട്: ടൈംസ്‌കെയിൽDB - അതുല്യമായ 4M ടൈം സീരീസിനുള്ള ഇൻസേർഷൻ ടെസ്റ്റ് സമയത്ത് I/O ഉപയോഗം.

IO ഉപയോഗ പാറ്റേണുകൾ ഡിസ്‌ക് ബാൻഡ്‌വിഡ്‌ത്തിനെ പ്രതിഫലിപ്പിക്കുന്നു - InfluxDB IO പരിമിതമാണ്, അതേസമയം VictoriaMetrics, TimescaleDB എന്നിവയ്ക്ക് സ്പെയർ ഐഒ ഉറവിടങ്ങളുണ്ട്.

40M അദ്വിതീയ സമയ ശ്രേണി

InfluxDB-യ്‌ക്ക് 40M അദ്വിതീയ സമയ ശ്രേണി വളരെ വലുതായിരുന്നു :)

ബെഞ്ച്മാർക്ക് ഫലങ്ങൾ:

• വിക്ടോറിയമെട്രിക്സ്: സെക്കൻഡിൽ 1,7M ഡാറ്റ പോയിന്റുകൾ; റാം ഉപയോഗം: 29 GB; ഡിസ്ക് സ്പേസ് ഉപയോഗം: 17 GB.
• InfluxDB: 60GB-ൽ കൂടുതൽ റാം ആവശ്യമുള്ളതിനാൽ പൂർത്തിയായില്ല.
• ടൈംസ്‌കെയിൽഡിബി: സെക്കൻഡിൽ 330K ഡാറ്റ പോയിന്റുകൾ, റാം ഉപയോഗം: 2,5 GB; ഡിസ്ക് സ്പേസ് ഉപയോഗം: 84GB.

ടൈംസ്‌കെയിൽഡിബി 2,5 ജിബിയിൽ വളരെ കുറഞ്ഞതും സ്ഥിരതയുള്ളതുമായ റാം ഉപയോഗം കാണിക്കുന്നു - അതുല്യമായ 4 എം, 400 കെ മെട്രിക്‌സിന് സമാനമാണ്.

100M ടാഗുചെയ്‌ത മെട്രിക് പേരുകൾ പ്രോസസ്സ് ചെയ്യുന്നതുവരെ VictoriaMetrics ഒരു സെക്കൻഡിൽ 40k ഡാറ്റാ പോയിന്റുകൾ എന്ന നിരക്കിൽ സാവധാനം സ്കെയിൽ ചെയ്തു. തുടർന്ന് അദ്ദേഹം സെക്കൻഡിൽ 1,5-2,0M ഡാറ്റ പോയിന്റുകളുടെ സുസ്ഥിരമായ ഇൻസെർഷൻ നിരക്ക് കൈവരിച്ചു, അതിനാൽ അവസാന ഫലം സെക്കൻഡിൽ 1,7M ഡാറ്റ പോയിന്റുകൾ ആയിരുന്നു.

40M അദ്വിതീയ സമയ ശ്രേണിയുടെ ഗ്രാഫുകൾ 4M അദ്വിതീയ സമയ ശ്രേണിയുടെ ഗ്രാഫുകൾക്ക് സമാനമാണ്, അതിനാൽ നമുക്ക് അവ ഒഴിവാക്കാം.

കണ്ടെത്തലുകൾ

• ഒരൊറ്റ സെർവറിൽ ദശലക്ഷക്കണക്കിന് അദ്വിതീയ സമയ ശ്രേണികൾക്കുള്ള ഇൻസെർട്ടുകൾ പ്രോസസ്സ് ചെയ്യാൻ ആധുനിക TSDB-കൾക്ക് കഴിയും. ദശലക്ഷക്കണക്കിന് അദ്വിതീയ സമയ ശ്രേണികളിലുടനീളം TSDB-കൾ എത്ര നന്നായി തിരഞ്ഞെടുക്കുന്നുവെന്ന് അടുത്ത ലേഖനത്തിൽ ഞങ്ങൾ പരിശോധിക്കും.
• അപര്യാപ്തമായ സിപിയു ഉപയോഗം സാധാരണയായി ഒരു I/O തടസ്സത്തെ സൂചിപ്പിക്കുന്നു. ഒരു സമയം കുറച്ച് ത്രെഡുകൾ മാത്രമേ പ്രവർത്തിപ്പിക്കാൻ കഴിയൂ എന്നതിനാൽ, തടയൽ വളരെ പരുക്കൻ ആണെന്നും ഇത് സൂചിപ്പിക്കാം.
• I/O തടസ്സം നിലവിലുണ്ട്, പ്രത്യേകിച്ച് ക്ലൗഡ് ദാതാക്കളുടെ വെർച്വലൈസ്ഡ് ബ്ലോക്ക് ഡിവൈസുകൾ പോലെയുള്ള SSD ഇതര സംഭരണത്തിൽ.
• വേഗത കുറഞ്ഞതും കുറഞ്ഞതുമായ I/O സ്റ്റോറേജിനുള്ള മികച്ച ഒപ്റ്റിമൈസേഷൻ VictoriaMetrics നൽകുന്നു. ഇത് മികച്ച വേഗതയും മികച്ച കംപ്രഷൻ അനുപാതവും നൽകുന്നു.

ഡൗൺലോഡ് വിക്ടോറിയമെട്രിക്സ് സിംഗിൾ സെർവർ ചിത്രം നിങ്ങളുടെ ഡാറ്റയിൽ ഇത് പരീക്ഷിക്കുക. അനുബന്ധ സ്റ്റാറ്റിക് ബൈനറി ഇവിടെ ലഭ്യമാണ് സാമൂഹികം.

വിക്ടോറിയമെട്രിക്സിനെ കുറിച്ച് ഇതിൽ കൂടുതൽ വായിക്കുക ലേഖനം.

അപ്ഡേറ്റ്: പ്രസിദ്ധീകരിച്ചു വിക്ടോറിയമെട്രിക്സിന്റെ ഇൻസെർട്ട് പ്രകടനത്തെ InfluxDB-യുമായി താരതമ്യം ചെയ്യുന്ന ലേഖനം പുനരുൽപ്പാദിപ്പിക്കാവുന്ന ഫലങ്ങളോടെ.

അപ്ഡേറ്റ് #2: ഇതും വായിക്കുക വെർട്ടിക്കൽ സ്കേലബിലിറ്റിയെക്കുറിച്ചുള്ള ലേഖനം വിക്ടോറിയമെട്രിക്സ് vs ഇൻഫ്ലക്സ് ഡിബി vs ടൈംസ്കെയിൽ ഡിബി.

അപ്ഡേറ്റ് #3: വിക്ടോറിയമെട്രിക്സ് ഇപ്പോൾ ഓപ്പൺ സോഴ്‌സാണ്!

ടെലിഗ്രാം ചാറ്റ്: https://t.me/VictoriaMetrics_ru1

അവലംബം: www.habr.com