Question SQLite sur un serveur de production? [fermé]


Je connais SQLite depuis longtemps et je sais que tout va très vite, mais je ne l’ai jamais essayée sur un serveur de production. Je n'ai jamais été capable de trouver une estimation fiable du trafic qu'il pouvait gérer avant d'échouer.

Quelqu'un at-il des chiffres ou un article à ce sujet?


7
2018-02-19 05:53


origine


Attention: La Question et certaines des Réponses contiennent des idées fausses, des incompréhensions et des informations obsolètes! - Chris S
Nous évaluons SQLite en tant que solution de mise en cache en production: uri.agassi.co.il/2014/10/using-sqlite-for-production.html - Uri Agassi


Réponses:


Malheureusement, je n'ai pas de chiffres pour vous concernant les capacités de charge, mais quelques commentaires sur certains facteurs limitant les performances:

  • La vitesse de SQLite est affectée par la vitesse du disque sur lequel il est placé et par le fait que de nombreuses insertions / mises à jour sont en cours (par exemple, un 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 valider la transaction. J'ai eu des insertions de masse très rapides lors du traitement de la transaction par programme

  • Si vous êtes généralement que en train de lire données alors vous obtenez de bonnes performances dans mon expérience. Ainsi, SQLite peut être utilisé comme système de cache pour stocker des lectures de serveur de base de données, en particulier des lectures distantes ou des requêtes complexes.

  • Il utilise moins de ressources qu'un serveur de base de données, ce qui peut affecter les performances du site en libérant plus de ressources pour le serveur Web et le code de l'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 mieux vous servir.

Comme Devrim Comme indiqué, le site SQLite indique environ 100 000 utilisateurs / jour devrait convenir. Un système Trac nécessite des écritures, donc les performances seraient probablement plus lentes dans ce cas.


4
2018-02-19 09:25



Merci pour les réponses, vous ne pouvez donc écrire qu’une seule fois dans la base de données? Mais vous pouvez toujours faire en sorte que plusieurs personnes lisent dans la base de données sans être bloquées? Si tel est le cas, je viens de recevoir quelques idées pour un système de mise en cache. - Dr Hydralisk
Le nombre "100K" jeté autour est inutile. La documentation indiquait: "De manière générale, tout site qui reçoit moins de 100 000 hits par jour devrait fonctionner correctement avec SQLite." Un "hit" est généralement défini comme une requête HTTP. Cela inclut une demande pour chaque .js, .css et image sur un hit. Qu'est-ce que cela a à voir avec les performances de la base de données? En supposant que les auteurs voulaient dire "pageview", cela reste inutile. Combien de requêtes par pageview? Ratio de lectures à écrit? Sur quel type de matériel la base de données fonctionne-t-elle? Ce n'est pas une bonne idée d'utiliser SQLite pour un site Web lorsqu'il existe au moins une douzaine d'autres outils plus performants. - jamieb
@Dr Hydralisk Oui, les lectures peuvent se dérouler en parallèle .. comme un fichier - Cez
@jamieb Le point sur les "hits" est juste. Cependant, personne n’a mentionné le type de ressources matérielles ou de serveurs disponibles. Ce pourrait donc être un petit serveur virtuel. Implication de bases de données SQLite dans un système de mise en cache, ou principalement dans des tables en lecture seule pouvez améliorer les performances, en particulier lorsque le serveur de base de données est distant. Le cache mémoire + le cache SQLite des requêtes de base de données vaincra seul les pantalons des requêtes de base de données. - Cez


J'ai quelques points à ajouter à ces bonnes réponses.

La version actuelle de SQLite a WAL (Écriture anticipée) afin que la lecture et l’écriture puissent se dérouler simultanément. Ainsi, la limitation traditionnelle à un seul auteur mentionnée dans les réponses précédentes n'existe plus. Je n'ai pas encore vu WAL en production, je ne peux donc pas dire à quel point il évolue.

Si vous utilisez WAL ou non, si votre base de données SQLite est en lecture seule (ou mise à jour par lots) et qu’elle tient dans la RAM (votre système d’exploitation dispose de suffisamment de RAM pour la conserver dans les mémoires 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, mais maintenant, après neuf mois de production il s'est avéré fonctionner même les parties les plus complexes du système très bien.


3
2018-04-18 00:43





Sqlite est idéal pour l’intégration dans les applications, et c’est pourquoi il est conçu, mais il n’est certainement pas "extrêmement rapide". Je l'utilise pour plusieurs de mes propres applications, uniquement pour la commodité de n'avoir que deux fichiers pouvant être copiés sur un autre ordinateur afin de donner une application pleinement opérationnelle. Des tests sur MySQL, 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 performances augmente avec la taille de la base de données, bien que je ne puisse pas en dire autant, car je ne l'ai utilisée qu'avec des bases de données de moins de 100 Mo.


1
2018-02-19 06:32



PRAGMA peut être ajusté pour améliorer les performances au détriment de la corruption occasionnelle de la base de données (sans perte de données). D'après mon expérience, SQLite pouvait prendre des inserts à environ 250-300 tr / s sur un ancien ordinateur Windows XP. - djangofan
-1, parce que je ne suis pas d'accord. J'ai construit et interrogé des bases de données SQLite de plusieurs Go de taille et je n'aurais jamais autant de requêtes par seconde avec MySQL par exemple (dans le même type de matériel). SQLite peut facilement faire 120 000 requêtes d'écriture par seconde si vous savez comment correctement massage il. - Alix Axel


Je pense que sqlite est seulement plus rapide qu'un fichier texte / xml (vous pourriez être surpris si vous l'aviez essayé). Et il ne prend pas en charge la concurrence, si vous voulez créer un site pour intranet où les gens enregistrent leurs heures de travail ou utilisent la billetterie Trac, cela peut bien servir. Autre que cela, il devrait être évité et remplacé par mysql ou couchdb.

Le site sqlite dit que 100 000 utilisateurs / jour devrait suffire, mais j’en doute fortement, puisqu’un simple projet trac reste bloqué par 10 utilisateurs de bureau.


0
2018-02-19 06:04





Sqlite n'est pas une application de base de données client / serveur traditionnelle. Il s'agit essentiellement d'une bibliothèque 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 MySQL / PostgreSQL / MS-SQL autonome dans un environnement multi-utilisateur, car toute la base de données est verrouillée en écriture. Vous aurez à faire face à des problèmes de conflit, même sur une charge légère, ce qui détruira les performances.


0
2018-02-19 08:11



Dans WAL, seuls les écrivains simultanés sont bloqués. De plus, le moteur MySQL par défaut (MyISAM) verrouille également les tables pleines chaque fois qu'il existe une requête en écriture. - Alix Axel
@AlixAxel Cette réponse a été écrite six mois avant la disponibilité de WAL. - jamieb