# 専用データベースシステム ## 定義 専用データベースシステム（specialized database systems）とは、特定のワークロード特性に合わせてストレージ構造・クエリ処理・トランザクションモデル・可用性機構を最適化したデータベースエンジンの総称である。[[Michael Stonebraker]] が [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]] で体系的に論じた概念であり、汎用 RDBMS が全ワークロードに最適であるという「one size fits all」戦略への対立命題として位置づけられる。ストリーム処理・データウェアハウス（カラムストア）・テキスト検索・センサネットワーク・科学データベース・XML データベースなど、ワークロードごとに根本的に異なるアーキテクチャが必要だと主張する。[[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]] では、この主張を OLTP 領域で具体化し、現行 RDBMS のバッファプール・ロックマネージャ・WAL・ラッチを完全に除去した [[H-Store]] プロトタイプで 82 倍のスループット向上を実証した。 ## 横断的知見 - **Stonebraker の予見は 1〜4 年以内に実証された**: Stonebraker が 2005 年に「汎用 RDBMS は特化エンジンに敗れる」と主張した翌年に Google が Bigtable を発表し（2006 年）、2 年後に Amazon が Dynamo を発表し（2007 年）、いずれも RDBMS の ACID トランザクションやリレーショナルモデルを意図的に捨て、ワークロード特性（大規模構造化データの読み書き、高可用キーバリューストア）に特化したアーキテクチャを採用した。Stonebraker が指摘した「異なるワークロードには異なるエンジンが必要」という命題が、産業界の最大規模のシステムで追認された形である。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]) - **「一貫性を犠牲にする」判断が専用化の核心にある**: Stonebraker は ACID トランザクションがストリーム処理やウェアハウスでは不要であり、軽量セマフォやプロセスペアで十分だと論じた。Dynamo は結果整合性（eventual consistency）を採用し、Cassandra はチューナブル一貫性でこれを一般化した。いずれも、汎用 RDBMS が提供する強い一貫性保証を**意図的に弱める**ことでスケーラビリティと可用性を得ている。「どの保証を捨てるか」がワークロード特化の最も本質的な設計判断であり、これは Stonebraker のインバウンド/アウトバウンドの対比をトランザクション保証の軸に拡張したものと解釈できる。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]], [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]) - **ストレージモデルの選択がワークロード特化の第一分岐点**: Stonebraker はロウストア（OLTP 向き）対カラムストア（ウェアハウス向き）の対比を論じた。Bigtable はカラムファミリ単位の分離ストレージ、Dynamo/Cassandra は分散ハッシュテーブル上のキーバリューストレージを採用した。いずれも行指向リレーショナルストレージを否定した点で Stonebraker の主張と一致するが、選択したモデルは互いに異なる。ワークロードの読み書きパターン（スキャン主体 vs ポイントルックアップ主体）がストレージモデルを決定づけるという原則が、独立した複数の大規模システムで確認された。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]) - **「システムソフトウェアの再分割」が NoSQL 時代に現実化した**: Stonebraker はアプリケーションサーバ・DBMS・メッセージバスの 3 層分割が歴史的偶然だと指摘し、SPE がこれら 3 サービスを単一プロセスに統合すべきだと主張した。Bigtable は GFS + Chubby + SSTable を垂直統合し、Dynamo はストレージ + パーティショニング + 障害検知 + 自己修復を単一サービスとして統合した。「機能の境界をどこに引くか」がワークロードごとに異なるという洞察は、マイクロサービスアーキテクチャやクラウドネイティブデータベースの設計にも引き継がれている。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]) - **Stonebraker のビジョンは 2 年で OLTP 領域でも実証された**: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]]（2005 年）で「ストリーム処理とウェアハウスに汎用 RDBMS は不適合」と主張してから 2 年後、[[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]] で OLTP 自体（RDBMS の本丸）においてもアーキテクチャの全面再設計が必要であることを [[H-Store]] プロトタイプで実証した。ストリーム処理での 178 倍、OLTP での 82 倍という独立した 2 つの実測結果は、オーバーヘッドの種類は異なれど除去時の改善幅が同程度（2 桁）に収束するという傾向を示す。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]) - **専用化の方法論は「何を除去するか」に収斂する**: Bigtable は SQL パーサとトランザクション保証を除去し、Dynamo は固定スキーマと強一貫性を除去し、H-Store はバッファプール・ロック・WAL・ラッチを除去した。いずれも汎用 RDBMS の「標準装備」を選択的に捨てることで 1〜2 桁の性能向上を得ている。専用化とは機能の追加ではなく、不要な機能の除去であるという共通原則が 5 つの独立したシステムで確認された。(Source: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]], [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]], [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]], [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]) ## 未解決の問い - **NewSQL の位置づけ**: Google Spanner や CockroachDB は ACID + 水平スケーラビリティの両立を達成した。これは Stonebraker の「一貫性保証を捨てる専用化」に対する反証か、それとも「分散トランザクション」に特化した新たな専用化か - **ポリストアの実現可能性**: Stonebraker が示唆した「共通フロントエンドパーサの下に複数エンジン」はどこまで実用化されたか。Presto/Trino 等のフェデレーションエンジンは十分に成熟しているか - **汎用拡張 vs 専用エンジン**: PostgreSQL の拡張機構（pgvector、TimescaleDB、Citus）が専用エンジンと競合する場面が増えている。「拡張で十分な範囲」と「専用化が不可避な範囲」の境界はどこか - **[[時系列データベース]]との関係**: TSDB は Stonebraker が列挙した専用化カテゴリの一つ（センサネットワーク/モニタリング）に相当する。TSDB 分野では TSDA（汎用 KVS 上構築）と TSDBMS（専用ストレージエンジン）が共存しており、「専用化の度合い」自体にグラデーションがある - **LLM/AI ワークロード向けデータベース**: ベクトルデータベース（Pinecone、Milvus、pgvector）や特徴量ストア（Feast）は「one size fits all」批判の最新の実例か。既存 RDBMS の拡張で済む範囲はどこまでか - **H-Store のアドホッククエリ排除は正しかったか**: [[H-Store]] はストアドプロシージャのみを許容しアドホック SQL を排除した。VoltDB は後にアドホッククエリを部分的に復活させた。「完全な機能除去」と「柔軟性の維持」のトレードオフにおいて、最適な抽象化レベルはどこか ## 関連 - ソース: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]] / [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] / [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]] / [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]] / [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]] - 概念: [[時系列データベース]] / [[プロセスペア]] - エンティティ: [[Michael Stonebraker]] / [[Ugur Cetintemel]] / [[Samuel Madden]] / [[Daniel J. Abadi]] / [[H-Store]] - 関連 MOC: [[分散深層学習 - MOC]]（大規模学習基盤のストレージ選択） ## 出典 - [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]]（「one size fits all」批判の原典。ストリーム処理で 2 桁のスループット差を実測） - [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]（Google の大規模構造化データ向け専用ストレージ） - [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]（Amazon の高可用キーバリューストア。結果整合性による専用化） - [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]（OLTP 特化型 H-Store プロトタイプで汎用 RDBMS の 82 倍のスループットを実証） - [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]（Bigtable のデータモデル + Dynamo のパーティショニングを融合した分散ストレージ）