在janusgraph中增加顶点计数器属性的有效方法答案

【问题标题】：Efficient way to Increment Vertex counter property in janusgraph在janusgraph中增加顶点计数器属性的有效方法
【发布时间】：2018-04-24 10:15:23
【问题描述】：

我正在使用带有 ES 的 Cassandra 后端的 janusGraph-0.2.0。

我想在 Vertex 属性中存储视图数量，需要一种高效且可扩展的方式来增加/存储视图数量而不影响读取性能。

在获取顶点时从图中读取views 属性，并在另一个查询中更新新的views 计数。（不会影响读取性能，但计数器不同步）
```
g.V().has("key","keyId").valueMap(true);
g.V(id).property('views', 21);
```

使用sack 存储值1，并将其添加到views 属性中。

g.withSack(0).V().has("key","keyId").
   sack(assign).by("views").sack(sum).by(constant(1)).
   property("views", sack())

使用内存存储 (Redis) 来增加计数器，并定期将更新保存在图表中。
还有其他更好的方法吗？

有没有办法在 janusGraph 中使用 cassendra 的 counter 功能？

【问题讨论】：

标签： gremlin janusgraph

【解决方案1】：

没有办法在 JanusGraph 中使用 Cassandra 计数器。更何况，一般的 Cassandra 表没有办法使用 Cassandra 计数器。 Cassandra 计数器的逻辑以更新计数器不需要锁定的方式开发。这就是为什么你会得到很多限制来换取出色的性能。

计数views 不是那么容易的任务。简而言之，我的建议是选择选项 3。

如果我们在单个数据中心并且您的单个主服务器可以处理所有请求，我会使用 Redis 并定期更新 JanusGraph（您当然可以使用一些哈希环在不同的 Redis 服务器之间拆分您的计数器，但是它会增加维护的复杂性成本）。

如果您有多个数据中心，您的单个主 Redis 服务器无法处理所有请求，我会使用 Cassandra 计数器。

如果您有大量的view 事件，那么即使是 Cassandra 计数器（及其缓存）也无法处理所有请求，因为磁盘访问次数过多，并且由于成本高昂而无法进行更多扩展，那么逻辑将更难。我从来没有遇到过这种情况，所以这只是理论上的。在这种情况下，我将开发应用程序服务器来缓存和分组views，并定期将此缓存的数据发送给 RabbitMQ 工作人员，以便他们可以更新 Cassandra 计数器，然后使用 JanusGraph 中的总视图量更新必要的顶点。在这种情况下，顶点views 会经常被分组，这样我们就不需要每次都用 +1 更新计数器，而是在一次更新中用 +100 或 +1000 个视图更新。它会大大降低磁盘使用率，并且您最终将获得一致且快速的计数器。同样，这个解决方案只是理论上的，应该进行测试。我相信其他解决方案也存在。

【讨论】：