【发布时间】:2016-08-01 06:20:23
【问题描述】:
我将顶点作为 User1 和 User2。当 User1 访问 User2 个人资料时,正在添加一个带有计数变量的边(即访问过)。
当 User1 再次访问 User2 个人资料时,我如何增加计数变量。
【问题讨论】:
标签: graph graph-databases gremlin titan
我将顶点作为 User1 和 User2。当 User1 访问 User2 个人资料时,正在添加一个带有计数变量的边(即访问过)。
当 User1 再次访问 User2 个人资料时,我如何增加计数变量。
【问题讨论】:
标签: graph graph-databases gremlin titan
使用 Titan 时,根据用例,不建议对边进行变异,因为它在内部会导致删除和重新创建该边(请注意边 id 会更改)。如果使用 Cassandra 后端,这可能会导致您必须自己处理 creation of tombstones。如果可以的话,避免改变边缘。实际上,边应该被视为不会改变的“事实”(因此是不变性):发生了“访问事实”,因此创建了“访问边”。事实不会改变,但它们可能会因新事实(新边)而失效。
如果您希望用户访问量很少,那么改变一条边并增加一个 count 属性应该没问题,尽管您有点失去了使用图形数据库的一些好处(我会说这是一种一个反模式)。如果您预计会有很多访问,您可能希望每次访问都添加一条新边(我会选择那条路线),这将是图形数据库的完美用例。为了获得更高的访问量和更快地检索总访问次数,您可能还希望通过在访问的顶点上存储计数器属性来跟踪访问计数(边数)。
【讨论】:
因此,如果您想执行突变,您可以执行以下操作(假设该属性已创建):
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();
但是,正如@jbmusso 所指出的,这是非常不建议的。墓碑很快成为一个问题,您的系统根本无法扩展。
【讨论】: