MongoDB 杀手来了？新数据库太狠

各位老铁，今天咱们不聊 996，也不吐槽产品经理，咱来点硬核的——数据库。

是的，你没看错，就是那个藏在后端深处、默默扛下所有请求压力、背锅时永远第一个被拉出来祭天的 数据库。

如果你用过 MongoDB，那你一定经历过这些名场面：

• 数据量一大，查询开始卡成 PPT；

• 想扩容？不好意思，得先停机迁移数据，半夜三点上线改配置；

• 写入高峰一到，副本集直接罢工：“老子不干了！”

• 成本账单一出，财务小姐姐脸都绿了：“这云服务费怎么比工资还高？”

别急，这些问题不是你技术不行，而是传统架构的“先天不足”。但今天我要告诉你：有一个叫 eloqdoc 的新家伙，正悄悄颠覆这一切。

它长得像 MongoDB，说话像 MongoDB，API 兼容得连 driver 都认不出它是“李鬼”，但它内里却是个彻头彻尾的“六边形战士”——高性能、高弹性、低成本、分布式原生、事务强一致…

这不是吹牛，这是实打实的技术降维打击。

来吧，搬好小板凳，泡上枸杞茶，咱们一起扒一扒这个神秘项目：eloqdoc —— 一个披着 MongoDB 外衣的“未来数据库”。

---

它是谁家的孩子？从 GitHub 开始挖根

先来看一眼它的“身份证”：

• 项目名：eloqdoc

• 作者组织：eloqdata

• 语言：C++

• 官网：https://www.eloqdata.com[1]

而且注意，它是用 C++ 写的！不是 Python 小玩具，也不是 Go 快速原型，是那种能怼进操作系统内核、榨干 CPU 缓存的真·系统级语言。

说明什么？说明这不是某个大学生的课程设计，而是一群老炮儿工程师憋的大招。

再看 README 里的关键词：

“A MongoDB API compatible, high-performance, elastic, distributed document database.”

翻译一下就是：
我长得像 MongoDB，但我比它快、比它弹、比它便宜，还能跑在云上自动伸缩。

口气不小啊兄弟。

那它是吹牛，还是真有两把刷子？咱们一层层剥开看。

---

架构革命：把“对象存储”当硬盘使？

我们先问一个问题：为什么传统的 MongoDB 在云上这么贵又这么难扩？

答案很简单：因为它本质上还是“本地磁盘思维”的产物。

MongoDB 默认靠副本集（Replica Set）保命。比如三个节点，主写从读，数据同步靠 oplog。一旦主挂了，自动选个从变主。听着挺稳？

但问题来了：

• 每一份数据要复制三份 → 存储成本 ×3

• 每个节点都要有完整的内存和 CPU 来处理全量数据 → 计算资源 ×3

• 扩容时要搬数据 → 慢、容易出错、还得停机或限流

说白了，这就是典型的“为可靠性牺牲效率”的老派做法。

而 eloqdoc 干了一件非常反直觉的事：它把云上的对象存储（Object Storage），比如 AWS S3 或阿里云 OSS，当作真正的持久化层！

什么意思？

想象一下，你现在开了一家快递中转站。传统做法是：

每个分拣员（数据库节点）手里都有一份完整订单清单（数据副本），每天互相打电话对账（replication），生怕谁丢了单子。

而 eloqdoc 的做法是：

所有订单统一存在总部云端档案库（S3），每个分拣员只拿一块小白板记最近的几十单（NVMe 缓存）。谁要查历史订单？去总部调档就行。谁要新增订单？先写日志，再异步归档。

这样一来：

• 不怕分拣员离职（节点宕机）—— 档案都在总部；

• 新人上岗极快（弹性扩容）—— 只需接入系统，无需搬运历史数据；

• 总部永久保存，跨可用区冗余，安全性拉满；

• 小白板飞快，热点数据秒响应。

这就是 eloqdoc 提出的 Tiered Storage Architecture（分层存储架构）：

+---------------------+
|     Application     |
+----------+----------+
           |
           v
+----------+----------+    +------------------+
|   Frontend (MongoDB   <-->   TxService       |
|      Protocol)        |    | (Transaction     |
+----------+----------+    |     Engine)       |
           |               +--------+---------+
           v                        |
   +-------+--------+               v
   |   LogService    |    +--------+---------+
   | (WAL, Redo Log)  <----+ Storage Service  |
   +-------+--------+    | (Checkpoint +     |
           |             |  Object Storage)   |
           v             +--------+---------+
    +------+-------+               |
    | Local NVMe    <-------------+
    |   (Cache)     |
    +---------------+

看到没？整个系统被拆成了四个独立模块：

1. Frontend + TxService：负责解析 MongoDB 协议、执行事务逻辑；

2. LogService：专管写前日志（WAL），保证崩溃不丢数据；

3. Storage Service：管理检查点和冷数据，直接对接 S3 类对象存储；

4. Local NVMe：仅作为热数据缓存，断电即丢也没关系。

这种“存算分离 + 日志解耦”的设计，在数据库圈子里其实不算新鲜事——Google Spanner、AWS Aurora 都玩得很溜。

但！能把这套思想套到 MongoDB 身上，并且做到 API 完全兼容的，eloqdoc 是第一个。

---

MongoDB 兼容？真的不用改代码？

这时候肯定有人拍桌子了：“吹这么多，你能兼容 MongoDB 我信，但你说 driver 不用换？骗鬼呢！”

别急，我们来看官方怎么说：

✅ Seamless integration with MongoDB clients, drivers, and tools.

也就是说，只要你现在的项目是这么连 MongoDB 的：

from pymongo import MongoClient

client = MongoClient("mongodb://localhost:27017")
db = client["myapp"]
collection = db["users"]

# 插入一条数据
collection.insert_one({"name": "张三", "age": 28})

那你只需要把连接地址换成 eloqdoc 的 endpoint：

client = MongoClient("mongodb://eloqdoc-cluster:27017")  # 只改这里！

剩下的代码一行都不用动！

为啥能做到这一点？

因为 eloqdoc 实现了 完整的 MongoDB Wire Protocol（通信协议），包括：

• OP_QUERY / OP_GETMORE 查询协议

• OP_INSERT / OP_UPDATE / OP_DELETE 写操作

• 支持 BSON 格式传输

• 兼容常见的命令如 find, aggregate, createIndex, distinct 等

• 甚至支持部分聚合管道（aggregation pipeline）

换句话说，它对外表现得就像一台标准的 mongod 进程，但实际上背后跑的是完全不同的引擎。

这就好比你去海底捞吃饭，服务员穿着一样的制服，端上来一样的麻酱碟，甚至连甩面绝活都一模一样，但厨房其实是预制菜中央工厂 + 机器人炒菜系统。

顾客毫无察觉，体验反而更好了。

---

性能对比：eloqdoc 真的吊打 Atlas？

光说不练假把式，咱们来看看官方放出的 benchmark 数据。

测试环境统一使用 AWS i4i.4xlarge 实例（16 核 CPU、128GB 内存、本地 NVMe），对比对象是 MongoDB Atlas（也就是 MongoDB 官方托管版）。

场景一：全内存命中（Hot Data）

也就是你的工作集完全装得下内存，属于“理想状态”。

混合读写（1:1）

 

EloqDoc vs Atlas Mixed Workload

结果：eloqdoc 吞吐高出约 60%，而且随着并发上升，Atlas 开始抖动，eloqdoc 依然平稳。

原因也很简单：
Atlas 基于 EBS 网络盘，即使开了 Provisioned IOPS，延迟也远高于本地 NVMe；而 eloqdoc 的缓存全走本地 SSD，命中率接近 100%，自然更快。

纯读场景

 

Read-only Benchmark

结果差不多：峰值吞吐提升 60%+，延迟更低更稳定。

结论：在热点数据场景下，eloqdoc 凭借本地 NVMe 缓存优势，完胜基于网络存储的传统方案。

---

场景二：缓存命中率低（Cold Data）

这才是真实世界的常态——数据总量远超内存，经常需要从磁盘加载。

这时 Atlas 使用的是 EBS 卷，受限于网络带宽和 IOPS 配额；而 eloqdoc 则通过本地 NVMe 作为 write-back cache 层，配合对象存储做最终落盘。

