“我会坚持下去”——这是数据库最常见的使用方法吗？

在我的职业生涯中，我接触过 MySQL、Postgres、Oracle、Microsoft SQL Server、DBase、Access、SQLite、DB2、MariaDB、AWS RDS、Azure SQL、Google Cloud SQL 以及几乎所有我能接触到的 RDBMS。喜欢 RDBMS 就不可能不喜欢 SQL，而SQL 本身就是一个无底的兔子洞（rabbit hole，出自小说《爱丽丝漫游奇境记》，意指神秘世界）。SQL 并不完全相同，MySQL 有自己的行话，微软的 T-SQL 和举世闻名的Oracle的 PL/SQL 互不兼容。

请相信，我见过所有的关系型数据库——金融、交通、酒店、社交媒体、视频流媒体服务及其他众多领域。无论在哪里，你都可能发现关系型数据库。这个世界的运行似乎完全靠关系型数据库支撑，这些数据库让Oracle、IBM 和微软赚得盆满钵满。如果你需要的是大型数据库，你会选择Oracle、IBM 或微软；尤其在面临金融领域的需求时，你也有可能选择 SAP。

Gartner 通过 Adam Ronthal (@aronthal)发布于Twitter

据说最早的 RDBMS 出现于 20 世纪 70 年代初，当时结构化英语查询语言（SEQUEL，后缩写为 SQL）被发明。Oracle 公司于 1979 年发布了其第一个数据库，而在此之前三年，霍尼韦尔（Honeywell）公司于 1976 年发布了Multics Relational Data Store——据说这是世界上第一个关系型数据库。再过几年，我们将回顾关系型数据库管理系统（RDBMS）50 年的发展历程。

毫无疑问，RDBMS 成为了现代社会和经济的支柱。可以肯定地说，除非你住在山洞里，否则每个人都至少拥有一个关系型数据库，并至少处于一个关系型数据库中。

你一生中的全部信息都可能存储在大型关系型数据库系统中——这些系统很可能来自微软、IBM、SAP 或 Oracle。想去海边旅行吗？你的机票、预订等所有信息都在关系型数据库中。无论向任何组织提供任何数据，这些数据最终都很可能会进入关系型数据库。

然而，大多数数据库都以类似于 PHP、MySQL、Microsoft Access 或VBA（Visual Basic for Applications）的形式存在。这些都不是复杂的数据库管理系统，而是使用 RDBMS 存储数据的小型应用程序。

对使用数据库的许多人来说，RDBMS 一开始就是一种巨大的负担，只是关系型数据库的流行促使开发人员选择关系型数据库。大学、中学及编程课程都教授 SQL 和关系型数据库，大多数开发人员可能倾向于使用关系型数据库。

你可能也会认同以下观点：大多数软件开发人员都不是优秀的数据库开发人员。这种情况有时是因为他们不在乎（提升数据库技术），但主要原因是教人如何正确构建关系型数据库的学习资源很少。大多数学校、书籍和课程都侧重于 SQL、规范化和事务处理，这一特点在关系型数据库方面尤为明显。

普通开发人员听到这句话一定会大吃一惊。对于经验丰富的数据库工程师来说，将整个关系型数据库结构隐藏在视图和存储过程之后是常态。

MySQL Workbench 允许以最漂亮的方式使用 ERM 设计数据库

20 世纪 80 年代，所有组织都开始使用关系型数据库（我说的“所有”是指地球上的所有组织）。如果搜索足够长的时间，你可能还会发现尚未拥有计算机的组织，他们通常使用定制的数据库。数十年来，这些驻留在大型计算机的数据库数据不断增加，制造商和供应商的服务费用也随之增加。

这些定制数据库包含数十个不对外显示的、相互交织的表格。无数的触发器、函数、过程和视图不仅可以组织存储，还可以运行该组织的所有业务流程。应用层上的应用程序为普通人提供了使用数据库的接口。然而，这些应用程序大多不操作任何业务流程，而只是调用存储过程来执行这些流程。

1992 年的 Microsoft Access 1.1，带有可视化查询编辑器和表单生成器

由于 80 年代的数据库顾问在几十年前已经退休，因此大部分定制的数据库系统仍在运行，但其 SQL 应用程序代码却大多无人维护。对于许多大型组织来说，这些数据库应用程序已成为黑盒，他们不知道这些系统的具体功能和工作原理，更不知道应该如何维护这些系统。

