关系数据库系统正在成为一个问题——如何解决它？

我与关系数据库的关系可以追溯到90年代末。这是我学习计算机和编程的第一步，也成为我作为软件工程师的正规教育和学习的重要组成部分，并一直伴随着我的职业生涯。如果你想了解更多关于数据科学的相关内容，可以阅读以下这些文章：
手把手教你用Python创建SQL数据库！
分析数据库：点亮数据科学智慧人生
15个基本数据库营销技术
如何建立一个全自动的数据漂移检测管道

在我的职业生涯中，我接触过MySQL、Postgres、Oracle、Microsoft SQL Server、DBase、Access、SQLite、DB2、MariaDB、AWS RDS、Azure SQL、Google Cloud SQL以及几乎所有我能接触到的RDBMS。如果你不喜欢SQL，你就不会喜欢RDBMS，因为SQL本身就是一个奇幻的世界。并不是所有的SQL都是相同的，你了解MySQL和它自己的术语，你了解微软的T-SQL和世界著名的Oracle PL/SQL，也许不必在意它们彼此都不兼容。

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

这些我都见过——金融、交通、酒店、社交媒体、视频流服务等等。无论你去哪里，都可能找到关系数据库，这个世界似乎完全是在关系数据库上运行的。

据说第一个RDBMS出现于20世纪70年代早期，当时发明了结构化英语查询语言(SEQUEL，后来缩写为SQL)。Oracle在1979年发布了它的第一个数据库，比Honeywell在1976年发布Multics关系数据存储晚了三年(据说是世界上第一个关系数据库)。我们将回顾50年来关系数据库管理系统(RDBMS)的发展历程。不出所料，RDBMS成为了我们现代社会和经济的支柱。可以肯定地说，每个人都至少有一个关系数据库，每个人都至少在一个关系数据库中，除非你住在一个山洞里。

你的社会保障记录、护照、警察记录、出生证明等等都幸福地存放在政府拥有的大型关系数据库系统中（最有可能是来自微软、IBM、SAP或Oracle）。想去海滩度假吗？你的机票，预订和所有这些都在关系数据库中，你提供给任何庞大组织的任何数据都很可能最终进入关系数据库。

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

然而，大多数数据库以这样或那样的方式存在，其形式与PHP和MySQL或Microsoft Access和VBA (Visual Basic for Applications)相当。这些都不是复杂的数据库管理系统，而是使用RDBMS存储数据的小型应用程序。对于他们中的许多人来说，RDBMS一开始就是一个巨大的累赘。只有关系数据库的流行才促使开发人员选择它们。大学、学校、编程课程都教SQL和关系数据库，大多数开发人员可能都倾向于使用关系数据库。

你可能也同意，大多数软件开发人员并不是很擅长数据库开发。有时是因为他们不在乎，但主要是因为很少有学习资源教你如何正确构建关系数据库。大多数大学、学校、书籍和课程都关注SQL、规范化和事务处理。

外部应用程序甚至永远不会知道存在哪些表。
——在2012年退休的一位并希望保持匿名的经验丰富的数据库管理员说。

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

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

在20世纪80年代，所有组织都转向关系数据库（这里的所有，我指的是这个星球上的所有组织）。很有可能，如果你搜索的时间足够长，你可能仍然会找到还没有电脑的政府机构。通常，这些组织使用自定义构建数据库，这些数据库留在大型计算机上数十年，增加了来自制造商和供应商的数据和支持费用。

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

带有可视化查询编辑器和表单构建器

由于80年代的数据库顾问在几十年前就退休了，这些自定义数据库系统中的大多数都存在于那里，它们的SQL应用程序代码基本上没有得到维护。对于许多大型组织来说，这些数据库应用程序已经变成了黑盒子。他们不知道自己做了什么，如何工作，更不用说应该如何维护了。然而，企业严重依赖这些应用程序，到目前为止，这些应用程序已经变得不可替代。逆向工程和重新构建这些应用程序已经成为大量组织的唯一方法。这些“遗留数据库迁移项目”的成本通常高得离谱，高达数百万美元。

想象一下，作为一家保险公司，它完全不知道单个合同的风险是如何在其主机上计算的。他们无法告诉客户一项特定的索赔会对他们的保费产生什么影响。许多组织不知道软件是如何运作他们的业务的，这既令人震惊，同时也很滑稽。只有当你是客户，而黑盒子里的是你的数据时，你才会感到害怕。

关系数据库的问题是什么？

我个人遇到过一些企业，非技术员工将中央关系数据库称为“Oracle”或“DB2”。很简单，因为这对IT部门来说是一种约束，每个影响RDBMS的更改请求都将成为数月而不是几天的任务——IT部门将其归咎于“Oracle”。中央数据库成了故障的中心，当数据库无法为促销活动提供服务时，促销活动就会走下坡路。

关系数据库和设计这些数据库的原则促使你将数据集中到该数据库中。关系数据库随着业务的增长而增长，产生的垃圾数据也随之增加。最终会到达一个点，你的业务在经济上无法离开关系数据库。

