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

“我會堅(jiān)持下去”——這是數(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 互不兼容。

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

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

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

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

毫無疑問，RDBMS 成為了現(xiàn)代社會和經(jīng)濟(jì)的支柱。可以肯定地說，除非你住在山洞里，否則每個人都至少擁有一個關(guān)系型數(shù)據(jù)庫，并至少處于一個關(guān)系型數(shù)據(jù)庫中。

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

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

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

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

你可能也會認(rèn)同以下觀點(diǎn)：大多數(shù)軟件開發(fā)人員都不是優(yōu)秀的數(shù)據(jù)庫開發(fā)人員。這種情況有時(shí)是因?yàn)樗麄儾辉诤酰ㄌ嵘龜?shù)據(jù)庫技術(shù)），但主要原因是教人如何正確構(gòu)建關(guān)系型數(shù)據(jù)庫的學(xué)習(xí)資源很少。大多數(shù)學(xué)校、書籍和課程都側(cè)重于 SQL、規(guī)范化和事務(wù)處理，這一特點(diǎn)在關(guān)系型數(shù)據(jù)庫方面尤為明顯。

“外部應(yīng)用程序甚至永遠(yuǎn)不知道存在哪些表。”

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

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

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

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

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

這些定制數(shù)據(jù)庫包含數(shù)十個不對外顯示的、相互交織的表格。無數(shù)的觸發(fā)器、函數(shù)、過程和視圖不僅可以組織存儲，還可以運(yùn)行該組織的所有業(yè)務(wù)流程。應(yīng)用層上的應(yīng)用程序?yàn)槠胀ㄈ颂峁┝耸褂脭?shù)據(jù)庫的接口。然而，這些應(yīng)用程序大多不操作任何業(yè)務(wù)流程，而只是調(diào)用存儲過程來執(zhí)行這些流程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)然，我的意思是，歸根結(jié)底，還是因?yàn)殚_始處理大量數(shù)據(jù)時(shí)，我們使用了多年的關(guān)系型數(shù)據(jù)庫的擴(kuò)展性并不理想，這其實(shí)又回到了關(guān)系型數(shù)據(jù)庫被發(fā)明的初衷。關(guān)系型數(shù)據(jù)庫之所以出現(xiàn)，是因?yàn)槲覀兠媾R數(shù)據(jù)壓力，處理數(shù)據(jù)的成本阻礙擴(kuò)展。

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

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

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

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

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

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

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

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

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

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

本地活動日歷的簡單 Dynamo 表

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

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

專用或定制搜索引擎

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

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

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

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

Amazon QLDB 工作原理概述

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

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

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

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

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

如今，在實(shí)施軟件或系統(tǒng)之前，我會先考慮存儲哪些數(shù)據(jù)以及如何訪問這些數(shù)據(jù)。然后，我經(jīng)常要花費(fèi)數(shù)小時(shí)甚至數(shù)天的時(shí)間來尋找正確的數(shù)據(jù)存儲方法。說實(shí)話，關(guān)系型數(shù)據(jù)庫很少成為解決方案的一部分，因?yàn)槲伊粢獾搅思惺疥P(guān)系型數(shù)據(jù)庫的長期影響。

作者丨Jan Kammerath  編譯丨onehunnit

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