SQLite: 35% más rápido que el sistema de archivos

 (sqlite.org)
15 puntos por GN⁺ 2024-07-28 | 4 comentarios | Compartir por WhatsApp
  • SQLite puede leer y escribir pequeños BLOBs (por ejemplo, imágenes en miniatura) un 35% más rápido que leerlos o escribirlos como archivos individuales con fread() o fwrite()
  • Además, una sola base de datos SQLite que almacena BLOBs de 10 KB usa aproximadamente un 20% menos de espacio en disco que guardar esos BLOBs como archivos individuales
  • La diferencia de rendimiento parece deberse a que, al trabajar con una base de datos SQLite, las llamadas al sistema open() y close() se invocan solo una vez, mientras que al usar BLOBs en archivos individuales se invocan una vez por cada BLOB. El overhead de open() y close() parece ser mayor que el overhead de usar la base de datos
  • La reducción de tamaño ocurre porque los archivos individuales se rellenan hasta el siguiente múltiplo del tamaño de bloque del sistema de archivos, mientras que los BLOBs quedan empaquetados de forma más compacta dentro de la base de datos SQLite

Consideraciones

  • La cifra de 35% es aproximada. Los tiempos reales varían según el hardware, el sistema operativo y los detalles del experimento, y existe variación aleatoria de rendimiento en hardware real
  • La cifra de 35% proviene de ejecutar pruebas en todos los sistemas a los que el autor tenía fácil acceso. Algunos revisores reportaron que, en sus sistemas, SQLite tuvo mayor latencia que la E/S directa. Aún no se entiende esa diferencia
  • SQLite no parece rendir tan bien como la E/S directa cuando el experimento se ejecuta con una caché fría del sistema de archivos
  • Este documento contradice la suposición general de que una base de datos relacional debería ser más lenta que la E/S directa del sistema de archivos
  • Según una investigación de 2022, en cargas de trabajo reales SQLite resultó aproximadamente 2 veces más rápido que Btrfs y Ext4 en Linux

Cómo se midió

  • El rendimiento de E/S se midió usando el programa kvtest.c del árbol de código fuente de SQLite
  • Para compilar este programa de prueba, hay que reunir el archivo fuente kvtest.c en un directorio junto con los archivos fuente amalgamados de SQLite sqlite3.c y sqlite3.h, y luego ejecutar en Unix un comando similar al siguiente
  • El programa kvtest resultante se usa para crear una base de datos de prueba compuesta por 100,000 BLOBs aleatorios sin comprimir, con tamaños entre 8,000 y 12,000 bytes cada uno
  • Para crear copias de todos los BLOBs como archivos individuales dentro de un directorio, se puede ejecutar el comando export usando la opción de línea de comandos --tree
  • Para medir el rendimiento al leer BLOBs desde la base de datos y desde archivos individuales, se usan los siguientes comandos
  • Si se usa la opción --blob-api, SQLite puede cargar el contenido de los BLOBs con la función sqlite3_blob_read() en lugar de ejecutar sentencias SQL, lo que hace que la prueba de lectura corra un poco más rápido

Medición del rendimiento de lectura

  • En Windows10, SQLite puede leer contenido desde la base de datos alrededor de 5 veces más rápido que leerlo directamente desde el disco
  • En Android, SQLite es aproximadamente un 35% más rápido que leer desde el disco
  • Al leer desde una base de datos mapeada en memoria usando sqlite3_blob_read(), en Mac y Android es 2 veces más rápido que leer archivos individuales desde el disco, y en Windows es 10 veces más rápido

Medición del rendimiento de escritura

  • En todos los sistemas, tanto la E/S directa como SQLite tienen un rendimiento de escritura entre 5 y 15 veces más lento que el de lectura
  • En las pruebas de escritura, el software antivirus casi no afecta las escrituras en SQLite, pero escribir directamente al disco se vuelve unas 10 veces más lento
  • Esto probablemente se deba a que SQLite solo modifica un único archivo de base de datos, mientras que escribir directamente al disco modifica miles de archivos individuales que el antivirus debe inspeccionar

Resultados generales

  • SQLite es competitivo frente a los BLOBs almacenados en archivos separados, tanto en lectura como en escritura, y por lo general es más rápido
  • SQLite es mucho más rápido que escribir directamente al disco en Windows cuando la protección antivirus está activada
  • La lectura es aproximadamente 10 veces más rápida que la escritura en todos los sistemas, tanto para SQLite como para la E/S directa al disco
  • El rendimiento de E/S varía mucho según el sistema operativo y el hardware. Es necesario hacer mediciones propias antes de sacar conclusiones
  • Algunos otros motores de bases de datos SQL aconsejan a los desarrolladores guardar los BLOBs en archivos separados y luego almacenar el nombre del archivo en la base de datos. En ese caso, guardar el BLOB completo dentro de la base de datos ofrece un rendimiento de lectura y escritura mucho mejor en SQLite

