En los últimos años, las bases de datos de series temporales han pasado de ser algo extravagante (altamente especializado, utilizado en sistemas de monitoreo abiertos (y vinculados a soluciones específicas) o en proyectos de Big Data) a un “producto de consumo”. En el territorio de la Federación de Rusia, debemos agradecer especialmente a Yandex y ClickHouse por esto. Hasta este punto, si necesitaba almacenar una gran cantidad de datos de series temporales, tenía que aceptar la necesidad de construir una monstruosa pila de Hadoop y mantenerla, o comunicarse con protocolos individuales para cada sistema.
Puede parecer que en 2019 un artículo sobre qué TSDB vale la pena usar consistirá en una sola frase: "solo usa ClickHouse". Pero... hay matices.
De hecho, ClickHouse se está desarrollando activamente, la base de usuarios está creciendo y el soporte es muy activo, pero ¿nos hemos convertido en rehenes del éxito público de ClickHouse, que ha eclipsado otras soluciones, quizás más efectivas y confiables?
A principios del año pasado empezamos a reelaborar nuestro propio sistema de seguimiento, durante lo cual surgió la cuestión de elegir una base de datos adecuada para almacenar datos. Quiero hablar aquí sobre la historia de esta elección.
Formulación del problema
Ante todo, un prefacio necesario. ¿Por qué necesitamos nuestro propio sistema de seguimiento y cómo se diseñó?
Comenzamos a brindar servicios de soporte en 2008, y en 2010 quedó claro que se volvió difícil agregar datos sobre los procesos que ocurren en la infraestructura del cliente con las soluciones que existían en ese momento (estamos hablando de, Dios me perdone, Cacti, Zabbix y el emergente Graphite).
Nuestros principales requisitos fueron:
- soporte (en ese momento - docenas, y en el futuro - cientos) de clientes dentro de un sistema y al mismo tiempo la presencia de un sistema de gestión de alertas centralizado;
- flexibilidad en la gestión del sistema de alerta (escalamiento de alertas entre oficiales de servicio, programación, base de conocimientos);
- la capacidad de detallar profundamente los gráficos (Zabbix en ese momento representaba gráficos en forma de imágenes);
- almacenamiento a largo plazo de una gran cantidad de datos (un año o más) y la capacidad de recuperarlos rápidamente.
En este artículo nos interesa el último punto.
Hablando de almacenamiento, los requisitos eran los siguientes:
- el sistema debe funcionar rápidamente;
- es deseable que el sistema tenga una interfaz SQL;
- el sistema debe ser estable y tener una base de usuarios activa y soporte (una vez nos enfrentamos a la necesidad de soportar sistemas como MemcacheDB, que ya no se desarrolló, o el almacenamiento distribuido MooseFS, cuyo rastreador de errores se mantuvo en chino: repetimos esta historia porque nuestro proyecto no quería);
- cumplimiento del teorema de CAP: Consistencia (obligatorio): los datos deben estar actualizados, no queremos que el sistema de gestión de alertas no reciba nuevos datos y emita alertas sobre la no llegada de datos para todos los proyectos; Tolerancia de partición (obligatoria): no queremos tener un sistema de cerebro dividido; Disponibilidad (no crítica, si hay una réplica activa): podemos cambiar nosotros mismos al sistema de respaldo en caso de un accidente, usando código.
Curiosamente, en aquel momento MySQL resultó ser la solución ideal para nosotros. Nuestra estructura de datos era extremadamente simple: identificación del servidor, identificación del contador, marca de tiempo y valor; Un gran grupo de buffer garantizó un muestreo rápido de datos calientes, y un SSD garantizó el muestreo de datos históricos.
Por lo tanto, logramos una muestra de datos nuevos de dos semanas, con detalles de hasta un segundo 200 ms antes de que los datos se renderizaran por completo, y vivimos en este sistema durante bastante tiempo.
Mientras tanto, pasó el tiempo y la cantidad de datos creció. En 2016, los volúmenes de datos alcanzaron decenas de terabytes, lo que supuso un gasto importante en el contexto del almacenamiento SSD alquilado.
En ese momento, las bases de datos en columnas se habían generalizado activamente, en lo que comenzamos a pensar activamente: en las bases de datos en columnas, los datos se almacenan, como puede comprender, en columnas, y si observa nuestros datos, es fácil ver una gran cantidad. número de duplicados que podrían, en Si usa una base de datos en columnas, comprimirla usando compresión.
Sin embargo, el sistema clave de la empresa seguía funcionando de forma estable y no quería experimentar cambiando a otra cosa.
En 2017, en la conferencia Percona Live en San José, los desarrolladores de Clickhouse probablemente se anunciaron por primera vez. A primera vista, el sistema estaba listo para producción (bueno, Yandex.Metrica es un sistema de producción severo), el soporte fue rápido y simple y, lo más importante, la operación fue simple. Desde 2018 iniciamos el proceso de transición. Pero en ese momento había muchos sistemas TSDB "adultos" y probados en el tiempo, y decidimos dedicar mucho tiempo y comparar alternativas para asegurarnos de que no hubiera soluciones alternativas a Clickhouse, de acuerdo con nuestros requisitos.
Además de los requisitos de almacenamiento ya especificados, han aparecido otros nuevos:
- el nuevo sistema debería proporcionar al menos el mismo rendimiento que MySQL con la misma cantidad de hardware;
- el almacenamiento del nuevo sistema debería ocupar mucho menos espacio;
- El DBMS debe seguir siendo fácil de gestionar;
- Quería cambiar la aplicación mínimamente al cambiar el DBMS.
¿Qué sistemas empezamos a considerar?
Colmena Apache/Apache Impala
Una pila de Hadoop antigua y probada en batalla. Esencialmente, es una interfaz SQL construida además del almacenamiento de datos en formatos nativos en HDFS.
Pros.
- Con un funcionamiento estable, es muy fácil escalar datos.
- Existen soluciones de columnas para el almacenamiento de datos (menos espacio).
- Ejecución muy rápida de tareas paralelas cuando hay recursos disponibles.
Contras
- Es Hadoop y es difícil de usar. Si no estamos listos para adoptar una solución lista para usar en la nube (y no estamos listos en términos de costo), toda la pila tendrá que ser ensamblada y respaldada por los administradores, y realmente no queremos este.
- Los datos se agregan. .
Sin embargo:
La velocidad se logra escalando la cantidad de servidores informáticos. En pocas palabras, si somos una gran empresa que se dedica a la analítica y es fundamental para la empresa agregar información lo más rápido posible (incluso a costa de utilizar una gran cantidad de recursos informáticos), esta puede ser nuestra elección. Pero no estábamos preparados para multiplicar el parque de hardware para acelerar las tareas.
Druida/Pinot
Hay mucho más sobre TSDB específicamente, pero nuevamente, la pila de Hadoop.
Hay .
En pocas palabras: Druid/Pinot se ven mejor que Clickhouse en los casos en que:
- Tiene una naturaleza heterogénea de datos (en nuestro caso, solo registramos series temporales de métricas del servidor y, de hecho, esta es una tabla. Pero puede haber otros casos: series temporales de equipos, series temporales económicas, etc., cada una con su propia estructura, que deben ser agregadas y procesadas).
- Además, hay muchos de estos datos.
- Las tablas y datos con series de tiempo aparecen y desaparecen (es decir, algún conjunto de datos llegó, fue analizado y eliminado).
- No existe un criterio claro según el cual se puedan dividir los datos.
En casos opuestos, ClickHouse funciona mejor, y este es nuestro caso.
casa de clics
- tipo SQL
- Fácil de gestionar.
- La gente dice que funciona.
Es preseleccionado para las pruebas.
Influjo DB
Una alternativa extranjera a ClickHouse. De las desventajas: la alta disponibilidad solo está presente en la versión comercial, pero es necesario compararla.
Es preseleccionado para las pruebas.
Cassandra
Por un lado, sabemos que se utiliza para almacenar series temporales métricas en sistemas de seguimiento como, por ejemplo, o OkMeter. Sin embargo, hay detalles.
Cassandra no es una base de datos en columnas en el sentido tradicional. Se parece más a una vista de filas, pero cada línea puede tener un número diferente de columnas, lo que facilita la organización de una vista de columnas. En este sentido, está claro que con un límite de 2 mil millones de columnas, es posible almacenar algunos datos en columnas (y la misma serie temporal). Por ejemplo, en MySQL hay un límite de 4096 columnas y es fácil toparse con un error con el código 1117 si intentas hacer lo mismo.
El motor Cassandra se centra en almacenar grandes cantidades de datos en un sistema distribuido sin un maestro, y el teorema CAP de Cassandra mencionado anteriormente trata más sobre AP, es decir, sobre la disponibilidad de datos y la resistencia a la partición. Por lo tanto, esta herramienta puede ser excelente si solo necesita escribir en esta base de datos y rara vez leer de ella. Y aquí es lógico utilizar Cassandra como almacenamiento "frío". Es decir, como un lugar confiable a largo plazo para almacenar grandes cantidades de datos históricos que rara vez se necesitan, pero que se pueden recuperar si es necesario. Sin embargo, para mayor exhaustividad, también lo probaremos. Pero, como dije antes, no deseamos reescribir activamente el código para la solución de base de datos seleccionada, por lo que la probaremos de forma algo limitada, sin adaptar la estructura de la base de datos a las características específicas de Cassandra.
Prometeo
Bueno, por curiosidad, decidimos probar el rendimiento del almacenamiento Prometheus, sólo para entender si somos más rápidos o más lentos que las soluciones actuales y en qué medida.
Metodología de prueba y resultados.
Entonces, probamos 5 bases de datos en las siguientes 6 configuraciones: ClickHouse (1 nodo), ClickHouse (tabla distribuida para 3 nodos), InfluxDB, Mysql 8, Cassandra (3 nodos) y Prometheus. El plan de prueba es el siguiente:
- subir datos históricos de una semana (840 millones de valores por día; 208 mil métricas);
- generamos una carga de grabación (se consideraron 6 modos de carga, ver más abajo);
- Paralelamente a la grabación, periódicamente realizamos selecciones, emulando las solicitudes de un usuario que trabaja con gráficos. Para no complicar demasiado las cosas, seleccionamos datos para 10 métricas (esa es exactamente la cantidad que hay en el gráfico de la CPU) durante una semana.
Cargamos emulando el comportamiento de nuestro agente de monitoreo, que envía valores a cada métrica una vez cada 15 segundos. Al mismo tiempo nos interesa variar:
- el número total de métricas en las que se escriben los datos;
- intervalo para enviar valores a una métrica;
- tamaño del lote.
Sobre el tamaño del lote. Dado que no se recomienda cargar casi todas nuestras bases de datos experimentales con inserciones individuales, necesitaremos un relé que recopile métricas entrantes, las agrupe en grupos y las escriba en la base de datos como una inserción por lotes.
Además, para comprender mejor cómo interpretar los datos recibidos, imaginemos que no solo enviamos un montón de métricas, sino que las métricas están organizadas en servidores: 125 métricas por servidor. Aquí el servidor es simplemente una entidad virtual; basta con entender que, por ejemplo, 10000 métricas corresponden a unos 80 servidores.
Y aquí, teniendo todo esto en cuenta, están nuestros 6 modos de carga de escritura de base de datos:
Hay dos puntos aquí. En primer lugar, para Cassandra estos tamaños de lote resultaron ser demasiado grandes, allí usamos valores de 50 o 100. Y en segundo lugar, dado que Prometheus funciona estrictamente en modo pull, es decir. él mismo va y recopila datos de fuentes de métricas (e incluso pushgateway, a pesar del nombre, no cambia fundamentalmente la situación), las cargas correspondientes se implementaron utilizando una combinación de configuraciones estáticas.
Los resultados de la prueba son los siguientes:
lo que vale la pena señalar: muestras increíblemente rápidas de Prometheus, muestras terriblemente lentas de Cassandra, muestras inaceptablemente lentas de InfluxDB; En cuanto a velocidad de grabación, ClickHouse ganó a todos, y Prometheus no participa en el concurso, porque él mismo fabrica inserciones y no medimos nada.
Como resultado,: ClickHouse e InfluxDB demostraron ser los mejores, pero un clúster de Influx solo se puede construir sobre la base de la versión Enterprise, que cuesta dinero, mientras que ClickHouse no cuesta nada y se fabrica en Rusia. Es lógico que en Estados Unidos la elección probablemente sea a favor de inInfluxDB, y en nuestro país a favor de ClickHouse.
Fuente: habr.com