结果如何？

官方描述很直接：

当 workload 需要频繁访问磁盘时，Atlas 的 EBS 后端迅速达到 IO 瓶颈，出现明显性能下降和尾延迟飙升；而 eloqdoc 仍能维持数十万 IOPS 的稳定输出。

这意味着什么？

举个例子：

你是一个内容平台，每天新增百万篇文章，用户偶尔会翻几个月前的老帖。这类“长尾访问”对传统数据库简直是噩梦——要么全放内存浪费钱，要么放硬盘慢得像蜗牛。

而 eloqdoc 的分层架构天生适合这种场景：

• 新文章 → 存 NVMe 缓存 → 秒级响应

• 老文章 → 归档到 S3 → 成本降到几分钱/GB

• 用户访问老文 → 自动加载进缓存 → 下次就快了

既省钱，又不牺牲体验。

---

弹性扩展：100 倍速扩容是怎么做到的？

接下来是最震撼的一点：elastic scalability（弹性可扩展性）。

传统数据库扩容有多痛苦？

“老板，我们数据快满了。”
“那就加机器呗。”
“可是要重新 shard，得停服两小时……”

而在 eloqdoc 这里，扩容变得像呼吸一样自然。

三大独立扩展维度：

维度	是否可独立扩展	说明
Compute（计算）	✅ 是	增加更多 frontend 节点即可，无需移动数据
Storage（存储）	✅ 是	对象存储天然无限扩展，S3 管够
Redo Log（日志）	✅ 是	可单独横向扩展 LogService 提升写吞吐

重点来了：因为数据不再绑定在本地磁盘上，所以增加计算节点时，根本不需要搬数据！

你想扩十倍？只要 Kubernetes 一键部署十个新 pod，它们启动后自动连接共享存储层，立刻加入集群提供服务。

官方说：“scaling compute is 100x faster than traditional databases”。

这不是夸张。传统方式搬 1TB 数据可能要几个小时，而 eloqdoc 新节点上线只需几秒钟——因为它压根不用搬。

这就带来了两个巨大好处：

1. 突发流量应对自如：双十一秒杀来了？立刻扩二十个节点顶上；

2. 资源利用率最大化：平时五台机器够用，高峰期五十台，用完立马缩容，只为实际使用的买单。

这才是真正的“云原生数据库”。

---

分布式事务：ACID 不只是口号

很多人以为文档数据库就等于“弱一致性”，其实不然。

eloqdoc 明确宣称支持 ACID 分布式事务，而且特别强调“fast distributed transactions”。

要知道，在分布式环境下实现 ACID 本来就很慢，尤其是跨节点写入时，要走两阶段提交（2PC），延迟高、容错差。

但 eloqdoc 用了啥黑科技？

根据其底层依赖的 Data Substrate[2] 技术文档推测，它很可能采用了类似 Paxos 或 Raft 的共识算法 + 时间戳排序（Timestamp Ordering） 的混合机制。

具体流程大概是这样的：

1. 客户端发起一个多文档事务；

2. TxService 分配全局单调递增的时间戳；

3. 所有参与节点按时间戳顺序执行操作，冲突则 abort；

4. 提交阶段通过 LogService 持久化 redo log；

5. Storage Service 异步 checkpoint 到对象存储。

这套机制避免了传统 2PC 的阻塞问题，同时保证了串行化隔离级别（Serializable Isolation）。

举个实际例子：

session.startTransaction();
db.accounts.updateOne({name: "Alice"}, {$inc: {balance: -100}});
db.accounts.updateOne({name: "Bob"},   {$inc: {balance: +100}});
session.commitTransaction();

这段代码在 eloqdoc 上运行，要么全部成功，要么全部回滚，不会出现“Alice 扣钱了，Bob 没收到”的情况。

这对于金融类、订单类应用至关重要。

---

无分片设计：告别 mongos 和 config server

说到 MongoDB 的痛，除了性能，还有一个就是 sharding 架构太复杂。

你要搞清楚这几个玩意儿：

• mongos：路由代理，负责把请求转发给正确的 shard；

