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

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

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

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

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

你的社會保障記錄、你的護照、你的警察記錄、你的出生證明以及所有這些都愉快地存儲在政府擁有的大型關(guān)系數(shù)據(jù)庫系統(tǒng)中——很可能來自微軟、IBM、SAP 或 Oracle。 想要去海灘旅行嗎？ 您的門票、預訂以及所有這些都位于關(guān)系數(shù)據(jù)庫中。 無論您向任何可怕的組織提供什么數(shù)據(jù)，最有可能最終都會出現(xiàn)在關(guān)系數(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ù)的小型應用程序。 對于他們中的許多人來說，RDBMS 一開始就是一種巨大的殺傷力。 只有關(guān)系數(shù)據(jù)庫的流行才促使開發(fā)人員選擇它們。 大學、學校、編程課程都教授 SQL 和關(guān)系數(shù)據(jù)庫。 大多數(shù)開發(fā)人員可能傾向于使用關(guān)系數(shù)據(jù)庫。

您可能也同意大多數(shù)軟件開發(fā)人員都不是優(yōu)秀的數(shù)據(jù)庫開發(fā)人員。 有時是因為他們不在乎，但主要是因為很少有學習資源可以教您如何正確構(gòu)建關(guān)系數(shù)據(jù)庫。 大多數(shù)大學、學校、書籍和課程都重點關(guān)注 SQL、規(guī)范化和事務。 就是這樣，它顯示在野外的關(guān)系數(shù)據(jù)庫中。

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

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

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

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

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

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

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

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

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

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

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

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

《軟件工程日報》第 979 集采訪。

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

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

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

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

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

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

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

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

對象、鍵值和文檔存儲

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

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

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

專用或定制的搜索引擎

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

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

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

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

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

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

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

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

今天，在實現(xiàn)軟件或系統(tǒng)之前，我會考慮存儲哪些數(shù)據(jù)以及如何訪問數(shù)據(jù)。 然后，我經(jīng)?；ㄙM數(shù)小時甚至數(shù)天的時間來尋找正確的數(shù)據(jù)存儲方法。 當我對自己誠實時，關(guān)系數(shù)據(jù)庫很少成為解決方案的一部分。 我經(jīng)?？吹郊惺疥P(guān)系數(shù)據(jù)庫的長期影響。