SQLite : 35 % plus rapide que le système de fichiers

 (sqlite.org)
15 points par GN⁺ 2024-07-28 | 4 commentaires | Partager sur WhatsApp
  • SQLite peut lire et écrire de petits BLOB (par ex. des images miniatures) 35 % plus rapidement que si on les lit ou les écrit comme fichiers individuels avec fread() ou fwrite()
  • Une base de données SQLite unique stockant des BLOB de 10 Ko utilise aussi environ 20 % d’espace disque en moins que le stockage des BLOB sous forme de fichiers individuels
  • L’écart de performance semble venir du fait que, lors de l’utilisation d’une base SQLite, les appels système open() et close() ne sont effectués qu’une seule fois, alors qu’avec des BLOB stockés dans des fichiers individuels, open() et close() sont appelés une fois pour chaque BLOB. Le surcoût de open() et close() semble supérieur au surcoût lié à l’utilisation de la base de données
  • La réduction de taille vient du fait que les fichiers individuels sont remplis jusqu’au multiple supérieur de la taille de bloc du système de fichiers, tandis que les BLOB sont empaquetés plus densément dans une base SQLite

Points d’attention

  • Le chiffre de 35 % est approximatif. Les mesures réelles varient selon le matériel, le système d’exploitation et les détails de l’expérience, et il existe aussi des variations aléatoires de performance sur du matériel réel
  • Ce chiffre de 35 % provient de tests exécutés sur tous les systèmes facilement accessibles à l’auteur. Certains relecteurs ont signalé que, sur leurs systèmes, SQLite présentait une latence plus élevée que l’I/O direct. La raison de cet écart n’est pas encore comprise
  • SQLite semble moins performant que l’I/O direct lorsque les expériences sont exécutées avec un cache du système de fichiers froid
  • Ce document remet en cause l’hypothèse générale selon laquelle une base de données relationnelle devrait être plus lente qu’un I/O direct sur le système de fichiers
  • Selon une étude de 2022, dans des charges de travail réelles, SQLite s’est montré environ 2 fois plus rapide que Btrfs et Ext4 sous Linux

Méthode de mesure

  • Les performances I/O ont été mesurées avec le programme kvtest.c de l’arborescence source de SQLite
  • Pour compiler ce programme de test, il faut rassembler le fichier source kvtest.c dans un répertoire avec les fichiers source amalgamés de SQLite, sqlite3.c et sqlite3.h, puis exécuter sous Unix une commande similaire à la suivante
  • Le programme kvtest ainsi obtenu est utilisé pour créer une base de test composée de 100 000 BLOB aléatoires non compressés, chacun ayant une taille comprise entre 8 000 et 12 000 octets
  • Pour créer une copie de tous les BLOB sous forme de fichiers individuels dans un répertoire, on peut exécuter la commande export avec l’option de ligne de commande --tree
  • Les commandes suivantes sont utilisées pour mesurer les performances de lecture des BLOB dans la base de données et des BLOB dans des fichiers individuels
  • Avec l’option --blob-api, SQLite peut charger le contenu des BLOB en utilisant la fonction sqlite3_blob_read() au lieu d’exécuter des instructions SQL, ce qui rend le test de lecture légèrement plus rapide

Mesure des performances de lecture

  • Sous Windows10, SQLite peut lire le contenu depuis la base de données environ 5 fois plus vite qu’une lecture directe depuis le disque
  • Sur Android, SQLite est environ 35 % plus rapide qu’une lecture depuis le disque
  • Lors d’une lecture depuis une base de données mappée en mémoire avec sqlite3_blob_read(), SQLite est 2 fois plus rapide que la lecture de fichiers individuels sur disque sur Mac et Android, et 10 fois plus rapide sous Windows

Mesure des performances d’écriture

  • Sur tous les systèmes, les performances d’écriture sont 5 à 15 fois plus lentes que les performances de lecture, aussi bien pour l’I/O direct que pour SQLite
  • Dans le test d’écriture, le logiciel antivirus a très peu d’effet sur les écritures SQLite, mais rend les écritures directes sur disque environ 10 fois plus lentes
  • Cela vient probablement du fait que SQLite ne modifie qu’un seul fichier de base de données, alors qu’une écriture directe sur disque modifie des milliers de fichiers individuels que l’antivirus doit inspecter

Résultats généraux

  • SQLite est compétitif, en lecture comme en écriture, face à des BLOB stockés dans des fichiers distincts sur disque, et il est généralement plus rapide
  • SQLite est nettement plus rapide que l’écriture directe sur disque sous Windows lorsque la protection antivirus est activée
  • Les lectures sont environ 10 fois plus rapides que les écritures sur tous les systèmes, aussi bien avec SQLite qu’avec l’I/O direct sur disque
  • Les performances I/O varient fortement selon le système d’exploitation et le matériel. Il faut effectuer ses propres mesures avant d’en tirer des conclusions
  • Certains autres moteurs de base de données SQL conseillent aux développeurs de stocker les BLOB dans des fichiers séparés, puis d’enregistrer les noms de fichier dans la base. Dans ce cas, stocker l’intégralité des BLOB dans la base offre, avec SQLite, des performances de lecture et d’écriture bien supérieures

