グラフデータベース大論争：リレーショナルデータベースではすべてに対応できるわけではない

レジスター討論会 最新のレジスター討論会へようこそ。ここでは、執筆者がテクノロジーの話題について議論し、読者の皆さんが勝利の議論を選びます。

形式はシンプルです。動議を提出し、賛成の論拠は月曜日と水曜日に、反対の論拠は今日と木曜日にそれぞれ発表されます。週の途中、下記に埋め込まれたアンケートを使って、賛成か反対かを選択して、どちらの側を支持するか投票できます。最終投票結果は金曜日に発表され、どの論拠が最も多かったかが明らかになります。

読者に自分たちの側に投票するよう説得するのは、私たちのライターの役割です。

今週の議題は次のとおりです。

グラフ データベース (関係がデータ要素とともにネイティブに保存される) は、ほとんどの同じユース ケースにおいて、適切に設計されたリレーショナル データベースに比べて大きな利点を提供しません。

グラフ データベースの歴史における主役の 1 つである Neo4j が初めて本番環境に導入されてから約 20 年が経ちました。

市場の力強い成長と投資家の関心は、ビジネス、メディア、社会、医療、科学など、私たちの周囲で見られるネットワーク化された関係に従ってデータを分析するため、RDBMS の行と列に追いつく可能性があることを示唆しています。

しかし、批判者はまだ疑念を抱いており、グラフ システムが提供していると思われる利点は、グラフ システムよりも長い歴史を持ち、おそらくより成熟していて管理が容易なリレーショナル システムでも実現できると主張しています。

この動議に反対する最初の寄稿者であるJim Webber氏は、Neo4j の主任科学者であり、ニューカッスル大学のコンピューターサイエンスの客員教授です。

リレーショナルではあらゆるユースケースに対応できない

グラフAPIの有用性に関する下院の主張の多くには同意します。私たちの反対の核心は、将来登場する「優れたアーキテクチャ」のリレーショナルデータベースエンジンによって、現在既に実稼働中の有用なグラフデータベースの使用が不要になるという主張です。「優れたアーキテクチャ」という形容詞は、この推測をほとんど信憑性のないものにするのに、非常に大きな役割を果たしています。

また、リレーショナルデータベースはあらゆるユースケースに対応でき、汎用的なデータベースオプションであるという考えは誤りであることを指摘しておく必要があります。「万能」という考え方は、リレーショナル学派の最も影響力のある理論家の一人であるマイケル・ストーンブレーカー氏によって否定されています[PDF]。ストーンブレーカー氏は、リレーショナルデータベースの範囲内であっても、ワークロードごとに異なるため、適切に機能するには異なるデータエンジンが必要であると主張しています。Neo4jでは、グラフデータベースとグラフ分析プラットフォームが異なるエンジンを使用しているため、この特化を積極的に採用しています。実際、ドキュメントデータベース、時系列データベース、そしてもちろんリレーショナルデータベースにおいても、この特化は豊かな伝統となっています[PDF]。

リレーショナルデータベースが何でもできるという考えは受け入れられません。また、「グラフシステムは過去50年間の苦労して得られた教訓の多くを無視している」という考えも受け入れられません。まるでグラフが日常的な運用データ管理とは別に存在するかのように。しかし、グラフデータベースは、トランザクション、クエリ計画／実行、インデックス作成、コンセンサス、レプリケーション、同時実行制御といった課題に、実証済みの技術を駆使して一貫して取り組んできました。

下院が「グラフAPIのメリット」とクエリ指向クエリ言語を認識していることを大変嬉しく思います。これが、形式的に記述されたセマンティクスを備えた宣言型言語Cypher [PDF] を構築した理由です。私たちは、SQLを標準化した同じISO委員会によって、CypherをベースにしたSQLのISO標準化グラフ言語であるGQLの定義に、学界や産業界と連携して取り組んでいます。GQLにより、多くの新規ユーザーが、SQLでは扱いにくくエラーが発生しやすいグラフクエリを簡潔かつ人間的に表現できるようになります。

グラフデータベースはビューとマイグレーションを適切にサポートできないため、（狭義の意味で）データ独立性に欠けているという主張は否定します。マイグレーションは実際には頻繁に行われ（この例のように）、GQLにはグラフビューを定義するためのネイティブ構文が含まれています。実際、多くのグラフデータベースはスキーマを任意に選択できる性質を持ち、クエリ言語にはあいまいパターンマッチング機能があるため、データ独立性に関しては他のデータベースよりも優れています。

しかし、データベースは理論だけの話ではありません。コンピューティングにおいて最も要求の厳しいタスクを実行するために設計された複雑なシステムです。「適切に設計された」という漠然とした概念を提示するだけでは不十分です。過去のデータベースは適切に設計されていなかったと示唆するのです。今日使用されている何千ものグラフ生成システムは、無知からグラフを選択したのではなく、グラフモデルとパフォーマンスが特定の要件に最適なエンジンだったからこそ選択したのです。

グラフ処理を実行するSQLを書けばよいという主張についてですが、異種グラフでは、ノード間の関係が多数かつ多様で、双方向性があります。それらは規則的な場合もあれば、そうでない場合もあります。疎な場合もあれば、密な場合もあります。グラフをテーブルの集合としてモデル化すべきだというNeo4jの考え方は現実的ではありません。私たちはこれを痛感しています。なぜなら、Neo4jはまさにこのように始まったからです。リレーショナルデータベース上でグラフAPIを使用することで、複雑さが爆発的に増加し、パフォーマンスが低下するという逆境に陥ったのです。グラフをネイティブに処理できるエンジンの開発を余儀なくされたのは、まさにこの技術的なギャップであり、独自のデータベースを構築したいという邪悪な意志からではありません。

実のところ、グラフのユースケースにおいて、ネイティブストレージエンジンは実行時に非常に大きなメリットをもたらすことがよくあります。そのメリットには、データの局所性の向上、並行処理のサポート強化、メモリ使用量の削減など、ほんの一例です。5年以上前に行われた、均質グラフ上の分析ワークロードに主に焦点を当てた厳選された研究も、この現実を変えるものではありません。

リレーショナルデータベースを理解するには50年かかりました。その有用性を尊重し、限界も理解してきました。したがって、本院が提案する「適切に設計された」処理エンジンは既に存在していると私たちは主張します。そして、それはグラフデータベースと呼ばれます。®

下記から投票してください。投票は木曜日の夜に締め切られ、最終結果は金曜日に発表されます。討論会の進捗状況はこちらで確認できます。