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的實驗室中一個集群上進行的,所有的測試都在物理硬件上進行,沒有使用任何虛擬化的層級?;鞠到y的搭建以及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配置信息矩陣

6.基準測試結果
6.1測試用例1(2億記錄/ 2000萬每節點)
在此測試中,原始數據大約為總系統RAM的45%。
posted on 2014-12-22 23:31 順其自然EVO 閱讀(455) 評論(0) 編輯 收藏 所屬分類: 測試學習專欄