La historia desconocida de SQLite

• Resumen de un pódcast de entrevista con Richard Hipp, desarrollador de SQLite (38 min, con transcripción)
• Su trabajo principal era como desarrollador de software para destructores de la Armada de EE. UU. → El Informix que usaban dentro del barco daba errores con frecuencia, el servidor se caía y la conexión se cortaba. → Como era un buque de guerra, incluso si recibía daños en combate, no podía aparecer un popup de “No se puede conectar a la base de datos”; tenía que seguir funcionando de forma robusta. Tampoco necesitaban transacciones, pero sí cargar los datos en RAM bajo cualquier circunstancia. → Buscó un motor de base de datos SQL que corriera sin servidor, pero no había ninguno, así que decidió hacerlo él mismo.

SQLite V1 (año 2000)

• Escribió un motor de bytecode que compilaba y ejecutaba consultas, tratando las sentencias SQL como programas.
• En realidad no se usó en el proyecto (el cliente quería usar Informix).
• Mientras lo usaba para desarrollo, lo publicó en internet y la gente empezó a usarlo.
• Empezó a ver comentarios como “Corrí una base de datos SQL en una Palm Pilot”, y eso atrajo la atención de la gente. Eso lo animó a seguir trabajando en el proyecto.

Motorola

• Entre 2001 y 2002, Motorola lo llamó para decirle que quería incluir SQLite en su nuevo sistema operativo para teléfonos.
• Le ofrecieron pagar si agregaba las funciones que necesitaban.
• Ahí fue cuando supo por primera vez que se podía ganar dinero con el open source.
• Eran unos $80,000, que hoy no suenan a tanto, pero para él fue una cantidad impresionante.
• Hizo el proyecto junto con otras tres personas con las que trabajaba, y ese fue el comienzo.

America Online Phones

• Después, quien se puso en contacto fue AOL.
• Era la época en la que enviaban CDs por correo, y dentro de ese CD necesitaban una base de datos.
• Es decir, querían meter SQLite en el CD, y también necesitaban nuevas funciones.

Symbian OS y Nokia

• Viajó a Londres en Thanksgiving para una reunión (porque en Reino Unido no existe Thanksgiving).
• Querían una base de datos para Symbian OS, y SQLite compitió contra otras bases de datos (2 open source y 7 comerciales).
• A las otras 9 bases de datos les dieron oportunidad de hacer tuning, pero SQLite terminó ganando.

Bus Factor [1] y el consorcio

• El bus factor es una métrica que indica cuántas personas tendrían que ser atropelladas por un autobús para que el desarrollo se detenga.
• Aunque él trabajaba full time junto con varias personas, en Symbian dijeron que había que subir el bus factor.
• La idea era iniciar el consorcio de SQLite para financiar el proyecto y lograr que más gente participara a largo plazo.
• Se le ocurrió la loca idea de que todos los miembros del consorcio tuvieran derecho a voto.
• Mitchell Baker, de la Fundación Mozilla, escuchó eso por algún lado y lo llamó. → “Richard, lo estás haciendo completamente mal. Te voy a enseñar cómo se arma un consorcio.” → Ella empezó a definir las reglas. → “Los desarrolladores deben tener el control. Su decisión es la final. No puedes dar derecho a voto solo por entrar.” → “Las empresas que usan esto obtienen el honor de aportar dinero, pero la decisión final debe ser tuya.” → Fue muy firme y puso todo en orden. Ella es abogada.
• Cuando Richard preguntó: “¿Y cómo hacemos para que la gente participe? ¿Cuál sería el incentivo?”, → ella respondió: “No te preocupes. Van a participar. Y de hecho, si lo haces así, Mozilla será miembro fundador.”
• Con apoyo de Mozilla, Symbian y Adobe, iniciaron el consorcio con esas tres empresas. → Al principio, cuando Symbian dijo que hacía falta un consorcio, él no tenía idea de qué hacer. No sabe cómo Mitchell Baker se enteró y lo llamó, pero dice que todo fue un viaje increíble.

Enter Android : el inicio de Android

• Como todos los smartphones usaban SQLite, Richard podía ver el desarrollo inicial de los smartphones desde todos los ángulos.
• En 2005 tuvo reuniones con Android. En ese momento todavía no existían ni Android ni el iPhone en el mercado.
• Hizo debugging de SQLite conectándolo a un teléfono parecido a un BlackBerry, con una pequeña pantalla arriba y teclado QWERTY completo.
• Fue una experiencia sorprendente hacer debugging con GDB en un teléfono conectado a una red telefónica real.
• En ese momento nadie en Motorola, Symbian ni Nokia hacía algo así, y ahí supo que Android se volvería enorme.

Guy, This Is Important : gente, esto es realmente importante

• En esa época, otros fabricantes tenían ciclos de actualización de hardware y software larguísimos, de unos 30 días, pero Android cargaba un nuevo OS varias veces al día en teléfonos conectados a la red real.
• El prototipo de teléfono Android que recibió bajo NDA tenía una carcasa que parecía hecha en impresora 3D, pero al menos se podía llevar en el bolsillo. → Los de otras empresas eran grandes protoboards y prototipos, ni siquiera estaban conectados a la red, así que ni podían usarse como teléfono.
• Quería decirles a la gente de Motorola y Symbian: “Esto es importante, tienen que resolverlo”, pero no podía decir nada por el NDA. Y eso terminó marcando la diferencia.

Testing and Aviation Standards : pruebas y estándares aeronáuticos

• Adam (el entrevistador): “La base de datos de Richard está en un momento realmente vibrante. Tienen talento, un gran equipo, pero en esencia siguen siendo una consultora de software de 1 a 4 personas que mantiene la base de datos que va en todos los teléfonos Android. Los desarrolladores de bases de datos se toman esto muy en serio y odian que los datos se dañen.”
• Nosotros presumíamos de forma ingenua que SQLite no tenía bugs, pero Android demostró claramente que estábamos equivocados.
• Pensaban que era posible hacer software sin errores, pero cuando el software se instala en millones de dispositivos, resulta sorprendente cuántos bugs pueden aparecer.
• Por esa época también estaban trabajando con Rockwell Collins, una empresa de aviónica, y ellos les presentaron el concepto de DO-178B [2]. → DO-178B trata sobre estándares de calidad para productos aeronáuticos críticos para la seguridad y, a diferencia de otros estándares de calidad, “se puede leer”. → Cuesta unos cientos de dólares, pero como es delgado, recomienda mucho leerlo.
• Realmente empezaron a seguir el proceso de DO-178B, y una de esas cosas era lograr 100% de cobertura de pruebas MCDC.
• MCDC (Modified Condition / Decision Coverage) [3] significa que las pruebas deben recorrer cada rama individual al menos una vez.
• Lograr que SQLite alcanzara 100% MCDC tomó un año trabajando 60 horas por semana. Fue realmente muy difícil. Tenía que trabajar 12 horas al día y fue agotador.
• Llegar a 90~95% de cobertura es fácil; el 5% restante es lo realmente difícil. Pero después de hacerlo durante un año y finalmente alcanzar 100%, dejaron de llegar reportes de bugs desde Android.
• Ahí fue cuando empezó a funcionar de verdad y marcó una gran diferencia. Después de eso, no hubo bugs durante 8~9 años.

Decenas de miles de millones de pruebas

• La primera batería fue escrita en TCL (Tool Command Language), y era una prueba típica de desarrolladores.
• Ese primer test en TCL todavía se mantiene y sigue siendo público. No da 100%, pero prueba en detalle todas las funciones de SQLite.
• La cobertura MCDC al 100% se llama TH3 y no es pública (proprietary).
• Intentaron ganar dinero vendiéndosela a empresas aeronáuticas, pero no lograron vender ni una sola copia, así que por ese lado no funcionó.
• Pero sí les permitió mantener el producto realmente robusto y hacer nuevas funciones y correcciones de bugs con rapidez.
• Es difícil contar cuántas pruebas hay, pero 100,000 pruebas individuales están parametrizadas y terminan ejecutando decenas de miles de millones de pruebas.
• Tienen un checklist y antes de cada release hacen pruebas durante al menos 3 días.
• Prueban deliberadamente en varios sistemas operativos. → Hoy casi todos los equipos son little-endian, pero antes había muchos big-endian. Por eso hacían pruebas big-endian en una PowerPC iBook. → Hacen pruebas en plataformas de 32 bits, ARM e Intel, plataformas de 64 bit, Windows, Linux, Mac, OpenBSD y cualquier plataforma y OS que puedan cubrir. → Tienen varios test suites distintos: el TCL original, TH3 y también fuzzers que corren de forma continua.
• También tienen pruebas de SQL Logic. → Es una enorme masa de sentencias SQL creada por Shane Harrelson hace 10 años. → La probaron contra todas las bases de datos que pudieron tocar, y todos los motores de base de datos fallaban o daban segmentation fault. SQLite también. Todos menos Postgres. → Solo Postgres siempre daba resultados y no lograban encontrarle fallas. Los desarrolladores de Postgres decían que ellos no se habían esforzado lo suficiente, pero aun así quedaron muy impresionados. → Incluso la versión comercial de Oracle se caía, y DB2 también. → El punto importante fue hacer que SQLite devolviera la misma respuesta para todas esas consultas.

