La performance ne suffit pas

• Si, dans le choix d’une base de données, on ne regarde que la vitesse brute des requêtes et les benchmarks généralistes, on risque de passer à côté du temps total nécessaire à l’utilisateur pour aller de la question à la réponse
• En 2019, le benchmark GigaOm plaçait Azure Data Warehouse et Redshift en tête, mais sur le marché réel Snowflake et BigQuery se vendaient mieux, montrant le poids de facteurs autres que la performance
• Même si l’on réduit le temps d’exécution côté serveur, des éléments périphériques comme le pilote JDBC, le téléchargement des résultats, le parsing de CSV ou la difficulté à écrire du SQL peuvent devenir des goulots d’étranglement plus importants
• ClickBench, TPC-H et TPC-DS sont utiles, mais les conclusions changent selon la présence ou non de JOIN, les scans d’une seule table, le tuning du schéma, ainsi que les conditions d’exactitude et de garanties ACID
• Les performances des moteurs de bases de données convergent avec le temps ; les critères de choix à long terme devraient donc être la vitesse entre l’idée et la réponse et l’intégration au workflow plutôt que le classement actuel

---

Le temps d’attente réel que les benchmarks ne voient pas

• Sur un trajet de 4,5 heures entre une maison à Seattle et un bureau à San Francisco, même si la vitesse de croisière de l’avion était multipliée par 10, le temps total ne pourrait diminuer que d’environ 20 % à cause du trajet vers l’aéroport, du contrôle de sécurité, de l’embarquement, de l’attente sur la piste, des bagages et du trajet à l’arrivée
• Les bases de données sont similaires
  • Même si le moteur devient plus rapide, l’utilisateur doit aussi faire face à des fichiers CSV étranges, à la difficulté d’exprimer une question en SQL et à des problèmes de connexion avec les outils
  • Un produit qui gagne la guerre des benchmarks est facile à promouvoir, mais cela ne signifie pas que le temps de résolution des problèmes des utilisateurs diminue immédiatement
• Pour choisir une base de données, la facilité d’utilisation, l’écosystème, la vitesse de mise à jour et l’intégration au workflow peuvent être de meilleurs critères
• La performance ne montre que le temps d’une tâche donnée à un moment donné, et peut pousser à optimiser avec acharnement le mauvais goulot d’étranglement

Les résultats GigaOm de 2019 et le décalage avec le marché

• En 2019, GigaOm a exécuté des benchmarks TPC-H et TPC-DS sur des entrepôts de données cloud
  • Les systèmes testés étaient ceux des trois grands fournisseurs cloud ainsi que Snowflake
  • Les résultats plaçaient Azure Data Warehouse en tête, suivi de Redshift, tandis que Snowflake et BigQuery étaient nettement à la traîne
• À l’époque, dans les évaluations clients de BigQuery, les clients qui le comparaient directement à Azure choisissaient souvent BigQuery
• Les résultats du marché étaient presque inverses au classement des benchmarks
  • Snowflake et BigQuery se vendaient davantage que Redshift
  • Redshift se vendait mieux qu’Azure
• TPC-H et TPC-DS étaient des tests standard du secteur et servaient aussi à juger les performances en interne ; mais si les clients achetaient davantage des systèmes mal classés dans de bons benchmarks de performance, c’est qu’il existait des facteurs plus importants que la performance

La rapidité ressentie par l’utilisateur n’est pas le temps serveur

• Les personnes qui construisent des bases de données ont tendance à se concentrer sur le temps d’exécution serveur entre le moment où l’utilisateur clique sur « run » et celui où les résultats sont prêts
• Le temps qui compte pour l’utilisateur est le temps total nécessaire pour terminer sa tâche, ce qui n’est pas la même chose que le temps d’exécution de la requête par le serveur de base de données
• Le cas du pilote JDBC de BigQuery illustre bien cette différence
  • Le pilote JDBC était une interface générique utilisée par les développeurs et les outils de BI pour se connecter à la base de données
  • Les requêtes BigQuery s’exécutaient en 1 à 2 secondes, mais à cause de la manière dont le pilote interrogeait l’état d’achèvement et téléchargeait les résultats, elles semblaient plus lentes de quelques secondes, voire de quelques minutes, pour l’utilisateur
  • Quand les résultats étaient nombreux, le pilote récupérait par pages toutes les données, y compris celles dont l’utilisateur n’avait pas besoin, ce qui augmentait la latence et pouvait même provoquer des plantages par manque de mémoire
