graphdb 中批量加载的最佳设置

Question

我一直在浏览文档，但无法确定批量加载的一般准则。

据我所知，将数据批量加载到 graphdb 的最佳方法是使用LoadRDF tool。

但是，我并不熟悉适当设置的一般规则。 首先，如果您有一个带有 SSD 驱动器的“普通”服务器，那么什么样的解析速度是可以接受的？ 1.000 条语句/秒、10.000 条语句/秒还是更多还是更少？

还有什么好的设置？例如，您可以设置 -Dpool.buffer.size 的默认值为 200.000 条语句，但如果您有 10gig 的 ram，那么增加这个的经验法则是什么？如果您有 100 或 300 gig 的 ram？

另一个选项是 -Dinfer.pool.size，它设置为最大线程数，因为 CPU 最少为 4。因此 1 核 = 4 线程，32 核为 32 线程。我认为这不需要任何额外的调整，或者只有当你想减少 CPU 负载并且如果你有 32 个内核时不超过 64 个线程时才需要这样做？

turtle 文件还提供了额外的选项，configs/templates 中的示例可能是 owlim:cache-memory 和 owlim:tuple-index-memory加载期间有用，加载后其他设置更有用吗？

最后，如果您有 100 个单独的文件而不是一个大的海龟文件和/或压缩文件是否会提高加载速度还是只会减少初始磁盘使用量，这也很重要？

就我个人而言，我目前设置了 290gb 内存和 32 个内核和 1.8T raid 0 SSD 驱动器（加载后会有备份）并尝试进行 30 亿三倍的初始加载，从 SSD 到相同SSD，全球速度为每秒 16.461 条语句，需要一段时间，但我不确定是否以及如何改进。

Answer 1

参考标准数据加载速度的最佳位置是GraphDB benchmark page。

从计算的角度来看，数据加载过程包括为所有 RDF 资源生成唯一的内部 ID，并为 PSOC、POSC 和 CPSO 等多个排序集合中的所有语句编制索引（如果启用了上下文索引）。这个过程主要受以下因素影响：

• 推理复杂性 - 数据库集成了前向链接推理引擎。这意味着对于每个新添加的语句，都会递归触发一组预定义的规则。根据特定的数据集和配置的规则，物化隐式语句的数量可能会急剧增加。数据加载速度受索引语句数量的影响，但不受输入显式三元组的影响。

• 数据集的大小 - 随着每个集合中编号索引语句的增加，添加更多数据的时间也会增加。主要的两个因素是已排序集合的对数复杂度，以及由于至少一个集合中随机出现的 ID 而导致的页面拆分次数。

只有在有推理的情况下，CPU 内核的数量才会加快数据加载速度。每个新文件的导入都会有最小的开销，所以除非它们的大小相当大，否则这不应该是一个问题。对于堆大小，我们发现 SSD 和限制为 30GB 的堆大小的组合效果最好。如果您将堆大小限制为 30GB，那么您可以从 XX:+UseCompressedOops 中受益，并且仍然有合理的 GC 时间。

请注意，GraphDB 8.x 还将为不可变数据结构（例如 RDF 资源到内部 ID 的映射）保留堆外空间！对于 3B 数据集，它可能会变成 15GB 大。这个设计决策背后的主要原因是为了节省 GC 时间。