開発者がグラフデータベースを使用する理由

20年前、私の開発チームは、検索可能なカテゴリの雇用、自動車、不動産の広告をスキャンする自然言語処理エンジンを構築しました。データ管理の課題が難しいことはわかっていました。一部の広告タイプのデータは、車のメーカーやモデルの特定など、比較的単純なものでしたが、スキルのリストに基づいて職種を特定するなど、より多くの推論が必要なものもありました。

検索可能なすべての用語をキャプチャするメタデータモデルを開発しましたが、自然言語処理エンジンでは、重要なメタデータ関係を公開するためにモデルが必要でした。リレーショナルデータベース内のデータポイント間の任意の接続を使用したメタデータモデルの設計は複雑であることがわかっていたため、オブジェクトデータベースを使用してモデルを管理することを検討しました。

当時私たちがオブジェクトデータベースで達成しようとしていたことは、今日ではグラフデータベースでより良く行うことができます。グラフデータベースは、情報をノードとして保存し、データは他のノードとの関係を指定します。これらは、複雑な関係を持つデータを格納するための実証済みのアーキテクチャです。

企業が他のNoSQLやビッグデータテクノロジーを検討するにつれて、グラフデータベースの使用は過去10年間で確実に増加しました。世界のグラフデータベース市場は2018年に6億5100万ドルと推定され、2026年までに37億3000万ドルに成長すると予測されています。しかし、Hadoop、Sparkなど、他の多くのビッグデータ管理テクノロジーでは、人気、スキルの採用、グラフデータベースと比較した本番環境のユースケース。比較すると、ビッグデータテクノロジーの市場規模は2018年に368億ドルと推定され、2026年までに1,043億ドルに成長すると予測されています。

多くの組織がグラフデータベースを検討していない理由を理解したかったのです。開発者はオブジェクトについて考え、XMLおよびJSONの階層データ表現を定期的に使用します。インターネットはハイパーリンクやソーシャルネットワークの友達や友達の友達のような概念を介して相互接続されたグラフであるため、技術者やビジネスの利害関係者は本質的にグラフを理解しています。では、なぜより多くの開発チームがアプリケーションでグラフデータベースを使用しなかったのでしょうか。

グラフデータベースのクエリ言語を学ぶ

グラフデータベースで使用されるノードと関係のモデリングを理解するのは比較的簡単かもしれませんが、それらをクエリするには、新しいプラクティスとスキルを学ぶ必要があります。

友達と友達の友達のリストを計算する例を見てみましょう。 15年前、私は旅行ソーシャルネットワークを共同設立し、すべてをMySQLに保存することでデータモデルをシンプルに保つことにしました。ユーザーのリストを格納するテーブルには、友達を表すための自己結合があり、友達のリストを抽出するのは比較的簡単なクエリでした。しかし、友達のリストの友達にたどり着くには、非常に複雑なクエリが必要でしたが、ユーザーがネットワークを拡張した場合はうまく機能しませんでした。

利用可能な確立されたグラフデータベースの1つであるNeo4jのチーフサイエンティストであるJimWebberに、友達の友達クエリを作成する方法について話しました。開発者はRDF(Resource Description Framework)とGremlinを使用してNeo4jグラフデータベースにクエリを実行できますが、Webberによると、顧客の90%以上がCypherを使用しています。友達や友達の友達を抽出するためのCypherのクエリは次のようになります。

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me f

RETURN f

このクエリを理解する方法は次のとおりです。

  • ラベルPersonとプロパティ名「Rosa」のノードがあるパターンを見つけて、それを変数「me」にバインドします。クエリは、「me」が深さ1または2で、Personラベルを持つ他のノードとの発信FRIEND関係を持っていることを指定し、それらの一致を変数「f」にバインドします。
  • 私は友達の友達なので、「私」が「f」と等しくないことを確認してください。
  • すべての友達と友達の友達を返す

