🧖🏻 👩🏻‍🚀 🚋 Bases de datos en la plataforma IIoT: cómo funciona Mail.ru Cloud Solutions con petabytes de datos de múltiples dispositivos 🕺🏿 🤣 🐴

Hola, soy Andrey Sergeev, jefe del grupo de desarrollo de soluciones de IoT en Mail.ru Cloud Solutions . Se sabe que no existe una base de datos universal. Especialmente cuando necesita construir una plataforma de Internet de las cosas capaz de procesar millones de eventos desde sensores por segundo en modo casi en tiempo real.

Nuestro producto Mail.ru IoT Platform comenzó con un prototipo basado en Tarantool. Te diré en qué dirección fuimos, qué problemas encontramos y cómo los solucionamos. Y también muestran la arquitectura actual de la plataforma moderna de Internet industrial de las cosas. En el artículo hablaremos:

sobre los requisitos de nuestra base de datos, solución universal y teorema CAP;
si la base de datos + servidor de aplicaciones en un enfoque es una bala de plata;
sobre la evolución de la plataforma y las bases de datos utilizadas en ella;
, Tarantool’ .

, @Databases Meetup by Mail.ru Cloud Solutions. , :

Mail.ru IoT Platform

Nuestro producto, Mail.ru IoT Platform, es una plataforma escalable e independiente del hardware para crear soluciones para el Internet industrial de las cosas. Le permite recopilar datos de cientos de miles de dispositivos simultáneamente y procesar esta transmisión en modo casi en tiempo real (es decir, casi en tiempo real), incluido el uso de reglas personalizadas: scripts en Python o Lua.

La plataforma puede almacenar una cantidad ilimitada de datos sin procesar de las fuentes, hay un conjunto de componentes listos para visualizar y analizar datos, herramientas integradas para el análisis predictivo y la creación de aplicaciones basadas en la plataforma.

Así es como se ve el dispositivo Mail.ru IoT Platform.

En este momento, la plataforma está disponible para su instalación de acuerdo con el modelo local en las instalaciones del cliente, este año se planea lanzar la plataforma como un servicio en la nube pública.

Prototipo de Tarantool: cómo comenzó todo

Nuestra plataforma comenzó como un proyecto piloto: un prototipo con una única instancia de Tarantool, cuya función principal era recibir el flujo de datos de un servidor OPC, procesar eventos recibidos utilizando scripts Lua en tiempo real, monitorear indicadores clave basados en ellos y generar eventos y alertas en sistemas superiores

Esquema del prototipo de Tarantool

Este prototipo incluso funcionó en condiciones de combate durante varios meses en un sitio de clúster, es una plataforma para la producción de petróleo en alta mar, en Irak, en el Golfo Pérsico. Supervisó los indicadores clave y proporcionó datos para el sistema de visualización y el registro de eventos. El piloto fue reconocido como exitoso, pero como suele ser el caso con los prototipos: no fue más allá del piloto y el prototipo quedó en espera durante mucho tiempo hasta que cayó en nuestras manos.

Nuestros objetivos en el desarrollo de una plataforma IoT

Junto con el prototipo, obtuvimos la tarea: crear una plataforma IoT completa, escalable y tolerante a fallas, que luego podría lanzarse como un servicio en una nube pública.

Necesitábamos construir una plataforma con la siguiente introducción:

Conecte cientos de miles de dispositivos simultáneamente.
Recibe millones de eventos por segundo.
Procesamiento de flujo en modo casi en tiempo real.
Almacenamiento de datos en bruto durante varios años.
Herramientas para análisis de transmisión y análisis histórico.
Soporte de implementación en múltiples centros de datos para una recuperación máxima ante desastres.

Pros y contras del prototipo de plataforma.

En el momento del inicio del desarrollo activo, el prototipo tenía el siguiente aspecto:

Tarantool, que se utiliza como base de datos + servidor de aplicaciones (Servidor de aplicaciones);
todos los datos se almacenan en la memoria de Tarantool;
una aplicación en Lua en el mismo Tarantool, que realiza las funciones de recibir datos, procesarlos y llamar a los scripts de usuario sobre los datos entrantes.

Este enfoque para crear aplicaciones tiene sus ventajas :

