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

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

在我的職業(yè)生涯中，我接觸過 MySQL、Postgres、Oracle、Microsoft SQL Server、DBase、Access、SQLite、DB2、MariaDB、AWS RDS、Azure SQL、Google Cloud SQL 以及幾乎所有我能接觸到的 RDBMS。喜歡 RDBMS 就不可能不喜歡 SQL，而SQL 本身就是一個(gè)無底的兔子洞（rabbit hole，出自小說《愛麗絲漫游奇境記》，意指神秘世界）。SQL 并不完全相同，MySQL 有自己的行話，微軟的 T-SQL 和舉世聞名的Oracle的 PL/SQL 互不兼容。

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

請(qǐng)相信，我見過所有的關(guān)系型數(shù)據(jù)庫(kù)——金融、交通、酒店、社交媒體、視頻流媒體服務(wù)及其他眾多領(lǐng)域。無論在哪里，你都可能發(fā)現(xiàn)關(guān)系型數(shù)據(jù)庫(kù)。這個(gè)世界的運(yùn)行似乎完全靠關(guān)系型數(shù)據(jù)庫(kù)支撐，這些數(shù)據(jù)庫(kù)讓Oracle、IBM 和微軟賺得盆滿缽滿。如果你需要的是大型數(shù)據(jù)庫(kù)，你會(huì)選擇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)化英語(yǔ)查詢語(yǔ)言（SEQUEL，后縮寫為 SQL）被發(fā)明。Oracle 公司于 1979 年發(fā)布了其第一個(gè)數(shù)據(jù)庫(kù)，而在此之前三年，霍尼韋爾（Honeywell）公司于 1976 年發(fā)布了Multics Relational Data Store——據(jù)說這是世界上第一個(gè)關(guān)系型數(shù)據(jù)庫(kù)。再過幾年，我們將回顧關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)（RDBMS）50 年的發(fā)展歷程。

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

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

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

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

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

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

“外部應(yīng)用程序甚至永遠(yuǎn)不知道存在哪些表?！?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《軟件工程日?qǐng)?bào)》第 979 節(jié)訪談

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

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

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

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

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

但現(xiàn)在，快進(jìn)到今天，我們?yōu)槊壳д鬃止?jié)（GB）支付幾分錢，為每 CPU 分鐘支付幾美元，CPU 不再只是一種固定資產(chǎn)，當(dāng)它不做其他事情時(shí)，就會(huì)在閑置循環(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ù)——存儲(chǔ)成本非常高昂

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

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

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

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

對(duì)象存儲(chǔ)、鍵值存儲(chǔ)和文檔存儲(chǔ)

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

本地活動(dòng)日歷的簡(jiǎn)單 Dynamo 表

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

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

專用或定制搜索引擎

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

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

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

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

Amazon QLDB 工作原理概述

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

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

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

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

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

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

作者丨Jan Kammerath  編譯丨onehunnit

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