一文讀懂數據庫發展史

• 2022 年 5 月 10 日
• 筆記

本文力求以簡單易懂的語言描述出數據庫發展史，盡量避免出現複雜的概念介紹。數據庫演進史如圖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模型），這種模型常被用來描述、抽象概念數據模型（詳細解釋可閱讀這篇文章//zhuanlan.zhihu.com/p/356216273）。
　　1979年，Oracle誕生，從誕生之日起，Oracle就一直是數據庫領域處於領先的產品。1983年，經過長達十年的開發與測試，IBM發佈了Database2，這標誌着DB2的正式誕生。

　　1985年，為存儲、表達更為複雜的數據結構（例如嵌套表、非結構化數據等），人們提出了面向對象的數據模型，這種模型吸收了層次、網狀和關係數據庫等各類數據模型的特點，並借鑒了面向對象的設計方法。面向對象的數據模型將所有事物都看作是一個對象，每個對象的定義包括狀態和行為兩個方面，其中狀態由一組屬性組成，行為由一組方法組成，具有相同屬性和方法的對象構成一個對象類。（詳細解釋可閱讀這篇文章//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不僅對數據倉庫提出了更精確的定義- 數據倉庫是在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合，而且提出了範式建模的數據倉庫建設方法。儘管後來範式建模受到了維度建模的挑戰（可以詳見這篇文章：
//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（可閱讀
//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

註：

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