关系数据库系统正在成为一个问题，该怎么办呢？

我与关系数据库的关系可以追溯到 90 年代末。 这是我接触计算机和编程的第一步，成为我作为软件工程师的正规教育和学习的重要组成部分，并一直伴随着我的职业生涯。 我几乎爬遍了整个 RDBMS 兔子洞，但仍然喜欢它。

在我的职业生涯中，我接触过 MySQL、Postgres、Oracle、Microsoft SQL Server、DBase、Access、SQLite、DB2、MariaDB、AWS RDS、Azure SQL、google Cloud SQL 以及几乎所有我能接触到的 RDBMS。 如果你不喜欢 SQL，就不可能喜欢 RDBMS，因为 SQL 本身就是一个兔子洞。 而且并非所有 SQL 都是相同的。 MySQL 有自己的行话，Microsoft 的 T-SQL 和世界著名的 Oracle PL/SQL。 可能没有必要提及它们彼此不兼容。

都是关系型数据库吗？ 一直都是。

相信我，我都见过——金融、交通、酒店、社交媒体、视频流服务等等。 无论您走到哪里，您都可能会找到关系数据库。 世界似乎完全依靠关系数据库来运行，这些数据库主要为 Oracle、IBM 和 Microsoft 填补了空缺。 如果你需要很大的东西，比如非常大的东西，你就会打电话给甲骨文、IBM 或微软。 很有可能，您的需求也可能会引导您选择 SAP——尤其是在金融领域。

据说第一个 RDBMS 早在 20 世纪 70 年代初就出现了，当时结构化英语查询语言（SEQUEL，后来缩写为 SQL）被发明。 Oracle 于 1979 年发布了其第一个数据库，三年前，Honeywell 于 1976 年发布了 Multics 关系数据存储（据说是世界上第一个关系数据库）。 几年后，我们将回顾关系数据库管理系统 (RDBMS) 的 50 年。 毫不奇怪，关系数据库管理系统成为我们现代社会和经济的支柱。 可以肯定地说，每个人都至少拥有一个，并且每个人都至少有一个关系数据库，除非您住在山洞里。

你的社会保障记录、你的护照、你的警察记录、你的出生证明以及所有这些都愉快地存储在政府拥有的大型关系数据库系统中——很可能来自微软、IBM、SAP 或 Oracle。 想要去海滩旅行吗？ 您的门票、预订以及所有这些都位于关系数据库中。 无论您向任何可怕的组织提供什么数据，最有可能最终都会出现在关系数据库中。

大多数数据库实现都很简单

然而，大多数数据库以某种方式以类似于 php 和 MySQL 或 Microsoft Access 和 VBA（Visual Basic for Applications）的形式存在。 这些不是复杂的数据库管理系统，而是仅使用 RDBMS 来存储数据的小型应用程序。 对于他们中的许多人来说，RDBMS 一开始就是一种巨大的杀伤力。 只有关系数据库的流行才促使开发人员选择它们。 大学、学校、编程课程都教授 SQL 和关系数据库。 大多数开发人员可能倾向于使用关系数据库。

您可能也同意大多数软件开发人员都不是优秀的数据库开发人员。 有时是因为他们不在乎，但主要是因为很少有学习资源可以教您如何正确构建关系数据库。 大多数大学、学校、书籍和课程都重点关注 SQL、规范化和事务。 就是这样，它显示在野外的关系数据库中。

“外部应用程序永远不会知道存在哪些表”——一位经验丰富的 DBA，于 2012 年退休，希望保持匿名

一般的开发者会对这种说法感到震惊。 对于经验丰富的数据库工程师来说，将整个关系数据库结构隐藏在视图和存储过程后面是常态。

数据库怪物已经变得不可替代

在 20 世纪 80 年代，所有组织都转向关系数据库。 总的来说，我指的是这个星球上的所有组织。 如果您搜索足够长的时间，您可能仍然会发现尚未拥有计算机的政府组织。 通常，这些组织使用驻留在大型计算机中数十年的自定义构建数据库，从而增加了制造商和供应商的数据和支持费用。

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

由于 80 年代的数据库顾问几十年前已经退休，因此大多数定制的数据库系统都存在，其 SQL 应用程序代码大多无人维护。 对于许多大型组织来说，这些数据库应用程序已经成为黑匣子。 他们不知道它们是做什么的，也不知道它们具体是如何工作的，更不用说它们应该如何维护了。 然而，企业严重依赖这些应用程序，而这些应用程序现在已经变得不可替代。 对这些应用程序进行逆向工程和重新架构已成为大量组织的唯一方法。 这些“遗留数据库迁移项目”的成本往往高达数百万美元。

