Datos curiosos sobre SQLite

• SQLite es la base de datos más distribuida y utilizada

  • Hay más de 1 billón de bases de datos SQLite en uso, y la mantienen tres personas
  • No permite contribuciones externas

• SQLite se usa más que todos los demás motores de base de datos juntos

  • Existen miles de millones de copias de SQLite y está en todas partes

• SQLite es uno de los módulos de software más distribuidos

• Hwaci es la empresa que desarrolló SQLite y también le interesa la música

• SQLite comenzó en un acorazado estadounidense

  • D. Richard Hipp (DRH) estaba desarrollando software para un destructor naval llamado USS Oscar Austin
  • Había un problema: cada vez que el servidor se caía, el software existente dejaba de funcionar
  • DRH ideó una base de datos que pudiera funcionar sin servidor

• SQLite no es open source en el sentido legal

  • El open source requiere una definición específica y una licencia aprobada por la OSI
  • En cambio, SQLite pertenece al dominio público y tiene menos restricciones que una licencia open source

• No permite contribuciones externas

  • Solo las personas invitadas pueden contribuir, y las contribuciones deben cederse al dominio público

• El código de pruebas de SQLite

  • SQLite tiene más de 600 líneas de código de pruebas por cada línea de código
  • Las pruebas cubren el 100% de todas las ramas de la biblioteca

• Algunas pruebas de SQLite son propietarias

  • Un conjunto de pruebas llamado TH3 es propietario, y para acceder a él hay que unirse al consorcio de SQLite

• El modelo de negocio de SQLite

  • Genera ingresos mediante soporte de pago, servicios de mantenimiento, membresías del consorcio y extensiones comerciales

• SQLite tiene un código de ética en lugar de un código de conducta

• SQLite es muy rápido y, en algunos casos de uso, es 35% más rápido que el sistema de archivos

• SQLite tiene un modelo de escritor único

  • No permite varios escritores al mismo tiempo

• Diferencias con otras bases de datos

  • Usa por defecto el modo de rollback journal, y las claves foráneas están desactivadas
  • Usa tipado débil, y el tipado fuerte es opcional

• La falta de tipos en SQLite puede ser incómoda

  • Se pueden insertar datos sin restricciones de tipo

• SQLite da muchísima importancia a la compatibilidad

  • Todas las versiones de SQLite 3 pueden leer y escribir archivos de base de datos de las versiones iniciales

• El autor de SQLite, DRH, consideró que los sistemas de control de versiones existentes no eran adecuados y por eso desarrolló Fossil

• DRH programó el B-Tree en un avión basándose en los algoritmos del libro TAOCP

• Se recomienda pronunciar SQLite como "Ess-Cue-El-Lite", aunque no existe una guía oficial

[dalinaum]

SQLite no es una base de datos tan rápida como uno podría pensar. MongoDB Realm, que ahora ya está descontinuado, es mucho más rápido. Parece que para la gente la velocidad no era un factor de elección tan importante.

[dalinaum]

Hubo alguien que preguntó por qué Realm era rápido y pidió fundamentos, pero parece que MongoDB eliminó la publicación cuando discontinuó el soporte.

Así que, desde la perspectiva de alguien que trabajó en esto en su momento, voy a explicar las razones técnicas que recuerdo. Creo que la mayor ventaja era que Realm usaba menos memoria que SQLite y tenía una tasa de aciertos de caché más alta.

Realm elige la cantidad que guarda en memoria en función del tamaño que realmente se usa. Por eso, aunque el usuario seleccione tipos de datos de gran tamaño, muchas veces los serializa en tamaños pequeños de unos pocos bits. La conversión se hace cuando de verdad el usuario necesita usar datos más grandes.

Realm agrupa y almacena juntos los datos del mismo tipo, de forma contigua. Muchas veces los usuarios no acceden a todos los datos de una tabla, sino a una parte de ellos de manera secuencial. Debido a esa codificación de menor tamaño que mencioné antes, la cantidad de datos que se puede encontrar de una sola vez en caché aumenta muchísimo.

