CouchDB vs FaunaDB：多主复制与全局强一致的两条路线

**重要提示：FaunaDB 官方托管服务已于 2025 年 5 月 30 日关停。**这篇对比的价值在于两条截然不同的分布式数据库设计路线——CouchDB 的"各自为政、事后和解" vs FaunaDB 的"全局协调、绝不冲突"——以及 Fauna 用户该往哪里走。

两个库的设计基因

CouchDB：Apache 开源文档数据库，JSON 文档 + _rev 字段自动版本跟踪。更新必须带上当前版本号——乐观并发控制，改别人改过的文档会得到冲突错误而不是悄悄覆盖。多主架构：每个实例独立接受写入，两地点同时改同一文档也允许——不阻止冲突，而是保留两个版本、标记冲突，由应用决定谁赢或实现自定义合并。查询用 JavaScript 写 MapReduce 视图，索引增量构建。

FaunaDB（已关停）：文档-关系混合模型，全局分布式事务（Calvin 协议），默认跨地域强一致，内建时态查询，Serverless 全托管。

复制：异步多主 vs 全局协调

// CouchDB：任意两节点间双向持续同步
const sfDB = new PouchDB('http://sf.example.com:5984/inventory');
const londonDB = new PouchDB('http://london.example.com:5984/inventory');
sfDB.replicate.to(londonDB, { live: true, retry: true });
londonDB.replicate.to(sfDB, { live: true, retry: true });
// 两地各自本地写入（本地延迟），变更异步传播

CouchDB 的哲学：断网也能干活。每个数据中心独立运行，用户写最近的节点，连通后复制恢复并检测冲突。典型拓扑：美西、美东、欧洲各一个节点，全部可写，双向互同步。

FaunaDB 相反：一个全球端点，写入全局协调——没有冲突的可能，代价是写入延迟包含跨地域共识的开销，且完全依赖托管服务可用。

一致性：可用性优先 vs 正确性优先

这是 CAP 定理的经典对位：

• CouchDB 选 AP：网络分区时各分区照常服务，一致性靠事后冲突解决追平。冲突是常态，应用必须处理；
• FaunaDB 选 CP：宁可协调等待也不产生分歧状态，应用永远读到一致视图，代价是延迟和对服务商的绝对依赖。

Fauna 的关停给 CP 托管路线上了沉重一课：技术再优雅，服务商消失，你的数据架构就得整体搬家。

冲突处理与事务范围

• CouchDB：冲突保留多版本由应用裁决；事务边界=单文档；
• FaunaDB：无冲突概念；事务跨文档跨集合且为默认。

查询能力

• CouchDB：MapReduce 物化视图，访问时才更新索引——预定义查询快，即席查询弱；
• FaunaDB：FQL 函数式查询语言表达力强，支持即席查询与事务混合。

成本模型

• CouchDB 自建：3 台服务器冗余 + 存储 + 带宽 ≈ 每月 230 美元起步的固定成本，随基础设施线性增长，成本可预测；
• FaunaDB：按请求/存储用量计费，零起步友好，规模化后账单不确定。

Fauna 用户往哪迁

CouchDB 今天还值得选吗

值得——如果你的场景命中它的甜蜜点：离线优先应用（移动端 + PouchDB 断网续写）、多地域协作编辑、边缘节点自治。它的模型久经考验、完全开源、无锁定风险。但要接受：即席分析能力弱、冲突处理逻辑要自己写、集群工具链不如主流库丰富。

观测云对照

多主架构的可观测性重点是复制健康：各节点间复制延迟、冲突率、同步失败次数。观测云 DataKit 采集 CouchDB 等数据库指标，监控器对复制中断、冲突激增告警；分布式部署下用统一仪表板对比各地域节点的写入延迟与可用率。 1 2

常见问题（FAQ）

Q：CouchDB 的冲突解决怎么做才不失控？
三个纪律：文档设计尽量"单人所有"减少冲突面；合并逻辑写成确定性函数（如取最大时间戳）；监控冲突率——冲突率飙升说明数据建模或写入路径有问题。

Q：CouchDB 和 PouchDB 什么关系？
PouchDB 是跑在浏览器/移动端的 CouchDB 协议兼容库，二者通过复制协议无缝同步，是实现离线优先架构的标准组合。

Q：Fauna 关停事件给选型的最大启示？
评估托管数据库时把"退出成本"当正式指标：数据能否完整导出、协议是否开放、有无自建开源退路。技术评估表之外，供应商的健康度也要尽调。

参考资料

• 观测云集成功能
• 观测云监控器与告警