摘要：圖元數(shù)據(jù)與數(shù)據(jù)文件結(jié)構(gòu)映射在建立集合的過(guò)程當(dāng)中，大對(duì)象存儲(chǔ)必須依附于普通集合存在，一個(gè)集合中的大對(duì)象僅歸屬于該集合，不能被另外一個(gè)集合管理。

企業(yè)內(nèi)容管理（Enterprise Content Management，ECM）系統(tǒng)是一種管理非結(jié)構(gòu)化內(nèi)容的系統(tǒng)，傳統(tǒng)代表為EMC Documentum或IBM Filenet等ECM解決方案。隨著大數(shù)據(jù)技術(shù)的越發(fā)普及，越來(lái)越多的客戶開(kāi)始嘗試把存放在傳統(tǒng)ECM系統(tǒng)中的文件、圖片、影像等內(nèi)容向開(kāi)放分布式平臺(tái)遷移。一般來(lái)說(shuō)，用戶可以選擇的方案根據(jù)場(chǎng)景與數(shù)據(jù)類型來(lái)看可以分為幾類，包括HDFS方案、對(duì)象存儲(chǔ)方案、NAS方案、以及分布式數(shù)據(jù)庫(kù)方案等。

其中，HDFS方案主要面向數(shù)據(jù)歸檔，對(duì)大量打成大包的文件直接存放，一般不提供在線讀寫(xiě)功能，主要的目的是替代磁帶。

而NAS方案則類似HDFS，使用獨(dú)立第三方傳統(tǒng)數(shù)據(jù)庫(kù)作為元數(shù)據(jù)管理系統(tǒng)，同時(shí)使用外接NAS設(shè)備存放中小型文件。一般來(lái)說(shuō)，NAS作為文件系統(tǒng)可以支持較多數(shù)量的小文件，但是當(dāng)小文件數(shù)量達(dá)到億級(jí)時(shí)同樣會(huì)產(chǎn)生管理、訪問(wèn)性能與擴(kuò)展性等一系列問(wèn)題。

對(duì)象存儲(chǔ)則以S3等接口為通用標(biāo)準(zhǔn)，設(shè)備提供商可以在底層使用K/V存儲(chǔ)或塊存儲(chǔ)等不同存儲(chǔ)機(jī)制，同時(shí)提供類似對(duì)象訪問(wèn)、版本管理等一系列功能特性。

最后，分布式數(shù)據(jù)庫(kù)方案則使用分布式數(shù)據(jù)庫(kù)中的大對(duì)象機(jī)制，將元數(shù)據(jù)與大對(duì)象統(tǒng)一存放在數(shù)據(jù)庫(kù)中，在支持批次管理、版本管理、流程管理等元數(shù)據(jù)管理特性時(shí)不需要借助額外第三方數(shù)據(jù)庫(kù)進(jìn)行支持。

SequoiaDB（巨杉數(shù)據(jù)庫(kù)）是一款新一代分布式文檔類數(shù)據(jù)庫(kù)，同時(shí)支持事務(wù)與標(biāo)準(zhǔn)SQL的結(jié)構(gòu)化數(shù)據(jù)訪問(wèn)方式。在同類開(kāi)源分布式數(shù)據(jù)庫(kù)中，SequoiaDB是唯一一款原生集成行存儲(chǔ)與塊存儲(chǔ)雙引擎的數(shù)據(jù)庫(kù)。除了JSON存儲(chǔ)引擎以外，為了提高非結(jié)構(gòu)化文件的讀寫(xiě)性能，SequoiaDB核心引擎提供了分布式塊存儲(chǔ)模式，可以將非結(jié)構(gòu)化大文件按照固定大小的數(shù)據(jù)塊進(jìn)行切分并存放于不同分區(qū)。當(dāng)用戶需要管理海量的小文件（例如照片、音視頻、文檔、圖片等）時(shí)，SequoiaDB的雙存儲(chǔ)引擎特性能夠幫助用戶快速搭建一個(gè)高性能、高可用的內(nèi)容管理與影像平臺(tái)系統(tǒng)。使用SequoiaDB搭建的影像平臺(tái)系統(tǒng)架構(gòu)相對(duì)簡(jiǎn)單，元數(shù)據(jù)與內(nèi)容數(shù)據(jù)均可使用SequoiaDB服務(wù)器的本地磁盤(pán)存放，不再需要額外購(gòu)買(mǎi)昂貴的外部存儲(chǔ)設(shè)備，節(jié)省企業(yè)的開(kāi)發(fā)和運(yùn)維成本。

