摘要：數(shù)據(jù)庫多模是指同一個數(shù)據(jù)庫支持多個存儲引擎，可以同時滿足應(yīng)用程序?qū)τ诮Y(jié)構(gòu)化半結(jié)構(gòu)化非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一管理需求。多模式數(shù)據(jù)管理能力，使得數(shù)據(jù)庫能夠進行跨部門跨業(yè)務(wù)的數(shù)據(jù)統(tǒng)一存儲與管理，實現(xiàn)多業(yè)務(wù)數(shù)據(jù)融合，支撐多樣化的應(yīng)用服務(wù)。

如今，隨著業(yè)務(wù)“互聯(lián)網(wǎng)化”和“智能化”的發(fā)展以及架構(gòu) “微服務(wù)”和“云化”的發(fā)展，應(yīng)用系統(tǒng)對數(shù)據(jù)的存儲管理提出了新的標(biāo)準(zhǔn)和要求，數(shù)據(jù)的多樣性成為了數(shù)據(jù)庫平臺面臨的一大挑戰(zhàn)，數(shù)據(jù)庫領(lǐng)域也催生了一種新的主流方向。

數(shù)據(jù)庫多模Multi-Model是指同一個數(shù)據(jù)庫支持多個存儲引擎，可以同時滿足應(yīng)用程序?qū)τ诮Y(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一管理需求。

1.數(shù)據(jù)庫云化需求催生Multi-Model多模
企業(yè)使用云數(shù)據(jù)庫對接的應(yīng)用越來越多，需求多種多樣，傳統(tǒng)的做法是在dbPaaS里面提供十幾個不同的數(shù)據(jù)庫產(chǎn)品分別應(yīng)對各種需求，這樣的方法在系統(tǒng)增加后，整體維護性和數(shù)據(jù)一致性管理成本很高，會影響到整個系統(tǒng)的使用。

云數(shù)據(jù)庫的“多模”示意圖

為了實現(xiàn)業(yè)務(wù)數(shù)據(jù)的統(tǒng)一管理和數(shù)據(jù)融合，新型數(shù)據(jù)庫需要具備多模式（Multi-Model）數(shù)據(jù)管理和存儲的能力。通常來說，結(jié)構(gòu)化數(shù)據(jù)特指表單類型的數(shù)據(jù)存儲結(jié)構(gòu)，典型應(yīng)用包括銀行核心交易等傳統(tǒng)業(yè)務(wù)； 而半結(jié)構(gòu)化數(shù)據(jù)則在用戶畫像、物聯(lián)網(wǎng)設(shè)備日志采集、應(yīng)用點擊流分析等場景中得到大規(guī)模使用；非結(jié)構(gòu)化數(shù)據(jù)則對應(yīng)著海量的的圖片、視頻、和文檔處理等業(yè)務(wù)，在金融科技的發(fā)展下增長迅速。

多模式數(shù)據(jù)管理能力，使得數(shù)據(jù)庫能夠進行跨部門、跨業(yè)務(wù)的數(shù)據(jù)統(tǒng)一存儲與管理，實現(xiàn)多業(yè)務(wù)數(shù)據(jù)融合，支撐多樣化的應(yīng)用服務(wù)。在架構(gòu)上，多模Multi-model也是針對云數(shù)據(jù)庫需求的，則使得數(shù)據(jù)庫使用一套數(shù)據(jù)管理體系可以支撐多種數(shù)據(jù)類型，因此支持多種業(yè)務(wù)模式，大大降低使用和運維的成本。

2.Multi-Model存儲引擎架構(gòu)
數(shù)據(jù)庫是現(xiàn)有許多業(yè)務(wù)系統(tǒng)的核心。隨著數(shù)據(jù)生成與采集技術(shù)的飛速發(fā)展，數(shù)據(jù)量不斷爆炸式增長，數(shù)據(jù)的結(jié)構(gòu)也越來越靈活多樣。傳統(tǒng)基于關(guān)系型理論構(gòu)建起來的數(shù)據(jù)庫管理系統(tǒng)，面對大數(shù)據(jù)、人工智能的真正到來，在成本、性能、擴展性、容錯能力等方面遭遇到了不小的挑戰(zhàn)。
面對多類型的的結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)，現(xiàn)代應(yīng)用程序?qū)Σ煌臄?shù)據(jù)提出了不同的存儲要求，數(shù)據(jù)庫因此也需要適應(yīng)這種多類型數(shù)據(jù)管理的需求。
比較流行的兩種解決思路分別是：混合持久化（Polyglot Persistence）與多模數(shù)據(jù)庫（Multi-Model Database）。
1）混合持久化 Polyglot Persistence
混合持久化的思路是指，用戶根據(jù)工作的不同需求分別選擇使用合適的數(shù)據(jù)庫，這樣在一個完整的系統(tǒng)中，可能同時運行著多種不同的數(shù)據(jù)庫。

