本文力求以簡單易懂的語言描述出資料庫發展史，儘量避免出現複雜的概念介紹。資料庫演進史如圖1所示：

圖1 資料庫演進

一、穿孔紙帶和檔案系統

　　在現代意義的資料庫出現之前(20世紀60年代)，人們通過人工和檔案系統的方式來儲存、管理資料。在人工管理時期，人們常使用穿孔紙帶來管理資料（圖2），雖然穿孔紙帶因不具備電子化特徵、不能被稱為資料庫，但其代表著人們在資料儲存結構上思考和實踐的結果，有必要單獨提及。

圖2 穿孔紙帶

　　隨著資料量的增多以及計算機技術、儲存技術的快速發展，穿孔紙帶這一紙質儲存媒介很快就被磁碟、磁鼓（圖3）等磁性儲存裝置所取代。在軟體方面，作業系統中也出現了專門管理資料的軟體，被稱為檔案系統（例如我們電腦裡的C,D,E盤）。

　　檔案系統可以說是最早的資料庫了，作業系統提供的檔案管理方法使得程式可以通過檔名來訪問檔案中的資料，不必再尋找資料的物理位置。相比較手工處理的方式，檔案系統使得管理資料變得簡單一些，使用者不需要再翻來覆去地查詢檔案的位置，但是檔案內的資料仍然沒有組織起來，程式設計師需要在腦海中嘗試構造出資料與資料的關係，再編寫程式碼才能從檔案中提取關鍵資料。除過資料結構和資料關係不完整的問題外，此時的資料只面向某個應用或者某個程式，資料的共享性也有著一定的問題。

圖3 磁鼓（長12英寸，每節可儲存不到10k資料）

　　隨著資料量的增長以及企業對資料共享的要求越來越高，人們開始提出資料庫管理系統（Database Management System, DBMS）的概念，對資料模型展開了更深層次的思考。

二、資料模型

　　通俗地講資料模型就是對現實世界的模擬，是對現實世界資料特徵的抽象。這個抽象的過程並不是一蹴而就的，事物的抽象存在多個層次，需要用到不同的模型來進行描述。在前輩們的不斷探索中，資料模型被劃分為三個層次，第一個層次為概念模型（又稱資訊模型）；第二層次為邏輯模型；第三層次為物理模型。

　　概念模型中就是從現實世界中抽取出事物、事物特徵、事物間的聯絡等資訊，並通過概念精確地加以描述。在這個層次進行資料建模時，有一些概念必須要知道，分別是實體、屬性和聯絡。在現實世界中客觀存在的事物或事件被稱為實體，例如一隻羊，一名學生，一張單據，甚至一份“用餐記錄”等。實體具有的某方面特性叫做屬性，例如學生的屬性有姓名、年齡等。現實世界中事物彼此的聯絡在概念模型中反映為實體之間的聯絡。聯絡有以下幾種（圖4）

圖4 實體間聯絡

邏輯模型是按照計算機系統的觀點對資料進行建模，用於DBMS的實現。而物理模型則用於描述資料在磁碟或系統中的表示方式和存取方法。

三、層次模型與網路模型

　　通用電氣的工程師CharlesW.Bachman領導開發了全球第一個資料庫管理系統-網狀資料庫管理系統（IDS），並於1964年正式推出。IDS採用網狀結構，很好地模擬了現實世界中事物間的多種聯絡。

網狀結構有多種表現形式（圖5）

圖5 網狀結構表現形式舉例

為便於讀者理解，舉一個例子加以說明

圖6 教務系統網狀結構

　　同時期為解決“阿波羅登月”計劃處理龐大資料量的需求，北美航空公司(NAA)開發出 GUAM(Generalized Update Access Method)軟體。其設計思想是將多個小元件構成較大元件，最終組成完整產品。這是一種倒置樹的結構，也被稱之為層次結構，層次結構僅能表示一對多的關係。隨後IBM加入NAA，將 GUAM 發展成為 IMS(Information Management System)系統併發佈於1968年。

為便於讀者理解，舉一個例子加以說明（圖7、8）。

圖7 “系-教研室/學生教職工”層次資料庫模型

圖8 “系-教研室/學生教職工”層次資料庫模型的一個值

　　相比較於檔案系統來說，層次資料庫和網狀資料庫實現了資料和程式的分離，但是缺乏理論基礎，而且也不方便使用。原因在於使用者在查詢一個數據時，總要先在腦海中構建出當前的層次結構或網路結構，接著才能按照從屬關係編碼再查詢。若在一個系統中有上千個實體的話，這就是人力所不能及的了。

四、關係模型的發展及完善

