我一直在阅读文档，但我无法确定批量加载的一般准则。
据我所知，将数据批量加载到 graphdb 中的最佳方法是使用LoadRDF 工具。
但是，我不熟悉适当设置的一般规则。首先，如果你有一个带有 SSD 驱动器的“普通”服务器，可以接受哪种解析速度？ 1.000 statements/sec，10.000 statements/sec 还是更多或更少？
还有什么好的设置？例如，你可以设置-Dpool.buffer.size，它有一个默认的 200.000 语句，但如果你有 10gig 的 ram，那么增加这个和你有 100 或 300 gig 的 ram 的经验法则是什么？
另一个选项是-Dinfer.pool.size，它设置为线程的最大值，因为 cpus 的最小值为 4.因此，1 个核心= 4 个线程，32 个核心是 32 个线程。我认为这不需要任何额外的调整，或者仅当你想要减少 CPU 负载而不是过冲时，如果你有 32 个内核就可以说 64 个线程？
还有通过 turtle 文件提供的额外选项，其中包含configs/templates中的示例，其中 owlim:cache-memory 和 owlim:tuple-index-memory 可能在加载过程中有用，而其他设置在加载后更有用？
最后，如果你有 100 个单独的文件而不是一个大龟文件和/或压缩文件会增加加载速度还是只减少初始磁盘使用量呢？
就我个人而言，我目前设置了 290gb ram 和 32 个核心以及 1.8T raid 0 SSD 驱动器(加载后将备份)并尝试从 SSD 到相同的 SSD 进行 30 亿三倍的初始加载，其中每秒 16.461 语句的全球速度需要一段时间，但我不确定是否以及如何改进这一点。
1 回答
获得标准数据加载速度参考的最佳位置是GraphDB 基准页面。
从计算的角度来看，数据加载过程包括为所有 RDF 资源生成唯一的内部 ID，并索引多个已排序集合中的所有语句，如 PSOC，POSC 和 CPSO(如果启用了上下文索引)。此过程主要受以下因素影响：
推理复杂性 - 数据库集成了一个正向链接推理引擎。这意味着对于每个新添加的语句，递归地触发预定义的规则集。根据特定数据集和配置的规则，具体化隐式语句的数量可能会急剧增加。数据加载速度受索引语句数量的影响，但不受输入显式三元组的影响。
数据集的大小 - 随着每个集合中编号索引语句的增加，添加更多数据的时间也会增加。主要的两个因素是排序集合的对数复杂度，以及由于至少一个集合中随机出现的 ID 而导致页面拆分的数量。
只有存在推断时，CPU 内核的数量才会加速数据加载。每个新文件的导入都将具有最小的开销，因此除非它们的大小相当大，否则这不应该是一个问题。对于堆大小，我们发现 SSD 和堆大小限制为 30GB 的组合效果最佳。如果将堆大小限制为 30GB，那么您可以从
XX:+UseCompressedOops中受益，并且仍然具有合理的 GC 时间。请注意，GraphDB 8.x 还将为不可变数据结构保留堆空间，例如将 RDF 资源映射到内部 ID！对于 3B 数据集，它可能会变得大到 15GB。此设计决策背后的主要原因是节省 GC 时间。