Excalidraw数据库选型分析：为何不用MongoDB？

Excalidraw 数据库选型分析：为何不用 MongoDB？

在构建现代协作式 Web 应用时，一个看似简单的技术决策——数据库选型——往往能深刻影响整个系统的性能、可维护性和扩展路径。以开源白板工具Excalidraw为例，它没有采用许多同类应用常见的 MongoDB，反而选择更轻量的存储方案，这一做法背后隐藏着对实时协作场景本质需求的精准把握。

表面上看，Excalidraw 的数据结构是典型的 JSON 文档集合：画布上的每个图形元素都包含位置、样式、ID 和版本信息，天然适合文档数据库。但深入其协同机制就会发现，这种“像 MongoDB”的表象极具误导性。真正决定存储架构的，不是数据格式，而是操作频率、一致性模型与系统部署目标。

协作编辑的核心：操作流而非状态快照

Excalidraw 的核心能力在于多人实时协作绘图。当用户拖动一个矩形或添加一条箭头时，这些动作并不会立刻生成完整的“当前状态”并全量保存，而是被转化为一个个细粒度的操作指令（operation），并通过 OT（Operational Transformation）或 CRDT 算法进行协调同步。

这意味着服务端的关键职责不是“存下最新画面”，而是：

• 按顺序接收来自不同客户端的操作；
• 保证所有参与者看到一致的操作序列；
• 将这些操作持久化为日志流，以便新加入者重放恢复状态；
• 在必要时支持撤销、历史回溯和冲突合并。

这类工作负载的本质是高并发、小体积、持续追加的日志写入，类似于消息队列或事件溯源系统中的 event log，而不是传统意义上的“记录更新”。

举个例子，一次简单的线条绘制可能产生几十次坐标微调，如果每次都将整个画布状态写入 MongoDB：

db.boards.updateOne( { id: "room-123" }, { $set: { elements: [...全部元素], updatedAt: Date.now() } } )

这不仅会造成严重的写放大（write amplification），还会因文档级锁引发竞争，甚至在网络波动时导致状态不一致。更重要的是，这种方式完全丢失了操作的历史轨迹，使得 OT/CRDT 失去基础支撑。

MongoDB 的优势在哪儿？又为何在这里失效？

MongoDB 的设计初衷是解决关系型数据库在敏捷开发中 Schema 变更困难的问题。它的主要优势包括：

• 动态 Schema：无需预定义字段，新增属性灵活；
• 嵌套文档支持：天然适合复杂对象结构；
• 强大的查询语言：支持嵌套查询、聚合、地理索引等；
• 成熟生态：驱动丰富，监控工具齐全。

但在 Excalidraw 的上下文中，这些特性几乎全部“英雄无用武之地”：

换句话说，你为了一个螺丝刀的功能买了一整套智能工具箱，结果每天只用来拧一颗螺丝。

更关键的是，MongoDB 的一些“默认行为”反而成了负担：

• 写入延迟偏高：即使使用w=1安全级别，单次写入通常也在几十到上百毫秒量级，难以满足每秒数百次操作的实时同步需求。
• 内存开销大：MongoDB 默认将整个文档加载进内存处理，对于频繁更新的大数组（如elements列表），缓存效率远低于专用结构。
• 部署运维成本高：需要独立进程、副本集配置、备份策略、监控告警——这对于希望一键部署的小团队或个人开发者来说，门槛过高。

那 Excalidraw 实际用了什么？

Excalidraw 并没有统一的“数据库”，而是根据部署模式动态选择最适合的存储策略，体现出极强的工程务实精神：

开发与测试环境：纯内存存储

最简单的情况就是什么都不存。多个客户端通过 WebSocket 直接连接 Node.js 服务端，状态保留在进程内存中。重启即清空，适合临时会议或本地调试。

优点显而易见：零依赖、极致低延迟、开发便捷。

生产部署常用方案

1. Firebase Realtime Database / Firestore
   支持双向实时同步，天然契合协作场景。客户端可以直接订阅数据变化，服务端只需做权限校验。Google 托管也省去了运维烦恼。