　　1970年， IBM 實驗室的Edgar Frank Codd 發表了一篇題為《大型共享資料庫資料的關係模型》論文，提出基於集合論和謂詞邏輯的關係模型，為關係型資料庫技術奠定了理論基礎。關係模型最大的創新點是拆掉了表與表之間的聯絡，將這種關係只儲存在表中的一個欄位中，從而實現了表與表之間的獨立（圖9）。

圖9 “系-教研室/學生教職工”關係資料庫模型

　　若採用關係結構對上述的“系-教研室/學生-教職工”進行建模，建成的模型將會成為這樣。例如在提取教研室的資料時，碰到系編號這個欄位，就會自然而然地連線到系的具體資料中。

　　當時Codd提出這個模型後，受限於當時的硬體條件，這個模型遭到了很多批評，人們認為這種模型是難以實現的。正如上述這個例子，當在檢索教研室這個表的資料時，碰到系編號這個欄位時就需要再去遍歷一遍這張表的資料，這種提取資料的方式讓當時的機器難以承受。但是在摩爾定律的加持下，這些問題迎刃而解，這種建立在嚴格數學概念上的關係模型很快就得到了學術界和工業界的青睞。

　　從資料關係理論到架構一個真實的關係資料庫系統之間還有很長的一段路要走，在這個過程中，有很多公司、學者都貢獻出了自己的成果，共同推動著資料庫領域的發展。1973年，IBM啟動了驗證關係型資料庫系統的專案System R，同年伯克利大學的Michael Stonebraker等人啟動了關係資料的研究專案 Ingres（interactive graphics andretrieval system）。

　　1974 年，Ingres 誕生，為後續大量基於其原始碼開發的PostgreSQL、Sybase、Informix 、Tandem和Sql Server等著名產品打下堅實基礎。1976年，P.P.Chen提出了實體-聯絡模型（簡稱E-R模型），這種模型常被用來描述、抽象概念資料模型（詳細解釋可閱讀這篇文章https://zhuanlan.zhihu.com/p/356216273）。
　　1979年，Oracle誕生，從誕生之日起，Oracle就一直是資料庫領域處於領先的產品。1983年，經過長達十年的開發與測試，IBM釋出了Database2，這標誌著DB2的正式誕生。

　　1985年，為儲存、表達更為複雜的資料結構（例如巢狀表、非結構化資料等），人們提出了面向物件的資料模型，這種模型吸收了層次、網狀和關係資料庫等各類資料模型的特點，並借鑑了面向物件的設計方法。面向物件的資料模型將所有事物都看作是一個物件，每個物件的定義包括狀態和行為兩個方面，其中狀態由一組屬性組成，行為由一組方法組成，具有相同屬性和方法的物件構成一個物件類。（詳細解釋可閱讀這篇文章https://blog.51cto.com/nu1l/2834178）

　　雖然面向物件的資料模型很早就被提出來了，但是真正結果還得等到20多年之後，在當時來說，仍然還是關係型資料庫的天下。1986 年，美國國家標準局(ANSI)資料庫委員會批准SQL作為資料庫語言的美國標準並公佈標準 SQL 文字。1987 年，國際標準化組織(ISO)也做出了同樣決定，對 SQL 進行標準化規範並不斷更新，使得 SQL 成為關係型資料庫的主流語言。此後相當長的一段時間內，不論是微機、小型機還是大型機，不論是哪種資料庫系統，都採用SQL 作為資料存取語言，各個公司紛紛推出各自支援SQL的軟體或介面。

　　1988年SQL Server誕生。微軟、Sybase等公司合作，在Sybase的基礎上生產出了在OS/2作業系統上使用的SQL Server 1.0。各大公司在關係資料庫管理系統(RDBMS)的實現和產品開發中，都遇到了一系列技術問題，主要是在資料庫的規模愈來愈大，資料庫的結構愈來愈複雜，又有愈來愈多的使用者共享資料庫的情況下，如何保障資料的完整性(Integrity)、安全性(Security)、並行性(Concurrency)，以及一旦出現故障後，資料庫如何實現從故障中恢復(Recovery)。這些問題如果不能圓滿解決，無論哪個公司的資料庫產品都無法進入實用階段，最終不能被使用者所接受。

　　在當時爭論紛繁的資料庫學術大戰中，Jim Gray將資料庫研究轉向底層，同時思考各種資料庫都面臨的併發和故障恢復等基本問題。最終，Jim Gray理清了事務的基本概念以及開創性的提出了目前資料庫事務處理機制的基礎ACID屬性，並且給出來許多具體的實現機制，他的研究成果反映在他發表的一系列論文和研究報告之中，最後結晶為一部厚厚的專著《Transaction Processing：Concepts andTechniques》。這不僅為資料庫事務處理的發展奠定了夯實的基礎，而且確保了現今電子化的商業和金融系統的可靠執行。

