Récit de RSE n ° 8: Pourquoi de terribles critiques vous conviennent!

Le conte RSE n ° 8 vient du professeur Barzan Mozafari du Michigan. Barzan dirige un groupe de recherche concevant la prochaine génération de bases de données évolutives à l'aide de modèles statistiques avancés. Récemment, leur algorithme de planification de verrouillage VATS a été adopté par MySQL et MariaDB. J'ai donc discuté avec Barzan de la manière dont le travail de VATS a été effectué. J'ai également discuté avec l'un de leurs collaborateurs industriels, Sunny Bains d'Oracle, pour comprendre le côté industrie de cette histoire. Dans l’ensemble, c’est une excellente histoire de RSE! Tout d'abord, laisse entendre Barzan:

C'était l'été 2013. Je venais juste de commencer à enseigner à l'Université du Michigan, et j'essayais de savoir sur quoi travailler. Au cours de mon postdoc au MIT, j'avais contribué à différents projets, allant de l'analyse (par exemple BlinkDB) aux transactions et à l'informatique en nuage (par exemple DBSeer) en passant par le crowdsourcing. Parmi ceux-ci, DBSeer a été de loin le défi le plus difficile que j'ai jamais affronté. Avec DBSeer, l'objectif était de prédire les performances d'un système de base de données (dans ce cas, MySQL) en fonction d'une charge de travail. Pendant près de deux ans, j'ai essayé tous les algorithmes d'apprentissage automatique du manuel. Bien que nous ayons réussi à prévoir l'utilisation des ressources (par exemple, une E / S de disque ou un processeur), nos résultats ont été médiocres en ce qui concerne la prévision du temps de latence d'une transaction.

Il y avait deux raisons fondamentales à cela. Premièrement, nous avions décidé de nous intéresser uniquement aux solutions non intrusives. Par exemple, nous allions examiner uniquement les variables de statut global de MySQL. Cela signifiait que nous n'avions pas accès à certaines statistiques critiques simplement parce que MySQL ne les exposait pas. (Le projet Peloton d’Andy Pavlo est un excellent moyen de résoudre ce premier problème en ayant accès aux ressources internes de la base de données). Mais à l'époque, notre raisonnement était que si nous pouvions y arriver, l'adoption de DBSeer deviendrait alors une évidence. La deuxième raison était beaucoup plus simple: pour commencer, MySQL n’était pas un système prévisible! Vous pouvez soumettre la même requête exactement dans les mêmes conditions plusieurs fois, et vous obtenez toujours des latences très différentes à chaque fois! Avec autant de bruit dans un signal, il n’ya pas grand chose à faire pour l’apprentissage automatique. C'est aussi simple que ça. Et je dois signaler que ce n’est pas seulement MySQL: tous les autres SGBD que nous avons examinés étaient tout aussi imprévisibles. "Lors de la conception de ces systèmes hérités, nos ancêtres étaient trop soucieux de les rendre plus rapides et n’avaient donc pas le luxe de s’inquiéter de leur prévisibilité." Ou du moins, c’est comme cela.

Je venais tout juste de commencer à Michigan et j’ai réalisé que c’était une excellente occasion de changer cela une fois pour toutes: rendons les systèmes de base de données plus prévisibles, pas seulement plus rapidement. J'avais récemment recruté Jiamin Huang, une étudiante impressionnante dotée de compétences système incroyables. Nous avons entrepris de déchiffrer ce qui pourrait causer l’imprévisibilité. Notre premier suspect était le manque de cache L2. Nous avons fait équipe avec l'un de mes collègues du matériel (Tom Wenisch) pour étudier cette question et un certain nombre d'autres causes potentielles, mais très rapidement, il était impossible de résoudre ce problème manuellement, étant donné la complexité de la base de code MySQL. Nous avons rapidement créé notre propre profileur qui, contrairement à Dtrace et à d’autres, était spécialement conçu pour rechercher les causes fondamentales de la variance des performances dans une base de code vaste et complexe. Il s'est avéré que notre profileur n'était pas spécifique aux bases de données et nous avons fini par le transformer en VProfiler, puis publié à EuroSys 2017. Il s'agissait de regarder des millions de lignes de code, puis d'informer le développeur de quelques informations nécessaires. des fonctions à utiliser pour rendre votre application prévisible.

La partie base de données de nos résultats a une histoire beaucoup plus intéressante. VProfiler a révélé un groupe de coupables d’avoir causé l’imprévisibilité. Par exemple, l’une de nos constatations est que, dans MySQL, la «cause» de la mise en file d’attente derrière des ressources partagées était la principale cause de la variance de latence. Avec le recul, c’est très intuitif: lorsque N transactions attendent dans la file d’attente la même ressource partagée, celle qui la précède connaîtra un temps d’attente très différent de celui qui se trouve à la fin de la file, et les deux va être très différent de celui au milieu de la file d'attente. C'est pourquoi ils finissent par afficher des latences très différentes pour effectuer le même travail.

