Réponse courte
Oui , vous pouvez écrire une référence significative d'un cas étudié, si vous le faites avec soin, et comprendre que si cela est pertinent pour le cas particulier, il peut ne pas l'être pour d'autres cas. Cela est également vrai lors de la comparaison des bases de données du même type (base de données relationnelle contre une autre base de données relationnelle) ou des bases de données de types différents.
Non , vous ne pouvez pas écrire un benchmark qui prouvera comme par magie qu'une base de données spécifique est bien meilleure qu'une autre dans tous les cas, pour chaque application.
Longue réponse
Il est certainement possible de dire que «le passage d'une base de données à une autre a amélioré les performances de notre site».
Vous mesurez les performances de la base de données précédente grâce au profilage ou aux statistiques d'exécution en collectant suffisamment d'informations sur les requêtes et leur rapidité.
Vous déplacez l'application vers la nouvelle base de données.
Vous faites les mêmes mesures.
Vous comparez.
Par exemple, si la liste complète des 3 182 432 produits chargés en 2,834 s. sur une ancienne base de données et se charge en 0,920 s. sur une nouvelle base de données, étant donné que dans les deux cas, l'application a un cache vide, c'est une victoire: la nouvelle base de données a amélioré les performances de votre site concernant cette requête.
Maintenant, comme toute mesure de performance, elle est biaisée:
D'accord, la nouvelle requête est plus rapide. Mais attendez, votre DBA ne savait pas comment utiliser la base de données que vous aviez auparavant , donc la requête qui charge tous les produits n'est pas optimisée . Si vous le réécrivez ainsi, vous pourrez charger ces produits en 0,855 s. au lieu de 2.834.
Ok, tu as un meilleur résultat. Mais ne pensez-vous pas qu'il est injuste de comparer une base de données avec de nouvelles données qui viennent d'être transférées dans une base de données vieille de 10 ans pour laquelle le dernier plan de maintenance a été exécuté il y a trois ans? Au fait, ne pensez-vous pas que vous auriez dû mettre à jour le produit de base de données au moins une fois au cours des quatre dernières années?
Certaines requêtes sont plus rapides. Certains sont plus lents. Comment calculez-vous le résultat moyen pour savoir que vous avez globalement gagné en performances lors du passage à la nouvelle base de données? D'accord, le temps de chargement des 3 182 432 produits est plus rapide. Mais est-ce important, alors que la requête n'est exécutée sur le site Web que dans de rares cas où un administrateur effectue une tâche spécifique qu'il n'a effectuée que deux fois au cours des dix dernières années? D'un autre côté, l'exécution de toutes les requêtes sur la page d'accueil pour un nouvel utilisateur gaspille 0,281 s. avec la nouvelle base de données, quand il était de 0,207 s. avec l'ancienne base de données. Ce résultat est beaucoup plus important, d'autant plus que ces requêtes ne peuvent pas être mises en cache pendant une longue période et sont exécutées des dizaines de milliers de fois par jour.
Les deux bases de données doivent être testées sur les mêmes serveurs , le même matériel, la même structure. Par exemple, vous ne pouvez pas tester une base de données sur un seul disque dur et l'autre sur un RAID1 de deux SSD. Lorsque vous migrez un grand projet vers une nouvelle base de données, il est possible que vous hébergiez simplement la nouvelle base de données sur une centaine d'autres serveurs rack nouvellement déployés, alors que la base de données précédente restera toujours sur les machines précédentes.
Pour résumer, vous pouvez comparer les requêtes de base de données d'une application et obtenir des mesures précises . Mais alors, il faut donner un sens aux chiffres. Dans cet état, il est tentant de dire que vous avez gagné en performances sur le site: sinon, la direction serait en colère d'apprendre que vous avez dépensé des milliers de dollars et des mois de travail juste pour ralentir les choses.
L'erreur la plus terrible est de tirer ces conclusions des références et de conclure une stupidité comme "Microsoft SQL Server est trois fois plus rapide qu'Oracle": dire cela revient à dire que "Java est meilleur que PHP". Définissez mieux. Mieux dans quels cas? Pour quel type d'applications? Pour quelle équipe de développeurs?
Plus vous interprétez et généralisez, plus la chose devient hors de propos et dénuée de sens.
La requête que select [...]vous pouvez trouver dans la révision # 832 dans le fichier ProductFactory.cs, la ligne 117 s'exécute sous 0,5 s. avec la nouvelle base de données lorsqu'elle est testée dans les conditions spécifiées dans l'annexe M des exigences non fonctionnelles, cas 3. Cela permet de passer l'exigence non fonctionnelle 527 (voir page 80, révision 9). La même exigence n'était pas satisfaite avec la base de données précédente, lorsque les résultats des tests étaient de l'ordre de 0,9 à 1,3 s. dans les mêmes conditions.
est significatif pour un développeur et suffisamment précis pour savoir ce qui a été testé, comment et quels ont été les résultats. Cela répond à votre question numéro 2.
Malheureusement, cela n'a aucun sens pour la direction. Au lieu:
La migration de notre produit de MySQL vers la dernière version de Microsoft SQL Server a amélioré les performances globales de notre produit de cinq, réduisant à la fois les coûts de deux et l'empreinte environnementale de trois. Nous pensons que la migration de toutes nos applications vers Microsoft SQL Server l'année prochaine donnera des résultats encore meilleurs et augmentera notre compétitivité sur le marché.
est un pur jabber-jabber marketing, et, techniquement, cela ne veut rien dire, mais a étonnamment une valeur pour les services de gestion et de marketing.
Enfin, peut-on comparer différents types de bases de données? Je dirais que c'est totalement possible. Disons que j'ai un site Web hébergeant de grandes photos. Ces photos sont stockées dans varbinary(max)Microsoft SQL Server 2005 (donc je ne peux pas les utiliser filestream). Je suis préoccupé par les performances lors du chargement de ces photos, je décide donc de stocker les photos sous forme de fichiers, en utilisant le système de fichiers comme ma nouvelle base de données. Tout d'abord, ces fichiers sont stockés sur la même machine que la base de données. Je profile la nouvelle solution et j'obtiens le résultat qui montre que dans mon cas, les fichiers sont chargés 4% plus rapidement à partir du système de fichiers qu'à partir de Microsoft SQL Server. L'indice de référence est très clair. Maintenant, je peux penser à déployer un serveur dédié optimisé pour le stockage direct de fichiers, plutôt que d'utiliser le serveur optimisé pour Microsoft SQL Server.