Selon cet article sur les utilisations appropriées de SQLite, il indique que, bien que SQLite soit limité à 140 téraoctets , un SGBDR client / serveur peut mieux fonctionner:
Une base de données SQLite est limitée en taille à 140 téraoctets (2 47 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 que cela. 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 source
Réponses:
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 .. .)
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
.sqlitefichier 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
.sqlitefichiers 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 utilisantsqlite3 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.
la source