# メインメモリデータベース ## 定義 メインメモリデータベース（Main Memory Database、MMDB）は、データベース全体を主記憶（RAM）上に常駐させることを前提として設計されたデータベースシステムである。ディスク指向の伝統的 RDBMS が前提とするページバッファプール管理・ディスク I/O を介した書き戻しを排除し、メモリへの直接アクセスで全データを操作する。OLTP ワークロードの大部分はトランザクションサイズが小さく、数千ドルのサーバの RAM に収まるデータ量であることが 2000 年代前半から観察されており、これがメインメモリデータベース設計の経済的根拠となっている。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) ### 設計上の帰結 メモリ常駐を前提とすると、以下の従来機能が不要または再設計対象になる: - **バッファプール管理**: ディスク上のページをキャッシュする層が丸ごと不要。レコードを malloc で直接確保すれば良い - **ページ指向のデータレイアウト**: ディスクブロックサイズに合わせたスロット付きページ構造が不要になり、キャッシュライン最適化されたレイアウトに変更できる - **WAL のコスト**: バッファプールへのページ書き戻し前にログをフラッシュする「ページベース WAL」から、トランザクション呼び出しのみを記録する「コマンドロギング」に軽量化できる - **B-tree の深さ**: ページサイズをディスク制約から解放し、キャッシュラインサイズに最適化した構造（cache-conscious B-tree）を採用できる ## 横断的知見 - **コマンドロギングへの置き換えはメインメモリ OLTP で最大 1.5× のスループット向上をもたらす**: ARIES 生理ロギングはメインメモリ環境で非自明なオーバーヘッドを生じる。TPC-C(9 テーブル・5 種トランザクション・多数タプル更新)では、コマンドロギングが生理ロギングより 1.5× 高いスループットを達成し、Voter でも 1.2× 高い。パフォーマンス差はディスク I/O 量だけでなく、差分ログレコード構築の CPU コストにも起因することが制御実験で確認された(ログレコードを 100 バイトに切り詰めてもスループット改善は 1%)。H-Store が「WAL を除去する」と言ったとき、その具体的手段がコマンドロギングへの置き換えであったことが初めて詳細に評価された。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **ドメイン特化インメモリ DB は ACID を捨てることで桁違いの性能改善を達成できる**: Gorilla（[[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]）は ACID 保証を不要と割り切り、ログを非 WAL 設計（64KB バッファリング）にしてクラッシュ時の数秒分データロスを許容した。その代わりに HBase 比でクエリレイテンシ 73〜350 倍削減・スループット 14 倍向上を本番で達成した。H-Store（[[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]）も単一スレッド・シェアードナッシングで汎用 RDBMS 比 82 倍達成。どちらも「何を捨てるか」の明快な設計哲学が大きな性能差を生んでいる。（Source: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]], [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]） - **ドメイン特有の物理的性質（固定間隔・隣接値の類似性）がインメモリ DB の圧縮比を決める**: 汎用 OLTP では圧縮はオプションだが、Gorilla（[[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]）では「監視メトリクスは固定間隔で到着し、隣接値が類似する」という物理的性質が圧縮アルゴリズムの中核仮定になっている。デルタ・オブ・デルタ（タイムスタンプ 96% を 1 ビット）と XOR 浮動小数点値（51% を 1 ビット）の組み合わせで 12 倍圧縮を達成し、「16TB で収まらないはず」だったデータセットをインメモリ化した。圧縮がなければメモリ常駐そのものが成立しない。（Source: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]） - **メモリ常駐だけでは 20 倍の高速化は得られない**: Shore での実測（TPC-C）によると、DB を主記憶にプリロードした段階では 640 TPS → 1,700 TPS（約 2.7 倍）にとどまる。20 倍には 4 コンポーネント全除去が必要。メモリ常駐はそれ自体ではなく、他コンポーネント除去の前提条件として機能する。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **2007 年の H-Store と 2008 年の測定の関係**: H-Store（[[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]）はメモリ常駐・単一スレッド・シェアードナッシングを組み合わせて商用 RDBMS の 82 倍のスループットを達成。[[@2008__SIGMOD__OLTP through the looking glass, and what we found there]] は Shore への段階的除去で「なぜ速くなるか」を命令数レベルで解明した。前者が実証、後者が機構分析である。(Source: 両論文) - **バッファマネージャ除去の波及効果が最大**: バッファマネージャを除去すると、新規レコード生成を malloc で直接行えるようになりレコード生成コストが事実上ゼロになる。さらに B-tree ルックアップ・更新も間接参照なしに高速化する。New Order では命令数の 34.6% 削減と最大の寄与。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **ページサイズ拡大だけで 14% の改善**: Shore のページサイズを 8KB から 32KB に変更するだけで New Order の命令数が約 14% 削減された。B-tree の深さ削減とページ確保頻度低下が原因。ディスク I/O を考慮しないメモリ常駐環境ではページサイズ増大が効果的。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **メインメモリ最適化はページ構造の放棄だけでなく、ページ構造の再工学でも進む**: 2008 年の OLTP 分解は、メモリ常駐ではディスク向け buffer manager と page layout がオーバーヘッドになることを示した。一方、B-Trees Are Back は 4 KiB の可ページング node を維持したまま、prefix truncation・heads・hints・dense leaves で cache locality と空間効率を改善する。これは「主記憶化 = page を捨てる」だけでなく、「主記憶と SSD の両方を見て page 内部を作り直す」経路があることを示す。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]], [[@2025__SIGMOD__B-Trees Are Back - Engineering Fast and Pageable Node Layouts]]) - **インメモリ並行性制御の到達点は「単一の正解」ではなく、軽量化・パーティション化・HTM の組み合わせ**: 2015 年時点のサーベイ([[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]] §1, §6)は、(i) 軽量ロック(LIL・VLL)、(ii) OCC/MVCC(Hekaton)、(iii) パーティション単位の単一スレッド逐次(H-Store)、(iv) HTM(Haswell TSX、L1 32KB 容量制約)が並立する状況を示す。同論文は「HTM + ロック + タイムスタンプ + 原子プリミティブの混在」を将来方向として推奨し、「ハードウェア支援アプローチがインメモリ環境で有利、ソフトウェア解は並列性と高速データアクセスの利点を相殺しがち」と整理する。これは [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]] の「並行性制御自体を消す」設計と表裏一体の到達点である。(Source: [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]], [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]) - **「メモリ常駐は必要条件、十分条件ではない」が複数論文で一貫**: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]] は Shore で TPC-C 主記憶常駐単独では 2.7 倍にとどまることを命令数レベルで示し、[[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]] §3.1.1 はこれを引用して H-Store の動機(従来 DB の処理時間の 90% 以上がロック・WAL・B-tree・バッファ管理に費やされる)へ結ぶ。「100 倍は理論限界、実際は重コンポーネント除去まで進めて初めて達成される」という形で、両論文は同じ主張を異なる粒度で実証する。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]], [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]]) - **データオーバーフローは「ユーザ空間 vs カーネル空間 vs ハイブリッド」の三項対立**: [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]] §6 は、H-Store Anti-Caching・Hekaton Siberia(ユーザ空間)、OS Swap・MongoDB mmap(カーネル空間)、Efficient OS Paging・UVMM(ハイブリッド)の 3 系統で整理し、「セマンティクス認識のユーザ空間とハードウェア意識のカーネル空間の両者を活用するハイブリッドが将来方向」と提示する。これは「メモリに収まらない部分をどう退避するか」が単一の正解を持たず、設計者が三項のどこに立つかを意識的に選ぶ問題であることを意味する。(Source: [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]]) ## 未解決の問い - コマンドロギングの復旧時間は 1.5×〜5× 生理ロギングより長いが、スループットがさらに向上した将来のシステムでは復旧時間がどの程度の問題になるか？レプリケーションが利用できない環境(全クラスタ障害等)ではどう対処するか？(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - Gorilla は「最新データを持つノードを先に読み取り可能にする」という部分データの積極的な公開戦略を取る。同様のアプローチを OLTP（金融・在庫等の整合性重視）ワークロードに適用する場合、どのレベルの不完全性を許容できるか？ - 主記憶に収まらない規模の OLTP ワークロードが将来も残る場合、メモリ常駐と部分ディスク利用をどう組み合わせるべきか？ - メモリ常駐環境で B-tree を廃止してハッシュテーブルに移行すると、範囲クエリ・ソートを含む TPC-C 相当のワークロードでどれだけの性能差が生じるか？ - NVM（不揮発性メモリ、Intel Optane 等）の登場により、「メモリ常駐」と「永続化」のトレードオフはどう変化するか？特に [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]] §2.5 が指摘する PCM の書き込み非対称(読み出しの 1 桁遅)・エンデュランス・順序保証は、Optane DC PMEM(2019)の実機で実際にどこまで顕在化したか? - page を残すメインメモリ最適化と、page を捨てる専用インメモリ索引は、range scan・payload storage・recovery まで含めた DBMS 全体ではどこで優劣が反転するか？ - 2015 サーベイ([[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]] §6)が将来課題として挙げた「HTM・ロック・タイムスタンプ・原子プリミティブの混在」は、その後 FaRM・DrTM・Cicada・Polaris 等でどの組み合わせが優勢になったか? - HTM の L1 32KB 制約と Intel 2014 年 TSX 無効化以降の制約は、現代の Sapphire Rapids 等で実用的な DB トランザクションサイズの上限にどう影響しているか? ## 関連 - 姉妹 concept: [[OLTPシステムアーキテクチャ]]（OLTP コンポーネントの分解）、[[専用データベースシステム]]（特化型 DBMS の大分類）、[[B-Tree]]（可ページング索引）、[[時系列データベース]]（インメモリ TSDB のユースケース）、[[コマンドロギング]]・[[ARIES]]（復旧手法の比較）、[[クラッシュリカバリ]] - 一次ソース: [[@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 のメモリ常駐・シェアードナッシング設計） - ドメイン特化実例: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]（監視特化インメモリ TSDB。ACID を捨て 12 倍圧縮でメモリ常駐を実現） - 復旧設計実験: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]（VoltDB でコマンドロギングと生理ロギングを比較） ## 出典 - [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]（メモリ常駐 OLTP の性能上限を段階的に測定した一次論文） - [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]（メモリ常駐 OLTP の完全特化設計として H-Store を提案） - [[@2025__SIGMOD__B-Trees Are Back - Engineering Fast and Pageable Node Layouts]]（B-Tree node layout の主記憶性能と out-of-memory 評価） - [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]（監視 TSDB 特化のインメモリ設計：Gorilla 圧縮・非 WAL・部分結果許容） - [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]]（基盤技術・代表系・処理フレームワーク・研究機会を 28 ページ 290 文献で網羅した教科書的サーベイ） - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]（VoltDB でのコマンドロギング vs 生理ロギングの実装・評価）