# ストレージ計算分離 ## 定義 ストレージ計算分離(Storage-Compute Disaggregation)とは、データベースシステムにおいて、クエリ処理・トランザクション実行などの「計算」と、データの永続化・複製・耐久性確保などの「ストレージ」の責務を独立したコンポーネントに分解するアーキテクチャパターンである。 分離により計算とストレージのコストを独立してスケールさせることができる。大量の計算が必要でストレージ量は少ないワークロードや、逆にストレージ容量は大きいが計算需要は低いワークロードに対して、それぞれ最適なリソース配分が可能になる。 代表的な実装: - **Amazon Aurora**: Redo ログレコードのみをストレージ層に送信し、ストレージサービスが非同期にページを実体化する。「ログがデータベース」の設計 - **Amazon MemoryDB**: インメモリ実行エンジン(Redis)の複製ストリームをマルチ AZ トランザクションログに分離し、ノードの DRAM は実行のみに専念させる - **PolarDB**: RDMA でストレージノードと計算ノードを接続。共有ストレージにより複数の読み取りノードが最新データを参照できる - **Sinfonia・Hyder**: スケールアウトサービス上のトランザクションアクセス抽象化 (Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) ## 横断的知見 - **インメモリエンジンへの分離適用は「侵襲度を最小化した統合」が鍵**: Aurora はディスクベースエンジンのストレージ I/O パスを置き換える侵襲的変更を加えたのに対し、[[Amazon MemoryDB]] は Redis の複製ストリームをインターセプトするだけで Redis コアを変更しない。これにより OSS Redis との完全 API 互換性と継続的なバージョン追従が可能になった。侵襲度と互換性のトレードオフが設計の核心となる。(Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) - **耐久性と DRAM コストを分離することでコスト最適化が可能**: MemoryDB では耐久性はトランザクションログが保証するため、ノードの DRAM は稼働中の作業集合(working set)のサイズだけに合わせれば良い。Aurora も同様に、ページバッファプールのサイズをデータセット全体のサイズと分離できる。(Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) - **オブザーバビリティストレージでは、分離の主目的が「継続的レプリケーション」ではなく「データ年齢に応じたコスト階層化(tiering)」と「バーストする読み取り計算の弾力化」の2つに分かれる**: Aurora・MemoryDB はいずれもホットな稼働系のログを常時ストレージ層へストリーミングし、耐久性とスケーラビリティを目的に分離する。これに対し Honeycomb Retriever([[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]])は、直近数分のデータのみをクエリノードのローカル SSD に置き、一定期間経過後にセグメントを圧縮して Amazon S3 へアップロードする「経過時間ベースのティアリング」でストレージ層を分離する。さらにクエリ実行そのものを AWS Lambda のサーバーレスワーカーへ MapReduce 的に委譲することで、計算層を常時稼働ノードではなくバースト可能な短命ワーカー群として分離する。Aurora/MemoryDB が「常時ストリーミングする書き込みパスの分離」を最適化するのに対し、Retriever は「経年データの読み取りパスの分離」と「読み取り計算のバースト弾力性」を最適化しており、ストレージ計算分離という同じアーキテクチャパターンが、OLTP系ワークロード(書き込み耐久性優先)とオブザーバビリティ系ワークロード(読み取りコスト・弾力性優先)で異なる目的に転用されていることを示す。(Source: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]], [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]]) - **同一書籍内の2つのオブザーバビリティ向けデータストア(Retriever・ClickHouse SharedMergeTree)が、著者自身によって「同種のアーキテクチャ的発想」と明示的に位置づけられながら、分離の実装粒度は異なる**: [[ClickHouse]] の SharedMergeTree([[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]])は、ReplicatedMergeTree(ノードごとにデータを複製)を置き換える ClickHouse Cloud 独自エンジンで、全データを単一シャードとしてオブジェクトストレージに置き、複数の計算ノードが Raft ベースの調整サービス Keeper 経由で同一シャードを並列に読み書きする。レプリカはデータのコピーを保持せず「追加のレプリカ計算」だけを提供するため、シャーディング不要でスケールゼロを含む高速なスケールアップ/ダウンが可能になる。第14章は「ClickHouse の SharedMergeTree と Honeycomb Retriever はいずれも高ボリューム分析向けにストレージと計算を分離する方法を提供し、ステートレスなクエリノードが単一のディスクに頼らず分散オブジェクトストアから読み取るという同種のアーキテクチャ的発想を共有する」と明記する。ただし実装粒度は異なる: Retriever は経過時間ベースのティアリング(ホット/コールドの物理的移動)とサーバーレスワーカーへの計算委譲という「時間軸での分離」であるのに対し、SharedMergeTree は「常時オブジェクトストレージに存在する単一の論理コピーへ、複数のステートフルではない計算ノードが同時アクセスする」という「同時アクセス軸での分離」であり、両者は同じ目的(ストレージと計算の独立スケーリング)を異なる軸で達成している。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]], [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]]) - **クラウドデータウェアハウスにおける分離は「計算 対 ストレージ」の2分割ではなく、クエリエンジン・ストレージフォーマット・テーブルフォーマット・データカタログの4コンポーネントへの分解として現れる**: 既存知見(Aurora・MemoryDB・Retriever・SharedMergeTree)はいずれも「計算ノード」と「ストレージ層(ログ・オブジェクトストレージ)」という2項対立で分離を語る。これに対しDDIA第4章は、かつてApache Hiveのような単一システムに統合されていた機能が、クエリエンジン(Trino・DataFusion)・ストレージフォーマット(Parquet・ORC)・テーブルフォーマット(Apache Iceberg・Delta——挿入削除・time travel・GCを担う)・データカタログ(Polaris・Unity Catalog——RESTで問い合わせるスタンドアロンサービス)という4つの独立コンポーネントへ分解されつつあると説明する。この4分解に照らすと、既存知見が扱ってきた「計算」は主にクエリエンジンに、「ストレージ」はストレージフォーマットに対応するが、テーブルフォーマットとデータカタログという2つの中間層は既存知見のどのソースにも明示的に登場しておらず、ストレージ計算分離という概念がOLTP文脈(Aurora・MemoryDB)よりOLAP文脈(データウェアハウス)でより細かい粒度の分解を要求することを示す。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Cloud Data Warehouses", [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]]) ## 未解決の問い - ストレージ計算分離を採用する場合、ネットワーク遅延が書き込みレイテンシのボトルネックになる。RDMA(PolarDB)・専用 AWS 内部サービス(Aurora・MemoryDB)・Ethernet(一般的)でどの程度のレイテンシ差が生じるか？ - MemoryDB はマルチ AZ トランザクションログへの同期書き込みにより書き込みレイテンシが OSS Redis より高くなる。このレイテンシコストを許容できるユースケースの境界はどこか？ - Redis のシングルスレッド処理モデルとストレージ計算分離の組み合わせでは、CPU スケーリング上限がネックになる。マルチスレッド対応エンジンへの移行余地は？ - Retriever のようにクエリ計算をサーバーレスワーカーへ委譲する分離は、Aurora/MemoryDB のような常時稼働ノード間の分離と比べてコールドスタート・テールレイテンシの面でどの程度不利か。Retriever が採用する「RPCインパーシェンス(90%完了時点で残り10%を再リクエスト)」のようなヘッジング戦略は、Aurora/MemoryDB 型の分離アーキテクチャにも適用価値があるか。 - SharedMergeTree の「単一シャード+複数計算ノードの同時読み書き」と Retriever の「時間軸ティアリング+サーバーレス計算」を同一ワークロード・同一データ量で比較した場合、コスト(オブジェクトストレージへのリクエスト課金 対 Lambda 実行課金)・レイテンシ・スケール弾力性のどこに具体的な差が生じるか。書籍はアーキテクチャ的類似性のみを指摘し定量比較はしていない。 ## 関連 - [[インメモリデータベース]] — 分離アーキテクチャが特に重要なインメモリエンジンの文脈 - [[Write-Ahead Logging (WAL)]] — Aurora の「ログのみ送信」とストレージ層でのページ実体化との関係 - [[分散 PostgreSQL]] — Aurora Limitless の分散 OLTP における分離アーキテクチャ - [[Amazon Aurora (Database)]] — ストレージ計算分離の先行事例 - [[Amazon MemoryDB]] — Redis インメモリエンジンへの分離適用事例 - [[Retriever]] — 経過時間ベースティアリング + サーバーレス計算による分離事例 - [[ClickHouse]] — SharedMergeTree による単一シャード+複数計算ノード方式の分離事例 - [[データパーティショニング]] — Retriever の時間ウィンドウ・パーティショニングとティアリングの関係 - [[列指向OLAPデータベース]] — クエリエンジン・ストレージフォーマット・テーブルフォーマット・カタログの4分解が生じる文脈 ## 出典 - [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]](MemoryDB のストレージ計算分離設計・Aurora との比較) - [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]](経過時間ベースのS3ティアリングとAWS Lambdaサーバーレスクエリ並列化による分離) - [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]](SharedMergeTreeによる単一シャード共有オブジェクトストレージ+Keeper調整の分離、Retrieverとの明示的比較) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]](§Cloud Data Warehouses — クエリエンジン/ストレージフォーマット/テーブルフォーマット/データカタログの4コンポーネント分解)