El código y los datos están en un solo lugar, lo que le permite operar con los datos directamente en la memoria de la aplicación y elimina los costos generales de las visitas a la red típicas de las aplicaciones tradicionales.
Tarantool utiliza JIT (Just in Time Compiler) para Lua, que en el momento de la compilación compila el código Lua en código máquina, lo que permite que los scripts simples de Lua se ejecuten a una velocidad comparable al código C (40,000 RPS desde un núcleo, y este no es el límite !).
Tarantool se basa en la multitarea cooperativa, es decir, cada llamada al procedimiento almacenado se lanza en su propia fibra, un análogo de la rutina, lo que da un impulso aún mayor en el rendimiento en tareas con operaciones de E / S, por ejemplo, visitas a la red.
Uso eficiente de los recursos: pocas herramientas pueden manejar 40,000 solicitudes por segundo desde un solo núcleo de CPU.

Pero hay desventajas significativas :

Necesitamos almacenar datos sin procesar de los dispositivos durante varios años, pero no tenemos cientos de petabytes de memoria para Tarantool.
Una consecuencia directa de la primera ventaja: todo el código de nuestra plataforma son procedimientos almacenados en la base de datos, lo que significa que cualquier actualización de la base de código de la plataforma es una actualización de la base de datos, lo cual es muy doloroso.
, . , Tarantool 24-32 (Tarantool ) . — Tarantool, .
. - , Tarantool Lua , - , LuaJIT .

Conclusión: Tarantool es una buena opción para crear MVP, pero no es adecuado para una plataforma IoT completa, escalable, fácilmente compatible y tolerante a fallas que puede recibir, procesar y almacenar datos de cientos de miles de dispositivos.

Los principales dolores del prototipo del que queríamos deshacernos

En primer lugar, queríamos curar dos dolores de nuestro prototipo:

Aléjese del concepto de base de datos + servicio de aplicación. Queríamos actualizar el código de la aplicación independientemente del almacén de datos.
Simplifique la escala dinámica bajo carga. Quería obtener una escala horizontal independiente y fácil de tantas funciones como sea posible.

Para resolver estos problemas, elegimos un enfoque innovador y aún no probado: arquitectura de microservicios y separación de servicios en aplicaciones sin estado (Stateful) y base de datos.

Para facilitar aún más la operación y la escala horizontal de los servicios sin estado, los incluimos en contenedores y adoptamos Kubernetes.

Descubrimos los servicios apátridas, queda por decidir qué hacer con los datos.

Requisitos básicos de la base de datos para la plataforma IoT

Inicialmente, no queríamos cercar el jardín y queríamos almacenar todos los datos de la plataforma en una base de datos universal. Después de analizar los objetivos, llegamos a la siguiente lista de requisitos para una base de datos universal:

ACID- — , .
— .
— , near real-time.
— - .
— , .
— ( !), .
— , ( !).
SQL — .

CAP-

Antes de comenzar a clasificar todas las bases de datos que están en el mercado para cumplir con nuestros requisitos, decidimos validar nuestros requisitos de cordura utilizando una herramienta bastante conocida: teoremas CAP.

El teorema CAP dice que un sistema distribuido puede tener un máximo de dos de las siguientes tres propiedades:

Consistencia (consistencia de datos) : en todos los nodos de computación en un punto en el tiempo, los datos no se contradicen entre sí.
Disponibilidad : cualquier solicitud a un sistema distribuido finaliza con una respuesta correcta, pero sin una garantía de que las respuestas de todos los nodos del sistema coincidan.
Tolerancia de partición : incluso si no hay conexión entre los nodos, continúan funcionando independientemente uno del otro.

Por ejemplo, el sistema CA clásico es un clúster Master-Slave PostgreSQL con replicación sincrónica, y el sistema AP clásico es Cassandra.

Volvamos a nuestros requisitos y clasifíquelos usando el teorema CAP:

Las transacciones ACID y la consistencia estricta (o al menos no consistencia eventual) son C.
La escala horizontal para escritura y lectura más alta disponibilidad es A (multimaestro).
La tolerancia a fallas es P, cuando un centro de datos se cae, la plataforma no debe morir.

