La arquitectura sin servidor de SQLite no sirve para entornos IoT - Parte 1

Primera parte: El móvil puede ser IoT, pero cuando se trata de datos, IoT no es móvil

Hace tres semanas, analizamos el rendimiento bruto -o la falta de él- de SQLite. A continuación, analizamos SQLite en el contexto más amplio de la gestion des données moderna gestion des données y descubrimos que sus deficiencias de rendimiento se veían agravadas por las exigencias del entorno. Como base de datos sin servidor, SQLite requiere la integración con una base de datos basada en servidor, lo que inevitablemente supone un impacto en el rendimiento, ya que los datos de SQLite se transforman a través de un proceso ETL para ser compatibles con la arquitectura de la base de datos basada en servidor.

Los partidarios de SQLite podrían entonces adoptar un tono sarcástico y decir: "¿Sí? Bueno, si SQLite es tan lento y la integración es tan engorrosa, ¿me puedes recordar por qué es la base de datos más omnipresente que existe?".

Pues sí, podemos. Y, al mismo tiempo, podemos ofrecer incluso a los partidarios razones de sobra para dudar de que la popularidad de SQLite continúe en el futuro. Spoiler alert: ¿Qué aspecto tienen las curvas de crecimiento global del IoT fuera del ámbito de los teléfonos móviles y las tabletas?

Cómo ganó la carrera la babosa bananera

En el primer blog de esta serie, vimos por qué los desarrolladores de Embarqué adoptaron SQLite en lugar de los sencillos sistemas de gestión gestion des données archivos, por un lado, y los grandes y complejos sistemas RDBMS, por otro. Las principales razones técnicas, por resumir, son su reducido tamaño; su capacidad para ser Embarqué en una aplicación; su portabilidad a casi cualquier sistema operativo y lenguaje de programación con una arquitectura sencilla (almacén de valores clave); y su capacidad para ofrecer funciones estándar de gestion des données a través de una API SQL. La razón clave no técnica -vale, razón-es que, bueno, ¡es gratis! en casos de uso dominados por aplicaciones personales que necesitaban una gestion des données integrada (incluidas las herramientas para desarrolladores), aplicaciones web que necesitaban una caché de datos y aplicaciones móviles que necesitaban algo que ocupara muy poco espacio. Si combinamos la gratuidad con estas características técnicas y tenemos en cuenta dónde y cómo se ha desplegado SQLite, no es de extrañar que, en términos de cifras brutas, SQLite se haya desplegado más que ninguna otra base de datos.

Lo que tienen en común los tres casos de uso mencionados es que se trata de escenarios de usuario único en los que los datos asociados a un usuario pueden almacenarse en un único archivo y tabla de datos (que, en SQLite, son la misma cosa). La demanda de datos en estos casos de uso generalmente implica lecturas y escrituras en serie; hay poca probabilidad de lecturas concurrentes, por no hablar de escrituras concurrentes. De hecho, no fue hasta versiones posteriores de SQLite cuando los desarrolladores del producto sintieron la necesidad de permitir lecturas simultáneas con una sola escritura.

Pero la cuestión es la siguiente: en el futuro, esos tres casos de uso no van a ser los que impulsen las decisiones arquitectónicas clave. Irónicamente, las características de SQLite que lo hicieron tan popular entre los desarrolladores y, a su vez, dieron lugar a un mundo en el que miles de millones de dispositivos actúan, reaccionan e interactúan en tiempo real -en el borde, en la nube y en el centro de datos- yese es un mundo para el que las características clave de SQLite son singularmente inadecuadas.

SQLite ha dejado de desempeñar un papel en el ámbito de la gestion des données moderna gestion des données.

Como hemos mencionado antes, SQLite se basa en una arquitectura elegante pero sencilla, almacén clave-valor, que permite almacenar cualquier tipo de datos. La implementación se realiza en C y ocupa muy poco espacio, unos cientos de KB, lo que lo hace portátil a prácticamente cualquier entorno con un mínimo de recursos. Y, aunque no es completamente SQL estándar ANSI, se acerca lo suficiente para herraduras, granadas de mano y aplicaciones móviles.

SQLite se adoptó en muchas de las primeras aplicaciones IoT, ya que estos primeros diseños eran casi un reflejo de las aplicaciones móviles (sin la necesidad de mucho esfuerzo en la capa de presentación), centradas en el almacenamiento local de datos en caché con la expectativa de que se trasladarían a la nube para el procesamiento y análisis de datos. Los proyectos piloto baratos hacían que los diseñadores y desarrolladores recurrieran a lo que conocían y era gratis: ¡ta-dah SQLite!

Independientemente de SQLite, el mercado del IoT y sus casos de uso se han alejado rápidamente de esta trayectoria inicial. La prueba de ello es evidente si ha tenido la oportunidad de asistir a las ferias de IoT de los últimos años. Hace tres o cinco años, recuerde cuántas de las sesiones describían pruebas de concepto (PoC) y pequeños proyectos piloto en los que todos los datos se enviaban a la nube. Cuando hablábamos con ingenieros y desarrolladores en las ferias, se mostraban escépticos sobre la necesidad de algo más que SQLite o sobre la necesidad de una base de datos, por no hablar de las versiones cliente-servidor. Sin embargo, en los últimos tres años, la mayoría de las sesiones se han centrado en la ampliación de proyectos piloto a la producción completa y la infusión de rutinas de ML en dispositivos locales y puertas de enlace. Muchas más conversaciones se han centrado en el uso de una gestion des données local gestion des données más robusta, incluyendo opciones cliente-servidor.

El IoT inteligente redefine la gestion des données Edge

