如果從大學學習數據庫管理系統算起，跟數據庫結緣已經超過 20 年了。回顧過去的職業生涯，走上數據庫這條不歸路也是一個小小的偶然：第一份工作在分小組的時候被分到了 Oracle，就此開始了與數據庫的不解之緣。

[[436440]]

關于數據庫已經有太多太多的內容，這里不敢講什么學術理論，只是想把自己對數據庫的理解做一個梳理，希望能夠幫助那些對數據庫感興趣的朋友們更好地理解數據庫這個既古老又充滿生機的玩意兒。

什么是數據庫

數據庫就是英文的「database」翻譯來的，data + base，顧名思義就是數據的根源，數據的基礎。那么為什么要有數據庫呢?數據庫首先是個計算機軟件，在所謂數據庫誕生之前，常用方法可能是程序員自己寫一個小程序來完成數據處理分析這樣的工作。

隨著計算機的普及，越來越多的場景開始使用計算機，產生了越來越多的數據，也催生了越來越多的數據分析需求。為了降低數據分析的門檻，讓更多人能夠更方便高效地管理分析數據，工程師們就打造了一種專門的軟件來幫助人們對數據進行合理的存儲以提高存取效率，提供易用的接口和豐富的分析算法以方便使用，集成有效的管理工具以提高數據安全性等等，這就是數據庫，也被稱為數據庫管理系統(DBMS，Database management system)。

數據庫是一整套數據管理體系，包括數據存儲的模型、數據組織的架構、數據分析的算法、數據管理的工具以及數據訪問的接口等等。

舉個例子，糧倉。如果你有一畝三分地，產的糧食剛剛夠一家人吃，吃不完的自己找個缸就放下了，這個缸也只需要方便自己家人使用就行了。隨著你種的地越來越多，比如一萬畝地，生產的糧食根本吃不完，那就必須修建一個專門用來存放糧食的倉庫，同時還要方便不同的商家來拉糧食，為了保證糧食存放的安全和效率，就必須對糧倉進行特殊的設計和處理，比如恒溫恒濕、自動噴淋、傳送系統等等。數據庫也是類似的道理。

數據庫起源于阿波羅登月計劃，因為當時需要大量的數據分析人員對大量的數據進行分析，就不得不開發一款能夠方便更多人使用的數據管理分析軟件。這確實是人類當時的燈塔，不得不給 NASA 的工程師們點個贊。

數據庫的核心功能是什么

數據庫根據應用場景的不同而分為不同的類別，比如最經典的分類 OLTP(在線事務處理)和 OLAP(聯機分析處理)。舉個例子，你每天要使用信用卡支付來坐地鐵、買午餐、買飲料、上淘寶購物等等，這每一筆交易都需要后臺數據庫準確地記錄下來，這個數據庫就是 OLTP 類型。

你也會通過系統去查詢你上個月的消費情況，系統會根據你上個月的交易數據做個匯總發給你，并告訴你吃飯花了多少、交通花了多少、娛樂花了多少等等，支持這個場景的就是 OLAP 類型。

OLTP 主要處理短小的事務，要求事務吞吐量很高，因為每個人每天可能要支付十幾次，但每次需要處理的數據量比較小;而 OLAP，每個人可能每個月只用一次，但是每次要處理的數據量相對比較大，而且計算比較復雜。

近年來，伴隨著人工智能、物聯網、邊緣計算等數字化場景的興起，數據庫的功能也產生了更多的分類，如 HTAP(同時能夠處理 OLTP 和 OLAP 的場景)、流式數據處理、時序數據處理、非結構化數據處理、跨平臺數據處理、多模態數據處理等等。如何理解這些分類呢?

類似于不同功能的汽車，有貨車、有客車、有 MPV、有 SUV、有皮卡、有燃油車、有新能源車等等。車的核心功能是一致的，只是為了適應不同的場景和需求，不同的車會有不同的架構設計和調參，如此而已。

那么，數據庫應該有哪些核心功能呢?

首先，數據庫、數據庫，必須要把數據保存下來。要把數據按照合理的格式，安全保存在可持久化的存儲介質里面，要保證數據的正確性、完整性和安全性。這是所有數據系統最核心的功能。換句話說，把數據交給數據庫，數據庫要保證數據不丟、不錯。這個是最最起碼的要求。正如糧倉，不能糧食存進去都發霉了，被耗子吃了。