SequoiaDB的塊存儲(chǔ)字段類型叫做LOB（Large OBject，大對(duì)象），其核心機(jī)制是將內(nèi)容文件打散成多個(gè)數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊被分別發(fā)送到不同分區(qū)獨(dú)立存放。與其他解決方案相比，由于不存在獨(dú)立中控元數(shù)據(jù)節(jié)點(diǎn)，SequoiaDB提供的LOB存儲(chǔ)機(jī)制理論上可以存放近乎無(wú)限數(shù)量的對(duì)象文件，并且不會(huì)由于元數(shù)據(jù)堆積而造成性能下降。同時(shí)，由于數(shù)據(jù)塊被散列分布到所有數(shù)據(jù)節(jié)點(diǎn)，整個(gè)系統(tǒng)的吞吐量隨集群磁盤(pán)數(shù)量的增加近乎線性提升。最后，SequoiaDB提供原生的內(nèi)容管理接口，通過(guò)REST訪問(wèn)方式支持批次管理、版本管理、流程管理等一系列基本CM特性。

從使用方式上看，SequoiaDB的LOB機(jī)制可以使用原生API的訪問(wèn)形式，對(duì)底層LOB對(duì)象進(jìn)行讀寫(xiě)訪問(wèn)；同時(shí)，用戶也可以通過(guò)高階CM API Java接口，Java驅(qū)動(dòng)會(huì)將請(qǐng)求封裝成RESTful形式，通過(guò)發(fā)送接收HTTP報(bào)文進(jìn)行對(duì)象和批次級(jí)別讀寫(xiě)更新操作。

SequoiaDB的LOB存儲(chǔ)結(jié)構(gòu)分為元數(shù)據(jù)文件（lobm）與數(shù)據(jù)文件（lobd）。其中，元數(shù)據(jù)文件存儲(chǔ)整個(gè)LOB數(shù)據(jù)文件的元數(shù)據(jù)模型，包括每個(gè)頁(yè)的空閑狀況、散列桶、以及數(shù)據(jù)映射表等一系列數(shù)據(jù)結(jié)構(gòu)。而數(shù)據(jù)文件則存儲(chǔ)用戶真實(shí)數(shù)據(jù)，數(shù)據(jù)頭之后所有數(shù)據(jù)頁(yè)按照page size進(jìn)行切分，每個(gè)數(shù)據(jù)頁(yè)不包含任何元數(shù)據(jù)信息。

圖1：LOB元數(shù)據(jù)與數(shù)據(jù)文件結(jié)構(gòu)映射

在建立集合的過(guò)程當(dāng)中，大對(duì)象存儲(chǔ)必須依附于普通集合存在，一個(gè)集合中的大對(duì)象僅歸屬于該集合，不能被另外一個(gè)集合管理。

當(dāng)用戶上傳一個(gè)大對(duì)象時(shí)，會(huì)經(jīng)歷幾次散列操作。

首先，協(xié)調(diào)節(jié)點(diǎn)或客戶端會(huì)生成（或者用戶指定）一個(gè)全局唯一的描述符，同時(shí)將傳入的數(shù)據(jù)按照用戶指定的pagesize大小切片，最后針對(duì)每一個(gè)切片按照（描述符+切片id）進(jìn)行散列，用于決定該切片存在哪個(gè)數(shù)據(jù)分區(qū)中。注意，集合的分區(qū)鍵設(shè)定并不作用于大對(duì)象。

在每個(gè)分區(qū)中，當(dāng)接收到數(shù)據(jù)分片后會(huì)根據(jù)（描述符+切片id）進(jìn)行再一次散列，決定元數(shù)據(jù)桶的位置。而真實(shí)數(shù)據(jù)則通過(guò)查找元數(shù)據(jù)信息，在數(shù)據(jù)文件中找到一個(gè)最近的空閑頁(yè)寫(xiě)入，然后將該頁(yè)的ID寫(xiě)入元數(shù)據(jù)桶中，代表該桶指向這個(gè)數(shù)據(jù)頁(yè)。如果散列后數(shù)據(jù)桶已經(jīng)被占用，則使用常規(guī)散列沖突的解決方式找到下一個(gè)空閑桶。

