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

Segunda parte: Repensar lo que significa cliente-servidor para Edge gestion des données

En las últimas semanas, nuestra serie de blogs sobre SQLite ha analizado las deficiencias de rendimiento de SQLite cuando se manejan datos locales persistentes y las complicaciones de rendimiento creadas por la necesidad de ETL cuando se comparten datos de SQLite con bases de datos back-end. En nuestra última entrega -Mobilemay be IoT but IoT is not Mobile-empezamos a entender por qué la arquitectura SQLite sin servidor no sirve muy bien a los entornos IoT. El hecho de que SQLite sea la base de datos más popular del planeta radica en que era barata (léase: gratuita) y aparentemente suficiente para las aplicaciones monousuario Embarqué que están surgiendo en smartphones y tablets móviles.

Eso fue ayer. Mañana será una historia muy diferente.

El IoT se está expandiendo a un ritmo explosivo, y lo que está sucediendo en los bordes -en términos de aplicaciones, análisis, demandas de procesamiento y rendimiento- hará que el mundo de las implementaciones SQLite de un solo usuario parezca pintoresco. Como veremos en esta y en la próxima entrega de este blog, los requisitos de datos para los casos de uso de los bordes modernos están muy lejos de la capacidad de SQLite.

SQLite Design-Ins para el IoT: El pie equivocado

Como hemos señalado, SQLite se basa en una arquitectura de árbol B elegante pero sencilla. Puede almacenar cualquier tipo de datos, está implementado 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 se trata de SQL estándar ANSI, se acerca lo suficiente para herraduras, granadas de mano y aplicaciones móviles.

Por todas estas razones, y porque se ha utilizado de forma ubicua a medida que los dispositivos móviles han proliferado en la última década, los desarrolladores de IoT adoptaron SQLite de forma natural en muchas de las primeras aplicaciones de IoT. 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). Los datos se capturaban y almacenaban en caché en el dispositivo, con la expectativa de que se trasladarían a la nube para su procesamiento y análisis.

Pero esa expectativa no era más que una extrapolación del mundo móvil que conocíamos, y era miope. No tenía en cuenta cuánta capacidad de procesamiento podía empaquetarse en un paquete de processeur cada vez más pequeño ni dónde podrían acabar esos paquetes. No contemplaba el perímetro como un lugar para el análisis (¿no era ese el dominio de la nube y el centro de datos?). No previó el verdadero poder de la IA y el ML ni el papel que pronto empezarían a desempeñar en todo el IoT. Y no contaba con el enorme volumen de datos que pronto inundaría las redes como un tsunami virtual.

¿Ha asistido recientemente a alguna feria de IoT? Hace entre tres y cinco años, muchas de las sesiones describían PoC y pequeños proyectos piloto en los que todos los datos se enviaban a la nube. Los ingenieros y desarrolladores con los que hablamos en la feria se mostraron escépticos sobre la necesidad de algo más que SQLite. Algunos incluso cuestionaron la necesidad de una base de datos (por no hablar de bases de datos coherentes entre clientes y servidores). En los últimos tres años, sin embargo, el tema común de las sesiones ha cambiado. Empezaron a centrarse en la ampliación de proyectos piloto a la producción completa y en la infusión de rutinas de ML en dispositivos locales y puertas de enlace. Las conversaciones empezaron a tener en cuenta necesidades de gestion des données local gestion des données más sólidas. Empezaron a surgir debates, al principio en voz baja, sobre configuraciones cliente-servidor (¡OMG!). Se empezaba a comprender que el IoT no es lo mismo que el móvil.

Repensar los agujeros redondos y las clavijas cuadradas

