JepsenによるMySQL 8.0.34の評価

 (jepsen.io)
3 ポイント 投稿者 GN⁺ 2023-12-20 | 1件のコメント | WhatsAppで共有

MySQLの背景

  • MySQLは過去28年間で最も広く導入されてきたSQLデータベースの1つ。
  • 主にオンライン・トランザクション処理（OLTP）で使われるが、OLAPやキューイングシステムの一部としても導入されている。
  • 単一サーバーのデータベースとして設計されたが、さまざまなマルチノード複製方式へと拡張されてきた。
  • InnoDBストレージエンジンを使用するMySQLに焦点を当てて分析している。

ANSI SQLの分離レベルは実際にはよくない

  • SQLの分離レベルの微妙さを論じるため、1977年に提案されたトランザクション整合性の4つの安全レベルと、1986年にANSIが公表したSQL標準の歴史的背景を説明する必要がある。
  • ANSI SQLは、分離レベルを3つの可能な現象（ダーティリード、ノンリピータブルリード、ファントム）によって定義している。
  • 1995年にANSI SQLの分離レベルの欠陥が指摘され、1999年にAdyaはANSI SQLの分離レベルに対する形式的かつ実装非依存の定義を構築した。

MySQLの分離レベル

  • MySQLのドキュメントでは、SQL:1992標準で説明された4つのトランザクション分離レベルを提供しているとしている。
  • 各分離レベルでMySQLがどのようにそれを達成しているかの説明が含まれている。
  • MySQLのRepeatable Read分離レベルは、スナップショット機構によって安全性を保証する。

テスト設計

  • Jepsenのテストライブラリを使って、MySQL向けのテストスイートを設計。
  • 単一のMySQLノード、binlogレプリケーションクラスター、AWS RDSクラスターなど、さまざまな環境でテストを実施。
  • Elleのlist-appendチェッカーを使って、トランザクション分離に関する主要なワークロードを実行。

結果

  • MySQLのRepeatable Readは、AdyaのPL-2.99分離レベルが禁止するG2-itemを許容する。
  • MySQLのRepeatable Readは、G-single（read skew）も許容する。
  • MySQLのRepeatable Readは、P4（lost update）現象を許容する。
  • MySQLのRepeatable Readは、内部整合性エラーを示す。
  • MySQLのRepeatable Readは、Monotonic Atomic Viewに違反する。

GN⁺の見解

  • MySQLのRepeatable Read分離レベルが標準に明記されたものと異なる挙動を示すことは、開発者やデータベース管理者にとって重要な情報である。これは、データ整合性や分離に対する期待を満たせない可能性があることを意味する。
  • テスト結果は、データベースシステムの分離レベルを理解し、適切な分離メカニズムを選択するうえで不可欠な情報を提供する。
  • これらの発見は、データベースの分離レベルに関する標準が実際の実装とどのように異なりうるかについての洞察を与える。これは、データベース技術の複雑さと分離レベルの微妙な違いを理解する助けとなる。

関連記事

1件のコメント

 
GN⁺ 2023-12-20
Hacker Newsの意見

  • 長い間、"repeatable read" は悪いアイデアだと主張してきた。実装が完璧で、データベース内で正しく動作するとしても、複雑なクエリを扱う際には理解しづらい。

    • 意味がある隔離レベルは2つだと思う:
      • read committed
      • serializable
    • serializable の設定では予期しないことが起きない。read committed の方向性では、データの一貫したビューが欲しいなら、行の読み取りを始める前にロックしなければならないことが明白だ。
    • read committed は一般的なマルチスレッドコードやメモリ管理と非常によく似ており、ほとんどのエンジニアが直感的に理解できる。
    • serializable は非常に厳格なので、予期しないミスをするのが難しい。
    • 中間レベルは誰のものでもない土地であり、Read Committed より一貫性が低いものは、もはやデータベースではない。

  • FOSSDEM-2024で "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study" を発表予定。

    • Oracle、MySQL、SQL Server、PostgreSQL、YugabyteDB の比較研究。

  • AWS RDS に関する記事を評価しているが、AWS Aurora (MySQL) に焦点が当たっているのか気になる。AWS は MySQL や PostgreSQL のふりをするデータベースプラットフォームを構築している。Aurora MySQL が RDS や MariaDB のような「機能」を持っているのかを見るのは興味深いだろう。

  • 多くの一貫性アーティファクトを示す基盤の上に構築された「実際に動作するシステム」を示す素晴らしい例だと思う。

  • RDS レプリケーションが 5 分で動作を停止し、ヘルスチェック失敗の通知もないのはやや心配だ。

  • append (a) が与えられたテーブル内の実際の SQL 操作にどう対応しているのか、TEXT フィールドがリストとして使われているのか気になる。

    • MySQL の repeatable read モードでは、単一の SELECT が単一行を選択し、不可能な結果を返した問題があった。たとえば、SELECT min(value), max(value) FROM table WHERE id = 1; で、id が主キーなのに min と max に異なる値が返ったことがある。

  • 理論上の隔離モード定義との比較だけでなく、PostgreSQL、MS SQL、Oracle のような他の人気のあるリレーショナルデータベースとの比較も役に立つだろう。開発者が互換性を確保しようとするときに念頭に置くべき点だ。

  • "SELECT ... FOR UPDATE" がこれらすべての問題への答えのようだ。更新する行をロックすれば、すべてがうたわれている通りに動作する。

  • 今日は少し仕事をしようと思っていたのに、aphyr の 'call me maybe' と jepsen.io がインターネットで読んだ最高のコンテンツの一部であることに感謝している。

  • MySQL 分析のどのくらいの部分が、デフォルトのストレージエンジンとして InnoDB を使う MariaDB にも同様に当てはまるのか気になる。