# OLTPシステムアーキテクチャ ## 定義 OLTPシステムアーキテクチャ（Online Transaction Processing System Architecture）は、短命な読み書きトランザクションを高スループットで処理するデータベースシステムの設計原則の集合である。1970 年代の System R に端を発する伝統的アーキテクチャは、ディスク常駐ストレージ・2 相ロック・WAL（Write-Ahead Logging）・マルチスレッドバッファマネージャという 4 コンポーネントを中核とする。これらは当時のハードウェア制約（主記憶容量が小さく・ディスク I/O がボトルネック）に対する合理的な設計だったが、現代のハードウェア（大容量主記憶・高速マルチコア）では不要なオーバーヘッドを生じさせる。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) ### 伝統的アーキテクチャの 4 大コンポーネント 1. **バッファマネージャ**: ディスク上のページをメモリにキャッシュし、fix/unpin で参照管理する。データベースが主記憶に収まる場合、このページ管理層は純粋なオーバーヘッドになる 2. **ロックマネージャ**: 2 相ロックでトランザクション間の並行アクセスを制御する。デッドロック検出・ロック昇格・ロック解放のロジックが全 DBMS 操作に浸透している 3. **ログマネージャ（WAL）**: Write-Ahead Logging によりページをディスクに書く前にログレコードを確実に永続化する。ページごとに LSN を管理し、バッファマネージャと密結合している 4. **ラッチ（latch）**: B-tree ノード・バッファプールメタデータ等の共有データ構造を保護する軽量ミューテックス。スレッドコードに全面的に浸透している ### 代替アーキテクチャの設計軸 | 軸 | 従来 | 代替 | 除去できる条件 | |---|---|---|---| | ストレージ | ディスク常駐 | メモリ常駐 | DB サイズが RAM に収まる | | 並行性制御 | 2 相ロック | 単一スレッド / 楽観的 CC | パーティション分割・可換トランザクション | | リカバリ | WAL | レプリカからのコピー | K-safety で他サイトが利用可能 | | マルチスレッド | 多スレッド + ラッチ | 単一スレッド / 仮想化 | ディスク待機なし・長時間クエリなし | ## 横断的知見 - **個別コンポーネントの除去だけでは不十分**: Shore での実測（TPC-C New Order）によると、バッファマネージャのみ除去で 34.6%・ロックのみで 16.3%・ログのみで 11.9%・ラッチのみで 14.2% の命令数削減にとどまる。20 倍のスループット改善には 4 コンポーネントすべての同時除去が必要。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **単一の「高い杭」は存在しない**: OLTP のボトルネックは 1 点に集中せず、ログ・ラッチ・ロック・B-tree・バッファ管理が均等に有効命令の大部分を消費する。これは「チューニングで解決できる」という誤解を否定し、アーキテクチャ全体の再設計が必要であることを示す。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **2007 年の H-Store 提案と 2008 年の測定の役割分担**: [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]] が H-Store アーキテクチャの完全再設計を提案し、本 wiki で ingested した [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]] がその根拠となる命令レベルの測定を詳細に公開した。同一著者グループによる相補的な 2 論文として読むべきである。(Source: 両論文) - **ロック vs ラッチの命令数比**: Payment では ロック(25.2%) > ラッチ(12.6%) の順だが、どちらも単独除去の効果は全コンポーネント除去に遠く及ばない。除去順序はコードの依存関係によって制約される（ロギング→ロック/ラッチ→バッファマネージャの順が必要）。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **サイクル数と命令数の乖離が設計ヒントを与える**: ログ記録はサイクル比 > 命令比（メモリアクセス多発でキャッシュミスあり）。B-tree 最適化は逆（キャッシュミスなしのオフセット計算）。この乖離は「命令数削減 = 性能改善」とはならないことを示し、メモリ階層を意識した設計の重要性を示唆する。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) ## 未解決の問い - 楽観的並行性制御は主記憶常駐ワークロードで 2 相ロックより優れるか？ 1980 年代のシミュレーション研究（ディスクストール前提）のメモリ版の再実施が必要。 - マルチコアへの対応として、トランザクショナルメモリ・仮想化・クエリ内並列性のうち、OLTP ワークロードにはどれが適切か？ - バッファマネージャを除去した後の主記憶 OLTP システムにおいて、キャッシュ最適化 B-tree（[Rao & Ross 1999, 2000]）はどれだけの改善をもたらすか？ - 主記憶 OLTP システムにおけるアクティブ-アクティブレプリケーションのコストは、従来のログシッピングと比べて実際にどの程度か？ ## 関連 - 姉妹 concept: [[メインメモリデータベース]]（メモリ常駐 OLTP の前提）、[[専用データベースシステム]]（ワークロード特化設計の大文脈） - 関連 concept: [[結果整合性]]（弱整合性の選択肢） - 一次ソース: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]（Shore の段階的分解・定量測定） - 先行提案: [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]（H-Store アーキテクチャ提案） - 関連 MOC: [[structures/分散深層学習 - MOC]] からは参照なし（別ドメイン） ## 出典 - [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]（Shore 命令数分解・20 倍スループット改善の一次測定） - [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]（H-Store アーキテクチャ提案・OLTP オーバーヘッドの設計的帰結）