> [!abstract] 概要(要約) > 20年前、著者の1人は過去40年のデータモデリング研究と開発に関する論文を共著した。その論文は、リレーショナルモデル(RM)とSQLが、それらを置き換えようとする試みにもかかわらずデータベース管理システム(DBMS)の主流であり続けることを示した。SQLは代替アプローチから優れたアイデアを吸収した。 > > 本稿ではこの問題を再考し、この進化が2005年以降も続いていることを論じる。SQLまたはRMを置き換えようとする試みが繰り返されてきたが、RMは依然として支配的なデータモデルであり続け、SQLは他の手法から優れたアイデアを取り込むよう拡張された。したがって我々は、SQLとリレーショナルDBMS(RDBMS)の継続的な進化という同様の傾向が今後も続くと予想する。また、DBMS実装についても論じ、主要な進展はRMシステムにおいて生じており、それは主にハードウェア特性の変化によって駆動されていると論じる。 > > 本稿では、データベースにおけるデータモデル・クエリ言語活動の過去20年間を分析する。議論を以下の領域に構造化する: (1) MapReduceシステム、(2) キーバリューストア、(3) ドキュメントデータベース、(4) カラムファミリ/ワイドカラム、(5) テキスト検索エンジン、(6) 配列データベース、(7) ベクトルデータベース、(8) グラフデータベース。 > > SQLまたはRMから逸脱したほとんどのシステムはDBMS市場を支配しておらず、しばしばニッチ市場にのみ役立っているにすぎないと主張する。大々的な喧伝とともにRMを拒絶して始まった多くのシステム(NoSQLを想起されたい)が、いまやRMデータベース向けのSQLライクなインターフェースを公開している。そうしたシステムはRDBMSとの収斂の道を歩んでいる。一方SQLは最良のクエリ言語のアイデアを取り込み、現代アプリケーションへの対応を拡張して関連性を保っている。 > > RMの根幹に大きな変化はなかったが、RMシステムの実装には劇的な変化があった。本稿の後半では、現代アプリケーションとハードウェアに対応するDBMSアーキテクチャの進展を論じる: (1) カラム型システム、(2) クラウドデータベース、(3) データレイク/レイクハウス、(4) NewSQLシステム、(5) ハードウェアアクセラレータ、(6) ブロックチェーンデータベース。これらの一部はDBMS実装への根本的な変化であり、他は誤った前提に基づく単なるトレンドに過ぎない。 > > 最後に、次世代DBMSにとって重要な考慮事項について論じ、研究・商業の両面でのデータベースの未来への期待を述べる。 ## 論文情報 - タイトル: What Goes Around Comes Around... And Around... - 著者: Michael Stonebraker(Massachusetts Institute of Technology / [[MIT]] CSAIL)、Andrew Pavlo([[Carnegie Mellon University]]) - 媒体: ACM SIGMOD Record, Vol. 53, No. 2, June 2024, pp. 21–37 - DOI: 10.1145/3685980.3685984 - 参照文献数: 204件(2005年版 [188] "What Goes Around Comes Around" を含む) 本稿は、Michael Stonebraker と Joseph Hellerstein が2005年に『Readings in Database Systems』第4版へ寄稿した章「What Goes Around Comes Around」[188]の直系の後継である。2005年版は1960年代から2000年代初頭までの9つのデータモデリング潮流(階層型・ネットワーク型・リレーショナル・実体関連・拡張リレーショナル・意味的・オブジェクト指向・オブジェクトリレーショナル・XML等の半構造化)を検討し、拡張可能な型システムを備えたリレーショナルモデル(オブジェクトリレーショナル)が全ての対抗馬に勝ったと結論づけた。本稿はこの結論の妥当性を2005年以降の20年間について再検証する。 ## 概要 本稿は2部構成である。第2節「データモデル・クエリ言語」は、MapReduce・キーバリューストア・ドキュメントDB・カラムファミリ・テキスト検索・配列DB・ベクトルDB・グラフDBという8つのデータモデル潮流を検討し、いずれもニッチ市場にとどまるかRM/SQLへ収斂しつつあると結論づける。第3節「システムアーキテクチャ」は、カラム型システム・クラウドDB・データレイク/レイクハウス・NewSQL・ハードウェアアクセラレータ・ブロックチェーンDBという6つのアーキテクチャ潮流を検討し、こちらはデータモデルではなく実装レベルの変化として位置づける。第4節は「良いマーケティングの価値を過小評価するな」「大手非DBMSベンダーのDBMSに注意せよ」といった箴言的な教訓と、LLM・自然言語クエリインターフェースがDBMSに与える影響への短い考察で締めくくられる。 ## 問題設定 入力は「2005年以降のデータベース研究・製品・市場の20年史」であり、著者らは各データモデル/アーキテクチャ潮流について、(1) 起源、(2) 主要な実装例、(3) 現在の市場での位置づけ、(4) RM/SQLとの収斂または乖離の程度、を論じるという形式を反復する。前提条件として、著者らは2005年版と同じ「RM/SQLが優勢であり続けるか」という中心的問いを引き継ぎ、新たに追加された領域(ベクトルDB・データレイク・ブロックチェーンDB・LLMの影響)を扱う。 ## 提案手法(論証の構成) - **反復的な「Discussion」パラグラフ構造**: 各データモデル/アーキテクチャ節は、まず技術の起源と主要な実装を年代記的に記述し、末尾に「Discussion:」段落でRM/SQLとの関係を評価するという形式を一貫して用いる。これにより8+6=14の異なる技術潮流を同一の評価軸(ニッチ市場か、SQL収斂か、それとも真に新しいアーキテクチャか)で比較可能にしている。 - **収斂の実証パターン**: 論証の核は「あるNoSQL/NewSQL技術がRDBMS的機能(SQLインターフェース・ACIDトランザクション・セカンダリインデックス)を後から獲得した」という具体的事例の列挙である。例えば DynamoDB PartiQL、Cassandra CQL、Aerospike AQL、Couchbase SQL++、MongoDB(2021年にAtlas向けSQLを追加)という5つの独立したNoSQLベンダーがSQLライクなインターフェースを追加した事実を並べることで、個別事例ではなく業界規模のパターンとして収斂を論証する。 - **実装レベルの変化とデータモデルレベルの変化を明確に分離**: 第2節(データモデル)と第3節(システムアーキテクチャ)を分けることで、「RMというデータモデル自体は変わっていないが、そのRMを実装する方法(列指向ストレージ・クラウドネイティブ・NewSQL)は劇的に変わった」という主張を構造的に裏付けている。 ## 新規性 2005年版が9つのデータモデリング潮流(1960年代〜2000年代)を「歴史の教訓」として振り返る回顧的な論文だったのに対し、本稿は(1)対象期間を2005年以降の20年に絞り、(2)MapReduce・NoSQL・ベクトルDB・グラフDBというその後の10〜20年で登場した潮流を新規に扱い、(3)データモデルの議論に加えてDBMS**実装**アーキテクチャ(カラム型・クラウド・データレイク・NewSQL・ハードウェアアクセラレータ・ブロックチェーン)という2005年版にはなかった第2の軸を導入した点が新しい。また、LLM/生成AIがDBMSに与える影響という2005年には存在しなかった論点(自然言語クエリインターフェース、ML最適化オプティマイザ)にも短く言及している。 ## 実験設定 本稿は実証研究論文ではなく、既存文献・業界動向・著者の一次的な観察に基づく評価論文(survey/position paper)である。定量的な主張の多くは、他の学術論文([172]のHadoop対DBMS比較研究、[196]のDuckPGQ対グラフDBMS比較等)からの引用、または著者が直接観察した業界イベント(Google がMapReduceを2014年に廃止した経緯、ベンダーのプロダクトアナウンス等)に基づく。専用の実験環境・データセット・比較対象は設定されていない。 ## 実験結果(節ごとの主要な知見) ### データモデル潮流(第2節) - **MapReduceシステム**(§2.1): Googleは2003年に自社クロール処理向けの「点解決策」としてMapReduce(MR)を構築した。2009年の研究[172]でデータウェアハウスDBMSがHadoopを性能面で上回ることが示され、Google/DBMSコミュニティ間で論争が起きた([123, 190])。決定打は2つの出来事: (1) 2010年代にHadoop技術・サービス市場が崩壊し、Cloudera・Hortonworks・MapRが実質的な製品を失った、(2) Googleが2014年にクロール処理をMRからBigTableへ移行しMRを技術スタックから排除した([164, 194])。ClouderaはHDFS上に直接RDBMS(Impala[150])を構築し、MapRはDrill[22]を、MetaはPresto[185]を構築した。**Discussion**: MRの欠陥は開発者コミュニティの熱狂をもってしても救えないほど深刻だった。Hadoopは約10年前に死滅し、HDFSクラスタとそこから収益を得る企業群という遺産だけが残った。分散RDBMSはクラウドで隆盛を極めている。 - **キーバリューストア**(§2.2): Memcached(キャッシュ用途)、Redis(Memcachedの堅牢な代替)、Amazon Dynamo(2007年、永続的アプリケーションデータ向け)が代表例。組み込み型ではBerkeleyDB(1990年代初頭)、Google LevelDB、Meta RocksDB(LevelDBのフォーク)が挙げられる。**アーキテクチャトレンドとして重要な点**: MySQLが最初にストレージマネージャを差し替え可能なAPIを公開し、MetaがInnoDBの代わりにRocksDBを構築した。MongoDBも2014年にMMAPベースのストレージマネージャを廃しWiredTigerのKVストアへ移行した([120, 138])。**Discussion**: KVストアは複数フィールドを要するアプリケーションには不向きで、セカンダリインデックスを欠く。SQLite・DuckDBのような組み込みDBMSの選択肢が今日充実しているため、単純なアプリケーションでもRDBMSの方が良い選択でありうる。 - **ドキュメントデータベース**(§2.3): NoSQLは「SQLと結合は遅い」「ACIDトランザクションは現代アプリケーションに不要(BASE[179]で十分)」という2つのマーケティングメッセージで台頭した。MongoDB[41]が代表例。**Discussion**: 非正規化/事前結合の問題は1970年代からの旧知の論点(重複データ発生・事前結合が必ずしも速くない・データ独立性の欠如)であり、ドキュメントDBは1980年代のオブジェクト指向DBMSや1990年代後半のXML DBMSと本質的に同じ主張を繰り返している。2010年代末までにほぼ全てのNoSQL DBMSがSQLインターフェースを追加し(DynamoDB PartiQL[56]、Cassandra CQL[15]、Aerospike AQL[9]、Couchbase SQL++[72])、最後の抵抗者だったMongoDBも2021年にAtlas向けSQLを追加した[42]。「SQLは遅い」という主張は「Not only SQL」(SQLも一部の用途には良い)へと変質した。 - **カラムファミリ/ワイドカラムデータベース**(§2.4): 最初のカラムファミリモデルDBMSはGoogle BigTable(2004年)[111]。CassandraとHBaseがこのモデルを模倣した(結合・セカンダリインデックスの欠如という限界も含めて)。**Discussion**: Googleは2010年代初頭にBigTable上にMegaStore[99]と初代Spannerを構築したが、後にBigTableの残滓を除去してSpannerを書き直した[98]。CassandraはThrift APIをSQLライクなCQL[15]へ置換し、HBaseはPhoenix SQLフロントエンド[57]を推奨する。カラムファミリモデルはNoSQLと同じ不利益を抱えたまま取り残された唯一の外れ値である。 - **テキスト検索エンジン**(§2.5): SMART(1960年代)がベクトル空間モデル・転置索引の起源。Elasticsearch・Solrが代表的で、内部でLucene[38]を使用する。**Discussion**: 全RDBMS(Oracle・SQL Server・MySQL・PostgreSQL)が全文検索索引をサポートするようになり、専用検索システムとほぼ同等の水準に達している。ただしSQLへの検索操作の統合はDBMS間で不統一かつ扱いにくい。完全一致検索を前提とする転置索引ベースの手法は、近年ML生成埋め込みによる類似検索(§2.7)に取って代わられつつある。 - **配列データベース**(§2.6): PICDMS[114]が最初の配列DBMS実装とされる。Rasdaman・kdb+が現存する最古参、SciDB・TileDBが新参、HDF5・NetCDFが科学データ向けファイル形式として普及。SQL:2023はRasdamanのRQLに着想を得たSQL/MDA(真の多次元配列サポート)を導入した。**Discussion**: 配列DBMSはゲノミクス・衛星画像等のニッチ市場にとどまり、主要クラウドベンダーはホスト型配列DBMSサービスを提供していない(市場規模が小さいと判断していることを示唆)。 - **ベクトルデータベース**(§2.7): 列ファミリモデルが文書モデルの縮約であるのと同様、ベクトルモデルは配列モデルを1次元ラスタへ単純化したものである。埋め込みベクトルは学習済み変換(BERT等)によりテキスト・画像から生成され、100〜1000次元規模になる。Pinecone・Milvus・Weaviateが主要ベンダー。**Discussion**: ベクトルDBMSはANN索引を特徴とするドキュメント指向DBMSに過ぎず、索引は特徴であって新しいシステムアーキテクチャの基盤ではない。ChatGPTが2022年末に主流化してから1年以内に複数のRDBMSが独自のベクトル検索拡張を追加した(Oracle[7]・SingleStore[137]・Rockset[8]・Clickhouse[157]、2023年)。JSON対応がRDBMSに追加されるのに数年かかったのと対照的に、ベクトル索引の急速な普及は(1)埋め込みによる類似検索の説得力の高さ、(2)pgVector[145]・DiskANN[19]・FAISS[24]のようなOSSライブラリの統合の容易さ、の2つの理由による。 - **グラフデータベース**(§2.8): OLTP向け(Neo4j[44]が最有力、CODASYL的なポインタでエッジを表現するがノードをクラスタリングしない)とOLAP向け(TigerGraph[74]・JanusGraph[32]がクエリ言語・ストレージ重視、Giraph[26]・Turi[78]が計算フレームワーク重視)の2用途がある。**Discussion**: グラフは常にNode/Edgeテーブルとしてリレーショナルにシミュレート可能である。分散グラフアルゴリズムは通信コストのため単一ノード実装に劣ることが多いという先行研究[160]があり、大規模グラフ以外はメモリに収まる単一ノードのデータ構造で処理する方が良い戦略とされる。MSSQL[3]・Oracle[50]は組み込みグラフSQL拡張を持ち、Amazon Neptune[45]はAurora MySQL上のグラフ指向ベニア、Apache AGEはPostgreSQL上のOpenCypherインターフェースである。SQL:2023はSQL/PGQ(プロパティグラフクエリ)を導入し[196]、DuckDBのSQL/PGQ実装が既存のリーディンググラフDBMSを最大10倍上回るという最新の研究結果[196]も紹介されている。 ### システムアーキテクチャ潮流(第3節) - **カラム型システム**(§3.1): 1990年代半ばのデータウェアハウス市場(Walmart等の小売業が先導)の隆盛を背景に、Ralph Kimballのスタースキーマ設計[148, 149]が普及した。カラムストアの利点は(1)圧縮効率の向上、(2)ベクトル化実行によるVolcano型エンジンの逐次処理オーバーヘッド削減[106, 147]、(3)レコードヘッダ(nullやバージョン情報の追跡用、20バイト規模)の削減。**Discussion**: 過去20年でデータウェアハウス市場の全ベンダーが行ストアから列ストアへ移行した(Amazon Redshift[94]、Google BigQuery[162]、Snowflake[121])。 - **クラウドデータベース**(§3.2): ネットワーク帯域がディスク帯域より速く成長したため、ネットワーク接続ストレージ(NAS、Amazon S3等のオブジェクトストア)が直接接続ストレージの代替として魅力的になった。計算・ストレージの分離(disaggregation)により(1)クエリごとの弾力性、(2)ストレージ・計算で異なるハードウェアの使用、(3)計算ノードの他タスクへの再割り当て、(4)ストレージノードへの計算プッシュダウン("push the query to the data")が可能になる。Snowflakeがこれを「サーバレスコンピューティング」として導入した[121]。**Discussion**: マルチノード共有ディスクDBMSは歴史的にはうまくいかなかった古いアイデアだが、ネットワーク技術の変化とクラウド移行によって復活した——著者らは「what goes around comes around」の典型例と位置づけ、共有ナッシングアーキテクチャの再浮上は今後ないと予測する。 - **データレイク/レイクハウス**(§3.3): クラウド化に伴い、モノリシックなデータウェアハウスからオブジェクトストア裏付けのデータレイクへの移行が進んだ。レイクハウス(data warehouse + data lakeの合成語)実行エンジン[93]がSQL・非SQL(Pandas DataFrame API[159]、Dask[181]・Polars[61]・Modin[177]・Bodo[198])の双方をサポートする統一インフラを提供する。Parquet[55]・ORC[53, 140]がオープンソースのファイル形式標準として普及し、Apache Arrow[11]がインメモリデータ交換の類似バイナリ形式として使われる。Delta Lake[92]・Iceberg[6]・Hudi[5]のようなミドルウェアがトランザクショナルな更新をサポートし、レイクハウスを従来のデータウェアハウスに近づける。**Discussion**: データガバナンスなしのデータレイクは整合性・発見性・バージョニングの問題を招くとの指摘[167]がある一方、レイクハウスはメタデータ・キャッシュ・索引サービスに関する制御を提供する[93]。データレイクは新しい統計不足への対応として適応的クエリ処理[97, 105, 163]が重要になる。Teradata・Verticaのようなレガシーウェアハウスベンダーもオブジェクトストアからの読み取りに対応するようになった。 - **NewSQLシステム**(§3.4): 2010年代初頭、NoSQLのスケーラビリティとRDBMSのRM/ACIDトランザクションを両立させる目的で登場[95, 171]。インメモリ系(H-Store[144, 189](VoltDBとして商用化)、SingleStore[69]、Microsoft Hekaton[128]、HyPer[146])とディスク指向分散系(NuoDB[47]、Clustrix[17])の2グループがあった。**Discussion**: NewSQL採用は劇的な広がりを見せていない[96]——既存DBMSが「十分に良かった」ため、組織は移行のコスト・リスクを負いたがらなかった。フラッシュストレージのコスト低下とインテル Optane等の不揮発性メモリの衰退により、SSDがOLTP DBMSで主流であり続けると予想される。GoogleはSpanner(2012年)で結果整合性を破棄し真のトランザクションを採用した[119]。NewSQLの遺産として、TiDB[141]・CockroachDB[195]・PlanetScale[60]・YugabyteDB[86]のような分散トランザクショナルRDBMS群が残った。 - **ハードウェアアクセラレータ**(§3.5): 1980年代のデータベースマシン(Britton-Lee IDM/500[192]、Teradata Y-net[1])はいずれも失敗した。過去20年はFPGA(Netezza[2]、Swarm64[91]、Vitesse Deepgreen DB[81])とGPU(Kinetica[35]、Sqream[35]、Brytlyt[13]、HeavyDB[48])を用いたコモディティハードウェアアクセラレーションへ移行した。**Discussion**: カスタムハードウェアはほとんどの企業にとってコスト効率が悪く、GPUの方がFPGAよりCUDA[169]のような既存サポートライブラリがある分優勢。アクセラレータが成功しうるのは$50–100Mの研究開発コストを正当化できる大規模クラウドベンダーのみ(Amazon Redshift AQUA[102]、Google BigQuery[89]が実例)。 - **ブロックチェーンデータベース**(§3.6): マークル木ベースの増分チェックサムで台帳の不変性を保証する分散ログ構造DB。正当な用途は誰も信頼できないP2Pアプリケーションに限られ、現状の実用ケースは暗号通貨(Bitcoin)のみ。Fluree[25]・BigChainDB[12]・ResilientDB[136]がDBMS化の試みだが著者らは正当性を疑問視する。**Discussion**: ブロックチェーンDBの性能コストは約5桁のオーバーヘッドに達し、正当な企業がそのコストを払う信頼喪失シナリオは存在しない——最大手の暗号通貨取引所自体も従来型RDBMSで運用されている。Amazon QLDB[65]は非分散(BFTコミットプロトコルなし)の不変台帳DBだが、これは完全に分散化されたブロックチェーンDBの需要が見出せなかった結果として構築された[108]。 ## 考察 第4節「Parting Comments」で著者らは以下の教訓を提示する: - **良いマーケティングの価値を過小評価するな**: 競争が激しく利益率の高いDBMS市場では、劣った製品でも強いマーケティングによって成功しうる(1980年代のOracle、2000年代のMySQL、2010年代のMongoDB)。 - **大手非DBMSベンダーのDBMSに注意せよ**: 過去10年、技術企業が社内アプリケーション向けに構築したDBMSをオープンソース化する(しばしばApache Foundationへ寄贈)トレンドがある(Meta由来のHive・Presto・Cassandra・RocksDB、LinkedIn由来のKafka・Pinot・Voldemort)。「自社開発文化(not invented here)」を助長する社内昇進制度がこの傾向を後押ししているが、こうしたシステムはオープンソース化直後は未成熟であることが多い。 - **out-of-boxエクスペリエンスを軽視するな**: DuckDBの人気の一因は、事前のデータベース・テーブル定義なしにファイルを直接処理できる点にある。 - **開発者はデータベースに直接クエリすべき**: ORMはリレーショナルDBを対象としがちで、多様なデータ基盤(検索エンジン・グラフDB・NoSQL)を持つ組織ではサポートが不足する。 - **LLM/AIの影響への短い考察**: 自然言語からSQLへの変換[133]への関心が高まっているが、OLTPアプリケーションでNLがSQLに取って代わることはないと予想する(ORMが介在するため)。LLMは説明可能性・訓練データ量の課題から企業の意思決定への採用は慎重に進むと予想される。ML最適化オプティマイザ[152, 156]・設定チューナ[200, 204]・アクセス手法[151, 193]は強力なツールだが高品質なシステムエンジニアリングの必要性を消さない。 ## 強み / 弱点・課題 **強み**: - 2005年版と同じ著者(Stonebraker)による20年越しの検証であり、長期的なトレンドの継続性を評価する上で高い権威性を持つ - MapReduce・NoSQL・NewSQL・ベクトルDB・ブロックチェーンDBという広範な技術潮流を単一の一貫した評価軸(RM/SQLとの収斂度)で比較しており、個別技術の断片的評価に終わらない見取り図を提供する - 「収斂」の主張を、複数ベンダーが独立にSQLインターフェースを追加したという具体的な業界事実の列挙によって裏付けている **弱点・課題**: - 実証研究ではなく評価論文(survey/position paper)であり、著者らの見解・解釈が強く反映される。特にブロックチェーンDB・グラフDBへの評価は他の研究者・実務者の見解と対立しうる - 「ニッチ市場」「収斂しつつある」という評価の多くは定性的判断であり、市場シェア等の定量データによる裏付けは限定的 - LLM/AIの影響についての考察は「本稿執筆時点では議論が急速に進行中」と著者ら自身が認めており、暫定的な見解にとどまる - 著者ら自身も認める通り、本稿の教訓の一部(良いマーケティングの価値、大手非DBMSベンダーへの注意)は2005年版からの繰り返しであり、業界がこれらの教訓から学んでいないことを示唆する ## 出典検査 すべての主張はPDF本文(§1〜§5)に遡及して裏付け確認済み。書誌情報(DOI・巻号・ページ)はACM Digital Library([https://dl.acm.org/doi/10.1145/3685980.3685984](https://dl.acm.org/doi/10.1145/3685980.3685984))で確認した実在URL。abstractは原文を一文ずつ忠実に和訳した。本論文には本文が名指しで参照する図表(Figure/Table)は一切存在せず(全文検索で確認済み)、埋め込み画像はACM論文ページの装飾的な「Check for updates」バッジ1点のみであり本文参照がないため取り込み対象外とした。