# 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]]) - **OLTP のスケールアウトには「専用再設計」と「互換拡張」の二つの道がある**: H-Store 系の議論は、メモリ常駐・単一スレッド・シェアードナッシングで伝統的 RDBMS のオーバーヘッドを取り除く方向だった。一方 Aurora Limitless は、PostgreSQL 互換性を残したままルータ/シャード分離、時刻ベース MVCC、2PC、Serverless V2、シャード分割を加える。前者は制約を強めて速くする設計、後者は既存アプリケーション資産を残して水平スケールさせる設計であり、OLTP アーキテクチャの評価軸は純粋性能だけでなく移行容易性と運用モデルを含む。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]], [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) - **クラウドネイティブ OLTP では「ネットワーク」がボトルネックとなり、伝統的な設計の 4 大コンポーネント問題は変容する**: Shore の研究([[@2008__SIGMOD__OLTP through the looking glass, and what we found there]])はバッファマネージャ・ロック・ログ・ラッチの CPU/命令コストを分析した。Aurora([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])は「I/O を複数ノードに分散するとネットワークが新ボトルネックになる」という別の問題を提起し、ログ記録の方式（ページではなくログのみをネットワーク越しに送る）を変えることで I/O を 7.7 倍削減し 35 倍のスループットを達成した。CPU コスト削減と I/O/ネットワークコスト削減は別の軸であり、クラウド分散 OLTP ではネットワーク軸が支配的になる。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]], [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **Petrov の一般的な DBMS アーキテクチャ図は、Shore の実測で除去可能と判明した4コンポーネントとほぼ一致する**: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] が提示する教科書的なストレージエンジン内訳(トランザクションマネージャ・ロックマネージャ・アクセスメソッド・バッファマネージャ・リカバリマネージャ)は、[[@2008__SIGMOD__OLTP through the looking glass, and what we found there]] が段階的除去で命令数を測定した4コンポーネント(バッファマネージャ・ロックマネージャ・ログマネージャ・ラッチ)とほぼ同じ機能分割に対応する(Petrov のロックマネージャ+トランザクションマネージャ ≒ Shore のロック+ラッチ、Petrov のリカバリマネージャ ≒ Shore のログマネージャ)。教科書レベルのアーキテクチャ記述と、除去実験で明らかになった「どのコンポーネントがオーバーヘッドか」という実証研究が同じ機能境界を指し示している点は、Shore の分解実験が特殊なシステムの癖ではなく DBMS の一般的な機能分割そのものを対象にしていたことを裏づける。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]], [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **ML実務書が挙げる「行優先ストレージゆえの分析クエリ非効率」という一文は、本conceptが命令レベルで検証するB-tree/バッファマネージャ中心のOLTP設計が暗黙に前提とする物理レイアウトを、非専門読者向けに一行で要約したものである**: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] は「それぞれのトランザクションは他のトランザクションとは別のひとつの単位として処理されるため、トランザクション型データベースは行優先であることが多く、このことは分析的な質問(複数行にまたがる列の集計)にはトランザクション型データベースが非効率的であることを意味する」と述べる。本conceptがShore実測([[@2008__SIGMOD__OLTP through the looking glass, and what we found there]])で分解するバッファマネージャ・ロックマネージャ・ログマネージャ・ラッチという4コンポーネントは、いずれも行(タプル)単位のトランザクション処理を前提にした設計であり、この行優先レイアウトの選択自体が[[列指向OLAPデータベース]]との性能特性の分岐点になる。ML実務書はこの分岐の理由(なぜ行優先か)を「トランザクションが独立した単位として処理されるため」という一文で説明するにとどまり、本conceptが持つ命令数レベルの実測的な根拠づけは持たない——非専門読者向けの直感的説明と、専門書の定量的検証が同じ結論(行優先ストレージと分析クエリの相性の悪さ)を異なる深さで支えている。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] §3.4.1, [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **OLTP/OLAPの境界の曖昧化を、CockroachDBという同一の具体例でML実務書が確認している**: 本conceptの「クラウドネイティブOLTPではネットワークが新ボトルネックになる」という知見はAmazon Auroraを主対象とするが、[[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] は図3-6で「OLAP」「OLTP」がGoogle Trends上で陳腐化しつつある用語だと述べ、その根拠としてCockroachDB(分析クエリを処理できるトランザクション型DB)とApache Iceberg・DuckDB(トランザクション型クエリを処理できる分析型DB)を挙げる。CockroachDBはAurora Limitless([[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]])と同じ「PostgreSQL互換性を保ったまま分散スケールする」設計系譜に属する製品であり、本conceptが整理する「専用再設計 対 互換拡張」という2つの道のうち後者(互換拡張)が、OLTP/OLAP境界の融解という形でも観測されていることを示す。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]] §3.4.1 図3-6, [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) ## 未解決の問い - 楽観的並行性制御は主記憶常駐ワークロードで 2 相ロックより優れるか？ 1980 年代のシミュレーション研究（ディスクストール前提）のメモリ版の再実施が必要。 - マルチコアへの対応として、トランザクショナルメモリ・仮想化・クエリ内並列性のうち、OLTP ワークロードにはどれが適切か？ - バッファマネージャを除去した後の主記憶 OLTP システムにおいて、キャッシュ最適化 B-tree（[Rao & Ross 1999, 2000]）はどれだけの改善をもたらすか？ - 主記憶 OLTP システムにおけるアクティブ-アクティブレプリケーションのコストは、従来のログシッピングと比べて実際にどの程度か？ - PostgreSQL 互換性を維持した分散 OLTP では、shard key 選択・DDL・バックアップ・外部整合性・クエリ pushdown のどれが実際の移行阻害要因になるか？ - Petrov のアーキテクチャ図が明示する「転送(クラスタ通信/クライアント通信)」層は、Shore の命令数分解には登場しない。ネットワーク層のオーバーヘッドは Amazon Aurora の測定(既存知見)以外に、Shore 型のローカル実測研究でどう扱われているか。 ## 関連 - 姉妹 concept: [[メインメモリデータベース]]（メモリ常駐 OLTP の前提）、[[専用データベースシステム]]（ワークロード特化設計の大文脈） - 関連 concept: [[結果整合性]]（弱整合性の選択肢） / [[分散 PostgreSQL]]（PostgreSQL 互換性を残す分散 OLTP） / [[コンピュートストレージ分離]]（クラウド OLTP のアーキテクチャ軸） - 一次ソース: [[@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 アーキテクチャ提案） - クラウド実装: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]（ネットワークボトルネックへの対処・ログのみ送信） - 教科書: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]]（DBMS アーキテクチャの一般図。転送・クエリプロセッサ・実行エンジン・ストレージエンジンの機能分割） / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]]（ACID・行優先ストレージ・OLTP/OLAP境界の平易な解説） - 関連 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 オーバーヘッドの設計的帰結） - [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]（PostgreSQL 互換の分散 OLTP とハイブリッドスケーリング） - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]（クラウドネイティブ OLTP のネットワークボトルネックと「ログがデータベース」設計） - [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]]（DBMS アーキテクチャの教科書的な一般図。§1.1） - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 3 データエンジニアリングの基礎知識]]（§3.4.1 ACID定義・行優先ストレージ・図3-6 OLAP/OLTP用語の陳腐化）