3

関係を具体的に扱うためにグラフデータベースを使用する価値があるかどうかを知りたいです。

「ユーザー」、「ページ」、「コメント」、「投稿」などのエンティティを格納するためにリレーショナル データベースを使用するふりをしています。

しかし、典型的なソーシャル グラフ ベースのワークロードのほとんどの場合、深いトラバーサルを取得する必要があり、リレーショナルでは対処しきれず、結合が遅くなります。

例：コメント-(made_in) ->投稿-(made_in) ->ページetc...

私はこのようなものを作ることを考えています：

例：

ユーザーID: 1

クエリ: user_id 1 のすべてのフォロワーを取得する

  • ID 1 のノード ユーザーの「follows」という名前のすべての出力エッジについて、Neo4j にクエリを実行します。

  • ID のリストを使用して、Users テーブルでそれらをクエリします。

    SELECT * FROM ユーザー WHERE user_id IN (ID)

これは遅いですか？

この質問を見たことがあります MySQL と Neo4j を一緒に使用することは良い考えですか? 、しかし、正解がなぜそれは良い考えではないと言うのか、まだ理解できません。

ありがとう

4

3 に答える 3

1

他の回答が示すように、Neo4j を単一のデータ ストアとして使用することをお勧めします。ただし、場合によっては、製品の背後に別のデータベースが既にある場合、選択肢があまりない場合があります。この場合、セカンダリデータベースとしてneo4jを実行すると機能することを追加したいと思います（私が取り組んでいる製品はこのモードで動作します）。neo4j に期待する機能、それに必要なデータの種類、データの同期を維持する方法、および常にリアルタイムではない結果に苦しむことの結果を理解するために、特別な努力をする必要があります。私たちのユースケースのほとんどは、ほぼリアルタイムの結果で動作するので問題ありません。お使いの製品には当てはまらない場合があります。それでも、私にとっては、このモードで neo4j を使用することは、neo4j なしで実行するよりも依然として望ましいことです。その結果、多くの優れたグラフィックスを生み出すことができます。

于 2013-04-06T03:03:17.587 に答える
1

一般に、データベース/システム/レイヤーが増えるほど、セットアップと操作全体が複雑になります。

データベースのサイズが大きくなると、同期、エクスポート/インポート、バックアップ/アーカイブなどのすべてのタスクが非常に高価になることを考えてみてください。

専用の特殊なデータベースを持つことの利点が、複数のデータストアに対処しなければならないという欠点を上回る場合にのみ、人々はポリグロットの永続性を使用します。これは、それぞれがユーザーに関連する多数のデータ項目 (アクティビティ ログまたはトランザクション ログ) がある場合に当てはまります。データ項目間の接続のみに関心がある場合、すべての情報をグラフ データベースに格納することはおそらく意味がありません。そのため、関係のみをグラフに格納し (ノードには他のデータベースへのポインターしかありません)、アイテムごとのデータを K/V ストアなどに格納することをお勧めします。

あなたのユースケースの例では、グラフであるため、Neo4jという1つのデータベースのみを使用します。

于 2013-04-05T20:58:34.187 に答える