NoSQL性能測試白皮書
編者按
最近，bankmark公司針對目前市面上流行的NoSQ數據庫SequoiaDB、Cassandra、MongoDB進行了詳細的
性能測試，InfoQ經授權發佈中文版白皮書。
正文
1.簡介
作爲一項快速發展的極具創新性的IT技術，NoSQL 技術在大數據和實時網頁應用中的運用在最近幾年呈現了大量的增長。因爲NoSQL數據庫的存儲允許更靈活的開發方式和執行方式，這些NoSQL數據庫能夠在許多的工商業應用領域很好地替代傳統關係型
數據庫（RDBMS）。因爲弱化了RDBMS的一些特徵，如一致性和關係型數據模型，NoSQL技術大大提高了數據庫的可擴展能力和可用性。
在這份報告中，bankmark針對一系列的基準測試實驗做了報告，這些測試是爲了對比SequoiaDB和現在市面上的其他一些NoSQL產品在不同的負載情境下的性能表現。因此，bankmark的測試團隊使用了 Yahoo Cloud Serving Benchmark（YCSB）方案作爲測試的工具。bankmark團隊針對所有的系統使用了可能出現的所有配置方案，最終選擇了哪些造成了較大的性能瓶頸的配置方案，在此過程中，我們參考了所有這些數據庫的官方文檔，和其他所有公開的技術資料。所有的主要方案我們都會在報告中詳細記錄，一份完全詳細的報告還會包括所有的配置細節。
現在的這一份報告，bankmark着重於每款數據庫在不同的用例下的性能表現，同時也保證了不同結果間的最大可比性。這些大量測試的一個目的之一就是得到這些產品最真實的性能表現。另一方面，分佈式的測試環境需要一定的優化來滿足數據庫集羣環境運行的需要。所有的被測試系統都按照集羣的需求來進行配置，其中還有一些針對分區操作進行的優化，以滿足結果的可比較性。
所有的測試都由bankmark團隊完成，所有重要的細節包括物理環境、測試配置信息等都在測試報告中有詳細的記錄，我們還將一份詳細版本的報告，這份報告將能確保我們進行的實驗都是可重複的。
2.測試結果概述
在我們的測試中，對三款數據庫產品進行了比較，SequoiaDB[1]、Cassandra[2]以及 MongoDB[3]。所有的產品都在一個10節點集羣的「全內存環境」（原始數據大小爲總RAM大小的1/4）或是「大部分內存環境」（原始數據大小爲總RAM大小的1/2）的環境下進行安裝測試。我們選用業界廣泛使用的YCSB工具作爲基準性能測試的平臺。在所有測試中，所有的數據都進行3次複製備份，以應對容錯操作。複製測試則使用了傾斜負載（Zipfian或是最新的分發版）。詳細的配置將在下面展示，也會在之後的詳細版報告中記錄。
所有測試的結果沒有顯示出三款之中一個完全的最優者。
我們的「大部分內存環境」下的測試顯示Cassandra 使用了最多的內存，因此也需要在多讀少寫負載的情況下，進行更多的磁盤I/O操作，這也導致了其嚴重的性能下降。在「大部分內存環境」的設定下，SequoiaDB的性能在大多數情境下都大大優於其他的產品，除了在Cassandra的強項多寫少讀負載。
在「全內存環境」（原始數據大小爲總RAM大小的1/4）下，SequoiaDB在讀請求下表現更好，而Cassandra在寫請求下表現稍好。MongoDB則幾乎在所有的測試情境下都墊底。
3.硬件和軟件配置
這一個部分，我們將介紹這次測試中我們所使用的軟件和硬件環境。這次的測試是在SequoiaDB的實驗室中一個集羣上進行的，所有的測試都在物理硬件上進行，沒有使用任何虛擬化的層級。基本系統的搭建以及MongoDB和SequoiaDB的基本安裝操作都是由訓練有素的專業人員進行的。bankmark有着完全的訪問集羣和查看配置信息的權限。Cassandra則由bankmark來進行安裝。
3.1集羣硬件
所有的數據庫測試都在一個10節點的集羣上進行（5臺 Dell PowerEdge R520 服務器，5臺Dell PowerEdge R720 服務器），另外還有5臺HP ProLiant BL465c刀片機作爲YCSB客戶端。詳細硬件信息如下：
3.1.1 5x Dell PowerEdge R520 (server)
1x Intel Xeon E5-2420, 6 cores/12 threads, 1.9 GHz
47 GB RAM
6x 2 TB HDD, JBOD
3.1.2 5x Dell PowerEdge R720 (server)
1x Intel Xeon E5-2620, 6 cores/12 threads, 2.0 GHz
47 GB RAM
6x 2 TB HDD, JBOD
3.1.3 5x HP ProLiant BL465c (clients)
1x AMD Opteron 2378
4 GB RAM
300 GB logical HDD on a HP Smart Array E200i Controller, RAID 0
3.2集羣軟件
集羣以上述的硬件爲物理系統，而其中則配置了不同的軟件。所有的軟件實用信息以及對應的軟件版本信息如下：
3.2.1 Dell PowerEdge R520 and R720 (used as server)
操作系統（OS）: Red Hat Enterprise Linux Server 6.4
架構（Architecture）: x86_64
內核（Kernel）: 2.6.32
Apache Cassandra: 2.1.2
MongoDB: 2.6.5
SequoiaDB: 1.8
YCSB: 0.1.4 master (brianfrankcooper version at Github) with bankmark changes (see 4.1)
3.2.2 HP ProLiant BL465c (used as client)
操作系統（OS）: SUSE Linux Enterprise Server 11
架構（Architecture）: x86_64
內核（Kernel）: 3.0.13
YCSB: 0.1.4 master (brianfrankcooper version at Github) with bankmark changes (see 4.1)
4.安裝過程
三款數據庫系統使用YCSB進行基準測試，分別是Apache Cassandra、MongoDB 以及 SequoiaDB。下來這一部分，分別介紹了這三者如何安裝。集羣上運行的數據庫系統使用3組副本以及3組不同的磁盤。壓縮性能的比較只在帶有此功能的系統上進行。
4.1集羣內核參數
下面的配置參數爲三款數據庫系統共同使用：
vm.swappiness = 0
vm.dirty_ratio = 100
vm.dirty_background_ratio = 40
vm.dirty_expire_centisecs = 3000
vm.vfs_cache_pressure = 200
vm.min_free_kbytes = 3949963
4.2 APACHE CASSANDRA
Apache Cassandra在所有服務器上都按照官方文檔[4]進行安裝，其配置也按照推薦的產品配置[5] 進行。提交的日誌和數據在不同的磁盤進行存儲（disk1 存儲提交的日誌，disk5和disk6 存儲數據）。
4.3 MONGODB
MongoDB由專業的工作人員安裝。爲了使用三個數據磁盤以及在集羣上運行復制組，我們根據官方文檔有關集羣安裝的介紹[6]，使用了一套複雜的方案。3個集羣點上都啓動了配置服務器。在十臺服務器上，每臺一個mongos實例（用於分區操作）也同時啓動。每一個分區都被加入集羣當中。爲了使用所有三個集羣以及三個複製備份，10個複製組的分佈按照下表進行配置（列 爲集羣節點）：
MongoDB沒有提供自動啓動已分區節點的機制，我們專門爲了10個集羣節點將手動啓動的步驟寫入了YCSB工具當中。
4.4 SEQUOIADB
SequoiaDB由專業的工作人員按照官方文檔進行安裝[7]。安裝設置按照了廣泛文檔中有關集羣安裝和配置[8]的部分進行。SequoiaDB可以用一個統一的集羣管理器啓動所有的實例，內置的腳本 「sdbcm」能用來啓動所有服務。三個數據庫系統的節點由catalog節點進行選擇。三個SequoiaDB的實例在每個節點啓動，訪問自己的磁盤。
4.5 YCSB
YCSB在使用中存在一些不足。它並不能很好的支持不同主機的多個YCSB實例運行的情況，也不能很好支持多核物理機上的連續運行和高OPS負載。 此外，YCSB也不是很方便溫服。bankmark根據這些情況，對資源庫中的YCSB 0,1,14版本 其做了擴展和一些修改優化。較大的改動如下：
增加了自動測試的腳本
Cassandra的jbellis驅動
MongoDB的achille驅動
增加批插入功能（SequoiaDB提供）
更新了MongoDB 2_12的驅動藉口，同時增加了flag屬性來使用批處理模式中的」無序插入「操作。
SequoiaDB驅動
針對多節點安裝配置以及批量加載選項的一些改動
5.基準測試安裝
5.基準測試安裝
如下的通用和專用參數爲了基準測試而進行運行：
十臺服務器（R520、R720）作爲數據庫系統的主機，五臺刀片機作爲客戶端。
使用第六臺刀片機作爲運行控制腳本的系統
每個數據庫系統將數據寫入3塊獨立的磁盤
所有測試運行都以3作爲複製備份常數
bankmark的YCSB工具，根據工作說明中的測試內容提供了負載文件：
對於數據載入，workload[1-5]-warmup或者workload[1-5]文件都可以使用，需要根據具體的需求載入類型選擇。5種負載中的每一個都會被分爲一個針對最終結果的負載文件和一個在真正運行測試之前運行的預熱文件。爲了避免和YCSB的內部訪問記錄控制部分衝突，預熱階段將不會進行插入操作。通過一個線程擴展的測試，我們發現每個YCSB實例將會使用64個線程對於所有的3個系統都是表現最好的。
如下是測試中用到的其他的參數：
儘可能的使用壓縮功能
每個YCSB客戶端的線程數：64
產生：
測試用例1：2億（2000萬每個節點）記錄
測試用例2：1億（1000萬每個節點）記錄
每條記錄由鍵user<ID> 和 十個域 Field<ID> 組成。YCSB默認的記錄大小爲100byte，最終的平均記錄大小爲1128 Bytes （10 fields + field names + key）
每個key value存儲的通用基準測試步驟爲：
啓動數據庫服務器
迭代提供的負載文件中的5個負載：
運行單數據載入（無時間限制，負載文件中的 workload[1-5]-warmup）
暫停30分鐘給每個系統進行清空等操作
運行30分鐘的負載預熱操作（負載文件中的 workload[1-5]-warmup）
運行30分鐘的負載（負載文件中的 workload[1-5]）
停止數據庫服務器
5.1指導方針/ 步驟
所有的系統都運行一次單條載入，一次預熱還有一次正式測試。對於支持批量載入的系統，MongoDB和SequoiaDB，還有一項批量載入的測試要運行。
5.2配置信息矩陣
7.關於作者
Tilmann Rabl是多倫多大學（University of Toronto）的博士後以及bankmark公司的CEO。他的研究主要針對於大數據的基準測試以及大數據系統方面。Michael Frank是bankmark公司的CTO，他是工業標準的基準測試方案Parallel Data Generation Framework(PDGF)的核心開發成員之一。ManuelDanisch是bankmark公司的COO。他是BigBench大數據分析基準測試系統的主要開發者之一，此外他還是Transaction Processing Performance Council(TPC) 基準測試 TPC-DI的數據貢獻者。
bankmark是一家獨立的基準測評機構，公司爲大數據提供了革命性的基準測試方案。受創新技術的推動，bankmark產生了許多優秀而有質量的測試，同時還對很多概念系統進行了驗證併成功的將這些概念系統進行生產力模擬以及成本模擬。以前沿科學研究爲基礎的技術，保證了史無前例的質量和速度。
bankmark是工業基準測試標準化協會SPEC和TPC的獨立成員之一，他們的技術基於TPC-DI和BigBench等基準測試標準。
最新內容請見作者的GitHub頁：http://qaseven.github.io/