VictoriaMetrics, TimescaleDB e InfluxDB foram comparados em em um conjunto de dados com um bilhão de pontos de dados pertencentes a séries temporais únicas de 40 mil.
Há alguns anos, houve uma era do Zabbix. Cada servidor bare metal não tinha mais do que alguns indicadores – uso de CPU, uso de RAM, uso de disco e uso de rede. Dessa forma, métricas de milhares de servidores podem caber em 40 mil séries temporais únicas, e o Zabbix pode usar o MySQL como backend para dados de séries temporais :)
Atualmente sozinho com configurações padrão fornece mais de 500 métricas no host médio. Existem muitos para vários bancos de dados, servidores web, sistemas de hardware, etc. Todos eles fornecem uma variedade de métricas úteis. Todos começam a definir vários indicadores para si próprios. Existe o Kubernetes com clusters e pods que expõem muitas métricas. Isso resulta em servidores expondo milhares de métricas exclusivas por host. Portanto, a série temporal exclusiva de 40K não é mais de alta potência. Está se tornando popular e deve ser facilmente gerenciado por qualquer TSDB moderno em um único servidor.
Qual é o grande número de séries temporais exclusivas no momento? Provavelmente 400K ou 4M? Ou 40m? Vamos comparar os TSDBs modernos com esses números.
Instalando um benchmark
é uma excelente ferramenta de benchmarking para TSDBs. Ele permite gerar um número arbitrário de métricas passando o número necessário de séries temporais dividido por 10 - sinalizador (antigo -scale-var). 10 é o número de medições (métricas) geradas em cada host ou servidor. Os seguintes conjuntos de dados foram gerados usando TSBS para benchmark:
- Séries temporais exclusivas de 400 mil, intervalo de 60 segundos entre pontos de dados, dados abrangendo 3 dias completos, número total de aproximadamente 1.7 bilhão de pontos de dados.
- Série temporal exclusiva de 4 milhões, intervalo de 600 segundos, dados abrangendo 3 dias completos, número total de aproximadamente 1.7 bilhão de pontos de dados.
- Séries temporais exclusivas de 40 milhões, intervalo de 1 hora, dados abrangem 3 dias completos, número total de aproximadamente 2.8 bilhões de pontos de dados.
O cliente e o servidor estavam rodando em instâncias dedicadas na nuvem do Google. Essas instâncias tinham as seguintes configurações:
- vCPUs: 16
- RAM: 60 GB
- Armazenamento: HDD padrão de 1 TB. Ele fornece taxa de transferência de leitura/gravação de 120 Mbps, 750 operações de leitura por segundo e 1,5 mil gravações por segundo.
Os TSDBs foram extraídos de imagens oficiais do docker e executados no docker com as seguintes configurações:
-
Métricas Victoria:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Os valores do InfluxDB (-e) são necessários para suportar alta potência. Veja detalhes em ):
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 (configuração retirada de arquivo):
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=100O carregador de dados foi executado com 16 threads paralelos.
Este artigo contém apenas resultados para benchmarks de inserção. Os resultados do benchmark seletivo serão publicados em artigo separado.
Série temporal única de 400 mil
Vamos começar com elementos simples – 400K. Resultados de referência:
- VictoriaMetrics: 2,6 milhões de pontos de dados por segundo; Uso de RAM: 3 GB; tamanho final dos dados no disco: 965 MB
- InfluxDB: 1.2 milhões de pontos de dados por segundo; Uso de RAM: 8.5 GB; tamanho final dos dados no disco: 1.6 GB
- Escala de tempo: 849 mil pontos de dados por segundo; Uso de RAM: 2,5 GB; tamanho final dos dados no disco: 50 GB
Como você pode ver nos resultados acima, VictoriaMetrics vence em desempenho de inserção e taxa de compactação. A linha do tempo vence no uso de RAM, mas usa muito espaço em disco - 29 bytes por ponto de dados.
Abaixo estão os gráficos de uso de CPU para cada um dos TSDBs durante o benchmark:
Acima está uma captura de tela: VictoriaMetrics - Carga da CPU durante o teste de inserção para uma métrica exclusiva de 400K.
Acima está uma captura de tela: InfluxDB - Carga da CPU durante o teste de inserção para métrica exclusiva de 400K.
Acima está uma captura de tela: TimescaleDB - Carga da CPU durante o teste de inserção para uma métrica exclusiva de 400K.
VictoriaMetrics usa todas as vCPUs disponíveis, enquanto o InfluxDB subutiliza cerca de 2 de 16 vCPUs.
A escala de tempo usa apenas 3 a 4 das 16 vCPUs. Altas proporções de iowait e sistema no gráfico de escala de tempo do TimescaleDB indicam um gargalo no subsistema de entrada/saída (E/S). Vejamos os gráficos de uso de largura de banda do disco:
Acima está uma captura de tela: VictoriaMetrics - Uso de largura de banda de disco no teste de inserção para métricas exclusivas 400K.
Acima está uma captura de tela: InfluxDB - Uso de largura de banda de disco no teste de inserção para métricas exclusivas 400K.
Acima está uma captura de tela: TimescaleDB - Uso de largura de banda de disco no teste de inserção para métricas exclusivas 400K.
VictoriaMetrics registra dados a 20 Mbps com picos de até 45 Mbps. Os picos correspondem a grandes fusões parciais na árvore .
InfluxDB grava dados a 160 MB/s, enquanto uma unidade de 1 TB taxa de transferência de gravação de 120 MB/s.
O TimescaleDB está limitado a uma taxa de transferência de gravação de 120 Mbps, mas às vezes ultrapassa esse limite e atinge 220 Mbps em valores de pico. Esses picos correspondem aos vales de utilização insuficiente da CPU no gráfico anterior.
Vejamos os gráficos de uso de entrada/saída (E/S):
Acima está uma captura de tela: VictoriaMetrics - Insira o uso de E/S de teste para 400 mil métricas exclusivas.
Acima está uma captura de tela: InfluxDB - Insira o uso de E/S de teste para 400 mil métricas exclusivas.
Acima está uma captura de tela: TimescaleDB - Insira o uso de E/S de teste para 400 mil métricas exclusivas.
Agora está claro que o TimescaleDB está atingindo seu limite de E/S e, portanto, não pode usar as 12 vCPUs restantes.
Série temporal única de 4 milhões
As séries temporais 4M parecem um pouco desafiadoras. Mas nossos concorrentes passaram neste exame com sucesso. Resultados de referência:
- VictoriaMetrics: 2,2 milhões de pontos de dados por segundo; Uso de RAM: 6 GB; tamanho final dos dados no disco: 3 GB.
- InfluxDB: 330 mil pontos de dados por segundo; Uso de RAM: 20,5 GB; tamanho final dos dados no disco: 18,4 GB.
- TimescaleDB: 480 mil pontos de dados por segundo; Uso de RAM: 2,5 GB; tamanho final dos dados no disco: 52 GB.
O desempenho do InfluxDB caiu de 1,2 milhão de pontos de dados por segundo para uma série temporal de 400 mil para 330 mil pontos de dados por segundo para uma série temporal de 4 milhões. Esta é uma perda significativa de desempenho em comparação com outros concorrentes. Vejamos os gráficos de uso da CPU para entender a causa raiz dessa perda:
Acima está uma captura de tela: VictoriaMetrics - uso de CPU durante o teste de inserção para uma série temporal exclusiva de 4M.
Acima está uma captura de tela: InfluxDB - uso de CPU durante o teste de inserção para séries temporais exclusivas de 4M.
Acima está uma captura de tela: TimescaleDB - uso da CPU durante o teste de inserção para uma série temporal exclusiva de 4M.
VictoriaMetrics usa quase toda a energia da unidade de processamento (CPU). A queda no final corresponde às mesclagens restantes do LSM após todos os dados terem sido inseridos.
O InfluxDB usa apenas 8 de 16 vCPUs, enquanto o TimsecaleDB usa 4 de 16 vCPUs. O que seus gráficos têm em comum? Alta participação iowait, o que novamente indica um gargalo de E/S.
TimescaleDB tem uma alta participação system. Assumimos que a alta potência resultou em muitas chamadas de sistema ou muitos .
Vejamos os gráficos de rendimento do disco:
Acima está uma captura de tela: VictoriaMetrics - Usando largura de banda de disco para inserir 4 milhões de métricas exclusivas.
Acima está uma captura de tela: InfluxDB - Usando largura de banda do disco para inserir 4 milhões de métricas exclusivas.
Acima está uma captura de tela: TimescaleDB - Usando largura de banda de disco para inserir métricas exclusivas de 4 milhões.
VictoriaMetrics atingiu um limite de 120 MB/s no pico, enquanto a velocidade média de gravação foi de 40 MB/s. É provável que várias fusões pesadas do LSM tenham sido realizadas durante o pico.
O InfluxDB novamente atinge uma taxa de transferência média de gravação de 200 MB/s com picos de até 340 MB/s em um disco com limite de gravação de 120 MB/s :)
TimescaleDB não é mais limitado em disco. Parece estar limitado por algo mais relacionado com a elevada proporção системной Carga da CPU.
Vejamos os gráficos de uso de IO:
Acima está uma captura de tela: VictoriaMetrics - Usando E/S durante o teste de inserção para uma série temporal exclusiva de 4M.
Acima está uma captura de tela: InfluxDB - Usando E/S durante o teste de inserção para uma série temporal exclusiva de 4M.
Acima está uma captura de tela: TimescaleDB - uso de E/S durante o teste de inserção para séries temporais exclusivas de 4M.
Os padrões de uso de IO refletem os da largura de banda do disco - o InfluxDB é limitado por IO, enquanto VictoriaMetrics e TimescaleDB possuem recursos de IO sobressalentes.
Série temporal única de 40 milhões
A série temporal única de 40 milhões era grande demais para o InfluxDB :)
Resultados de referência:
- VictoriaMetrics: 1,7 milhão de pontos de dados por segundo; Uso de RAM: 29 GB; Uso de espaço em disco: 17 GB.
- InfluxDB: Não foi concluído porque exigia mais de 60 GB de RAM.
- TimescaleDB: 330 mil pontos de dados por segundo, uso de RAM: 2,5 GB; Uso de espaço em disco: 84 GB.
TimescaleDB mostra uso de RAM excepcionalmente baixo e estável em 2,5 GB – o mesmo que para as métricas exclusivas de 4M e 400K.
VictoriaMetrics aumentou lentamente a uma taxa de 100 mil pontos de dados por segundo até que todos os 40 milhões de nomes de métricas marcadas fossem processados. Ele então alcançou uma taxa de inserção sustentada de 1,5-2,0 milhões de pontos de dados por segundo, de modo que o resultado final foi de 1,7 milhões de pontos de dados por segundo.
Os gráficos para séries temporais únicas de 40 milhões são semelhantes aos gráficos para séries temporais únicas de 4 milhões, então vamos ignorá-los.
Descobertas
- Os TSDBs modernos são capazes de processar inserções para milhões de séries temporais exclusivas em um único servidor. No próximo artigo, testaremos o desempenho dos TSDBs na seleção em milhões de séries temporais exclusivas.
- A utilização insuficiente da CPU geralmente indica um gargalo de E/S. Também pode indicar que o bloqueio é muito grosseiro, com apenas alguns threads capazes de serem executados por vez.
- O gargalo de E/S existe, especialmente em armazenamento não SSD, como dispositivos de bloco virtualizados de provedores de nuvem.
- VictoriaMetrics fornece a melhor otimização para armazenamento de E/S lento e baixo. Ele fornece a melhor velocidade e a melhor taxa de compressão.
Baixar e experimente com seus dados. O binário estático correspondente está disponível em .
Leia mais sobre VictoriaMetrics neste .
Atualização: publicada com resultados reproduzíveis.
Atualização nº 2: Leia também .
Atualização nº 3: !
Bate-papo por telegrama:
Fonte: habr.com