Raiva, barganha e depressão ao trabalhar com InfluxDB

Se você usar um banco de dados de série temporal (timeseries db, wiki) como armazenamento principal de um site com estatísticas, então em vez de resolver o problema você pode ter muitas dores de cabeça. Estou trabalhando em um projeto que usa esse banco de dados e, às vezes, o InfluxDB, que será discutido, apresenta surpresas completamente inesperadas.

Aviso Legal: os problemas listados se aplicam ao InfluxDB versão 1.7.4.

Por que séries temporais?

O projeto consiste em rastrear transações em vários blockchains e exibir estatísticas. Especificamente, analisamos a emissão e queima de moedas estáveis ​​(wiki). Com base nessas transações, você precisa construir gráficos e mostrar tabelas resumidas.

Ao analisar as transações, surgiu uma ideia: usar o banco de dados de série temporal InfluxDB como armazenamento principal. As transações são pontuais e se ajustam bem ao modelo de série temporal.

As funções de agregação também pareciam muito convenientes - ideais para processar gráficos de longo período. O usuário precisa de um gráfico para um ano e o banco de dados contém um conjunto de dados com intervalo de tempo de cinco minutos. Não faz sentido enviar a ele todos os cem mil pontos - além do longo processamento, eles nem cabem na tela. Você pode escrever sua própria implementação para aumentar o prazo ou usar as funções de agregação incorporadas ao Influx. Com a ajuda deles, você pode agrupar os dados por dia e enviar os 365 pontos necessários.

Foi um pouco confuso que esses bancos de dados geralmente sejam usados ​​para coletar métricas. Monitoramento de servidores, dispositivos iot, tudo a partir do qual milhões de pontos na forma de “fluxo”: [<tempo> - <valor métrico>]. Mas se o banco de dados funciona bem com um grande fluxo de dados, então por que um volume pequeno deveria causar problemas? Pensando nisso, colocamos o InfluxDB para funcionar.

O que mais é conveniente no InfluxDB

Além das funções de agregação mencionadas, há outra grande coisa - consultas contínuas (doca). Este é um agendador integrado ao banco de dados que pode processar dados de acordo com uma programação. Por exemplo, a cada 24 horas você pode agrupar todos os registros do dia, calcular a média e registrar um novo ponto em outra tabela sem precisar escrever suas próprias bicicletas.

Há também um está políticas de retenção (doca) — configurando a exclusão de dados após um determinado período. É útil quando, por exemplo, você precisa armazenar a carga da CPU por uma semana com medições uma vez por segundo, mas em alguns meses essa precisão não é necessária. Em tal situação, você pode fazer o seguinte:

1. crie uma consulta contínua para agregar dados em outra tabela;
2. para a primeira tabela, defina uma política para excluir métricas anteriores à mesma semana.

E o Influx reduzirá de forma independente o tamanho dos dados e excluirá coisas desnecessárias.

Sobre dados armazenados

Não são armazenados muitos dados: cerca de 70 mil transações e mais um milhão de pontos com informações de mercado. Adicionando novas entradas - não mais que 3000 pontos por dia. Também existem métricas para o site, mas há poucos dados e, de acordo com a política de retenção, eles ficam armazenados por no máximo um mês.

Problemas

Durante o desenvolvimento e posterior teste do serviço, surgiram cada vez mais problemas críticos na operação do InfluxDB.

1. Excluindo dados

Há uma série de dados com transações:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

Resultado:

Estou enviando um comando para excluir dados:

DELETE FROM transactions WHERE symbol=’USDT’

Em seguida faço uma solicitação para receber os dados já excluídos. E em vez de uma resposta vazia, o Influx retorna parte dos dados que deveriam ser excluídos.

Estou tentando excluir a tabela inteira:

DROP MEASUREMENT transactions

Eu verifico a exclusão da tabela:

SHOW MEASUREMENTS

