SQLite equivale a un proceso ETL complejo
Hace dos semanas, comparé el rendimiento de SQLite con el de una babosa del plátano. Ahora bien, puede que algunos lo consideren una exageración (y puede que algunos antiguos alumnos de la Universidad de California en Santa Cruz piensen que he mancillado el buen nombre de su mascota, lo cual no era mi intención), pero las cifras no mienten. La diferencia cuantificable en el rendimiento del procesamiento local entre SQLite y un sistema moderno de gestión de datos en el borde como Actian Zen es de dos a tres órdenes de magnitud. Por lo tanto, la comparación entre un guepardo y una babosa del plátano es cuantitativamente precisa.
De hecho, prepárate —porque voy a insistir en la analogía de la babosa de plátano—, pero voy a sustituir al guepardo (con su velocidad máxima de 70 mph) por un halcón peregrino, con una velocidad máxima de 240 mph. ¿El motivo? Al plantearse la gestión moderna de datos en el borde para el IoT, o cualquier entorno de borde a nube, hay que tener en cuenta el rendimiento en términos de lectura y escritura de datos distribuidos —entre dispositivos, pasarelas, estaciones de trabajo locales y servidores y, por supuesto, la nube—. Esa distribución plantea complicaciones que SQLite simplemente no puede superar con nada que se parezca ni remotamente a la velocidad necesaria.
Te pondré un ejemplo: SQLite solo funciona como base de datos sin servidor, lo que obliga a integrarla con una base de datos cliente-servidor y, por lo tanto, a transformar sus datos a ese formato. Es habitual ver SQLite combinada con Microsoft SQL Server, MySQL, Oracle o Postgres. Además, existen combinaciones «ocultas» en las que SQLite está presente, pero parece invisible. No se ve a SQLite junto con MongoDB o Couchbase, por ejemplo, pero la versión para clientes móviles de ambas bases de datos es, en realidad, SQLite. Los «servidores de sincronización» entre el cliente móvil y los servidores de bases de datos realizan las funciones necesarias de extracción, transformación y carga (ETL) para trasladar los datos desde SQLite a las bases de datos principales de MongoDB o Couchbase.
Pero espera, dirás: ¿No consiste precisamente la gestión moderna de datos en el borde en que los datos del borde vayan a ser capturados, compartidos y procesados por componentes más inteligentes situados en el propio borde? ¿Y además en que parte de esos datos se vayan a enviar desde los dispositivos del borde a los servidores en la nube? ¿Por qué te fijas precisamente en SQLite?
Así que, por orden, la respuesta a tus objeciones es sí, sí, y te lo voy a explicar.
La gestión moderna de datos en el borde es compartida y distribuida
Sí, todos deberíamos dar por hecho que los entornos de IoT y móviles enviarán datos desde los dispositivos y sensores de IoT en el perímetro hasta los servidores en la nube. Y sí, los nuevos estándares de red como el 5G (y las variantes industriales del 4G-LTE), junto con la IA que se ejecuta en más dispositivos periféricos, darán lugar a un procesamiento más local y entre pares. Esto trasladará la gestión de dispositivos y metadatos fuera de la nube o del centro de datos hacia las pasarelas perimetrales en servidores locales. Ambos escenarios comparten y distribuyen cantidades masivas de datos y, cuando intervenga SQLite, supondrán una explosión de procesos ETL, ya que SQLite no se ejecutará en los servidores de mayor tamaño situados en el perímetro ni en la nube. Ahí es donde entran en juego SQL Server, MySQL, Oracle, Postgres y otros (incluidas las ediciones Actian Zen Edge, Enterprise y Cloud).
Lo cual nos lleva a la pregunta de por qué es importante el ETL. Cuando se analizan las características de los sistemas que compartirán y distribuirán todos estos datos, destacan tres aspectos clave: el rendimiento, la integración y la seguridad. Ya hemos hablado de las características reales de rendimiento de procesamiento de nuestra «babosa de plátano» en lo que respecta a las operaciones locales con datos. Cuando analizamos SQLite más detenidamente en el contexto más amplio del intercambio y la distribución de datos, resulta evidente que el uso de SQLite puede tener un profundo impacto en el rendimiento operativo y la seguridad.
Todo gira en torno a la «T» de ETL
Desde el punto de vista de los sistemas de gestión de datos, la acción de transformación en el proceso ETL es el elemento más crítico de ese acrónimo. A diferencia de las letras «E» y «L», que no se ven afectadas por los sistemas de gestión de datos —ya que la transferencia de datos es una función de la máquina virtual, el sistema operativo, las capas de abstracción de hardware y, por supuesto, los subsistemas de E/S—, las implementaciones de gestión de datos determinan si se producirán transformaciones de datos, cuándo y cómo. Al trasladar datos de un formato de base de datos o sistema de gestión de archivos a otro, siempre es necesario reformatear los datos para que el sistema receptor pueda leerlos. SQLite destaca la coherencia de su sistema de archivos subyacente en todas las plataformas, lo que sugeriría que trasladar datos de una plataforma a otra no requiere ninguna transformación. Para una aplicación SQLite que funcione como una simple caché de datos en un dispositivo móvil o en sitios web con un tráfico moderado, esto puede ser cierto. Pero ese no es el caso de un entorno de IoT compartido y distribuido. Los entornos modernos de gestión de datos en el borde son totalmente gestionados, seguros y están diseñados para realizar procesamientos y análisis complejos de datos en diversos sistemas y ubicaciones: en el propio dispositivo, en el borde y en la nube. Se trata de entornos repletos de agregación de datos, intercambio entre pares y otras operaciones de gestión de datos que requieren una transformación del formato SQLite a otro —y muy posiblemente a varios formatos distintos—.
Y tú que pensabas que la babosa del plátano era lenta
Esa es la segunda dimensión en la que SQLite simplemente se vuelve lento. Actian llevó a cabo una serie de pruebas para comparar el rendimiento transformador de Zen Core y SQLite. En una serie de pruebas se comparó el rendimiento de las transferencias de datos entre SQLite y MS SQL Server con el de la misma transferencia de datos entre Zen Core y Zen Enterprise Server. Tanto los clientes sin servidor de SQLite como los de Zen Core se ejecutaron en un dispositivo Raspberry Pi, mientras que SQL Server y Zen Enterprise se ejecutaron en un sistema basado en un servidor Windows.
Los resultados de rendimiento son impresionantes: extraer un bloque de 25 000 filas de Zen Core e insertarlo en Zen Enterprise llevó una media de 3 ms. Extraer el mismo bloque de SQLite e insertarlo en Microsoft SQL Server llevó 73 ms, es decir, aproximadamente 24 veces más tiempo. Otras pruebas, en las que se compararon actualizaciones, lecturas y eliminaciones con y sin índice, arrojaron resultados similares. ¿Por qué? Debido a las transformaciones necesarias. Al trasladar datos entre SQLite y SQL Server, los datos de SQLite tuvieron que transformarse a un formato que SQL Server —que tiene un formato y un modelo de datos diferentes— pudiera leer. Al trasladar los datos de Zen Core a Zen Enterprise Server, que utilizan el mismo formato y modelo de datos, no es necesaria dicha transformación.
Adiós a lo de «más rápido, mejor y más barato»
Zen no es la única base de datos con una arquitectura común que abarca desde el cliente hasta el servidor. Microsoft SQL Server cuenta con una arquitectura de este tipo, pero solo funciona en dispositivos basados en Windows. Actian Zen funciona prácticamente en cualquier dispositivo: desde dispositivos móviles y de IoT basados en Android hasta dispositivos periféricos basados en Windows, pasando por servidores de centros de datos y en la nube que ejecutan una amplia gama de implementaciones de Linux. Zen cuenta con una arquitectura única, segura y modular que permite a la versión sin servidor interactuar con las versiones Edge, Enterprise y Cloud utilizando las mismas API, formatos de datos y sistema de archivos, lo que elimina cualquier necesidad de transformaciones.
Y ahí es precisamente donde la diferencia entre el halcón peregrino y la babosa del plátano se hace palpablemente real. Si SQLite fuera capaz de interactuar directamente con otros elementos del entorno moderno de gestión de datos en el borde, todos los que utilizan SQLite con satisfacción podrían evitar las transformaciones de datos y los procesos ETL pesados. Pero ese no es el mundo en el que nos movemos. SQLite siempre implicará procesos ETL pesados, y seguirá siendo una babosa del plátano.
En el mundo del desarrollo de ingeniería existe una disyuntiva ancestral que reza así: podemos ofrecerte más rapidez, mejor calidad o menor coste. Elige dos. SQLite promete más rapidez, pero en la práctica resulta más lento, tal y como demuestran las pruebas de rendimiento anteriores. Eso nos deja con «mejor calidad» y «menor coste», salvo que, como veremos, con SQLite ni siquiera conseguimos ni lo uno ni lo otro. No te pierdas la próxima entrada de esta serie, en la que analizaremos por qué SQLite no es mejor. Después, analizaremos con mirada aguda, como la de un halcón, el coste total de propiedad.
Puedes obtener más información sobre Actian Zen. O, si lo prefieres, puedes probarlo gratis con Zen Core, que es de uso gratuito para el desarrollo y la distribución.
Mantente conectado
Te ofrecemos información detallada sobre los datos.
(por ejemplo, sales@..., support@...)
