我的用例是一个包含数亿个顶点(比如 100M 到 1B)的图。每个顶点都有一组 10 个属性，这些属性基本上是根据顶点边的权重和相邻顶点的分数计算的分数。在图中添加(或删除)节点时，可能需要重新计算所有顶点的分数。这不需要实时完成，因此这绝对是一个 OLAP/批处理用例。还有一些非常简单的图OLTP需求，基本上就是读取给定顶点及其相邻节点的分数。 我正在尝试确定是否应该采用以下任一方法: 1- Giraph:这意味着以文件格式导出整个图，将其加载到 Giraph 中，然后将结果加载回用于持久保存图的任何数据存储区(Neo4J、Neptune、JanusGraph、HBase、RDBMS...) . 2- Tinkerpop3 的 GraphComputer:如果我理解正确，我可以直接在兼容 Tinkerpop3 的图数据库(JanusGraph、Neptune 等？)上运行 OLAP 图更新算法，从而用一个工具同时解决 OLAP 和 OLTP 用例，无需进行额外的数据导入/导出。
最佳答案
如果您尚未获得所需的 Graph OLAP 性能，或者如果将数据移动到 Spark 证明速度缓慢或繁琐，我建议您看看 AnzoGraph。它由构建 Netezza 和 ParAccel/Redshift 的同一个团队编写。
AnzoGraph 是大规模并行处理原生图 OLAP (GOLAP) 引擎的全新 C/C++ HPC 实现，即数据仓库样式的交互式或批量报告分析和图数据聚合。它的性能非常高，并且可以在商用计算机上线性扩展，因此可以处理您提到的数据集(您甚至可能不需要集群来处理那么大的数据)。在撰写本文时，它不支持 Tinkerpop/Gremlin，这对您来说可能是个问题。它确实支持 SPARQL1.1 和 RDF*(属性图支持，这还不是 W3C SPARQL 标准的一部分)以及常规分析所需的许多附加扩展函数/聚合函数。它还支持推理、命名查询、 View 、各种图算法等
免责声明:我在 Cambridge Semantics 工作。
关于graph-theory - 图 OLAP 处理 - Giraph vs. Tinkerpop3 GraphComputer，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48528301/