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

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?

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}

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.

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.

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.

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.

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.

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.

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.

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.

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