2016-04-11 5 views

答えて

5

Titanを使用する場合、ユースケースによっては、内部的にそのエッジを削除して再作成するため、エッジを変更することはお勧めしません(エッジIDが変更されることに注意してください)。 Cassandraバックエンドを使用している場合、これは自分で処理する必要があるcreation of tombstonesにつながります。可能であれば、エッジの変異を避けてください。実際には、エッジは変化しない "事実"と見なされるべきである(したがって不変性)。 "訪問事実"が発生したので、 "訪問エッジ"が作成された。ファクトは変更されませんが、新しいファクト(新しいエッジ)によって無効にすることができます。

ユーザーには訪問数が少ないと思われる場合は、エッジを突然変異させてcountプロパティを増やしても問題ありませんが、グラフデータベースを使用する利点の一部は失われます(これは反パターン)。多くの訪問が期待される場合は、訪問ごとに新しいエッジを追加することができます(私はそのルートに行くでしょう)。それはグラフデータベースにとって最適なユースケースになります。ボリュームを高くして総訪問数をすばやく取得するには、訪問した頂点にカウンタプロパティを保存して訪問数(エッジ数)を把握することもできます。だから、

+2

私はこれがより良いアプローチだと思います。カウントをインクリメントするのではなく、新しい訪問ごとにタイムスタンプを付けてエッジ自体を追加する必要があります。 –

3

あなたは(プロパティが既に作成されていると仮定した場合)のような何かを行うことができ、突然変異を実行する場合:

Edge edge = g.traversal().V(user1.id).outE("Label").as("found_edge").otherV().hasId(user2.id).select("found_edge").next(); 
int newValue = egde.value("count") + 1; 
edge.property("count", newValue); 
g.commit(); 

しかし、これは非常にunadvisedある@jbmussoで指摘したように。墓石はすぐに問題になり、あなたのシステムは単純に拡大縮小できません。

関連する問題