Perf ne suffit pas

La culture de l’obsession de la performance dans les bases de données

• Le secteur des bases de données se concentre sur l’amélioration des performances, mais l’expérience réelle des utilisateurs est souvent influencée par d’autres facteurs.
• Pour traiter des données, ce qui compte réellement pour l’utilisateur peut être moins l’optimisation des requêtes que le format des données ou la capacité à formuler une question en SQL.
• Les performances d’une base de données sont importantes, mais il peut être préférable de la choisir selon d’autres critères comme la facilité d’usage, l’écosystème, la rapidité des mises à jour ou l’intégration au workflow.

La fin de la guerre des benchmarks

• En 2019, GigaOm a publié un benchmark comparant des entrepôts de données cloud, mais le marché réel a ensuite montré une dynamique différente.
• Lorsque les résultats d’un benchmark ne correspondent pas à l’expérience utilisateur, cela peut indiquer que le benchmark est erroné, qu’il teste les mauvaises choses, ou que la performance n’est tout simplement pas si importante.

Ce que signifie être rapide

• Dans le domaine des bases de données cloud, on tend à se focaliser sur le temps écoulé entre le clic sur le bouton « exécuter » et l’affichage du résultat.
• Mais ce qui a réellement un impact pour l’utilisateur, c’est le temps nécessaire pour accomplir le travail, et ce n’est pas la même chose que le temps passé par le serveur de base de données.

La performance est subjective

• La performance doit être mesurée du point de vue de l’utilisateur et, en tant que problème d’UX, elle ne peut pas se résumer à un chiffre unique.
• Le caractère subjectif de la performance signifie que ce qui est le plus rapide dépend de la manière dont la base de données est utilisée.

La vitesse du changement

• DuckDB s’améliore rapidement, ce qui rend les benchmarks actuels rapidement caducs.
• Lorsqu’on choisit une base de données, les performances actuelles ne sont pas le seul critère : l’évolution future des performances et des fonctionnalités est aussi une variable importante.

Il n’existe pas de solution miracle

• Si toutes les bases de données sont activement maintenues, leurs performances finiront par converger avec le temps.
• Les écarts de performance vraiment significatifs ont peu de chances de durer sur la durée.

Le problème se situe entre la chaise et le clavier, puis entre le clavier et la base de données

• Pour l’utilisateur, l’indicateur de performance qui compte est le temps qu’il faut pour partir d’une question et obtenir une réponse.
• La vraie fonctionnalité importante n’est pas le temps d’exécution de la requête par la base, mais la vitesse qui mène de l’idée à la réponse.

À propos des raisins verts

• DuckDB figure actuellement parmi les meilleurs dans les benchmarks ClickBench et h20.ai, et affiche aussi des performances correctes sur TPC-H et TPC-DS.
• Avant de supposer qu’une base de données est rapide, il est important de la tester sur une charge de travail réelle.

Conclusion

• Les entreprises de bases de données les plus prospères n’ont pas réussi parce qu’elles étaient plus rapides que leurs concurrentes.
• Les bases de données qui ont fait de la performance leur principal argument de vente n’ont pas réussi sur le marché.
• Au moment de choisir une base de données, il vaut mieux se décider sur d’autres critères que la vitesse brute.

L’avis de GN⁺

• Cet article souligne qu’il est important de ne pas se focaliser uniquement sur la performance des bases de données, mais aussi sur l’optimisation de l’expérience utilisateur et du flux de travail. C’est aussi une leçon importante pour les ingénieurs logiciel débutants : lors du choix d’une base de données, il faut envisager une approche centrée sur l’utilisateur plutôt que de se limiter à des indicateurs de performance.
• Les performances des bases de données tendent à converger avec le temps, car les progrès technologiques se diffusent à l’ensemble des plateformes. Cela suggère qu’au moment de faire un choix technologique, il faut considérer non seulement la performance à court terme, mais aussi le support à long terme et le potentiel d’amélioration.
• Des projets open source comme DuckDB peuvent évoluer très vite grâce à leur rythme d’amélioration et au soutien de leur communauté. Cela signifie que, lors de l’adoption d’une nouvelle technologie, il faut aussi prendre en compte le dynamisme de la communauté et la vitesse d’évolution du projet.
• Lors du choix d’une base de données, il est important de ne pas s’appuyer uniquement sur les résultats des benchmarks de performance, mais aussi de tester les performances sur une charge de travail réelle. Cela peut aider à choisir une base de données mieux adaptée aux cas d’usage réels.
• Le choix d’une technologie de base de données ne doit pas se limiter à des considérations techniques : il faut aussi prendre en compte les besoins métier, la facilité de maintenance et l’efficacité du traitement des données.

[GN⁺]