當(dāng)用戶讀取大對(duì)象時(shí)，協(xié)調(diào)節(jié)點(diǎn)按照其（描述符+偏移+長(zhǎng)度）計(jì)算出需要讀取多少個(gè)切片，以及每個(gè)切片所在的數(shù)據(jù)分區(qū)，最后將數(shù)據(jù)節(jié)點(diǎn)返回的數(shù)據(jù)按順序排列返回客戶端。

由于SequoiaDB將文件切片存儲(chǔ)，一個(gè)大文件可能存在有非常多個(gè)分片，所以在訪問(wèn)的時(shí)候協(xié)調(diào)節(jié)點(diǎn)還需要進(jìn)行請(qǐng)求合并，盡可能使用最小的報(bào)文一次性請(qǐng)求多個(gè)連續(xù)的數(shù)據(jù)頁(yè)，以防止訪問(wèn)一個(gè)對(duì)象時(shí)協(xié)調(diào)節(jié)點(diǎn)需要向數(shù)據(jù)節(jié)點(diǎn)發(fā)送成千上萬(wàn)的此類請(qǐng)求，同時(shí)對(duì)數(shù)據(jù)節(jié)點(diǎn)做到I/O合并，一次性讀入盡可能多的連續(xù)頁(yè)面。

隨著網(wǎng)絡(luò)技術(shù)的漸漸普及，越來(lái)越多的銀行開(kāi)始將傳統(tǒng)渠道向互聯(lián)網(wǎng)與移動(dòng)端靠攏。隨之而來(lái)的，是更多監(jiān)管業(yè)務(wù)的需要，例如針對(duì)遠(yuǎn)程開(kāi)戶等業(yè)務(wù)，銀行需要開(kāi)始提供“雙錄”能力，對(duì)用戶的音頻與視頻數(shù)據(jù)進(jìn)行存儲(chǔ)。傳統(tǒng)EMC、IBM提供的企業(yè)內(nèi)容管理系統(tǒng)以小機(jī)加高端存儲(chǔ)硬件為基礎(chǔ)，對(duì)于僅存票據(jù)證照等相對(duì)小量的圖片存儲(chǔ)還可以勉強(qiáng)滿足需要，但是當(dāng)存儲(chǔ)類型擴(kuò)展到音視頻等領(lǐng)域性能并不出色，同時(shí)開(kāi)銷(xiāo)還會(huì)指數(shù)級(jí)增加。
SequoiaDB提供的分布式、雙引擎以及對(duì)象存儲(chǔ)的功能，天然為海量的音視頻、影像、證照等內(nèi)容提供了分布式存儲(chǔ)的能力。SequoiaDB可以使用高存儲(chǔ)密度的PC服務(wù)器替代傳統(tǒng)的小機(jī)加高端存儲(chǔ)的配置，能夠使用戶以1/5的擁有成本，提供更多的存儲(chǔ)空間與更高的吞吐能力。

圖2：基于SequoiaDB的新一代企業(yè)內(nèi)容管理平臺(tái)與舊平臺(tái)的對(duì)比

在SequoiaDB內(nèi)容管理解決方案中，數(shù)據(jù)庫(kù)除了提供基本的記錄與文件的讀寫(xiě)操作外，還提供了內(nèi)容管理平臺(tái)的批次管理、版本管理、流程控制等一系列后臺(tái)管控能力，為與用戶中間件對(duì)接提供了最大便利。

圖3：SequoiaDB內(nèi)容管理平臺(tái)架構(gòu)圖

SequoiaDB提供基于shell的命令行界面，以及C、C++、Java、Python、PHP、Nodejs等驅(qū)動(dòng)訪問(wèn)原生LOB API。同時(shí)，SequoiaDB提供訪問(wèn)協(xié)議的CM API Java接口。本文將會(huì)就命令行、C++、Java以及CM API接口進(jìn)行詳細(xì)描述。

表1：命令行操作指令

樣例：

