去年做知识图谱项目，团队在 Neo4j 和 Dgraph 之间纠结了好久。Neo4j 名气大，但 License 贵得离谱，单机版一年就要十几万。Dgraph 开源免费，而且原生支持分布式，听起来很香。可网上资料少得可怜，中文文档更是稀碎。我们硬着头皮上了车，踩了无数坑，也攒了不少经验。今天就跟大家聊聊，怎么从零搭建一套能扛住千万级关系的 Dgraph 系统。
先说安装。Dgraph 的 Docker 部署最省心，一条命令就能拉起三个组件：Zero、Alpha 和 Ratel。Zero 管理集群元数据，Alpha 存数据，Ratel 是可视化界面。我建议别用 latest 标签，指定版本号更稳，比如 v21.03.2。跑起来后，用 Ratel 连接 Alpha 的 8080 端口，能看到一个类似 Neo4j 浏览器的界面。这时候别急着导入数据，先调几个关键参数。Alpha 的默认内存限制是 512 MB，生产环境至少给 4 GB，不然查询稍微复杂点就 OOM。还有，一定要开 HTTPS，GraphQL 端点暴露在公网上就是裸奔。
数据建模是 Dgraph 的精髓，也是最容易翻车的地方。Dgraph 用三元组存数据，类似 RDF 的 Subject‑Predicate‑Object。比如“张三认识李四”，Subject 是张三，Predicate 是认识，Object 是李四。这和关系型数据库的思维方式完全不同。我见过有人把 Dgraph 当 MySQL 用，建了一堆冗余边，结果查询性能惨不忍睹。正确的做法是，把实体和关系都当成节点，用边连接。比如用户和订单，用户是一个节点，订单是另一个节点，用户下的订单是一条叫“下单”的边。这样设计，一条查询就能拿到用户的所有订单，不用做 JOIN。
导入数据是第二个大坑。Dgraph 支持 JSON 和 RDF 格式，但官方文档对批量导入的优化讲得不够细。我们当时用 Python 写了个脚本，一条条 INSERT，10 万条数据跑了半个小时。后来发现，用 Dgraph 的 Bulk Loader 才是正解。把数据写成 N‑Triples 格式，用 bulk 命令导入，百万级数据几分钟搞定。还有个细节，数据里的字符串字段尽量用 hash 索引，默认的 exact 索引在模糊查询时慢得离谱。比如用户名，用 exact 索引查“张三”很快，但查“张%”就卡死。换成 hash 索引，模糊查询性能提升十倍以上。
查询语言是 Dgraph 的另一个门槛。它用 GraphQL+-，乍一看和标准 GraphQL 差不多，但多了很多图数据库特有的操作符。比如“张三的朋友的朋友”，标准 GraphQL 需要写嵌套查询，GraphQL+- 用 就搞定。还有递归查询， 表示反向边， 能展开所有邻接节点。这些操作符看着简单，实际使用时门道很多。我建议初学者先别碰复杂的递归，从基础查询开始，比如查某个节点的属性，或者查两个节点之间的最短路径。等熟悉了数据模型，再玩高级功能。
性能调优是 Dgraph 的终极考验。我们遇到过最头疼的问题，是查询响应时间突然从毫秒级飙升到秒级。排查下来，是某个热门节点的边数太多，超过了默认的扇出限制。Dgraph 每个节点的出边默认是 100 条，超过这个数，查询就得多次跳转。解决方案是调大 参数，但也不能太大，免得内存撑不住。另一个优化点是使用 反向索引。比如“关注”关系，如果经常查“谁关注了我”，给这条边加反向索引，查询速度能提升一个数量级。
聊聊运维。Dgraph 的 Zero 节点是集群的大脑，挂了整个集群就废了。生产环境至少部署三个 Zero 节点，用 Raft 协议保证高可用。Alpha 节点可以水平扩展，数据会自动分片，但分片策略是自动的，不能手工控制。这有个坑：如果某个分片的数据量特别大，它所在的 Alpha 节点就会成为瓶颈。解决办法是，在数据建模时就考虑分片均衡，比如按地域或用户 ID 范围拆分实体。还有，Dgraph 的备份只能用 命令在线导出，速度很慢。我们后来写了脚本，定期用 bulk 命令离线快照，恢复起来快得多。
回头看这个项目，Dgraph 确实是个狠角色。它把图数据库的分布式、高可用、高性能都做到了极致，而且完全开源。但门槛摆在那里，文档不全，社区小众，出了问题只能自己啃源码。如果你团队有 Go 语言功底，愿意折腾，Dgraph 值得一试。如果你只想快速出活，Neo4j 可能更省心。不过话说回来，技术选型从来不是非黑即白。Dgraph 的 GraphQL 原生支持、分布式架构的原生设计，这些都是 Neo4j 无法替代的。至少对我来说，踩过的坑越多，越觉得这工具值得深入学习。下次再聊具体的查询优化技巧，比如如何用 Dgraph 做社交推荐，或者知识图谱的推理。