• config server：存储元数据，记录哪个 chunk 在哪台机器；

• shard：真正存数据的副本集；

• balancer：后台进程，负责均衡 chunks。

稍微配置错一步，轻则查询变慢，重则数据丢失。

而 eloqdoc 直接说：我不需要 sharding coordinator。

因为它采用的是 native distributed hashing + consistent lookup table 的方式，所有节点都知道数据分布规则，可以直接定位目标节点。

相当于原来你要找某个文件得先问秘书（mongos），秘书再去查目录（config server），现在每个人手头都有完整地图，直接上门拜访就行。

好处显而易见：

• 减少网络跳数 → 延迟更低

• 去除单点故障 → 更可靠

• 运维复杂度骤降 → DBA 少掉一半头发

---

成本对比：一年能省一辆特斯拉？

让我们来做道数学题。

假设你有一个中等规模的应用，每天产生 1TB 数据，保留一年就是 365TB。

如果用 MongoDB Atlas 的 M40 层级（约 $200/月），三年下来大概要花：

200 × 12 × 3 = $7,200 ≈ 5.1 万人民币

而这还只是计算费用，不包括备份、监控、额外存储等附加服务。

而 eloqdoc 的成本结构完全不同：

• 计算层：只部署少量 frontend 节点（比如 3~5 个 i4i.xlarge），按需扩展；

• 存储层：全部扔 S3 Glacier Deep Archive，单价低至 $0.00099/GB/月；

• 日志层：可以用高速 SSD 单独部署，按流量计费；

粗略估算：

• 存储 365TB 在 S3 Deep Archive：
  365 * 1024 ≈ 373,760 GB
  373,760 × 0.00099 ≈ $370/年 ≈ 2,600 元/年

• 计算层（5 台中配实例）：
  每台约 月9,000/年

等等，这不是更贵了吗？

别忘了：eloqdoc 支持自动缩容！

白天高峰期跑 5 台，晚上低峰期缩到 1 台，平均利用率只有 40%？

那实际支出就是：

5 × 0.4 = 2 台等效
2 × 150 × 12 = $3,600 ≈ 2.5 万元/年

再加上存储不到 3 千，总成本约 2.8 万元/年。

而 Atlas 固定套餐基本无法缩容，三年就得准备 15 万元以上。

算下来，三年至少省下 12 万，够买一辆 Model Y 了。

---

开源现状与社区生态

目前 eloqdoc 还处于早期阶段（v0.x），功能虽已可用，但尚未进入生产推荐列表。

但从代码结构来看，工程规范非常严谨：

/src            # C++ 核心代码
/tests          # 单元测试 & 集成测试
/docs           # 文档齐全
/scripts        # 部署脚本
/concourse      # CI/CD 流水线配置
/scons          # 构建系统（替代 Makefile）

特别是用了 SCons 构建工具，而不是简单的 CMake，说明团队重视跨平台构建一致性。

License 是 AGPL-3.0，意味着：

• 你可以免费使用、修改、部署；

• 但如果你在产品中集成并对外提供服务，必须开源你的改动；

• 商业公司可以购买企业授权规避限制。

这也是很多新兴数据库（如 CockroachDB、TiDB）走的路线：开源引流，商业变现。

他们还提供了托管版本 EloqCloud[3]，显然是想走“开源核心 + 云服务盈利”的路子。

---

适用场景：谁该考虑切换？

说了这么多优点，那是不是所有人都应该立刻迁移到 eloqdoc？

当然不是。

任何技术都有适用边界。以下是几个典型适用场景：

✅ 推荐使用：

1. Web 应用后端：CMS、社交平台、UGC 内容库；

2. 日志与事件存储：高写入频率，偶尔查询；

3. 微服务架构下的共享数据层：需要 JSON 文档模型 + 强一致性事务；

4. 初创公司快速搭建 MVP：不想被 vendor lock-in 绑架，追求极致性价比；

5. 已有 MongoDB 架构但遇到瓶颈者：扩容难、成本高、性能上不去。

❌ 暂时不建议：

1. 极度成熟稳定的 legacy 系统：改不动，也不敢动；

2. 对 SLA 要求极高且不允许试错的企业：毕竟项目尚新，缺少大规模验证；

3. 纯 OLAP 场景：虽然支持聚合，但不如专门的数据仓库（如 ClickHouse）高效；

4. 预算充足、图省事的大厂：宁愿花钱买服务，也不想自己运维。

---

如何体验？动手试试看！

想亲自感受一下 eloqdoc 的威力？这里有几种方式：

方式一：本地尝鲜（Docker）

虽然官方还没发布 Docker 镜像，但从构建脚本看，支持容器化部署：

git clone https://github.com/eloqdata/eloqdoc.git
cd eloqdoc
scons   # 编译核心组件

后续预计会推出 Helm Chart 和 Operator，用于 Kubernetes 部署。

方式二：上云体验（EloqCloud）

访问 https://cloud.eloqdata.com[4]，注册账号即可获得免费额度，一键创建集群，连接方式与 MongoDB 完全一致。

适合想快速验证兼容性和性能的同学。

方式三：贡献代码

项目欢迎 PR，尤其是：

• 更多语言的 driver 测试（Node.js、Java、Python 等）

• 监控插件（Prometheus Exporter）

• 备份恢复工具

• UI 管理界面

GitHub 地址：https://github.com/eloqdata/eloqdoc[5]

---

未来展望：会不会成为下一个 MongoDB？

这个问题很难回答，但我们可以说几点趋势：

1. 云原生数据库是大势所趋：存算分离、弹性伸缩、按需付费，已是主流方向；

2. MongoDB 自身也在转型：Atlas 已经拥抱云，但底层仍是传统架构，难以彻底革新；

3. 开发者越来越反感 vendor lock-in：谁都不想被一家公司绑架；

4. 中国市场对自主可控数据库需求强烈：类似 PingCAP、OceanBase 的成功证明这条路可行。

eloqdoc 正好踩在这些趋势的交汇点上。

如果它能在未来两年内：

• 完成 v1.0 发布

• 积累足够多的真实案例

• 建立活跃的中文社区

• 提供完善的文档和支持

那么，它完全有可能成长为新一代文档数据库的领导者。

---

结语：技术的进步，从来都是“站在巨人肩膀上踹一脚”

最后我想说，eloqdoc 并不是一个凭空蹦出来的天才发明。

它的每一块拼图，都能在历史上找到影子：

• 存算分离 ← Google Spanner

• 日志即数据库 ← AWS Aurora

• 分层存储 ← Facebook Cold Storage

• 分布式事务 ← Calvin、FaunaDB

• MongoDB 兼容 ← DynamoDB API 兼容模式

但它聪明的地方在于：把这些先进的理念打包起来，穿上 MongoDB 的外衣，让开发者零门槛接入。

---

📌 参考资料 & 延伸阅读：

• GitHub 项目主页：https://github.com/eloqdata/eloqdoc[6]

• 官方博客（Data Substrate 解析）：https://www.eloqdata.com/blog[7]

• EloqCloud 托管服务：https://cloud.eloqdata.com[8]

• MongoDB vs Aurora 架构对比：https://aws.amazon.com/cn/blogs/database/amazon-documentdb-mongodb-compatibility/[9]

• 分布式事务经典论文：Highly Available Transactions: Virtues and Limitations (Michael Stonebraker et al.)

参考资料

[1] https://www.eloqdata.com: https://www.eloqdata.com

[2] Data Substrate: https://www.eloqdata.com/blog/2024/08/11/data-substrate

[3] EloqCloud: https://cloud.eloqdata.com

[4] https://cloud.eloqdata.com: https://cloud.eloqdata.com

[5] https://github.com/eloqdata/eloqdoc: https://github.com/eloqdata/eloqdoc

[6] https://github.com/eloqdata/eloqdoc: https://github.com/eloqdata/eloqdoc

[7] https://www.eloqdata.com/blog: https://www.eloqdata.com/blog

[8] https://cloud.eloqdata.com: https://cloud.eloqdata.com

[9] https://aws.amazon.com/cn/blogs/database/amazon-documentdb-mongodb-compatibility/: https://aws.amazon.com/cn/blogs/database/amazon-documentdb-mongodb-compatibility/