我與關(guān)系數(shù)據(jù)庫的關(guān)系可以追溯到 90 年代末。 這是我接觸計(jì)算機(jī)和編程的第一步，成為我作為軟件工程師的正規(guī)教育和學(xué)習(xí)的重要組成部分，并一直伴隨著我的職業(yè)生涯。 我?guī)缀跖辣榱苏麄€(gè) RDBMS 兔子洞，但仍然喜歡它。

在我的職業(yè)生涯中，我接觸過 MySQL、Postgres、Oracle、Microsoft SQL Server、DBase、Access、SQLite、DB2、MariaDB、AWS RDS、Azure SQL、Google Cloud SQL 以及幾乎所有我能接觸到的 RDBMS。 如果你不喜歡 SQL，就不可能喜歡 RDBMS，因?yàn)?SQL 本身就是一個(gè)兔子洞。 而且并非所有 SQL 都是相同的。 MySQL 有自己的行話，Microsoft 的 T-SQL 和世界著名的 Oracle PL/SQL。 可能沒有必要提及它們彼此不兼容。

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

相信我，我都見過——金融、交通、酒店、社交媒體、視頻流服務(wù)等等。 無論您走到哪里，您都可能會(huì)找到關(guān)系數(shù)據(jù)庫。 世界似乎完全依靠關(guān)系數(shù)據(jù)庫來運(yùn)行，這些數(shù)據(jù)庫主要為 Oracle、IBM 和 Microsoft 填補(bǔ)了空缺。 如果你需要很大的東西，比如非常大的東西，你就會(huì)打電話給甲骨文、IBM 或微軟。 很有可能，您的需求也可能會(huì)引導(dǎo)您選擇 SAP——尤其是在金融領(lǐng)域。

據(jù)說第一個(gè) RDBMS 早在 20 世紀(jì) 70 年代初就出現(xiàn)了，當(dāng)時(shí)結(jié)構(gòu)化英語查詢語言（SEQUEL，后來縮寫為 SQL）被發(fā)明。 Oracle 于 1979 年發(fā)布了其第一個(gè)數(shù)據(jù)庫，三年前，Honeywell 于 1976 年發(fā)布了 Multics 關(guān)系數(shù)據(jù)存儲(chǔ)（據(jù)說是世界上第一個(gè)關(guān)系數(shù)據(jù)庫）。 幾年后，我們將回顧關(guān)系數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 的 50 年。 毫不奇怪，關(guān)系數(shù)據(jù)庫管理系統(tǒng)成為我們現(xiàn)代社會(huì)和經(jīng)濟(jì)的支柱。 可以肯定地說，每個(gè)人都至少擁有一個(gè)，并且每個(gè)人都至少有一個(gè)關(guān)系數(shù)據(jù)庫，除非您住在山洞里。

你的社會(huì)保障記錄、你的護(hù)照、你的警察記錄、你的出生證明以及所有這些都愉快地存儲(chǔ)在政府擁有的大型關(guān)系數(shù)據(jù)庫系統(tǒng)中——很可能來自微軟、IBM、SAP 或 Oracle。 想要去海灘旅行嗎？ 您的門票、預(yù)訂以及所有這些都位于關(guān)系數(shù)據(jù)庫中。 無論您向任何可怕的組織提供什么數(shù)據(jù)，最有可能最終都會(huì)出現(xiàn)在關(guān)系數(shù)據(jù)庫中。

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

然而，大多數(shù)數(shù)據(jù)庫以某種方式以類似于 PHP 和 MySQL 或 Microsoft Access 和 VBA（Visual Basic for Applications）的形式存在。 這些不是復(fù)雜的數(shù)據(jù)庫管理系統(tǒng)，而是僅使用 RDBMS 來存儲(chǔ)數(shù)據(jù)的小型應(yīng)用程序。 對(duì)于他們中的許多人來說，RDBMS 一開始就是一種巨大的殺傷力。 只有關(guān)系數(shù)據(jù)庫的流行才促使開發(fā)人員選擇它們。 大學(xué)、學(xué)校、編程課程都教授 SQL 和關(guān)系數(shù)據(jù)庫。 大多數(shù)開發(fā)人員可能傾向于使用關(guān)系數(shù)據(jù)庫。

您可能也同意大多數(shù)軟件開發(fā)人員都不是優(yōu)秀的數(shù)據(jù)庫開發(fā)人員。 有時(shí)是因?yàn)樗麄儾辉诤酰饕且驗(yàn)楹苌儆袑W(xué)習(xí)資源可以教您如何正確構(gòu)建關(guān)系數(shù)據(jù)庫。 大多數(shù)大學(xué)、學(xué)校、書籍和課程都重點(diǎn)關(guān)注 SQL、規(guī)范化和事務(wù)。 就是這樣，它顯示在野外的關(guān)系數(shù)據(jù)庫中。

“外部應(yīng)用程序永遠(yuǎn)不會(huì)知道存在哪些表”——一位經(jīng)驗(yàn)豐富的 DBA，于 2012 年退休，希望保持匿名

一般的開發(fā)者會(huì)對(duì)這種說法感到震驚。 對(duì)于經(jīng)驗(yàn)豐富的數(shù)據(jù)庫工程師來說，將整個(gè)關(guān)系數(shù)據(jù)庫結(jié)構(gòu)隱藏在視圖和存儲(chǔ)過程后面是常態(tài)。

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

在 20 世紀(jì) 80 年代，所有組織都轉(zhuǎn)向關(guān)系數(shù)據(jù)庫。 總的來說，我指的是這個(gè)星球上的所有組織。 如果您搜索足夠長的時(shí)間，您可能仍然會(huì)發(fā)現(xiàn)尚未擁有計(jì)算機(jī)的政府組織。 通常，這些組織使用駐留在大型計(jì)算機(jī)中數(shù)十年的自定義構(gòu)建數(shù)據(jù)庫，從而增加了制造商和供應(yīng)商的數(shù)據(jù)和支持費(fèi)用。

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

由于 80 年代的數(shù)據(jù)庫顧問幾十年前已經(jīng)退休，因此大多數(shù)定制的數(shù)據(jù)庫系統(tǒng)都存在，其 SQL 應(yīng)用程序代碼大多無人維護(hù)。 對(duì)于許多大型組織來說，這些數(shù)據(jù)庫應(yīng)用程序已經(jīng)成為黑匣子。 他們不知道它們是做什么的，也不知道它們具體是如何工作的，更不用說它們應(yīng)該如何維護(hù)了。 然而，企業(yè)嚴(yán)重依賴這些應(yīng)用程序，而這些應(yīng)用程序現(xiàn)在已經(jīng)變得不可替代。 對(duì)這些應(yīng)用程序進(jìn)行逆向工程和重新架構(gòu)已成為大量組織的唯一方法。 這些“遺留數(shù)據(jù)庫遷移項(xiàng)目”的成本往往高達(dá)數(shù)百萬美元。

想象一下，一家保險(xiǎn)公司完全不知道如何在其主機(jī)上實(shí)際計(jì)算單個(gè)合同的風(fēng)險(xiǎn)。 他們無法告訴客戶特定索賠會(huì)對(duì)他們的保費(fèi)產(chǎn)生什么影響。 不知道該軟件如何運(yùn)行其業(yè)務(wù)的組織數(shù)量令人恐懼，同時(shí)又令人捧腹。 只有當(dāng)你是客戶并且黑匣子里有你的數(shù)據(jù)時(shí)才會(huì)令人恐懼。

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

我個(gè)人遇到過一些企業(yè)，非技術(shù)員工將中央關(guān)系數(shù)據(jù)庫稱為“Oracle”或“DB2”。 僅僅因?yàn)檫@對(duì) IT 部門來說是一個(gè)很大的限制，以至于影響 RDBMS 的每個(gè)變更請(qǐng)求都將成為一項(xiàng)長達(dá)數(shù)月而不是幾天的任務(wù)——IT 部門將責(zé)任歸咎于“Oracle”。 中央數(shù)據(jù)庫成為故障的中心點(diǎn)。 當(dāng)數(shù)據(jù)庫無法為促銷提供服務(wù)時(shí)，促銷就會(huì)走下坡路。 在桌子上添加一欄需要定期參加周日祈禱。 我們最好不要開始討論查詢性能。

