Qu'est-ce qu'une taille maximale réaliste et réelle pour une base de données SQLite?


34

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?


3
Je pense simplement que nous devons généralement tenir compte du nombre de connexions simultanées, car les grands ensembles de données sont souvent supposés être consommés par plusieurs utilisateurs. Il existe un moyen pour vous de tester cela sur votre propre système n'est-ce pas?
JeffO

3
Pour quelque chose comme une base de données de transactions archivées qui n'a pratiquement jamais besoin d'être consultée, SQLite peut être un excellent choix, et il n'y aura qu'un seul utilisateur à la fois (le cas échéant), et vous n'avez pas besoin d'avoir un tout Configuration du serveur de base de données pour le prendre en charge. Si vous avez plusieurs utilisateurs simultanés, d'un autre côté, vous pouvez facilement rencontrer des problèmes de verrouillage qui gênent bien avant d'accéder à une base de données de plusieurs gig.
Michael Kohne


2
@Pacerier - oui, pour installer le logiciel. Ensuite, vous devez attribuer des rôles de base de données, comprendre comment intégrer dans votre système de sauvegarde, assurez-vous que le système de sauvegarde place le serveur DB dans l'état approprié au début et à la fin des sauvegardes, etc., etc. Il y a beaucoup plus à mettre en place un serveur db que simplement installer le logiciel. De plus, c'est un service de plus dont vous devez vous soucier du point de vue de la sécurité du réseau, et une chose de plus que vous devez suivre avec les correctifs. Si vous avez BESOIN d'un service db, allez-y bien, mais si vous n'en avez pas besoin, SQLite a beaucoup moins de frais généraux.
Michael Kohne

1
@ leeand00 - Ou vous pouvez louer un espace pour un mois.
JeffO

Réponses:


26

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 .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 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.


7
Vous auriez pu arrêter d'écrire après le quatrième paragraphe. Mais +1 quand même.
Robert Harvey

3
Peut-être, mais j'ai été désagréablement très surpris de constater que même sur une nouvelle base de données sqlite de seulement quelques mégaoctets, les transactions sont si importantes dans la pratique (avec un seul processus accédant, écrivant en fait, ce nouveau fichier).
Basile Starynkevitch

3
C'est certainement vrai pour les écritures. En pratique, il est difficile d'imaginer une base de données SQLite avec des tailles comme l'OP le décrit. Postgresql serait probablement un meilleur choix, non pas pour ses capacités de taille, mais pour la concurrence de puissance industrielle que SQLite n'a pas.
Robert Harvey

5
Il existe de nombreuses situations légitimes où vous pourriez avoir des bases de données SQLite avec des tailles de fichier énormes. Des développeurs SQLite eux-mêmes: considérez-le moins comme un remplacement pour MySql, et plus comme un remplacement pour fopen. L'écriture de certains logiciels de CAO 3D et l'utilisation de bases de données SQLite pour stocker des données sur des objets peuvent être parfaitement raisonnables.
whatsisname

2
@Pacerier: les fichiers de films et les blobs binaires similaires ne sont généralement pas stockés dans la base de données. Ils sont stockés dans le système de fichiers et les liens vers ceux-ci sont stockés dans la base de données.
Robert Harvey
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.