loadRestAPI.sh 脚本基本上是以下内容中提到的脚本：
https://wiki.blazegraph.com/wiki/index.php/Bulk_Data_Load#Command_line
因此应该可以直接使用命令行工具而不是 REST API。
而且整个过程看起来也很尴尬。该工具依赖于 .gz 文件，该文件比 .bz2 文件大 25%，并且下载时间更长。解压缩 .bz2 文件比 munge 过程更快。我的假设是处理解压后的 230GB 文件，例如
230033083334 一月 4 07:29 wikidata-20180101-all-BETA.ttl
以“块明智”的方式可能会效果更好。但首先我们需要看看是什么导致了进口的停滞。
我的第一个问题是 shell 脚本 runBlazegraph.sh 给出了缺少 mwservices.json 的错误。
我假设一个文件像https://github.com/wikimedia/wikidata-query-deploy/blob/master/mwservices.json是期待。
所以我尝试用以下方法解决这个问题
wget https://raw.githubusercontent.com/wikimedia/wikidata-query-deploy/master/mwservices.json
尽管我怀疑这是否有多大意义。
实际调用
./loadRestAPI.sh -n wdq -d data/split/wikidump-000000001.ttl.gz
Loading with properties...
quiet=false
verbose=0
closure=false
durableQueues=true
#Needed for quads
#defaultGraph=
com.bigdata.rdf.store.DataLoader.flush=false
com.bigdata.rdf.store.DataLoader.bufferCapacity=100000
com.bigdata.rdf.store.DataLoader.queueCapacity=10
#Namespace to load
namespace=wdq
#Files to load
fileOrDirs=data/split/wikidump-000000001.ttl.gz
#Property file (if creating a new namespace)
propertyFile=/home/wf/wikidata/wikidata-query-rdf/dist/target/service-0.3.0-SNAPSHOT/RWStore.properties
<?xml version="1.0"?><data modified="0" milliseconds="493832"/>DATALOADER-SERVLET: Loaded wdq with properties: /home/wf/wikidata/wikidata-query-rdf/dist/target/service-0.3.0-SNAPSHOT/RWStore.properties
我在使用 Java 1.8.0_151 的 Ubuntu 16.04 LTS 服务器上工作，所以我相信我们必须研究更多细节来解决 Thomas 的问题。
也可以看看https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-query/Documentation
更多细节。
为了检查结果，我使用 ssh 隧道连接到我的 ubuntu 服务器
ssh -L 9999:localhost:9999 user@server
进而
http://localhost:9999/bigdata/namespace/wdq/sparql
在我的本地计算机（笔记本电脑）浏览器的浏览器中。
第二次导入也正常。
然后我使用以下 SPARQL 查询检查了数据库内容：
SELECT ?type (COUNT(?type) AS ?typecount)
WHERE {
?subject a ?type.
}
GROUP by ?type
ORDER by desc(?typecount)
LIMIT 7
给出结果
type typecount
<http://wikiba.se/ontology#BestRank> 2938060
schema:Article 2419109
<http://wikiba.se/ontology#QuantityValue>. 78105
<http://wikiba.se/ontology#TimeValue>. 61553
<http://wikiba.se/ontology#GlobecoordinateValue> 57032
<http://wikiba.se/ontology#GeoAutoPrecision> 3462
<http://www.wikidata.org/prop/novalue/P17>. 531
考虑到导入经验，我想说 munge 和 loadRestAPI 调用可以在某种程度上并行运行，因为 loadRestAPI 步骤显然较慢。
导入每个 gz 文件大约需要 5 分钟。后来这个问题消失了，一些文件实际上在 Wolfgang 的服务器上花费了长达 1 小时 15 分钟的时间。
在 Wolfgang 的第一台机器上加载所有数据可能需要 10 天或更长时间，因此请继续关注最终结果。
目前，440 个文件中的 358 个是在 158 小时后在此计算机上导入的。此时 wikidata.jnl 文件有 250 GB 大，并且已导入约 17 亿条语句。
加载统计数据相当尴尬。在 Wolfgang 的机器上加载 *.ttl.gz 文件之一需要 87 到 11496 秒。此时平均为 944 秒。看起来在导入过程中的某些步骤中，每个 gz 文件的时间会增加，例如从 805 到 4943 秒或从 4823 到 11496 - 之后时间似乎稳定在更高的水平并回到 293 或 511 秒。这种计时行为使得预测完全导入需要多长时间变得非常困难。
鉴于装载时间较长，沃尔夫冈配置的第二台进口机器略有不同。
- 机器：8 核、56 GB RAM、6 TB 5.400 rpm 硬盘
- 机器：8 核、32 GB RAM、1 512 GB 7.200 rpm 硬盘和 1 480 GB SSD
第二台机器将要导入的数据存储在 7.200 rpm 硬盘上，并将 blazegraph 日志文件存储在 SSD 上。
第二台机器导入在导入完成 3.8 天后显示出更好的计时行为，统计数据如下：
| sum d | sum h | mins | secs |
----+--------+---------+--------------+--------------+
MIN | 0.0 d | 0.0 h | 1.2 mins | 74 secs |
MAX | 0.0 d | 1.1 h | 64.4 mins | 3863 secs |
AVG | 0.0 d | 0.2 h | 12.3 mins | 738 secs |
TOT | 3.8 d | 90.2 h | 5414.6 mins | 324878 secs |
10天后第一台机器仍未完成
SUM | 10.5 d | 252.6 h | 15154.7 mins | 909281 secs |
----+--------+---------+--------------+--------------+
MIN | 0.0 d | 0.0 h | 1.5 mins | 87 secs |
MAX | 0.3 d | 7.3 h | 440.5 mins | 26428 secs |
AVG | 0.0 d | 0.6 h | 36.4 mins | 2185 secs |
TOT | 11.1 d | 267.1 h | 16029.0 mins | 961739 secs |
----+--------+---------+--------------+--------------+
ETA | 0.6 d | 14.6 h | 874.3 mins | 52458 secs |
