Obtenez et mettez des tests de performances sur Google BigTables (et autres bases de données intégrées)

Quels sont les moyens efficaces d'effectuer des tests de performances programmatiques sur les opérations de base de données, en particulier dans les environnements où les bases de données elles-mêmes n'offrent pas d'outils dédiés?

Par exemple, dans Google App Engine, les chargements de page entiers sont évalués comme une seule opération qui peut inclure des opérations de base de données spécifiques. Ce problème est également probablement présent dans SQLite et d'autres bases de données intégrées. Comme il est difficile d'abstraire complètement les (équivalents) sélections et insertions qui doivent être testées, existe-t-il des outils de base de données recommandés pour effectuer des diagnostics plus approfondis sur ce type de requêtes?

— Brian Ballsun-Stanton
source

Avez-vous un accès direct à la base de données en question?

— Stingervz

Oui, c'est moi qui écris l'application. Et bien que les performances des applications soient une question différente, j'obtiens des résultats de performances assez sévères dans une mauvaise requête que j'ai écrite.

— Brian Ballsun-Stanton

Parfois, une douzaine de paires d'yeux est un meilleur diagnostic qu'un analyseur de requêtes ... (ok pas si souvent)

— jcolebrand

@Brian Je pense que vous feriez mieux sur Stackoverflow avec ce type de question car il s'agit plus d'une question de programmation que d'une question DBA.

— IamIC

@IanC Drat. J'essaie d'obtenir la sous-couche bigtable plutôt que la performance dans son ensemble. Mais je supprimerai si les gens pensent que la question ne convient pas. (J'essaie également de m'assurer que le site n'est pas tout le temps oracle / sql-server / mysql)

— Brian Ballsun-Stanton

Réponses:

Il me semble que votre problème est que vous essayez de tester des mesures de performances qui ne sont pas bien prises en charge dans la base de données sous-jacente. Il est donc très difficile de comparer les performances entre les systèmes car les approches sous-jacentes sont très différentes. Je ne pense pas qu'il soit possible de faire des comparaisons de pommes à pommes comme je ne pense pas que vous puissiez faire une comparaison de pommes à pommes d'approches de type ORDBMS à des approches de type RDBMS. Les problèmes de performances sont tout simplement trop différents et si Stonebraker a raison, l'optimisation d'un ORDBMS pour les tests TPC-C passe à côté, alors pour les systèmes encore plus éloignés, cela sera impossible. (Je pense qu'il n'est là, cependant, que là où la fonctionnalité ORDBMS entre en jeu.)

Je pense que ce dont vous avez besoin pour être honnête, c'est de regarder comment vous utiliseriez chaque système et de construire un outil de référence basé sur l'approche que vous adopteriez avec chacun. Ensuite, vous pouvez dire au moins pour ce flux de travail que le benchmark montre quelque chose de spécifique. Je ne vois cependant pas comment généraliser. Vous pouvez ensuite l'exécuter dans un profileur afin d'obtenir des informations supplémentaires sur l'endroit où le temps est passé lors du test sur différents moteurs.

Cependant, l'analyse comparative db est très difficile à rendre significative dans le meilleur des cas et lorsque vous comparez des systèmes différents, il devient impossible de généraliser.

— Chris Travers
source

Appstats est l'outil clé pour mesurer les performances sur App Engine. Il montrera le temps utilisé pour chaque RPC, y compris le magasin de données, memcache, urlfetch et les demandes de courrier dans un graphique. Normalement, les demandes apparaissent comme un "escalier" où chaque demande commence au point où la demande précédente s'est terminée, sur la ligne suivante.

Si vous utilisez les requêtes asynchrones avancées dans ndb, vous pouvez réellement voir les requêtes se produire en parallèle.

Cet outil m'a été d'une immense aide pour voir où le temps est passé et comment optimiser les requêtes.

— Brent Washburne
source