• Les ingénieurs consacraient beaucoup de temps à gagner des fractions de seconde sur les requêtes, alors que le connecteur réellement utilisé par de nombreux utilisateurs introduisait des retards bien plus importants
• Les benchmarks internes tournaient tous les jours, mais la performance de bout en bout et le temps ressenti par l’utilisateur restaient invisibles

La performance ne se fige pas dans un seul chiffre

• La performance doit être mesurée du point de vue de l’utilisateur, et non de celui de la base de données ; comme l’UX, elle est difficile à décrire entièrement par un seul chiffre
• La base de données la plus rapide dépend de la charge de travail réelle
  • Même si une Lamborghini est plus rapide qu’une Prius, cela peut ne rien changer au temps de trajet domicile-travail dans les embouteillages
  • L’écart de performance entre ClickHouse et Redshift dépend lui aussi de la façon dont on les utilise
• Le ClickBench de ClickHouse a montré que ClickHouse était plus rapide que plusieurs autres bases de données
  • Le benchmark fonctionnait sur une seule table sans JOIN et reposait beaucoup sur les comptages distincts
  • Cela peut être un bon indicateur de substitution pour l’analyse de logs ou le calcul d’utilisateurs uniques d’un site web
  • Mais cela peut induire en erreur pour les charges de travail en schéma en étoile des entrepôts de données traditionnels
• Les benchmarks de fournisseurs se concentrent généralement sur les domaines où le fournisseur est fort
• BigQuery peut paraître mal classé dans les benchmarks, mais comme il a très peu de réglages et s’auto-tune globalement, l’expérience utilisateur réelle peut être ressentie comme bonne
• Une instance SingleStore fortement tunée peut surpasser largement BigQuery sur de nombreuses tâches, mais cela exige du temps de tuning du schéma et une adaptation lors de l’ajout de nouvelles charges de travail
• On peut aussi améliorer les performances en réduisant les garde-fous ou l’exactitude
  • suppression des vérifications d’overflow
  • omission du flush des écritures
  • fourniture de résultats approximatifs pour certaines opérations
  • absence de garanties ACID
• Ces raccourcis peuvent devenir des options que l’on ne voudrait pas utiliser hors d’un environnement contrôlé

Le rythme d’amélioration dure plus longtemps que le classement du moment

• Lors de la création d’une entreprise fondée sur DuckDB, certains faisaient remarquer que DuckDB était très en retrait dans le benchmark h2o.ai
• Il y avait deux raisons de ne pas s’en inquiéter
  • La performance était un facteur secondaire
  • DuckDB s’améliorait à un rythme très rapide
• Les progrès rapides de DuckDB s’expliquent en partie par certains choix d’architecture, une base de code relativement récente et propre, ainsi que d’excellents ingénieurs
• Dans les résultats publics du même benchmark sur des versions récentes de DuckDB, DuckDB est passé du milieu du classement au groupe de tête, avec une large avance
• Le choix d’une base de données est une décision qui dure plusieurs années ; les performances et fonctionnalités actuelles ne sont donc pas les seuls éléments importants, les capacités possibles dans un an le sont aussi
• Si deux bases de données progressent à des rythmes différents, il est probablement préférable de choisir celle qui avance le plus vite

Les écarts de performance se resserrent avec le temps

• Après plusieurs années d’améliorations répétées sur plusieurs bases de données activement maintenues, les performances ont tendance à converger
• Une technique de performance utilisée par un produit peut être implémentée avec le temps dans d’autres produits
  • Si ClickHouse utilise une technique avantageuse pour la vitesse de scan, Snowflake peut disposer d’une fonctionnalité similaire en un ou deux ans
  • Si Snowflake ajoute des vues matérialisées incrémentales, BigQuery peut bientôt suivre
• Les techniques permettant d’obtenir de bonnes performances varient selon les bases de données
  • compilation des requêtes en code machine
  • mise en cache des données sur des SSD locaux
  • traitement du shuffle avec du matériel réseau spécialisé