然而，企业严重依赖这些应用程序，尤其是它们现在已经变得不可替代。对这些应用程序进行逆向工程和重新架构已成为大量企业的唯一出路。这些“遗留数据库迁移项目”的成本往往高得离谱，可达数百万美元。

想象一下，如果一家保险公司完全不知道他们的主机是如何计算单个合同的风险，他们也就无法告诉客户特定索赔会对保费产生什么影响。对软件如何运行业务一无所知的企业数量之多，既令人恐惧，又令人啼笑皆非。只有当你是客户，而黑盒中包括你的数据时，你才会切身体会到害怕。

我曾亲身经历过一些企业，非技术员工将核心关系型数据库称为“Oracle”或 “DB2”，原因是这对 IT 部门造成了极大的限制，以至于影响 RDBMS 的每个变更请求都将成为一项长达数月而非几天的任务—— IT 部门将责任归咎于 “Oracle”，核心数据库成为故障的中心点。

问题出在哪里？关系型数据库和其设计原则促使你将数据集中到数据库中。随着业务的增长，关系型数据库会随着其产生的垃圾数据而增长。最终，您的企业将在经济层面无法摆脱关系型数据库。

我可以引用无数的媒体对关系型数据库毁掉企业和人们日常生活的报道，比如航空业的例子有《航空公司订票系统短暂崩溃》（2000年）、《航空公司的计算机系统为何经常崩溃》（2016年）、《西南航空失败背后可耻的公开秘密》（2022年），金融业的例子有《TSB银行因计算机升级失败被罚近5000万英镑》（2018年），公共部门的例子有《6年，6000万欧元——但职业介绍所没有软件》（2017年）。

等待遗留数据库迁移项目完成

在关系型数据库管理系统发明的时代，使用的计算机和如今的计算机完全不同，用例也完全不同，这些系统需要处理的数据量小到可以轻松装进当今任何人的口袋。

我强烈推荐里克-霍利汉（Rick Houlihan）参加他关于数据库和数据库技术未来的演讲，请在 YouTube 上查看他的各种演讲。以下是他在《软件工程日报》（Software Engineering Daily）上接受的采访内容。

《软件工程日报》第 979 节访谈

 

Jeff Meyerson（《软件工程日报》创始人）：

在 SQL 成为主流数据库类型之后，关于NoSQL 为何会流行起来有几种解释。我们在节目中探讨了一些不同的理论。请从历史的角度谈谈 NoSQL 为什么会流行起来。

 

Rick Houlihan（现MongoDB员工，前 AWS员工）：

当然，我的意思是，归根结底，还是因为开始处理大量数据时，我们使用了多年的关系型数据库的扩展性并不理想，这其实又回到了关系型数据库被发明的初衷。关系型数据库之所以出现，是因为我们面临数据压力，处理数据的成本阻碍扩展。

 

而关系型数据库降低了存储系统的压力，因为规范化数据模型去除了数据的重复性，减轻了存储系统的压力，而存储空间在三四年前确实是数据中心最昂贵的资源。

 

但现在，快进到今天，我们为每千兆字节（GB）支付几分钱，为每 CPU 分钟支付几美元，CPU 不再只是一种固定资产，当它不做其他事情时，就会在闲置循环中旋转。这是我们可以用来做其他事情的资产。因此，可以说，我们不再愿意花钱去完成连接数据和运行复杂查询这类事情。

当结构化数据需要符合 ACID 标准时，RDBMS 非常强大。然而，许多用例根本不需要 ACID 合规性，其中包括视频流、游戏、社交媒体、互联网搜索等。所有这些用例都更倾向于速度和性能，而不是具备一致性和原子性的 ACID 合规性。

20 世纪 80 年代的数据中心以 20 世纪 80 年代的方式管理数据——存储成本非常高昂

互联网搜索引擎不需要向每个用户显示最新的结果，也不是每个用户都需要相同的结果。因此，ACID 合规性与互联网搜索引擎的用例完全无关。没有哪个正常人会将 RDBMS 用于大型互联网搜索引擎或社交媒体网站。