我可以引用无数关于关系数据库破坏企业和我们日常生活的媒体报道，比如航空公司预订系统短暂崩溃(2000年)，为什么航空公司的计算机系统经常崩溃(2016年)，西南航空公司失败背后可耻的公开秘密(2022年)，TSB银行在计算机升级失败后被罚款近5000万英镑(2018年)或公共部门6年时间花费6000万欧元却没有软件可用（2017年）的例子。

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

关系数据库管理系统是在计算机与我们今天所拥有的完全不同的时代发明的，使用案例完全不同，而这些系统所处理的数据量在今天看来微乎其微。

我强烈推荐Rick Houlihan的演讲，他对数据库和未来数据库技术的思考非常有见地。你一定要在YouTube上观看他的各种演讲（https://www.youtube.com/results?search_query=%22Rick+Houlihan%22）。

他在Software Engineering Daily上的以下采访基本上概括了他的观点。

《软件工程日报》第979期访谈（https://softwareengineeringdaily.com/wp-content/uploads/2020/01/SED979-NoSQL-Rick-Houlihan.pdf）。

Jeff Meyerson(软件工程日报创始人)：

在SQL成为主流数据库类型之后，NoSQL的流行有几种解释。我们在这个节目中探讨了一些不同的理论。

Rick Houlihan (MongoDB，前AWS)：

确实，当人们开始处理大量的数据，我们多年来使用的关系数据库并不适应这种规模。这实际上回溯到它最初被发明的原因，关系数据库的出现是因为我们面临着数据压力，数据处理的成本阻碍了我们的扩展，而关系数据库通过规范化的数据模型对数据进行了去重，减轻了存储系统的压力，这在3或4年前是数据中心中最昂贵的资源。

但现在，我们每千兆字节只需支付几美分，每CPU分钟的费用是几美元，CPU不再只是固定资产，在闲置时处于空转状态，这是我们可以用来做其他事情的资产。因此，连接数据和运行复杂查询实际上并不是我们愿意花钱去做的事情。

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

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

解决方案是：有目的地构建系统

显然，具有“一刀切”态度的通用数据库很难在所有用例中获得优势。尝试将RDBMS用于事务、搜索、分析和任何其他用例，很可能永远不会得到其中任何一个的最佳结果。这些可以是数据库，甚至是关系数据库，但也可以是其他系统，例如专用搜索引擎，甚至是定制软件。

只有当你严格遵循微服务架构，并且不构建“微服务单体”时，使用专门构建的数据管理方法才有效，在这种情况下，你的微服务都在一个集中的数据管理系统(如关系数据库)上工作。经常会发现微服务架构与单片数据库相结合，这使得微服务方法完全无用。

对象存储、键值存储和文档存储

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

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

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

专用或定制的搜索引擎

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

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

交易数据库或区块链

关系数据库的主要领域是事务处理。然而，这一领域目前正受到亚马逊QLDB等基于区块链的数据库系统的挑战。大多数键值存储还提供ACID遵从性选项，允许你在其中安全地存储事务。无论如何，总是建议为OLTP(在线事务处理)和OLAP(在线分析处理)使用不同的数据库环境。访问事务通常不超过3-4个键，因此键值存储也可能是事务的理想选择。

我个人在生产环境中部署过Amazon QLDB，不会再使用关系数据库。加密可验证的事务存储的优点是允许更大的可审计性。虽然任何人都可以在关系数据库中操作事务，但QLDB使用事务的应变跟踪对记录的任何更改。对于金融事务处理，QLDB是我的首选系统。然而，这取决于用例，以及你是否需要用例的加密验证。

挑战现状

我喜欢用存储过程、函数、触发器和视图编写SQL。用MySQL Workbench设计关系数据库对我来说很有趣。MySQL8中有关地理空间数据的最新特性令人惊叹。在关系数据库中，你可以做很多事情，而且都在一个地方完成。说实话，我有时很怀念在MySQL、Oracle或SQL Server中编写整个业务应用程序的日子。但我必须对自己诚实：这在80年代是可以接受的。现在是2023年，计算和存储已经发生了变化，我们的数据中心和应用程序也发生了变化。

随着数据库系统、键值和对象存储、搜索引擎技术和编程语言的大量涌现，长期使用同一个数据库的时代已经结束了。不再有关于MySQL、MSSQL、Oracle或Postgres哪个是正确选择的无休止争论，现在的数据库和存储是根据具体情况来决定的。而且我经常会发现自己编写一个基于对象或键值存储的小型自定义存储策略。

如今，在实现一个软件或系统之前，我会考虑存储哪些数据以及如何访问这些数据。我经常花费数小时甚至数天的时间来寻找数据存储的正确方法。坦白地说，关系数据库很少是解决方案的一部分，我见证了太多次集中式关系数据库的长期影响。

谢谢你的阅读，你对关系数据库的看法是什么？你是否发现自己有“我就坚持这样做”的想法？请在评论区告诉我。你还可以订阅我们的YouTube频道，观看大量大数据行业相关公开课：https://www.youtube.com/channel/UCa8NLpvi70mHVsW4J_x9OeQ；在LinkedIn上关注我们，扩展你的人际网络！https://www.linkedin.com/company/dataapplab/

原文作者：Jan Kammerath
翻译作者：过儿
美工编辑：过儿
校对审稿：Chuang
原文链接：https://medium.com/@jankammerath/relational-database-systems-are-becoming-a-problem-but-what-to-do-about-it-eb868d060601