SQLite: Ni más rápido, ni mejor, ¿pero más barato?

Comprender el coste total de propiedad (TCO) de SQLite

Durante los últimos tres meses, esta serie de blogs ha explorado por qué los desarrolladores se decantaron por SQLite para Embarqué gestion des données. Algunos desarrolladores eligieron SQLite porque los miembros del equipo ampliado conocían SQL y querían aprovechar ese conocimiento para apoyar la gestion des données o la extracción de datos para visualización e informes. Sin embargo, la mayoría de los desarrolladores lo adoptaron para superar las limitaciones de los sistemas de gestión de archivos planos existentes.

Todo esto tiene sentido en retrospectiva. La adopción de nuevos productos y tecnologías suele depender de la respuesta a una simple pregunta: ¿es este sustituto una mejora con respecto a lo que tengo ahora? Más categóricamente aún: ¿es el nuevo producto más rápido, mejor o más barato? La sustitución ideal sería más rápida, mejor y más barata, pero esa trifecta suele escapársenos. Sin embargo, rara vez se produce un cambio propuesto si al menos una de estas características no está presente. ¿Qué impulsó la adopción de SQLite? ¿Era más rápido, mejor o más barato que las alternativas disponibles? Y si fue alguna de estas cosas, ¿sigue siendo más rápida, mejor o más barata que las alternativas de bases de datos disponibles en la actualidad?

¿Más rápido?

Antes, sí, SQLite era más rápido en comparación con las operaciones que implicaban un archivo plano. ¿En la actualidad? Difícilmente.

SQLite es positivamente letárgico en varios frentes. En una comparación cara a cara entre SQLite y Actian Zen Core, el acceso a los datos a través de SQL puede ser comparable, pero acceder a los mismos datos utilizando la API NoSQL de Actian Zen ofrece una mejora de rendimiento que es un orden de magnitud superior a SQLite. O considere la velocidad en términos de los tipos de interacciones cliente-servidor optimizadas que exigen las aplicaciones en el ámbito de la gestion des données moderna gestion des données. Las interacciones cliente-servidor en escenarios IoT y móviles dependen de la recopilación de datos de haute performance y del procesamiento en línea de transacciones procedentes de múltiples canales externos. Pero como SQLite funciona exclusivamente en modo sin servidor, los datos deben transformarse (la "T" de ETL) antes de que puedan pasar a o desde cualquier compañero basado en servidor, como Microsoft SQL Server. Ese paso no sólo supone un impacto medible en el rendimiento, sino que también crea un punto de estrangulamiento potencial que puede limitar la escalabilidad de la aplicación. Si a esto le añadimos la necesidad de cifrar y descifrar los datos como parte de la transformación cliente-servidor -y ¿es realmente necesario cifrar los datos en cualquier escenario moderno gestion des données ?

SQLite era un demonio de la velocidad en su época, pero también lo era la arquitectura Intel 80×86. ¿Hace falta decir más?

¿Mejor?

Bueno, a menos que sigas interactuando exclusivamente con el sistema de archivos subyacente, la respuesta es otro fácil "no". Examinamos ampliamente las limitaciones de la arquitectura sin servidor de SQLite en las entregas 5, 6 y 7 de esta serie. Aunque la arquitectura fue un gran avance en su momento, también lo fue para su época. Satisfacía la necesidad entonces emergente de una caché de datos sencilla para aplicaciones móviles y web. Pero esa no es la necesidad de hoy. Los escenarios móviles y de IoT actuales requieren una arquitectura diseñada para aplicaciones de alta velocidad, multicanal, multiproceso y multihilo. Aunque algunas de las primeras aplicaciones IoT se crearon partiendo del supuesto de que la gran mayoría de los datos se enviarían a la nube para su procesamiento y análisis -un escenario en el que SQLite parecía viable como caché de datos local-, se ha hecho evidente que el propio supuesto subyacente era erróneo. Con la aparición de una topología moderna gestion des données en el perímetro en la que el análisis y el procesamiento de transacciones pueden tener lugar en el perímetro en lugar de en la nube, una arquitectura cliente-servidor optimizada diseñada para un rendimiento optimizado a lo largo de todo el proceso dispositivo-perímetro-nube-centro de datos redefine el concepto de "mejor".