圖1 Polyglot Persistence示意圖
混合持久化一個顯著的優(yōu)點就是單一流程的性能提升，但缺點也同樣的顯而易見：以增加復(fù)雜性和學(xué)習(xí)成本為代價，在部署、使用及維護上帶來了挑戰(zhàn)。

2）多模Multi-Model
Multi-model多模數(shù)據(jù)庫則是另一種解決思路，在同一個數(shù)據(jù)庫內(nèi)有多個數(shù)據(jù)引擎，將各種類型的數(shù)據(jù)進行集中存儲和使用。多個不同類型的應(yīng)用，同時接入一個數(shù)據(jù)庫，并在同一個分布式數(shù)據(jù)庫內(nèi)進行管理，大大簡化應(yīng)用程序的開發(fā)及后期維護成本。

圖2：多模數(shù)據(jù)庫引擎架構(gòu)示意圖

圖為多模Multi-Model數(shù)據(jù)庫的示意圖，我們可以看到在同一個存儲引擎里面同時具備 關(guān)系型數(shù)據(jù)、JSON半結(jié)構(gòu)化數(shù)據(jù)、對象數(shù)據(jù)以及全文檢索引擎等等多個數(shù)據(jù)引擎，統(tǒng)一提供給應(yīng)。這一架構(gòu)大大降低開發(fā)和運維的難度，應(yīng)用統(tǒng)一連接到數(shù)據(jù)庫，數(shù)據(jù)庫內(nèi)部進行數(shù)據(jù)的劃分、隔離和管理，對應(yīng)用來說只需要連接到數(shù)據(jù)庫即可，無需為了每個應(yīng)用搭建對應(yīng)的數(shù)據(jù)后臺。

3.存儲數(shù)據(jù)結(jié)構(gòu)
針對多模數(shù)據(jù)庫的需求，分布式數(shù)據(jù)庫的存儲數(shù)據(jù)結(jié)構(gòu)也會有新的創(chuàng)新。以下就是SequoiaDB在Multi-model方面，進行的數(shù)據(jù)存儲結(jié)構(gòu)和訪問的設(shè)計和實現(xiàn)，可以作為Multimodel數(shù)據(jù)庫的一個很好的參考。

3.1 結(jié)構(gòu)化、半結(jié)構(gòu)化數(shù)據(jù)存儲
結(jié)構(gòu)化數(shù)據(jù)的特點是結(jié)構(gòu)固定，每一行的屬性是相同的，如傳統(tǒng)關(guān)系型數(shù)據(jù)庫表中的數(shù)據(jù)。半結(jié)構(gòu)化數(shù)據(jù)是一種自描述結(jié)構(gòu)，它包含相關(guān)標(biāo)記用來分隔語義元素及對記錄和字段進行分層，如 XML，JSON 等。
存儲結(jié)構(gòu)
如何在數(shù)據(jù)引擎中同時管理結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)呢？SequoiaDB 使用JSON 數(shù)據(jù)模型，在數(shù)據(jù)庫內(nèi)部使用BSON 格式來將結(jié)構(gòu)化及非結(jié)構(gòu)化數(shù)據(jù)以文檔的形式存儲在集合中。
BSON（Binary JSON）是對 JSON 的一種二進制編碼數(shù)據(jù)格式，和 JSON 一樣，BSON支持嵌入式的文檔和數(shù)組。BSON 由若干個鍵值對存儲為單個實體，這種實體稱為文檔。BSON 包含了 JSON 中的數(shù)據(jù)類型，并擴展了一些 JSON 中沒有的數(shù)據(jù)類型，如Date，BinData 等。BSON 結(jié)構(gòu)的一個簡單示例如下圖所示。

圖3： BSON 結(jié)構(gòu)示例
BSON 具有以下幾個特性：輕量級（Lightweight），可遍歷性（Traversable），高效性（Efficient）。由于BSON結(jié)構(gòu)包含足夠的自描述信息，因此它是一種 schema-less 的存儲形式。

SequoiaDB將 BSON作為記錄的存儲結(jié)構(gòu)，由于其良好的靈活性，不需要事先對集合的結(jié)構(gòu)進行定義，每一個記錄中包含的字段信息可以相同，也可以不同，并可隨時進行修改，這樣對結(jié)構(gòu)及半結(jié)構(gòu)化的數(shù)據(jù)都能以一致的方式統(tǒng)一存儲和訪問。

SequoiaDB中的數(shù)據(jù)管理模型如圖4所示。