Conclusión : la base de datos universal que necesitamos debe tener las tres propiedades del teorema CAP, lo que significa que no hay una base de datos universal para todos nuestros requisitos.

Elegir una base de datos para los datos con los que trabaja la plataforma IoT

Si no puede elegir una base de datos universal, decidimos seleccionar los tipos de datos con los que trabajará la plataforma y seleccionar una base de datos para cada tipo.

En una primera aproximación, dividimos los datos en dos tipos:

La metainformación es un modelo del mundo, dispositivos, configuraciones, reglas, casi todos los datos, excepto aquellos que transmiten dispositivos finales.
Datos sin procesar de los dispositivos : lecturas de sensores, telemetría e información de servicio de los dispositivos. De hecho, estas son series de tiempo, donde cada mensaje individual contiene un valor y una marca de tiempo.

Elegir una base de datos para metadatos

Requisitos de la base de datos para metadatos . Los metadatos son inherentemente relacionales. Se caracterizan por una pequeña cantidad, rara vez se modifican, pero son datos importantes, no se pueden perder, por lo tanto, la consistencia es importante incluso en el marco de la replicación asincrónica, así como las transacciones ACID y el escalado de lectura horizontal.

Hay relativamente pocos datos de este tipo y se cambiarán con poca frecuencia, por lo que puede sacrificar la escala horizontal a la grabación, así como la posible inaccesibilidad de la base de datos de grabación en caso de accidente. Es decir, en términos del teorema de CAP, necesitamos un sistema CA.

Lo cual es adecuado en el caso habitual . Con tal declaración del problema, cualquier base de datos relacional clásica con soporte para clústeres con replicación asincrónica como PostgreSQL o MySQL sería muy adecuada para nosotros.

Características de nuestra plataforma . También necesitábamos soporte para árboles con requisitos específicos. Como parte del prototipo, había una característica de los sistemas de la clase BDRV (bases de datos en tiempo real): modelar el mundo usando un árbol de etiquetas. Le permiten combinar todos los dispositivos del cliente en una estructura de árbol, lo que facilita la gestión de una gran cantidad de dispositivos y su visualización.

Así es como se ve la visualización de dispositivos en forma de estructura de

árbol, que le permite vincular dispositivos finales con el entorno, por ejemplo, puede colocar dispositivos que se encuentran físicamente en una habitación en un subárbol, lo que facilita enormemente el trabajo con ellos en el futuro. Esta es una función conveniente, además, además queríamos trabajar en el nicho del sistema de detonador aerotransportado, y allí la presencia de dicha funcionalidad es en realidad el estándar de la industria.

Para la implementación completa de los árboles de etiquetas, una base de datos potencial debe cumplir los siguientes requisitos:

Soporte para árboles con ancho y profundidad arbitrarios.
Modificación de elementos de árbol en transacciones ACID.
Alto rendimiento al atravesar un árbol.

Las bases de datos relacionales clásicas pueden manejar árboles pequeños bastante bien, pero no funcionan tan bien con árboles arbitrarios.

Solución posible. Utilice dos bases de datos: una base de datos de gráficos para almacenar un árbol y una base de datos relacional para almacenar el resto de la metainformación.

Este enfoque tiene varias grandes desventajas a la vez:

Para garantizar la coherencia entre dos bases de datos, debe agregar un coordinador de transacciones externo.
Este diseño es difícil de mantener y no muy confiable.
En la salida obtenemos dos bases de datos en lugar de una, mientras que la base de datos de gráficos solo se necesita para admitir una funcionalidad limitada.

Una solución posible pero no muy buena con dos bases de datos.

Nuestra solución para almacenar metadatos . También pensamos y recordamos que inicialmente esta funcionalidad se implementó en un prototipo basado en Tarantool y resultó muy bien.

Antes de continuar, me gustaría dar una definición no estándar de Tarantool: Tarantool no es una base de datos, sino un conjunto de primitivas para construir una base de datos para su caso específico.

Primitivas disponibles fuera de la caja:

Espacio: un análogo de las tablas en la base de datos para almacenar datos.
Transacciones ACID completas.
La replicación es asincrónica utilizando registros WAL.
Una herramienta de fragmentación que admite la reorganización automática.
LuaJIT superrápido para procedimientos almacenados.
Gran biblioteca estándar.
Administrador de paquetes LuaRocks con aún más paquetes.