Por supuesto, la razón para no utilizar una base de datos cliente-servidor en un entorno IoT (o, para el caso, en cualquier entorno Embarqué ) tenía todo el sentido del mundo, siempre y cuando el modelo cliente-servidor al que se renunciara fuera el modelo cliente-servidor empresarial que se había estado utilizando desde los años 80. En ese paradigma cliente-servidor, las bases de datos estaban diseñadas para el centro de datos. En ese paradigma cliente-servidor, las bases de datos estaban diseñadas para el centro de datos. Se construyeron para funcionar en grandes equipos y para soportar aplicaciones empresariales como ERP, con decenas, cientos e incluso miles de usuarios simultáneos interactuando desde máquinas apenas sensibles. Reúna estas bases de datos, añada sofisticadas capas de gestión, un ejército de administradores de bases de datos, tal vez un integrador de sistemas externo, y sumérjalas en millones de dólares de inversión, y pronto tendrá un pequeño almacén de datos empresariales.

Eso no es algo que vayas a meter en una aplicación Embarqué . Clavija cuadrada, agujero redondo. Y eso explica por qué los desarrolladores y el personal técnico de línea de negocio tendían a anunciar que tenían asuntos urgentes en otra parte cada vez que las palabras "cliente-servidor" empezaban a aparecer en las conversaciones sobre el IoT. Los casos de uso que surgían en lo que empezamos a considerar el IoT no se centraban en el usuario final humano. A menos que alguien estuviera creando un prototipo o realizando algún tipo de prueba y mantenimiento en un dispositivo o pasarela o algún tipo de instrumentación compleja, apenas se realizaban consultas ad hoc. El cliente-servidor era una auténtica exageración.

En resumen, dado un conjunto muy limitado de casos de uso, presupuestos limitados y la conciencia del coste y la complejidad de los entornos tradicionales de bases de datos cliente-servidor, confiar en SQLite tenía todo el sentido.

Reimaginar cliente-servidor pensando en el IoT

La dinámica de la gestion des données moderna gestion des données exige que replanteemos nuestras nociones de cliente-servidor, ya que las exigencias de la IO difieren de las de la informática distribuida tal y como se concebía en los años ochenta. El antiguo paradigma cliente-servidor implicaba mucha interacción ad hoc con las bases de datos, tanto directamente para consultas ad hoc como indirectamente mediante aplicaciones en las que participaban usuarios finales humanos. En los casos de uso de IoT, el acceso a los datos es más prescrito, a menudo repetido y axé sur des événements; se sabe exactamente a qué datos hay que acceder, así como cuándo (o al menos en qué circunstancias) un evento generará la solicitud.

Del mismo modo, en un determinado caso de uso de IoT no hay incógnitas sobre cuántas aplicaciones se ejecutan en un dispositivo o sobre cuántos dispositivos externos solicitarán datos a una aplicación (o los enviarán) y su emparejamiento de base de datos (y aquí, si la base de datos es Embarqué o independiente no importa realmente). Aunque estas cifras varían según los casos de uso y las implantaciones, un equipo virtual de desarrolladores, integradores de sistemas, gestores de productos y otros diseñarán la estructura, la repetibilidad y la visibilidad del sistema, incluso si no tiene estado (y más aún si tiene estado).

En el espacio moderno del IoT, los requisitos de las bases de datos cliente-servidor se parecen más a relaciones bien definidas de publicación y suscripción (publicación por el editor/lectura por el suscriptor y acceso del editor/escritura al suscriptor). Funcionan como relaciones automatizadas de máquina a máquina, en las que la publicación/difusión y las actividades paralelas de admisión multicanal suelen tener lugar simultáneamente. De hecho, cliente-servidor en el IoT es como publicar-suscribir, salvo que todo tiene que realizar ambas operaciones, y la mayoría de los dispositivos complejos (incluidas las pasarelas y los equipos inteligentes) tendrán que ser capaces de realizar ambas operaciones no sólo simultáneamente, sino también a través de canales paralelos.

Permítanme repetir esto para enfatizar: la mayoría de los dispositivos IoT complejos (léase: prácticamente cualquier cosa que no sea un sensor) va a necesitar ser capaz de leer y escribir simultáneamente.

SQLite no puede hacer esto.

