我一直在阅读文档，但我无法确定批量加载的一般准则。
据我所知，将数据批量加载到graphdb中的最佳方法是使用LoadRDF tool。
然而，我并不熟悉适当设置的一般规则。 首先，如果你有一个带有SSD驱动器的“普通”服务器，可以接受哪种解析速度？ 1.000语句/秒，10.000语句/秒或更多或更少？
还有什么好的设置？例如，您可以设置-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内存和32个内核以及1.8T raid 0 SSD驱动器（加载后将备份）并尝试初始加载30亿个三倍，从SSD到相同SSD，全球速度为每秒16.461个语句需要一段时间，但我不确定是否以及如何改进这一点。
答案 0 :(得分：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时间。