• Avec assez de temps, tout le monde peut implémenter les techniques efficaces, et si elles fonctionnent bien, elles ont de fortes chances de se diffuser dans plusieurs systèmes
• Dans la comparaison des performances des entrepôts de données de George Fraser, CEO de Fivetran, le meilleur temps était de 8 secondes et le plus lent de 18 secondes en 2020 ; en 2022, trois fournisseurs étaient autour de 7 secondes et le plus lent à 9 secondes
• En revanche, les différences d’architecture sont difficiles à surmonter
  • les bases de données shared nothing peuvent être désavantagées par rapport aux architectures shared disk
  • Redshift a mis plusieurs années à migrer largement vers une architecture shared disk
  • les lakehouses qui stockent les métadonnées dans des object stores peuvent avoir du mal avec les mises à jour rapides
• Ces différences apparaissent surtout dans les cas limites, et à long terme il n’y a pas de raison intrinsèque pour que Redshift soit plus rapide ou plus lent que Snowflake

Les fonctionnalités qui réduisent le temps entre la question et la réponse

• La performance qui compte pour l’utilisateur est le temps entre le moment où une question apparaît et celui où la réponse est obtenue
• Réduire ce temps ne se limite pas à améliorer le plan de requête
  • on peut aider à exprimer plus facilement la question
  • on peut rendre les résultats de requête plus faciles à comprendre
  • on peut fournir du feedback lorsqu’une mauvaise question est posée
  • on peut aider à comprendre les problèmes de données
  • on peut aider à préparer les données nécessaires au bon endroit et dans le bon format
• Snowflake avait un point fort : faire en sorte que, lorsque l’utilisateur saisissait du SQL, « ça marche tout simplement »
  • Pour calculer des différences de dates, on peut utiliser à la fois DATEDIFF et TIMEDIFF
  • Si les types sont raisonnables, les deux fonctionnent
  • On peut préciser ou omettre la granularité
  • On peut mettre ou ne pas mettre de guillemets autour de la granularité
• DuckDB a aussi ajouté, avec Friendlier SQL, des fonctionnalités qui facilitent l’écriture et la maintenance des requêtes
  • GROUP BY ALL réduit les oublis de champs dans la clause GROUP BY des requêtes d’agrégation
  • Il suffit de modifier la liste SELECT, ce qui réduit le besoin de changer plusieurs endroits quand une requête évolue
  • Lorsque cette fonctionnalité s’est révélée utile, plusieurs fournisseurs de bases de données ont ajouté des fonctions similaires
• Le CSV est un format qui contient beaucoup de données dans le monde, mais de nombreux fichiers sont mal structurés et le parsing est en réalité difficile
  • Le splitter CSV initial de BigQuery ne faisait pas d’inférence, et il était déstabilisé lorsque les schémas variaient légèrement d’un fichier à l’autre
  • Le parsing de CSV est un problème plus délicat qu’il n’y paraît
• Si deux ingénieurs doivent lire des données CSV pour calculer le même résultat, celui qui ingère plus facilement et correctement le CSV obtiendra la réponse en premier, indépendamment de la vitesse du moteur de requête
• La manière de traiter les résultats a aussi un impact majeur sur l’expérience utilisateur
  • Si SELECT * renvoie la première page et un curseur comme MySQL, l’affichage peut être immédiat
  • Si, comme BigQuery, il faut créer une copie de table côté serveur, cela peut prendre des heures sur une grande table
  • Si le client tente de télécharger toutes les données, il peut manquer de mémoire
  • Les connexions longues sont vulnérables aux problèmes réseau, et le polling peut donner l’impression qu’une requête est plus lente lorsqu’elle se termine entre deux intervalles de polling

Repères pour lire les benchmarks de DuckDB

• DuckDB est rapide et se situe parmi les meilleurs dans ClickBench pour certaines tailles de machines
  • L’exemple donné est celui des résultats sur c6a.4xlarge
• DuckDB obtient aussi de bonnes performances dans la plupart des benchmarks h2o.ai, et n’est pas mauvais non plus sur TPC-H et TPC-DS
• Avant de supposer qu’une base de données est rapide, il faut la tester directement sur sa propre charge de travail

Résoudre vite un problème plutôt qu’exécuter vite une requête