Las bases de datos cliente-servidor tradicionales sí pueden, pero no se diseñaron pensando en ocupar poco espacio. La mayoría de las bases de datos cliente-servidor de la nube y los centros de datos requieren cientos de megabytes, incluso gigabytes, de espacio de almacenamiento. Sin embargo, las funciones básicas necesarias para gestionar lecturas y escrituras simultáneas de forma eficiente ocupan mucho menos espacio. Actian Zen base de données Edge, por ejemplo, ocupa menos de 50 MB. Y aunque esto es 100 veces la huella instalada de SQLite, es apenas una astilla del espacio que ocupan las plataformas basadas en procesadores ARM e Intel Embarqué de 64 bits que vemos hoy en día. Además, la huella de Actian Zen edge proporciona todos los recursos necesarios para la gestión multiusuario, la integración con aplicaciones externas a través de ODBC y otros estándares, la gestión de la seguridad y otras funcionalidades que son imprescindibles una vez que se da el salto de serverless a client-server. Una base de datos sin servidor como SQLite no proporciona esos servicios porque su necesidad -como la del propio edge- simplemente no se previó en su momento.

Si nos fijamos en la diferencia entre Actian Zen edge y Actian Zen enterprise (con su huella por debajo de 200 MB), podemos ver que la mayor parte de la diferencia tiene que ver con la habilitación del usuario final humano. Por ejemplo, Actian Zen enterprise incluye un editor SQL que permite requêtes ad hoc y otras operaciones de gestion des données desde una línea de comandos. Mientras que la mayor parte de esa misma funcionalidad reside en Zen edge, se accede y se ejecuta a través de llamadas a la API desde una aplicación en lugar de una CLI.

Pero, ¿necesitan servidores todos los escenarios de IoT Edge?

Aquellos de ustedes que han estado siguiendo de cerca ahora se sentarán y dirán: Oye, espera: ¿No decías que no todos los escenarios de gestion des données IoT necesitan una arquitectura cliente-servidor?

Sí, lo hice. Te felicito por prestar atención. No todos los escenarios lo hacen, pero esa no es realmente la pregunta que deberías hacerte. La pregunta principal es: ¿realmente quiere dominar una arquitectura, implementación y solución de proveedor para esos casos de uso sin servidor y arquitecturas, implementaciones y soluciones de proveedor independientes para el Edge, la nube y el centro de datos? Y, ¿desde qué dirección se aborda esta cuestión?

Históricamente, la gran mayoría de los arquitectos y desarrolladores de datos han abordado esta cuestión de abajo arriba. Por eso empezamos con archivos planos y luego pasamos a SQLite. En lugar de mirar desde abajo hacia arriba, estoy argumentando que tenemos que dar un paso atrás, abrazar una nueva comprensión de lo que puede ser cliente-servidor, y luego volver a examinar la cuestión desde arriba hacia abajo. No intentes forzar la adaptación de serverless a un mundo para el que nunca fue concebido, o peor aún, pasar de serverless a una implementación manipulada de una configuración de servidor de finales^{del siglo} XX.

Por ahí anda la locura, como veremos en la última entrega de esta serie, donde analizaremos qué ocurre si los desarrolladores deciden utilizar SQLite de todos modos.

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 trabajar con datos sea fácil. Nuestra plataforma de datos simplifica la forma en que las personas conectan, gestionan y analizan datos en entornos cloud, híbridos y locales. Con décadas de experiencia en gestión y analítica de datos, Actian ofrece soluciones de alto rendimiento que ayudan a las empresas a tomar decisiones basadas en datos. Estamos reconocidos por los principales analistas del sector y hemos recibido premios por nuestro rendimiento e innovación. Nuestros equipos comparten casos de éxito en conferencias (como Strata Data) y contribuyen activamente a proyectos de código abierto. En el blog de Actian tratamos temas como la ingesta de datos en tiempo real, el análisis de datos, la gobernanza y gestión de datos, la calidad de los datos, la inteligencia de datos y el análisis impulsado por IA.