Question

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

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

在获取顶点时从图中读取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功能？

Answer 1

无法在JanusGraph中使用Cassandra计数器。更甚者，无法将Cassandra计数器与一般的Cassandra表一起使用。卡桑德拉（Cassandra）计数器的逻辑以这样的方式开发：更新计数器不需要锁。这就是为什么您会受到很多限制以换取出色的性能的原因。

计算views并非易事。简而言之，我的建议是选择选项3。

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

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

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

在janusgraph

1 个答案: