このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。
この記事のオリジナルは、Glenn Paulley が sybase.com に2012年5月に掲載したものです。Glenn はこの中で、SQL Anywhere で利用可能な様々なオプションを使用した場合の並行性制御とその結果について語っています。
2011年に、私は「 データベースアプリケーションのパフォーマンスにおける7つの大罪」と題したブログ記事を書きました。そして、それに続く記事として、2011年4月に「データベースアプリケーションのパフォーマンスにおける7つの大罪（続き）～ 第一の大罪 」という題で、リレーショナルモデルにおける弱い型付けに関連した問題について説明しました。
この記事では、並行性制御の影響、特に
READ UNCOMMITTED や READ COMMITTED といった弱い標準SQL 分離レベルの使用を決定する場合のトレードオフについて説明したいと思います。ブロックによる競合
SQL 標準の分離レベル [3] である
READ UNCOMMITTED(確定していないデータまで読み取る)、READ COMMITTED(確定した最新データを常に読み取る)、REPEATABLE READ(読み取り対象のデータを常に読み取る)、そして SERIALIZABLE (直列化可能)をサポートする多くの商用データベースシステムは、通常、並行トランザクションによる更新異常を避けるため、ローレベルで2 フェーズロック (2PL) を使用します。分離レベルが異なると、読み取りの動きには影響がありますが、書き込みの動きに影響はありません。
トランザクションは、まず最初にローを修正する前にそのローの排他ロックを獲得しなければならず、これはトランザクションが
COMMIT または ROLLBACK を実行するまで保持されます。そのため、別のトランザクションによるそのローへのさらなる修正を防ぐことができます。
これが、2PL のセマンティクスです。
そのため、本質的に直列実行を強制するアプリケーションを設計するのは簡単です。
私が以前書いた容量計画のホワイトペーパーの例1 が、典型的な直列実行の例です。
この例では、アプリケーションは新しい client が挿入されると以下のような SQL 文のセットを yield しながら、サロゲートキーを増やしていきます。
- UPDATE surrogate SET @x = next key, next key = next key + 1 WHERE object-type = 'client';
- INSERT INTO client VALUES(@x, ...);
- COMMIT;
サロゲートテーブル内の 'client' ロー上の排他ローロックは、トランザクションの終了まで保たれるので、このロジックは、事実上、全 client 挿入の直列化を強制します。このロジックを1つの、あるいはほんの 2・3 のトランザクションでテストするだけでは、後にパフォーマンス問題を引き起こしかねません。
この直列化が問題になるのは、スケール時のみで、全てがそうでないとしても、デッドロックを除き、並行性制御の問題です。
ロック競合によって発生した問題はパフォーマンスに大きく関係しているため、直列化を最もシビアな形式の1つとして、ロック競合をテストするのは困難です。
また、通常追加の待ちスレッドのみ yield するので、アプリケーションの並行性の程度を増すことによって問題を解決するのは難しく、以前私のメンターであった Great-West Life社のGord Steindel 氏が言っていたように－全ての CPU が同じスピードで待つ－ので、問題があるところに追加の計算パワーを投入しても、問題解決は困難です。
なぜ低い分離レベルではいけないのか?
2PLでは、書き込みトランザクションは
READ COMMITTED またはそれよりも高いレベルのものを実行している読み込みトランザクションをブロックします。これらの読み込みロックの数、そしてスコープは、
SERIALIZATION 分離レベルに移行するにつれて増加します。そしてreader やwriter のワークロードがミックスしたワークロードにおいて、直列実行を犠牲にすることで直列化可能セマンティクスを実現します。
そのため、獲得する読み込みロックの数を減らすことでパフォーマンスをより良くし、それゆえブロックの総数を減らすことと、直列トランザクションスケジュールのサーバーの保証をトレードオフするというのは、筋が通っています。
これは、通常読み込みトランザクションと書き込みトランザクションの割合が8：2の多くのアプリケーションで有意義である戦略です。
しかし、このトレードオフは無償ではありません。これは、アプリケーションを更新トランザクションの直列実行の結果発生するデータ異常にさらすという犠牲の上になりたっています。
しかし、また、これは定量化するのがとても困難です。
誰が、データベース内の陳腐化したデータに対するアクション、あるいは以前に修正されたロー（しばしば「ロストアップデート」と称される）を上書きするリスクを測定しようと試みるでしょうか?
繰り返しますが、この問題はスケールで悪化するため、典型的なアプリケーションの開発サイクルの中で、このリスクを分析し測定するのは困難です。
先週米国アリゾナ州フェニックスで開催された 2012 ACM SIGMOD Conference で、これらの課題についての最新の研究[1]が発表されました。
このカンファレンスでは、カナダ モントリオール マギル大学コンピューター科学の大学院生である Kamal Zellag と、彼のスーパーバイザーである Bettina Kemme がアプリケーション実行時にアプリケーション内で発展する直列グラフサイクルの数を測定するシステム、ConsAD を発表しました。
ここでは、サイクルは、陳腐化されたデータ、ロストアップデート、あるいは両方を含む状況を意味します。
昨年ドイツのハノーハーで開催された IEEE Data Engineering Conference でプレゼンされた全体文書 [2] を読むと、背景がわかります。
以下がその概要です。
オンラインプロセッシングのアプリケーションは、ベースとなるインフラストラクチャーが提供するトランザクショナルプロパティにたいへん依存するにも関わらず、不経済で厳密な2フェーズロッキング並行性制御が潜在的に意味するパフォーマンスを理由に、最高の分離レベル、つまり、serializability を使用しない選択がされることがよくあります。
一方で、アプリケーションサーバー層とデータベースサーバー層で構成されているモダンなトランザクションシステムでは、パフォーマンスと一貫性の間のトレードオフを提供しながら、いくつかの分離レベルを提示しています。
また、特定の分離レベルで発生する可能性のある異常の特定方法はたいへんよく知られているにも関わらず、あるアプリケーション実行時に発生する異常の量の定量化は困難です。
我々は、この問題に対して、任意の多層アプリケーションの一貫性異常をリアルタイムに検出するという新しいアプローチを発表します。
アプリケーションを実行すると、我々のツールは関連するトランザクションとデータアイテムを正確に示しながら、オンラインで異常を検出します。
さらに、発生の頻度とともにビジネスメソッドを示しながら、検出された異常をいくつかのパターンにクラス分けしていきます。
新しく投入するトランザクションタイプが、特定の分離レベルの異常の数に対していかに劇的な効果を与えることができるのか、そして、我々のツールがいかに速くこのような問題トランザクションを検出できるのかをお見せするため、RUBiS ベンチマークを使用します。
そのため、我々のシステムは、設計者の異常が発生しない分離レベルの選択にも、異常を避けるためのトランザクション設計変更にも、役に立ちます。
この研究で説明されている Java のアプリケーションシステムは、JBOSSのオブジェクトリレーショナルマッピングツールキットである Hibernate を利用しています。
このConsAD は、2つの部分から成っています。
ColAgent と呼ばれる「shim」は、アプリケーションのトレースをキャプチャーし、アプリケーションが使用するHibernate ライブラリを修正して実装されます。
そして、もう一方は、分析ピースである DetAgent で、ColAgent が作成する 直列グラフを分析し、異常を探します。
彼らの2011年の研究で、RuBis と称されるテスト中のアプリケーションにおいて、Hibernateのビルトインの楽観的並行性制御スキーム (この文書ではJOCC と称されている) を使用した場合、
READ COMMITTED を使用している2PL、あるいはPostgreSQLにおけるスナップショット分離の実装(でさえも) 異常に苦しんでいることを発見しています。2011 ICDE の文書に掲載されているこのこのグラフは、RUBiS "eBay シミュレーション" の全3種の並列制御スキーマにおける異常の頻度を示しています。
これらの実験では、スナップショット分離は、全ベンチマークサイズで継続して最少の異常を提示したことに注意してください。
これはアプリケーションアーキテクトが研究すべき特徴です。
しかし、スナップショット分離は、直列化可能性に相当するものではありません。
他の著者が [4-7] について執筆していますが、まだ、テストにおいて低頻度の異常が発生します。
このグラフは、全3つの並列性制御スキーマで発生する異常を示すだけでなく、これらの異常の頻度が、スケールとともに劇的に増加するということを示しています。
この問題の一部は、Hibernate がキャッシングを使用することにあります。
直接のローの参照は、結果としてキャッシュヒットになります。
一方、それゆえにネストされたサブクエリーを含むより複雑なクエリーまたはジョインは、データベース内の （最新の）ローのコピーに反して実行され、データの陳腐化に繋がるます。
そのため、これらの結果は、OEM ツールキットを使用しているアプリケーション開発者への警告として出す必要があります。なぜならば、負荷がかけられている場合に、彼らのアプリケーションで直面するかもしれない陳腐化した異常、そして/あるいはアップデートのことは、あったとしてもほとんど考えにないことがよくあるからです。
Kamal と Bettina が、この仕事を拡大してHibernate以外のアプリケーションフレームワークをカバーするようになると素晴らしいと思います。
先週 Phoenix にいた際に、Kamal と長話しましたが、Hibernateのマッピングモデルは、制限されていないODBC アプリケーションよりずっと簡単にこの種の分析を行うことができます。
もし存在すれば、このようなツールは別のタイプのアプリケーションでこのような異常を発見するのにも便利でしょう。
参考
[1] K. Zellag and B. Kemme (May 2012). ConsAD: a real-time consistency anomalies detector. In Proceedings of the 2012 ACM SIGMOD Conference, Phoenix, Arizona, pp. 641-644.
[2] K. Zellag and B. Kemme (April 2011). Real-Time Quantification and Classification of Consistency Anomalies in Multi-tier Architectures. In Proceedings of the 27th IEEE Conference on Data Engineering, Hannover, Germany, pp. 613-624.
[3] H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O'Neil, and P. O'Neil (May 1995). A critique of ANSI SQL isolation levels. In Proceedings of the ACM SIGMOD Conference, San Jose, California, pp. 1-10.
[4] A. Fekete (January 1999). Serialisability and snapshot isolation. In Proceedings of the Australian Database Conference, Auckland, New Zealand, pp. 201-210.
[5] A. Fekete, D. Liarokapis, E. J. O'Neil, P. E. O'Neil, and D. Shasha (2005). Making snapshot isolation serializable. ACM Transactions on Database Systems 30(2), pp. 492-528.
[6] S. Jorwekar, A. Fekete, K. Ramamritham, and S. Sudarshan (September 2007). Automating the detection of snapshot isolation anomalies. Proceedings of the 33rd International Conference on Very Large Data Bases, Vienna, Austria, pp. 1263-1274.
[7] A. Fekete, E. O'Neil, and P. O'Neil (2004). A read-only transaction anomaly under snapshot isolation. ACM SIGMOD Record 33(3), pp. 12-14.
過去のブログ記事より
- SAP Managed Tags:
