NewSQL數據庫大對象塊存儲原理與應用

前言

企業內容管理（Enterprise Content Management，ECM）系統是一種管理非結構化內容的系統，傳統表明爲EMC Documentum或IBM Filenet等ECM解決方案。隨着大數據技術的愈加普及，愈來愈多的客戶開始嘗試把存放在傳統ECM系統中的文件、圖片、影像等內容向開放分佈式平臺遷移。通常來講，用戶能夠選擇的方案根據場景與數據類型來看能夠分爲幾類，包括HDFS方案、對象存儲方案、NAS方案、以及分佈式數據庫方案等。

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

而NAS方案則相似HDFS，使用獨立第三方傳統數據庫做爲元數據管理系統，同時使用外接NAS設備存放中小型文件。通常來講，NAS做爲文件系統能夠支持較多數量的小文件，可是當小文件數量達到億級時一樣會產生管理、訪問性能與擴展性等一系列問題。

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

最後，分佈式數據庫方案則使用分佈式數據庫中的大對象機制，將元數據與大對象統一存放在數據庫中，在支持批次管理、版本管理、流程管理等元數據管理特性時不須要藉助額外第三方數據庫進行支持。

功能概述

SequoiaDB（巨杉數據庫）是一款新一代分佈式文檔類數據庫，同時支持事務與標準SQL的結構化數據訪問方式。在同類開源分佈式數據庫中，SequoiaDB是惟一一款原生集成行存儲與塊存儲雙引擎的數據庫。除了JSON存儲引擎之外，爲了提升非結構化文件的讀寫性能，SequoiaDB核心引擎提供了分佈式塊存儲模式，能夠將非結構化大文件按照固定大小的數據塊進行切分並存放於不一樣分區。當用戶須要管理海量的小文件（例如照片、音視頻、文檔、圖片等）時，SequoiaDB的雙存儲引擎特性可以幫助用戶快速搭建一個高性能、高可用的內容管理與影像平臺系統。使用SequoiaDB搭建的影像平臺系統架構相對簡單，元數據與內容數據都可使用SequoiaDB服務器的本地磁盤存放，再也不須要額外購買昂貴的外部存儲設備，節省企業的開發和運維成本。

SequoiaDB的塊存儲字段類型叫作LOB（Large OBject，大對象），其核心機制是將內容文件打散成多個數據塊，每一個數據塊被分別發送到不一樣分區獨立存放。與其餘解決方案相比，因爲不存在獨立中控元數據節點，SequoiaDB提供的LOB存儲機制理論上能夠存放近乎無限數量的對象文件，而且不會因爲元數據堆積而形成性能降低。同時，因爲數據塊被散列分佈到全部數據節點，整個系統的吞吐量隨集羣磁盤數量的增長近乎線性提高。最後，SequoiaDB提供原生的內容管理接口，經過REST訪問方式支持批次管理、版本管理、流程管理等一系列基本CM特性。

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

架構

SequoiaDB的LOB存儲結構分爲元數據文件（lobm）與數據文件（lobd）。其中，元數據文件存儲整個LOB數據文件的元數據模型，包括每一個頁的空閒情況、散列桶、以及數據映射表等一系列數據結構。而數據文件則存儲用戶真實數據，數據頭以後全部數據頁按照page size進行切分，每一個數據頁不包含任何元數據信息。

圖1：LOB元數據與數據文件結構映射

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

當用戶上傳一個大對象時，會經歷幾回散列操做。

首先，協調節點或客戶端會生成（或者用戶指定）一個全局惟一的描述符，同時將傳入的數據按照用戶指定的pagesize大小切片，最後針對每個切片按照（描述符+切片id）進行散列，用於決定該切片存在哪一個數據分區中。注意，集合的分區鍵設定並不做用於大對象。

在每一個分區中，當接收到數據分片後會根據（描述符+切片id）進行再一次散列，決定元數據桶的位置。而真實數據則經過查找元數據信息，在數據文件中找到一個最近的空閒頁寫入，而後將該頁的ID寫入元數據桶中，表明該桶指向這個數據頁。若是散列後數據桶已經被佔用，則使用常規散列衝突的解決方式找到下一個空閒桶。

