Definition：Database Disaggregation
データベース・ディスアグリゲーションとは、従来モノリシックな一つのDBMSプロセスあるいは一台のサーバーに統合されていた計算（Compute）、メモリ、ログ（WAL）、ストレージといった機能・資源を、それぞれ独立したサービスないし資源プールへと分離し、ネットワークを介して疎結合に組み合わせることでDBMSを構成するアーキテクチャ原理である。
この定義には二つの側面が含まれる。第一に「機能の分離」であり、クエリ処理、トランザクション処理、同時実行制御、ログ管理、ストレージ管理といったDBMS内部の各責務を、単一のソフトウェアの内部モジュールとしてではなく、独立したコンポーネントとして切り出す点である。第二に「資源の分離」であり、CPU、メモリ、ストレージといったハードウェア資源を、DBMSインスタンスに固定的に紐づけるのではなく、独立した資源プールとして扱い、必要に応じて個別に割り当て・拡張・縮小できるようにする点である。
この結果として、Computeとストレージ、あるいはComputeの内部における読み取り・書き込み・コンパクションといった各機能、さらにはメモリまでもが、それぞれ独立にスケール可能な単位として扱われるようになる。すなわちデータベース・ディスアグリゲーションとは、「DBMSを大きくする」という発想を、「DBMSを構成する機能と資源をコンポーネント単位に分解し、ワークロードに応じて動的に組み合わせる」という発想へと転換する設計原理として定義される。
データベース・ディスアグリゲーションとは、モダン・データスタックとは切り離して捉えるべき概念であり、「DBMSそのものの分離・非集約化」を意味する。従来の「一台あるいは一クラスタのサーバーに、DBMSの計算・メモリ・ログ・ストレージを密結合させる」という構造を廃し、DBMSを複数の独立した資源プール・サービスへと分離する流れである。現在ではクラウドDBの主要な設計原理の一つとなっており、研究面でもモノリシックなDBMSをコンポーネントへ分解する方向が明確に議論されている。
従来のRDBMSでは、SQLパーサ、クエリオプティマイザ、クエリ実行、トランザクションマネージャ、同時実行制御、バッファプール、ログ、ストレージエンジン、インデックス、そしてローカルのSSDやディスクといった要素が、すべて一つのDBMSインスタンスに束縛されている。この構造では、データ量だけが増えた場合でもCPUやメモリを含めてサーバー全体を大きくする必要があり、逆にCPU負荷だけが増えた場合にもストレージ資源を抱えたまま計算資源を増強することになる。この資源の束縛こそが、クラウド環境において大きな問題として顕在化した。
データベース・ディスアグリゲーションの中心となったのが、StorageとComputeを分離するという考え方である。従来型の構成では、CPU、メモリ、DBエンジン、SSDが一台のDBサーバーに同居していたのに対し、分離型の構成では、SQL処理・オプティマイザ・トランザクション・キャッシュを担うCompute層と、WAL・データページ・レプリケーションを担うStorage層とがネットワークを介して結合される。これにより、ComputeとStorageを独立して増減させることが可能になる。
この方式を代表する初期の商用例がAmazon Auroraである。Auroraは、DBインスタンスとは独立した共有ストレージ層を持ち、複数のDBインスタンスが同一のクラスタボリュームを利用する構造を採る。AWS自身もAuroraについて、ストレージとコンピュートの分離である旨を明示している。
MicrosoftのSocratesも重要な事例である。Microsoft Researchは2019年のSIGMOD論文において、従来のモノリシックなデータベースアーキテクチャでは、クラウドのDBaaSが要求する柔軟性を十分に実現できないとし、SQL Serverを分離型アーキテクチャへ再設計したSocratesを提示した。これがAzure SQL Database Hyperscaleへとつながっている。
ここがデータベース・ディスアグリゲーションにおける技術的な要点である。単純にDBサーバーからストレージサーバーへデータをやり取りするだけでは、従来のローカルSSDより性能が劣化してしまう。そこでAuroraなどでは、データそのものを毎回ネットワーク転送するのではなく、ログを中心にストレージ側を構成するという設計が採られている。
SIGMODのデータベース・ディスアグリゲーションに関するチュートリアルでも、Auroraについて、Compute側とStorage側を分離したうえで、ネットワーク上では実データページではなくログを送ることでネットワークI/Oを削減し、Storage側でログからデータページを非同期に生成する設計が説明されている。すなわち、従来はトランザクションからバッファプールを経てデータページがディスクに書き込まれていたのに対し、分離型ではトランザクションからWALが生成され、それがネットワークを経由してストレージに送られ、ストレージ側でページが生成される。WALをデータベースの状態変化の中心に据えるこの設計が、データベース・ディスアグリゲーションの重要な鍵となっている。
データベース・ディスアグリゲーションはここからさらに進み、ストレージそのものを一つの巨大なサービスとするのではなく、WALサービス、ページサービス、キャッシュ、オブジェクトストレージ、レプリケーションといった複数の要素へと分離する段階に至る。
この段階を分かりやすく示す実例がNeonである。NeonはPostgreSQLのComputeとStorageを分離し、Compute側では通常のPostgreSQLを動作させる一方、Storage側にはPageserverとSafekeeperを配置し、さらにその先にクラウドのオブジェクトストレージを備える。PostgreSQLはWALをSafekeeperへ送信し、Pageserverがそれを処理してデータページを提供する構造である。NeonではさらにStorageを複数のPageserverへとシャーディングすることで、ストレージそのものも水平方向に拡張できるようにしている。
従来型のDBMSは、クエリ処理、トランザクション処理、同時実行制御、キャッシュ、WAL、ストレージエンジン、インデックスといった機能を一つのソフトウェアの内部に統合していた。これに対しデータベース・ディスアグリゲーションでは、クエリエンジン、トランザクション処理を担うCompute、WALサービス、そしてページ・キャッシュ・レプリケーション・オブジェクトストレージから成るStorageサービスへと、DBMS内部の責務がネットワーク越しの独立したコンポーネントへと移されていく。これが、DBMSを分解するという発想の具体的な姿である。
近年の研究では、Compute側についても一つのDBMSプロセスとして一体的に扱うのではなく、読み取り・クエリ、書き込み、トランザクション、コンパクション、バックグラウンド処理といった機能ごとに分離し、それぞれを個別にスケールさせるという発想が示されている。2024年に発表された「Disaggregated Database Management Systems」と題する論文では、ComputeとStorageの分離にとどまらず、書き込み用のCompute、クエリ用のCompute、コンパクション用のComputeを分離することまでがデータベース・ディスアグリゲーションの方向性として整理されており、さらにメモリを独立した資源として扱うディスアグリゲーテッド・メモリも対象に含まれている。ここまで来ると、「DBサーバーを大きくする」という発想そのものが変化し、CPUプール、メモリプール、ストレージプール、WALプール、クエリプールといった複数の資源プールを組み合わせてデータベースを構成するという方向へと転じていく。
データベース・ディスアグリゲーションの対象はストレージだけにとどまらない。2023年のSIGMODチュートリアルでは、Storage DisaggregationとMemory Disaggregationとが区別して扱われている。特にメモリについては、RDMA、リモートメモリ、CXL、不揮発性メモリなどを利用し、DBMSが直接所有するメモリ以外の資源を活用する方向が研究されている。すなわち、DBサーバーが自身のローカルRAMのみに依存するのではなく、Compute側からローカルRAMとリモートメモリの両方、いわゆるメモリプールを利用する構造への転換である。CXLの登場は、この方向性をさらに現実的なものにする可能性を持ち、DBMSに限らず、データセンターそのものをCPU、メモリ、ストレージなどの資源プールとして構成する方向の研究も進んでいる。
ここが現在のデータベース・ディスアグリゲーションにおいて最も重要な部分である。従来のDBMSは固定されたサーバーの上で動作することが前提であったが、クラウド環境ではAPIを通じてハードウェア資源を再構成できるため、DBMSを複数のコンポーネントに分解したうえで、ワークロードの特性に応じて効率的かつ低コストな構成を動的に組み立てるという方向が2024年の研究において示されている。CPU、RAM、ストレージといった資源プールから、ワークロードに応じて必要な資源をDBコンポーネントへ割り当てるという発想であり、これは単なるアーキテクチャの変更にとどまらず、データベース運用の考え方そのものの転換を意味している。
これまでの流れを大まかに整理すると、DBMSとサーバーが密結合していた従来型RDBMSから出発し、DBのComputeとStorageを分離したShared Storage、それを商用化したAuroraやSocrates、そしてNeonやAlloyDBに代表されるクラウドネイティブなDBへと展開してきた。さらにStorage内部がWAL、ページ、キャッシュ、オブジェクトストレージへと分離され、Compute内部もクエリ、書き込み、トランザクション、コンパクションへと分離される段階を経て、RDMAやCXL、リモートメモリを用いたメモリ・ディスアグリゲーションへと至り、現在ではDBMSを動的に構成する方向へと進んでいる。
従来型のDBMSは、SQL処理、トランザクション、同時実行制御、ストレージ、ログ、キャッシュなどを一つのDBMSとして統合して提供する設計原理を採っている。これに対しデータベース・ディスアグリゲーションは、Compute、トランザクション、WAL、ストレージ、キャッシュ、メモリなどに機能を分け、ネットワークを介して組み合わせる方向へと進んできた。ただし、これは特定の従来型DBMSを分解した結果としてAuroraやNeonが生まれたという意味ではない。むしろ、DBMS内部に機能を統合するという従来型の設計原理に対して、クラウド環境では機能と資源を分離するという別の設計原理としてデータベース・ディスアグリゲーションが発展してきた、という関係にある。
そして近年では、単なるStorage-Compute Separationを超えて、WAL、ストレージ、クエリ、書き込み、コンパクション、メモリまでもが分離対象となるところまで進んでいる。2026年に発表されたACMの論文でも、ストレージ分離型のデータベースがクラウドで広く使われるようになった一方で、ネットワーク越しのアクセスに伴うテールレイテンシが現在の重要な課題として研究されており、その対象事例としてAurora、Microsoft Socrates、Neonが挙げられている。
以上をまとめれば、データベース・ディスアグリゲーションの本質とは、DBMSを一つの巨大なソフトウェアとして動かすのではなく、DBMSを構成する処理機能と、CPU・メモリ・ストレージなどの資源とを分離し、それらをネットワーク越しの独立したコンポーネントとして組み合わせ、必要に応じて個別にスケールさせる方向への転換である。そしてこの流れは、モダン・データスタックとは別の潮流として、DBMSそのもののアーキテクチャを変えつつあるものとして捉えるのが正確である。
Mathematics is the language with which God has written the universe.