問題？ 關(guān)系數(shù)據(jù)庫和設(shè)計(jì)這些數(shù)據(jù)庫的原則推動(dòng)您在該數(shù)據(jù)庫內(nèi)集中數(shù)據(jù)。 隨著業(yè)務(wù)的增長，關(guān)系數(shù)據(jù)庫會(huì)隨著其產(chǎn)生的垃圾數(shù)據(jù)而增長。 最終，您的企業(yè)將在經(jīng)濟(jì)上無法擺脫關(guān)系數(shù)據(jù)庫。

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

關(guān)系數(shù)據(jù)庫管理系統(tǒng)是在計(jì)算機(jī)與我們今天的計(jì)算機(jī)完全不同的時(shí)代發(fā)明的。 用例完全不同，這些系統(tǒng)必須處理的體積適合今天任何人的口袋。

《軟件工程日?qǐng)?bào)》第 979 集采訪。

Jeff Meyerson（《軟件工程日?qǐng)?bào)》創(chuàng)始人）：在 SQL 成為主要數(shù)據(jù)庫類型之后，NoSQL 為何越來越受歡迎，有多種解釋。 我們?cè)谶@個(gè)節(jié)目中探討了一些不同的理論。 請(qǐng)告訴我您對(duì) NoSQL 流行原因的歷史看法。

Rick Houlihan（MongoDB，前 AWS）：嗯，當(dāng)然。 我的意思是，歸根結(jié)底，當(dāng)人們開始處理大量數(shù)據(jù)時(shí)，我們使用了這么多年的關(guān)系數(shù)據(jù)庫結(jié)果證明擴(kuò)展性不太好。 這確實(shí)回到了它最初被發(fā)明的原因，關(guān)系數(shù)據(jù)庫的出現(xiàn)是因?yàn)槲覀冊(cè)俅蚊媾R數(shù)據(jù)壓力，處理數(shù)據(jù)的成本阻礙了我們擴(kuò)展，而 關(guān)系型數(shù)據(jù)庫減輕了存儲(chǔ)系統(tǒng)的壓力，因?yàn)橐?guī)范化的數(shù)據(jù)模型對(duì)數(shù)據(jù)進(jìn)行了去重，讓我們釋放了存儲(chǔ)空間，可以說，這在三四年前是數(shù)據(jù)中心最昂貴的資源。

但現(xiàn)在，快進(jìn)到今天，我們?yōu)槊?GB 支付幾美分，為每 CPU 分鐘支付美元，實(shí)際上 CPU 不再只是這種固定資產(chǎn)，當(dāng)它不做任何其他事情時(shí)，它會(huì)在空閑循環(huán)中旋轉(zhuǎn)。 這是我們可以用來做其他事情的資產(chǎn)。 因此，可以這么說，連接數(shù)據(jù)和運(yùn)行復(fù)雜查詢確實(shí)不是我們?cè)敢饣ㄥX的事情。

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

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

解決方案？ 專門構(gòu)建的系統(tǒng)。

顯然，具有“一刀切”態(tài)度的通用數(shù)據(jù)庫很難在任何用例中取得優(yōu)勢(shì)。 嘗試使用 RDBMS 進(jìn)行事務(wù)、搜索、分析和任何其他用例很可能永遠(yuǎn)不會(huì)獲得最佳結(jié)果。 因此，房間里顯而易見的大象是專門構(gòu)建的解決方案。 這些可以是數(shù)據(jù)庫，甚至是關(guān)系數(shù)據(jù)庫，但也可以是其他系統(tǒng)，例如專用搜索引擎甚至定制軟件。

