データ集約型アプリケーションの設計 (Japanese Edition), 2nd Edition

第8章 トランザクション

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

一部の著者は、一般的な二相コミットはパフォーマンスや可用性の問題を引き起こすため、サポートするにはコストがかかりすぎると主張している。我々は、トランザクションの過剰使用によるパフォーマンス問題を、ボトルネックが発生した時点でアプリケーションプログラマが対処する方が、常にトランザクション不足を回避するコーディングを行うよりも良いと考えている。

James Corbett et al., “Spanner: Google’s Globally-Distributed Database” (2012)

データシステムの厳しい現実では、多くの問題が発生しうる：

• データベースソフトウェアやハードウェアはいつでも故障する可能性がある（書き込み操作の途中も含む）。

• アプリケーションはいつでもクラッシュする可能性がある（一連の操作の途中も含む）。

• ネットワークの中断により、アプリケーションとデータベース、あるいはデータベースノード間の接続が予期せず切断されることがある。

• 複数のクライアントが同時にデータベースに書き込みを行い、互いの変更を上書きする可能性がある。

• クライアントが、更新が部分的にしか行われていないために意味をなさないデータを読み込む可能性がある。

• クライアント間の競合状態は、予期せぬバグを引き起こす可能性がある。

信頼性を確保するには、システムはこれら全ての障害に対処し、致命的な失敗を引き起こさないようにしなければならない。しかし、耐障害性メカニズムの実装は膨大な作業を要する。起こりうるあらゆる問題について慎重に検討し、実装した解決策が実際に機能することを確認するための厳密なテストが必要だ。

数十年にわたり、トランザクションはこれらの問題を簡素化する手段として選ばれてきた。トランザクションとは、アプリケーションが複数の読み取りと書き込みを論理的な単位にまとめる方法である。概念的には、トランザクション内の全ての読み取りと書き込みは単一の操作として実行される。トランザクション全体が成功すればコミットとなり、失敗すればアボートまたはロールバックとなる。失敗した場合、アプリケーションは安全に再試行できる。 トランザクションを用いることで、アプリケーションのエラー処理は大幅に簡素化される。なぜなら、部分的な失敗（何らかの理由で一部の操作が成功し、一部が失敗する状態）を気にする必要がなくなるからだ。

トランザクションに慣れている者にとっては当然のように思えるかもしれないが、これを当然視すべきではない。トランザクションは自然法則ではない。データベースにアクセスするアプリケーションのプログラミングモデルを簡素化するという目的で生み出されたものである。 トランザクションを利用することで、アプリケーションは特定の潜在的なエラーシナリオや並行処理問題を無視できる。なぜならデータベースが代わりにそれらを処理するからだ（これを安全性の保証と呼ぶ）。

全てのアプリケーションがトランザクションを必要とするわけではなく、時にはトランザクション保証を弱めたり完全に放棄したりする利点もある（例えば、より良いパフォーマンスや高い可用性を達成するため）。 安全性の特性の中には、トランザクションなしで達成できるものもある。一方で、トランザクションは多くのトラブルを防ぐことができる。例えば、郵便局のホライゾンスキャンダルの技術的要因（ ...