Building From First Principles

• Cuando empezó a escribirlo, intentó buscar referencias sobre cómo construir un motor de base de datos SQL, pero no había nada. Así que tuvo que hacerlo él mismo y fue una misión completamente independiente.
• Había muchas teorías desarrollándose en MIT, Harvard y Berkeley, pero si no ibas a esas universidades ni siquiera sabías que existían, y tampoco había una forma clara de encontrarlas.
• El modelo Volcano que usa Postgres y el modelo de bytecode que usa SQLite, si se analizan, muestran que ambos terminaron convergiendo en la misma idea.
• Desde arriba parecen partir de lugares muy distintos, pero ambos convergen en la misma zona al preguntarse cómo hacerlo más rápido.
• Cree que eso es una especie de validación teórica: dos líneas de desarrollo independientes llegando a la misma respuesta.
• Por ejemplo, él no sabía nada sobre los covering indexes, pero en una conferencia de PHP en Alemania coincidió con David Axmark, de MySQL, que dio una charla. → En esa charla explicó cómo MySQL había implementado los covering indexes. → Cuando un índice de la base de datos tiene varias columnas, si consultas solo por las columnas iniciales del índice y la respuesta está en las demás columnas indexadas, la base de datos puede resolverlo usando solo el índice, sin consultar la tabla original, y eso acelera el trabajo. → Entonces, como en el vuelo de regreso había poca gente, abrió la laptop e implementó los covering indexes de SQLite sobre el Atlántico.

B-Trees and The Art of Computer Programming

• Tuvo que construir muchas cosas por su cuenta. Nadie le había enseñado nunca B-Trees. Solo había oído hablar de ellos.
• Cuando intentó desarrollar su propio B-Tree, encontró en su librero TAOCP de Don Knuth, buscó B-Trees ahí y vio que el libro explicaba el algoritmo.
• Lo curioso es que el libro explica en detalle los algoritmos de búsqueda e inserción para B-Trees, pero no da el algoritmo de borrado. Eso aparece como ejercicio al final del capítulo, así que tuvo que resolver el problema antes de poder hacer su propio B-Tree. “Gracias, Don, muchas gracias.”
• La gente de hoy al menos debería leer o por lo menos hojear TAOCP.

Freedom to Build It Yourself : la libertad de construirlo tú mismo

• SQLite no depende de nada que Richard no haya hecho él mismo (salvo el compilador de C y libc). Incluso hizo su propio sistema de control de versiones y su bug tracker. Eso le da libertad.
• La libertad significa poder cuidarte por ti mismo.
• Cuando la gente se va de mochilazo y carga en la espalda todo lo que necesita, dicen que son libres porque pueden ocuparse por sí mismos.
• Si construyes todo tú mismo, hay una libertad en eso porque no quedas atado a nadie.
• Si SQLite 2 hubiera elegido Berkeley DB como motor de almacenamiento, → en ese momento Berkeley DB era open source, pero después fue vendida a Oracle y terminó en un modelo privativo de doble licencia, así que ya no podías obtener el código fuente más reciente sin pagar licencias.
• Hoy el parser generator de SQLite no usa Yacc ni Bison, sino uno hecho por él mismo llamado Lemon, y gracias a eso pudo modificarlo cuando necesitó nuevas funciones del lenguaje sin quedar atado a esas herramientas.
• A inicios de los 2000 todos los proyectos usaban CVS, así que ellos también, pero a mediados de esa década empezaron a aparecer las ideas de control de versiones distribuido.

Construcción de Fossil

• Miró Git y Mercurial, definió sus requisitos y decidió desarrollar él mismo un sistema de control de versiones.
• Ahora Fossil funciona bien y se convirtió en su propio proyecto.
• Como Torvalds creó Git para apoyar el desarrollo del kernel de Linux, si trabajas con el kernel de Linux, Git es el sistema de control de versiones perfecto.
• Fossil es el sistema de control de versiones ideal para trabajar en SQLite. Como él mismo lo hizo, cumple exactamente con sus requisitos.
• Al desarrollarlo él mismo, puede controlar su propio destino, tener más libertad y no depender de terceros.

