El volumen de la curva de tiempo de Didi aumentó decenas de veces entre 2017 y 2023. Nos adaptamos y mejoramos constantemente durante todo el proceso para afrontar este crecimiento. Por ejemplo, la selección de bases de datos de series temporales ha evolucionado desde el InfluxDB inicial hasta RRDtool, pasando por el desarrollo de TSDB en memoria para compartir la presión de las consultas y luego hasta VictoriaMetrics en 2020. La aerolínea también ha pasado del modelo físico más equipado de la compañía al actual despliegue de contenedores completos. Pasó por muchos pensamientos y decisiones. A continuación le contaremos esta serie de historias en orden cronológico.
La era InfluxDB en 2017
InfluxDB, el hermano mayor de la base de datos de series temporales, fue nuestra elección inicial de base de datos de series temporales. Sin embargo, a medida que aumenta el tamaño de la curva de tiempo, las limitaciones de InfluxDB comienzan a quedar expuestas. Al mismo tiempo, hay cada vez más debates sobre InfluxDB OOM en la comunidad. La razón fundamental radica en las escrituras y consultas en caliente. Imagine que una consulta que alcanza millones de curvas cae en una instancia de InfluxDB. OOM es casi inevitable. También puede buscar OOM en la comunidad InfluxDB, y hay más de 400 resultados para "InfluxDB OOM".
A medida que estos problemas se vuelven cada vez más prominentes, tenemos que repensar la selección de bases de datos de series temporales. La siguiente imagen muestra el rendimiento de la función de visualización de gráficos del sistema observable en ese momento después de que Influxdb fallara:
InfluxDB OOM, rendimiento de la función de visualización de imágenes
2017～2018 Era Open-Falcon
InfluxDB tiene un rendimiento independiente limitado y la solución de clúster no está abierta. Aunque hemos dividido InfluxDB según líneas de negocio, todavía nos enfrentamos a una situación en la que el volumen de la curva de un solo nodo de servicio es enorme, lo que es difícil de manejar para InfluxDB.
Después de una exploración en profundidad y múltiples experimentos, decidimos adoptar la solución de almacenamiento RRDtool utilizada por Open-Falcon. Usamos el mismo algoritmo hash consistente en los enlaces de almacenamiento y consulta para dividir las curvas en diferentes instancias para resolver el problema. Resuelve el problema de OOM causado por puntos calientes demasiado altos en la era InfluxDB.
2018～2020 Era post-Open-Falcon
Hasta abril de 2018, la solución RRDtool se ejecutaba en Didi. Pero a medida que el volumen de las curvas aumenta rápidamente, nos enfrentamos a un nuevo problema: el coste. El costo es una cuestión que casi todas las empresas de Internet no pueden evitar cuando alcanzan una determinada etapa de desarrollo. Especialmente como plataforma observable para productos sin fines de lucro, la cuestión de los costos es particularmente prominente. Incluso en los tres años transcurridos desde 2017, aunque el uso de la memoria de nuestro clúster de almacenamiento ha alcanzado más del 90 %, todavía no hemos podido obtener soporte para máquinas nuevas. Una de las razones fue que la configuración de la máquina que necesitábamos era demasiado alta. Incluso el modelo de gama alta equipado con discos NVMe en ese momento tenía una tasa de utilización de IO de más del 90%. El Comité de Presupuesto no estaba del todo convencido de que un servicio pudiera tener demandas tan altas de CPU, memoria e IO al mismo tiempo.
Ante este dilema, nos encontramos atrapados en un dilema. Por un lado, existe una presión constante por parte de los usuarios y, por otro, no se pueden cumplir los requisitos de los modelos necesarios para el almacenamiento.
Después de un período de reflexión e investigación, descubrimos que más del 80% de las solicitudes de consulta se concentraron en las últimas 2 horas. Por lo tanto, intentamos dividir el almacenamiento en frío y en caliente y crear un nuevo servicio para compartir la presión del almacenamiento. Fue en ese momento que conocimos el documento de Facebook Gorilla y surgió un servicio llamado Cacheserver.
El diseño de Cacheserver está inspirado en el documento Gorilla de Facebook y tiene como objetivo compartir solicitudes con el servicio de almacenamiento original y solo apunta a solicitudes de consulta para las últimas 2 horas de datos, lo que reduce en gran medida la presión sobre el clúster de servicios RRDtool. Esta arquitectura en niveles frío y caliente no solo alivia los problemas de costos de almacenamiento, sino que también mejora el rendimiento general y la eficiencia de las consultas.
Arquitectura del servidor de caché
2020 ~ La era VictoriaMetrics actual
Con la llegada de la era de los contenedores Didi, nos enfrentamos a una situación más difícil.
Primero, a medida que la cobertura de contenedores continúa mejorando, la cantidad de curvas de tiempo aumenta enormemente. En 2020, a medida que la cobertura de contenedores siga aumentando, se espera que el crecimiento de la curva supere el 100%.
Además, la presión de los costes sigue aumentando. Aunque la arquitectura de RRDtool se puede escalar horizontalmente, el costo de la observabilidad en sí ya no puede aumentar linealmente con el crecimiento empresarial.
La arquitectura actual de RRDtool tiene una gran demanda y un bajo rendimiento, y debe utilizar modelos SSD/NVMe. Si se utilizan discos normales, se colgarán directamente cuando se caiga el disco. Además, solo admite algunas funciones limitadas, como suma, promedio, máximo y mínimo, que no pueden satisfacer las necesidades cada vez más ricas de los usuarios.
Para ahorrar espacio de almacenamiento, en ese momento solo se conservaron 2 horas de datos originales. Los usuarios necesitan más tiempo (por ejemplo, 15 días) para ver y analizar datos sin procesar, sin embargo, cambiar la estrategia de reducción de minería traerá dos problemas: primero, la modificación de reducción de minería de RRDtool hará que se pierdan todos los datos. En segundo lugar, almacenar 15 días de puntos originales aumentará el espacio de almacenamiento de cada curva en 8,5 veces (120 KB → 1 MB).
Por eso, desde principios de 2020, comenzamos a investigar nuevas soluciones. Se necesita una arquitectura de almacenamiento más eficiente y flexible para hacer frente a los problemas anteriores.
¿Cuáles son las alternativas?
Al seleccionar una nueva solución de almacenamiento, consideramos varias alternativas, entre ellas:
druida
Prometeo
Thanos/Cortex
M3
VictoriaMétricas
¿Druida?
Druid es la solución de almacenamiento de series temporales de Woater, otro sistema de Didi, y es operado y mantenido por el equipo de big data. Sin embargo, finalmente no consideramos a Druid por las siguientes razones:
El modelo no es satisfactorio: el modelo de almacenamiento de Woater es un esquema predefinido (Dimensiones), y lo que necesitamos es un esquema dinámico, que no es compatible de forma nativa con Druid. Aunque el equipo de big data dijo que puede desarrollar soporte, existen muchas restricciones.
Problema de costos: almacenar datos existentes en Druid costará 10 veces más.
Problemas de rendimiento: el rendimiento de escritura de Druid no es tan bueno como el de RRDtool y su capacidad de escritura es deficiente porque Druid necesita realizar un resumen, mientras que RRDtool agrega datos directamente.
Rollup "inútil": la función destacada de Druid, Rollup, no es aplicable a nuestro escenario porque la mayoría de las consultas son para valores originales en lugar de resultados de Rollup.
¿Prometeo?
Prometheus es el estándar de facto en el campo observable, y su modelo de almacenamiento, DSL y su ecosistema han atraído la atención de muchos usuarios y empresas. Pero en el escenario de Didi, no elegimos Prometheus, las razones principales son:
Sin almacenamiento a largo plazo: Prometheus se centra principalmente en el almacenamiento y la consulta de datos a corto plazo, y necesitamos retención a largo plazo.
Sin solución de clúster: Prometheus no tiene una solución de clúster incorporada y, para lograr la expansión horizontal, necesita depender de arquitecturas de terceros como Thanos, Cortex, etc., lo que sin duda aumenta la complejidad.
Sin capacidades de alta disponibilidad.
Aunque la comunidad ha brindado algunas soluciones a estos problemas, dado el tamaño de Didi, estas soluciones no pueden satisfacer nuestras necesidades de producción.
Thanos, ¿corteza?
Se puede decir que Thanos y Cortex son las únicas soluciones de agrupación y almacenamiento a largo plazo para Prometheus en ese momento. Sus objetivos de diseño son resolver los siguientes problemas:
Vista global: se pueden realizar consultas en múltiples instancias de Prometheus para lograr una vista global.
Almacenamiento a largo plazo: implemente el almacenamiento a largo plazo para satisfacer las necesidades de análisis y revisión a largo plazo.
Alta disponibilidad.
Estas características hacen de Thanos y Cortex adiciones importantes al ecosistema de Prometheus.
Arquitectura Thanos
Arquitectura de corteza
Pero Thanos/Cortex también tiene algunos problemas:
La estructura de almacenamiento de Cortex todavía se estaba explorando internamente y aún no era lo suficientemente estable. Los bloques todavía estaban en estado experimental en ese momento.
Tanto Thanos como Cortex necesitan introducir el almacenamiento de objetos, lo que puede generar algunos costos de gestión adicionales y plantear interrogantes en términos de rendimiento.
Thanos Remote Read tiene demasiada memoria sobrecargada. Por ejemplo, alguien planteó la siguiente pregunta:
Problemas de memoria de Thanos
Falta de bautismo en un entorno de producción a gran escala: Thanos y Cortex, estas dos soluciones aparentemente hermosas, tienen sus defectos. También hay una falta de verificación real en entornos de producción a gran escala, y la confiabilidad y estabilidad pueden requerir más verificación y optimización.
¿Uber M3?
M3 es la solución TSDB de código abierto de Uber. Aunque tiene algunas ventajas, también tiene algunas desventajas, incluidos los altos costos de administración (como la introducción de etcd) y ninguna ventaja en los costos de la máquina (aún se requieren SSD de alta gama).
arquitectura m3
VictoriaMétricas？
Arquitectura Victoriamétrica
VictoriaMetrics es una base de datos de series temporales de alto rendimiento, bajos requerimientos de recursos y bajos costos de operación y mantenimiento, sus principales características y principios incluyen:
Bajos requisitos de recursos: VictoriaMetrics puede ejecutarse en modelos normales y no requiere el uso de hardware de alto rendimiento como SSD/NVMe.
Modelo de almacenamiento central: basado en LSM, similar a Clickhouse. Almacena los datos en la memoria y los vacía en el directorio de partición del disco cada segundo. Las particiones más pequeñas se fusionan gradualmente en particiones más grandes en segundo plano.
Almacenamiento en columnas: VictoriaMetrics utiliza almacenamiento en columnas, lo que hace que el rendimiento de lectura y escritura sea muy alto. Un núcleo de CPU puede escanear 30 millones de puntos/s.
Alta velocidad de escritura: una sola instancia tiene una capacidad de escritura de 760 000 puntos/s (frente a RRDtool 210 ~ 260 000 puntos/s).
Compresión: utilizando una versión mejorada de Gorilla combinada con un algoritmo de compresión general (Facebook zstd), solo requiere un promedio de 1,2 a 1,5 bytes/punto y la relación de compresión alcanza el 13%.
El clúster es fácil de expandir: adopte el diseño Share Nothing. Es conveniente ampliar y contraer la máquina. También puede redirigir automáticamente cuando la máquina está dañada.
Sin reducción de resolución: el diseño sin reducción de resolución permite conservar los datos originales.
Compatible con Prometheus: Compatible con Prometheues en escritura y métodos de escritura. Y mejorado para PromQL (MetricsQL)
Soporte débil para marcas de tiempo desordenadas.
Capacidad calculable: la capacidad de VictoriaMetrics es calculable, lo que nos permite estimar los requisitos de almacenamiento de forma más intuitiva y cómoda.
Planificación de capacidad de VictoriaMetrics
Como se mencionó anteriormente, porque VictoriaMetrics sobresale en términos de rendimiento, compresión, velocidad de consulta y escalabilidad. Después de considerar exhaustivamente todos los aspectos de las necesidades y consideraciones, creemos que VictoriaMetrics es una solución de almacenamiento de datos de series temporales adecuada para nosotros y puede satisfacer nuestras necesidades.
Problemas y soluciones de VictoriaMetrics
Aunque VictoriaMetrics tiene muchas ventajas como solución de base de datos de series de tiempo, también existen algunos problemas potenciales. Aquí hay algunos puntos y un breve resumen de nuestra solución:
Problema de uso de recursos: el uso de espacio en disco es proporcional a la cantidad de puntos de almacenamiento. Cuanto más datos se almacenan y durante más tiempo, más espacio en disco se requiere. Para solucionar este problema, establecemos diferentes períodos de retención para diferentes líneas de negocio.
Sin reducción de resolución: VictoriaMetrics no admite la reducción de resolución de datos, lo que significa que los datos no se agregan ni descartan automáticamente, pero se conservan los datos originales. Esto puede generar mayores requisitos de almacenamiento de datos en algunos escenarios, especialmente cuando se almacenan datos a largo plazo. Sin embargo, debido a la velocidad de consulta de VictoriaMetrics y la alta compresión, este problema no tuvo un impacto significativo en el costo ni en el rendimiento del sistema.
Actividad limitada y no lo suficientemente generalizada: en comparación con otras soluciones de almacenamiento de series temporales convencionales, es posible que VictoriaMetrics no haya estado lo suficientemente activa en ese momento. Sin embargo, a través de una comprensión profunda del código y múltiples comunicaciones con el autor, gradualmente fuimos ganando confianza en la calidad y el rendimiento de VictoriaMetrics.
Diseño VictoriaMetrics de múltiples clústeres
Diseñamos e implementamos una solución multiclúster basada en VictoriaMetrics para mejorar la escalabilidad y disponibilidad del sistema. Por ejemplo, en la figura siguiente, hemos creado varios clústeres en la región 1 para procesar datos de diferentes líneas de negocio respectivamente, lo que aísla la competencia de recursos y el impacto de cada línea de negocio y reduce el dominio de fallas. También puede elegir un mezclador entre varias regiones para leer y fusionar datos entre regiones.
Diseño de múltiples clústeres de VictoriaMetrics
fin
Lo anterior presenta la historia de desarrollo de la solución de almacenamiento de tiempo observable de Didi. Espero que a través de este intercambio podamos brindar experiencia útil e inspiración a otros equipos y desarrolladores. Damos la bienvenida a los intercambios y discusiones juntos.
Debido a la extensión limitada del artículo, es imposible ampliarlo más aquí. Por ejemplo, implementación en contenedores, gestión de fallas, replicación, migración de datos, etc. de VictoriaMetrics. Estos contenidos se le presentarán en artículos posteriores, ¡así que estad atentos!
Charla nocturna nativa de la nube
Hablemos de cómo su empresa almacena datos observables y cómo responde a una gran cantidad de solicitudes de consulta. Si necesita comunicarse más con nosotros, también puede enviar un mensaje privado directamente al backend.
El autor seleccionará uno de los mensajes más significativos y regalará un vale de taxi Didi de 200 yuanes, deseándole un viaje sin preocupaciones el 1 de noviembre. La lotería se sorteará el 28 de septiembre a las 21:00 horas.