レジスター討論会 最新のレジスター討論会へようこそ。ここでは、執筆者がテクノロジーの話題について議論し、読者の皆さんが勝利の議論を選びます。
形式はシンプルです。動議を提出し、賛成の議論は月曜日と本日、反対の議論は火曜日と明日に行われます。週中は、下記に埋め込まれたアンケートで賛成か反対かを選択して、どちらの側を支持するか投票できます。最終投票結果は金曜日に発表され、どの議論が最も支持されたかが明らかになります。
読者に自分たちの側に投票するよう説得するのは、私たちのライターの役割です。
今週の議題は次のとおりです。
グラフ データベース (関係がデータ要素とともにネイティブに保存される) は、ほとんどの同じユース ケースにおいて、適切に設計されたリレーショナル データベースに比べて大きな利点を提供しません。
昨日のジム・ウェバー氏の主張に反論し、再びこの動議に賛成を唱えているのは、カーネギーメロン大学のデータベース学准教授アンディ・パブロ氏です。
物事が関係性を持つようになるまでは、すべて楽しいゲームです
尊敬する同僚は、「well-architected(適切に設計された)」DBMSの意味を理解していないと遠慮がちに主張しています。しかしながら、そのようなシステムの主要な特徴を改めて説明させてください。グラフDBMSはリレーショナルDBMSよりも分析クエリに優れているとされているため、ここではグラフを介した分析クエリに焦点を当てます。以下のリストは、CWIの研究者によるCIDR 2023論文[PDF]にも影響を受けています。
- 型付きデータの高速スキャン – NoSQLムーブメントは、開発者にスキーマレス(つまりスキーマオプション)データベースが良いアイデアだと誤解させました。これは一部のシナリオでは必須であり、現在ではほとんどのリレーショナルDBMSがJSONデータ型をサポートしています。しかし、データを高速に処理するには、DBMSがスキーマとデータの型を認識していれば、間接参照がなくなり、スキャンパフォーマンスが向上します。
- 列指向ストレージ – 列指向でデータを保存することには、クエリに不要な列をスキップすることでディスクI/Oとメモリのオーバーヘッドを削減できるなど、いくつかの利点があります。また、列指向データは行指向データよりもエントロピーが低いため、DBMSによる事前の解凍を必要としない圧縮スキームに適しています。
- ベクトル化されたクエリ実行 – ベクトル化された処理モデル [PDF] (タプル・アット・ア・タイム・モデルとは対照的に)を使用すると、DBMSの分析クエリのパフォーマンスが10~100倍向上します。また、データをバッチ処理することで、DBMSはベクトル化されたCPU命令(SIMD)を活用してパフォーマンスをさらに向上させることができます。
- メモリの明示的な制御 – DBMSはメモリ割り当てを完全に制御する必要があります。これは、フラグメンテーションやガベージコレクションによってパフォーマンスの問題が発生する「管理型」メモリランタイム(JVM、Erlangなど)を使用しないことを意味します。また、OSがキャッシュからどのデータを削除するかを決定することも許可しません(MMAPなど)。DBMSはまた、CPU効率を向上させるために、関連情報が互いに近い場所に配置されるように、きめ細かなデータ配置も備えていなければなりません。
アンディ・パブロ:「彼らが犯した間違いは、データベースの歴史を無視し、リレーショナルモデルを放棄して車輪の再発明をしようとしたことだ」
リレーショナル DBMS に組み込む必要があるグラフに固有の追加の最適化がいくつかあります。
- グラフ中心のクエリAPI – SQL:2023標準では、リレーショナルDBMSにおけるグラフの定義とトラバースのためのプロパティグラフクエリ(SQL/PGQ)が導入されています。SQL/PGQは、新興のGQL標準のサブセットです。そのため、SQL/PGQはリレーショナルDBMSとネイティブグラフDBMS間の機能差をさらに縮めます。
- クエリ実行の強化 – 適切に設計されたリレーショナルDBMSには、グラフクエリの最適化に特化した強化機能が組み込まれています。これには、多元最悪ケース最適結合(WCOJ)、コンパクトな一時データ構造(例:圧縮されたスパース行)、因数分解クエリ処理などが含まれます。これらの追加には高度なエンジニアリングが必要ですが、既存のリレーショナルDBMS実行エンジンとうまく連携するため、新しいエンジンをゼロから開発する必要はありません。
Well-Architected なリレーショナルDBMSがグラフDBMSに対してどの程度の性能を発揮するかを示す証拠として、CWIのCIDR 2023論文 [PDF] を参照します。この論文では、DuckDB組み込み分析リレーショナルDBMSを拡張し、SQL/PGQと上記の機能強化をサポートしました。そして、業界標準のグラフベンチマークを用いて、主要なグラフDBMSと比較しました。その結果、上記の機能強化を施したDuckDBは、ネイティブグラフDBMSを最大10倍上回る性能を発揮することが示されました。これは2023年1月時点の最先端の結果であり、5年前のものではありません。
CWI チームには世界最高のデータベース システム研究者が数名所属していますが、この成果を達成するために数億ドルもの資金を調達したわけではありません。
同僚が2006年に発表された「万能型」DBMSアーキテクチャを否定するストーンブレーカーの画期的な論文に言及したことについてですが、2000年代にグラフ中心のワークロードにリレーショナルDBMSを採用しようと試みた結果、Neo4jが生まれたという逸話は、ストーンブレーカーの主張を裏付けるものです。しかし、彼らが犯した過ちは、データベースの歴史を無視し、リレーショナルモデルを放棄して車輪の再発明を試みたことにあります。関心のある読者には、ストーンブレーカーの2006年の論文 [PDF] もぜひ読んでみてください。この論文は、1969年のリレーショナルデータモデル発明以来、代替データモデルがそれを置き換えることができなかったことに関するものです。グラフデータベースは非リレーショナルDBMSのもう一つのカテゴリーに過ぎず、リレーショナルDBMSがグラフデータベースの優れた部分を採用するにつれて(過去に他のDBMSでも同様であったように)、最終的には人気が低下するでしょう。
最後に、グラフデータベース市場の将来について2021年に公に賭けた私の立場は変わりません。CMUの公式写真を、「グラフデータベースはナンバーワン」と書かれたシャツを着た私の写真に差し替えます。この写真は、私が退職するか、解雇されるか、あるいは元学生に刺されるまで使い続けます。®
下記から投票してください。投票は木曜日の夜に締め切られ、最終結果は金曜日に発表されます。討論会の進捗状況はこちらで確認できます。
JavaScriptが無効です
この機能を利用するにはJavaScriptを有効にしてください。