Ser autosuficiente

• ¿Cómo llamas a alguien que se va fuera de la ciudad a cultivar su propia comida y vivir por su cuenta? ¿Survivalist? ¿O prepper? “Como habrás notado incluso mientras estábamos en contacto, mi Gmail anda medio raro. Los correos rebotan todo el tiempo. Así que estoy pensando en montar mi propio servidor de correo. Incluso mientras organizábamos esta reunión estaba tomando notas sobre eso. No debería ser más difícil que escribir un motor de base de datos, pero no quiero quedar atado a Gmail. No quiero que ellos controlen mi destino. No quiero que controlen el registro de todas mis conversaciones. Quiero tener el control yo mismo, así que aunque sea doloroso y haya mucho por hacer, voy a intentar encontrar una solución que yo pueda controlar. Puedo alquilar una máquina virtual en la nube y correrlo ahí sin depender de terceros.”
• Si alguien llega y te dice que va a resolver tu problema, debes entender que probablemente también va a quitarte tu libertad. “Si quieres ser libre, tienes que hacerlo tú mismo.”

Consejo para otras personas

• Yo empecé con la loca idea de crear un motor de base de datos que leyera y escribiera directamente en disco sin necesitar un servidor.
• Si se lo preguntas a los expertos, te dirán: “Eso es imposible. Nunca va a funcionar. Es una idea tonta.”
• Por suerte, yo no conocía a esos expertos, así que simplemente lo hice, y pasó todo esto.
• No escuches demasiado a los expertos; haz lo que tenga sentido. Resuelve tu problema.

--

[1] Bus Factor: un indicador del riesgo de que el equipo entre en crisis si un miembro es atropellado por un autobús.

• Es una métrica del riesgo que surge cuando la información y las funciones no están compartidas entre los miembros del equipo.
• Cuanto más alto es este índice, más se comparte el conocimiento y menos se concentra el trabajo en una sola persona.

[2] DO-178B: Software Considerations in Airborne Systems and Equipment Certification.

• Adoptado por la FAA como método para demostrar conformidad en la certificación de software aeronáutico.

[3] MCDC: Modified Condition / Decision Coverage

• Un método para diseñar casos de prueba donde, cuando hay varias condiciones, cada condición individual afecta de forma independiente el resultado de la condición total, sin quedar influida por las demás.

[enowy]

Había un texto tan bueno como este. Qué bueno poder leerlo en una versión traducida.

[mkeasy]

Es un texto que me hace volver a leerlo una y otra vez. Gracias.

Si quieres ser libre, tienes que hacerlo tú mismo.

Haz un trabajo que tenga sentido.

Resuelve tu propio problema.

[edunga1]

¡Es un artículo realmente interesante!

"Lograr una cobertura de pruebas del 90~95% es fácil, pero el 5% restante es realmente difícil. Pero tras hacerlo durante un año y finalmente llegar al 100%, dejaron de llegar reportes de errores desde Android"

Así que eso puede pasar.

[panarch]

Lo leí con mucho interés. ¡Gracias!

[jsryu]

Se leyó muy bien. Gracias.

[falconer]

Lo leí con mucho interés.

[gmlwo530]

¡Lo leí con gusto!

[kwangyeol]

Lo leí con gusto. Gracias.

[baeba]

Lo leí muy bien.

Parece que resumirlo y organizarlo sería todavía más difícil.

[shaichoi]

Lo leí con mucho interés. Me deja pensando bastante. Gracias :)

[fureweb]

Lo leí con mucho gusto. ¡Gracias!

[kalihman]

Lo leí con gusto.

[jongpak]

Lo leí sin darme cuenta de cómo se me fue el tiempo jaja

Ahora hasta me da vergüenza haber subestimado a SQLite por pensar que era una simple DB embebida ^^;

[sixmen]

Lo usé pensando que era solo un DBMS simple para desarrollo local, ¡pero resulta que para nada es algo simple!

[nicewook]

Lo leí con muchísimo gusto.

[xguru]

Actualmente hay más de 1 billón de instancias de SQLite operando en todo el mundo.

• Más de 4 mil millones de smartphones (Android, iOS)

• Mac/Windows

• Navegadores FF/Chrome/Safari

• PHP/Python

• Skype/iTunes/Dropbox/Turbotax

• La mayoría de los decodificadores y televisores

• Los sistemas multimedia de la mayoría de los automóviles

https://www.sqlite.org/mostdeployed.html