En résumé, nous nous sommes concentrés sur la gestion des files d’attente et nous avons pris conscience que chaque base de données dans le monde utilisait encore une variante de FIFO (premier entré, premier sorti). Nous avons mis au point un nouvel algorithme, appelé VATS (ordonnancement de transaction basé sur la variance), et l'avons publié dans notre document SIGMOD 2017 («Une approche descendante de la prévisibilité des performances dans les systèmes de base de données»). L'un des points forts de cette analyse est que la prévisibilité ne doit pas nécessairement aller au prix de la performance moyenne. En d'autres termes, il existe un moyen de rendre les systèmes plus prévisibles tout en les rendant plus rapides: en réduisant la variance basée sur les conflits.

Plus tard, nous avons formulé le problème général de la planification des verrous. Nous avons exploré un nouvel algorithme différent, optimal pour réduire le temps de latence moyen (et augmentant le débit), publié dans VLDB 2018 («Planification du verrouillage en présence de conflits pour les bases de données transactionnelles»). Nous avons appelé ce nouvel algorithme VATS 3.0 (nous n’avons jamais publié VATS 2.0), que nous avons appelé plus tard CATS (Planification des transactions en contention).

Planification des transactions prenant en compte le conflit: l'octroi du verrou sur O1 à t1 active davantage de parallélisme (réduit davantage de conflits) que de l'attribuer à t2

Du point de vue de l’adoption par l’industrie, les choses se sont déroulées sans encombre: MySQL et MariaDB ont tous deux exécuté leurs propres tests avec notre nouvel algorithme et ont décidé de l’adopter dans leurs versions autonomes (MySQL en a même fait leur stratégie par défaut). Nous sommes reconnaissants à tous nos collaborateurs open source de la communauté MySQL, notamment à Jan Lindstrom (MariaDB), Sunny Bains et Dimitri Kravtchuk (Oracle), Laurynas Biveinis et Alexey Stroganov (Percona), Mark Callaghan ( Facebook) et Daniel Black (IBM).

Du point de vue académique, cependant, les choses ne se sont pas passées aussi facilement. Voici une chronologie de ce qui s'est passé:

Avertissement: Certains noms / années de conférence peuvent avoir été différents

  • SIGMOD’16: Nous avons soumis nos résultats MySQL.
  • Rejet: "Comment savons-nous si cela fonctionne pour autre chose que MySQL?"

Commentaire: Il est intéressant de noter que vous ne recevez des commentaires comme celui-ci que lorsque vous appliquez votre idée à un système réel. Si vous concevez simplement votre idée à partir d'un modèle et créez une base de données sur maquette, personne ne vous demandera généralement si elle s'applique à d'autres systèmes réels! Sans se laisser décourager par ces commentaires, mon élève a décidé de prouver que la critique avait tort…

  • VLDB’16: Nous avons également appliqué VProfile à Postgres et à VoltDB.
  • Rejet: "Si ce problème était suffisamment important, quelqu'un d'autre l'aurait déjà fait!"

Commentaire: À ce jour, cela reste l'un de mes commentaires préférés! Recevoir une critique injuste n’est jamais amusant, mais celui-ci était si ridicule que cela ne nous a pas dérangés - en fait, nous avons trouvé cela assez amusant. Bien que nous souhaitons avoir eu l’occasion de poser deux questions à cet auteur:

1) L’examinateur mesure-t-il ses propres recherches par rapport à la même barre? (Nous savons que c'était un “il”; voir la leçon 5.)

2) Comment pourrions-nous jamais progresser dans la recherche en appliquant ce principe? Si quelque chose a déjà été fait, alors ce n'est pas nouveau et publiable, et si cela n'a pas été fait, alors ce n'est tout simplement pas assez important et il ne faut en aucun cas les publier!

  • OSDI’16: Néanmoins, mon élève a décidé une fois de plus de prouver que le relecteur avait tort et de prouver que le problème était réel. Nous avons donc envoyé nos algorithmes et nos résultats à MariaDB et à MySQL. MySQL a choisi VATS comme planification par défaut et nous l’avons mentionné dans le document.
  • Rejet: «Vous avez appliqué VProfiler à MySQL, Postgres et VoltDB. Comment savons-nous si cela fonctionne pour autre chose qu'un SGBD? ”