當用戶讀取大對象時，協調節點按照其（描述符+偏移+長度）計算出須要讀取多少個切片，以及每一個切片所在的數據分區，最後將數據節點返回的數據按順序排列返回客戶端。

因爲SequoiaDB將文件切片存儲，一個大文件可能存在有很是多個分片，因此在訪問的時候協調節點還須要進行請求合併，儘量使用最小的報文一次性請求多個連續的數據頁，以防止訪問一個對象時協調節點須要向數據節點發送成千上萬的此類請求，同時對數據節點作到I/O合併，一次性讀入儘量多的連續頁面。

行業應用案例

企業內容管理平臺

隨着網絡技術的漸漸普及，愈來愈多的銀行開始將傳統渠道向互聯網與移動端靠攏。隨之而來的，是更多監管業務的須要，例如針對遠程開戶等業務，銀行須要開始提供「雙錄」能力，對用戶的音頻與視頻數據進行存儲。傳統EMC、IBM提供的企業內容管理系統以小機加高端存儲硬件爲基礎，對於僅存票據證照等相對小量的圖片存儲還能夠勉強知足須要，可是當存儲類型擴展到音視頻等領域性能並不出色，同時開銷還會指數級增長。
SequoiaDB提供的分佈式、雙引擎以及對象存儲的功能，自然爲海量的音視頻、影像、證照等內容提供了分佈式存儲的能力。SequoiaDB可使用高存儲密度的PC服務器替代傳統的小機加高端存儲的配置，可以使用戶以1/5的擁有成本，提供更多的存儲空間與更高的吞吐能力。

圖2：基於SequoiaDB的新一代企業內容管理平臺與舊平臺的對比

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

圖3：SequoiaDB內容管理平臺架構圖

操做指南

SequoiaDB提供基於shell的命令行界面，以及C、C++、Java、Python、PHP、Nodejs等驅動訪問原生LOB API。同時，SequoiaDB提供訪問協議的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.

C++

Java

CM API

性能指標

系統配置

本文測試使用3臺物理機做爲服務器與1臺物理機做爲客戶端。客戶端使用C程序與服務端直連，使用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分區3副本，三臺機器構成高可用集羣，網絡爲千兆網，協調節點與編目節點分別部署在3臺服務器上。數據節點分佈見表3，其中紅色部分表明該分區的主節點，黑色爲從節點。

寫操做測試

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

表8：DIO模式

表9：文件系統模式

能夠看到，打開DIO與普通文件系統緩存相比，性能確實存在必定降低。在三臺服務器的狀況下，尺寸較小的文件在DIO打開的狀況下顯示出與普通文件系統緩存更大的差別。當文件尺寸平均達到1-2MB左右後，使用DIO與普通文件系統的差別幾乎能夠忽略不計。圖1顯示了啓用與關閉DIO的狀況下，在800線程併發中整個集羣的吞吐量（MB/s）。

讀操做測試

不一樣於寫操做，SequoiaDB LOB機制在讀操做中受DIO的影響較小。

在文件讀取的過程中，由於絕大部分讀取都是順序I/O，所以是否打開文件系統緩存基本對性能不構成影響。從性能讀數能夠看出，SequoiaDB LOB讀取時每次讀取的緩存大小對於讀取性能基本上不構成太大的影響。

測試中吞吐量上限基本達到客戶端千兆網瓶頸，所以經過增長網絡帶寬依然有能夠提高的空間。

結論

SequoiaDB的大對象機制主要爲用戶存儲海量中小型文件所設計。經過配置pagesize大小，SequoiaDB在存儲100KB到100MB區間內的文件性能與磁盤開銷比例最優，所以針對各個企業的票據、掃描件、合同件、照片、小視頻、音頻等文件最爲適用。

整體來看，使用SequoiaDB替代傳統ECM，爲企業存儲海量中小型文件不單可以大大下降企業的整體擁有成本，還可以大幅度提高數據訪問層面的吞吐量，並從開發、運維、管理等各個層面大幅度下降使用難度，幫助企業更快地在企業內容管理系統上落地。