我與關系數據庫的關系可以追溯到 90 年代末。 這是我接觸計算機和編程的第一步，成為我作為軟件工程師的正規教育和學習的重要組成部分，并一直伴隨著我的職業生涯。 我幾乎爬遍了整個 RDBMS 兔子洞，但仍然喜歡它。
在我的職業生涯中，我接觸過 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。 可能沒有必要提及它們彼此不兼容。
都是關系型數據庫嗎？ 一直都是。
相信我，我都見過——金融、交通、酒店、社交媒體、視頻流服務等等。 無論您走到哪里，您都可能會找到關系數據庫。 世界似乎完全依靠關系數據庫來運行，這些數據庫主要為 Oracle、IBM 和 Microsoft 填補了空缺。 如果你需要很大的東西，比如非常大的東西，你就會打電話給甲骨文、IBM 或微軟。 很有可能，您的需求也可能會引導您選擇 SAP——尤其是在金融領域。
據說第一個 RDBMS 早在 20 世紀 70 年代初就出現了，當時結構化英語查詢語言（SEQUEL，后來縮寫為 SQL）被發明。 Oracle 于 1979 年發布了其第一個數據庫，三年前，Honeywell 于 1976 年發布了 Multics 關系數據存儲（據說是世界上第一個關系數據庫）。 幾年后，我們將回顧關系數據庫管理系統 (RDBMS) 的 50 年。 毫不奇怪，關系數據庫管理系統成為我們現代社會和經濟的支柱。 可以肯定地說，每個人都至少擁有一個，并且每個人都至少有一個關系數據庫，除非您住在山洞里。
你的社會保障記錄、你的護照、你的警察記錄、你的出生證明以及所有這些都愉快地存儲在政府擁有的大型關系數據庫系統中——很可能來自微軟、IBM、SAP 或 Oracle。 想要去海灘旅行嗎？ 您的門票、預訂以及所有這些都位于關系數據庫中。 無論您向任何可怕的組織提供什么數據，最有可能最終都會出現在關系數據庫中。
大多數數據庫實現都很簡單
然而，大多數數據庫以某種方式以類似于 php 和 MySQL 或 Microsoft Access 和 VBA（Visual Basic for Applications）的形式存在。 這些不是復雜的數據庫管理系統，而是僅使用 RDBMS 來存儲數據的小型應用程序。 對于他們中的許多人來說，RDBMS 一開始就是一種巨大的殺傷力。 只有關系數據庫的流行才促使開發人員選擇它們。 大學、學校、編程課程都教授 SQL 和關系數據庫。 大多數開發人員可能傾向于使用關系數據庫。
您可能也同意大多數軟件開發人員都不是優秀的數據庫開發人員。 有時是因為他們不在乎，但主要是因為很少有學習資源可以教您如何正確構建關系數據庫。 大多數大學、學校、書籍和課程都重點關注 SQL、規范化和事務。 就是這樣，它顯示在野外的關系數據庫中。
“外部應用程序永遠不會知道存在哪些表”——一位經驗豐富的 DBA，于 2012 年退休，希望保持匿名
一般的開發者會對這種說法感到震驚。 對于經驗豐富的數據庫工程師來說，將整個關系數據庫結構隱藏在視圖和存儲過程后面是常態。
數據庫怪物已經變得不可替代
在 20 世紀 80 年代，所有組織都轉向關系數據庫。 總的來說，我指的是這個星球上的所有組織。 如果您搜索足夠長的時間，您可能仍然會發現尚未擁有計算機的政府組織。 通常，這些組織使用駐留在大型計算機中數十年的自定義構建數據庫，從而增加了制造商和供應商的數據和支持費用。
這些定制的數據庫將包含數十個對外界不可見的相互交織的表。 無數的觸發器、函數、過程和視圖不僅會組織存儲，還會運行該組織的所有業務流程。 應用層上的應用程序為普通人提供了使用數據庫的接口。 然而，這些應用程序大多不操作任何業務流程，而只是調用存儲過程來執行這些流程。
由于 80 年代的數據庫顧問幾十年前已經退休，因此大多數定制的數據庫系統都存在，其 SQL 應用程序代碼大多無人維護。 對于許多大型組織來說，這些數據庫應用程序已經成為黑匣子。 他們不知道它們是做什么的，也不知道它們具體是如何工作的，更不用說它們應該如何維護了。 然而，企業嚴重依賴這些應用程序，而這些應用程序現在已經變得不可替代。 對這些應用程序進行逆向工程和重新架構已成為大量組織的唯一方法。 這些“遺留數據庫遷移項目”的成本往往高達數百萬美元。
想象一下，一家保險公司完全不知道如何在其主機上實際計算單個合同的風險。 他們無法告訴客戶特定索賠會對他們的保費產生什么影響。 不知道該軟件如何運行其業務的組織數量令人恐懼，同時又令人捧腹。 只有當你是客戶并且黑匣子里有你的數據時才會令人恐懼。
關系數據庫有什么問題？
我個人遇到過一些企業，非技術員工將中央關系數據庫稱為“Oracle”或“DB2”。 僅僅因為這對 IT 部門來說是一個很大的限制，以至于影響 RDBMS 的每個變更請求都將成為一項長達數月而不是幾天的任務——IT 部門將責任歸咎于“Oracle”。 中央數據庫成為故障的中心點。 當數據庫無法為促銷提供服務時，促銷就會走下坡路。 在桌子上添加一欄需要定期參加周日祈禱。 我們最好不要開始討論查詢性能。
問題？ 關系數據庫和設計這些數據庫的原則推動您在該數據庫內集中數據。 隨著業務的增長，關系數據庫會隨著其產生的垃圾數據而增長。 最終，您的企業將在經濟上無法擺脫關系數據庫。
關系數據庫來自不同的時代
關系數據庫管理系統是在計算機與我們今天的計算機完全不同的時代發明的。 用例完全不同，這些系統必須處理的體積適合今天任何人的口袋。
《軟件工程日報》第 979 集采訪。
Jeff Meyerson（《軟件工程日報》創始人）：在 SQL 成為主要數據庫類型之后，NoSQL 為何越來越受歡迎，有多種解釋。 我們在這個節目中探討了一些不同的理論。 請告訴我您對 NoSQL 流行原因的歷史看法。
Rick Houlihan（MongoDB，前 AWS）：嗯，當然。 我的意思是，歸根結底，當人們開始處理大量數據時，我們使用了這么多年的關系數據庫結果證明擴展性不太好。 這確實回到了它最初被發明的原因，關系數據庫的出現是因為我們再次面臨數據壓力，處理數據的成本阻礙了我們擴展，而 關系型數據庫減輕了存儲系統的壓力，因為規范化的數據模型對數據進行了去重，讓我們釋放了存儲空間，可以說，這在三四年前是數據中心最昂貴的資源。
但現在，快進到今天，我們為每 GB 支付幾美分，為每 CPU 分鐘支付美元，實際上 CPU 不再只是這種固定資產，當它不做任何其他事情時，它會在空閑循環中旋轉。 這是我們可以用來做其他事情的資產。 因此，可以這么說，連接數據和運行復雜查詢確實不是我們愿意花錢的事情。
當您擁有需要符合 ACID 的結構化數據時，RDBMS 也非常強大。 然而，許多用例根本不需要 ACID 合規性。 其中包括視頻流、游戲、社交媒體、互聯網搜索等等。 所有這些用例都更注重速度和性能，而不是 ACID 一致性和原子性合規性。
互聯網搜索引擎不需要向每個用戶顯示最新結果，也不是每個用戶都需要相同的結果。 因此，ACID 合規性與互聯網搜索引擎的用例完全無關。 任何頭腦正常的人都不會將 RDBMS 用于大型互聯網搜索引擎或社交媒體網站。
解決方案？ 專門構建的系統。
顯然，具有“一刀切”態度的通用數據庫很難在任何用例中取得優勢。 嘗試使用 RDBMS 進行事務、搜索、分析和任何其他用例很可能永遠不會獲得最佳結果。 因此，房間里顯而易見的大象是專門構建的解決方案。 這些可以是數據庫，甚至是關系數據庫，但也可以是其他系統，例如專用搜索引擎甚至定制軟件。
僅當您嚴格遵守微服務架構并且不構建“微服務單體”（其中所有微服務都在關系數據庫等單一集中式數據管理系統上運行）時，使用專用數據管理的方法才有效。 微服務架構與整體數據庫相結合的情況很常見，這使得微服務方法完全毫無用處。
對象、鍵值和文檔存儲
應用程序數據存儲的首選應該是基本的鍵值存儲，例如 Apache Cassandra、AWS DynamoDB、Google Cloud Spanner 或 Azure Cosmos DB。 鍵值存儲提供高可擴展性、耐用性和簡單性。 它們適用于所有基本應用程序用例，您只需要插入數據并使用最多 3-4 個鍵訪問它。
如果您的數據需要更復雜的查詢，例如 搜索或分析，您始終可以通過將數據從鍵值存儲流式傳輸到其他系統來切換到專用搜索引擎或分析系統。 如果您根本不需要查詢而只需要簡單的數據存儲，那么使用 AWS S3、Azure Blob 存儲或 Google Cloud Storage 等對象存儲是最佳實踐方法。
MongoDB 或 AWS DocumentDB 等文檔存儲嘗試提供關系數據庫的替代方案，盡管它們通常具有相同的原理，只是不是關系數據庫。 只是從表格轉移到文檔可能仍然會給您帶來以前遇到的相同問題。
專用或定制的搜索引擎
關系數據庫的一個常見用例是搜索。 這是關系數據庫很少適合的用例。 在大多數情況下，搜索功能根本不需要符合 ACID。 Lucene、Solr、OpenSearch 或 ElasticSearch 等專門構建的搜索引擎可顯著提高性能并降低運營成本。
根據使用案例，云提供商（例如 Google 的 Cloud Search）的現有產品可能已經更適合您的要求。 如果這些都不符合您的要求，那么考慮到 Go 等語言的開發速度（請參閱使用 Go 編寫服務器軟件），構建適合您需求的專用搜索軟件并不是太牽強。 在直接進入您喜愛的關系數據庫之前，絕對值得計算您的選擇的影響。
交易數據庫或區塊鏈
關系數據庫的主場是事務處理。 然而，這一領域目前受到 Amazon QLDB 等基于區塊鏈的數據庫系統的挑戰。 大多數鍵值存儲還提供 ACID 合規選項，允許您在其中安全地存儲事務。 無論如何，始終建議為 OLTP（聯機事務處理）和 OLAP（聯機分析處理）使用不同的數據庫環境。 訪問事務通常由不超過 3-4 個鍵完成，因此鍵值存儲也可能是事務的理想選擇。
我親自在生產環境中部署了 Amazon QLDB，并且不會再使用關系數據庫。 可加密驗證的交易存儲的優點是可實現更高的可審計性。 雖然任何人都可以操作關系數據庫中的事務，但 QLDB 使用事務的壓力來跟蹤記錄的任何更改。 對于金融交易處理，QLDB 是我的首選系統。 但是，這取決于用例以及您的用例是否需要加密驗證。
挑戰現狀
我喜歡使用存儲過程、函數、觸發器和視圖編寫 SQL ?。 使用 MySQL Workbench 設計關系數據庫對我來說很有趣。 MySQL 8 中地理空間數據的最新功能令人驚嘆。 您可以在關系數據庫中做很多事情 - 全部集中在一處。 老實說，我有時會懷念在 MySQL、Oracle 或 SQL Server 中編寫整個業務應用程序的日子。 但我需要對自己誠實：這在 80 年代是可以接受的。 進入 2023 年，計算和存儲發生了變化，我們的數據中心和應用程序也發生了變化。
隨著數據庫系統、鍵值和對象存儲、搜索引擎技術和編程語言的廣泛應用，幾十年來使用數據庫的時代已經結束。 不再有關于 MySQL、MSSQL、Oracle 或 Postgres 是否是正確選擇的無休止爭論的項目。 今天的數據庫和存儲是根據具體情況決定的。 我經常發現自己編寫了一個基于對象或鍵值存儲的小型自定義存儲策略。
今天，在實現軟件或系統之前，我會考慮存儲哪些數據以及如何訪問數據。 然后，我經常花費數小時甚至數天的時間來尋找正確的數據存儲方法。 當我對自己誠實時，關系數據庫很少成為解決方案的一部分。 我經?？吹郊惺疥P系數據庫的長期影響。