• Les entreprises de bases de données les plus prospères ne l’ont pas été simplement parce qu’elles étaient plus rapides que leurs concurrentes
• Redshift a été fort pendant un temps, mais si Snowflake a pu entrer sur le marché, ce n’était pas à cause de ses performances dans les benchmarks, mais grâce à sa maintenabilité
• Les bases de données qui faisaient de la performance leur principal argument de vente n’ont pas obtenu de bons résultats sur le marché ; celles qui permettaient de terminer le travail plus facilement ont mieux résisté
• Les dimensions à examiner pour choisir une base de données sont plus larges
  • il n’existe pas de technique secrète magique, et sauf différences d’architecture, les performances convergent avec le temps
  • la vitesse d’amélioration des moteurs de bases de données varie beaucoup, et ceux qui avancent vite ont un avantage à long terme
  • les fournisseurs de bases de données les plus obsédés par la performance peuvent devenir plus lents à long terme
  • il n’existe pas d’indicateur unique de performance pour les bases de données, et même une base rapide peut être mauvaise pour certaines charges de travail
  • la fonctionnalité importante n’est pas la vitesse entre la requête et le résultat, mais la vitesse entre l’idée et la réponse
• Une requête rapide vaut mieux qu’une requête lente, mais le choix d’une base de données doit se faire sur d’autres critères que la vitesse brute

[GN⁺]

Avis sur Hacker News

• Il est frustrant de lire qu’après des années de plaintes clients, ils n’avaient « absolument pas réalisé » qu’un problème de pilote JDBC plombait les performances
  En interne, Google n’utilisait pas son propre produit comme de vrais clients, et comme le temps des requêtes vu par les utilisateurs n’était pas visible en interne, le problème était traité comme celui de quelqu’un d’autre

  • Même la leçon tirée ici semble un peu à côté. Ce n’est pas que « les performances ne suffisent pas » ; c’est que les performances sur les chemins réellement empruntés par les clients comptent plus que les benchmarks de composants pris isolément
    Le problème n’était pas d’avoir consacré trop d’efforts à l’optimisation, mais de ne pas être parti de la douleur des clients pour remonter jusqu’à la cause racine. Et la cause réelle était bien, au final, un problème de performance

• L’histoire du JDBC était vraiment excellente. Google a créé une base de données qui fonctionnait bien en interne, puis a fait sous-traiter une couche d’adaptation pour le monde extérieur ; comme elle ne fonctionnait pas correctement, les utilisateurs externes se retrouvaient avec une base de données médiocre
  En quelque sorte, ils ont enveloppé le cœur sophistiqué utilisé par Google dans un emballage défectueux, rendant tout le produit inutilement catastrophique ; en interne, personne ne s’en est rendu compte, et les utilisateurs externes avaient du mal à identifier la cause. Cela ressemble à un exemple très précis de la stratégie open source de Google

  • Du point de vue du management, on peut comprendre. L’idée est : « Nous avons recruté les meilleurs talents en informatique, faisons-les travailler sur les vrais problèmes d’informatique, et externalisons le pilote JDBC, ce n’est pas notre cœur de compétence »
    Le problème, c’est que si l’on détériore suffisamment les domaines non essentiels, l’excellence du cœur de compétence ne sert plus à rien. L’externalisation n’est pas un repas gratuit
  • Les wrappers Python pour les API Google, c’était exactement ça
  • C’est dû à un manque d’intégration verticale. Si Apple gagne sur de nombreux plans, c’est parce qu’elle réussit très bien l’intégration verticale
  • Les contrats business du type Workspace reposent exactement sur cette structure. Un excellent produit de base est recouvert de contrats de « support » où certaines des pires sociétés de conseil du monde prélèvent environ 15 %, et qui sont non seulement inutiles, mais nuisibles

• L’article dit que « la performance est subjective » et que les mesures simples ne suffisent pas, mais les exemples montrent justement des cas où la performance était réellement importante et objective. Ils mesuraient simplement la mauvaise cible

  • Dès le premier paragraphe, on commence par un cas qui correspond parfaitement à la loi d’Amdahl, et il est étonnant que l’article ne la mentionne jamais

• On dirait un problème d’organisation dans l’entreprise. Si l’objectif final est d’amener les gens à utiliser le cloud et de leur apporter de la valeur, je ne comprends pas pourquoi les indicateurs suivis sont déconnectés de ce qui importe aux clients
  Il devrait y avoir chez Google des personnes qui parlent directement aux clients, comprennent leurs problèmes, puis les transmettent aux ingénieurs pour qu’ils sachent quoi améliorer. L’organisation devrait être conçue de sorte que les ingénieurs reçoivent les indicateurs nécessaires, ou que la création même de ces indicateurs fasse partie de leur travail

  • « Quand les anecdotes et les métriques divergent, ce sont généralement les anecdotes qui ont raison » — Jeff Bezos. Malheureusement, il lui arrivait parfois de dire des choses pertinentes
  • Google semble avoir une petite allergie au fait de parler directement aux clients
  • https://en.wikipedia.org/wiki/Seeing_Like_a_State
  • Si notre solution ne résout pas le problème du client, alors soit le client a besoin d’un autre problème, soit nous avons besoin d’un autre client
  • Tout à fait d’accord. Cela ressemble à un problème de mauvais indicateur choisi comme objectif. Mais cela va au-delà d’une équipe d’ingénierie qui ne mesurerait qu’une portion trop étroite de la latence
    Je me demande surtout quels indicateurs regardaient les responsables produit et organisationnels pour avoir manqué ce retour client