圖4： SequoiaDB 數(shù)據(jù)管理模型架構(gòu)圖

數(shù)據(jù)最終都是要在磁盤文件中進行持久存儲，與之相關(guān)的三個概念如下：
?文件（File）：磁盤上的物理文件，用于持久存儲集合數(shù)據(jù)、索引及 LOB 數(shù)據(jù)。
?頁（Page）：頁是數(shù)據(jù)庫文件中用于組織數(shù)據(jù)的一種基本結(jié)構(gòu)，SequoiaDB中使用頁來對文件中的空間進行管理與分配。
?數(shù)據(jù)塊（Extent）：由若干個頁組成，用于存放記錄。

在該模型中，與結(jié)構(gòu)/半結(jié)構(gòu)化數(shù)據(jù)存儲相關(guān)的三個核心邏輯概念包括：
?集合空間（Collection Space）：用于存儲集合的對象，物理上對應(yīng)于一組磁盤上的文件。
?集合（Collection）：存放文檔的邏輯對象。
?文檔（Document）：存儲在集合中的記錄，以 BSON 結(jié)構(gòu)存儲。

一個集合會包含若干個 extent，所有這些 extent使用鏈表串聯(lián)起來。當(dāng)向集合中插入文檔時，需要從 extent 中分配空間。如果當(dāng)前 extent 沒有足夠空間，則分配新的 extent（必要時對文件進行擴展），掛到該集合的 extent 鏈表上，然后向其中插入文檔。每個 extent 內(nèi)的記錄也通過鏈表的形式組織起來，這樣在進行表掃描時，可順序讀取塊內(nèi)的所有記錄。

數(shù)據(jù)訪問
1）SQL
當(dāng)前大量基于數(shù)據(jù)庫的應(yīng)用使用 SQL 來進行數(shù)據(jù)庫訪問，因此對的 SQL 支持是數(shù)據(jù)庫必不可少的能力。SequoiaDB支持標(biāo)準(zhǔn) SQL 接口，完全兼容 PostgreSQL 及 MySQL語法和協(xié)議，現(xiàn)有的應(yīng)用可平滑地將存儲系統(tǒng)切換為 SequoiaDB，以獲得分布式存儲系統(tǒng)所帶來的擴展性、性能及可靠性等立面的巨大提升。

2）API
SequoiaDB 在結(jié)構(gòu)化數(shù)據(jù)提供了豐富的 API 接口用于管理整個集群及操作數(shù)據(jù)，提供了各種主流編譯語言的驅(qū)動。

數(shù)據(jù)壓縮
對于JSON/BSON數(shù)據(jù)結(jié)構(gòu)，因為其嵌套結(jié)構(gòu)，在擁有靈活的存儲結(jié)構(gòu)同時，也會造成數(shù)據(jù)的膨脹。JSON數(shù)據(jù)存儲的膨脹問題，也是早期如MongoDB等JSON數(shù)據(jù)庫性能瓶頸的一個重要原因。

SequoiaDB在使用JSON/BSON作為數(shù)據(jù)存儲結(jié)構(gòu)時，為了避免過度的膨脹問題，在數(shù)據(jù)引擎中加入了數(shù)據(jù)壓縮的機制。目前SequoiaDB引擎提供了兩類壓縮方式：行壓縮與表壓縮。行壓縮使用Snappy算法，是一種不需要字典的快速壓縮機制。表壓縮則使用LZW算法，是一種基于字典的壓縮機制。

數(shù)據(jù)壓縮機制，一方面從存儲上節(jié)省空間和成本，另一方面提升單位I/O的效率。在IO吞吐量非常高的查詢場景下，基于數(shù)據(jù)字典的深度壓縮機制能夠大幅降低IO開銷，有效提高查詢效率。

3.2非結(jié)構(gòu)化數(shù)據(jù)存儲
存儲結(jié)構(gòu)
非結(jié)構(gòu)化數(shù)據(jù)即沒有固定結(jié)構(gòu)的數(shù)據(jù)，如文檔、圖片、音頻/視頻等，這種類型的數(shù)據(jù)在現(xiàn)在的很多業(yè)務(wù)中所占的比重越來越大。在SequoiaDB中，使用大對象（LOB，Large Object）來對這種類型的數(shù)據(jù)進行管理。
大對象依附于普通集合存在，當(dāng)用戶上傳一個大對象時，系統(tǒng)為它分配一個唯一的 OID 值，后續(xù)對該大對象的操作可通過該值來進行指定。
大對象在存儲時會進行分片，并使用hash算法將分片分散存儲在相應(yīng)的分區(qū)組中，其哈?？臻g與所屬集合的哈希空間一致。分片大小為 LOB 頁大小，在創(chuàng)建集合空間時指定，默認為 512KB。
為了對 LOB 數(shù)據(jù)進行有效的存儲和管理，SequoiaDB內(nèi)部將 LOB 數(shù)據(jù)抽象為元數(shù)據(jù)和數(shù)據(jù)本身，并使用兩種文件來存儲這些數(shù)據(jù)： LOBM 文件用于存儲 LOB 分片的元數(shù)據(jù)，LOBD 文件用于存儲真正的 LOB 數(shù)據(jù)分片。它們的邏輯結(jié)構(gòu)如下圖所示。

