À quelle vitesse Berkeley DB SQL est-il comparé à SQLite?

Question

Oracle a récemment publié a Berkeley DB back-end to SQLite. Il m'arrive d'avoir une base de données SQLite de centaines de mégaoctets qui pourrait très bien bénéficier de "performances améliorées, concurrence, évolutivité et fiabilité", mais le site d'Oracle semble manquer de mesures des améliorations. Quelqu'un a-t-il fait un peu d'analyse comparative?

Answer 1

J'ai participé à l'évaluation bêta du code BDB SQLite et l'une des choses que j'ai essayé de maîtriser était la différence de performance. À ce stade, Je ne peux pas publier exactement ce que j'ai trouvé jusqu'à ce que j'ai au moins une autre personne évaluer mon code, exécuter les tests, et confirmer les numéros que j'ai (qui est fait). Cependant, je peux généraliser ici et dire qu'il y a des cas où BDB offre des améliorations de performance significatives sur SQLite, en particulier dans la zone de la gestion de charges lourdes qui impliquent une concomitance d'écriture.

Il y a, en général, deux mesures de « rapide » droit - (1) l'efficacité: combien de temps faut-il pour un seul processus pour faire XYZ par rapport accès concurrentiel (2): combien de fois pouvez de nombreux processus faire XYZ par unité de temps. Le principal problème porte sur BDB est concurrency - le traitement des transactions à grande échelle. Ainsi vous pensez de nombreuses connexions simultanées écriture et/ou modifier le contenu de la base de données.

SQLite, par définition, utilise le verrouillage au niveau de la base de données, de sorte qu'un seul écrivain peut travailler dans la base de données à la fois. Ainsi, le taux de transaction de SQLite reste plus ou moins constant avec le nombre de connexions simultanées, donc son évolutivité dans les applications intensives en écriture est vraiment mesurée par son efficacité (1). Par contre, BDB utilise le verrouillage au niveau de la page, ce qui permet à plusieurs auteurs de travailler dans la base de données à un moment donné (à condition qu'ils travaillent sur des pages séparées). Ainsi, le débit de BDB augmente potentiellement avec le nombre de connexions et donc son extensibilité est à la fois une question d'efficacité (1) et simultanée (2), qui peut s'additionner.

Principalement ce qui se résume à est (écriture) concurrence. BDB peut pousser plus de TPS que SQLite pour plusieurs écrivains. Par transaction, je veux dire quelque chose qui modifie la base de données (comment sont-ils d'une aide réelle pour les opérations en lecture seule?). Cela dit, pour la concurrence en lecture (applications qui font principalement SELECT), SQLite pourrait très bien aller tête à tête avec BDB parce que le verrouillage n'est plus un problème critique. En ce qui concerne la taille de l'ensemble de données, je ne suis pas sûr. Je n'ai pas examiné cela. En fin de compte, ils utilisent tous les deux des arbres B pour le stockage. Il peut y avoir des facteurs dans leurs implémentations respectives à considérer, mais je n'ai pas étudié cela. I sait que SQLite peut gracieusement gérer les ensembles de données dans les centaines de Mo et gigaoctets à deux chiffres (et peut-être plus maintenant que l'implémentation de la page cartonnée sale a été modifiée). Par conséquent, si vous avez une application qui utilise de nombreuses connexions qui modifient une base de données donnée et la contention de page est relativement faible, alors BDB peut offrir des améliorations de performances significatives. Mais la contention de page est une variable critique . Dans la limite, si vous aviez une base de données BDB dont les données se composaient d'une seule page , alors ses performances correspondraient à celles de SQLite dans tous les cas car le verrouillage au niveau de la page dégénère effectivement en l'équivalent de verrouillage de base de données - tout le monde se bat sur une chose. Cependant, à mesure que le nombre de pages augmente dans BDB (et que la contention de page diminue), le TPS maximal va commencer à croître avec le nombre de connexions simultanées. A partir de là, la mémoire devient le facteur limitant suivant. Mais c'est une autre histoire de .

BTW, Je suis en train d'écrire un article sur l'utilisation de BDB pour ceux à venir de SQLite.

liens article:

Oracle Berkeley DB SQL API vs. SQLite API – A Technical Evaluation

Oracle Berkeley DB SQL API vs. SQLite API – Integration, Benefits and Differences

Answer 2

C'est un peu une question chargée. Les résultats varieront considérablement selon votre vitesse d'accès au disque, la taille du cache en mémoire, nombre d'insertions par rapport lectures, ruptures de page, concurrency, etc, etc, etc.

Dans l'ensemble, BerkeleyDB peut être extrêmement rapide - J'ai récemment conçu construit une plate-forme d'analyse de données pour un employeur qui était capable de faire 40k inserts par seconde sur un système x86 8 de base (tout en même temps faire des milliers de lectures par seconde) avec un jeu de données dans la plage de 30G. C'était avec une protection transactionnelle complète. Mais dans les meilleurs cas, il y avait des moments où les insertions pouvaient descendre jusqu'à 2k par seconde, en fonction des données entrantes et de ce qui était actuellement stocké dans Berkeley. Les performances chutent de manière significative si vous avez disque lent E/S et un taux de succès pauvre cache ou sont en constante expansion la page faisant DB se dédouble pour se produire. Il existe également une énorme quantité de réglage que vous pouvez faire pour améliorer les performances de votre jeu de données particulier. Dans l'ensemble, c'est un excellent système, mais la documentation et les connaissances sont relativement minces. Je recommande The BerkeleyDB Book comme probablement la meilleure référence actuellement disponible.

Answer 3

En plus du Berkeley DB livre que Brian mentionne, vous trouverez peut-être aussi les ressources suivantes:

• Les Forums en ligne Berkeley DB peuvent fournir beaucoup de suggestions à la fois des utilisateurs et les développeurs du produit. Voir Berkeley DB forum,
• Le jeu de documentation Berkeley DB, qui peut être trouvé here. En particulier, le Guide de référence contient plusieurs sections traitant du réglage, de la performance et du débit.