0

グラフ データベースに適していると思われる問題がありますが、それを適用する最善の方法がわかりません。

最初に、方向リンクを持つことができるオブジェクトのセットがあります (それらの数は数千万で、典型的なリンクのイン/アウト数はオブジェクトごとに数千です)。次に、各オブジェクトは、潜在的に非常に多数のユーザー (数千万人も) から評判 (賛成票、カルマなどを考えてください) を蓄積できます。

注意が必要なのは、ユーザーがオブジェクトの評価を調整するたびに、かなり複雑なルールに基づいて、リンクされたすべてのオブジェクトの評価を (おそらく 1 度を超えて) 更新したいということです。

SQL では、これは次のようになります。

CREATE TABLE objects (id INTEGER PRIMARY KEY);
CREATE TABLE object_links (from_object_id INTEGER, to_object_id INTEGER);
CREATE TABLE users (id INTEGER PRIMARY KEY);
CREATE TABLE object_reputations (object_id INTEGER, user_id INTEGER, reputation FLOAT);

UPDATE
    object_reputations
SET
    object_reputations.reputation = object_reputations.reputation + ... # some formula goes here
FROM
    object_reputations
    INNER JOIN object_links
        ON object_reputations.object_id = object_links.to_object_id
WHERE
    object_links.from_object_id = ...;

これはグラフを扱っているため、グラフ データベースは自然に適合するように思われますが、Neo4j / OrientDB / Blazegraph / Tinkerpop API をざっと読んだだけでは、この問題をどのようにマッピングできるのかわかりません。全然します。

例として Tinkerpop を使用すると、オブジェクトは Vertex であり、オブジェクト間のリンクは Edge であり (これまでのところすべて良い)、評判は...? おそらくVertexPropetriesですが、頂点ごとにユーザーと同じ数のプロパティが潜在的にある場合、物事がどのようにスケーリングされるかはわかりません。または、評判はユーザー頂点からの加重エッジである可能性があります...これには、別の種類のパフォーマンスの問題があるようです。

この種の問題を一般的なグラフ データベースの 1 つに簡単に変換できますか?

4

2 に答える 2

2

それは、データのクエリ方法に大きく依存すると思います。評価に有限数の値があり、その値がユーザー間で繰り返される場合、評判も頂点になる可能性があります。たとえば、1 ～ 10 の数字の場合、レピュテーションが 7 のすべてのユーザーをこの頂点にリンクさせることができます。このモデルを使用すると、頂点からクエリを開始して、その評判を持つすべてのユーザーを簡単に見つけることができます。Gremlin を使用すると、次のようになります。

g.V().has(label,"reputation").has("reputation","7").in()

これにより、レピュテーションが「7」のレピュテーション頂点にリンクされているすべての頂点が返されます。

または、評判をプロパティとして持つこともでき、そのようなプロパティを持つすべての頂点を探すことができます。

g.V().has("reputation","7")

プロパティの数は問題になりません。Titan は、照会するプロパティにインデックスを付けることをお勧めします。これにより、ルックアップが大幅に改善されます。

于 2016-09-19T19:44:54.187 に答える