Quelle est la vitesse de Berkeley DB SQL par rapport à SQLite?
Oracle a récemment publié n back-end Berkeley DB pour SQLite . Il se trouve que j'ai une base de données SQLite de plusieurs centaines de mégaoctets qui pourrait très bien bénéficier de "performances, simultanéité, évolutivité et fiabilité améliorées", mais le site d'Oracle semble manquer de mesures des améliorations. Quelqu'un ici a-t-il fait des analyses comparatives?
J'ai participé à l'évaluation bêta du code BDB SQLite et l'une des choses que j'ai essayé de comprendre était la différence de performances. À ce stade, je ne peux pas publier exactement ce que j'ai trouvé jusqu'à ce qu'au moins une autre personne évalue mon code, exécute les tests et confirme les chiffres que j'ai obtenus (ce qui est en cours). Cependant, je peux généraliser ici et dire qu'il existe des cas où BDB offre des améliorations de performances significatives par rapport à SQLite, en particulier dans le domaine de la gestion de charges lourdes qui impliquent la concurrence d'accès en écriture.
Il y a, en général, deux mesures de la droite "rapide" 1) l'efficacité: combien de temps faut-il pour qu'un seul processus fasse XYZ contre (2) la concurrence: combien de fois plusieurs processus peuvent-ils faire XYZ par unité de temps. Le principal problème auquel BDB est confronté est la concurrence - le traitement des transactions à grande échelle. Ainsi, vous pensez à de nombreuses connexions simultanées écrivant et/ou modifiant le contenu de la base de données.
SQLite, de par sa conception, utilise un verrouillage au niveau de la base de données, donc un maximum d'un é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 gourmandes en écriture est vraiment mesurée par son efficacité (1).
BDB d'autre part utilise le verrouillage au niveau de la page, qui permet à plusieurs écrivains de travailler dans la base de données à un moment donné (à condition qu'ils travaillent sur des pages distinctes). Ainsi, le taux de BDB augmente potentiellement avec le nombre de connexions et donc son évolutivité est à la fois une question d'efficacité (1) et de concurrence (2), ce qui peut s'additionner.
Cela se résume principalement à (écrire) la 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 (en quoi sont-ils d'une réelle aide pour les opérations en lecture seule?). Cela dit, pour la lecture simultanée (applications qui font principalement des SELECT), SQLite pourrait très bien aller de pair avec BDB car le verrouillage n'est plus un problème critique.
Quant à 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 à considérer dans leurs implémentations respectives, mais je n'ai pas étudié cela. Je sais que SQLite peut gérer gracieusement les ensembles de données dans les centaines de Mo et les Go à deux chiffres (et peut-être plus maintenant que l'implémentation de la carte de page 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 que le conflit de pages est relativement faible, alors BDB peut offrir des améliorations de performances significatives. Mais la contention de page est une variable critique. À la limite, si vous aviez une base de données BDB dont les données consistaient en une seule page, 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 du verrouillage au niveau de la base de données - tout le monde se bat pour une chose. Cependant, à mesure que le nombre de pages augmente en BDB (et que le conflit de pages diminue), le TPS maximal commencera à augmenter avec le nombre de connexions simultanées. À partir de là, la mémoire devient le prochain facteur limitant. Mais c'est une autre histoire.
BTW, je suis en train d'écrire un article sur l'utilisation de BDB pour ceux qui viennent de SQLite.
Liens vers les articles:
--- (API Oracle Berkeley DB SQL vs API SQLite - Une évaluation technique
API Oracle Berkeley DB SQL vs API SQLite - Intégration, avantages et différences
C'est un peu une question chargée. Les résultats varieraient considérablement en fonction de vos vitesses d'accès au disque, de la taille du cache en mémoire, du nombre d'insertions par rapport aux lectures, des divisions de page, de la simultanéité, etc., etc., etc.
Dans l'ensemble, BerkeleyDB peut être extrêmement rapide - J'ai récemment conçu une plate-forme d'analyse de données pour un employeur qui était capable de faire 40 000 insertions par seconde sur un 8 système x86 de base (tout en faisant des milliers de lectures par seconde) avec un ensemble de données dans la plage 30G. C'était avec une protection transactionnelle complète.
C'était le meilleur des cas, cependant - il y avait des moments où les insertions pouvaient chuter à aussi peu que 2 000 par seconde, selon les données entrantes et ce qui était actuellement stocké à Berkeley. Les performances diminuent considérablement si vous avez des E/S de disque lentes et un faible taux d'accès au cache ou si vous étendez constamment la base de données, ce qui entraîne des fractionnements de page. Il existe également une énorme quantité de réglages que vous pouvez faire pour augmenter les performances de votre ensemble de données particulier.
Dans l'ensemble, c'est un excellent système, mais la documentation et les connaissances sont assez minces. Je recommande The BerkeleyDB Book comme probablement la meilleure référence actuellement disponible.
En plus du Berkeley DB Book que Brian mentionne, vous pouvez également trouver les ressources suivantes utiles:
- Les forums en ligne de Berkeley DB peuvent fournir de nombreuses suggestions à la fois des utilisateurs et des développeurs du produit. Voir forum Berkeley DB ,
- L'ensemble de documentation Berkeley DB, qui peut être trouvé ici . En particulier, le Guide de référence contient plusieurs sections couvrant le réglage, les performances et le débit.