想象一下，一家保险公司完全不知道如何在其主机上实际计算单个合同的风险。 他们无法告诉客户特定索赔会对他们的保费产生什么影响。 不知道该软件如何运行其业务的组织数量令人恐惧，同时又令人捧腹。 只有当你是客户并且黑匣子里有你的数据时才会令人恐惧。

关系数据库有什么问题？

我个人遇到过一些企业，非技术员工将中央关系数据库称为“Oracle”或“DB2”。 仅仅因为这对 IT 部门来说是一个很大的限制，以至于影响 RDBMS 的每个变更请求都将成为一项长达数月而不是几天的任务——IT 部门将责任归咎于“Oracle”。 中央数据库成为故障的中心点。 当数据库无法为促销提供服务时，促销就会走下坡路。 在桌子上添加一栏需要定期参加周日祈祷。 我们最好不要开始讨论查询性能。

问题？ 关系数据库和设计这些数据库的原则推动您在该数据库内集中数据。 随着业务的增长，关系数据库会随着其产生的垃圾数据而增长。 最终，您的企业将在经济上无法摆脱关系数据库。

关系数据库来自不同的时代

关系数据库管理系统是在计算机与我们今天的计算机完全不同的时代发明的。 用例完全不同，这些系统必须处理的体积适合今天任何人的口袋。

《软件工程日报》第 979 集采访。

Jeff Meyerson（《软件工程日报》创始人）：在 SQL 成为主要数据库类型之后，NoSQL 为何越来越受欢迎，有多种解释。 我们在这个节目中探讨了一些不同的理论。 请告诉我您对 NoSQL 流行原因的历史看法。

Rick Houlihan（MongoDB，前 AWS）：嗯，当然。 我的意思是，归根结底，当人们开始处理大量数据时，我们使用了这么多年的关系数据库结果证明扩展性不太好。 这确实回到了它最初被发明的原因，关系数据库的出现是因为我们再次面临数据压力，处理数据的成本阻碍了我们扩展，而 关系型数据库减轻了存储系统的压力，因为规范化的数据模型对数据进行了去重，让我们释放了存储空间，可以说，这在三四年前是数据中心最昂贵的资源。

但现在，快进到今天，我们为每 GB 支付几美分，为每 CPU 分钟支付美元，实际上 CPU 不再只是这种固定资产，当它不做任何其他事情时，它会在空闲循环中旋转。 这是我们可以用来做其他事情的资产。 因此，可以这么说，连接数据和运行复杂查询确实不是我们愿意花钱的事情。

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

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

解决方案？ 专门构建的系统。

显然，具有“一刀切”态度的通用数据库很难在任何用例中取得优势。 尝试使用 RDBMS 进行事务、搜索、分析和任何其他用例很可能永远不会获得最佳结果。 因此，房间里显而易见的大象是专门构建的解决方案。 这些可以是数据库，甚至是关系数据库，但也可以是其他系统，例如专用搜索引擎甚至定制软件。

仅当您严格遵守微服务架构并且不构建“微服务单体”（其中所有微服务都在关系数据库等单一集中式数据管理系统上运行）时，使用专用数据管理的方法才有效。 微服务架构与整体数据库相结合的情况很常见，这使得微服务方法完全毫无用处。

对象、键值和文档存储

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

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

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

专用或定制的搜索引擎

关系数据库的一个常见用例是搜索。 这是关系数据库很少适合的用例。 在大多数情况下，搜索功能根本不需要符合 ACID。 Lucene、Solr、OpenSearch 或 ElasticSearch 等专门构建的搜索引擎可显着提高性能并降低运营成本。

根据使用案例，云提供商（例如 Google 的 Cloud Search）的现有产品可能已经更适合您的要求。 如果这些都不符合您的要求，那么考虑到 Go 等语言的开发速度（请参阅使用 Go 编写服务器软件），构建适合您需求的专用搜索软件并不是太牵强。 在直接进入您喜爱的关系数据库之前，绝对值得计算您的选择的影响。

交易数据库或区块链

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

我亲自在生产环境中部署了 Amazon QLDB，并且不会再使用关系数据库。 可加密验证的交易存储的优点是可实现更高的可审计性。 虽然任何人都可以操作关系数据库中的事务，但 QLDB 使用事务的压力来跟踪记录的任何更改。 对于金融交易处理，QLDB 是我的首选系统。 但是，这取决于用例以及您的用例是否需要加密验证。

挑战现状

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

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

今天，在实现软件或系统之前，我会考虑存储哪些数据以及如何访问数据。 然后，我经常花费数小时甚至数天的时间来寻找正确的数据存储方法。 当我对自己诚实时，关系数据库很少成为解决方案的一部分。 我经常看到集中式关系数据库的长期影响。