銀行でお金を引き出す方式を考えてみてください。従来の銀行システムでは、一度に一人の顧客だけが特定の口座にアクセスできます。ある顧客が取引中の場合、他のリクエストは必ず待たなければなりません。一方、現代的なATMネットワークでは、複数の顧客がそれぞれ異なるATMで同時に取引を試行できますが、同時取引の問題が発生すると「取引中にエラーが発生しました。再度お試しください」というメッセージを受け取ることになります。
この二つの方式が、まさにデータベース世界の悲観的ロックと楽観的ロックの核心的な哲学を示しています。
1970年代初頭、最初のリレーショナルデータベースが登場した時から、開発者たちは一つの根本的な問題と格闘してきました。複数のユーザーが同時に同じデータを変更しようとする時、どうやってデータの一貫性を保証するのか？
同時実行問題の発見：1970年代のジレンマ
1970年代初頭、IBM System Rが開発された当時、研究者たちはすぐに致命的な問題を発見しました。複数のユーザーが同時に同じデータを変更する時に発生する同時実行問題でした。
簡単な例で見てみましょう。1980年代の銀行システムで、二つの異なる端末から同時に同じ口座にアクセスしたらどうなるでしょうか？
このような状況を**更新損失問題（Lost Update Problem）**と呼び、1970年代からデータベース研究者たちを悩ませてきた古典的な同時実行問題です。
従来のロック：データベースと共に生まれた基本メカニズム
初期のデータベースシステムの解答は直感的で単純でした。「問題が起きる前に最初から防いでしまおう。」
この方式は最初は単純に**「ロック（Lock）」**と呼ばれていました。特別な形容詞が付かない、データベースの基本的な同時実行制御方法でした。
原理は単純でした。一つのデータには一度に一つのトランザクションだけがアクセスでき、どのトランザクションがいつアクセスするかはデータベースが自動的に管理していました。従来の銀行システムで、ある取引が口座を処理している間、他の取引が同じ口座にアクセスできないのと同じです。
悲観的ロック：既存方式に重ねられた新しい名前
「悲観的ロック（Pessimistic Locking）」という名前は、実は後から生まれた用語です。1981年に新しいアプローチである「楽観的ロック」が登場したことで、既存の従来のロック方式を区別するために「悲観的」という形容詞が重ねられたのです。
本質的には同じ方式ですが、新しい観点から見た名前を得ることになったわけです。
悲観的ロック：口座をロックする銀行
悲観的ロックでは、データベースがすべての責任を負います。リクエストが特定のデータにアクセスすると、そのデータをロックし、作業が終わるまで他のリクエストはアクセスできなくします。
開発者やユーザーは特に気を使う必要がありません。データベースが自動的に順序を決めて、正確なデータ処理を保証してくれるからです。ただし、ロックされたデータは最初のリクエストの作業が完全に終了するまでアクセス不可能で、他のリクエストは待機しなければなりません。
悲観的ロックの特徴
悲観的ロックは「競合が頻繁に起こるだろう」と仮定します。そのためデータベースがすべての同時実行制御を担当し、開発者はロックについて気を使う必要がありません。確実なデータ一貫性を保証しますが、その代わりに同時処理能力が制限されます。
1981年、哲学の転換点
1980年代半ば、システム規模が大きくなり、同時ユーザーが急増すると、従来のロッキング方式の限界が明確になりました。一度に一つのリクエストだけを処理する方式では、増加する同時アクセス要求に対応できなかったのです。
1981年、H.T. KungとJ.T. RobinsonがACM Transactions on Database Systemsに発表した論文「On Optimistic Methods for Concurrency Control」は、データベースロッキング歴史の転換点となりました。
この論文で研究者たちは、既存のロッキング方式を**「悲観的（Pessimistic）」と命名しました。競合が頻繁に起こるだろうと仮定して事前に阻止する方式だからです。そして新しいアプローチである「楽観的（Optimistic）」**方式を提案しました。競合は稀だろうと仮定し、まず作業を進めてから後で競合を検査する方式でした。
この研究を通じて初めて同時実行制御技法が二つの哲学に明確に分類され、今日まで使われている「悲観的ロック」と「楽観的ロック」という用語が誕生しました。
楽観的ロックの革新：「競合は稀である」という大胆な仮定
1981年に研究者たちが提案した楽観的ロックの核心アイデアは、既存のアプローチと正反対でした。従来のロックが「競合が頻繁に起こるから事前に防ごう」だったなら、楽観的ロックは「競合は稀に起こるから、まず進めてから後で確認しよう」という哲学でした。
楽観的ロック：実際には「ロック」ではない競合検出メカニズム
興味深いことに「楽観的ロック」という名前とは異なり、この方式は実際にはデータをロックしません。代わりに競合検出と意図的な失敗を通じて同時実行性を制御するメカニズムです。
楽観的ロックの核心目的は**「競合がほとんど発生しないデータに対してはわざわざロックをかけない」**ということです。すべてのトランザクションが自由にデータを読み、変更作業を準備できますが、実際にデータを変更しようとするトランザクションのコミット直前にのみ競合を検査します。競合が発見されると、後から試行したトランザクションを意図的に失敗させ、開発者が再試行ロジックを実装しなければなりません。
楽観的ロックの主要特徴
競合予防ではなく競合検出方式です。悲観的ロックのように事前に防ぐのではなく、競合が実際に発生した時にのみ検出して処理します。
開発者が競合処理の責任を負います。競合発生時の再試行ロジックを開発者が直接実装しなければならないため、開発複雑度が増加します。しかし競合が稀な環境では非常に効率的です。
二つのロッキング方式の現代的発展
悲観的ロックの進化：より精巧なロッキングメカニズム
従来のロッキング方式も立ち止まっていませんでした。現代の悲観的ロックは以下のように発展しました。
細分化されたロッキングによってロッキング範囲を最適化しました。テーブル全体をロックする代わりに行単位やページ単位でロックをかけて同時実行性を高めました。
効率的な待機列管理でロック待機キューとタイムアウト設定を通じて待機時間を予測できるようになりました。
また即座応答オプションでロックを即座に取得できなければ待機せずにすぐに失敗する選択権を提供します。スキップロックを通じては、すでにロックがかかっているデータは飛ばして次のデータを処理する方式も登場しました。
楽観的ロックの発展：実装方式の多様化
楽観的ロックは最初に**バージョンカラム（Version Column）**方式で実装されました。各データにバージョン番号を付与してデータ変更を追跡する方法でした。しかし時間が経つにつれて様々な実装方式が登場しました。
タイムスタンプベース方式はデータの最終更新時刻を基準に競合を検出します。チェックサムベース方式はデータ全体のハッシュ値で変更有無を確認し、全データ比較方式は読み取ったデータと現在のデータを直接比較します。**CAS（Compare-And-Swap）**方式はハードウェアレベルでサポートする原子的演算を活用してより効率的な競合検出を実装しました。
技術的発展と共に段階的検証で複数のデータを一度に変更する時により正確な競合検出が可能になり、遅延検証でトランザクション完了直前にのみ競合を確認してパフォーマンスを向上させました。
現代的選択ガイド：どのレストラン方式を選ぶか？
悲観的ロック（専用アクセス方式）が適合する場合
データベース観点から見ると、以下のような状況で悲観的ロックが有利です。
- 金融取引システム：ミスが許されない重要な取引（決済、送金）
- 在庫管理システム：同時更新が頻繁に起こる人気商品管理
- 多段階業務処理：複数の段階が順序通りに進行しなければならない複雑なトランザクション
- 高い信頼性要求：クライアントが待機してでも完璧なデータ一貫性を望む場合
楽観的ロック（競合検出方式）が適合する場合
以下のような状況では楽観的ロックが効果的です。
- 一般的なアプリケーション：高速応答が重要なほとんどのオンラインサービス
- ユーザーデータ管理：競合が稀な個人プロフィールや設定管理
- 非同期処理環境：クライアントが直接再試行ロジックを実装できる環境
- 大容量処理：多くの同時リクエストを処理しなければならない分散システム
実際のシステムでの選択：データ特性による適用
実際のシステムでは、すべてのデータに一つのロッキング方式だけを使用しません。データの特性とアクセスパターンに応じて適切な方式を選択するのが一般的です。
データ種類別戦略
個人データには楽観的ロックが効果的です。ユーザープロフィール、個人設定、個人文書などは同時変更がほとんど起こらないため、高速処理が可能です。
共有リソースの場合、悲観的ロックが必要です。在庫数量、座席予約、口座残高などは同時アクセスが頻繁であるため、正確性が優先されなければなりません。
システム規模別アプローチ
小規模システムでは単純な悲観的ロックでも十分な場合が多いです。同時ユーザーが少なくロック競合が深刻ではなく、実装と管理が単純です。
大規模システムでは状況に応じた戦略選択が重要です。データ特性とアクセスパターンを分析してテーブルや機能別に異なるロッキング戦略を適用するのが一般的です。
パフォーマンス特性：競合頻度が核心変数
二つの方式のパフォーマンスは競合発生頻度によって大きく異なります。一般的な特性は以下の通りです。
競合が稀な状況では楽観的ロックが有利です。ほとんどのトランザクションが再試行なしで成功するため、ロックを取得・解除するオーバーヘッドがなく、より高速な処理が可能です。
競合が頻繁な状況では悲観的ロックが有利です。楽観的ロックでは再試行が多くなって全体処理時間が急激に増加しますが、悲観的ロックは待機時間はあっても再試行はないため、予測可能なパフォーマンスを提供します。
転換点は通常、競合率20-30%付近で現れます。これはシステム特性と再試行コストによって変わり得ますが、この地点を超えると悲観的ロックがより効率的な場合が多いです。
結論：完璧なソリューションは存在しない
50年にわたる進化の核心的教訓は以下の通りです：
「完璧なロッキング戦略は存在しない。ユーザーと状況に合った最適な組み合わせを見つけることが核心である。」
最も重要なことは実際のデータと使用パターンを測定することです。理論的な判断よりは実際の競合発生率、応答時間、ユーザー満足度を基準に決定しなければなりません。またシステムが成長するにつれてパターンが変わる可能性があるため、継続的なモニタリングと調整が必要です。
最後に：測定と検証の重要性
1970年代のIBM研究者たちが発見した同時実行制御問題は、今日でも依然としてすべてのデータシステムの核心課題です。50年が経った今、私たちは悲観的ロックと楽観的ロックという二つの基本アプローチとその変形を活用できるようになりました。
しかし技術がいくら発展しても変わらない原則があります。測定なき最適化は推測に過ぎないということです。どのロッキング戦略が最適かは、実際のデータと使用パターンを分析してこそ知ることができます。
皆さんが次のプロジェクトでロッキング戦略を選択する時は、理論より実測を優先してください。現在のシステムの競合発生率を測定し、ユーザーの実際のアクセスパターンを分析し、小さな範囲でテストしてみてください。そしてシステムが成長するにつれてパターンが変わり得ることを記憶し、継続的に観察して調整することが真のデータベースマスタリーです。
完璧なロッキング戦略は存在しません。しかし皆さんのユーザーとシステムに最も適合する戦略は必ず見つけることができます。