Qu'est-ce qu'une taille maximale réaliste et réelle pour une base de données SQLite?
Selon cet article sur tilisations appropriées pour SQLite il indique que, alors que SQLite est limité à 140 téraoctets , un client/serveur Le SGBDR peut mieux fonctionner:
Une base de données SQLite est limitée en taille à 140 téraoctets (247 octets, 128 tibioctets). Et même s'il pouvait gérer des bases de données plus importantes, SQLite stocke la base de données entière dans un seul fichier disque et de nombreux systèmes de fichiers limitent la taille maximale des fichiers à quelque chose de moins. Donc, si vous envisagez des bases de données de cette ampleur, vous feriez bien d'envisager d'utiliser un moteur de base de données client/serveur qui répartit son contenu sur plusieurs fichiers disque, et peut-être sur plusieurs volumes.
En général, je suis d'accord avec cela, mais j'ai été surpris d'apprendre que la limite maximale de SQLite était si élevée! D'après mon expérience, j'ai utilisé pas mal de bases de données SQL Server d'une taille de ~ 30-100 Go. J'ai également travaillé indirectement avec des bases de données beaucoup plus grandes utilisant Oracle, Postgres ou Cassandra. Parmi ceux-ci, du moins à ma connaissance, aucun ne s'approchait de 140 To. Je ne suis pas un DBA, c'est donc ce que je considérerais comme "grand" d'après mon expérience directe.
Je n'ai considéré SQLite que pour les situations où la base de données serait minuscule; des dizaines de mégaoctets tout au plus.
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. Mais je me demande si j'ai sous-estimé ses capacités. Qu'est-ce qu'une limite de taille maximale réaliste pour une base de données SQLite en utilisation réelle?
La limite réaliste (de la taille d'une base de données Sqlite) est identique à la limite réaliste d'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 si grand .sqlite fichier, 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) de beaucoup 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 disponible RAM (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 un poste de travail coûteux (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 Je ne le ferai peut-être que si un (ou très peu) processus accède à cette base de données. Si vous avez une douzaine de processus accédant simultanément à la même base de données, mieux installer un vrai SGBDR SQL (à la MariaDB ou PostGreSQL)
Notez également que si le format (binaire) de .sqlite les fichiers de base de données sont documentés comme étant "portables", 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 gros fichiers indexés en utilisant GDBM .
PPS. Dans ma expjs branche (sept.2016) de mon moniteur MELT (logiciel libre GPLv3, sur github), je suis persistant le tas d'application entier 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.