• Le passage sur les « 4,5 heures porte à porte entre une maison à Seattle et un bureau à San Francisco » me fait penser que les fondateurs d’aujourd’hui ne se déplacent plus à 179 miles par heure. C’est apparemment ce qui arrive quand la Fed relève ses taux

  • À la première lecture, j’ai cru qu’il conduisait, mais il s’agit probablement du temps total avion + trajets vers/depuis l’aéroport + contrôle de sécurité
  • Je suis justement en train d’aller de chez moi, à Seattle, à un bureau à SF. Je suis parti il y a 48 minutes ; quand j’arriverai, je mettrai à jour pour ajouter ici un point de donnée personnel

• Il y a clairement de bons points, mais la conclusion me semble un peu à côté. La performance n’est pas tellement secondaire, comme l’article le suggère, mais plutôt une question de suffisance ou non
  Il faut d’abord être suffisamment rapide ; ensuite seulement, on peut juger les autres facteurs. Avant cela, on n’est même pas invité à la table de la concurrence. L’auteur dit lui-même que « DuckDB est rapide » ; s’il ne l’était pas, il aurait dû rivaliser sur la performance, au moins jusqu’à cocher cette case
  De plus, l’idée que « le moteur de base de données qui avance le plus vite finit par gagner » peut être vraie dans une certaine mesure, mais elle n’est pas très pratique. Quand on est un nouvel entrant, les progrès sont rapides, mais une fois arrivé à une position comme celle de Snowflake, la cadence ralentit forcément. Quand on choisit un système aujourd’hui, on ne peut pas extrapoler l’accélération actuelle telle quelle dans le futur
  Cela dit, la perspective « non pas de la requête au résultat, mais de l’idée à la réponse » mérite probablement d’être explorée plus en profondeur

• La performance n’est pas tant « subjective » que relative. Sa signification est liée à la tâche à accomplir
  En revanche, si l’on parle d’interfaces utilisateur qui donnent l’impression d’aller plus vite, comme une barre de progression qui bouge rapidement, c’est une autre question. C’est un problème d’interface, pas de base de données

  • « Subjective » est bien le bon terme. Les tâches pertinentes dépendent du sujet
    Dire « relative » impliquerait qu’il n’existe aucun moyen d’associer un nombre à la performance autrement qu’en comparant des systèmes entre eux, ce qui n’est pas vrai

• La première web app qui a connu du succès stockait tout son état dans un dict Python et le vidait sur disque toutes les quelques minutes. C’était l’API la plus rapide que j’aie jamais vue
  Après la migration vers Mongo, les performances ne sont jamais revenues. Malgré tout, quand je crée un site web aujourd’hui, je ne prends pas « pickledb »

  • Comme alternative à fopen, SQLite est un juste milieu
  • Davantage de gens devraient envisager dès le départ une architecture résidente en mémoire + snapshots, plutôt qu’une structure de base de données transactionnelle
    Elle convient moins aux interactions utilisateur de type requête/réponse, mais pour de gros volumes de données statiques ou des flux de données rejouables traités de façon incrémentale ou par lots, je pense qu’elle devrait être plus courante qu’aujourd’hui

• Je cherche de bonnes ressources sur le sujet suivant : « Les bases de données shared-nothing sont désavantagées par rapport au shared-disk, Redshift a mis des années à basculer principalement vers une architecture shared-disk, et les Lakehouses qui stockent des métadonnées dans un stockage objet ont du mal avec les mises à jour rapides »

• Bon article. Je pense que c’est aussi l’une des raisons pour lesquelles pandas a été si fort au cours des dix dernières années
  Les performances sur une seule machine étaient suffisamment bonnes, et il pouvait lire 99 % des CSV connus de l’humanité