事務處理

五、資料庫能力的拓展

　　隨著關係型資料庫的發展以及不同業務場景的數字化，人們逐漸產生通過資料監控業務發展，並通過資料分析來輔助業務發展的想法。在此想法之上，1988年，資料倉庫的概念被正式提出。資料倉庫是一個面向主題的、整合的、非易失的、隨時間變化的用來支援管理人員決策的資料集合。

　　單從概念來說，很難理解資料倉庫究竟是一個什麼東西。舉個例子，一個企業不同業務的資料存放在不同的資料庫中，若沒有資料倉庫這個產品，資料分析師或業務分析人員就必須從各個業務資料庫中拉取自己所需要的資料，而各個資料庫的命名規則、存取規則、格式可能都各不相同，這就造成業務分析人員必須做大量工作來整理自己所需要的資料，而且這一結果不能被複用，需要做大量重複的工作。資料倉庫就解決了這些問題。

　　儘管當時的人們已經有了資料倉庫的概念，但是對於資料倉庫的實現方式，一直爭論不休。直到1991年Bill Inmon出版了《Buildingthe Data Warehouse》（建立資料倉庫）這本書，資料倉庫實現方法的爭論才告一段落。在這本書中，Inmon不僅對資料倉庫提出了更精確的定義- 資料倉庫是在企業管理和決策中面向主題的、整合的、與時間相關的、不可修改的資料集合，而且提出了正規化建模的資料倉庫建設方法。儘管後來正規化建模受到了維度建模的挑戰（可以詳見這篇文章：
https://segmentfault.com/a/1190000006255954），但因Inmon的巨大影響力，他被尊稱為“資料倉庫之父”。

構建資料倉庫

　　在有了資料倉庫概念和具體實現方法後，人們嘗試在此基礎上做資料分析，但在分析過程中，人們發現使用關係資料庫對多維資料進行分析時效率非常低。原因在於關係資料庫並不是專為資料分析而打造的，要想提升分析效率，人們還需要一個支援多維資料的處理引擎。1993年，關係型資料庫創始人Edgar F. Codd提出聯機分析處理（OLAP）的概念，目標是為了滿足決策支援、報表展示以及多維資料查詢的需求。

六、開源成果湧現

　　到目前為止，資料庫只覆蓋了少數業務領域，資料庫使用者侷限在大型商超、金融機構、學術研究機構等業務機構中。且當時的資料庫也被IBM、Oracle等公司壟斷著，資料庫仍然是一個比較小眾的軟體。但在同一時期網際網路開始進入了尋常百姓家，網際網路行業迎來了快速發展，湧現出了大量的網頁、網站和網際網路公司。人們需要資料庫來儲存網頁的相關資料，但當時的商業資料庫又太貴或者因查詢效能不足而無法滿足人們的需求，Stonebraker等人的努力在此時開枝散葉，由於他將Ingres的原始碼公佈在網上，教會了很多人如何架構資料庫，從而在一定程度上促進了當時資料庫開源運動的興起，其中最著名的兩個成果就是1996年釋出的MySQL和PostgreSQL。

PostgreSQL與MySQL

七、NoSQL（Not Only SQL）時代

　　而隨著網際網路和移動網際網路的蓬勃發展，接入網際網路的使用者逐漸增多，使用者的需求越來越多以及資料的不斷提升，傳統單機關係型資料庫已經無法滿足人們的需求了。人們在資料庫領域開始尋求新的出路，其中有兩個值得提起的分支，一個分支是探索多種資料模型和儲存介質的資料庫，早期比較有影響力的專案是Memcached，這個專案採用了鍵值模型來建立資料模型；另外一個分支就是分散式資料庫，人們希望用多臺機器形成叢集來儲存、處理資料，其中最具影響力和代表性的事件是Google於2003年至2006年釋出的三篇論文，分別是Google File System、Google Big table和Google MapReduce，奠定了分散式資料系統基礎。

三駕馬車

　　由於傳統基於集中式資料庫在應對海量資料及複雜分析處理時，存在資料庫的橫向擴充套件能力受限、資料儲存和計算能力受限、不能滿足業務瞬時高峰的效能等根本性的架構問題。利用分散式計算和記憶體計算等新技術設計的分散式資料庫能夠解決上述遇到的效能不足等問題。分散式資料庫的資料分散在網路上多個互聯的節點上，資料量、寫入讀取的負載均衡分散到多個單機中，叢集中某個節點故障時整個叢集仍然能繼續工作，資料通過分片、複製、分割槽等方式實現分佈儲存。

