La limite réaliste (de la taille d'une base de données Sqlite) est la même que la limite réaliste pour un fichier de données. Et cette limite dépend beaucoup de votre ordinateur et de votre système. Sur mon bureau Linux actuel, je ne peux pas me permettre beaucoup plus gros qu'un fichier de 350 Go (car en règle générale, j'évite qu'un seul fichier ne consomme plus de la moitié d'une partition de disque). BTW, cette limite pratique a également un impact sur d'autres SGBDR SQL comme PostGreSQL ou MariaDB (mais la plupart d'entre eux conservent des données dans plusieurs fichiers, que vous pouvez conserver sur différents systèmes de fichiers, et certains d'entre eux sont capables de gérer des données distribuées sur des machines distantes .. .)
Après avoir lu cet article, je ne suis toujours pas convaincu de considérer SQLite pour tout ce qui pourrait nécessiter des centaines de gigaoctets
Vous avez raison et tort.
Vous avez raison, car sur les ordinateurs d'aujourd'hui (ordinateurs portables et de bureau, pas les superordinateurs ou les serveurs de centres de données), une centaine de gigaoctets reste un espace disque assez important. Donc, dans la pratique, si vous pensez à une si grande base de données, vous feriez mieux d'imaginer un vrai serveur SQL (à la PostGreSQL) en particulier parce que vous voudrez très probablement un accès à distance, effectivement un accès simultané et probablement des données et des tables distribuées.
Vous vous trompez (en principe, je n'ai jamais essayé) car très probablement SQLite est capable (et parfois testé) de gérer une base de données de plusieurs centaines de gigaoctets, en supposant que vous avez un système de fichiers capable de traiter un fichier aussi volumineux (et probablement deux de au moins).
Je considérerais certainement (parfois) SQLite pour des bases de données de plusieurs dizaines de gigaoctets (et j'ai essayé une fois un .sqlite
fichier aussi volumineux , IIRC de 40 Go). Sur les machines actuelles (non supercalculatrices), j'hésiterais à avoir plusieurs centaines de gigaoctets de base de données SQLite, simplement parce qu'un tel fichier est assez volumineux selon la pratique actuelle.
IIRC un vendeur de matériel vendant des machines de systèmes de fichiers spécialisés m'a parlé une fois d'une application sqlite téraoctet (mais je peux me tromper).
Bien sûr, les performances de SQLite dépendent (comme toutes les bases de données SQL) d' une grande partie du nombre et de la largeur des tables, de leurs index, des requêtes SQL impliquées. Et vous ne voulez pas avoir un accès simultané (par de nombreux processus différents), et vous devez utiliser la transaction (par expérience, même sur une petite base de données SQLITE de quelques mégaoctets, vous voulez vraiment envelopper vos milliers de demandes d'insertion par exemple avec BEGIN TRANSACTION
& END TRANSACTION
, ne pas faire cela ralentit Sqlite par un facteur important (plus de 10x)).
Et par expérience personnelle, avec une configuration et une organisation appropriées, SQLite est capable de gérer une base de données plus grande que la RAM disponible (donc 30 Go n'est pas un problème) - mais vous voulez probablement que les index tiennent dans la RAM!
S'il vous arrive de coder quelque chose pour un "supercalculateur" ou une station de travail coûteuse (avec par exemple 512 Go de RAM et 8 To de disque et 512 Go de SSD), vous pouvez certainement avoir une base de données Sqlite de téraoctets. Mais vous ne voudrez peut-être le faire que si un (ou très peu) processus accède à cette base de données. Si vous avez une dizaine de processus accédant simultanément à la même base de données, mieux vaut installer un vrai SGBDR SQL (à la MariaDB ou PostGreSQL)
Notez également que bien que le format (binaire) des .sqlite
fichiers de base de données soit documenté comme étant "portable", je préfère de loin sauvegarder les bases de données au format textuel SQL (en utilisant sqlite3 mydb.sqlite .dump > mydb.sql
). Ensuite, j'ai également besoin d'espace disque supplémentaire pour ce vidage textuel (et cela abaisse la limite réaliste).
Sqlite n'est généralement pas le goulot d'étranglement. Mais le disque pourrait l'être.
PS Le même raisonnement pourrait être appliqué aux fichiers indexés volumineux à l'aide de GDBM .
PPS. Dans ma branche expjs (septembre 2016) de mon moniteur MELT (logiciel gratuit GPLv3, sur github), je persiste le tas d'application complet en JSON dans une nouvelle base de données Sqlite. J'ai fait de minuscules expériences avec plusieurs millions d'objets (assez "gros") sans mauvaises surprises. YMMV.