janus graph id 生成逻辑会与扩展应用程序冲突吗

Question

在探索 JanusGraph-core 库时，我看到了 id 生成部分（StandardIDPool.nextID()），它似乎是由应用程序逻辑生成的 janus 顶点的 id。在这种情况下，如何水平扩展使用 janusGraph 的应用程序，在扩展应用程序时是否不会遇到 id 冲突问题？

扩展使用 JanusGraph 的应用程序的最佳方法是什么？

Answer 1

图的 JanusGraph 实例选择一个维护 ID 池管理器的实例。JanusGraph 参考文档介绍了以下有关优化 ID 分配的内容：

\n

ID块大小

\n

每个新添加的顶点或边都被分配一个唯一的 id。JanusGraph\xe2\x80\x99s id 池管理器获取特定 JanusGraph 实例的块中的 id。id块获取过程是昂贵的，因为它需要保证块的全局唯一分配。增加 ids.block-size 会减少获取次数，但可能会导致许多 id 未分配并因此被浪费。对于事务工作负载，默认块大小是合理的，但在批量加载期间，顶点和边的添加更加频繁且连续。因此，通常建议根据每台机器要添加的顶点数量将块大小增加 10 倍或更多。

\n

经验法则：将 ids.block-size 设置为您希望每个 JanusGraph 实例每小时添加的顶点数。

\n

重要提示：所有 JanusGraph 实例必须配置相同的 ids.block-size 值，以确保正确的 id 分配。因此，在更改此值之前请小心关闭所有 JanusGraph 实例。

\n

ID获取流程

\n

当多个JanusGraph实例频繁并行分配id块时，实例之间不可避免地会出现分配冲突并减慢分配过程。此外，由于批量加载而增加的写入负载可能会进一步减慢该过程，直至 JanusGraph 认为它失败并抛出异常。可以调整三个配置选项来避免这种情况。

\n

\n
1. ids.authority.wait-time 配置 id 池管理器等待存储后端确认 id 块应用程序的时间（以毫秒为单位）。该时间越短，应用程序在拥塞的存储集群上失败的可能性就越大。
\n

\n

经验法则：将此值设置为在负载下存储后端集群上测量的第 95 个百分位读取和写入时间的总和。重要提示：该值在所有 JanusGraph 实例中应该相同。

\n

\n
2. ids.renew-timeout 配置 JanusGraph\xe2\x80\x99s id 池管理器在尝试获取新 id 块失败之前总共等待的毫秒数。
\n

\n

经验法则：将此值设置为尽可能大的值，以免因不可恢复的故障而等待太久。增加它的唯一缺点是 JanusGraph 会在不可用的存储后端集群上进行很长时间的尝试。

\n