データベースの孤立（Isolation）レベル：弱い最適化から脱却しよう

はじめに

データの不整合（汚染）がどの程度発生しているかは開発者が認識していない可能性があります。「READ COMMITTED」が十分すぎるくらい適切である一方で、デフォルトで弱い孤立レベルを使用することは、「未熟な最適化」であり有害であるという結論に至ります。例外を除き、デフォルトとして**シリアライズ可能（Serializable）**な孤立レベルの使用を検討すべきです。

ACID プロパティと孤立の重要性

• ACID の意味
  • データベーストランザクションが持つ必須のプロパティです。
  • 「I」は「Isolation」（孤立）、すなわち並行性制御を表します。
• シリアライズ可能な孤立レベル
  • 複数のトランザクションを同時に実行した場合の結果と、順番に連続して実行（シリアル）した場合の結果が同一であることを保証します。
  • これを維持するにはパフォーマンスの犠牲が必要です。
• デフォルト設定の現状
  • 単一構成 DBMS: パフォーマンス優先のため、「READ COMMITTED」など弱いレベルがデフォルト（PostgreSQL, MySQL など）。
  • 分散型 DBMS: セキュリティ・整合性優先のため、強いレベルがデフォルト（YugabyteDB: REPEATABLE READ, CockroachDB/YDB: SERIALIZABLE など）。

微弱なバグとセキュリティリスク

弱い孤立レベルは微妙な並行性のバグを引き起こし、それがセキュリティ脆弱性へと直結することがあります。

• ビットコイン（BTC）取引所における事例では、この種のバグにより数千万ドル単位の資金が盗まれる事件が多発しました。
• 不正アクセスや認証故障ではなく、アプリケーション自体の設計欠陥によるものです。

実際的な例：オンコール医師管理システム

PostgreSQL（デフォルト：READ COMMITTED）を用いたシミュレーションです。

CREATE TABLE shift (id int, name text, on_call boolean);
INSERT INTO shift VALUES (1, 'Alice', true), (1, 'Bob', true);
SELECT * FROM shift WHERE id = 1 AND on_call; 
-- 初期状態: Alice と Bob の両方がオンコール中

シナリオ: Alice と Bob が同時にシフトを引く（on_call を false にする）場合。

UPDATE shift SET on_call = false WHERE ... name = 'Alice';

UPDATE shift SET on_call = false WHERE ... name = 'Bob';

SELECT * FROM shift WHERE id = 1; 
-- 結果: Alice と Bob の両方が `false` (off) になっている！
-- [問題点]: 病院には医師がいない状態（制約破綻）になった。

• READ COMMITTEDの場合：色分け例やシフト例のように、予期せぬデータ不整合が発生します。
• SERIALIZABLEの場合：トランザクションが順番に処理され、一人だけが引けるように制御されます（病院が空になることがありません）。

データベースベンダーによる命名規則の混乱

ベンダー独自の名付けや実装の違いにより、実際の保証レベルと名前が一致しないケースがあります。

• PostgreSQL / Oracle
  • デフォルト：

    READ COMMITTED

• MySQL (InnoDB)
  • デフォルト：

    REPEATABLE READ

  • 注意点: 読み取り専用クエリには保証が適用されず、実質的には

    READ COMMITTED

    （単調原子性ビュー）に近い挙動を示すことがあります。
• YugabyteDB
  • デフォルト：

    REPEATABLE READ

• Oracle "SERIALIZABLE"
  • 名称は「シリアライズ可能」ですが、実装は

    READ COMMITTED

    （スナップショット隔離）です。回避策が必要となります。
• Citus
  • マルチシャード環境では ACID を満たさない傾向があります。

パフォーマンスへの影響：神話か現実か？

弱い孤立レベルが常に高性能であるとは限りません。シリアライズ可能レベルのパフォーマンス劣化は過大評価されています。

研究事例からの知見

• ACIDRain (Stanford, 2017): 4 つの言語、200 万件以上のサイトで確認されたバグのうち、約 20% が孤立関連でした。
• セキュリティリスク: Flexcoin や Poloniex のハッキング事故は、並行性バグ（ロストアップデート等）が原因です。

ベンチマーク比較結果

• Postgres SSI (Serial Snapshot Isolation) 実装研究:
  • 「SERIALIZABLE」は「REPEATABLE READ」よりもわずかにパフォーマンス劣化しますが、リトライ機構で解決可能。
• TPC-C ベンチマーク (Percona 投稿):
  • 「REPEATABLE READ」対「READ COMMITTED」の比較において、業界標準の OLTP ロードではほとんど差がないことが確認されています。

アドホックトランザクションの問題

• アプリケーション側で並行性制御を実装する場合（アドホックトランザクション）でも、91 件のうち 53 件に誤りが見られました。
• 経験豊富な開発者ですらバグを起こすため、デフォルトの弱いために依存すべきではありません。
• 新しい強力なトランザクションを追加する際、既存の弱いトランザクションとの互換性を保つのは困難です。

結論と推奨事項

現在の研究とデータに基づき、以下の結論が導かれます。

1. バグは頻繁に発生する
   • デフォルト設定における並行性バグは珍しいものではなく、トランザクション関連バグの約**20%**を占めます。
2. パフォーマンスへの懸念は過剰である
   • 「SERIALIZABLE」レベルでも十分なパフォーマンスが確認されており、劇的な劣化は証拠がない。
3. 安全で堅牢なアプローチ
   • C.A.R. Hoare の言葉に学ぶように、「明らかな欠陥がないほどシンプルにすること」が設計の原則です。

アクションプラン

• デフォルトを変更する: CockroachDB や YDB など、例外を除きデフォルトをSERIALIZABLEへ設定すべきです。
• パフォーマンス検証: 強い孤立レベルを選択した場合でも、必要かどうかはパフォーマンステスト（確立された手法）で判断可能です。
• 学習推奨:
  • Martin Kleppmann: 『Designing Data-Intensive Applications』
  • Alex Petrov: 『Database Internals』
  • Franck Pachot: 『Modern SQL Databases Series: Isolation Levels』