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

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

一、前言

企業內容管理（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接口進行詳細描述。

5.1 命令行

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

5.2 C++

sdbclient::sdbCollection類：

表2：sdbCollection類中LOB相關函數

sdbclient::sdbLob類：

表3：sdbLob類中的相關函數

樣例代碼可以參考安裝目錄下samples/CPP/lob.cpp文件。

5.3 Java

com.sequoiadb.base.DBCollection類：

表4：DBCollection類中LOB相關函數

com.sequoiadb.base.DBLob類：

表5：DBLob類中的相關函數

樣例代碼可以參考安裝目錄下samples/Java/com/sequoiadb/samples/Lob.java文件。

5.4 CM API

表6：CM API中的相關函數

六、性能指標

6.1 系統配置

本文測試使用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，其中紅色部分代表該分區的主節點，黑色為從節點。

表7：數據節點分布

6.2 寫操作測試

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

表8：DIO模式

表9：文件系統模式

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

圖4：寫操作吞吐量對比

6.3 讀操作測試

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

表10：DIO模式

表11：文件系統模式

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

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

圖5：讀操作吞吐量對比

七、結論

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

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

作者簡介：巨杉王濤，SequoiaDB巨杉數據庫創始人兼CTO。

 

來自：http://geek.csdn.net/news/detail/96176

 

Save