圖5： LOB 文件邏輯結(jié)構(gòu)
其中LOBM 文件主要包括：
?文件頭：包含該文件的一些元數(shù)據(jù)信息。
?空間管理段（SME）：用來標(biāo)記頁的使用情況。
?桶管理段（BME）：hash 值相同的分片所占用的頁以雙向鏈表的形式掛在一個桶上。
?頁：與 LOBD 中的頁一一對應(yīng)，記錄該頁所屬的集合信息，OID及sequence 值等。

LOBD 文件主要包括：
?文件頭：包含該文件的一些元數(shù)據(jù)信息。
?真正的數(shù)據(jù)頁：用于存儲 LOB 分片。LOB 還有一些自身的元數(shù)據(jù)，保存在 sequence 為0的分片中，包括該 LOB 數(shù)據(jù)的大小、創(chuàng)建時間、版本號等。

數(shù)據(jù)訪問
1）寫入LOB
當(dāng)需要寫入 LOB 數(shù)據(jù)時，LOB 數(shù)據(jù)會在協(xié)調(diào)節(jié)點上進行分片，每一個分片分配了一個 sequence 值，它表示這些分片在原始 LOB 數(shù)據(jù)中的順序。因此，LOB 的OID與分片的 sequence 值唯一地標(biāo)識了這個分片。
在存儲一個 LOB 分片時，使用其 OID + sequence 計算 hash 值。先使用集合的分區(qū) hash函數(shù)來計算出該分片要存儲到哪個分區(qū)組上，然后使用 LOB 分片的 hash 函數(shù)來計算出其掛接到哪個桶上，之后在 LOBD 及 LOBM 文件中分配數(shù)據(jù)頁，完成數(shù)據(jù)寫入，LOBM 中的頁掛到對應(yīng)的桶上。

2）讀取LOB
在獲取 LOB 數(shù)據(jù)時，需要指定其 OID值。引擎根據(jù)OID值獲取 sequence 值為0的分片，從中讀出 LOB 的元數(shù)據(jù)信息，然后進行分片計算，確定所有分片信息，向所有包含分片的分區(qū)組發(fā)送請求。
當(dāng)協(xié)調(diào)節(jié)點接收到各級返回的分片數(shù)據(jù)后，按 sequence 的順序?qū)?LOB 數(shù)據(jù)進行合并還原，以獲取完整的 LOB 數(shù)據(jù)。

3）標(biāo)準(zhǔn) Posix文件系統(tǒng)接口
除了LOB的API之外，目前提供SequoiaFS文件系統(tǒng)，它是基于FUSE在Linux系統(tǒng)下實現(xiàn)的一套文件系統(tǒng)，支持通用的文件操作API。SequoiaFS利用SequoiaDB的集合存儲文件和目錄的屬性信息，LOB對象存儲文件的數(shù)據(jù)內(nèi)容，從而實現(xiàn)了類似NFS分布式網(wǎng)絡(luò)文件系統(tǒng)。用戶可以將遠程SequoiaDB的某個集合通過映射的方式掛載到本地節(jié)點，從而在掛載節(jié)點的目標(biāo)目錄下可以通過通用文件系統(tǒng)API對文件和目錄進行操作。

4.小結(jié)
根據(jù)Gartner的報告，Multi-Model多模是數(shù)據(jù)庫領(lǐng)域近年興起的一個主要的技術(shù)方向之一，其代表了在云化架構(gòu)下，多類型數(shù)據(jù)管理的一種新理念，也是簡化運維、節(jié)省開發(fā)成本的一個新選擇。
SequoiaDB的Multi-Model數(shù)據(jù)庫產(chǎn)品，目前已經(jīng)在許多行業(yè)的到了應(yīng)用，這也證明市場正在慢慢接受這一新的數(shù)據(jù)庫架構(gòu)。我們也看到MySQL，PostgreSQL等數(shù)據(jù)庫也在開始支持JSON等多類型格式，也在朝著Multi-model的方向發(fā)展。未來相信各產(chǎn)品也會持續(xù)保持創(chuàng)新，出現(xiàn)更多Multi-model的數(shù)據(jù)庫產(chǎn)品。