Jena tdbloader 性能和限制

Wol*_*ahl 5 jena wikidata tdbloader

当尝试按照https://muncca.com/2019/02/14/wikidata-import-in-apache-jena/ 中描述的过程加载获取您自己的 WikiData 副本中记录的当前 Wikidata 转储时我正在运行Apache Jenas tdbloader 命令的一些性能问题和限制。

它似乎有两个版本：

TDB1 tdbloader 的名称 tdbloader2 令人困惑，因此首次尝试使用它。

使用 TDB1/tdbloader2 的经验是，前几十亿个三元组的加载非常顺利。

最初的速度是 150 k 三倍/秒。然后它以大约 90 亿个三元组下降到大约 10 万个三元组/秒。在 100 亿个三元组时，速度在大约 100 亿个三元组时下降到 15000 个三元组/秒，并在向 110 亿个三元组移动时保持在 5000 个三元组/秒左右。

我原以为到那时导入已经完成，所以目前我什至怀疑进度是在计算三元组，而是在计算海龟输入的行，这可能不一样，因为输入有大约 150 亿行，但预计只有大约 110 亿行.

由于此时导入已经运行了 3.5 天，因此我必须决定是否中止它并寻找更好的导入选项，或者只是等待一段时间。

所以我把这个问题放在了stackoverflow上。根据 AndyS 暗示有两个版本的 tdbloader，我在大约 4.5 天后中止了 TDB1 导入，据报道在“数据”阶段导入了超过 110 亿个三元组。那时性能下降到 2.3k 三倍/秒。

使用 tdb2.tdbloader 修改后的脚本，如维基中记录的那样，导入已再次运行多次尝试。两次导入 tdb2.tdbloader 尝试已经失败，导致 Java VM 崩溃，所以我再次将硬件从 MacPro 更改为旧的 linux 机器（不幸的是速度较慢），然后又回来了。

在较旧的 Oracle JVM 在第一次尝试使用 tdb2.tdbloader 时崩溃后，我将 Java 虚拟机更改为最新的 OpenJDK。此 Java VM 崩溃并出现相同的症状 # 内部错误 (safepoint.cpp:310)，参见例如https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8169477

对于 tdb2.tdbloader 的尝试，我假设需要导入 157 亿个三元组（乌龟文件的每一行一个）。对于真实数据集，三元组的数量将是大约 130 亿个三元组。

如果您查看 wiki 文章中显示的性能结果，您会发现当出现对数性能下降时。对于旋转磁盘，退化非常严重，以至于导入需要很长时间，等待结果是不值得的（我们在这里讨论了几个月......）

在下图中，两个轴都有一个对数刻度。x 轴显示导入的三元组总数的日志（导入中止时最多 30 亿） y 轴显示批次/平均大小的日志 - 在给定时间范围内导入的三元组数量。导入的三元组越多，速度越慢，从每秒 300.000 个三元组降到每秒仅 300 个三元组。在第 4 次尝试中，11 天后的性能大约为 1k 三倍/秒，大约 20% 的数据被导入。这意味着在 230 天后完成导入的估计时间 - 鉴于速度下降可能会更长一些（超过一年）。

目标数据库大小为 320 GByte，因此希望结果适合为目标分配的 4 TerraByte 磁盘空间，而不是限制因素。

自从 Jonas Sourlier 在使用 SSD 磁盘大约 7 天后报告了他的成功后，我终于向我的项目负责人询问了为 4 TB SSD 磁盘提供资金并将其借给我进行实验。使用该磁盘，现在对真实数据集的第五次尝试成功了，大约 52 亿个三元组在大约 4 1/2 天后导入。坏消息是，这正是我不想要的——我曾希望通过软件和配置设置来解决问题，而不是通过投入更快、更昂贵的硬件来解决问题。不过这里是这个导入的图表：

我打算很快导入完整的 120 亿个三元组，为此，知道如何通过软件/配置设置或其他非硬件方法提高速度仍然很好。

我还没有调整 Java VM Args 或拆分文件，正如2017 年底 Apache 用户邮件列表讨论中提到的那样

现在的导入速度显然不能接受。另一方面，由于预算有限，无法大量投资额外的硬件。

上面提到的维基文章中的链接没有回答一些问题：

什么被证明可以在不投资额外硬件的情况下加快导入速度？

例如，拆分文件、更改 VM 参数、运行多个进程......

是什么解释了更高数量的三元组速度下降的原因，以及如何避免这种情况？

您知道 Jena 有哪些成功的数十亿三重进口产品，这些产品的情况如何？

归档时间：	5 年，3 月前
查看次数：	425 次
最近记录：	5 年，1 月前