　　2007年，Hbase誕生，其理論基礎正是Google在2006年所提出的Big table。它是以分散式儲存作為基礎的資料庫，底層儲存基於分散式檔案系統具備了分片或者分割槽儲存的能力，擴大了普通儲存裝置的儲存系統的上限。同年Amazon發表了Dynamo論文，這篇論文第一次在非關係型資料庫領域引入了資料庫的底層特性，奠定了後續NoSQL資料庫領域的部分基礎特性。

　　2008年9 月，美國《自然》（Nature）雜誌專刊——The next google,第一次正式提出“大資料”概念。這個概念的真正意義在於，資料被認為是人類認知世界的一種新型方法，人們可以通過資料來了解、探索、觀察、研究世界。

　　關係型資料庫不能較好地處理高併發讀寫、多結構化資料儲存等情景。為應對這一問題，資料庫供應商和開源社群都提出了各種解決方案，例如通過分庫、分表、加快取等方式來提升效能，但底層的關係設計仍然是效能天花板的根本原因。此時NoSQL資料庫應運而生，它擴充套件了諸多資料模型，在不同場景下使用不同的資料模型來進行處理。其代表成果是2009推出的文件資料庫Mongdb、2010年推出的鍵值資料庫Redis和2010年推出的圖資料庫Neo4j。這類NoSQL資料庫極大地擴充套件了人們儲存、使用資料的方式。

八、NewSQL時代

　　這種NoSQL資料庫雖然解決了高併發讀寫、多結構化資料儲存等問題，但其設計思路是犧牲事務處理、一致性以及犧牲SQL換來的。而SQL、事務的重要性讓人們開始反思怎麼樣才能在解決前述問題的基礎上保留SQL和事務的能力。Google 於2012年釋出了Spanner的論文，這篇文章創新性地提出了TrueTime的概念，它在第一代 NoSQL 系統的基礎之上引入了 SQL 和分散式事務，保證了強一致性。（也正是這篇論文，宣佈了NoSQL時代的結束，資料庫發展來到了NewSQL的階段）

　　這篇文章在工業界和學術界都有著巨大的反響，截止2022年4月，對其開源實現最好的產品是於2015年誕生的CockroachDB和TiDB（可閱讀
https://www.zhihu.com/question/60686555/answer/1531192635）。和Spanner及它的追隨者不同的是，Amazon在面對這一問題時，選擇了完全不同的路徑，Amazon 釋出的Aurora 是一個儲存計算分離的系統，執行在公有云之上，它的設計思想很巧妙，它把儲存與計算分離使得可以非常簡單得實現儲存能力的可擴充套件。並於2017年在SIGMOD上發表了《Amazon Aurora: Design Considerations for High Throughput Cloud-NativeRelational Databases》這篇論文，披露了Aurora的一些技術實現細節。

九、未來展望

　　大資料時代，資料量不斷爆炸式增長，資料儲存結構也越來越靈活多樣，日益變革的新興業務需求催生資料庫及應用系統的存在形式愈發豐富，這些變化均對資料庫的各類能力不斷提出挑戰，推動資料庫的不斷演進。總的來說可能會有四個方向，第一個方向是垂直領域的資料庫，例如工業資料庫、財經資料庫等。

　　截止目前為止，資料庫都是“通才“，企圖囊括所有領域，而並非深耕某一垂直領域。第二個方向是分散式資料庫，通過“分散式”解決水平擴充套件性與容災高可用兩個問題，並且有融合OLAP的潛力。第三個方向是雲原生資料庫，雲原生資料庫能夠隨時隨地從前端訪問，提供雲服務的計算節點，並且能夠靈活及時調動資源進行擴容，助力企業降本增效。以亞馬遜AWS、阿里雲、Snowflake等為代表的企業，開創了雲原生資料庫時代。第四個方向是資料安全領域，在如今這樣一個什麼都可以量化的年代，資料是很多企業的生命線，而第三方服務商並非真正中立，誰願意自己的命根被掌握在別人手裡呢？在未來，隱私計算和區塊鏈技術可能會幫助資料庫發展得更好，共同解決資料安全的問題。

參考文獻：

[1]中國資訊通訊研究院，資料庫發展研究報告（2021 年）

[2]Spanner: Google’s Globally-DistributedDatabase

[3]Amazon Aurora: Design Considerations for High Throughput Cloud-NativeRelational Databases

[4]中國人民大學資訊學院，資料庫系統概論

[5]Google File System、Google Bigtable 和 Google MapReduce

[6]吳鶴齡.關係資料庫的標準語言——SQL[J].計算機研究與發展,1989(06):7

注：

歡迎轉載，但請在文章末尾或文章開頭註明來源