我與關系型數(shù)據(jù)庫的淵源可以追溯到上世紀 90 年代末，它是我接觸計算機和編程的第一步，也是我作為軟件工程師接受正規(guī)教育和學習的重要組成部分，并自此與我的職業(yè)生涯如影隨形。我探索了 RDBMS（Relational Database Management System，關系型數(shù)據(jù)庫管理系統(tǒng)）的全新世界，如今仍保持對它的熱愛。

“我會堅持下去”——這是數(shù)據(jù)庫最常見的使用方法嗎？

在我的職業(yè)生涯中，我接觸過 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 互不兼容。

都是關系型數(shù)據(jù)庫嗎？一直都是

請相信，我見過所有的關系型數(shù)據(jù)庫——金融、交通、酒店、社交媒體、視頻流媒體服務及其他眾多領域。無論在哪里，你都可能發(fā)現(xiàn)關系型數(shù)據(jù)庫。這個世界的運行似乎完全靠關系型數(shù)據(jù)庫支撐，這些數(shù)據(jù)庫讓Oracle、IBM 和微軟賺得盆滿缽滿。如果你需要的是大型數(shù)據(jù)庫，你會選擇Oracle、IBM 或微軟；尤其在面臨金融領域的需求時，你也有可能選擇 SAP。

Gartner 通過 Adam Ronthal (@aronthal)發(fā)布于Twitter

據(jù)說最早的 RDBMS 出現(xiàn)于 20 世紀 70 年代初，當時結(jié)構化英語查詢語言（SEQUEL，后縮寫為 SQL）被發(fā)明。Oracle 公司于 1979 年發(fā)布了其第一個數(shù)據(jù)庫，而在此之前三年，霍尼韋爾（Honeywell）公司于 1976 年發(fā)布了Multics Relational Data Store——據(jù)說這是世界上第一個關系型數(shù)據(jù)庫。再過幾年，我們將回顧關系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）50 年的發(fā)展歷程。

毫無疑問，RDBMS 成為了現(xiàn)代社會和經(jīng)濟的支柱?？梢钥隙ǖ卣f，除非你住在山洞里，否則每個人都至少擁有一個關系型數(shù)據(jù)庫，并至少處于一個關系型數(shù)據(jù)庫中。

你一生中的全部信息都可能存儲在大型關系型數(shù)據(jù)庫系統(tǒng)中——這些系統(tǒng)很可能來自微軟、IBM、SAP 或 Oracle。想去海邊旅行嗎？你的機票、預訂等所有信息都在關系型數(shù)據(jù)庫中。無論向任何組織提供任何數(shù)據(jù)，這些數(shù)據(jù)最終都很可能會進入關系型數(shù)據(jù)庫。

大多數(shù)數(shù)據(jù)庫的實現(xiàn)都很簡單

然而，大多數(shù)數(shù)據(jù)庫都以類似于 PHP、MySQL、Microsoft Access 或VBA（Visual Basic for Applications）的形式存在。這些都不是復雜的數(shù)據(jù)庫管理系統(tǒng)，而是使用 RDBMS 存儲數(shù)據(jù)的小型應用程序。

對使用數(shù)據(jù)庫的許多人來說，RDBMS 一開始就是一種巨大的負擔，只是關系型數(shù)據(jù)庫的流行促使開發(fā)人員選擇關系型數(shù)據(jù)庫。大學、中學及編程課程都教授 SQL 和關系型數(shù)據(jù)庫，大多數(shù)開發(fā)人員可能傾向于使用關系型數(shù)據(jù)庫。

你可能也會認同以下觀點：大多數(shù)軟件開發(fā)人員都不是優(yōu)秀的數(shù)據(jù)庫開發(fā)人員。這種情況有時是因為他們不在乎（提升數(shù)據(jù)庫技術），但主要原因是教人如何正確構建關系型數(shù)據(jù)庫的學習資源很少。大多數(shù)學校、書籍和課程都側(cè)重于 SQL、規(guī)范化和事務處理，這一特點在關系型數(shù)據(jù)庫方面尤為明顯。

“外部應用程序甚至永遠不知道存在哪些表?！?/p>

——一位經(jīng)驗豐富的 DBA，2012 年退休，應要求匿名

普通開發(fā)人員聽到這句話一定會大吃一驚。對于經(jīng)驗豐富的數(shù)據(jù)庫工程師來說，將整個關系型數(shù)據(jù)庫結(jié)構隱藏在視圖和存儲過程之后是常態(tài)。

MySQL Workbench 允許以最漂亮的方式使用 ERM 設計數(shù)據(jù)庫

