代碼家：簡明數據庫史

本文做者：代碼家，資深開發者，熱衷於開源社區， GitHub 20K 的 Star，15K 的 Follower；數字貨幣信奉者，熱愛二級市場交易（股票+數字貨幣）；目前在真格基金作投資。

若是你想與代碼家交流，能夠加他的微信：daimajia（著名來源和身份），若是你在創業，或者有想法創業，也歡迎投遞 BP 或者和代碼家郵件交流： huiwen@zhenfund.com

在工業時代，煤炭和鋼鐵的使用量是一個國家發達程度的指標。而到了信息時代，數據量將是新的發達程度指標，幾乎全部行業競爭本質上都是數據的競爭。支撐數據增加的背後，是一代又一代不斷演化的數據庫引擎，在真格基金的投資工做中，不斷的開始有中國團隊嘗試挑戰數據庫領域海外的壟斷地位，打造新一代的數據庫引擎。業餘時間，對整個數據庫發展史作了個簡單的總結。

整個數據庫大體經歷了四個發展階段。

第一階段：非關係型數據庫

在現代意義的數據庫出來以前（20 世紀 60 年代），文件系統（File system）能夠說是最先的數據庫，程序員們讀取文本文件，並經過代碼提取文件中的關鍵數據，在腦海中嘗試構造數據與數據之間的關係。當年能流行起來的編程語言，每每都有很強的文件和數據處理能力（好比 Perl 語言）。隨着數據量的增加，數據維度的多元化，以及對於數據可信和數據安全的要求不斷提高，簡單的將數據存儲在 txt 文本中，成爲極其具備挑戰的事情。

隨後，人們開始提出數據庫管理系統（Database Management System, DBMS）的概念。數據庫的演進抽象來看是人們對 數據結構 和 數據關係 這兩個維度展開的思考和優化。

層次模型和網絡模型（1960）

第一階段的數據庫模型（Database model) 是層次模型（Hierarchical Databases）。

圖 1：一個表達學校結構的層次模型數據庫

層次模型是最先的數據庫模型。隨着早期 IBM 大型機逐漸推廣開來。這個模型相對於文本文件管理數據，是個巨大的提高，但也有不少問題。

問題：

• 儘管能比較好的表達 一對一 ( one to one) 結構，但在 多對多（many to many) 結構上難以表達

  • 如：圖中能較好的表達一個繫有多個老師，但很難表達一個老師可能屬於多個系。

• 層次結構不夠靈活

  • 如：添加一個新的數據庫關係有可能對整個數據庫結構帶來巨大變化，以致於在真正的開發中帶來巨大的工做量
• 查詢數據須要腦海中隨時有最新的結構圖，且須要遍歷樹狀結構作推導

然後在層次模型的基礎之上，人們提出了優化方案，即：網絡模型（Network Model)。

圖 2：網狀模型的數據庫

網絡模型是關係型數據庫出來以前最爲流行的數據庫模型。很好的解決了數據的多對多的問題。但依然存在如下問題：

問題：

• 難以從代碼層面實現和維護
• 查詢數據須要腦海中隨時有最新的結構圖

第二階段：關係型數據庫

模型初期（1970）

關係模型（ Relational Model) 是相對網絡模型的巨大飛躍。在網絡模型中，不一樣類型的數據老是會依賴另外一類數據，如圖 1 中，Teachers 從屬於 Departments，這是層次模型和網絡模型在真實設計和開發中痛苦的根源（由於你老是要在腦海中記錄當前的網絡結構，想象一下一個擁有幾千張表的複雜系統）

關係模型一大創新就是拆掉了表和表之間的連接，將關係只存儲在當前表中的某一個字段中（fields），從而實現不一樣的表之間的相對獨立。以下表：當你只看 Table2 的時候，你就知道 Product_code 會指向一個 產品的具體細節，Table2 和 Table1 在保持相對獨立的同時，又天然而然的鏈接了起來。

圖 3：關係型數據庫
Table2 中的 Product_code 列指向了 Table1 中對應的數據，從而創建 Table2 和 Table1 的關係

1970年，當 E.F.Codd 開發出這個模型時，人們認爲是難以實現的，正如上面的例子通常，當你檢索 Table2 時，遇到 Product_code 列，就須要再去 Table1 遍歷一遍。受限於當時的硬件條件，這種檢索方法老是會讓機器難以負載。但很快，你們質疑的問題，在摩爾定律加持下，已經再也不是問題。你們現在所據說的 IBM DB2, Ingres, Sybase, Oracle, Informix, MySQL 就是誕生在這個時代。

至此數據庫領域誕生了一個大的分類：聯機事務處理 OLTP（on-line transaction processing），代指一類專門用於平常事務的數據庫，如銀行交易用的增刪改查數據庫。後面還會提到另外一類數據庫，專門用於從大量數據中發現決策的輔助數據庫 On-Line Analytical Processing – OLAP（聯機分析處理）數據庫。

數據倉庫（1980s）

隨着關係型數據庫的發展，不一樣業務場景數據化，人們開始有了聚集不一樣業務場景數據，並嘗試進行數據分析並輔助業務決策的想法（Decision Support System)。在此需求之上，誕生了數據倉庫（ Data warehouse）的概念。

以下圖：一個企業每每把不一樣的業務場景數據存在不一樣的數據庫中，在沒有成熟的數據倉庫產品以前，數據分析師每每須要本身作大量的前期準備工做來聚集本身所需的數據。而數據倉庫本質上就是解決數據分析和挖掘的業務場景。

圖 4：數據倉庫

解釋：ETL 是 Extract(提取)，Transform(轉換)，Load（加載）的縮寫。由於數據在不一樣的數據庫或者系統中，可能存在格式不統一，單位不統一等等狀況。須要作一次數據的預處理。

數據倉庫是一個面向主題的、集成的、非易失的、隨時間變化的用來支持管理人員決策數據集合。

OLAP（聯機分析處理）

1980 年代有了數據倉庫的概念和實現後，人們嘗試在此基礎上作數據分析。但分析的過程出現一些新的問題。最明顯的是效率問題。由於以前的關係型數據庫並非爲數據分析而打造。數據分析師想要的是一個支持多維的數據視圖和多維數據操做的引擎。

以下面👇的數據魔方通常，相比於上面提到的關係型數據庫中的二維數據展現和二維數據操做而言。OLAP 數據庫對多個維度的數據能夠快速的組建和操做。

數據魔方
將多個維度的數據組織和展現

數據魔方的多種操做

1993 年，關係型數據庫創始人Edgar F. Codd提出聯機分析處理（OLAP）的概念。本質上是多維數據庫和多維分析能力的概念。目標是知足決策支持或多維環境特定的查詢和報表需求。

第三階段：NoSQL

時間繼續推動，互聯網時代到來之後，數據量的暴增給關係型數據庫也帶來的新的挑戰。最爲明顯的挑戰有如下兩點：

挑戰一：數據列的擴展成本巨高

關係型數據庫由於提早定義了 Table 的字段（Fields），當數據庫已經擁有數以億計條的數據以後，業務場景須要一列新的數據，你驚訝的發現，在關係型數據庫的規則限制下，你必需要同時操做這數以億計的數據愛完成新的一列的添加（否則數據庫會有報錯出現），對生產環境的服務器性能挑戰極大。

能夠想象一下 Facebook，Twitter, Weibo 這樣的社交網站，天天字段都在不斷的變化，來添加各類新的功能。

好比須要添加 status 列，你必需要在某一時刻同時爲數以億計的行，添加 Active 或者 In-Active 內容，不然數據庫會沒法知足合規約束

挑戰二：數據庫性能的挑戰

業務規模不斷上升以後，關係型數據庫的性能問題開始浮出水面，雖然數據庫供應商都提出了各類解決方案，但底層關係綁定式的設計依然是性能天花板的根本緣由。開發人員開始嘗試分庫、分表、加緩存等極限操做來擠出性能。

在此挑戰之上，人們提出了新的數據庫模型 – NoSQL。

針對擴展數據列的問題，NoSQL 提出了新的數據存儲格式，去掉了關係模型的關係性。數據之間無關聯，這樣就換回了架構上的擴展性。

新的數據結構，將相關性數據都放在一塊兒

NoSQL 更底層的創新源自於天生爲集羣可擴展場景所打造。

而在 NoSQL 理論基礎之上，根據企業應用場景又拓展出了四大類型的數據庫：

• 文檔型數據庫（Document-Oriented)：如大名鼎鼎的 MongoDB、CouchDB。文檔泛指一種數據的存儲結構，如 XML、JSON、JSONB 等。
• 鍵值數據庫（Key-Value Database) ：你們所據說的 Redis、Memcached、Riak 都是鍵值對數據庫
• 列式存儲數據庫（Column-Family)：如 Cassandra、HBase
• 圖數據庫（Graph-oriented)：如 Neo4j、OrientDB 等。聚焦在數據間關係鏈的數據組織方式。

隨着企業數據的不斷變大，對數據處理能力也提出了新的要求。平常所聽到的大數據（Big Data）一詞，表明一個龐大的技術體系結構。包括了數據的採集，整理，計算，存儲，分析等環節。數據庫只是其中一環。以下圖，餓了麼2017 年大數據架構，文中所提到的數據庫，基本上只表明了圖中存儲環節。你們平常所聽到的 Hadoop、Kafka、Hive、Spark、Materialize等都是大數據引擎，千萬不要搞混了。

數據庫只是大數據概念中的一部分

第四階段：

隨着雲時代的到來，基於雲環境所打造的雲原生數據庫不斷地開始佔了數據庫市場份額。

雲原生數據庫和託管/自建數據庫最大的區別就是：雲原生數據庫是面向獨立資源的雲化，其CPU、內存、存儲等都可實現獨立的彈性，利用大型雲廠商的海量資源池，最大化其資源利用率，下降成本，同時支持獨立擴展特定資源，知足多種用戶不斷變化的業務需求，實現徹底的Serverless; 而託管數據庫仍是侷限於傳統的服務器架構，各項資源等比率的限制在一個範圍內，其彈性範圍，資源利用率都受到較大的限制，沒法充分利用雲的紅利。

http://mysql.taobao.org/monthly/2020/05/01/

基於雲原生數據庫技術，將來創業團隊無需花費巨大精力來應對海量數據來襲，只需聚焦在業務便可。

雲原生數據庫的表明如：阿里雲的 PolarDB、騰訊雲的 CynosDB、華爲雲的 TaurusDB、亞馬遜雲的 Aurora。

最後，以阿里 CIO 學院的一個數據庫分佈圖結束這篇文章，圖示中的數據庫產品和分佈圖很好的表明了當前數據庫產業的格局。

附錄：

數據庫領域裏有一個不得不提的 CAP 理論，感興趣的能夠閱讀阮一峯的 Blog。

CAP 理論

在近代數據庫領域，有一個 CAP 理論，CAP 分別表明：

• Consistency（數據一致性）
• Availability（數據可用性）
• Partition tolerance（分區容錯）

CAP 理論簡單理解就是分佈式數據庫不可能同時作到一致性、可用性和分區容錯這三個指標。更具體的解釋能夠參考阮一峯的 Blog，寫的很是棒，這裏就不展開。

關係型數據庫庫選擇了一致性和分區容錯，而 NoSQL 爲了適應業務須要，選擇了分區容錯和可用性。