Commentaire: C'était une préoccupation légitime. Après tout, OSDI est une conférence de système d'exploitation. En fait, nous avons été très satisfaits de la qualité des commentaires reçus. En tant que chercheur DB, j’envie toujours la communauté des systèmes d’exploitation pour son système d’examen nettement meilleur.

  • SIGMOD’17: Nous avons soumis VATS et d’autres résultats de base de données.
  • Acceptez! Finalement!
  • EuroSys’17: Nous avons généralisé notre profileur, qui est devenu plus tard VProfiler et s’applique au serveur Web Apache en plus des systèmes de base de données.
  • Acceptez! Yay!
  • VLDB’18: Enfin, une fois que nous avons réussi à formaliser le problème de planification des verrous, nous avons également réussi à résoudre le problème des performances (et pas seulement de la prévisibilité). Ceci est devenu l'algorithme CATS.
  • Acceptez. Nous avons eu d'excellentes critiques de VLDB’18. Nous avons également reçu des commentaires exceptionnels de Peter Bailis après la publication du document.

Donc, voici quelques leçons de ce long post:

Leçon 1. Les critiques terribles sont réellement bonnes pour vous. Ils vous poussent (et votre étudiant!) À faire plus de travail, ce qui n’est pas un mauvais résultat!

Leçon 2. Ne faites pas confiance à ce que les gens disent sur les panneaux. Même si tous les universitaires déclarent systématiquement valoriser l'impact et les validations réelles, certains mentent parfois inconsciemment. Lorsqu'ils portent leur casquette de critique, ils pénalisent souvent les articles qui utilisent un véritable système d'évaluation, par exemple, en demandant un milliard d'autres choses qui ne seraient possibles que si vous utilisiez un prototype de simulation. Je ne veux pas dire que vous devriez renoncer à utiliser de vrais systèmes dans vos expériences, mais simplement vous préparer à faire plus de travail!

Leçon 3. Les universités et l'industrie ont des longueurs d'onde différentes. Pour ceux d'entre nous qui sommes dans le monde universitaire, trois mois sont une éternité. Cependant, les équipes de produits fonctionnent sur leur propre calendrier - il faut parfois jusqu'à un an avant de pouvoir vous proposer des cycles. Il vous suffit d'être patient et d'apprécier l'excellent travail qu'ils font pour maintenir un éco-système open source de haute qualité.

Leçon 4. Tous les lecteurs ne sont pas des mathématiciens. Dans l'une de nos précédentes communications, nous rapportions le pourcentage de la variance totale que nous avions éliminé, ce qui était d'environ 65%. Évidemment, vous ne pouvez rien éliminer de plus de 100%. Malheureusement, il ne s’agit que d’une limitation des lois mathématiques. Mais l’un de nos examens (je pense que SIGMOD’16 ou VLDB’16) était d’avis que la réduction de 65% n’était pas assez significative. Dans notre prochaine soumission, nous avons donc commencé à signaler le rapport d'amélioration, défini comme étant la variance du MySQL d'origine divisée par la variance de notre version modifiée. Cette même réduction de 65% était maintenant rapportée comme une réduction de la variance 3x, et les examinateurs (bien que probablement des personnes différentes) étaient plus heureux cette fois-ci.

Leçon 5. Soyez gentil ou soyez anonyme. Cela s’applique à notre critique préféré: si vous envisagez de rédiger une critique désagréable, ce n’est probablement pas une bonne idée de demander aux auteurs de citer trois de vos propres articles. Le maintien de votre anonymat ne vous convient pas ☺

Leçon 6. Travailler sur de vrais systèmes est une tâche difficile, mais cela en vaut la peine. Si vous êtes prêt à accepter de mauvaises critiques et un délai d’exécution beaucoup plus long, travailler sur de vrais systèmes est une expérience extrêmement enrichissante!

Passons au point de vue industriel sur ce travail. J'ai discuté avec Sunny Bains d'Oracle, qui a joué un rôle déterminant dans l'adoption de VATS dans MySQL / InnoDB. Je présente ma conversation avec lui sous forme de questions et réponses.

CSRTales: Comment avez-vous découvert le travail de CATS?

Sunny: IIRC Barzan et Jiamin ont publié un document contenant des points de repère. Ce document m'a été transmis par un membre de notre organisation. Ils ont ensuite fourni un patch qui est ce qui m'a intéressé. Verrouiller nécessite toujours une optimisation, et à ce moment-là, nous cherchions à optimiser le gestionnaire de verrous InnoDB. C'était donc très opportun. CATS, comme on l'appelait alors, semblait être un candidat prometteur à examiner. À ce stade, nous nous sommes concentrés trop étroitement sur la distribution uniforme et n’avons constaté aucun gain. En outre, l'accent a été mis sur la résolution d'autres problèmes à l'intérieur d'InnoDB. Une fois que nous avions trouvé de bonnes solutions pour d’autres problèmes liés à la gestion des transactions au sein d’InnoDB, les problèmes de verrouillage sont à nouveau au premier plan. L'équipe InnoDB a recommencé à regarder CATS et, comme par hasard, Mark Callaghan de Facebook m'a envoyé un courrier électronique dès le lendemain, me présentant Barzan et Jiamin. Une collaboration plus étroite a commencé par la suite et grâce à la communication directe et à l’aide apportée, l’a été à la baisse.

