我正在使用带有hbase后端的titan 1.0,每天创建数亿个顶点和边。我反复收到以下错误:
TitanException: Could not acquire new ID from storage
经过一些研究,我能够自己生成顶点ID,但我仍然看到分配错误,同时添加新的边和顶点属性。我能做些什么来克服这个问题?是否可以像这里提供的那样使用uuid设置边缘和属性id?它会影响查询性能吗?谢谢
mqxuamgl1#
经过一番研究,我得出了一些见解。在titan 1.0上,为每个id块分配设置超时的配置设置被移动,现在被调用 ids.authority.wait-time . 此外,您不能通过本地titan属性文件来设置此选项的值——它必须在后端全局更新(在我的例子中是hbase)。超时的默认值为 0.3 seconds -这就是我们经常失败的原因。设置该值后,错误发生的频率大大降低。
ids.authority.wait-time
0.3 seconds
ygya80vv2#
我也遇到了类似的错误,我解决这个问题的方法是增加每个事务可以使用的id块大小。这对我很有帮助:
TitanGraph titanGraph = TitanFactory.open(config); graph.configuration().setProperty("ids.block-size", idBlockSize);
这里的参考文档说明了有关更改ids.block-size的以下内容:全局保留此大小的块中的图形元素ID。将此值设置得太低将使提交频繁地阻止缓慢的保留请求。如果设置得太高,则在关闭带有保留但大部分未使用的块的图示例时,会浪费ID。
2条答案
按热度按时间mqxuamgl1#
经过一番研究,我得出了一些见解。
在titan 1.0上,为每个id块分配设置超时的配置设置被移动,现在被调用
ids.authority.wait-time
. 此外,您不能通过本地titan属性文件来设置此选项的值——它必须在后端全局更新(在我的例子中是hbase)。超时的默认值为
0.3 seconds
-这就是我们经常失败的原因。设置该值后,错误发生的频率大大降低。ygya80vv2#
我也遇到了类似的错误,我解决这个问题的方法是增加每个事务可以使用的id块大小。这对我很有帮助:
这里的参考文档说明了有关更改ids.block-size的以下内容:
全局保留此大小的块中的图形元素ID。将此值设置得太低将使提交频繁地阻止缓慢的保留请求。如果设置得太高,则在关闭带有保留但大部分未使用的块的图示例时,会浪费ID。