16

現在、専門企業向けにCRMのようなソリューションを社内で実装しています。保存される情報の性質、および情報の値とキーが異なるため、目的に完全に適合するドキュメントストレージデータベースを使用することにしました（この場合はMongoDBを選択しました）。

このCRMソリューションの一部として、エンティティ間の関係と関連付けを保存したいと考えています。たとえば、利害関係情報、株主、受託者などの競合を保存します。これらすべてのエンティティを最も効果的な方法でリンクすることで、「関係」の中心的なモデルが必要であると判断しました。 。すべての関係には、履歴情報（開始日と終了日）、およびさまざまなメタデータを添付する必要があります。たとえば、株主関係には、保有する株式数も含まれます。

従来のRDBMSソリューションは以前のニーズに適合していなかったため、現在の状況でそれらを使用することは現実的ではありません。私が判断しようとしているのは、私たちの場合、グラフデータベースを使用する方が適切かどうか、または実際にmongoの組み込みのリレーショナル情報を使用することが適切かどうかです。

関係情報は、システム全体で非常に頻繁に使用されます。実行したい情報クエリの例は次のとおりです。

  • 「xyzlimited」の「クライアント」である企業の「主要な連絡先」の人々をすべて取得する
  • 'john'が株主である会社の他のすべての'株主'を取得する
  • 「abclimited」の「clients」であり、「trustusbanklimited」のクライアントであるエンティティのすべての「Keycontact」の人々を取得します

この関係の「ツリー」構造を考えると、グラフデータベース（Neo4jなど）を使用する方が適切ですか？

4

4 に答える 4

8

マイク、

関係データをグラフデータベースに保存できるはずです。大きなグラフをトラバースする際のその高いパフォーマンスは、局所性に由来します。つまり、クエリをグローバルに実行するのではなく、ノードのセットを開始します（この場合、インデックスによって検索されるドキュメントと同じです。start-node-を格納することもできます。 mongoドキュメントにすばやくアクセスするためのID）。そこから、一定時間（データセットサイズごと）に任意の大きなパスをトラバースできます。

他の要件は何ですか（つまり、データセットのサイズ、同時アクセスの数など、関係/グラフの複雑さ）。

クエリはグラフデータベースに非常によく適合し、その用語で簡単に表現できます。

neo4jのようなgraphdbを取得し、ドメインをすばやくスパイクして、一般的な実現可能性を確認し、2番目のテクノロジーに投資する前に回答したい追加の質問を見つけることをお勧めします。

PSまだ開始していない場合は、グラフデータベースがドキュメントデータベースのスーパーセットであるため、純粋なgraphdbアプローチを使用することもできます。そして、とにかく、一般的なドキュメントよりも、ドメインについて話したいと思います。（たとえば、 structrはNeo4j上に構築されたCMSです）。

于 2011-04-29T07:28:57.503 に答える
6

MongoDBのドキュメントは、関係を除いて、Neo4jのノードに非常に似ています。どちらもKey-Valueプロパティを保持しています。すでにMongoDBを使用することを選択している場合は、Neo4jを使用して関係を保存し、アプリケーション内のストアをブリッジすることができます。新しいテクノロジーを選択する場合は、ノードがドキュメントと同じようにプロパティデータを保持できるため、すべてにNeo4jを使用できます。

関係の部分に関しては、Neo4jが最適です。無関係なドキュメントではなく、グラフがあります。グラフデータベースを使用することはここでは完全に理にかなっており、サンプルクエリにはグラフが全体に書き込まれています。

正直なところ、何が効果的かを知る最良の方法は、低コストで高価値のPoCを実行することです。

免責事項：私はNeoTechnologyで働いています。

于 2011-04-29T18:54:35.157 に答える
1

mongodbにとどまります。2つの理由-1。複雑さを軽減できる場合は同じドメインにとどまるほうがよい2.mongodbはクエリに優れており、たとえば、redisよりも少ない作業で済みます。

于 2011-04-28T16:00:14.150 に答える
1

両方を使用することになり、輸送ネットワーク用の検索エンジンを実装しています。

1つまたは2つの「リンク」を超えると、MongoDBでリレーションシップを実装しようとすると扱いにくくなる可能性があります。基本的に、オブジェクトIDを配列に格納することになり、双方向の関係を実装する場合は、2つの別々のリンクを実装する必要があります。Mongoでは、エンティティ（または「リンク」）への「ポインタ」は単なる別のテキストプロパティ（別の方法で解釈できます）であり、Neo4jの関係のようなファーストクラスのオブジェクトではありません。

そこで、Neo4jを使用してリレーションシップを保存し、MongoDBを使用してその他すべてを保存することにしました。次に、2つのストアの同期を維持することが課題になりました。

MongoDBを別のストアと同期させるメカニズムである「MongoConnector」と呼ばれる10genラボプロジェクトを使用しています。プロジェクトは現在サポートされていませんが、コードは利用可能です：

http://blog.mongodb.org/post/29127828146/introducing-mongo-connector

MongoConnectorは、レプリカメカニズムを使用して同期を実装します。基本的に、MongoDB OpLogを監視しており、アップサート（更新または挿入）と削除のコールバックを実装しています。この実装は、MongoConnectorspeakでは「DocumentManager」と呼ばれます。Neo4jDocumentManagerの実装を終了しました。

クエリ側では、Neoは「友達の友達」の種類のクエリに適しているのに対し、MongoDBは汎用クエリに適していることがわかりました。日付を処理するフィールドまたは範囲ごとのクエリ。

講演とブログ投稿を計画していますが、まだ行っていません。

http://www.meetup.com/graphdb-boston/events/91703472/

このソリューションには、プロセスがダウンした場合に同期が外れたり、同期が遅い（リアルタイムではない）などの欠点があります。

于 2013-03-26T21:21:26.050 に答える