Je connais SQLite depuis longtemps et je sais qu'il est très rapide, mais je ne l'ai jamais essayé sur un serveur de production. Je n'ai jamais été en mesure de trouver une estimation solide de la quantité de trafic qu'il pouvait supporter avant d'échouer.
Quelqu'un a-t-il des chiffres ou un article à ce sujet ?
Malheureusement, je n'ai pas de chiffres à vous communiquer sur les capacités de charge, mais quelques commentaires sur certains des facteurs qui limitent les performances :
La vitesse de SQLite est affectée par la vitesse du disque sur lequel il se trouve et par le fait qu'il y a beaucoup d'insertions/mises à jour en cours (c'est-à-dire des accès en écriture). Le verrouillage en écriture est limité par la vitesse de rotation du disque.
Les transactions sont lancées par défaut, mais vous obtenez de meilleures performances si vous démarrer et commit la transaction. J'ai eu des insertions de masse très rapides en gérant la transaction de façon programmatique.
Si vous êtes généralement seulement lecture données alors vous obtenez de bonnes performances selon mon expérience. Ainsi, SQLite peut être utilisé comme un système de cache pour stocker les lectures du serveur de base de données, en particulier les lectures à distance ou les requêtes complexes.
Il utilise moins de ressources qu'un serveur de base de données, ce qui peut avoir une incidence sur les performances du site, car il libère davantage de ressources pour le serveur Web et le code d'application.
Si vous avez besoin d'un certain nombre d'écritures simultanées, un serveur de base de données (par exemple, MySQL, Postgres) peut vous être utile.
Comme Devrim Le site SQLite indique que 100 000 utilisateurs par jour devraient suffire. Un système Trac nécessite des écritures, donc les performances seraient probablement plus faibles dans ce cas.
J'ai quelques points à ajouter à ces bonnes réponses.
La version actuelle de SQLite a WAL (Write-Ahead Logging) afin que la lecture et l'écriture puissent se dérouler simultanément. Ainsi, la limitation traditionnelle à un seul écrivain mentionnée dans les réponses précédentes n'existe plus. Je n'ai pas encore vu WAL en production et je ne peux donc pas me prononcer sur sa capacité à évoluer.
Que vous utilisiez WAL ou non, si votre base de données SQLite est en lecture seule (ou est mise à jour par lots) et qu'elle tient dans la RAM (votre système d'exploitation a suffisamment de RAM de réserve pour la conserver dans des tampons), elle peut très bien s'adapter à une application web de production. Personnellement, j'étais très sceptique quant à ses performances, son évolutivité et sa robustesse. maintenant après neuf mois de production il a été prouvé qu'il fonctionne même les parties les plus complexes du système très bien.
Sqlite est excellent pour être intégré dans des applications, et c'est ce pour quoi il a été conçu, mais il n'est certainement pas "incroyablement rapide". Je l'utilise pour plusieurs de mes propres applications, purement pour la commodité d'avoir seulement deux fichiers qui peuvent être copiés sur une autre machine pour donner une application entièrement fonctionnelle. Des tests contre MySQL, en utilisant la même structure, les mêmes index, etc., montrent que Sqlite est considérablement plus lent, même pour les petites bases de données. Je m'attendrais à ce que la différence de performance augmente avec la taille de la base de données, bien que je ne puisse pas en être certain car je ne l'ai utilisé qu'avec des bases de données de moins de 100MB.
Je pense que sqlite est seulement plus rapide qu'un fichier texte/xml (vous pourriez être surpris si vous l'essayiez). Et il ne supporte pas la concurrence, si vous voulez créer un site pour intranet où les gens enregistrent leurs heures de travail ou utilisent la billetterie trac, il peut servir. A part cela, il devrait être évité et remplacé par mysql ou couchdb.
le site web de sqlite dit que 100k utilisateurs/jour devrait suffire mais j'en doute fortement, car un simple projet trac est souvent bloqué avec 10 personnes au bureau.
Sqlite n'est pas une application traditionnelle de base de données client/serveur. Il s'agit essentiellement d'une bibliothèque qui est intégrée à une autre application. Il est conçu pour les applications de bureau mono-utilisateur. Vous ne voulez absolument pas essayer de l'utiliser comme une sorte de remplacement autonome de MySQL/PostgreSQL/MS-SQL dans un environnement multi-utilisateurs parce que la BD entière est verrouillée en écriture. Vous aurez à faire face à des problèmes de contention, même pour une charge légère, ce qui détruira les performances.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
