本文力求以簡單易懂的語言描述出資料庫發展史，儘量避免出現複雜的概念介紹。資料庫演進史如圖1所示： 圖1 資料庫演進 一、穿孔紙帶和文件系統 在現代意義的資料庫出現之前(20世紀60年代)，人們通過人工和文件系統的方式來存儲、管理數據。在人工管理時期，人們常使用穿孔紙帶來管理數據（圖2），雖然穿孔紙帶 ...
本文力求以簡單易懂的語言描述出資料庫發展史，儘量避免出現複雜的概念介紹。資料庫演進史如圖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
註：
歡迎轉載，但請在文章末尾或文章開頭註明來源