CSRTales: Qu'avez-vous préféré dans l'idée de CATS lorsque vous en avez entendu parler?

Sunny: Cela résolvait un problème réel et le contenu lui-même était très général et je pense qu'il a des applications au-delà du gestionnaire de verrous. Il est tout aussi important, d’un point de vue pratique, d’avoir une preuve de concept. Un patch que nous pourrions tester tout de suite. Il y a beaucoup de bonnes idées qui circulent. Avoir quelque chose de concret à tester est un énorme avantage. Cela nous fait économiser beaucoup de temps et de ressources. Je pense aussi que c'est l'un des avantages des logiciels open source. C'est un très bon exemple de cela.

CSRTales: Combien de temps a-t-il fallu de la première audience au travail pour le fusionner?

Sunny: Cela a pris environ un an, je pense. À partir du moment où nous avons décidé de nous engager et jusqu'au moment où cela a été poussé, il a fallu six mois. Notre processus d’AQ est très rigoureux et je ne saurais trop remercier notre AQ. Il y avait quelques bugs dans le correctif d'origine. Nous avons décidé de le réécrire aussi. Nous souhaitons également réduire le nombre de variables de configuration en tant que stratégie. Il y avait quelques problèmes avec les verrous d'espacement qui devaient être corrigés dans le correctif.

CSRTales: En règle générale, dans les communautés open-source telles que le noyau Linux, votre crédibilité doit déjà être créée avant que vos correctifs ne soient acceptés. Je suppose que quelque chose de similaire est arrivé ici?

Sunny: bien sur. Nous recevons pas mal de correctifs / contributions. Mais je voudrais souligner que ce n'est pas une condition préalable. Nous sommes ouverts à l’acceptation de correctifs qui fonctionnent immédiatement et avons une documentation qui montre le problème et explique comment les correctifs résolvent ces problèmes. Nous souhaitons sincèrement encourager les chercheurs / utilisateurs / développeurs, tous ceux qui s'intéressent à ce domaine, à tirer parti des avantages de l’open source et à nous envoyer leurs correctifs. Je tiens à souligner, parler est bon marché. Montre moi le code :-)

CSRTales: Est-il pratique courante de réécrire les correctifs apportés?

Sunny: Oui, une fois que nous décidons de nous engager dans un travail, nous préférons qu'il soit entièrement effectué au sein de l'équipe. Il y a des raisons pratiques à cela. Le processus d'assurance qualité est assez intense et il existe toute une infrastructure autour des révisions de code et du suivi des problèmes, auxquelles les étrangers ne peuvent pas accéder. De plus, la personne qui valide le code doit en assumer la responsabilité pour les corrections de bogues ultérieures, etc. C’est principalement pour des raisons pratiques que nous ne faisons pas appel à des auteurs originaux pour qu’ils effectuent le travail au fur et à mesure de son avancement. Nous (en fait je l'ai fait) avons réécrit le patch. Il y avait un échange constant de courriels entre Jiamin, Dimitri, Barzan et moi-même pour discuter des problèmes. Dimitri est notre architecte de performance. Leur contribution a été très utile pour nous assurer que nous avions tous le même modèle mental autour de leurs idées.

Je voudrais souligner plusieurs choses intéressantes dans ce CSRTale. Tout d’abord, c’est un excellent exemple de la façon de faire adopter le secteur. Barzan et son groupe ont fourni un patch pouvant être testé directement. C'est crucial. Deuxièmement, Barzan et son groupe ont passé beaucoup de temps à discuter de leur idée avec Sunny pour s’assurer qu’ils étaient sur la même page. Le transfert de technologie prend beaucoup de temps, au-delà du temps consacré à la publication du document. Si vous recherchez un impact, c'est un excellent chemin, mais soyez conscient du coût en temps. Troisièmement, l'examen de la qualité n'est pas très cohérent dans la communauté des systèmes au sens large. J'ai vu des critiques similaires à celles que Barzan a reçues: certains critiques (heureusement) se sont d'abord décidés, puis ont essayé de trouver une quelconque excuse pour rejeter le journal. Ainsi, parfois, les critiques sont des signaux très bruyants: vous pourriez penser que si vous corrigiez ce que le réviseur demandait, vous seriez accepté, mais ce n'est pas souvent le cas. Il se peut qu’il y ait d’autres faiblesses dans votre document que vous feriez mieux de passer votre temps à réparer. Par exemple, si les idées de votre document ne sont pas clairement exprimées, un critique peut ne pas aimer votre document et se plaindre de l’évaluation. Corriger l'évaluation (sans corriger l'écriture) n'améliorerait pas vos chances d'être accepté. Parlez-en à vos conseillers :)