Cómo optimizar la fusión de datos de sensores con bases de datos en tiempo real

En el primer escenario (A), una base de datos tradicional utiliza un modelo de concurrencia pesimista. Todas las tareas que compiten por el mismo recurso (como una base de datos o un bloqueo de tabla) se ejecutan secuencialmente en orden FIFO.

En el segundo escenario (B), una base de datos tradicional utiliza un modelo de concurrencia optimista donde la primera y la segunda tarea compiten por el mismo recurso (por ejemplo, actualizar la misma fila de una tabla). Todas las tareas se ejecutan en paralelo, pero una de las dos primeras tareas recibe una notificación de un conflicto y debe volver a intentar su transacción.

El tercer caso ilustra lo que sucede en un administrador de transacciones consciente del tiempo (en tiempo real) cuando tres tareas inician transacciones aproximadamente al mismo tiempo (C): Las tres transacciones (T1P2, T2P1 y T3P2) están en cola.

Luego (D) el administrador de transacciones programa las transacciones según su prioridad y fecha límite.

Dado que T1P2 comenzó primero y no se estaban ejecutando otras transacciones en ese momento, la ejecución comenzó de inmediato. Pero T2P1 entró en la cola inmediatamente después. El programador detecta que T2P1 tiene una prioridad más alta que T1P2 y el tiempo de reversión es más corto que la fecha límite de T2P1, por lo que T1P2 avanza y se ejecuta T2P1. T3P2 comenzó en último lugar y tiene una prioridad menor que T2P1, por lo que espera en la cola independientemente de su fecha límite. Una vez completado el T2P1, se programa el T3P2 ya que el plazo es más corto que el del T1P2.

Dado que no existe un sistema de base de datos en tiempo real, estas cosas deben resolverse a nivel de aplicación. Se necesita tiempo para diseñarlo e implementarlo, y ese es tiempo dedicado a tareas que no están directamente relacionadas con las responsabilidades de la aplicación.

Esto requiere recursos adicionales (y costos asociados) o lleva tiempo implementar la funcionalidad principal del sistema de destino (por ejemplo, conducir el automóvil). Esto, a su vez, alarga el cronograma de desarrollo y genera costos de oportunidad difíciles de medir pero aún así auténticos. Después de todo, sabemos por años de estudio que los errores son costosos y cuanto más tarde en el ciclo de desarrollo se descubren, más costosos se vuelven.

La necesidad de una base de datos «verdadera» en tiempo real

Los desarrolladores de sistemas en tiempo real de misión crítica deberían considerar un sistema de base de datos en tiempo real que ya haya sido sometido a extensas pruebas unitarias, pruebas de integración y un sólido control de calidad. Esto evita los costos de corregir defectos a lo largo del ciclo de desarrollo que surgen del desarrollo interno de los requisitos anteriores.

Los desarrolladores deben tener cuidado de no confundir marketing con rendimiento. Muchos proveedores de sistemas de bases de datos utilizan el término “tiempo real” para promover soluciones que en realidad no funcionan en tiempo real. En este contexto, el término se refiere a datos o análisis «en vivo». Y «en tiempo real» significa que no hay demoras causadas por guardar los datos y luego volver a leerlos antes de realizar el análisis, o actualizar el conjunto de resultados de una consulta «en tiempo real» sin la necesidad de volver a consultar el sistema de bases de datos.