Avis Hacker News

• Après plusieurs années de plaintes de clients, ils ont réalisé qu’un bug du pilote JDBC dégradait les performances. Beaucoup de temps d’ingénierie a été investi pour accélérer les requêtes, mais le connecteur utilisé par la plupart des utilisateurs ajoutait bien plus de latence que le temps économisé. De plus, ils ne s’en rendaient absolument pas compte. Comme personne chez Google n’utilisait le pilote JDBC en interne, ils ne pouvaient pas voir les temps de requête réellement vécus par les utilisateurs et considéraient cela comme le problème de quelqu’un d’autre.

  • Ce commentaire exprime sa déception face au fait que Google était « complètement aveugle » aux plaintes des clients et n’utilisait pas son propre produit. L’histoire de JDBC est particulièrement marquante.
• Google a construit en interne une base de données qui fonctionnait bien, mais a sous-traité la création de la couche d’adaptation pour le monde extérieur, et celle-ci ne fonctionnait pas correctement, si bien que le monde extérieur s’est retrouvé avec une base de données défectueuse. Le cœur sophistiqué utilisé par Google était entouré d’adaptateurs imparfaits, ce qui a produit au final un ensemble inutilement bancal. En interne, ils ne s’en rendaient pas compte, et de l’extérieur, c’était difficile à identifier.
  • Ce commentaire juge cela très représentatif de la stratégie open source de Google.
• Je trouve étrange que le blog affirme que « la performance est subjective ». Il ne suffit certes pas de simplement mesurer, mais dans le seul exemple donné, la performance est importante et objective. Ils ont simplement mesuré la mauvaise chose.
  • Ce commentaire remet en question l’affirmation du blog concernant la mesure des performances.
• Cela ressemble à un problème d’organisation de l’entreprise. Si l’objectif final est que les clients utilisent le cloud et y trouvent de la valeur, alors on ne devrait pas avoir des métriques différentes de ce qui compte pour eux. Chez Google, quelqu’un devrait activement écouter les problèmes des clients et les transmettre aux ingénieurs afin d’indiquer ce qu’il faut améliorer.
  • Ce commentaire souligne la nécessité d’une structure organisationnelle permettant à Google de comprendre les besoins des clients et de les améliorer.
• De chez moi à Seattle jusqu’au bureau de San Francisco, il faut environ 4,5 heures de porte à porte.
  • Ce commentaire fait remarquer, sur le ton de la plaisanterie, que les fondateurs ne vont plus aussi vite qu’avant, peut-être parce que la Réserve fédérale a relevé les taux d’intérêt.
• Je ne pense pas que la performance soit secondaire comme cela semble être dit ici. Il faut d’abord vérifier que la performance est suffisamment bonne, puis évaluer tout le reste. L’auteur dit lui-même que « DuckDB est rapide ». Sinon, il faudrait se lancer dans une compétition sur la performance.
  • Ce commentaire n’est pas d’accord avec l’idée que la performance serait secondaire et affirme qu’il faut d’abord s’assurer qu’elle est suffisante.
• La performance n’est pas « subjective », elle est « relative ». Son sens dépend de la tâche à accomplir.
  • Ce commentaire explique la relativité de la performance et la distingue de la perception de performance liée à la conception d’interface utilisateur.
• La première web app populaire stockait tout son état dans un dict Python et le déversait sur disque toutes les quelques minutes. L’API était très rapide, mais après le passage à MongoDB, les performances ne sont jamais revenues. Malgré cela, aujourd’hui encore, on ne choisirait pas pickledb pour créer un site web.
  • Ce commentaire partage une expérience sur les performances d’une ancienne web app et sur leur dégradation après le changement de base de données.
• J’ai construit mon propre système de base de données et je voulais comparer ses performances à celles d’autres bases populaires (Postgres, Sqlite, MySQL, SQL Server).
  • Ce commentaire explique qu’il ne s’estimait satisfait que lorsque, en mesurant jusqu’au moment où l’utilisateur appuyait sur le bouton « exécuter » puis voyait le résultat apparaître à l’écran, sa base de données devenait plus rapide sur divers types de requêtes.
• « Bien sûr, il existe des exceptions à cette règle, notamment lorsqu’il est difficile de surmonter des différences d’architecture. Les bases de données shared nothing sont désavantagées par rapport aux shared disk, et il a fallu de nombreuses années à Redshift pour passer principalement à une architecture shared disk. Les lakehouses qui persistent les métadonnées dans l’object storage auront du mal avec les mises à jour rapides ; c’est inhérent au modèle. »
  • Ce commentaire souligne les problèmes liés aux différences d’architecture des bases de données et mentionne qu’il cherche de bonnes références sur le sujet.