數(shù)據(jù)庫怪物已變得不可替代

20 世紀 80 年代，所有組織都開始使用關系型數(shù)據(jù)庫（我說的“所有”是指地球上的所有組織）。如果搜索足夠長的時間，你可能還會發(fā)現(xiàn)尚未擁有計算機的組織，他們通常使用定制的數(shù)據(jù)庫。數(shù)十年來，這些駐留在大型計算機的數(shù)據(jù)庫數(shù)據(jù)不斷增加，制造商和供應商的服務費用也隨之增加。

這些定制數(shù)據(jù)庫包含數(shù)十個不對外顯示的、相互交織的表格。無數(shù)的觸發(fā)器、函數(shù)、過程和視圖不僅可以組織存儲，還可以運行該組織的所有業(yè)務流程。應用層上的應用程序為普通人提供了使用數(shù)據(jù)庫的接口。然而，這些應用程序大多不操作任何業(yè)務流程，而只是調(diào)用存儲過程來執(zhí)行這些流程。

1992 年的 Microsoft Access 1.1，帶有可視化查詢編輯器和表單生成器

由于 80 年代的數(shù)據(jù)庫顧問在幾十年前已經(jīng)退休，因此大部分定制的數(shù)據(jù)庫系統(tǒng)仍在運行，但其 SQL 應用程序代碼卻大多無人維護。對于許多大型組織來說，這些數(shù)據(jù)庫應用程序已成為黑盒，他們不知道這些系統(tǒng)的具體功能和工作原理，更不知道應該如何維護這些系統(tǒng)。

然而，企業(yè)嚴重依賴這些應用程序，尤其是它們現(xiàn)在已經(jīng)變得不可替代。對這些應用程序進行逆向工程和重新架構已成為大量企業(yè)的唯一出路。這些“遺留數(shù)據(jù)庫遷移項目”的成本往往高得離譜，可達數(shù)百萬美元。

想象一下，如果一家保險公司完全不知道他們的主機是如何計算單個合同的風險，他們也就無法告訴客戶特定索賠會對保費產(chǎn)生什么影響。對軟件如何運行業(yè)務一無所知的企業(yè)數(shù)量之多，既令人恐懼，又令人啼笑皆非。只有當你是客戶，而黑盒中包括你的數(shù)據(jù)時，你才會切身體會到害怕。

關系型數(shù)據(jù)庫有什么問題？

我曾親身經(jīng)歷過一些企業(yè)，非技術員工將核心關系型數(shù)據(jù)庫稱為“Oracle”或 “DB2”，原因是這對 IT 部門造成了極大的限制，以至于影響 RDBMS 的每個變更請求都將成為一項長達數(shù)月而非幾天的任務—— IT 部門將責任歸咎于 “Oracle”，核心數(shù)據(jù)庫成為故障的中心點。

問題出在哪里？關系型數(shù)據(jù)庫和其設計原則促使你將數(shù)據(jù)集中到數(shù)據(jù)庫中。隨著業(yè)務的增長，關系型數(shù)據(jù)庫會隨著其產(chǎn)生的垃圾數(shù)據(jù)而增長。最終，您的企業(yè)將在經(jīng)濟層面無法擺脫關系型數(shù)據(jù)庫。

我可以引用無數(shù)的媒體對關系型數(shù)據(jù)庫毀掉企業(yè)和人們?nèi)粘Ｉ畹膱蟮?，比如航空業(yè)的例子有《航空公司訂票系統(tǒng)短暫崩潰》（2000年）、《航空公司的計算機系統(tǒng)為何經(jīng)常崩潰》（2016年）、《西南航空失敗背后可恥的公開秘密》（2022年），金融業(yè)的例子有《TSB銀行因計算機升級失敗被罰近5000萬英鎊》（2018年），公共部門的例子有《6年，6000萬歐元——但職業(yè)介紹所沒有軟件》（2017年）。

關系型數(shù)據(jù)庫來自一個不同的時代

在關系型數(shù)據(jù)庫管理系統(tǒng)發(fā)明的時代，使用的計算機和如今的計算機完全不同，用例也完全不同，這些系統(tǒng)需要處理的數(shù)據(jù)量小到可以輕松裝進當今任何人的口袋。

我強烈推薦里克-霍利漢（Rick Houlihan）參加他關于數(shù)據(jù)庫和數(shù)據(jù)庫技術未來的演講，請在 YouTube 上查看他的各種演講。以下是他在《軟件工程日報》（Software Engineering Daily）上接受的采訪內(nèi)容。