A pesar de sus puntos fuertes en el espacio de las aplicaciones monousuario, SQLite y su arquitectura sin servidor no están a la altura de las exigencias de los vehículos autónomos, la agricultura inteligente, la instrumentación médica y otros espacios del IoT industrial. Lo mismo ocurre con los espacios horizontales ocupados por los componentes clave del IoT industrial, como las pasarelas IoT, los equipos de red 5G, etc. A diferencia de las aplicaciones para un solo usuario diseñadas para satisfacer las necesidades entre personas y máquinas, se están creando innumerables aplicaciones de IoT para las relaciones entre máquinas que se producen en entornos altamente automatizados. Los escenarios modernos de máquina a máquina implican muchas menos relaciones uno a uno y un número mucho mayor de relaciones entre pares y jerárquicas (incluidos los escenarios de suscripción y publicación uno a muchos y muchos a uno), todos los cuales tienen requisitos de gestion des données mucho más complejos que aquellos para los que se creó SQLite. Además, a medida que la potencia de processeur ha ido migrando del centro de datos a la nube y ahora a la periferia, una gama mucho más amplia de sistemas está realizando operaciones complejas definidas por software, procesamiento de datos y análisis como nunca antes. Las demandas de procesamiento son cada vez más sofisticadas y locales.

Considérelo: Las redes de sensores IoT del mañana abarcarán desde la alimentación de datos estructurados de baja velocidad y baja resolución (capturando decenas de miles de lecturas de presión, volumen y temperatura, por ejemplo) hasta la alimentación de vídeo de alta velocidad y alta resolución de cientos de cámaras UHD en streaming. En una planta de procesamiento químico, ambas redes de sensores podrían fluir hacia una o varias pasarelas IoT que, a su vez, podrían fluir hacia una red de sistemas de borde (cada uno con la potencia que hace unos años sólo se habría encontrado en un centro de datos) para su procesamiento y análisis local, tras lo cual algunos o todos los datos y la información analítica se pasarían a una red de servidores en la Nube.

Profundizar más: Los flujos de datos brutos procedentes de estas redes deben leerse y procesarse en paralelo. Estas actividades podrían implicar descartar inmediatamente puntos de datos espurios, ejecutar filtros de señal-ruido, normalizar datos o fusionar datos de múltiples sensores, por nombrar sólo algunas de las funciones obvias de procesamiento de datos. Una parte de los datos se almacenaría tal y como llegara -de forma temporal o permanente, según lo requiriera el caso de uso-, mientras que otra parte podría descartarse.

Un mundo cada vez más complejo

En estos escenarios vemos operaciones mucho más complejas en todos los niveles, incluidas rutinas de inferencia de ML que se ejecutan localmente en los dispositivos, en la pasarela o en ambos. Puede haber operaciones adicionales que se ejecuten en paralelo en estos mismos conjuntos de datos, incluidas las operaciones de supervisión y gestión de dispositivos aguas abajo, que efectivamente crean nuevos flujos de datos que se mueven en la dirección opuesta (por ejemplo, lecturas desde la pasarela IoT y escrituras hacia abajo en la escalera jerárquica). O los datos podrían extraerse simultáneamente para la elaboración de informes y el análisis por parte de analistas empresariales y científicos de datos en la nube o el centro de datos. En un entorno como el de la planta química que hemos imaginado, también puede haber más actividades de analytique avancée y visualización realizadas, por ejemplo, en un centro de operaciones local.

Estos escenarios son cada vez más frecuentes y, al mismo tiempo, totalmente distintos de los escenarios que propulsaron el auge de SQLite. Son combinatorios y aditivos; presentan un mundo de demandas de procesamiento y gestion des données tan alejado del mundo de un solo usuario y una sola aplicación -el punto dulce de SQLite- como es posible:

• Las escrituras concurrentes son un requisito, y no sólo en un único archivo o tabla de datos, con tiempos de respuesta entre solicitudes de escritura de tan sólo unos milisegundos.
• Múltiples aplicaciones leerán y escribirán datos en las mismas tablas de datos (o se unirán a ellas) en pasarelas IoT y otros dispositivos de borde, lo que requerirá el mismo tipo de orquestación sofisticada que se necesitaría con múltiples usuarios simultáneos.
• Los sistemas de borde locales pueden tener una supervisión humana local de las operaciones, y sus actividades añadirán más complejidad a la orquestación de múltiples actividades de lectura y escritura en las bases de datos y tablas de datos.

Si todo esto te suena a un entorno para el que SQLite no está preparado adecuadamente, estás en lo cierto. En las partes dos y tres de este blog profundizaremos en estas cuestiones.

Si está listo para reconsiderar SQLite, obtenga más información sobre Actian Zen. También puede probar Zen Core, que está libre de derechos de autor para el desarrollo y la distribución.

Acerca de Actian Corporation

Actian hace que los datos sean fáciles. Nuestra plataforma de datos simplifica el modo en que las personas conectan, gestionan y analizan los datos en entornos en la nube, híbridos y locales. Con décadas de experiencia en gestión de datos y análisis, Actian ofrece soluciones de alto rendimiento que permiten a las empresas tomar decisiones basadas en datos. Actian cuenta con el reconocimiento de los principales analistas y ha recibido premios del sector por su rendimiento e innovación. Nuestros equipos comparten casos de uso probados en conferencias (por ejemplo, Strata Data) y contribuyen a proyectos de código abierto. En el blog de Actian, tratamos temas que van desde la ingesta de datos en tiempo real hasta el análisis basado en IA. Conozca al equipo directivo https://www.actian.com/company/leadership-team/