# データベースのアンバンドリング ## 定義 データベースのアンバンドリング(unbundling databases)とは、単一のデータベース製品に内蔵されているセカンダリインデックス・マテリアライズドビュー・レプリケーションログ・全文検索インデックスといった「導出データを最新に保つ機能」を、CDCとイベントログを介して複数の独立したソフトウェア(異なるチームが異なるマシン上で運用する)として分解し composeするアーキテクチャの見方である。`CREATE INDEX` の実行時にデータベースが行う処理(既存データのスキャン・導出・書き込み以降の継続的な追従)は、新しいフォロワーレプリカのセットアップやCDCのブートストラップと本質的に同じ処理であり、この視点に立つと組織全体のデータフローは1つの巨大なデータベースのように見える。バッチ・ストリーム・ETLプロセスは、この巨大データベースにおけるトリガー・ストアドプロシージャ・マテリアライズドビュー保守アルゴリズムの精巧な実装だと解釈できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Unbundling Databases", "Composing Data Storage Technologies") ## フェデレーションとアンバンドリング:融合の2つの道筋 異なるストレージ・処理技術を composeする道筋には2つある。**フェデレーテッドデータベース(federated database、polystore)**は多様なストレージエンジンへ統一的なクエリインターフェースを提供する(PostgreSQLのforeign data wrapper、Trino等のフェデレーションクエリエンジン)。これはリレーショナルの伝統(単一の高レベルクエリ言語)を踏襲し、**読み取りの統合**を扱う。一方、**アンバンドリング**は複数のストレージシステムへの**書き込みの同期**を扱う——単一データベース内で暗黙に行われるインデックス保守を、CDCやイベントログを通じて異種技術間で明示的に再現する。書き込みの同期は分散トランザクションでも実現しうるが、標準化されたトランザクションプロトコルの欠如ゆえに異種システム間では実務上困難であり、べき等なコンシューマを持つ順序付きイベントログの方がはるかに実現性が高い。フェデレーションは比較的扱いやすい問題(データモデルの写像)であるのに対し、書き込みの同期は難しい工学的問題であるため、本章はもっぱら後者に焦点を当てる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Composing Data Storage Technologies", "Making unbundling work") アンバンドリングの利点は疎結合(loose coupling)である。システムレベルでは、あるコンポーネントの障害・性能劣化がイベントログにバッファされることで局所化され、他コンポーネントへの伝播を防ぐ(分散トランザクションが局所障害を全体へエスカレートさせがちなのと対照的)。人間レベルでは、異なるチームがそれぞれのコンポーネントを独立に開発・保守できる。ただしアンバンドリングは万能薬ではなく、単一の技術で要件を満たせるならその技術をそのまま使う方が学習コスト・運用の複雑さの面で有利であり、composeの利点は「単一のソフトウェアでは要件を満たせないとき」に限って現れる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Making unbundling work", "Unbundled versus integrated systems") ## アプリケーションコードを導出関数として捉える アンバンドリングされたシステムでは、アプリケーションコードは「1つのデータセットから別のデータセットを導出する変換関数」として機能する(セカンダリインデックス・全文検索インデックスの言語処理・MLモデルの特徴抽出・UI向けキャッシュの集約はいずれも導出関数の例)。この導出処理を担うのは、データベース内蔵のトリガー・ストアドプロシージャではなく、Kubernetes・Docker等のデプロイ環境で稼働する独立したアプリケーションコードである——データベースは依存関係管理・バージョン管理・ローリングアップグレード・監視といった現代的なアプリケーション開発の要求に不向きであり、状態管理(データベース)とアプリケーションロジック(ステートレスサービス)を分離するのが現在の主流である。ストリームプロセッサと[[マイクロサービスアーキテクチャ|マイクロサービス]]は、いずれも小さな独立コンポーネントを組み合わせる点で似ているが、通信機構が対照的である——マイクロサービスは同期的なリクエスト/レスポンス(REST API)、ストリームプロセッサは一方向・非同期のメッセージストリームを使う。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Application code as a derivation function", "Separation of application code and state", "Stream processors and services") ## 横断的知見 - **Stonebraker のSPE統合論とDDIA第13章のアンバンドリング論は、同じ「アプリケーションサーバ・DBMS・メッセージバスの3層分割」を出発点にしながら逆方向の設計判断へ向かう**: [[専用データベースシステム]]が蓄積するStonebrakerの主張(2005年、One Size Fits All)は、この3層分割を「歴史的偶然」と断じ、[[H-Store]]系のSPE(ストリーム処理エンジン)がこれら3サービスを**単一プロセスへ垂直統合**すべきだと論じた——性能のために境界を消す方向である。対してDDIA第13章は、この3層分割を出発点として認めた上で、CDC・イベントログという明示的なインターフェースを介して各層を**独立したまま疎結合に保つ**べきだと論じる——組織のスケーラビリティ(異なるチームが独立に開発できること)を優先し、境界をあえて保つ方向である。両者は「性能最優先の垂直統合」と「組織スケーラビリティ最優先の疎結合」という異なる目的関数のもとで、同じ3層分割という現象に対して逆の処方箋を出しており、どちらが正しいかは目的(単一ワークロードの最大性能 vs 複数チームでの持続的な開発)に依存する。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Unbundled versus integrated systems") - **アンバンドリングと[[ストレージ計算分離]]は、いずれもデータベースの内部機能を「分解する」点で似るが、分解の軸が直交する**: ストレージ計算分離は単一の論理データベースの内部で「計算(クエリ処理)」と「ストレージ(永続化)」という2つの責務を分離し、両者を独立にスケールさせる(Aurora・MemoryDB・ClickHouse SharedMergeTree)。一方アンバンドリングは、1つのデータベースが持つ複数の**機能**(インデックス保守・マテリアライズドビュー更新・レプリケーション)を、それぞれ別の**製品**(検索エンジン・キャッシュ・データウェアハウス)へ分解する。前者は「同じデータベース内の層(レイヤー)の分離」、後者は「異なるデータベース製品間での機能の再配置」であり、両概念は同じ「データベースを要素に分解する」という語感を共有しながら、分解対象の粒度がまったく異なる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Unbundling Databases", [[ストレージ計算分離]]の既存横断的知見) ## 未解決の問い - Debezium・Kafkaのプロトコルが「事実上の標準」になりつつあるとDDIA第13章は述べるが、標準化が進むことでアンバンドリングの運用複雑さ(学習曲線・構成の複雑さ)はどこまで軽減されるか。書籍刊行後の実務動向で検証する価値がある。 - Stonebraker のSPE統合論(性能最優先の垂直統合)とDDIAのアンバンドリング論(組織スケーラビリティ最優先の疎結合)のどちらを取るべきかを判断する定量的な基準(スループット要求・チーム数・変更頻度等)は、業界で確立されているか。 - インクリメンタルビューメンテナンスエンジン(第12章で扱われた)は、アンバンドリングされたシステムにおける「マテリアライズドビュー保守」を、内蔵機能に近い体験でどこまで再現できているか。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Unbundling Databases", "Composing Data Storage Technologies", "Designing Applications Around Dataflow") - 概念: [[専用データベースシステム]](対比:垂直統合 vs 疎結合) / [[ストレージ計算分離]](対比:分解の粒度) / [[導出データ]] / [[マイクロサービスアーキテクチャ]] / [[マテリアライズドビューとデータキューブ]] - 実体: [[Apache Kafka]] / [[Debezium]] / [[Kubernetes]] / [[Docker]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Unbundling Databases", "Composing Data Storage Technologies", "Designing Applications Around Dataflow", "Unbundled versus integrated systems")