Dgraph 不是关系型数据库替代品，而是图模型优先的分布式存储；它无表、无外键、无 SQL JOIN，依赖谓词、UID 和 @reverse 模拟关联，适合深度关系场景如社交图谱、权限继承和推荐链路，但不适用于多表 JOIN 的 OLTP 业务。
Dgraph 不是关系型数据库的“替代品”，而是图模型优先的分布式存储方案；强行当 MySQL 替代用，大概率会卡在 schema 设计、事务语义和 JOIN 模拟上。
为什么不能直接替换 PostgreSQL/MySQL 的业务表结构
Dgraph 没有表、没有外键约束、没有 SQL JOIN 语法。它用谓词（predicate）表达属性或边，用 UID 做节点标识，靠逆向边（@reverse）或级联查询模拟关联。比如你原来有 users 表和 orders 表，外键 user_id，在 Dgraph 里得建两个谓词：user.name 和 order.for_user，后者类型必须是 uid，且要显式加 @reverse 才能从 user 查到 order。
常见踩坑点：
- 漏写
@reverse导致反向查不到数据，调试时只看到空数组 - 把字符串 ID（如
"123"）当成 UID 写入，Dgraph 会当作普通字符串存，后续无法做图遍历 - 试图用
eq匹配 uid 字段——必须用uid函数，比如uid(0x12345)，不能写order.for_user == "0x12345" - schema 更新后没执行
dgraph alter，新字段不生效，但无报错提示
Go 微服务里怎么安全接入 Dgraph
别用裸 HTTP 调 GraphQL endpoint，优先走 gRPC + dgo 客户端。它内置连接池、自动重连、上下文取消支持，比手搓 http.Client 稳得多。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
关键实操建议：
- 初始化 client 时传入
grpc.WithBlock()和超时控制，避免启动卡死：dgo.DialContext(ctx, "localhost:9080", grpc.WithBlock(), grpc.WithTimeout(5*time.Second)) - 所有写操作必须包裹在
txn.Mutate()+txn.Commit()中，Dgraph 不支持单条 auto-commit 插入 - 读操作推荐用
txn.QueryWithVars()，变量用 map[string]string 传，避免字符串拼接注入风险 - 批量插入超过 1000 条？拆成多个
Mutate请求，单次请求体别超 10MB，否则 gRPC 流被断开
哪些微服务场景适合迁 Dgraph
不是所有“需要关联查询”的服务都适合。真正受益的是那些天然带深度关系、路径遍历、推荐链路的模块：
- 用户关系图谱：关注/被关注、好友的好友、共同群组——用
expand(_all_)或递归查询比 JOIN 快一个数量级 - 权限继承系统：角色→权限组→具体权限→资源范围，树状继承用 Dgraph 的
loop查询比 RBAC 表 join 清晰 - 商品推荐链路：用户→浏览→加购→下单→评价→复购，边带时间戳和权重，原生支持按边属性过滤
反例：订单主表+明细表+物流表+支付表四层 JOIN 的 OLTP 核心交易服务——Dgraph 会逼你把所有字段 flat 化进一个谓词，丧失范式，且无法利用索引加速范围扫描。
生产部署必须绕开的坑
Docker Compose 启动的单节点 dgraph/standalone 只能用于验证 schema 和跑 demo。真实微服务必须用集群模式，否则：
- Alpha 节点挂了，整个写入不可用——Zero 节点不存数据，只管调度
- 没配置
--lru_mb，默认 512MB 缓存，高并发下频繁 GC，latency 毛刺明显 - Ratel UI 默认暴露在 8000 端口，千万别在生产环境开着，它没鉴权机制
- 备份用
dgraph backup生成的是二进制快照，恢复必须停机，不能热备
最易被忽略的一点：Dgraph 的 ACID 是 per-transaction 的，但跨 Alpha 节点的事务性能随分片数线性下降。如果你的谓词分散在 5 个 Alpha 上，一次事务平均要协调 5 次网络 round-trip——这比单机 PostgreSQL 的本地事务慢得多，别指望它扛住每秒几千笔金融级交易。