很明显，“一刀切”式的通用数据库很难在任何用例中取得优势。试图将 RDBMS 用于事务、搜索、分析和任何其他用例，都很可能无法获得最佳结果。因此，最明显的问题是专门构建的解决方案。这些解决方案可以是数据库，甚至是关系型数据库，但也可以是其他系统，如专用搜索引擎，甚至是定制软件。

只有严格遵守微服务架构，不构建 “微服务单体”（即所有微服务都在关系型数据库等单一集中式数据管理系统上运行），使用专门构建的数据管理方法才能奏效。微服务架构与单体数据库搭配使用的情况很常见，这使得微服务方法完全失去了作用。
 

应用程序数据存储的首选应该是基本的键值存储，如 Apache Cassandra、AWS DynamoDB、Google Cloud Spanner 或 Azure Cosmos DB。键值存储具有高扩展性、耐用性和简单性。它们适用于所有基本应用程序用例，在这些用例中，您只需插入数据并最多使用 3-4 个键即可访问数据。

本地活动日历的简单 Dynamo 表

如果您的数据需要更复杂的查询（如搜索或分析），您可以随时将数据从键值存储流式传输到其他系统，切换到专用搜索引擎或分析系统。如果完全不需要查询，只需要简单的数据存储，那么使用 AWS S3、Azure Blob Storage 或 Google Cloud Storage 等对象存储是最佳实践方法。

MongoDB 或 AWS DocumentDB 等文档存储试图提供关系型数据库的替代方案，尽管它们通常具有相同的原理，差别在于不是关系型数据库。从表格到文档可能仍然会带来以前遇到过的相同问题。

关系型数据库的一个常见用例是搜索，关系型数据库很少适合这种用例。在大多数情况下，搜索功能根本不需要符合 ACID 标准。专门构建的搜索引擎（如 Lucene、Solr、OpenSearch 或 ElasticSearch）可提供更好的性能和更低的运营成本。

根据使用情况，云提供商的现有产品（如 Google 的云搜索）可能更适合您的要求。如果这些都不符合您的要求，考虑到 Go 等语言的开发速度，构建匹配需求的专用搜索软件也不是什么难事（请参阅使用 Go 编写服务器软件）。在一头扎进你心爱的关系型数据库之前，绝对有必要计算一下这个选择所带来的影响。

关系型数据库的主场是事务处理。不过，这一领域目前正受到Amazon QLDB 等基于区块链的数据库系统的挑战。大多数键值存储还提供 ACID 合规性选项，允许您在其中安全地存储事务。无论如何，始终建议为 OLTP（联机事务处理）和 OLAP（联机分析处理）建立不同的数据库环境。访问事务通常不超过 3-4 个键，因此键值存储也是事务的理想选择。

Amazon QLDB 工作原理概述

我个人已经在生产中部署了 Amazon QLDB，再也不会回到关系型数据库中去了。可加密验证的事务存储的优势实现了更高的可审计性。任何人都可以操作关系型数据库中的事务，而 QLDB 则使用事务的压力跟踪记录的任何更改。对于财务交易处理，QLDB 是我的首选系统。不过，这取决于用例以及用例是否需要加密验证。

我喜欢使用存储过程、函数、触发器和视图编写 SQL，使用 MySQL 工作台设计关系型数据库对我来说很有趣，MySQL 8最新的地理空间数据功能令人惊叹。在关系型数据库中可以做的事情太多了——所有事情可以集中于一处完成。老实说，我有时会怀念在 MySQL、Oracle 或 SQL Server 中编写整个业务应用程序的日子。但我必须对自己诚实：这在 80 年代是可以接受的。进入 2023 年，计算和存储发生了变化，我们的数据中心和应用程序也发生了变化。

上图：评估数据存储要求 vs 选择关系型数据库

下图：开发人员

随着数据库系统、键值和对象存储、搜索引擎技术和编程语言的广泛应用，几十年来一直使用一种数据库的时代已经一去不复返了。再也不会有项目无休止地争论 MySQL、MSSQL、Oracle 或 Postgres 是否是正确的选择。如今，数据库和存储是根据具体情况决定的。很多时候，我发现自己正在编写一个基于对象或键值存储的小型自定义存储策略。

如今，在实施软件或系统之前，我会先考虑存储哪些数据以及如何访问这些数据。然后，我经常要花费数小时甚至数天的时间来寻找正确的数据存储方法。说实话，关系型数据库很少成为解决方案的一部分，因为我留意到了集中式关系型数据库的长期影响。