L’avis de GN⁺

  • Il est très intéressant de voir que SQLite surpasse la lecture et l’écriture de fichiers individuels. Cela semble pouvoir aider à améliorer les performances des applications qui utilisent une base de données
  • Toutefois, ces résultats de benchmark ne s’appliquent pas nécessairement de manière générale à toutes les situations. Ils peuvent varier selon la nature des données, les modèles d’accès, la configuration matérielle, etc. Pour une application critique, il est important d’effectuer des benchmarks avec une charge de travail réelle
  • SQLite présente aussi l’avantage d’échapper aux analyses antivirus. Cela peut être particulièrement utile pour les applications qui manipulent un grand nombre de petits fichiers
  • L’inconvénient de SQLite est que toutes les données sont stockées dans un seul fichier ; si ce fichier de base de données est corrompu, toutes les données peuvent être perdues. Il est donc important de sauvegarder régulièrement le fichier de base de données

À lire aussi

4 commentaires

 
iolothebard 2024-07-28

À moins d’inclure dans la base de données l’accès aux attributs des fichiers (nom de fichier, taille, permissions d’accès, …),
sinon ne faudrait-il pas comparer avec les E/S par blocs plutôt qu’avec les E/S de fichiers…
Quoi qu’il en soit, SQLite est effectivement rapide.
 
GN⁺ 2024-07-28
Avis sur Hacker News

  • Il n’y a pas d’attributs ni de métadonnées du système de fichiers, donc pas besoin d’écritures ou de mises à jour d’attributs supplémentaires, ni de vérification de fichiers physiques, de pipes ou de liens symboliques, de contrôle des permissions, ou de désalignement avec la taille des blocs ; une seule commande d’ouverture suffit

    • C’est compréhensible quand on abandonne des fonctionnalités et qu’on ignore une conception généraliste
    • Si on utilise un mapping FUSE pour SQLite et qu’on monte un répertoire pour y accéder, les performances peuvent être similaires ou plus lentes
    • En désactivant les attributs et en créant un système de fichiers personnalisé avec une taille de blocs optimisée, on peut obtenir des performances comparables
    • Il y a la simplicité de pouvoir parcourir et manipuler les fichiers avec des commandes shell comme rsync
    • SQLite convient bien aux ressources statiques packagées ou aux applications de type appliance

  • Une amélioration de vitesse par 4 sous Windows 10 souligne à quel point les appels au système de fichiers de Windows sont lents

  • Quelqu’un a eu l’idée d’enregistrer en temps réel toutes les notes jouées par un piano numérique

    • En utilisant SQLite, tout est stocké dans une table unique où chaque ligne correspond à un événement MIDI du piano
    • Les performances sont bonnes et cela permet une analyse ultérieure

  • Il était intéressant, dans un laboratoire de recherche sur les bases de données, de comparer cela aux recherches sur les OS

    • Les bases de données relationnelles sont optimisées pour de petits enregistrements individuels et pour la cohérence
    • Les performances chutent fortement à mesure que la taille des lignes augmente

  • Certains envisagent d’ajouter à une base sqlite en mode WAL2

    • Il y a presque aucune pénalité en écriture et de gros avantages pour la lecture et l’analyse

  • Dans une base de données SQLite, les appels système open() et close() ne sont effectués qu’une seule fois

    • Cela entraîne moins de surcharge que l’utilisation de blobs dans des fichiers individuels

  • Il n’est pas recommandé de stocker des fichiers à l’aide de champs blob dans une base SQLite

    • La taille maximale d’un blob est de 2 Go
    • Il faut sérialiser/désérialiser les objets en octets
    • Il faut des fichiers pour interagir avec d’autres systèmes/services
    • SQLite a des configurations pour gérer des requêtes parallèles, mais la base se verrouille à cause des requêtes concurrentes

  • Le fait qu’un système construit au-dessus du système de fichiers soit plus rapide que le système de fichiers signifie surtout que le système de fichiers est lent lorsqu’il est utilisé d’une manière non optimisée

  • Supprimer beaucoup de lignes dans une base de données SQLite est plus lent que supprimer des fichiers

  • Tous les accès aux systèmes de fichiers/lecteurs sont gérés par l’OS

    • Le fichier de base de données est stocké sur le disque en clusters
    • Le système de gestion de base de données est conçu de manière pratique pour résoudre un domaine et des problèmes spécifiques
 
halfenif 2024-07-28

Il y a 20 ans, j’ai utilisé avec succès une architecture consistant à stocker des fichiers en BLOB dans une base Oracle... mais il fallait à chaque fois en expliquer les avantages aux gens. Bien sûr, ça ne marchait pas toujours.
 
narusas 2024-07-29

Il y a 20 ans, le prix des SAN DISK d’Oracle ne devait pas être donné..