Si utiliza una base de datos de series temporales (timeseries db, ) como almacenamento principal para un sitio con estatísticas, entón en lugar de resolver o problema podes ter moitos dores de cabeza. Estou traballando nun proxecto que utiliza esa base de datos e, ás veces, InfluxDB, do que se comentará, presentaba sorpresas completamente inesperadas.
retratação: Os problemas indicados aplícanse á versión 1.7.4 de InfluxDB.
Por que series temporais?
O proxecto consiste en rastrexar as transaccións en varias cadeas de bloques e mostrar estatísticas. En concreto, observamos a emisión e a queima de moedas estables (). En función destas transaccións, cómpre construír gráficos e mostrar táboas de resumo.
Mentres se analizaban as transaccións, xurdiu unha idea: utilizar a base de datos de series temporais InfluxDB como almacenamento principal. As transaccións son puntos no tempo e encaixan ben no modelo de series temporais.
As funcións de agregación tamén parecían moi convenientes, ideais para procesar gráficos cun período longo. O usuario necesita un gráfico durante un ano e a base de datos contén un conxunto de datos cun prazo de cinco minutos. Non ten sentido enviarlle os cen mil puntos: ademais do procesamento longo, nin sequera caberán na pantalla. Podes escribir a túa propia implementación para aumentar o prazo ou usar as funcións de agregación integradas en Influx. Coa súa axuda, pode agrupar os datos por día e enviar os 365 puntos necesarios.
Foi un pouco confuso que tales bases de datos adoitan usarse co propósito de recoller métricas. Monitorización de servidores, dispositivos iot, todo a partir do cal millóns de puntos da forma “fluyen”: [<tempo> - <valor métrico>]. Pero se a base de datos funciona ben cun gran fluxo de datos, entón por que un pequeno volume debería causar problemas? Con isto en mente, levamos a InfluxDB ao traballo.
Que máis é conveniente en InfluxDB
Ademais das mencionadas funcións de agregación, hai outra gran cousa: consultas continuas (). Este é un programador integrado na base de datos que pode procesar datos nunha programación. Por exemplo, cada 24 horas podes agrupar todos os rexistros do día, calcular a media e rexistrar un novo punto noutra táboa sen escribir as túas propias bicicletas.
Tamén hai políticas de retención (): configurar a eliminación de datos despois dun período determinado. É útil cando, por exemplo, precisa almacenar a carga da CPU durante unha semana con medicións unha vez por segundo, pero durante un par de meses non se precisa esa precisión. En tal situación, podes facer isto:
- crear unha consulta continua para agregar datos noutra táboa;
- para a primeira táboa, defina unha política para eliminar métricas que sexan máis antigas que esa mesma semana.
E Influx reducirá de forma independente o tamaño dos datos e eliminará as cousas innecesarias.
Sobre os datos almacenados
Non se almacenan moitos datos: preto de 70 mil transaccións e outro millón de puntos con información de mercado. Engadindo novas entradas - non máis de 3000 puntos por día. Tamén hai métricas para o sitio, pero hai poucos datos alí e, segundo a política de retención, gárdanse non máis dun mes.
Problemas
Durante o desenvolvemento e as probas posteriores do servizo, xurdiron cada vez máis problemas críticos no funcionamento de InfluxDB.
1. Eliminación de datos
Hai unha serie de datos coas transaccións:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Resultado:
Estou enviando un comando para eliminar datos:
DELETE FROM transactions WHERE symbol=’USDT’A continuación fago unha solicitude para recibir os datos xa eliminados. E en lugar dunha resposta baleira, Influx devolve parte dos datos que deberían eliminarse.
Estou tentando eliminar toda a táboa:
DROP MEASUREMENT transactionsComprobo a eliminación da táboa:
SHOW MEASUREMENTSNon vexo a táboa na lista, pero unha nova consulta de datos aínda devolve o mesmo conxunto de transaccións.
O problema só se me ocorreu unha vez, xa que o caso de eliminación era un caso illado. Pero este comportamento da base de datos claramente non encaixa no marco da operación "correcta". Máis tarde atopeino aberto en github hai case un ano sobre este tema.
Como resultado, eliminar e restaurar toda a base de datos axudou.
2. Números de coma flotante
Os cálculos matemáticos cando se usan funcións integradas en InfluxDB teñen erros de precisión. Non é que isto sexa algo inusual, pero é desagradable.
No meu caso, os datos teñen un compoñente financeiro e gustaríame procesalos con gran precisión. Por iso, pensamos abandonar as consultas continuas.
3. As consultas continuas non se poden adaptar a diferentes fusos horarios
O servizo ten unha táboa coas estatísticas de transaccións diarias. Para cada día, debes agrupar todas as transaccións dese día. Pero o día de cada usuario comezará nun momento diferente e, polo tanto, o conxunto de transaccións será diferente. Pola UTC si quendas para as que precisa agregar datos.
En InfluxDB, ao agrupar por hora, tamén podes especificar un cambio, por exemplo para a hora de Moscova (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Pero o resultado da consulta será incorrecto. Por algún motivo, os datos agrupados por día comezarán ata 1677 (InfluxDB admite oficialmente un período de tempo a partir deste ano):
Para solucionar este problema, cambiamos temporalmente o servizo a UTC+0.
4. Rendemento
Hai moitos puntos de referencia en Internet que comparan InfluxDB e outras bases de datos. A primeira vista, parecían materiais de marketing, pero agora creo que hai algo de verdade neles.
Vouche contar o meu caso.
O servizo ofrece un método API que devolve estatísticas do último día. Ao realizar cálculos, o método consulta a base de datos tres veces coas seguintes consultas:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCExplicación
- Na primeira solicitude, obtemos os últimos puntos por cada moeda con datos de mercado. Oito puntos por oito moedas no meu caso.
- A segunda solicitude obtén un dos puntos máis novos.
- O terceiro solicita unha lista de transaccións das últimas XNUMX horas; pode haber varios centos delas.
Permítanme aclarar que InfluxDB constrúe automaticamente un índice baseado en etiquetas e tempo, o que acelera as consultas. Na primeira solicitude símbolo é unha etiqueta.
Fixen unha proba de esforzo neste método API. Para 25 RPS, o servidor demostrou unha carga completa de seis CPUs:
Ao mesmo tempo, o proceso NodeJs non proporcionou ningunha carga.
A velocidade de execución xa se deteriorou en 7-10 RPS: se un cliente podía recibir unha resposta en 200 ms, entón 10 clientes tiñan que esperar un segundo. 25 RPS é o límite no que sufriu a estabilidade; devolvéronse 500 erros aos clientes.
Con tal rendemento é imposible usar Influx no noso proxecto. Ademais: nun proxecto no que se debe demostrar a monitorización a moitos clientes, poden aparecer problemas similares e o servidor de métricas sobrecargarase.
Saída
A conclusión máis importante da experiencia adquirida é que non se pode incorporar unha tecnoloxía descoñecida a un proxecto sen unha análise suficiente. Unha simple selección de problemas abertos en github podería proporcionar información para evitar escoller InfluxDB como o principal almacén de datos.
InfluxDB debería ser un bo axuste para as tarefas do meu proxecto, pero como a práctica demostrou, esta base de datos non satisface as necesidades e ten moitos erros.
Xa podes atopar a versión 2.0.0-beta no repositorio do proxecto; só podemos esperar que a segunda versión teña melloras significativas. Mentres tanto, vou estudar a documentación de TimescaleDB.
Fonte: www.habr.com