Não vejo a tabela na lista, mas uma nova consulta de dados ainda retorna o mesmo conjunto de transações.

O problema só me ocorreu uma vez, pois o caso de exclusão foi um caso isolado. Mas este comportamento do banco de dados claramente não se enquadra na estrutura de operação “correta”. Mais tarde encontrei-o aberto no github bilhete há quase um ano sobre este assunto.

Como resultado, excluir e restaurar todo o banco de dados ajudou.

2. Números de ponto flutuante

Os cálculos matemáticos ao usar funções integradas no InfluxDB apresentam erros de precisão. Não que isso seja algo incomum, mas é desagradável.

No meu caso, os dados têm uma componente financeira e gostaria de os processar com elevada precisão. Por causa disso, planejamos abandonar as consultas contínuas.

3. Consultas contínuas não podem ser adaptadas a diferentes fusos horários

O serviço possui uma tabela com estatísticas diárias de transações. Para cada dia, você precisa agrupar todas as transações daquele dia. Mas o dia de cada usuário começará em um horário diferente e, portanto, o conjunto de transações será diferente. Por UTC sim 37 variantes turnos para os quais você precisa agregar dados.

No InfluxDB, ao agrupar por horário, você também pode especificar um turno, por exemplo, para o horário de Moscou (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

Mas o resultado da consulta estará incorreto. Por alguma razão, os dados agrupados por dia começarão até 1677 (o InfluxDB suporta oficialmente um intervalo de tempo a partir deste ano):

Para contornar esse problema, mudamos temporariamente o serviço para UTC+0.

4. Desempenho

Existem muitos benchmarks na Internet que comparam o InfluxDB e outros bancos de dados. À primeira vista, pareciam materiais de marketing, mas agora acho que há alguma verdade neles.

Vou te contar meu caso.

O serviço fornece um método API que retorna estatísticas do último dia. Ao realizar cálculos, o método consulta o banco de dados três vezes com as seguintes consultas:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

Explicação:

1. Na primeira solicitação, obtemos os últimos pontos de cada moeda com dados de mercado. Oito pontos por oito moedas no meu caso.
2. A segunda solicitação obtém um dos pontos mais recentes.
3. O terceiro solicita uma lista de transações das últimas XNUMX horas; pode haver várias centenas delas.

Deixe-me esclarecer que o InfluxDB cria automaticamente um índice baseado em tags e tempo, o que acelera as consultas. No primeiro pedido símbolo é uma etiqueta.

Executei um teste de estresse neste método de API. Para 25 RPS, o servidor demonstrou uma carga completa de seis CPUs:

Ao mesmo tempo, o processo NodeJs não forneceu nenhuma carga.

A velocidade de execução já foi degradada em 7 a 10 RPS: se um cliente pudesse receber uma resposta em 200 ms, 10 clientes teriam que esperar um segundo. 25 RPS é o limite em que a estabilidade foi prejudicada; 500 erros foram retornados aos clientes.

Com esse desempenho é impossível utilizar o Influx em nosso projeto. Além disso: em um projeto onde o monitoramento precisa ser demonstrado para muitos clientes, problemas semelhantes podem surgir e o servidor de métricas ficará sobrecarregado.

Jogar aviator online grátis: hack aviator funciona

A conclusão mais importante da experiência adquirida é que não é possível incorporar uma tecnologia desconhecida em um projeto sem uma análise suficiente. Uma simples triagem de questões abertas no github poderia fornecer informações para evitar a escolha do InfluxDB como principal armazenamento de dados.

O InfluxDB deveria ser uma boa opção para as tarefas do meu projeto, mas como a prática tem mostrado, esse banco de dados não atende às necessidades e tem muitos bugs.

Você já pode encontrar a versão 2.0.0-beta no repositório do projeto; só podemos esperar que a segunda versão tenha melhorias significativas. Enquanto isso, estudarei a documentação do TimescaleDB.

Fonte: habr.com