其次，數據庫要盡可能提高數據存取效率。要用更有效率的方式存儲數據，讓數據存儲得更快，更易于使用者理解，更方便上層業務的使用。查詢數據時效率更高，更快給出結果。就像有人來送糧食入庫，要快速地稱重、烘干、質檢、打包、入庫，不能讓人家等一禮拜。有人要買小麥，有人要買玉米，必須按照要求快速找到相應的存放地點把糧食交給糧商。

再次，數據庫要提供豐富的數據分析算法，盡可能把跟數據密切相關的計算在數據庫中完成，減少數據傳輸的開銷，減輕上層業務邏輯的計算壓力。就像糧庫要提供完善的糧食處理措施，比如稱重、烘干、打包、品質分級等，方便糧食交易。

最后，數據庫要提供易于使用的接口，降低數據分析人員的使用門檻，能夠支持各種數據分析工具，讓使用數據更加方便。就像糧庫要有方便的停車場、清晰的指示牌、專業友好的工作人員等。

數據庫的核心組件有哪些

為了實現這些核心功能，通常數據庫會包括以下核心組件：

a. 存儲管理

數據用什么樣的方式來組織、存儲，是 key-value 還是關系型，是按行存還是按列存，支不支持壓縮，支不支持刪除和修改，支持什么樣的數據類型和存儲接口，POSIX 還是對象存儲。是否要支持計算存儲分離，是否要支持分布式存儲，是否支持事物處理，是否支持多副本，采用什么算法來加速數據的檢索(索引)等等。存儲管理是數據庫的核心組件，解決了存儲管理問題，數據庫的問題就解決了一半了。 

b. 查詢優化器

要提高數據查詢的效率，數據庫必須找到一條最優化的執行路徑，比如，查詢時是否需要使用索引，如果有多個索引，應該選擇哪一個，如果數據分布在不同的存儲單元(表、集合等)里，應該按照什么順序來訪問效率最高等等。優化器面對的問題可能是一個極其復雜的路徑規劃問題，它需要在很短的時間里計算出最優路徑，需要大量核心優化算法，屬于數據庫中復雜程度最高的部分。

舉個例子，你要帶著全家人，包括老人、小孩一起從上海去海南旅行，要制作一個性價比最好、家人滿意度最高的計劃，那么在計劃時需要考慮哪些因素呢?首先，怎么去，是開車去，還是火車去，還是飛機去。開車，路上要花多久，中間需要休息幾次，你和太太有沒有時間，老人孩子是不是受得了，汽油費用，過路費用;飛機，怎么去機場，行李有多少，帶不帶得下，機票有沒有打折，下了飛機怎么辦等等。住什么酒店，去什么景點，老人喜歡去人多的人文景觀，太太喜歡安靜的地方和方便購物的地方，小孩喜歡有游樂場的地方，要不要酒店 + 景點一起訂，會不會有優惠，要不要租車，租什么車......說到這里，是不是可以體會一個查詢優化器需要考慮的問題有多少? 

 

當然，這部分工作可以有相對簡單的實現(基于規則)，比如太太說了，時間確定、飛機來回、五星酒店、帶私人沙灘，這樣計劃就會簡單很多。然而，這份工作也可能復雜到難以想象(基于機器學習、基于實際開銷等等)，比如太太說你全權負責，具體時間不確定，大概在 8月 - 9月，要少花錢多辦事，多做調研，找一個最優方案。那么做這個計劃就會非常復雜，需要的支持決策信息就會非常多。這樣做出來的決策大概率相對會優化，比基于規則實現的計劃能適應更多場景。

c. 執行模塊

優化器做好了執行計劃后，接下來就會有執行的模塊按照執行計劃對數據進行相關的計算，包括數據的存取、常規的加減乘除、排序、平均值、哈希，也會包括一些機器學習的算法，數據的壓縮/解壓縮，最后將計算完成的結果返回給客戶端。 

 

d. 內部管理和調度

數據庫要正常地工作，還會需要一些內部協調管理的模塊，比如內存和存儲同步，存儲空間整理，元數據管理，集群狀態檢測，容錯和故障恢復等。

e. 管理工具和接口

為了提高易用性，數據庫都需要提供一套管理工具，比如備份/恢復、狀態檢測、運行時監控、資源隔離、權限管理、安全審計、自定義接口、各種數據訪問接口等。

數據庫的發展和展望

數據庫的發展是伴隨著計算機體系架構的發展而不斷演進的，從主機，到個人電腦 + 網絡(x86)，到現在的云服務，數據庫也經歷了一系列的演化歷程。 

 