Opinión de GN⁺

  • Es muy interesante que el rendimiento de SQLite sea superior al de leer y escribir archivos individuales. Esto parece poder ayudar a mejorar el rendimiento de aplicaciones que usan bases de datos
  • Sin embargo, estos resultados de benchmark no se aplican de forma general a todas las situaciones. Pueden variar según las características de los datos, los patrones de acceso, la configuración del hardware, etc. En aplicaciones importantes, es fundamental hacer benchmarks con cargas de trabajo reales
  • Además, SQLite tiene la ventaja de poder evitar las inspecciones del antivirus. Esto puede ser especialmente útil en aplicaciones que manejan grandes cantidades de archivos pequeños
  • La desventaja de SQLite es que todos los datos se almacenan en un solo archivo, por lo que si el archivo de base de datos se corrompe, todos los datos pueden perderse. Por eso es importante hacer copias de seguridad periódicas del archivo de base de datos

Lecturas relacionadas

4 comentarios

 
iolothebard 2024-07-28

Si la base de datos incluye incluso el acceso a los atributos del archivo (nombre, tamaño, permisos de acceso, …),
si no, me parece que habría que compararlo no con entrada/salida de archivos sino con entrada/salida de bloques…
De una forma u otra, SQLite sí que es rápido.
 
GN⁺ 2024-07-28
Opiniones en Hacker News

  • No hay atributos ni metadatos del sistema de archivos, así que no se necesita registrar o actualizar atributos adicionales, y como no hay verificación de archivos físicos, pipes/enlaces simbólicos, comprobaciones de permisos ni desajustes de alineación por tamaño de bloque, solo se necesita una sola llamada a open

    • Es entendible cuando se sacrifican funciones y se ignora un diseño de propósito general
    • Si se usa un mapeo FUSE para SQLite y se monta un directorio para acceder, el rendimiento puede ser similar o incluso peor
    • Si desactivas atributos y creas un sistema de archivos personalizado con un tamaño de bloque optimizado, puedes obtener un rendimiento parecido
    • Existe la simplicidad de poder explorar y manipular archivos usando comandos de shell como rsync
    • SQLite es adecuado para activos estáticos empaquetados o aplicaciones tipo appliance

  • El aumento de velocidad de 4x en Windows 10 resalta qué tan lentas son las llamadas al sistema de archivos de Windows

  • Surgió la idea de registrar en tiempo real todas las notas producidas por un piano digital

    • Usando SQLite, se guarda en una sola tabla donde cada fila es un evento MIDI del piano
    • El rendimiento es bueno y luego se puede analizar

  • Fue interesante compararlo con la investigación de sistemas operativos en un laboratorio de bases de datos

    • Las bases de datos relacionales están optimizadas para registros individuales pequeños y consistencia
    • A medida que aumenta el tamaño de las filas, el rendimiento cae drásticamente

  • Están considerando agregar a una DB de SQLite en modo WAL2

    • Casi no hay penalización en rendimiento de escritura y hay grandes ventajas para lectura/análisis

  • En una base de datos SQLite, las llamadas al sistema open() y close() solo se invocan una vez

    • Hay menos sobrecarga que al usar blobs en archivos individuales

  • No se recomienda guardar archivos usando campos BLOB en SQLite

    • El tamaño máximo de un BLOB es de 2 GB
    • Hay que serializar/deserializar los objetos a bytes
    • Para interactuar con otros sistemas/servicios se necesitan archivos
    • SQLite tiene configuraciones para manejar solicitudes en paralelo, pero la base de datos se bloquea por solicitudes en competencia

  • Que algo construido sobre un sistema de archivos sea más rápido que el sistema de archivos significa que este es lento cuando se usa de una manera no optimizada

  • Eliminar muchas filas en una base de datos SQLite es más lento que borrar archivos

  • Todo acceso a sistemas de archivos/unidades es administrado por el OS

    • El archivo de la base de datos se guarda en el disco en clústeres
    • Los sistemas de gestión de bases de datos se crean por conveniencia para resolver dominios y problemas específicos
 
halfenif 2024-07-28

Hace 20 años usé bien una arquitectura donde se guardaban archivos como blobs en Oracle DB... pero cada vez tenía que explicarle a la gente sus ventajas. Claro que no siempre lo lograba.
 
narusas 2024-07-29

Hace 20 años, los discos SAN de Oracle no deben haber sido nada baratos...