2. Redis + Streams
   使用 Redis 的 Stream 数据结构作为操作日志的持久化载体。支持高效的追加写入与消费者组读取，同时可通过 TTL 设置自动清理过期房间。

示例：
bash XADD board:abc123 * operation add elementId rect123 x 100 y 200

3. SQLite / LevelDB（嵌入式）
   对于自托管用户，SQLite 提供了 ACID 保障的同时仍保持轻量。配合 WAL 模式可实现高效追加写入，且无需独立数据库服务。

4. 文件即存储
   用户保存的.excalidraw文件本质上是一个 JSON 快照，可以离线编辑、邮件分享、Git 版本控制。这种“数据即文件”的理念极大提升了可移植性。

这些方案的共同点非常清晰：

• 轻量级：可嵌入应用进程，无需额外服务；
• 低延迟：写入路径短，响应迅速；
• append-only 友好：原生支持日志式写入；
• 易于部署：适合边缘节点、Docker 容器或 Serverless 架构。

技术背后的哲学：简洁优于通用

Excalidraw 的存储设计反映出一种鲜明的技术哲学：不要让基础设施成为体验的瓶颈。

它的目标不是成为一个“企业级协作平台”，而是让任何一个开发者都能快速搭建一个可用的白板服务。因此，在技术选型上始终坚持几个原则：

• 最小依赖：尽可能减少外部组件，提升可移植性；
• 客户端主导：渲染、撤销栈、布局计算均由前端完成，服务端仅负责中继与防篡改；
• 成本敏感：面向个人和小团队，降低部署与学习成本；
• 数据自主权：用户应能轻松导出、迁移和备份自己的内容。

这与 MongoDB 所代表的“集中式、服务化、功能完备”的数据库范式存在根本冲突。后者更适合用户管理系统、CMS 内容库这类需要复杂查询和长期运维的场景，而不适用于强调瞬时性、低延迟、去中心化同步的协作绘图工具。

AI 功能的引入是否改变了局面？

近年来，Excalidraw 集成了 AI 绘图能力，例如通过文本描述生成图表结构。有人可能会问：这是否带来了新的数据管理需求，比如向量索引或语义搜索？是否需要 MongoDB 来存储 prompt 历史或生成元数据？

答案依然是否定的。

AI 生成的内容最终仍然是标准的ExcalidrawElement对象，插入画布的方式与其他手动绘制元素无异。相关的 prompt 记录、生成参数等辅助信息，通常作为临时上下文保留在会话中，或随画布一起序列化为 JSON 存储。并没有出现需要全文检索、标签分类或向量化相似度匹配的场景。

即便未来要支持“基于草图搜索历史白板”，更合理的做法也是引入专用搜索引擎（如 Meilisearch）或向量数据库（如 Pinecone），而不是强行让 MongoDB 承担本不属于它的角色。

总结：选型的关键是理解访问模式

Excalidraw 没有使用 MongoDB，并非因为 MongoDB 不够强大，而是因为它太重了，而 Excalidraw 的需求恰恰要求足够轻。

真正的技术选型不应从“数据长什么样”出发，而应从以下几个问题开始：

• 数据是如何被写入的？是偶尔更新，还是高频追加？
• 读取模式是什么？是随机查询，还是顺序回放？
• 一致性要求多强？能否容忍短暂分裂？
• 部署环境如何？是否有专职 DBA？是否追求一键启动？

在 Excalidraw 的场景下：

• 写入是高频、小批量、有序追加；
• 读取主要是日志回放或完整状态拉取；
• 要求强顺序一致性，避免视图分裂；
• 部署期望尽可能简单，最好零配置。

这样的需求组合，显然更适合日志结构存储（log-structured store）或实时同步引擎，而非通用文档数据库。

这也给所有开发者提了个醒：不要被“JSON 数据”这个表象迷惑。当你面对的是操作流、事件流、状态变更序列时，也许真正需要的不是一个数据库，而是一个可靠的消息通道或状态机日志。

Excalidraw 的成功证明，有时候最强大的技术决策，就是克制地不做选择——尤其是不去选用那些看起来很美、实则冗余沉重的方案。