Databus vs. Base de datos: 6 preguntas clave que todo desarrollador IIoT debe considerar

El Internet Industrial de las Cosas (IIoT) introduce muchos conceptos nuevos, a menudo construyendo sobre principios de computación familiares pero remodelando cómo operan los sistemas. Entre estos, el "databus" destaca como elemento fundacional.

La próxima arquitectura de referencia IIC v2 introduce un nuevo patrón llamado "databus en capas". Aunque los detalles aún están en revisión, el proceso de documentación ha clarificado definiciones clave y mejores prácticas.

Definición: Un databus es una tecnología de intercambio de información centrada en datos que implementa un espacio de datos global virtual. Las aplicaciones de software leen y actualizan entradas en este espacio, y las actualizaciones se propagan vía un mecanismo de publicación-suscripción.

Características clave:

1. Las aplicaciones interactúan directamente con los datos, sin envoltorios intermedios.
2. La infraestructura comprende los datos, permitiendo filtrado selectivo y herramientas avanzadas.
3. La infraestructura hace cumplir garantías de Calidad de Servicio (QoS) como tasa, fiabilidad y seguridad.

Estas propiedades conducen a una serie de preguntas que surgen al introducir conceptos de databus en un entorno IIoT. Las siguientes seis secciones abordan las consultas más comunes.

Pregunta 1: ¿Cómo difiere un databus de una base de datos?

Respuesta corta: Una base de datos almacena datos históricos para recuperación posterior, mientras que un databus gestiona datos vivos entrantes, filtrándolos por las propiedades de la nueva información.

Respuesta larga: La centricidad en datos se expresa en tres dimensiones:

• Interfaz: Los datos mismos son la interfaz principal; no hay envoltorios artificiales como mensajes o archivos.
• Comprensión: La infraestructura puede interpretar los datos, permitiendo filtrado, búsqueda e integración de herramientas.
• Gobernanza: El sistema aplica reglas para el intercambio de datos, estableciendo una única fuente de verdad y gestionando ciclos de vida de datos, esquemas y semántica CRUD.

Una base de datos relacional, por ejemplo, proporciona una capa de almacenamiento estructurado que asegura consistencia y ofrece búsqueda global. Define la "verdad" del sistema porque los datos almacenados no pueden corromperse ni perderse. Un databus, por otro lado, proporciona un espacio de datos global virtual que permite a las aplicaciones escribir y leer flujos de datos, mientras el middleware aplica reglas QoS y entrega solo la información que coincide con los criterios del consumidor.

Pregunta 2: ¿Actúa un databus como una base de datos accedida mediante interfaz pub-sub?

Respuesta corta: No. Una base de datos implica almacenamiento persistente; un databus ofrece un espacio de datos global puramente virtual que puede o no persistir datos.

Respuesta larga: Considera un controlador de intersección suscrito a posiciones de vehículos dentro de 200 m. El controlador recibe actualizaciones que satisfacen sus restricciones QoS (ej. < 0.01 s latencia, 100 actualizaciones/s). El databus puede entregar datos directamente sin almacenarlos, aunque el caching temporal puede ocurrir para cumplir requisitos de fiabilidad.

Pregunta 3: ¿Qué significa que los participantes interactúan directamente con los datos?

En middleware centrado en mensajes, las aplicaciones deben conocer detalles del peer, como esquema y tasas de actualización esperadas, lo que añade acoplamiento y dificulta la reutilización. Un databus abstrae estos detalles; las aplicaciones leen o escriben en el espacio de datos usando una interfaz CRUD, especificando solo los datos y QoS necesarios. La infraestructura maneja descubrimiento de fuentes, filtrado, transporte y garantías.

Pregunta 4: ¿Cómo funciona el filtrado selectivo en un databus comparado con pub-sub tradicional?

El pub-sub tradicional simplemente reenvía mensajes a suscriptores, a menudo sin inspeccionar payloads. Incluso el pub-sub con filtrado de contenido se basa en selectores simples que no pueden expresar QoS complejos. Un databus, por el contrario, permite a un suscriptor especificar criterios detallados (ej. vehículo dentro de 200 m, moviéndose > 10 m/s hacia la intersección, actualizaciones 200 Hz). El middleware aplica estas restricciones en la fuente, limitando, descartando o bufferizando datos para cumplir el contrato, y garantizando vida.

Como el filtrado ocurre en el productor, el suscriptor recibe solo las muestras relevantes (ej. 600 actualizaciones por segundo), reduciendo drásticamente ancho de banda y sobrecarga de procesamiento mientras asegura fiabilidad.

Pregunta 5: ¿Cómo difiere un databus de un motor CEP?

Respuesta corta: Un databus es un middleware distribuido que reenvía datos basándose en filtros simples, mientras que un motor CEP es un servicio centralizado que evalúa patrones de eventos complejos.

Respuesta larga: Los motores CEP analizan flujos para detectar patrones definidos por el usuario y pueden disparar acciones, pero requieren que todos los datos se ruten a un único nodo. Un databus realiza filtrado local en cada fuente de datos, entregando solo muestras que coinciden a consumidores interesados, escalando así a miles de nodos sin cuellos de botella centrales.

Pregunta 6: ¿Qué impulsó la creación del estándar DDS y conceptos de databus?

Adoptantes tempranos en robótica, defensa y sistemas de coordinación a gran escala demandaban fiabilidad, baja latencia y descubrimiento selectivo frente a fallos de componentes. Estos requisitos llevaron al estándar DDS, que hoy encuentra aplicación en sanidad, transporte, ciudades inteligentes y sector energético.

Para aprender más sobre software inteligente moldeando el IIoT, descarga nuestro whitepaper, The Secret Sauce of Autonomous Cars.