> db.foo.bar.putLob("/opt/sequoiadb/standalone/diaglog/sdbdiag.log")
579f55b7389d2aef0a000000
Takes 0.166125s.
> db.foo.bar.listLobs()
{
  "Size": 29342,
  "Oid": {
    "$oid": "579f55b7389d2aef0a000000"
  },
  "CreateTime": {
    "$timestamp": "2016-08-01-21.59.19.939000"
  },
  "Available": true
}
Return 1 row(s).
Takes 0.6703s.
> db.foo.bar.getLob("579f55b7389d2aef0a000000", "/opt/sequoiadb/standalone/test.log")
{
  "LobSize": 29342,
  "CreateTime": {
    "$timestamp": "2016-08-01-21.59.19.939000"
  }
}
Takes 0.910s.

本文測(cè)試使用3臺(tái)物理機(jī)作為服務(wù)器與1臺(tái)物理機(jī)作為客戶端。客戶端使用C程序與服務(wù)端直連，使用LOB API進(jìn)行讀寫(xiě)訪問(wèn)操作。

CPU:Intel? Xeon? CPU E5-2420 0 @1.90GHZ(6core *2) (一臺(tái)物理機(jī))
CPU:Intel? Xeon? CPU E5-2620 V2@ 2.10GHZ (6core *2) （二臺(tái)物理機(jī)）
MEMORY:48
DISK: 2T/6塊

CPU:Intel? Xeon? CPU E5-2420 0 @1.90GHZ(6core *2) (一臺(tái)物理機(jī))
MEMORY:48
DISK: 2T/6塊

集群部署方式為6分區(qū)3副本，三臺(tái)機(jī)器構(gòu)成高可用集群，網(wǎng)絡(luò)為千兆網(wǎng)，協(xié)調(diào)節(jié)點(diǎn)與編目節(jié)點(diǎn)分別部署在3臺(tái)服務(wù)器上。數(shù)據(jù)節(jié)點(diǎn)分布見(jiàn)表3，其中紅色部分代表該分區(qū)的主節(jié)點(diǎn)，黑色為從節(jié)點(diǎn)。

文件系統(tǒng)的配置分別使用兩種方式：打開(kāi)DIO以及用普通文件系統(tǒng)緩存方式。

表8：DIO模式

表9：文件系統(tǒng)模式

可以看到，打開(kāi)DIO與普通文件系統(tǒng)緩存相比，性能確實(shí)存在一定下降。在三臺(tái)服務(wù)器的情況下，尺寸較小的文件在DIO打開(kāi)的情況下顯示出與普通文件系統(tǒng)緩存更大的差異。當(dāng)文件尺寸平均達(dá)到1-2MB左右后，使用DIO與普通文件系統(tǒng)的差異幾乎可以忽略不計(jì)。圖1顯示了啟用與關(guān)閉DIO的情況下，在800線程并發(fā)中整個(gè)集群的吞吐量（MB/s）。

不同于寫(xiě)操作，SequoiaDB LOB機(jī)制在讀操作中受DIO的影響較小。

在文件讀取的過(guò)程當(dāng)中，因?yàn)榻^大部分讀取都是順序I/O，因此是否打開(kāi)文件系統(tǒng)緩存基本對(duì)性能不構(gòu)成影響。從性能讀數(shù)可以看出，SequoiaDB LOB讀取時(shí)每次讀取的緩存大小對(duì)于讀取性能基本上不構(gòu)成太大的影響。

測(cè)試中吞吐量上限基本達(dá)到客戶端千兆網(wǎng)瓶頸，因此通過(guò)增加網(wǎng)絡(luò)帶寬依然有可以提升的空間。

SequoiaDB的大對(duì)象機(jī)制主要為用戶存儲(chǔ)海量中小型文件所設(shè)計(jì)。通過(guò)配置pagesize大小，SequoiaDB在存儲(chǔ)100KB到100MB區(qū)間內(nèi)的文件性能與磁盤(pán)開(kāi)銷(xiāo)比例最優(yōu)，因此針對(duì)各個(gè)企業(yè)的票據(jù)、掃描件、合同件、照片、小視頻、音頻等文件最為適用。

總體來(lái)看，使用SequoiaDB替代傳統(tǒng)ECM，為企業(yè)存儲(chǔ)海量中小型文件不單能夠大大降低企業(yè)的總體擁有成本，還能夠大幅度提升數(shù)據(jù)訪問(wèn)層面的吞吐量，并從開(kāi)發(fā)、運(yùn)維、管理等各個(gè)層面大幅度降低使用難度，幫助企業(yè)更快地在企業(yè)內(nèi)容管理系統(tǒng)上落地。