本文作者：程式碼家，資深開發者，熱衷於開源社群，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; 而託管資料庫還是侷限於傳統的伺服器架構，各項資源等比率的限制在一個範圍內，其彈性範圍，資源利用率都受到較大的限制，無法充分利用雲的紅利。
基於雲原生資料庫技術，未來創業團隊無需花費巨大精力來應對海量資料來襲，只需聚焦在業務即可。
雲原生資料庫的代表如：阿里雲的 PolarDB、騰訊雲的 CynosDB、華為雲的 TaurusDB、亞馬遜雲的 Aurora。
最後，以阿里 CIO 學院的一個資料庫分佈圖結束這篇文章，圖示中的資料庫產品和分佈圖很好的代表了當前資料庫產業的格局。
附錄：
資料庫領域裡有一個不得不提的 CAP 理論，感興趣的可以閱讀阮一峰的 Blog。
CAP 理論
在近代資料庫領域，有一個 CAP 理論，CAP 分別代表：
- Consistency（資料一致性）
- Availability（資料可用性）
- Partition tolerance（分割槽容錯）
CAP 理論簡單理解就是分散式資料庫不可能同時做到一致性、可用性和分割槽容錯這三個指標。更具體的解釋可以參考阮一峰的 Blog，寫的非常棒，這裡就不展開。
關係型資料庫庫選擇了一致性和分割槽容錯，而 NoSQL 為了適應業務需要，選擇了分割槽容錯和可用性。