- 对于Dgraph只是试摸索阶段， 其中还有很多点从未涉及， 后续需要更新优化
1、Dgraph启动
启动zero ./dgraph zero --log_dir ***
启动alpha
./dgraph alpha --badger.tables disk --badger.vlog disk --abort_older_than 1m --pending_proposals 1000 --lru_mb 3072 --query_edge_limit 100000000 --log_dir ***
- 本地测试环境内存较小， 设置的直接存储在磁盘， 查询内存增加到3G， 默认查询内存为1G， 同时设置了最大边查询上限
2、Dgraph的数据录入
- 使用pydgraph录入数据(json格式)
- 主要的数据录入可分为两个步骤， 录入点数据(node)，录入关系数据(edge)
Node数据录入
由于本地环境采用的是先写入node数据生成一批添加了UID的node结构，之后可根据node的UID导入图的关系结构，因此分两步完成。
-
dgraph提供了外部的xid用于生成uid， 具体实现方式还在学习， 移步https://www.jianshu.com/p/db730cbf282f有一些dgraph的概念解析
对于多线程写入数据的环境， 存在着诸多问题， 不同的事务操作同一个节点数据， 会抛出事务冲突错误。解决办法分为两种（1、添加试错机制， 捕获异常后等待特定时间后重试（git中有dgraph4j下的演示代码）。2、单线程写入(目前我采取的办法， 同时加入了试错机制) ）。
具体步骤思路：
- 遍历队列中的数据
- 对数据查重
- 对不存在的数据进行存储操作，生成作为唯一主键uid，并增加了试错机制，最多限制5次试错
Edge数据录入
理论上数据库中已经存在了目标数据所有的节点， 目前只需要对数据进行查询并生成入下的数据格式即可。
{uid:"0x1", scan_to:[{uid:"0x2"}, {uid:"0x3"}]} //scan_to为数据库中自设定的字段值
对于数据录入遇到的问题
1、 事务的生成
- txn = client.txn(read_only=True)， 尽量少的使用best_effort参数， 对于查询结果准确率影响较大(demo环境中反应的情况)
2、数据的写入
client.txn().mutate(set_obj=insert_list, commit_now=True)
time.sleep(0.01)
commit之后尽可能的进行一次睡眠操作(建议、具体博客出处暂时找不到)
3、 对于事务txn的闭合必须清楚
- txn在进行commit或者discard之后都不可以继续操作， 因此需要清楚txn的提交或者关闭的状态
具体环境中出现的问题也需要具体处理， 此处只是我遇到的问题只做参考
3、数据查询
官方文档中对于查询文档说的足够细， 查询文档中基本涵盖了能想到的所有的场景不做过多拓展。但是需要注意的是， 在较大数据查询时可能存在grpc的报错， 原因是grpc数据传输管道最大支持5m数据， 需要在本地查询客户端内给与扩大grpc上限值
类似https://www.jianshu.com/p/8c2ca29fd3f9中提到的
pydgraph.DgraphClientStub(DGRAPH_SERVER_ADDR, options=[('grpc.max_receive_message_length', 1024 * 1024 * 512)])
同时， 在查询时尽量限制查询结果层数。数据量较大时还是会突破启动数据库给与的上限值。
4、数据展示
数据展示因人而异的选择插件。我采用的是开源的vis.js。官网文档加载较为缓慢， 并且是英文的。具体的中文文档https://ame.cool/pages/a7d858/对官网的文档中文化做的最好。
这是本地的具体效果图， 内部具体逻辑为双击后查询并展示下一级/隐藏子节点
