La transición de los archivos planos a SQLite

En diciembre, enero y febrero, publiqué una breve serie de blogs sobre los sistemas de archivos planos. La serie de blogs se centra en el uso continuado de archivos planos y por qué ya no son viables para su uso en el futuro.

La primera entrega se centraba en los archivos planos y en por qué los desarrolladores de aplicaciones informáticas Embarqué los adoptaban con facilidad. Luego, en la segunda entrega, analicé por qué los desarrolladores de Embarqué se resisten a utilizar bases de datos. La tercera entrega analizó por qué los desarrolladores se aferran a los sistemas de archivos planos. La última entrega proporcionó una lista de comprobación para los desarrolladores de Embarqué que migran de los archivos planos.

En la siguiente serie, me gustaría centrar mi atención en el siguiente peldaño en el camino de muchos desarrolladores de Embarqué que se alejan de los archivos planos: SQLite. Aunque es un progreso, me gustaría convencerte de que deberías pasar por encima de esta piedra o saltar de ella si todavía te estás tambaleando.

Quizá deberíamos empezar por explicar por qué y cómo supone un paso adelante respecto a los archivos planos. Eso, por supuesto, tendría que ser con respecto a dónde y cómo se aplica a los requisitos del mundo real. Según la propia gente de SQLite, como se indica en el sitio web de SQLite, Usos apropiados de SQLite: "SQLite no compite con las bases de datos cliente/servidor. SQLite compite con fopen()". Esta afirmación está ligada a su principio fundamental de que no está pensado para ser comparado con los motores de bases de datos SQL porque los motores de bases de datos SQL están pensados para ser un repositorio compartido de datos empresariales. Para ser un repositorio compartido, de acuerdo con el sitio SQLite y por lo tanto la comunidad, un motor de base de datos SQL necesita: Escalabilidad, simultanéité, centralización y control. SQLite, por otro lado, se centra en el almacenamiento local de datos para aplicaciones y dispositivos individuales donde hay un requisito para la administración de base de datos cero (a continuación, proporcionan la lista de lavandería estándar de los dispositivos típicos de la IO).

La gente de SQLite también dice que sería genial en entornos Embarqué si se pudiera tener un único formato de archivo compacto para soportar la transferencia de datos entre plataformas y así como conjuntos de datos ad-hoc, de cosecha propia de múltiples tipos de datos. De hecho, SQLite ha realizado pruebas comparativas para demostrar que son un 35% más rápidos que los sistemas de archivos y que la lectura y escritura de este tipo de datos a través de fread() o fwrite()¹.

Estamos de acuerdo con la mayor parte de lo que dice la gente de SQLite: sí, los motores de bases de datos SQL deben cumplir los requisitos enumerados anteriormente. Sí, existe la necesidad de una gestion des données local gestion des données que sea portátil entre plataformas y pueda soportar múltiples tipos de datos; y, por último, definitivamente no hay manera de evitar un entorno de administración cero en el borde para móviles e IoT.

Así que, dicho esto, "U" sabe lo que viene a continuación, esa palabra de tres letras que empieza con "B" y acaba con "T": PERO. ¿Y si pudiera tener su pastel y comérselo también? ¿Y si pudieras obtener todas las características y ventajas de los almacenes de datos compartidos empresariales de un motor de base de datos SQL, y a la vez tener la capacidad de reducirlo y Embarquer directamente en una aplicación móvil o IoT local, con soporte para múltiples tipos de datos, portabilidad entre plataformas y sin necesidad de administrar la base de datos?

La respuesta que debe dar es sí. Sin embargo, puede replicar con las siguientes posturas razonables:

En primer lugar, SQLite y los sistemas de archivos son gratuitos y populares. Los motores de bases de datos SQL de código abierto (MySQL, Postgres, MariaDB, etc.) no son capaces de funcionar escalados a una huella IoT o Móvil. Tampoco puedo ejecutarlos Embarqué en mis aplicaciones.

En segundo lugar, ¿por qué la gente utiliza una analogía tan estúpida como que puedes tener tu pastel y comértelo también? Es más bien como si necesitara un coche, no un camión, eso es exagerado, así que ¿para qué molestarse?

Bueno, mi respuesta sería que eso es tan de 2015 (por cierto, esa fue la última vez que SQLite actualizó su página de "uso apropiado"). El hecho es que, en 2020 y definitivamente, en 2025, necesitarás la funcionalidad de un coche y un camión con cualquier aplicación que construyas de todos modos. Sí, necesitarás almacenar y analizar muchos más datos localmente, incluso con WiFi-6 y ancho de banda 5G. Sin embargo, el mero aumento del volumen de datos y la necesidad de gestionar dispositivos de igual a igual y de borde a nube, compartir datos contextuales para la gouvernance, imágenes operativas comunes, etc., dictarán lo máximo posible y seguirán necesitando realizarse localmente para evitar la latencia.

Además, muchas operaciones peer-to-peer y edge-to-cloud -por no hablar de las operaciones de pasarela en las que se toman datos de múltiples fuentes descendentes- requieren simultanéité y control de esas fuentes de datos descendentes. Las puertas de enlace y los almacenes de datos periféricos también requerirán escalabilidad para poder utilizar la misma arquitectura y portabilidad de datos entre plataformas. Por último, a medida que se traslada más funcionalidad a esa pasarela que habría estado en el centro de datos o en la nube, lo que se consideraba funcionalidad de centralización también debe trasladarse allí.

Por tanto, piensa que tu coche necesita tracción a las dos ruedas en la mayoría de los casos, pero necesita la opción de tracción total en el resto. Tu coche también puede necesitar capacidad de remolque. Pero, también piense en esto a la inversa, su camión no siempre está remolcando un barco o se utiliza para todo terreno, y tal vez lleva pasajeros adicionales, y usted quiere muchas de las comodidades de un coche de lujo.

Para resumir, con respecto a la gestion des données y esta analogía, el borde en 2020 y en los próximos cinco años requiere todo lo que se necesitaba en el centro de datos para un almacén de datos SQL (los requisitos de su camión). Pero también, todo lo que se necesitaba para la gestion des données del dispositivo local cuando era autónomo (los requisitos de su coche).

En esencia, necesitas un todoterreno que pueda escalar desde un CRV muy pequeño hasta uno de tamaño monstruoso. Desafortunadamente, esto no es lo que SQLite es capaz de hacer, e invariablemente, cuando usas SQLite, te ves forzado a atornillarlo a alguna otra base de datos en el otro extremo. Discutiremos los inconvenientes de este matrimonio forzado en el próximo blog.

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, cubrimos temas que van desde la ingestión de datos en tiempo real hasta el análisis impulsado por IA.