専用データベースシステム - yuuk1's Digital Garden

# 専用データベースシステム ## 定義専用データベースシステム（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 倍のスループット向上を実証した。 ## 横断的知見 - **DeWitt/Gray（1992）は「専用化 vs 汎用化」論争の前史として位置づけられる**: Stonebraker が 2005 年に「汎用 RDBMS の終焉」を宣言する 13 年前、DeWitt/Gray はシェアードナッシング並列データベースが汎用メインフレームより安価かつ高性能であることを実証し Grosch の法則を崩壊させた。「ハードウェアを問わず最適化する専用アーキテクチャ」という思想は Stonebraker の「ワークロードを問わず専用エンジンが優る」論と同型の発想を異なる軸（コモディティハードウェアの活用 vs ワークロード特化）で展開している。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]]) - **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]]) - **TSDB の専用化では「除去」に加え「ドメイン固有機能の追加」が主役になりうる**: [[Chronix]]（[[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]）は、汎用 TSDB が持たない機能——DDC（Date-Delta-Compaction：ほぼ周期的時系列の「機能的損失なし」タイムスタンプ圧縮）・汎用バイナリデータモデル（ログ・トレースを格納可能）・ビルトイン高水準解析関数（outlier・trend・frequency・sax・fastdtw）・コミッショニング方法論——を追加することで 108 GB の実運用データで汎用 TSDB 比 20〜97% の性能差を実証した。Bigtable/Dynamo/H-Store との違いは、捨てた機能（ACID・アドホック SQL・汎用スキーマ）の量より**追加したドメイン知識の密度**が性能向上の主因であること。これは Stonebraker の「不要な機能の除去」テーゼを拡張し、「**ドメイン要求に応じた機能を積む**ことが追加の専用化」という双方向の命題として完成させる。(Source: [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §1–5) - **「機能的損失なし（functionally-lossless）」はドメイン固有の許容誤差モデルを設計に組み込んだ専用化**: Chronix の DDC は「閾値内のタイムスタンプジッタを切り捨てる（値は一切省略しない）」設計を「**functionally-lossless**」と定義した。「異常検知では値の精度が必須だがタイムスタンプの絶対精度は 200ms 以内のジッタが許容範囲」というドメイン知識が設計判断の根拠である（§3・§4）。これは H-Store の「アドホック SQL を全廃してストアドプロシージャのみ」という設計と同型——ドメインが「不要」と見なすものを捨てる専用化——だが、Chronix では「不要」の定義が「機能的同等性の範囲内での近似」という形で確率的・定量的に表現されている。この「許容誤差を仕様として明示する専用化」は、汎用システムには原理的に実装できない設計パターンである。(Source: [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §3 DDC, §4 Commissioning) - **メトリクス専用エンジンでは「除去」の対象が機能ではなく協調プリミティブ自体になりうる**: Bigtable/Dynamo/H-Store の「除去」は SQL パーサ・強一貫性・バッファプールといった機能単位だったのに対し、[[Mach]]([[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]])はメトリクスワークロードが「ほぼ順序どおりの追記のみ」という性質を持つことを根拠に、複数ライター間の mutex 協調そのものを除去した(各データソースを単一ライタースレッドに固定し、疎結合(loosely coordinated)に振る舞わせる)。著者らは mutex 獲得だけで Prometheus の書き込みオーバーヘッドの約 25% を占めると指摘しており、これは「不要な機能を除去する」専用化の対象が、上位のデータモデル・保証(ACID・スキーマ)だけでなく、下位の同期プリミティブそのものにまで及びうることを示す。予備結果では既存手法比で約10倍の書き込みスループットを達成しており、Bigtable/Dynamo/H-Store が示した「1〜2桁の性能向上」パターンと同じ桁数に収束する。(Source: [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] §3.1) ## 未解決の問い - **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 の拡張で済む範囲はどこまでか - **Chronix が示した「TSDB のドメイン特化追加」は 2017 年の先例だが、現代 TSDB（InfluxDB 3.x・TimescaleDB・ClickHouse 時系列モード）はどこまでビルトイン解析とデータモデル汎化を採り込んだか** - **H-Store のアドホッククエリ排除は正しかったか**: [[H-Store]] はストアドプロシージャのみを許容しアドホック SQL を排除した。VoltDB は後にアドホッククエリを部分的に復活させた。「完全な機能除去」と「柔軟性の維持」のトレードオフにおいて、最適な抽象化レベルはどこか - **Mach の「協調除去」は他の専用化領域にも一般化できるか**: Mach はメトリクスワークロードの「ほぼ順序どおりの追記」という性質を前提に mutex 協調を除去した。この「ワークロードの順序性を前提に同期プリミティブを除去する」パターンは、ログ・イベントのような他の追記主体ワークロードにも適用できるか。それとも順序外挿入・更新が多いワークロードでは Mach 型の疎結合設計は成立しないか。 ## 関連 - ソース: [[@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]] / [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] / [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] - 概念: [[時系列データベース]] / [[プロセスペア]] - エンティティ: [[Michael Stonebraker]] / [[Ugur Cetintemel]] / [[Samuel Madden]] / [[Daniel J. Abadi]] / [[H-Store]] / [[Chronix]] / [[Mach]] - 関連 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 のパーティショニングを融合した分散ストレージ） - [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]（運用データ異常検知向けドメイン固有 TSDB。DDC・汎用データモデル・ビルトイン解析・コミッショニングで汎用 TSDB 比 20〜97% 性能差を実証） - [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]](メトリクス専用ストレージエンジン。mutex 協調の除去による疎結合アーキテクチャで既存手法比書き込み約10倍を実証)