Al igual que con faster, SQLite fue en su día mejor que otras alternativas de bases de datos cuando se trataba de aplicaciones móviles monousuario y almacenamiento local de datos en caché. Pero las arquitecturas sin servidor no están pensadas para abordar las tareas de nuestro tiempo. El nuestro es un multiverso, con interacciones y transacciones multi-máquina a multi-máquina y multi-humano a máquina que ocurren todo el tiempo. Ese mundo exige más de lo que SQLite puede ofrecer.

¿Más barato?

Vale, SQLite se lleva esa. Es de código abierto, gratis. Más barato imposible. Para los aficionados al bricolaje, que miran con lupa el coste del software producido y adquirido externamente, SQLite puede seguir ejerciendo una atracción. Lo mismo ocurre con los responsables de la toma de decisiones empresariales cuando se enteran de que SQLite es gratuito. Eso podría significar que queda más en el presupuesto para otras partidas de la lista de materiales o para pagar horas de servicio adicionales.

Pero "gratis", aquí, es tan engañoso como "cachorros gratis". Si sólo te fijas en el coste inicial de SQLite, no hay nada mejor. Pero estás desvinculando esa evaluación de cualquier consideración del coste interno de esa decisión. Si se tienen en cuenta los costes de diseño del software, desarrollo, pruebas, actualizaciones, soporte continuo, etc. -todos los cuales, como ya hemos comentado, implican una gran cantidad de obstáculos, dadas las limitaciones inherentes de la arquitectura-, el cálculo del coste cambia drásticamente.

Podríamos dedicar un blog entero a las estimaciones de costes de bricolaje, así que no vamos a profundizar aquí. Cualquiera que todavía tenga activos Cobol u otras herramientas y sistemas heredados entiende perfectamente lo difícil que puede ser mantener y dar soporte a un código que se diseñó originalmente para afrontar los retos de una época anterior. Si el coste sigue siendo lo más importante para usted y si está decidido a hacer el trabajo de ampliar las capacidades de SQLite para satisfacer las necesidades actuales, hay varias herramientas a las que puede acceder para modelar la carga de costes por número de líneas de código en que incurrirá este esfuerzo. Los modelos varían en función del tamaño del código, las directrices normativas, el ciclo de vida previsto y muchos otros factores, pero pueden ayudarle a evaluar por adelantado el coste real de esta locura, perdón, de este esfuerzo.

Por supuesto, puede que estés sonriendo con suficiencia y pensando que, en realidad, no vas a hacerlo tú mismo. Hay toda una industria de desarrolladores especializados en herramientas SQLite y componentes adicionales, como editores de consultas SQL, utilidades para cifrar données au repos y en tránsito, herramientas de transformación para sincronizar datos con Microsoft SQL Server y mucho más. Pero este enfoque no hace sino introducir una dimensión diferente de coste en su empresa. Estos complementos no sólo anulan de hecho el aspecto "gratuito" de SQLite (ya que no son gratuitos), sino que la dependencia de estos pequeños proveedores introduce un elemento de riesgo sobre el que no tienes ningún control. Cualquier error o deficiencia en su código se convierte en parte inherente de tu aplicación. Si el desarrollador de la boutique desaparece -y la mayoría de ellos han desaparecido históricamente en poco tiempo-, de repente vuelves al modelo DIY que pensabas que estabas evitando. Esta vez, sin embargo, tendrás que hacerlo tú mismo sin tener una comprensión completa del código que has incorporado, lo que a menudo significa parches subóptimos y ampliar el código que probablemente habrías diseñado de manera diferente desde el principio si fuera tuyo.

Ah, y entre líneas -sin querer hacer un juego de palabras- se ve claramente que sigues necesitando un DIY para integrar estos complementos de boutique en la solución que estás desarrollando. ¿Tenemos que pinchar aún más tu burbuja señalando que la carga de solucionar cualquier problema o conflicto que surja de la incorporación de estos complementos también recae sobre ti? No tendrás necesariamente la perspicacia necesaria para resolver estos problemas con facilidad, pero en última instancia serás responsable de la solución que has entregado y la tuya será la garganta a la que recurrirán cuando los usuarios estén descontentos.

Es hora de retirar ese número

En definitiva, SQLite no es más rápido, ni mejor, ni más barato. Ya no lo es. Le daremos a SQLite su merecido: fue una brillante incorporación al equipo técnico en su juventud, pero ya es hora de izar esa camiseta hasta las vigas y jubilar el número. Si no es más rápido, mejor o más barato, ¿por qué seguir adoptándolo? Dadas las exigencias de la moderna gestion des données, más rápido, mejor y más barato, todo apunta a Actian Zen.

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.