Dans quelle mesure SQLite est-il évolutif? [fermé]

182

J'ai récemment lu cette question sur SQLite vs MySQL et la réponse a souligné que SQLite ne s'adapte pas bien et le site Web officiel le confirme cependant.

Dans quelle mesure SQLite est-il évolutif et quelles sont ses limites supérieures?

GateKiller
la source

Réponses:

433

Hier, j'ai publié un petit site *pour suivre votre représentant qui a utilisé une base de données SQLite partagée pour tous les visiteurs. Malheureusement, même avec la modeste charge qu'il a mise sur mon hôte, il a fonctionné assez lentement. En effet, toute la base de données était verrouillée à chaque fois que quelqu'un affichait la page car elle contenait des mises à jour / insertions. Je suis rapidement passé à MySQL et même si je n'ai pas eu beaucoup de temps pour le tester, il semble beaucoup plus évolutif que SQLite. Je me souviens juste des chargements de pages lents et parfois une erreur de base de données verrouillée en essayant d'exécuter des requêtes à partir du shell dans sqlite. Cela dit, j'utilise un autre site de SQLite très bien. La différence est que le site est statique (c'est-à-dire que je suis le seul à pouvoir modifier la base de données) et qu'il fonctionne donc très bien pour les lectures simultanées. Morale de l'histoire:

edit : Je viens de réaliser que je n'ai peut-être pas été juste envers SQLite - je n'ai indexé aucune colonne dans la base de données SQLite lorsque je la servais à partir d'une page Web. Cela a en partie causé le ralentissement que je connaissais. Cependant, l'observation du verrouillage de la base de données est valable - si vous avez des mises à jour particulièrement onéreuses, les performances de SQLite ne correspondront pas à MySQL ou Postgres.

une autre modification: depuis que j'ai publié ceci il y a presque 3 mois, j'ai eu l'occasion d'examiner de près l'évolutivité de SQLite, et avec quelques astuces, il peut être assez évolutif. Comme je l'ai mentionné dans ma première modification, les index de base de données réduisent considérablement le temps de requête, mais il s'agit plus d'une observation générale sur les bases de données que sur SQLite. Cependant, il existe une autre astuce que vous pouvez utiliser pour accélérer SQLite: les transactions . Chaque fois que vous devez effectuer plusieurs écritures de base de données, placez-les dans une transaction. Au lieu d'écrire (et de verrouiller) le fichier à chaque fois qu'une requête d'écriture est émise, l'écriture n'aura lieu qu'une seule fois lorsque la transaction se termine.

Le site que je mentionne que j'ai publié dans le premier paragraphe est revenu à SQLite et il fonctionne assez bien une fois que j'ai réglé mon code à quelques endroits.

* le site n'est plus disponible

Kyle Cronin
la source
3
Le moteur de base de données "classique" de MySQL, MyISAM, a les mêmes problèmes concernant les opérations de lecture / écriture simultanées que SQLite. En fait, il verrouille chaque ligne qu'il touche lors d'une opération d'écriture, ce qui rend impossible la mise à l'échelle des applications gourmandes en écriture. Pourtant, il a très bien servi de nombreuses applications Web.
Henning
1
Pourriez-vous alors réécrire le début de votre réponse? Juger la performance de DB sans index appropriés est complètement injuste. Les transactions modifient également beaucoup les performances et l'évolutivité de SQLite.
Kornel
3
@porneL: C'est vrai, mais SQLite sans index était un ordre de grandeur plus lent que MySQL sans index, et j'ai également inclus un peu sur les transactions dans ma deuxième édition. Je pense toujours que la progression de la réponse a du sens - cela montre mon utilisation naïve initiale de SQLite et à quel point les performances étaient relativement mauvaises. Je m'attends à ce que les nouveaux utilisateurs de la plate-forme rencontrent des problèmes similaires, et j'espère qu'ils pourront s'identifier au premier paragraphe, puis lire les modifications suivantes et se rendre compte qu'il existe des moyens d'accélérer SQLite pour avoir des performances acceptables.
Kyle Cronin le
1
Pouvez-vous nous dire combien de visites par seconde environ votre site reçoit?
NoobOverflow
3
Il existe également une journalisation en écriture anticipée (WAL) disponible dans les nouvelles versions de SQLite, ce qui peut supprimer une partie de la douleur des cycles de lecture / écriture. Les choses changent.
Lasse V. Karlsen
60

Sqlite est évolutif en termes de mono-utilisateur, j'ai une base de données multi-gigaoctets qui fonctionne très bien et je n'ai pas eu beaucoup de problèmes avec elle.

Mais il s'agit d' un utilisateur unique, donc cela dépend du type de mise à l'échelle dont vous parlez.

En réponse aux commentaires. Notez que rien n'empêche d'utiliser une base de données Sqlite dans un environnement multi-utilisateurs, mais chaque transaction (en fait, chaque instruction SQL qui modifie la base de données) prend un verrou sur le fichier , ce qui empêchera d'autres utilisateurs d'accéder à la base de données à tout .

Donc, si vous avez beaucoup de modifications apportées à la base de données, vous allez essentiellement rencontrer des problèmes de mise à l'échelle très rapidement. Si, d'un autre côté, vous avez beaucoup d'accès en lecture par rapport à l'accès en écriture, ce n'est peut-être pas si grave.

Mais Sqlite fonctionnera bien sûr dans un environnement multi-utilisateurs, mais il ne fonctionnera pas bien.

Lasse V. Karlsen
la source
5
SQLite 3 prend en charge la lecture lorsque d'autres utilisateurs y écrivent.
Alix Axel
2
Notez que les commentaires ci-dessus sont obsolètes, avec le nouveau système (er) WAL, les écritures et les lectures peuvent être effectuées en même temps, augmentant ainsi l'évolutivité.
Lasse V.Karlsen
Est-il possible de créer pour exporter des enregistrements à la volée vers sqlite à partir de n'importe quel rdbms comme le serveur SQL ou Oracle, etc.?
ILoveStackoverflow
30

SQLite pilote le site Web sqlite.org et d'autres qui ont beaucoup de trafic. Ils suggèrent que si vous avez moins de 100 000 visites par jour, SQLite devrait fonctionner correctement. Et cela a été écrit avant la livraison de la fonction "Writeahead Logging".

Si vous souhaitez accélérer les choses avec SQLite, procédez comme suit:

  • mise à niveau vers SQLite 3.7.x
  • Activer la journalisation en écriture anticipée
  • Exécutez le pragma suivant: "PRAGMA cache_size = Number-of-pages;" La taille par défaut (nombre de pages) est de 2000 pages, mais si vous augmentez ce nombre, vous augmenterez la quantité de données qui sortent directement de la mémoire.

Vous voudrez peut-être jeter un œil à ma vidéo sur YouTube intitulée « Améliorer les performances de SQLite avec la journalisation en écriture » qui montre comment utiliser la journalisation en écriture anticipée et démontre une amélioration de la vitesse de 5x pour les écritures.

Jay Godse
la source
24

Sqlite est une base de données de bureau ou en cours de traitement . SQL Server, MySQL, Oracle et leurs frères sont des serveurs .

De par leur nature, les bases de données de bureau ne sont pas un bon choix pour toute application qui doit prendre en charge l'accès en écriture simultané au magasin de données. Cela inclut à un certain niveau la plupart des sites Web jamais créés. Si vous devez même vous connecter pour quelque chose, vous avez probablement besoin d'un accès en écriture à la base de données.

Joël Coehoorn
la source
5
Je ne suis pas d'accord avec le "Cela inclut à peu près tous les sites Web jamais créés." commentaire. Si le site Web est chargé, vous avez raison. Trac, par exemple, utilise SQLite par défaut et fonctionne très bien pour les petites équipes.
Andrew Burns
2
Donnez-lui du temps: vous aurez deux développeurs accéder au même champ en même temps et cela s'étouffera.
Joel Coehoorn
3
Que définissez-vous comme étranglement? d'après votre réponse, je suppose que vous n'avez pas beaucoup d'expérience avec SQLite. SQLite verrouillera le fichier entier sur les opérations afin que vous puissiez rencontrer un retard, mais il est presque impossible de le faire "s'étouffer" dans la situation que vous avez proposée.
Andrew Burns
3
Andrew, parce que SQL Lite fonctionne bien pour les petites équipes, ne le rend pas évolutif, pour évoluer, l'exigence est bien à l'échelle, ce qui signifie qu'il devrait bien fonctionner avec de grandes équipes. À ma connaissance, SQL Lite n'est pas évolutif pour les grandes équipes / opérations de base de données simultanées qui dépassent un seuil assez bas.
Pop Catalin
5
@Justice. Cette réponse n'a aucune preuve à l'appui de l'évolutivité de SQLite. La réponse de personne n'est bien meilleure.
GateKiller
23

Avez-vous lu cette documentation SQLite - http://www.sqlite.org/whentouse.html ?

SQLite fonctionnera généralement très bien comme moteur de base de données pour les sites Web à trafic faible à moyen (c'est-à-dire 99,9% de tous les sites Web). La quantité de trafic Web que SQLite peut gérer dépend, bien sûr, de la fréquence à laquelle le site Web utilise sa base de données. De manière générale, tout site qui reçoit moins de 100 000 visites / jour devrait fonctionner correctement avec SQLite. Le chiffre de 100K hits / jour est une estimation prudente, pas une limite supérieure fixe. Il a été démontré que SQLite fonctionne avec 10 fois plus de trafic.

Sam
la source
3
Je suis TRÈS d'accord avec cela. 99% des sites Web pourraient être gérés correctement avec SQLLite si vous le souhaitez. Mais, 99% du trafic Web va vers le plus grand 1% des sites Web, en revanche.
djangofan le
7
La métrique de "100k hits / jour" est complètement nul. Un "hit" est généralement défini comme un HTTP GET et un site Web avec un tas d'images découpées peut obtenir plus de 40 "hits" par page vue - rien de tout cela ne touche la base de données. Même si les documents font l'erreur de hit == pageview, c'est toujours trompeur. SQLite verrouille l'ensemble de la base de données sur une écriture. Bien qu'il puisse servir vaillamment 100000 pages vues de personnes qui parcourent simplement des enregistrements, il va s'effondrer dans une application gourmande en écriture (commerce électronique, messageboard, etc.).
jamieb
10

L'évolutivité de SQLite dépendra fortement des données utilisées et de leur format. J'ai eu une expérience difficile avec des tables extra longues (enregistrements GPS, un enregistrement par seconde). L'expérience a montré que SQLite ralentirait par étapes, en partie à cause du rééquilibrage constant des arbres binaires croissants contenant les index (et avec des index horodatés, vous savez juste que l'arbre va être rééquilibré beaucoup, mais il est vital pour votre recherches). Donc, au final, à environ 1 Go (très approximatif, je sais), les requêtes deviennent lentes dans mon cas. Votre kilométrage variera.

Une chose à retenir, malgré toutes les vantardises, SQLite n'est PAS fait pour l'entreposage de données. Il existe diverses utilisations non recommandées pour SQLite. Les bonnes personnes derrière SQLite le disent elles-mêmes:

Une autre façon de voir SQLite est la suivante: SQLite n'est pas conçu pour remplacer Oracle. Il est conçu pour remplacer fopen ().

Et cela conduit à l'argument principal (pas quantitatif, désolé, mais qualitatif), SQLite n'est pas pour tous les usages, alors que MySQL peut couvrir de nombreux usages variés, même si ce n'est pas idéalement. Par exemple, vous pourriez avoir MySQL stocker des cookies Firefox (au lieu de SQLite), mais vous auriez besoin de ce service en cours d'exécution tout le temps. D'un autre côté, vous pourriez avoir un site Web transactionnel fonctionnant sur SQLite (comme beaucoup de gens le font) au lieu de MySQL, mais attendez-vous à beaucoup de temps d'arrêt.

MPelletier
la source
1
Vous pouvez contourner le problème d'avoir de très grandes tables indexées en partageant vos données, par exemple une table par jour / semaine. SQLite vous permet même de diviser les tables en fichiers de base de données distincts, puis de les utiliser ATTACH DATABASEpour créer une connexion de base de données virtuelle avec toutes les tables (cependant limité à 62 bases de données).
Alix Axel
3

Je pense qu'un serveur Web (en nombre 1) desservant des centaines de clients apparaît sur le backend avec une seule connexion à la base de données, n'est-ce pas?

Il n'y a donc pas d'accès simultané à la base de données et nous pouvons donc dire que la base de données fonctionne en «mode mono-utilisateur». Cela n'a aucun sens de discuter de l'accès multi-utilisateur dans une telle circonstance et donc SQLite fonctionne aussi bien que toute autre base de données serveur.

La glace
la source
1
Thx GateKiller, mais veuillez spécifier "site Web à faible volume".
Ice
3

Pense-y de cette façon. SQL Lite sera verrouillé chaque fois que quelqu'un l'utilisera (SQLite ne se verrouille pas à la lecture). Donc, si vous diffusez une page Web ou une application qui a plusieurs utilisateurs simultanés, un seul peut utiliser votre application à la fois avec SQLLite. Il y a donc un problème d'échelle. Si c'est une application pour une seule personne, dites une bibliothèque musicale où vous détenez des centaines de titres, évaluations, informations, utilisation, lecture, temps de lecture, alors SQL Lite évoluera magnifiquement en contenant des milliers, voire des millions d'enregistrements (disque dur disponible)

MySQL, en revanche, fonctionne bien pour les applications de serveurs où les gens du monde entier l'utiliseront simultanément. Il ne se verrouille pas et sa taille est assez grande. Donc, pour votre bibliothèque musicale, MySql serait plus que tuer car une seule personne le verrait, À MOINS QUE ce soit une bibliothèque musicale partagée où des milliers de l'ajouter ou de la mettre à jour. Alors MYSQL serait celui à utiliser.

Donc, en théorie, MySQL évolue mieux que Sqllite car il peut gérer plusieurs utilisateurs, mais il est excessif pour une seule application utilisateur.

pèlerin
la source
5
s / l'utilise / y écrit. sqlite ne se verrouille pas en lecture.
Gregg Lind
5
eh bien, votre réponse peut être facilement mal interprétée. SQLite se verrouille uniquement sur les demandes d'écriture . Nous utilisons SQLite pour avec plus de 50 Go de données médicales sous forme relationnelle et desservons des centaines de clients Web simultanés pour la navigation et les requêtes. Ses performances de lecture ne sont jamais pires que celles d'un MySQL récent.
Berk D. Demir
3
MyISAM de MySQL n'est pas beaucoup mieux pour l'accès simultané que SQLite. MySQL utilise beaucoup les verrous au niveau de la table, et ne fera pas d'écritures simultanées sauf dans quelques cas où la disposition de MyISAM est optimale. Sauf si vous optez pour InnoDB (qui a ses propres problèmes comme un fichier de données qui ne rétrécit jamais), vous ne serez peut-être pas beaucoup mieux avec MySQL.
Kornel
1

Le site Web de SQLite (la partie que vous avez référencée) indique qu'il peut être utilisé pour une variété de situations multi-utilisateurs.

Je dirais que cela peut gérer pas mal de choses. D'après mon expérience, cela a toujours été très rapide. Bien sûr, vous devez indexer vos tables et lors du codage par rapport à celles-ci, vous devez vous assurer que vous utilisez des requêtes paramétrées, etc. Fondamentalement, la même chose que vous feriez avec n'importe quelle base de données pour améliorer les performances.

jle
la source
et utiliser les transactions. C'est crucial pour SQLite.
Kornel
-1

Cela vaut peut-être la peine de vérifier REAL SQL Server , qui est un serveur de base de données basé sur SQLite.

Paul Lefebvre
la source
7
Je ne pense pas qu'aucun site justifie de dépenser 299 $ pour "REAL SQL Server" alors que la plupart des sites n'obtiennent pas assez de trafic pour même commencer à atteindre les limites de SQLLite.
djangofan le