クエリはエレガントで効率的ですが、SQLクエリの作成に慣れている人にとっては学習曲線があります。グラフデータベースに移行する組織にとっての最初の課題はそこにあります。SQLは普及しているスキルセットであり、Cypherやその他のグラフクエリ言語は学ぶべき新しいスキルです。

グラフデータベースを使用した柔軟な階層の設計

製品カタログ、コンテンツ管理システム、プロジェクト管理アプリケーション、ERP、およびCRMはすべて、階層を使用して情報を分類およびタグ付けします。もちろん、問題は一部の情報が真に階層的ではないことであり、主題は情報アーキテクチャを構築するための一貫したアプローチを作成する必要があります。これは、特に情報の構造化に関する内部の議論がある場合、またはアプリケーションのエンドユーザーが階層の別の部分にあるために探している情報を見つけることができない場合、骨の折れるプロセスになる可能性があります。

グラフデータベースは任意の階層を有効にするだけでなく、開発者がさまざまなニーズに合わせて階層のさまざまなビューを作成できるようにします。たとえば、グラフデータベースに関するこの記事は、データ管理、新しいテクノロジ、グラフデータベースを使用する可能性のある業界、一般的なグラフデータベースの使用例、またはテクノロジの役割のためのコンテンツ管理システムの階層の下に表示される場合があります。レコメンデーションエンジンには、コンテンツをユーザーの関心と一致させるためのはるかに豊富なデータセットがあります。

建設スケジューリングプラットフォームであるGritを含む建設業界にテクノロジーを販売しているConstruxivの共同創設者であるMarkKluszaに話を聞きました。商業建設プロジェクトのスケジュールを見ると、複数の取引、機器、部品、およびモデルの参照への参照が表示されます。 1つの作業パッケージに、プロジェクト計画に依存関係のある何百ものタスクを簡単に含めることができます。これらの計画は、ERP、ビルディングインフォメーションモデリング、およびその他のプロジェクト計画からのデータを統合し、スケジューラー、プロジェクトマネージャー、および下請け業者にビューを提示する必要があります。 Klusza氏は、次のように説明しています。「Gritのグラフデータベースを使用することで、誰が、いつ、どこで、どの機器を使用し、どの材料を使用して、より豊かな関係を築くことができます。これにより、ビューをパーソナライズし、ジョブスケジュールの競合をより適切に予測できます。」

柔軟な階層を利用するには、グラフデータベースを使用してアプリケーションをゼロから設計するのに役立ちます。次に、グラフにクエリを実行し、グラフのノード、関係、ラベル、およびプロパティを活用して、アプリケーション全体を設計します。

クラウド展開オプションにより、運用の複雑さが軽減されます

データ管理ソリューションをデータセンターに導入することは簡単ではありません。インフラストラクチャと運用では、セキュリティ要件を考慮する必要があります。サーバー、ストレージ、およびネットワークのサイズを決定するためのパフォーマンスの考慮事項を確認します。また、ディザスタリカバリのために複製されたシステムを運用可能にします。

グラフデータベースを実験している組織には、いくつかのクラウドオプションがあります。エンジニアは、Neo4jをGCP、AWS、Azureにデプロイしたり、サービスとしてのデータベースであるNeo4jのAuraを活用したりできます。TigerGraphには、顧客360、不正検出、レコメンデーションエンジン、ソーシャルネットワーク分析、サプライチェーン分析などのユースケース向けのクラウドオファリングとスターターキットがあります。また、パブリッククラウドベンダーには、AWS Neptune、AzureのCosmoDBのGremlin API、GCPのオープンソースJanusGraph、OracleのCloud DatabaseServicesのグラフ機能などのグラフデータベース機能があります。

元の質問に戻ります。すべての興味深いユースケース、利用可能な成熟したグラフデータベースプラットフォーム、グラフデータベース開発を学ぶ機会、およびクラウド展開オプションがあるのに、なぜグラフデータベースを使用するテクノロジー組織が増えないのでしょうか。