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 vertiginoso, y lo que está ocurriendo en el «edge» —en cuanto a aplicaciones, análisis, demandas de procesamiento y rendimiento— hará que el mundo de las implementaciones de SQLite para un solo usuario parezca algo anticuado. Como veremos en esta y en la próxima entrada de este blog, los requisitos de datos para los casos de uso modernos en el «edge» van mucho más allá de las capacidades 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 dado que se ha utilizado de forma generalizada a medida que los dispositivos móviles se han ido extendiendo durante la última década, los desarrolladores de IoT adoptaron de forma natural SQLite en muchas de las primeras aplicaciones de IoT. Estas primeras integraciones eran prácticamente réplicas de las aplicaciones móviles (sin la necesidad de dedicar mucho esfuerzo a la capa de presentación). Los datos se capturaban y se almacenaban en caché en el dispositivo, con la expectativa de que se transfirieran 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 se pueda encajar a la fuerza en una aplicación integrada. Es como meter una clavija cuadrada en un agujero redondo. Y eso explica por qué los desarrolladores y el personal técnico de las empresas solían decir que tenían asuntos urgentes que atender en otro lugar cada vez que las palabras «cliente-servidor» empezaban a surgir en las conversaciones sobre el IoT. Los casos de uso que surgían en lo que empezamos a considerar como 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, una pasarela o algún sistema de instrumentación complejo, apenas se realizaban consultas ad hoc. El modelo 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 gestión moderna de datos en el borde exige que replanteemos nuestros conceptos sobre el modelo cliente-servidor, ya que las exigencias del IoT difieren de las de la informática distribuida tal y como se concebía en los años 80. El antiguo paradigma cliente-servidor implicaba una gran cantidad de interacciones ad hoc con bases de datos, tanto de forma directa para consultas ad hoc como de forma indirecta a través de aplicaciones en las que participaban usuarios finales humanos. En los casos de uso del IoT, el acceso a los datos está más regulado, suele ser repetitivo y está impulsado por eventos; 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 caso de uso concreto del IoT, no hay incógnitas sobre cuántas aplicaciones se están ejecutando en un dispositivo ni sobre cuántos dispositivos externos solicitarán datos (o enviarán datos) a una aplicación y a su base de datos asociada (y, en este caso, no importa realmente si la base de datos está integrada o es independiente). Aunque estas cifras varían según los casos de uso y las implementaciones, un equipo virtual formado por desarrolladores, integradores de sistemas, gestores de producto y otros profesionales diseñará la estructura, la repetibilidad y la visibilidad del sistema, incluso si este es sin estado (y más aún si es con estado).
En el ámbito actual del IoT, los requisitos de las bases de datos cliente-servidor se asemejan más a relaciones de publicación y suscripción bien definidas (publicación por parte del editor/lectura por parte del suscriptor y acceso por parte del editor/escritura por parte del suscriptor). Funcionan como relaciones automatizadas de máquina a máquina, en las que las actividades de publicación/difusión y de recepción multicanal en paralelo suelen tener lugar de forma simultánea. De hecho, el modelo cliente-servidor en el IoT es similar a la publicación-suscripción, salvo que todo debe realizar ambas operaciones, y la mayoría de los dispositivos complejos (incluidas las pasarelas y los equipos inteligentes) deberán ser capaces de llevar a cabo ambas operaciones no solo de forma simultánea, 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 analizamos las diferencias entre Actian Zen Edge y Actian Zen Enterprise (cuya huella es inferior a 200 MB), podemos observar que la mayor parte de ellas tiene que ver con las capacidades que se ofrecen al usuario final. Por ejemplo, Actian Zen Enterprise incluye un editor SQL que permite realizar consultas ad hoc y otras operaciones de gestión de datos desde la línea de comandos. Aunque la mayor parte de esa misma funcionalidad está presente en Zen Edge, se accede a ella y se ejecuta mediante llamadas a la API desde una aplicación, en lugar de desde una interfaz de línea de comandos (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 de datos y desarrolladores han abordado esta cuestión de abajo hacia arriba. Por eso empezamos con archivos planos y luego pasamos a SQLite. En lugar de mirar de abajo hacia arriba, defiendo que debemos dar un paso atrás, adoptar una nueva visión de lo que puede ser el modelo cliente-servidor y, a continuación, replantearnos la cuestión de arriba hacia abajo. No intentes simplemente encajar a la fuerza el modelo «serverless» en un mundo para el que nunca fue concebido —o, peor aún, improvisar a partir del «serverless» una implementación chapucera de una configuración de servidor de finalesdel 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.
¿Estás listo para replantearte el uso de SQLite? Descubre más sobre Actian Zen. O, si lo prefieres, puedes probarlo gratis con Zen Core, que es de uso libre para el desarrollo y la distribución.
Mantente conectado
Te ofrecemos información detallada sobre los datos.
(por ejemplo, sales@..., support@...)