Nuestra solución de CA fue una base de datos relacional + gráfica basada en Tarantool. Hemos recopilado el repositorio de metainformación de sueños basado en las primitivas de Tarantool:

Espacio para almacenamiento de datos.
Transacciones ACID: estaban disponibles.
Replicación asincrónica: estaba disponible.
Relaciones - hecho en procedimientos almacenados.
Árboles - también hechos en procedimientos almacenados.

La instalación de clúster que tenemos es clásica para tales sistemas: un maestro para escritura y varios Slive con replicación asincrónica para escalar para leer.

El resultado: un híbrido rápido y escalable de una base de datos relacional y gráfica. Una sola instancia de Tarantool es capaz de manejar miles de solicitudes de lectura, incluidas aquellas con recorrido de árbol activo.

Elegir una base de datos para datos de dispositivos

Requisitos de la base de datos para datos de dispositivos . Estos datos se caracterizan por el registro frecuente y una gran cantidad de datos: millones de dispositivos, varios años de almacenamiento, petabytes de información tanto de mensajes entrantes como de datos almacenados. Su alta disponibilidad es importante, ya que son las lecturas del sensor las que operan principalmente tanto en las reglas del usuario como en nuestros servicios internos.

Para una base de datos, la escala horizontal para lectura y escritura, la disponibilidad y la tolerancia a fallas, así como la disponibilidad de herramientas analíticas preparadas para trabajar con esta matriz de datos, preferiblemente basadas en SQL, son importantes. Al mismo tiempo, podemos sacrificar la consistencia y las transacciones ACID.

Es decir, en el marco del teorema CAP, necesitamos un sistema AP.

Requerimientos adicionales. Teníamos algunos requisitos adicionales para decidir dónde se almacenarían las cantidades gigantescas de datos:

Series temporales: los datos de los sensores son series temporales, quería obtener una base especializada.
Código abierto: las ventajas del código fuente abierto no necesitan comentarios.
Un clúster gratuito es un azote común entre las bases de datos novedosas.
Buena compresión: dada la cantidad de datos y, en general, su uniformidad, quería comprimir eficientemente los datos almacenados.
Operación exitosa: queríamos comenzar en una base de datos que alguien ya está explotando activamente cerca de nuestras cargas para minimizar los riesgos.

Nuestra decision . ClickHouse se adapta exclusivamente a nuestros requisitos: una base de datos basada en columnas de series de tiempo con replicación, multimaster, fragmentación, soporte SQL y un clúster gratuito. Además, Mail.ru tiene muchos años de experiencia exitosa en la operación de uno de los clústeres ClickHouse más grandes en volumen de almacenamiento.

Pero no importa cuán bueno sea ClickHouse, y tenemos problemas con él.

Problemas de base de datos para estos dispositivos y su solución

El problema con el rendimiento de escritura. Inmediatamente hubo un problema con el rendimiento de escritura de un gran flujo de datos. Deben llevarse a la base de datos analíticos lo más rápido posible para que las reglas que analizan el flujo de eventos en tiempo real puedan ver el historial de un dispositivo en particular y decidir si generar una alerta o no.

Solución al problema . ClickHouse no tolera múltiples inserciones individuales (inserciones), pero funciona bien con grandes lotes (lotes) de datos: se adapta fácilmente a la grabación de lotes en millones de líneas. Decidimos almacenar en búfer el flujo de datos entrantes y luego pegar estos datos en lotes.

Así que lidiamos con un rendimiento de grabación deficiente. El

problema de grabación se resolvió, pero nos costó un retraso significativo de varios segundos entre los datos que ingresan al sistema y su aparición en nuestra base de datos.

Y esto es crítico para varios algoritmos que responden a los datos de los sensores en tiempo real.

Lea el problema de rendimiento. El análisis de flujo para el procesamiento de datos en tiempo real necesita constantemente información de la base de datos; estas son decenas de miles de consultas pequeñas. En promedio, un nodo ClickHouse contiene alrededor de un centenar de consultas analíticas al mismo tiempo; se creó para consultas analíticas pesadas poco frecuentes para procesar grandes cantidades de datos. Por supuesto, esto no es adecuado para calcular tendencias en el flujo de datos de cientos de miles de sensores.

