En busca de un SQLite más rápido

• SQLite ya es un sistema de base de datos rápido, pero los investigadores están buscando formas de hacerlo aún más rápido.
• Investigadores de la Universidad de Helsinki y Cambridge publicaron el artículo "Codesarrollo de runtime/serverless y base de datos mediante I/O asíncrona", mostrando que es posible reducir la latencia de cola hasta 100 veces. Este trabajo sirve como base de Limbo, una reescritura de SQLite en Rust.

io_uring

• Explicación de io_uring: El subsistema io_uring del kernel de Linux proporciona una interfaz para I/O asíncrona. Esto reduce la sobrecarga de copia de buffers mediante un ring buffer entre el espacio de usuario y el espacio del kernel. Las aplicaciones pueden enviar solicitudes de I/O y seguir realizando otras tareas hasta recibir del sistema operativo la notificación de que la operación terminó.

• Ejecución de consultas en SQLite: SQLite usa archivos para almacenar datos, abre la base de datos con la función sqlite3_open() y convierte las sentencias SQL a bytecode con la función sqlite3_prepare(). La función sqlite3_step() ejecuta las instrucciones de bytecode para procesar la consulta.

Premisa

• Ascenso del cómputo serverless: En entornos serverless, la latencia de la base de datos puede volverse un problema. Si la base de datos se integra directamente en el runtime del edge, no hay latencia de red, y SQLite encaja bien en este tipo de entorno.

• Problemas de SQLite: El uso de I/O síncrona impide optimizar por completo el uso de recursos y provoca problemas de concurrencia y multitenencia.

• Transición a io_uring: Reemplazar las llamadas de I/O POSIX por io_uring no es sencillo; SQLite debe rediseñarse para ajustarse a un modelo de I/O asíncrona.

Limbo

• Soporte para I/O asíncrona: Se modificaron los componentes VM y BTree para admitir I/O asíncrona, sustituyendo las instrucciones síncronas de bytecode por instrucciones asíncronas. La I/O asíncrona elimina bloqueos y mejora la concurrencia.

• Separación entre consultas y motor de almacenamiento: Se propone separar el motor de consultas y el motor de almacenamiento para maximizar el uso de recursos.

Evaluación y resultados

• Benchmarking: Se simuló un runtime serverless multi-tenant para que cada tenant tuviera su propia base de datos embebida. Al comparar la latencia de consultas entre SQLite y Limbo, Limbo redujo la latencia de cola en p999 hasta 100 veces.

• Trabajo futuro: Se planean benchmarks adicionales con múltiples lectores y escritores, y la ventaja de rendimiento solo destaca de forma clara a partir de p999.

• Código open source: El código de Limbo está disponible como open source: Limbo GitHub

[GN⁺]

Opiniones de Hacker News

• Hay una discusión sobre cómo ciertos casos de uso de la computación serverless, por ejemplo AWS Lambda y una base de datos central, no siempre encajan bien con apps construidas de forma serverless

  • Hace 6-7 años trabajé resolviendo un problema en el que había que procesar archivos jerárquicos complejos y extraer cierta información
  • FaaS resulta caro para tareas computacionalmente costosas, y cargar y parsear archivos XML grandes cada vez era ineficiente
  • Como solución, se usó una función central con temporizador que leía y parseaba los archivos, los cargaba e indexaba en una base de datos SQLite, y luego guardaba el archivo en S3
  • La función Lambda descargaba el archivo desde S3 para hacer consultas cuando era más reciente que la copia local o durante un cold start
  • Descubrí que Lambda tiene un directorio local /tmp y que el runtime de Python incluye SQLite, así que no hacía falta subir código adicional aparte de la función
  • Me parece interesante que se esté trabajando en hacer este tipo de solución aún más rápida

• Puede valer la pena aclarar que uno de los dos investigadores es el jefe del autor

  • Me equivoqué al pensar que el autor y los investigadores no estaban relacionados

• Estoy de acuerdo con que "las ventajas solo se notan a partir de p999, y en p90 y p99 el rendimiento es casi igual al de SQLite"

  • Me gusta SQLite y me gustan las optimizaciones, pero eso es cierto

• SQLite tiene una suite de pruebas muy amplia, así que está probado a fondo

  • Me pregunto si una reescritura recibirá pruebas similares, especialmente si usa funciones rápidas pero difíciles de desarrollar y potencialmente propensas a errores, como io_uring

• Para el benchmarking se simuló un runtime serverless multitenant en el que cada tenant tiene su propia base de datos embebida

  • SQLite tiene su propio hilo por tenant, y se mide ejecutando consultas en cada hilo
  • Me pregunto si una configuración serverless de SQLite usaría un proceso de SQLite por solicitud

• Antes hubo intentos de introducir async io en Postgres, pero se abandonaron

  • Una propuesta reciente busca permitir reemplazar el storage manager por uno personalizado sin necesidad de hacer fork del codebase
  • Hay mucho interés en la nueva propuesta, y se relaciona con el movimiento de separar storage y cómputo

• Hay una pregunta sobre la idea de poder hacer otro trabajo mientras async io está en funcionamiento

  • Me pregunto si, al trabajar con bases de datos, de todos modos hay que esperar a que termine la transacción

• Como autor de la entrada del blog, no esperaba que este artículo llegara a la portada

  • Trabajo en Turso; el paper se publicó en abril de 2024 y desde entonces se han hecho muchas mejoras

• SQLite es open source, pero el test harness importante no lo es

  • Hay una pregunta sobre cómo garantizarán la compatibilidad las alternativas

• Intenté encontrar una forma simple de crear un formato parecido a JSON como subconjunto estricto del formato de archivo de SQLite, pero fracasé

  • Hay bastante arbitrariedad en el formato de archivo, así que perdí el interés, aunque otra persona podría tener éxito