《軟件工程日報》第 979 節(jié)訪談

Jeff Meyerson（《軟件工程日報》創(chuàng)始人）：

在 SQL 成為主流數(shù)據(jù)庫類型之后，關于NoSQL 為何會流行起來有幾種解釋。我們在節(jié)目中探討了一些不同的理論。請從歷史的角度談談 NoSQL 為什么會流行起來。

Rick Houlihan（現(xiàn)MongoDB員工，前 AWS員工）：

當然，我的意思是，歸根結(jié)底，還是因為開始處理大量數(shù)據(jù)時，我們使用了多年的關系型數(shù)據(jù)庫的擴展性并不理想，這其實又回到了關系型數(shù)據(jù)庫被發(fā)明的初衷。關系型數(shù)據(jù)庫之所以出現(xiàn)，是因為我們面臨數(shù)據(jù)壓力，處理數(shù)據(jù)的成本阻礙擴展。

而關系型數(shù)據(jù)庫降低了存儲系統(tǒng)的壓力，因為規(guī)范化數(shù)據(jù)模型去除了數(shù)據(jù)的重復性，減輕了存儲系統(tǒng)的壓力，而存儲空間在三四年前確實是數(shù)據(jù)中心最昂貴的資源。

但現(xiàn)在，快進到今天，我們?yōu)槊壳д鬃止?jié)（GB）支付幾分錢，為每 CPU 分鐘支付幾美元，CPU 不再只是一種固定資產(chǎn)，當它不做其他事情時，就會在閑置循環(huán)中旋轉(zhuǎn)。這是我們可以用來做其他事情的資產(chǎn)。因此，可以說，我們不再愿意花錢去完成連接數(shù)據(jù)和運行復雜查詢這類事情。

當結(jié)構化數(shù)據(jù)需要符合 ACID 標準時，RDBMS 非常強大。然而，許多用例根本不需要 ACID 合規(guī)性，其中包括視頻流、游戲、社交媒體、互聯(lián)網(wǎng)搜索等。所有這些用例都更傾向于速度和性能，而不是具備一致性和原子性的 ACID 合規(guī)性。

20 世紀 80 年代的數(shù)據(jù)中心以 20 世紀 80 年代的方式管理數(shù)據(jù)——存儲成本非常高昂

互聯(lián)網(wǎng)搜索引擎不需要向每個用戶顯示最新的結(jié)果，也不是每個用戶都需要相同的結(jié)果。因此，ACID 合規(guī)性與互聯(lián)網(wǎng)搜索引擎的用例完全無關。沒有哪個正常人會將 RDBMS 用于大型互聯(lián)網(wǎng)搜索引擎或社交媒體網(wǎng)站。

解決方案是什么？專用系統(tǒng)

很明顯，“一刀切”式的通用數(shù)據(jù)庫很難在任何用例中取得優(yōu)勢。試圖將 RDBMS 用于事務、搜索、分析和任何其他用例，都很可能無法獲得最佳結(jié)果。因此，最明顯的問題是專門構建的解決方案。這些解決方案可以是數(shù)據(jù)庫，甚至是關系型數(shù)據(jù)庫，但也可以是其他系統(tǒng)，如專用搜索引擎，甚至是定制軟件。

只有嚴格遵守微服務架構，不構建 “微服務單體”（即所有微服務都在關系型數(shù)據(jù)庫等單一集中式數(shù)據(jù)管理系統(tǒng)上運行），使用專門構建的數(shù)據(jù)管理方法才能奏效。微服務架構與單體數(shù)據(jù)庫搭配使用的情況很常見，這使得微服務方法完全失去了作用。

對象存儲、鍵值存儲和文檔存儲

應用程序數(shù)據(jù)存儲的首選應該是基本的鍵值存儲，如 Apache Cassandra、AWS DynamoDB、Google Cloud Spanner 或 Azure Cosmos DB。鍵值存儲具有高擴展性、耐用性和簡單性。它們適用于所有基本應用程序用例，在這些用例中，您只需插入數(shù)據(jù)并最多使用 3-4 個鍵即可訪問數(shù)據(jù)。

本地活動日歷的簡單 Dynamo 表

如果您的數(shù)據(jù)需要更復雜的查詢（如搜索或分析），您可以隨時將數(shù)據(jù)從鍵值存儲流式傳輸?shù)狡渌到y(tǒng)，切換到專用搜索引擎或分析系統(tǒng)。如果完全不需要查詢，只需要簡單的數(shù)據(jù)存儲，那么使用 AWS S3、Azure Blob Storage 或 Google Cloud Storage 等對象存儲是最佳實踐方法。

