文档模型为何比 RDBMS 更划算?

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
简介: 合适的文档数据模型可映射应用程序使用的对象,并借助应用程序代码已定义的相同结构来存储数据。

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


合适的文档数据模型可映射应用程序使用的对象,并借助应用程序代码已定义的相同

结构来存储数据。

关系型数据库的发展

关系数据库管理系统 (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 工作负载。

立即注册 阿里云版MongoDB进行免费试用。

扫码加入钉群,与MongoDB专家一对一沟通,了解更多阿里云MongoDB产品与方案,市场活动及线上培训等内容。

钉钉入群二维码_Fotor.png

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
12月前
|
SQL JavaScript
深入浅出DAX:购买推荐及产品ABC分类分析
深入浅出DAX:购买推荐及产品ABC分类分析 DAX运算求值的三步骤。首先是检测筛选,然后将筛选功能应用于基础表格,最后计算结果。DAX中的筛选器函数是复杂且功能强大的函数。例如筛选函数可用于操作数据上下文来创建动态计算。
106 4
|
数据库
LeetCode(数据库)- 每个产品在不同商店的价格
LeetCode(数据库)- 每个产品在不同商店的价格
105 0
|
数据库
LeetCode(数据库)- 每家商店的产品价格
LeetCode(数据库)- 每家商店的产品价格
106 0
|
SQL 存储 监控
【内含干货PPT下载】DTCC 2020 | 阿里云赵殿奎:PolarDB的Oracle平滑迁移之路
Oracle兼容性是业务客户从Oracle生态迁移到PolarDB生态的第一步也是至关重要的一步,PolarDB通过不断沉淀支持大量实际业务的真实Oracle兼容性功能,确保客户业务可以真正做到平滑迁移。同时PolarDB带给Oracle生态客户的不仅仅是上的来的问题,PolarDB在成本、性能、可用性、扩展性等云能力方面也给用户带来更高的业务价值。在DTCC 2020大会分布式数据库实践专场上,阿里巴巴高级数据库专家赵殿奎为大家介绍阿里巴巴电PolarDB的Oracle平滑迁移之路。
3612 0
【内含干货PPT下载】DTCC 2020 | 阿里云赵殿奎:PolarDB的Oracle平滑迁移之路
|
Oracle 关系型数据库 索引
ORACLE常见问题一千问(提供下载)(不怕学不成、就怕心不诚!)
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/chinahuyong/article/details/6543516 ORACLE常见问题一千问(提供下载) (不怕学不成、就怕心不诚!) ——通过知识共享树立个人品牌。
1337 1
下一篇
无影云桌面