Realm no hidrata objetos POJO, sino que entrega los datos cuando hacen falta mediante getter y setter. Para lograrlo, en Java manipula el código a nivel de bytecode. La razón por la que tipos de datos como Protobuf se usaban en ese entonces en el cliente de la app de Facebook de Meta era que este proceso de hidratación representaba una gran desventaja de rendimiento, y acceder solo a los datos necesarios tenía ventajas.

Realm era mucho más rápido que SQLite en la mayoría de los escenarios, pero no creo que ese haya sido un factor tan importante en el mercado.

Si no recuerdo mal, el mayor competidor de Realm era Parse, que había sido creado por Facebook. Después, el competidor pasó a ser Firebase de Google. Ninguno de los dos es una base de datos móvil local, sino servicios para guardar datos fácilmente en remoto. Uno podría preguntarse cómo Realm podía competir con esos dos, pero al usuario real probablemente solo le importaba poder guardar los datos en cualquier lugar, y la velocidad no parecía ser tan importante.

Y después, cuando Ericsson invirtió, el alcance de Realm se redujo. Ericsson veía que Realm ya tenía cierta participación en iOS y no entendía por qué había que seguir desarrollando más funciones. En cambio, reconocía más valor en Realm como solución de sincronización. Más tarde, Realm terminó fusionándose con MongoDB.

[aer0700]

Creo que el 80% de la razón por la que elegí SQLite fue porque era fácil de manejar.

[dalinaum]

Creo que esta también es una de las razones importantes. Realm ofrecía una forma de uso basada en thread-local, proporcionaba actualización automática y decía que, si se volvía a consultar desde otro hilo, podía entregar los mismos datos con un costo muy bajo, además de recomendar no pasar datos a otros hilos, pero no era fácil explicar este tipo de cosas.

[sanggi]

¡Parece que usan SQLite en muchísimos lugares!

[xguru]

Historias poco conocidas de SQLite

[GN⁺]

Comentarios en Hacker News

• Hay quienes opinan que la OSI no es el criterio definitivo de lo que es código abierto. La definición de open source de la OSI es útil, pero también ha recibido críticas y controversias. Decir que SQLite no es legalmente open source es una afirmación incorrecta

  • No es deseable depender de la aprobación de la OSI. La lista de licencias aprobadas por la OSI solo refleja una historia práctica y política
  • Hay debate sobre si SQLite es open source. La dedicación al dominio público no es una licencia, por lo que no cumple con la OSD, pero es aún más abierta

• El blog parece intentar generar vistas e interacción usando puntos viejos reciclados sobre un tema popular

  • Las publicaciones anteriores del blog carecen de profundidad técnica y tienen mucho contenido exagerado

• SQLite tiene un código de ética (CoE), no un código de conducta (CoC). El CoC se usa como herramienta para controlar el comportamiento de colaboradores externos, mientras que el CoE es una declaración del comportamiento que los desarrolladores de SQLite buscan tener hacia los demás

• Hay confusión sobre la pronunciación de SQLite. Se dice que se pronuncia "Ess-Cue-El-Lite", pero hay personas que lo pronuncian como "S-Q-L-ite"

• SQLite admite tablas estrictas de forma opcional. Se puede forzar el tipado usando CREATE TABLE name (stuff TEXT) STRICT

• SQLite puede usarse no solo como base de datos SQL, sino también como base de datos NoSQL. La forma de almacenar datos usando columnas JSON es útil

• Hay experiencia de haber trabajado en un proyecto con Richard Hipp. Él obtiene ingresos estables mediante contratos de soporte

• En una de las versiones de SQLite, el rendimiento mejoró un 50% gracias a muchas microoptimizaciones

• Se usa SQLite para prototipado rápido y volcados de logs, pero cuando se quiere soporte para múltiples escritores aparecen dificultades. Esa es una de las principales razones para dejar de usar SQLite

• SQLite tiene un modelo de un solo escritor. Redis también tiene un modelo de un solo hilo

• Uno de los datos curiosos de SQLite es que tuvieron que cambiar el prefijo predeterminado de sqlite_ a etilqs_ cuando los usuarios empezaron a llamar a los desarrolladores a medianoche