a. 主機時代

最初的計算機和數據庫只是在航空航天、軍事領域使用，只需要支持專業的數據分析人員進行數據分析。到了上世紀 70 年代末，伴隨著計算機進入更多商業場景，大量數據分析的需求產生了，數據庫則需要面對更為普遍的用戶需求。在 IBM 最早發布的關系型數據庫的論文中，最強調的一點就是希望能夠讓數據庫的用戶不用再去操心數據應該如何存儲和組織，而能夠高效率使用這些數據進行分析。

為了方便用戶的使用，SQL(結構化查詢語言)被定義了出來，按照這樣的語法，數據庫用戶只需要關注數據該如何分析，不需要關注底層的數據分布和存儲等。

為了要支持大量用戶的并發數據操作，數據庫事務特性被定義了出來，保證在并發的數據操作下，用戶能夠看到符合業務邏輯的數據內容。

為了保證數據庫的高效率和安全性，數據庫重做日志(事務日志)被設計出來，包括當前數據庫中經常出現的一系列概念，比如回滾日志(undo log)、提交日志(commit log)、檢查點(checkpoint)等等。

主機時代的硬件成本極其昂貴，不論是存儲、內存還是CPU資源，相對來說都很稀缺。那么，數據庫在設計和使用上就會采用各種算法和架構來降低對內存的使用，減少數據的冗余，提高數據的檢索效率。因此，各種數據索引類型，功能強大的查詢優化器，數據緩存算法等在數據庫中得到了極大的發展。同時在使用數據庫時，也要對數據進行各種復雜的模型設計(三范式模型、星型模型、雪花型模型等等)以降低數據的冗余程度，當然，這樣也會增加數據庫應用的開發難度。

b. x86 時代

伴隨著 x86 服務器的廣泛使用和網絡技術的發展，把 N 臺 x86 服務器通過網絡組建成一個集群，利用這個集群的計算、存儲能力來取代昂貴的主機也就更加具有性價比。在這種趨勢下，也就設計出了各種能夠使用集群能力的分布式數據庫系統，這些系統的核心思想就是把數據分散在不同的節點上，利用多個節點的計算和存儲資源提高對數據的存儲和分析能力。在分布式的處理架構下，數據一致性協議、多副本機制、高可用機制、數據分片機制、擴容/縮容機制等等也都成為了分布式數據庫必須要設計和解決的問題。

在 x86 時代，由于硬件成本的大幅下降，用戶更多關注數據分析的靈活性和交付的效率。因此，使用數據庫時更多會關注如何加快數據分析的過程、如何讓數據更易于人類理解，而不需要為了降低數據的冗余而進行復雜的模型構建。

c. 云時代

隨著技術的進一步發展，通過把傳統硬件虛擬化/容器化等技術，提高硬件資源的使用效率，降低生產運維成本的云服務被越來越多企業采用。為了更好地適應云服務的技術體系，數據庫也設計出了相關的云特性，比如存儲計算分離、彈性伸縮、微服務化、跨域數據同步等等。

云時代，用戶更加關注數據分析的效率和投入產出比，更加關注產品是否能夠提供便利的一體化數據處理服務，讓業務開發者能夠更加專注于業務本身，而數據庫服務也在朝著標準化云服務的方向不斷演進。

d. 展望

不同的數據庫架構和部署方式不是一個簡單的迭代和取代的關系，而是在很長一段時間里會同時存在并且逐步迭代的過程。時至今日，依然有不少金融機構會選擇使用在主機上的數據庫產品，只是新的業務和場景非常有限。而基于 x86 服務器的數據處理產品，還是當前企業數據庫的主流選擇。與此同時，云數據庫的市場份額也在逐步增長和擴大。采用何種數據庫產品要根據自身的業務需求來決定，合適的就是最好的。當然從技術演進的方向上看，云技術(包括公有云和私有云)會是大勢所趨，因為云能夠提供更高的效率。

數據庫作為信息產業的三大基礎技術(還有芯片和操作系統)之一，在相當長的時間里，不論從資本還是技術方面都非常火熱，國內近幾年來也出現了相當多優秀的數據庫產品和企業。在人類邁向數字化文明的進程中，必定會產生越來越多的數據，也需要從數據中挖掘出更多的價值，而數據庫作為承載數據的核心，也必將持續發揮重要作用。有幸一直在從事這個領域的工作，期待與廣大同仁一道為人類數字化技術的進步貢獻力量。