database - data - prometheus vs elk
Casos de uso: InfluxDB vs. Prometheus (4)
InfluxDB CEO y desarrollador aquí. La próxima versión de InfluxDB (0.9.5) tendrá nuestro nuevo motor de almacenamiento. Con ese motor podremos almacenar eficientemente datos de eventos únicos o series muestreadas regularmente. es decir, series temporales irregulares y regulares.
InfluxDB admite los tipos de datos int64, float64, bool y string utilizando diferentes esquemas de compresión para cada uno. Prometheus solo admite float64.
Para la compresión, la versión 0.9.5 tendrá compresión competitiva con Prometheus. En algunos casos, veremos mejores resultados, ya que variamos la compresión en las marcas de tiempo según lo que vemos. El mejor escenario es una serie regular muestreada a intervalos exactos. En aquellos, por defecto, podemos comprimir marcas de tiempo de 1k puntos como un tiempo de inicio de 8 bytes, un delta (codificado en zig-zag) y un conteo (también codificado en zig-zag).
Dependiendo de la forma de los datos, hemos visto <2.5 bytes por punto en promedio después de las compactaciones.
YMMV basado en sus marcas de tiempo, el tipo de datos y la forma de los datos. Los flotadores aleatorios con marcas de tiempo en escala de nanosegundos con grandes deltas variables serían los peores, por ejemplo.
La precisión variable en las marcas de tiempo es otra característica que tiene InfluxDB. Puede representar tiempos de escala de segundo, milisegundo, microsegundo o nanosegundo. Prometeo se fija en milisegundos.
Otra diferencia es que las escrituras en InfluxDB son duraderas después de que se envía una respuesta de éxito al cliente. Las memorias intermedias de Prometheus escriben en la memoria y, por defecto, las limpian cada 5 minutos, lo que abre una ventana de pérdida potencial de datos.
Nuestra esperanza es que una vez que se lance 0.9.5 de InfluxDB, será una buena opción para los usuarios de Prometheus usar como almacenamiento de métricas a largo plazo (en conjunto con Prometheus). Estoy bastante seguro de que el soporte ya está en Prometheus, pero hasta que la versión 0.9.5 caiga, podría ser un poco difícil. Obviamente tendremos que trabajar juntos y hacer un montón de pruebas, pero eso es lo que espero.
Para la ingesta de métricas de servidor único, esperaría que Prometheus tenga un mejor rendimiento (aunque no hemos realizado pruebas aquí y no tenemos números) debido a su modelo de datos más restringido y porque no agregan escrituras al disco antes de escribir el índice .
El lenguaje de consulta entre los dos es muy diferente. No estoy seguro de lo que respaldan que todavía no tenemos o viceversa, por lo que necesitaría investigar los documentos en ambos para ver si hay algo que uno pueda hacer que necesite. A largo plazo, nuestro objetivo es que la funcionalidad de consulta de InfluxDB sea un superconjunto de grafito, RRD, Prometheus y otras soluciones de series temporales. Digo superconjunto porque queremos cubrirlos además de más funciones analíticas más adelante. Obviamente nos llevará tiempo llegar allí.
Finalmente, un objetivo a largo plazo para InfluxDB es admitir alta disponibilidad y escalabilidad horizontal a través de la agrupación. La implementación actual de agrupación aún no está completa y solo está en alfa. Sin embargo, estamos trabajando en ello y es un objetivo central de diseño para el proyecto. Nuestro diseño de agrupamiento es que los datos eventualmente son consistentes.
Que yo sepa, el enfoque de Prometheus es utilizar escrituras dobles para HA (por lo que no existe una garantía de coherencia eventual) y utilizar la federación para la escalabilidad horizontal. No estoy seguro de cómo funcionarían las consultas en servidores federados.
Dentro de un clúster InfluxDB, puede consultar a través de los límites del servidor sin copiar todos los datos a través de la red. Esto se debe a que cada consulta se descompone en una especie de trabajo MapReduce que se ejecuta sobre la marcha.
Probablemente haya más, pero eso es lo que puedo pensar en este momento.
Siguiendo la página web de Prometheus, una diferencia principal entre Prometheus e InfluxDB es el caso de uso: mientras Prometheus almacena series temporales, solo InfluxDB está mejor orientado a almacenar eventos individuales. Dado que se realizó un trabajo importante en el motor de almacenamiento de InfluxDB, me pregunto si esto sigue siendo cierto.
Quiero configurar una base de datos de series de tiempo y, aparte del modelo push / push (y probablemente una diferencia en el rendimiento), no veo nada importante que separe ambos proyectos. ¿Alguien puede explicar la diferencia en los casos de uso?
InfluxDB simplemente no puede mantener la carga de producción (métricas) de 1000 servidores. Tiene algunos problemas reales con la ingestión de datos y termina estancado / colgado e inutilizable. Intentamos usarlo por un tiempo, pero una vez que la cantidad de datos alcanzó un nivel crítico, ya no se pudo usar. No hay actualizaciones de memoria o CPU ayudadas. Por lo tanto, nuestra experiencia es definitivamente evitarlo, no es un producto maduro y tiene serios problemas de diseño arquitectónico. Y ni siquiera estoy hablando de un cambio repentino a comercial por Influx.
Luego investigamos Prometheus y, aunque requería reescribir consultas, ahora ingiere 4 veces más métricas sin ningún problema en comparación con lo que intentamos alimentar a Influx. Y toda esa carga es manejada por un solo servidor Prometheus, es rápida, confiable y confiable. Esta es nuestra experiencia con una gran tienda de internet internacional bajo una carga bastante pesada.
La implementación actual de Prometheus del IIRC está diseñada alrededor de todos los ajustes de datos en un solo servidor. Si tiene cantidades gigantescas de datos, es posible que no todos encajen en Prometheus.
Tenemos el mensaje de marketing de las dos compañías en las otras respuestas. Ahora ignorémoslo y volvamos al triste mundo real de las series de datos de tiempo.
Algo de historia
InfluxDB y prometheus se hicieron para reemplazar las herramientas antiguas de la era pasada (RRDtool, grafito).
InfluxDB es una base de datos de series de tiempo. Prometheus es una especie de herramienta de recopilación de métricas y alertas, con un motor de almacenamiento escrito solo para eso. (En realidad, no estoy seguro de que pueda [o deba] reutilizar el motor de almacenamiento para otra cosa)
Limitaciones
Lamentablemente, escribir una base de datos es una tarea muy compleja. La única forma en que ambas herramientas logran enviar algo es mediante la eliminación de todas las características duras relacionadas con la alta disponibilidad y la agrupación.
Para decirlo sin rodeos, es una aplicación única que ejecuta solo un nodo.
Prometheus no tiene el objetivo de admitir la agrupación y la replicación de ningún tipo . La forma oficial de admitir la conmutación por error es " ejecutar 2 nodos y enviar datos a ambos ". Ay. (Tenga en cuenta que es seriamente la ÚNICA forma posible, está escrita innumerables veces en la documentación oficial).
InfluxDB ha estado hablando sobre la agrupación durante años ... hasta que fue oficialmente abandonado en marzo. La agrupación ya no está sobre la mesa para InfluxDB . Solo olvídalo. Cuando se haga (suponiendo que alguna vez lo esté) solo estará disponible en la Edición Enterprise.
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
En los próximos años, con suerte tendremos una base de datos de series temporales bien diseñada que maneje todos los problemas difíciles relacionados con las bases de datos: replicación, conmutación por error, seguridad de datos, escalabilidad, copia de seguridad ...
Por el momento, no hay bala de plata.
Qué hacer
Evaluar el volumen de datos que se espera.
100 métricas * 100 fuentes * 1 segundo => 10000 puntos de datos por segundo => 864 Mega-puntos de datos por día.
Lo bueno de las bases de datos de series de tiempo es que usan un formato compacto, se comprimen bien, agregan puntos de datos y limpian datos antiguos. (Además, vienen con características relevantes para las series de datos de tiempo).
Suponiendo que un punto de datos se trata como 4 bytes, eso es solo unos pocos Gigabytes por día. Por suerte para nosotros, hay sistemas con 10 núcleos y unidades de 10 TB disponibles. Eso probablemente podría ejecutarse en un solo nodo.
La alternativa es utilizar una base de datos NoSQL clásica (Cassandra, ElasticSearch o Riak) y luego diseñar los bits que faltan en la aplicación. Es posible que estas bases de datos no estén optimizadas para ese tipo de almacenamiento (¿o sí? Las bases de datos modernas son tan complejas y optimizadas que no se pueden saber con seguridad a menos que sean comparativas).
Debe evaluar la capacidad requerida por su aplicación . Escriba una prueba de concepto con estas diversas bases de datos y mida cosas.
Vea si cae dentro de las limitaciones de InfluxDB. Si es así, es probablemente la mejor apuesta. Si no, tendrá que hacer su propia solución además de otra cosa.