当图谱构建完毕后,就需要将数据上传到图谱查看效果,往往数量量比较大,借助一些工具能实现数据的快速上传,dgraph 自带了两个上传命令,dgraph bulk 和 dgraph live。
dgraph bulk:作为首选方案的原因是它的执行效率比dgraph live高很多,话不多说,先罗列一它的执行命令:
dgraph bulk -f data.rdf -s data.schema --map_shards=4 --reduce_shards=1 --zero=localhost:5080
(如果是docker镜像执行,需要在命令前面加上docker exec -it xxx dgraph bulk…… <xxx为镜像名>)
查看命令有什么参数,执行dgraph bulk --help,
参数说明:
-f 为上传的数据文件名,可以为rdf格式或者压缩成gz文件
-s 为字段定义文件,类似于mysql的表结构
--map_shards 没有做特殊说明,大致意思是它设置的大一点,数据分布在不同分片会更均匀
--reduce_shards 这个根据副本数和server的节点数来定,如果你是三个节点,并且副本为3, 此参数就设置为1,如果有6个节点,则设置为2,因为它会在执行该命令的服务器上生成out文件夹,里面会根据这个参数将数据分成reduce_shards份数
--zero 这个参数即填写zero命令所在的服务器。
操作说明:
这条命令是离线执行的,dgraph服务必须先停掉,将p和w文件清空,只需要启动zero命令的服务,执行完上传命令后,会生成一个out文件夹,会生成reduce_shards份数据,进入里面找到p和w文件夹,复制至各节点dgraph主目录对原先的p、w进行覆盖,重新启动服务, 数据导入完成。
性能调优(来源:https://www.jianshu.com/p/ffd4c88e8280):
Map
在map语句中,修改下面的参数可以降低内存使用:
--num_go_routines
标志控制worker线程的数量,数值越小,占用的内存越少
--mapoutput_mb
标志控制map输出文件的大小,数值越小,占用的内存越少
对于更大的数据集,以及有很多core的服务器,map中的gzip解码可能会成为瓶颈,可以首先把RDF拆分成多个.rdf.gz
文件(例如每个256MB)。这对内存使用会有略微的影响
Reduce
Reduce语句对内存的压力比map小,尽管它仍然可能会使用很多内存。有些参数可以提高性能,但是只有在你有很大的RAM的情况下使用:
--reduce_shards
控制产生的dgraph实例数。增大--map_shards
flag controls the number of separate map output shards. Increasing this increases memory consumption but balances the resultant dgraph instances more evenly.--shufflers
controls the level of parallelism in the shuffle/reduce stage. Increasing this increases memory consumption.dgraph live: 根据live单词即可知道,它是在线更新数据的,不需要暂停服务,命令如下:
dgraph live -r g01.rdf.gz -s g01.schema -d localhost:9080 -z localhost:5080