ClickHouse no funciona bien con una gran cantidad de solicitudes .

Solución . Decidimos poner un caché frente a ClickHouse, que contendrá los datos más solicitados durante las últimas 24 horas.

Los datos de las últimas 24 horas no son datos de un año, sino también una cantidad bastante significativa de datos, por lo tanto, también necesitamos un sistema AP con escala horizontal para lectura y escritura, pero con un enfoque en el rendimiento tanto para grabar eventos individuales como para múltiples leyendo. También requiere alta disponibilidad, análisis de series temporales, persistencia y TTL incorporado.

Al final, necesitábamos un ClickHouse rápido, que incluso puede almacenar todo en la memoria para mayor velocidad. No encontramos ninguna solución adecuada en el mercado, por lo que decidimos construirla sobre la base de las primitivas de Tarantool:

Persistencia: es (registros WAL + instantáneas).
Rendimiento: hay todos los datos en la memoria.
Escalado: hay replicación + fragmentación.
Alta disponibilidad - hay.
Herramientas de análisis de series temporales (agrupación, agregación, etc.): realizadas en procedimientos almacenados.
TTL: realizado en procedimientos almacenados con una fibra de fondo (corutina).

Resultó ser una solución conveniente y productiva: una instancia contiene 10.000 RPC para lectura, incluidas consultas analíticas de hasta decenas de miles de consultas.

Aquí está la arquitectura resultante:

Arquitectura final: ClickHouse como base de datos analítica y caché Tarantool que almacena datos en 24 horas.

Nuevo tipo de datos: estado y su almacenamiento

Seleccionamos bases de datos especializadas para todos los datos, pero la plataforma se desarrolló y apareció un nuevo tipo de datos: estado. El estado contiene el estado actual de dispositivos y sensores, así como varias variables globales para reglas de análisis de flujo.

Por ejemplo, hay una bombilla en la habitación. Se puede activar y desactivar, y siempre debe tener acceso a su estado actual, incluso en las reglas. Otro ejemplo es una variable en las reglas de flujo, por ejemplo, algún tipo de contador. Este tipo de datos se caracteriza por la necesidad de grabación frecuente y acceso rápido, pero al mismo tiempo los datos ocupan una cantidad relativamente pequeña.

El repositorio de metainformación no es adecuado para este tipo de datos, ya que el estado puede cambiar con frecuencia y, en nuestro caso, el límite máximo de grabación está limitado a un maestro. Los almacenamientos a largo plazo y operativos también son inadecuados, ya que nuestro estado cambió por última vez hace tres años, y es importante para nosotros tener un acceso de lectura rápido.

Es decir, para la base de datos en la que se almacena el estado, la escala horizontal para lectura y escritura, la alta disponibilidad y la tolerancia a fallas son importantes, mientras que se necesita consistencia a nivel de valores / documentos. Puede recurrir a la coherencia general y a las transacciones ACID.

Una solución adecuada podría ser cualquier valor clave o una base de datos de documentos: un clúster de Redis sombreado, MongoDB o nuevamente Tarantool.

Tarantool Pros:

Esta es la forma más popular de usar Tarantool.
Escalado horizontal: hay replicación asincrónica + fragmentación.
La consistencia a nivel de documento - es.

Como resultado, ahora tenemos tres Tarantools, que usamos para casos completamente diferentes: almacenar metainformación, un caché para leer rápidamente datos de dispositivos y almacenar datos de estado.

Cómo elegir una base de datos para la plataforma IoT

No existe una base de datos universal.
Cada tipo de datos tiene su propia base de datos que es más adecuada para ellos.
A veces la base de datos que necesita puede no estar disponible en el mercado.
Tarantool es adecuado como base para una base de datos especializada.

Esta charla se realizó por primera vez en @Databases Meetup por Mail.ru Cloud Solutions. Mire un video de otras presentaciones e inscríbase en los anuncios de eventos de Telegram Around Kubernetes en Mail.ru Group .

¿Qué más leer ?

Bases de datos en la plataforma IIoT: cómo funciona Mail.ru Cloud Solutions con petabytes de datos de múltiples dispositivos