Évaluation de MySQL 8.0.34 par Jepsen

 (jepsen.io)
3 points par GN⁺ 2023-12-20 | 1 commentaires | Partager sur WhatsApp

Contexte de MySQL

  • MySQL est l’une des bases de données SQL les plus largement déployées depuis 28 ans.
  • Il est principalement utilisé pour le traitement transactionnel en ligne (OLTP), mais aussi déployé pour l’OLAP et comme composant de systèmes de file d’attente.
  • Il a été conçu comme une base de données sur serveur unique, puis étendu via diverses méthodes de réplication multi-nœuds.
  • L’analyse se concentre sur MySQL utilisant le moteur de stockage InnoDB.

Les niveaux d’isolation ANSI SQL sont en réalité mauvais

  • Pour discuter des subtilités des niveaux d’isolation SQL, il faut expliquer le contexte historique des quatre niveaux de sécurité de cohérence transactionnelle proposés en 1977 et de la norme SQL publiée par l’ANSI en 1986.
  • ANSI SQL définit les niveaux d’isolation à travers trois phénomènes possibles (dirty read, logical pit read, phantom).
  • En 1995, les défauts des niveaux d’isolation ANSI SQL ont été soulignés, puis en 1999 Adya a développé une définition formelle et indépendante de l’implémentation des niveaux d’isolation ANSI SQL.

Les niveaux d’isolation de MySQL

  • La documentation MySQL indique fournir les quatre niveaux d’isolation transactionnelle décrits par la norme SQL:1992.
  • Elle inclut des explications sur la manière dont MySQL atteint chacun de ces niveaux d’isolation.
  • Le niveau d’isolation Repeatable Read de MySQL garantit la sécurité via un mécanisme de snapshot.

Conception des tests

  • Une suite de tests pour MySQL a été conçue à l’aide de la bibliothèque de test Jepsen.
  • Les tests ont été menés dans divers environnements, notamment un nœud MySQL unique, un cluster avec réplication binlog et des clusters AWS RDS.
  • Les principales charges de travail sur l’isolation transactionnelle ont été exécutées avec le vérificateur list-append de Elle.

Résultats

  • Le niveau Repeatable Read de MySQL autorise G2-item, pourtant interdit par le niveau d’isolation PL-2.99 d’Adya.
  • Le niveau Repeatable Read de MySQL autorise également G-single (read skew).
  • Le niveau Repeatable Read de MySQL autorise le phénomène P4 (lost update).
  • Le niveau Repeatable Read de MySQL présente des erreurs de cohérence interne.
  • Le niveau Repeatable Read de MySQL viole Monotonic Atomic View.

Avis de GN⁺

  • Le fait que le niveau d’isolation Repeatable Read de MySQL se comporte différemment de ce qui est indiqué dans la norme est une information importante pour les développeurs et les administrateurs de bases de données. Cela signifie qu’il peut ne pas répondre aux attentes en matière de cohérence et d’isolation des données.
  • Les résultats des tests fournissent des informations essentielles pour comprendre les niveaux d’isolation des systèmes de bases de données et choisir des mécanismes d’isolation adaptés.
  • Ces constats apportent un éclairage sur la manière dont les standards liés aux niveaux d’isolation des bases de données peuvent différer des implémentations réelles. Cela aide à comprendre la complexité des technologies de bases de données et les différences subtiles entre niveaux d’isolation.

À lire aussi

1 commentaires

 
GN⁺ 2023-12-20
Commentaire Hacker News

  • Je soutiens depuis longtemps que « repeatable read » est une mauvaise idée. Même si l’implémentation est parfaite et que cela fonctionne correctement dans une base de données, c’est difficile à comprendre lorsqu’on manipule des requêtes complexes.

    • Je pense que deux niveaux d’isolation seulement ont du sens :
      • read committed
      • serializable
    • Avec le mode serializable, rien d’inattendu ne se produit. Avec read committed, il est évident que si l’on veut une vue cohérente des données, il faut verrouiller les lignes avant de commencer à les lire.
    • read committed ressemble beaucoup au code multithread classique et à la gestion mémoire, donc la plupart des ingénieurs peuvent le comprendre intuitivement.
    • serializable est si strict qu’il est difficile d’y faire des erreurs inattendues.
    • Les niveaux intermédiaires sont un no man’s land, et tout ce qui est moins cohérent que Read Committed n’est plus vraiment une base de données.

  • Présentation prévue à FOSSDEM-2024 : « Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study ».

    • Étude comparative entre Oracle, MySQL, SQL Server, PostgreSQL et YugabyteDB.

  • J’évalue l’article au sujet d’AWS RDS, mais je me demande s’il se concentre aussi sur AWS Aurora (MySQL). AWS construit une plateforme de base de données qui prétend être MySQL ou PostgreSQL. Il serait intéressant de voir si Aurora MySQL présente les mêmes « fonctionnalités » que RDS ou MariaDB.

  • Je pense que c’est un excellent exemple de « systèmes qui fonctionnent réellement » construits sur une base qui présente de nombreux artefacts de cohérence.

  • Il est un peu inquiétant que la réplication RDS cesse de fonctionner au bout de 5 minutes et qu’il n’y ait aucune alerte d’échec des vérifications de santé.

  • Je me demande comment append (a) est réellement mappé aux opérations SQL dans la table donnée, et si un champ TEXT est utilisé comme liste.

    • En mode repeatable read de MySQL, il y a eu un problème où un seul SELECT sélectionnait une seule ligne et renvoyait un résultat impossible. Par exemple, dans SELECT min(value), max(value) FROM table WHERE id = 1;, alors que id est une clé primaire, j’ai déjà obtenu des valeurs différentes pour min et max.

  • Une comparaison avec d’autres bases de données relationnelles populaires comme PostgreSQL, MS SQL et Oracle, et pas seulement avec les définitions théoriques des modes d’isolation, serait utile. C’est un point que les développeurs doivent garder à l’esprit lorsqu’ils cherchent à garantir la compatibilité.

  • On dirait que SELECT ... FOR UPDATE est la réponse à tous ces problèmes : si l’on verrouille les lignes à mettre à jour, tout fonctionne comme annoncé.

  • J’avais prévu de travailler un peu aujourd’hui, mais je suis reconnaissant qu’aphyr, avec « call me maybe » et jepsen.io, ait produit certains des meilleurs contenus que j’aie lus sur Internet.

  • Je me demande quelle part de l’analyse de MySQL s’appliquerait aussi à MariaDB, qui utilise InnoDB comme moteur de stockage par défaut.