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

企業(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ā)普及，越來越多的客戶開始嘗試把存放在傳統(tǒng)ECM系統(tǒng)中的文件、圖片、影像等內(nèi)容向開放分布式平臺遷移。一般來說，用戶可以選擇的方案根據(jù)場景與數(shù)據(jù)類型來看可以分為幾類，包括HDFS方案、對象存儲方案、NAS方案、以及分布式數(shù)據(jù)庫方案等。

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

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

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

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

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

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

從使用方式上看，SequoiaDB的LOB機制可以使用原生API的訪問形式，對底層LOB對象進行讀寫訪問；同時，用戶也可以通過高階CM API Java接口，Java驅(qū)動會將請求封裝成RESTful形式，通過發(fā)送接收HTTP報文進行對象和批次級別讀寫更新操作。

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

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

在建立集合的過程當中，大對象存儲必須依附于普通集合存在，一個集合中的大對象僅歸屬于該集合，不能被另外一個集合管理。

當用戶上傳一個大對象時，會經(jīng)歷幾次散列操作。

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

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

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

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

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

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

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

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

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

表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.

本文測試使用3臺物理機作為服務(wù)器與1臺物理機作為客戶端。客戶端使用C程序與服務(wù)端直連，使用LOB API進行讀寫訪問操作。

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

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

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

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

表8：DIO模式

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

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

不同于寫操作，SequoiaDB LOB機制在讀操作中受DIO的影響較小。

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

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

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

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