文档模型为何比 RDBMS 更划算

合适的文档数据模型可映射应用程序使用的对象，并借助应用程序代码已定义的相同 结构来存储数据。

关系型数据库的发展

关系数据库管理系统 (RDBMS) 擅长处理随机问题。事实上，这也是研发 RDBMS 的初衷。 规范化数据模型代表数据的最小公分母，即与所有访问模式无关，也未曾随之优化过。

曾打造第一代 RDBMS 的 IBM System R 团队始终致力于帮助用户查询数据，规避编写复杂 的代码，也无需深入了解数据的物理存储方式。RDBMS 的创始人 Edgar Codd 在其著名的 文章“大型共享数据库的数据关系模型”中这样写道：

“未来的用户不需要了解数据在机器中的组织机制，就能够使用大型数据库。”

关系型数据库面临的挑战

对于在线分析处理 (OLAP) 工作负载的需求认证了这一论断。有时，用户需要提出新问题 或运行复杂的数据报告。在 RDBMS 出现之前，查询存储在原有分层管理系统 (HMS) 中的 数据需要编写代码，这不仅要求软件工程技术，还需投入大量的时间。而 RDBMS 不但 能够提升信息可用性的周转率，确保快速增长，还缩短了获得新解决方案的时间。

不过，数据灵活性的代价是高昂的。有批评者很快指出，RDBMS 的时间复杂性或查询标准化 数据模型所需时间远高于 HMS。因此，或许并不适用于占用 90% IT 基础设施的高速线上交 易处理 (OLAP) 工作负载。Codd 本人意识到了权衡的必要性。他在相关文章中也提及了标 准化的时间复杂性：

“如果命名集存在强冗余，并且直接反映在存储集中（或者引入了其他强冗余），那么一 般而言，会消耗额外的存储空间和更新时间，进而可能缩短某些查询的查询时间，降低中 央处理单元的工作负载。”

如果没有摩尔定律的存在，RDBMS 可能早已被否定，根本无法从概念进入雏形阶段。随着 处理器效率的提升，人们对于 RDBMS 的感知成本开始降低。从总拥有成本 (TCO) 的角度 来看，利用规范化数据运行 OLTP 工作负载最终变得可行；并且在 1980 年至 1985 年间 ，RDBMS 平台被誉为大多数新企业工作负载的首选解决方案。

这也说明，摩尔定律实际上是一个财务方程，而非物理定律。只要市场能够承受每两年翻 倍一次的晶体管密度成本，摩尔定律就依然有效。

不幸的是，对于 RDBMS 技术而言，这种情况在 2013 年左右发生了变化。当时，升级至 5 纳米制程对服务器 CPU 而言成本过高，成为几乎无法逾越的需求屏障。移动市场采用 5 纳米技术作为亏本产品，数年间，通过与移动设备相关的订阅服务来收回成本。

然而，服务器处理领域并不能通过订阅服务带来收益，导致近 10 年间，制造商一直无法 提升 5 纳米 CPU 的产量，每个核心服务器 CPU 的性能也始终没有新的突破。

去年二月，AMD 称由于服务器 CPU 成本过高，导致市场需求疲软，将无限期减少 5 纳米 晶圆库存。现实情况是，服务器 CPU 效率要实现数量级提升，需要一场跨世纪的技术变革 ，而这在短期内很难实现。

与此同时，存储的成本却在直线下降。RDBMS 解决方案采用的规范化数据模型需要用廉价 的 CPU 周期来打造高效的解决方案，而 NoSQL 解决方案依赖于高效的数据模型来降低执 行常规查询所需的 CPU 占用率。这通常就要对数据进行反规范化操作，本质上来说，就是 用 CPU 换存储。随着 CPU 的效率趋于平稳，存储成本持续下跌，NoSQL 解决方案成为了企业降本增效的手首选。

NoSQL数据库备受青睐

在近十年的时间里，RDBMS 与 NoSQL 之间的差距一直在拉大。包括 Amazon 在内的《财 富》前 10 强企业已经进行综合评估，并全面采用以 NoSQL 为首要开发策略的方式支持所 有关键任务服务。

客户在使用诸如 MongoDB Atlas 的 NoSQL 数据库之前，常见的阻力之一是开发人员已经掌 握 RDBMS 的使用方法，因此更倾向于“保持现状”。在我看来，最简单的方法是按照应 程序用实际使用的方式来存储数据。

合适的文档数据模型能够映射应用程序所使用的对象，借助应用程序代码中已定义的相同 数据结构来存储数据，其中利用到模拟数据实际处理方式的容器。这样避免了物理存储之 间的抽象层，也不会增加查询时间复杂度，并最终缩短 CPU 处理重要数据查询所需的时间 。 有人可能会觉得这类似于将数据结构硬编码到存储中，比如之前的 HMS 系统。 那么 ，RDBMS 支持的那些 OLAP 查询又当如何解释呢？

MongoDB 始终在投资打造 API，助力用户开展常见企业工作负载所需的特殊查询。近期新 增的 SQL-92 适配 API 意味着 Atlas 用户可通过连接 MongoDB Atlas 时的常用工具来运行企 业报告，这和 ODBC（开放数据库互连）中的任何其他 RDBMS 平台别无二致。

复杂的 SQL 查询成本高昂，高速运行更是意味着需要将大量资金投入到资本支出预算中。 而 NoSQL 数据库通过优化高速查询的数据模型成功地规避了这一问题，进而触及了问题的 关键所在。这种设计的深远影响在运行 OLAP 查询时得以显现，因为对非规范化数据执行 查询时，效率始终很低。

以往日常报表需要 5 秒，而现在需要 10 秒，这种事情实际上没人会在意，因为每天只需 要运行一次。同样地，需要运行特殊查询寻找答案的数据分析师或支持工程师也不会留意 到 10 毫秒和 100 毫秒之间的差别。事实上，OLAP 查询的性能从来都不是重点，人们只 需要获得答案。

MongoDB 采用文档数据模型和 Atlas 开发者数据平台，不仅能提供更好的 OLTP 性能，还 可支持绝大多数 OLAP 工作负载。

关于作者：Rick Houlihan 在 MongoDB 担任面向战略客户的开发者关系团队主管。他负责公司大客户的咨询工作，在行业最佳实践、技术转型、分布式系统实施、云迁移等方面提供指导。点击阅读 Rick Houlihan 的更多文章。