僅當(dāng)您嚴(yán)格遵守微服務(wù)架構(gòu)并且不構(gòu)建“微服務(wù)單體”（其中所有微服務(wù)都在關(guān)系數(shù)據(jù)庫等單一集中式數(shù)據(jù)管理系統(tǒng)上運(yùn)行）時(shí)，使用專用數(shù)據(jù)管理的方法才有效。 微服務(wù)架構(gòu)與整體數(shù)據(jù)庫相結(jié)合的情況很常見，這使得微服務(wù)方法完全毫無用處。

對(duì)象、鍵值和文檔存儲(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ù)需要更復(fù)雜的查詢，例如 搜索或分析，您始終可以通過將數(shù)據(jù)從鍵值存儲(chǔ)流式傳輸?shù)狡渌到y(tǒng)來切換到專用搜索引擎或分析系統(tǒng)。 如果您根本不需要查詢而只需要簡(jiǎn)單的數(shù)據(jù)存儲(chǔ)，那么使用 AWS S3、Azure Blob 存儲(chǔ)或 Google Cloud Storage 等對(duì)象存儲(chǔ)是最佳實(shí)踐方法。

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

專用或定制的搜索引擎

關(guān)系數(shù)據(jù)庫的一個(gè)常見用例是搜索。 這是關(guān)系數(shù)據(jù)庫很少適合的用例。 在大多數(shù)情況下，搜索功能根本不需要符合 ACID。 Lucene、Solr、OpenSearch 或 ElasticSearch 等專門構(gòu)建的搜索引擎可顯著提高性能并降低運(yùn)營成本。

根據(jù)使用案例，云提供商（例如 Google 的 Cloud Search）的現(xiàn)有產(chǎn)品可能已經(jīng)更適合您的要求。 如果這些都不符合您的要求，那么考慮到 Go 等語言的開發(fā)速度（請(qǐng)參閱使用 Go 編寫服務(wù)器軟件），構(gòu)建適合您需求的專用搜索軟件并不是太牽強(qiáng)。 在直接進(jìn)入您喜愛的關(guān)系數(shù)據(jù)庫之前，絕對(duì)值得計(jì)算您的選擇的影響。

交易數(shù)據(jù)庫或區(qū)塊鏈

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

我親自在生產(chǎn)環(huán)境中部署了 Amazon QLDB，并且不會(huì)再使用關(guān)系數(shù)據(jù)庫。 可加密驗(yàn)證的交易存儲(chǔ)的優(yōu)點(diǎn)是可實(shí)現(xiàn)更高的可審計(jì)性。 雖然任何人都可以操作關(guān)系數(shù)據(jù)庫中的事務(wù)，但 QLDB 使用事務(wù)的壓力來跟蹤記錄的任何更改。 對(duì)于金融交易處理，QLDB 是我的首選系統(tǒng)。 但是，這取決于用例以及您的用例是否需要加密驗(yàn)證。

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

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

隨著數(shù)據(jù)庫系統(tǒng)、鍵值和對(duì)象存儲(chǔ)、搜索引擎技術(shù)和編程語言的廣泛應(yīng)用，幾十年來使用數(shù)據(jù)庫的時(shí)代已經(jīng)結(jié)束。 不再有關(guān)于 MySQL、MSSQL、Oracle 或 Postgres 是否是正確選擇的無休止?fàn)幷摰捻?xiàng)目。 今天的數(shù)據(jù)庫和存儲(chǔ)是根據(jù)具體情況決定的。 我經(jīng)常發(fā)現(xiàn)自己編寫了一個(gè)基于對(duì)象或鍵值存儲(chǔ)的小型自定義存儲(chǔ)策略。

今天，在實(shí)現(xiàn)軟件或系統(tǒng)之前，我會(huì)考慮存儲(chǔ)哪些數(shù)據(jù)以及如何訪問數(shù)據(jù)。 然后，我經(jīng)常花費(fèi)數(shù)小時(shí)甚至數(shù)天的時(shí)間來尋找正確的數(shù)據(jù)存儲(chǔ)方法。 當(dāng)我對(duì)自己誠實(shí)時(shí)，關(guān)系數(shù)據(jù)庫很少成為解決方案的一部分。 我經(jīng)常看到集中式關(guān)系數(shù)據(jù)庫的長期影響。