MongoDB 或 AWS DocumentDB 等文檔存儲試圖提供關系型數(shù)據(jù)庫的替代方案，盡管它們通常具有相同的原理，差別在于不是關系型數(shù)據(jù)庫。從表格到文檔可能仍然會帶來以前遇到過的相同問題。

專用或定制搜索引擎

關系型數(shù)據(jù)庫的一個常見用例是搜索，關系型數(shù)據(jù)庫很少適合這種用例。在大多數(shù)情況下，搜索功能根本不需要符合 ACID 標準。專門構建的搜索引擎（如 Lucene、Solr、OpenSearch 或 ElasticSearch）可提供更好的性能和更低的運營成本。

根據(jù)使用情況，云提供商的現(xiàn)有產(chǎn)品（如 Google 的云搜索）可能更適合您的要求。如果這些都不符合您的要求，考慮到 Go 等語言的開發(fā)速度，構建匹配需求的專用搜索軟件也不是什么難事（請參閱使用 Go 編寫服務器軟件）。在一頭扎進你心愛的關系型數(shù)據(jù)庫之前，絕對有必要計算一下這個選擇所帶來的影響。

事務型數(shù)據(jù)庫或區(qū)塊鏈

關系型數(shù)據(jù)庫的主場是事務處理。不過，這一領域目前正受到Amazon QLDB 等基于區(qū)塊鏈的數(shù)據(jù)庫系統(tǒng)的挑戰(zhàn)。大多數(shù)鍵值存儲還提供 ACID 合規(guī)性選項，允許您在其中安全地存儲事務。無論如何，始終建議為 OLTP（聯(lián)機事務處理）和 OLAP（聯(lián)機分析處理）建立不同的數(shù)據(jù)庫環(huán)境。訪問事務通常不超過 3-4 個鍵，因此鍵值存儲也是事務的理想選擇。

Amazon QLDB 工作原理概述

我個人已經(jīng)在生產(chǎn)中部署了 Amazon QLDB，再也不會回到關系型數(shù)據(jù)庫中去了?？杉用茯炞C的事務存儲的優(yōu)勢實現(xiàn)了更高的可審計性。任何人都可以操作關系型數(shù)據(jù)庫中的事務，而 QLDB 則使用事務的壓力跟蹤記錄的任何更改。對于財務交易處理，QLDB 是我的首選系統(tǒng)。不過，這取決于用例以及用例是否需要加密驗證。

挑戰(zhàn)現(xiàn)狀

我喜歡使用存儲過程、函數(shù)、觸發(fā)器和視圖編寫 SQL，使用 MySQL 工作臺設計關系型數(shù)據(jù)庫對我來說很有趣，MySQL 8最新的地理空間數(shù)據(jù)功能令人驚嘆。在關系型數(shù)據(jù)庫中可以做的事情太多了——所有事情可以集中于一處完成。老實說，我有時會懷念在 MySQL、Oracle 或 SQL Server 中編寫整個業(yè)務應用程序的日子。但我必須對自己誠實：這在 80 年代是可以接受的。進入 2023 年，計算和存儲發(fā)生了變化，我們的數(shù)據(jù)中心和應用程序也發(fā)生了變化。

上圖：評估數(shù)據(jù)存儲要求 vs 選擇關系型數(shù)據(jù)庫 下圖：開發(fā)人員

隨著數(shù)據(jù)庫系統(tǒng)、鍵值和對象存儲、搜索引擎技術和編程語言的廣泛應用，幾十年來一直使用一種數(shù)據(jù)庫的時代已經(jīng)一去不復返了。再也不會有項目無休止地爭論 MySQL、MSSQL、Oracle 或 Postgres 是否是正確的選擇。如今，數(shù)據(jù)庫和存儲是根據(jù)具體情況決定的。很多時候，我發(fā)現(xiàn)自己正在編寫一個基于對象或鍵值存儲的小型自定義存儲策略。

如今，在實施軟件或系統(tǒng)之前，我會先考慮存儲哪些數(shù)據(jù)以及如何訪問這些數(shù)據(jù)。然后，我經(jīng)常要花費數(shù)小時甚至數(shù)天的時間來尋找正確的數(shù)據(jù)存儲方法。說實話，關系型數(shù)據(jù)庫很少成為解決方案的一部分，因為我留意到了集中式關系型數(shù)據(jù)庫的長期影響。

作者丨Jan Kammerath  編譯丨onehunnit

來源丨medium.com/@jankammerath/relational-database-systems-are-becoming-a-problem-but-what-to-do-about-it-eb868d060601