# 専用データベースシステム ## 定義 専用データベースシステム（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) - **『詳説 データベース』第I部序論は、Stonebraker の「one size fits all批判」を裏付ける一般原則を、個別システムの実装事例とは独立に教科書的な形で定式化する。** 同書は「考えうる限りのユースケースにとって完全に最適なストレージエンジンが存在すれば、誰もがそれを使用するでしょう。しかし、実際には存在しない」と述べ、都市計画(人口密度の高い垂直方向の建築 対 より広い地域をカバーする水平方向の建築)との類推を用いて、ストレージエンジン開発者の設計判断が読み取り/書き込みレイテンシの低さ・データ密度(ノードごとの格納量)の最大化・管理上の単純さという複数の軸のどれを重視するかによって、適合する状況が異なると論じる。Bigtable(構造化データの読み書き最適化)・Dynamo(高可用性)・H-Store(OLTPレイテンシ)・Mach(メトリクス書き込みスループット)がそれぞれ異なる軸を重視して機能を除去した実例は、この教科書的な三分類(レイテンシ・データ密度・管理単純さ)のいずれかに対応づけられる。個別事例の帰納から導かれた既存の横断的知見(「専用化とは機能の除去である」)に対し、本書は演繹的な設計トレードオフの語彙(3つの最適化軸)を与える点で相補的である。(Source: [[@2021__OReillyJapan__詳説 データベース - Part I 序論 ストレージエンジン]] I.2, [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]) - **1章の OLTP/OLAP/HTAP という教科書的3分類そのものが「唯一の正しい分類は存在しない」という留保つきで提示されており、Part I 序論が定式化する『完全に最適なストレージエンジンは存在しない』というテーゼを分類論のレベルで裏づける**: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] は OLTP・OLAP・HTAP の3分類を挙げつつ、「これはデータベース管理システムの完全な分類ではなく、これら以外にも分類方法は数多く存在する」と明言し、key-value ストア・リレーショナルデータベース・ドキュメント指向ストア・グラフデータベース等の個別定義には立ち入らないと述べる。これは Part I 序論(既存知見)が示す「考えうる限りのユースケースにとって完全に最適なストレージエンジンが存在すれば誰もがそれを使うが、実際には存在しない」というテーゼと同型の留保であり、同一書籍の連続する2つの導入部が「単一の分類軸・単一の最適解は存在しない」という立場を、それぞれ独立に(分類論のレベルと設計トレードオフのレベルで)表明していることを示す。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]], [[@2021__OReillyJapan__詳説 データベース - Part I 序論 ストレージエンジン]]) - **Stonebraker 自身が2024年に「専用化の勝利は一時的だった」と自己修正した——20年前の予見の的中と、その後の収斂の両方を同一著者が観察した稀有な事例**: [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] は、本ページが蓄積してきた「2005〜2007年のStonebrakerの予見が1〜4年で実証された」という既存知見の**続き**を提供する。Bigtable(2006)・Dynamo(2007)がRDBMSのACID/RMを捨てて専用化に成功した直後の物語だけでなく、その後2010年代末までにDynamoDB・Cassandra・Aerospike・Couchbase・MongoDBという主要NoSQLベンダーが**全て**SQLライクなインターフェースとACIDトランザクションを再獲得したことを著者自身が報告している。これは「機能の除去による専用化」(既存知見)が、市場で長期的に生き残るには「除去した機能の選択的な再獲得」を伴うという、専用化のライフサイクルの後半局面を示す一次証拠であり、H-Store/Bigtable/Dynamoの成功だけを見ていた従来の横断的知見に「専用化の勝利は永続的ではなく、収斂圧力にさらされ続ける」という時間軸を追加する。(Source: [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §2.2–2.4) - **除去された機能の中で「SQL/ACID」と「ワイドカラム/BigTable系ストレージ構造」は収斂の速度が異なる——収斂は均質に進まない**: 2024年論文は、ドキュメントDB(MongoDB等)・KVストア(DynamoDB等)がSQLインターフェースを獲得した一方、カラムファミリモデル(BigTable・Cassandra・HBase)は「NoSQLと同じ不利益を抱えたまま取り残された唯一の外れ値」だと明言する。これは、Bigtable/Dynamo/Cassandraを並列に扱ってきた既存知見(「専用化の方法論は除去に収斂する」)に対し、除去した機能の**種類**によってその後の収斂しやすさが異なるという反例を示す。データモデル層(ドキュメント・KV)はSQL化しやすいが、ストレージ構造層(カラムファミリという物理配置そのもの)はSQL化しても本質的な差別化が残りにくく市場から取り残されやすい、という仮説が浮かぶ。(Source: [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §2.4) - **専用化カテゴリの新設(ベクトルDB)は「除去」でなく「索引の追加」に過ぎず、既存知見の適用範囲外にある**: 2024年論文は、ベクトルDBを「ANN索引を特徴とするドキュメント指向DBMS」であり、H-Store/Bigtable/Dynamo/Chronix/Machのような「不要な機能を除去する」専用化とは異なる種類の変化(索引構造の追加)だと位置づける。この区別は、本ページが蓄積してきた「専用化とは機能の除去である」というテーゼが、実は専用化の一部の類型(ストレージ/協調プリミティブレベルの除去)にしか当てはまらず、索引レベルの専用化(ベクトルDB・全文検索エンジン)には別の分析軸が必要であることを示す。既存RDBMSがpgVector等のOSSライブラリ統合によってベクトル索引を1年以内に取り込んだという事実は、「索引の追加」型専用化は「機能の除去」型専用化よりも汎用RDBMSへの再吸収が起きやすいという非対称性を示唆する。(Source: [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §2.7) - **クラウド化による共有ディスクアーキテクチャの復権は、Stonebrakerが2007年に主張した「共有ナッシングへの専用化」の逆転として観察される**: 本ページが既存知見として蓄積する「Bigtable/Dynamo/H-Storeはいずれも行指向リレーショナルストレージ・共有ナッシング構造を選んだ」というパターンに対し、2024年論文§3.2は、ネットワーク帯域の向上とオブジェクトストア(S3等)の普及により、マルチノード共有ディスクアーキテクチャ(歴史的には失敗した古いアイデア)がクラウドで復権しつつあり、著者らは「共有ナッシングの再浮上は今後ない」とまで予測すると報告する。これは「専用化=特定ハードウェア前提への最適化」という軸において、ハードウェア環境(ネットワーク帯域)そのものが変化すれば、過去に淘汰されたアーキテクチャが再び最適解になりうることを示し、専用化の判断が固定的でなく環境依存であることを裏付ける新たな一次証拠である。(Source: [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §3.2) - **『ウェブオペレーション』15章(2011年)は、Stonebraker流の学術的専用化論(2005〜2007年)とほぼ同時期に、実務家自身が独立に到達した「NoSQLの5分類」という帰納的な専用化の地図を提示している**: 本ページはこれまでBigtable(2006)・Dynamo(2007)・H-Store(2007)というアカデミアの一次システムから「専用化とは機能の除去である」というテーゼを積み上げてきたが、15章はこれらの学術的主張を一切引用せず、実務者(Eric Florenzano)が2010年前後の現場観察から独自に「NoSQL はキーバリュー型・データ構造型・グラフ型・ドキュメント指向型・高分散型の5つに分類できる」という帰納的な地図を描く。この5分類は、Stonebraker(2005年)が挙げたストリーム処理・データウェアハウス・テキスト検索・センサネットワーク・科学データベース・XMLデータベースという専用化カテゴリとは軸が異なり(Stonebrakerは学術的ベンチマークが可能なワークロード特性で分類するのに対し、15章はデータモデルの形状で分類する)、同じ「one size fits allは成立しない」という認識に、理論(Stonebraker)と実務(Florenzano)がほぼ同時期に独立に到達したことを示す。15章が高分散型データベース(Cassandra・HBase・Riak)について「一貫性を犠牲にして、可用性と分割耐性を保証するものが多い」と述べる箇所は、本ページの既存知見が示す「一貫性を犠牲にする判断が専用化の核心にある」というテーゼの、実務者による独立した言い換えである。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.1, §15.1.5, [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]]) - **15章の結論(「NoSQLの時代はまだ始まったばかり」)は、2024年のStonebraker自己修正(専用化は市場で長期的に収斂する)を待たずして、2011年時点で既に「この専用化地図は暫定的である」という留保を実務者自身が明言していた一次証拠である**: 本ページは既存知見として、Stonebraker自身が2024年の論文([[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]])で「専用化の勝利は一時的だった」と自己修正し、DynamoDB・Cassandra・MongoDB等がSQLライクなインターフェースとACIDトランザクションを再獲得したことを報告している事実を蓄積してきた。15章はこの13年前の時点で「これから先、ここで紹介したデータベースが消えてしまったり、新しく出てきたものと入れ替わったりするかもしれない。データベースの成熟度は今後も高まっていくだろうが、それを決めるのは、実際の現場での利用である」と明言しており、実務者が学術的な収斂論を知らずとも、現場感覚から同種の暫定性を予期していたことがわかる。実際、15章が個別に詳述するCouchDB(独立企業がサポート)・Riak(Basho社)の勢力図は、2024年論文が報告する収斂(SQL化・ACID再獲得)を経て現在では大きく様変わりしており、15章自身の予言が的中したことになる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.3, [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §2.2–2.4) ## 未解決の問い - **NewSQL の位置づけ**: Google Spanner や CockroachDB は ACID + 水平スケーラビリティの両立を達成した。これは Stonebraker の「一貫性保証を捨てる専用化」に対する反証か、それとも「分散トランザクション」に特化した新たな専用化か——[[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §3.4 は部分的に答える: NewSQL自体(H-Store/VoltDB系のインメモリ実装)は「劇的な普及に至らなかった」が、その遺産としてTiDB・CockroachDB・PlanetScale・YugabyteDBのような分散トランザクショナルRDBMSが定着した。つまりNewSQLは専用化のカテゴリとして独立に生き残ったのではなく、RDBMSの一亜種(分散ACID対応RDBMS)として収斂した、というのが2024年時点の著者らの評価である。ただしこの評価はSpanner固有の技術的優位性を論じておらず、「なぜSpanner/CockroachDBは生き残りTiDB以外は苦戦するNewSQLベンダーもあるのか」という個別差の分析は本稿の範囲外。 - **ポリストアの実現可能性**: 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 の拡張で済む範囲はどこまでか——[[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §2.7 は「ベクトルDBはANN索引を特徴とするドキュメント指向DBMSに過ぎず新アーキテクチャの基盤ではない」と否定的に評価し、既存RDBMSは2023年のうちにpgVector・DiskANN等のOSSライブラリ統合でベクトル索引を取り込んだと報告する。ただし、なぜベクトル索引の取り込みがJSON対応(数年を要した)より速かったのかという理由(索引実装の容易さ vs 需要の説得力)は定性的な推測にとどまり、性能面でRDBMS内蔵ベクトル索引が専用ベクトルDBに追いついたかの定量比較は本稿の範囲外。 - **カラムファミリ(BigTable系)だけがNoSQLの中で収斂に取り残された理由**: [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] §2.4 は、ドキュメントDB・KVストアがSQLを獲得する中、カラムファミリモデルだけが「同じ不利益を抱えたまま取り残された唯一の外れ値」だと指摘するが、その理由(市場規模の小ささ、Googleという単一ベンダー起源への依存、データモデル自体の表現力の限界等)を深く分析していない。ワイドカラムストアが収斂しにくい構造的理由は何か。 - **Chronix が示した「TSDB のドメイン特化追加」は 2017 年の先例だが、現代 TSDB（InfluxDB 3.x・TimescaleDB・ClickHouse 時系列モード）はどこまでビルトイン解析とデータモデル汎化を採り込んだか** - **H-Store のアドホッククエリ排除は正しかったか**: [[H-Store]] はストアドプロシージャのみを許容しアドホック SQL を排除した。VoltDB は後にアドホッククエリを部分的に復活させた。「完全な機能除去」と「柔軟性の維持」のトレードオフにおいて、最適な抽象化レベルはどこか - **Mach の「協調除去」は他の専用化領域にも一般化できるか**: Mach はメトリクスワークロードの「ほぼ順序どおりの追記」という性質を前提に mutex 協調を除去した。この「ワークロードの順序性を前提に同期プリミティブを除去する」パターンは、ログ・イベントのような他の追記主体ワークロードにも適用できるか。それとも順序外挿入・更新が多いワークロードでは Mach 型の疎結合設計は成立しないか。 - **『詳説 データベース』が示す3つの最適化軸(レイテンシ・データ密度・管理単純さ)は網羅的か**: Bigtable/Dynamo/H-Store/Mach の除去パターンはこの3軸のいずれかに大別できるように見えるが、Chronix のような「ドメイン固有機能の追加」型の専用化はこの3軸のどれにも明確には対応しない。本書が挙げる3軸は「何を除去するか」を主眼とする専用化には十分でも、「何を追加するか」を主眼とする専用化(Chronixのドメイン知識密度)を捉えるにはもう1軸(ドメイン適合度、といった軸)が必要ではないか。 ## 関連 - ソース: [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]] / [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]] / [[@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]] / [[@2021__OReillyJapan__詳説 データベース - Part I 序論 ストレージエンジン]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] - 概念: [[時系列データベース]] / [[プロセスペア]] / [[ベンチマーキング]] / [[ベクトル検索インデックス]] - エンティティ: [[Michael Stonebraker]] / [[Andrew Pavlo]] / [[Ugur Cetintemel]] / [[Samuel Madden]] / [[Daniel J. Abadi]] / [[H-Store]] / [[Chronix]] / [[Mach]] / [[Alex Petrov]] / [[Eric Florenzano]] - 関連 MOC: [[分散深層学習 - MOC]]（大規模学習基盤のストレージ選択） ## 出典 - [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]]（「one size fits all」批判の原典。ストリーム処理で 2 桁のスループット差を実測） - [[@2024__SIGMODRecord__What Goes Around Comes Around... And Around]]（2005年版の20年後の続編。MapReduce・NoSQL・NewSQL・ベクトルDB・ブロックチェーンDBの興亡を検証し、専用化の多くがRM/SQLへ収斂しつつあると報告） - [[@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倍を実証) - [[@2021__OReillyJapan__詳説 データベース - Part I 序論 ストレージエンジン]]（ストレージエンジン設計のトレードオフを、都市計画との類推とレイテンシ/データ密度/管理単純さの3軸で教科書的に定式化） - [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]]（§1 — OLTP/OLAP/HTAP の3分類とその限界に関する明示的な留保） - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]]（実務者による独立の専用化地図「NoSQLの5分類」。専用化の暫定性を2011年時点で予期した結論）