人脸向量库选型分析
A/B 双中心都有 ES 和 PGSQL；PGSQL 已做双中心同步，ES 需要项目组自己保证同步；后续 PGSQL 计划替换为 GaussDB。
结论
建议用 PGSQL/GaussDB 做权威向量库，ES 只作为可选检索加速层。
原因很直接：人脸库最怕 A/B 中心数据不一致。PGSQL 已有双中心同步能力，比 ES 自建同步更稳、更简单。
方案对比
PGSQL / GaussDB 推荐主库
- 优点：双中心同步已有基础，一致性更好。
- 优点：向量、人员信息、状态可事务一致。
- 优点：删除、禁用、变更更容易审计和回放。
- 缺点：大规模向量检索需要压测。
- 缺点：GaussDB 向量能力和索引兼容性必须提前确认。
ES Vector 适合加速
- 优点：向量检索和过滤能力强，高并发更有优势。
- 优点：横向扩展和索引调优方便。
- 缺点：当前没有双中心同步，需要项目组自建。
- 缺点：与数据库天然最终一致，删除和更新容易漂移。
- 缺点：需要 CDC、补偿、校验、重建索引机制。
关键判断
| 维度 | PGSQL/GaussDB | ES |
|---|---|---|
| 双中心一致性 | 好，已有同步基础 | 弱，需要自建同步 |
| 事务一致性 | 好 | 一般 |
| 检索性能 | 需看规模和索引 | 更强 |
| 运维复杂度 | 较低 | 较高 |
| 后续迁移 | 需验证 GaussDB 向量能力 | 不受换库直接影响，但同步仍复杂 |
推荐架构
- PGSQL/GaussDB 存人员信息、图片 ID、向量、状态、版本号、删除标记。
- A/B 中心依赖数据库同步，保证权威数据一致。
- 中小规模直接用数据库向量索引检索。
- 大规模或高 QPS 时，再把 ES 作为派生索引加速。
关键风险：换 GaussDB 前必须确认是否支持向量类型、距离函数、HNSW/IVFFlat 等索引能力。
选择口径
- 百万级以内、一致性优先：选 PGSQL/GaussDB。
- 千万级以上、高 QPS：PGSQL/GaussDB 做主库，ES 做加速索引。
- GaussDB 向量能力不足：数据库做事实源，检索层改用 ES 或专门向量库。