一文解析資料庫的三生三世

編者薦語： 上世紀 60 年代，第一款企業級資料庫產品誕生；六十多年來，資料庫領域不斷迭代更新；在資料規模爆炸性增長、資料型別愈發豐富的今天，新型資料庫全面興起，標準化雲服務成為趨勢。 讓我們站在歷史的角度，重新認識資料庫的「前世今生」。

如果從大學學習資料庫管理系統算起，跟資料庫結緣已經超過 20 年了。回顧過去的職業生涯，走上資料庫這條不歸路也是一個小小的偶然：第一份工作在分小組的時候被分到了 Oracle，就此開始了與資料庫的不解之緣。 關於資料庫已經有太多太多的內容，這裡不敢講什麼學術理論，只是想把自己對資料庫的理解做一個梳理，希望能夠幫助那些對資料庫感興趣的朋友們更好地理解資料庫這個既古老又充滿生機的玩意兒。

什麼是資料庫

資料庫就是英文的「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 伺服器的資料處理產品，還是當前企業資料庫的主流選擇。與此同時，雲資料庫的市場份額也在逐步增長和擴大。採用何種資料庫產品要根據自身的業務需求來決定，合適的就是最好的。當然從技術演進的方向上看，雲技術（包括公有云和私有云）會是大勢所趨，因為雲能夠提供更高的效率。

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

---

Zilliz 以重新定義資料科學為願景，致力於打造一家全球領先的開源技術創新公司，並通過開源和雲原生解決方案為企業解鎖非結構化資料的隱藏價值。 Zilliz 構建了 Milvus 向量資料庫，以加快下一代資料平臺的發展。 Milvus 資料庫是 LF AI & Data 基金會的畢業專案，能夠管理大量非結構化資料集，在新葯發現、推薦系統、聊天機器人等方面具有廣泛的應用。