千萬級海量測試資料運算下，Redis VS Couchbase效能大揭秘！

上一篇中我們介紹了Redis 和Couchbase的不同之處和展現各自的優勢所在(請戳藍色加粗字型：Couchbase vs Redis，究竟哪個更勝一籌。）。本文會為開發人員提供最真實有力的資料支撐，讓技術選型更加客觀，讓叢集擴容不再盲目，在可預估的業務規模下，讓每一台機器物盡其材。

▲測試人員：楊挺，宋佳陽

▲測試時間：2017.5.8-2017.5.19；2017.6.28---2017.6.30

▲測試環境

▲測試載入器

▲系統部署

1.叢集部署：
由於redis採用單執行緒模式，即一個執行個體只能使用一個核，所以這裡為了充分發揮機器效能，在3台4核的叢集機器上一共部署了24個redis執行個體,其中12個主執行個體12個備份執行個體，對所有資料啟用一份備份，即每台伺服器部署八個redis執行個體，四主四從。而Couchbase可以充分利用多核CPU，因此每個機器只部署一個執行個體，資料備份啟用一份。

2.壓測用戶端部署：
OPS壓測用戶端部署多線程OPS測試程式，用於測試並統計OPS;ResponseTime壓測用戶端部署單線程ResponseTime測試程式，用於測試並統計不同壓力下叢集服務的回應時間。

▲測試方案
每台OPS用戶端使用500/1000/2000（同步的讀寫操作會阻塞線程，直至提升線程數OPS無明顯變化）個並發線程向叢集發送讀/寫請求，以確保Redis/Couchbase叢集發揮最大輸出能力，與此同時RsponseTime壓測用戶端採用單線程（OPS和RsponseTime測試分用戶端執行是為了避免用戶端網路，用戶端CPU調度等對測試結果的幹擾；RsponseTime壓測用戶端端採用單線程是為了減少CPU時間分區對回應時間的影響）發送讀/寫請求並記錄每個請求的回應時間，以納秒層級的統計精度準確反映出叢集在最大OPS的壓力下，仍能表現出的處理速度。(OPS和回應時間統計工作，由測試程式碼完成)

▲測試案例
以下測試中，採用HashMap作為測試資料類型，在Redis中直接以HashMap格式存取，在Couchbase中需要將Hashmap轉換為Json格式進行存取。

【 小塊資料小數 據量寫入測試】 四台OPS用戶端分別向叢集發送100W個100位元組大小的資料寫入請求，並統計OPS;RsponseTime壓測用戶端向叢集發送1W個100位元組大小的資料寫入請求,並統計回應時間。

一、 Couchbase寫入測試
四台OPS壓力用戶端分別啟動500個並發線程和4個bucket串連數（升高和降低該數值效能表現都略有降低）分別向Couchbase叢集插入100W條資料，即2000個並發線程發起400W個100位元組大小的Document的插入請求，一台RsponseTime壓測用戶端分別在OPS壓測前和OPS壓測過程中，測試和統計Couchbase叢集的服務處理速度。

壓測前Couchbase叢集的RsponseTime統計：

10.20.135.66

壓測前，RsponseTime壓測用戶端使用單線程向叢集發起一萬筆寫入請求，平均回應時間為0.35ms。

Couchbase控台監控情況如下：

Couchbase叢集的資源消耗情況如下：
10.20.135.71

（memcached負責記憶體和硬碟的資料操作；beam.smp負責Couchbase其他潛在進程的監控和管理，比如跨叢集備份，索引和叢集操作）
10.20.135.72

10.20.135.73

OPS壓測用戶端的資源消耗如下：

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

OPS壓測用戶端統計如下：

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

RsponseTime壓測用戶端統計如下：
10.20.135.66

測試結果分析：
Couchbase叢集資源消耗幾乎達到瓶頸，且再增大壓力OPS沒有提升，RsponseTime倒是明顯升高。因此，三台4核8G的Couchbase叢集，正常情況下能提供0.35ms（有一個重要原因是Couchbase插入操作返回完整Document）的平均回應時間，在2000個並發線程發起400W個100位元組大小Document的寫入壓力下，能夠穩定提供15W的OPS，且平均回應時間只有1.95ms（多次測試後選取的一個穩定時間）。

二、Redis寫入測試

四台OPS壓力用戶端分別啟動500個並發線程和300個並發串連（再升高該數值效能表現略微下降），分別向Redis叢集插入100W條資料，即2000個並發線程發起400W個100位元組大小的資料寫入請求，一台RsponseTime壓測用戶端分別在OPS壓測前和OPS壓測過程中，測試和統計Redis叢集的服務處理速度，測試結果如下：
壓測前Redis叢集的RsponseTime統計：

壓測前，RsponseTime壓測用戶端使用單線程向叢集發起一萬筆寫入請求，平均回應時間為0.21ms。

Redis叢集的資源消耗情況如下：
10.20.135.71

（4個Redis主節點對外暴露提供讀寫服務，4個從節點提供備份服務；因此查詢測試中只有4個Redis進程消耗資源）
10.20.135.72

10.20.135.73

 OPS壓測用戶端統計如下：

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

RsponseTime壓測用戶端統計如下：

10.20.135.66

測試結果分析：
雖然OPS壓測用戶端和Redis叢集的資源消耗都沒有逼近滿負荷，但再增大壓力的情況下OPS不升反降，RsponseTime更是明顯增長。因此，三台四核八G的Redis叢集正常使用方式下能提供0.21ms的平均回應時間，在百萬量級100位元組大小的資料區塊寫入請求下能夠穩定提供20W的OPS，且平均回應時間只有2.09ms。

三、 測試小結
正常使用方式下，Redis和Couchbase都可以提供亞毫秒層級的處理速度，但Redis叢集的響應速度（0.21ms）比Couchbase叢集（0.35ms）幾乎快一倍。在2000個並發線程發起400W個100位元組大小資料寫入壓力下，Redis叢集能穩定提供20W的OPS，Couchbase叢集能提供穩定15W的OPS，平均回應時間方面兩者相當。繼續增大壓力的話，Redis的RsponseTime增長速度大於Couchbase，即Redis在較大壓力下的處理速度下降較快。

【小塊資料大資料量寫入測試】

每台OPS用戶端向叢集發送500W個100位元組大小的資料寫入請求，並統計OPS;RsponseTime壓測用戶端向叢集發送1W個100位元組大小的資料寫入請求,並統計回應時間。

一、 Couchbase寫入測試
四台OPS壓力用戶端分別啟動500個並發線程和4個bucket串連數向Couchbase叢集插入500W條資料，即2000個並發線程發起2000W個100位元組大小的Document的寫入請求，一台RsponseTime壓測用戶端在OPS壓測過程中，測試和統計Couchbase叢集的服務處理速度，測試結果如下：
Couchbase控台監控情況如下：

Couchbase叢集的資源消耗情況如下：
10.20.135.71

10.20.135.72

10.20.135.73

OPS壓測用戶端的資源消耗如下：
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

OPS壓測用戶端統計如下：
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

RsponseTime壓測用戶端統計如下：
10.20.135.66

測試結果分析：
Couchbase叢集資源消耗幾乎達到瓶頸，且再增大壓力OPS沒有提升，RsponseTime倒是明顯升高。因此，三台4核8G的Couchbase叢集，正常情況下能提供0.35ms的平均回應時間，在2000個並發線程發起2000W個100位元組大小Document的寫入請求壓力下，能夠穩定提供14W的OPS，平均回應時間達到3.81ms。

二、 Redis寫入測試
四台OPS壓力用戶端分別啟動500個並發線程和300個並發串連（再升高該數值效能表現略微下降），分別向Redis叢集插入500W條資料，即2000個並發線程發起2000W個100位元組大小的資料插入請求，一台RsponseTime壓測用戶端在OPS壓測過程中，測試和統計Redis叢集的服務處理速度，測試結果如下：

Redis叢集的資源消耗情況如下：
10.20.135.71

10.20.135.72

10.20.135.73

OPS壓測用戶端資源消耗如下：
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

OPS壓測用戶端統計如下：
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

RsponseTime壓測用戶端統計如下：
10.20.135.66

測試結果分析：
Redis叢集和OPS壓測用戶端的資源消耗並未達到瓶頸，但再增大壓力OPS沒有提升，RsponseTime倒是明顯升高。因此，三台4核8G的Redis叢集，正常情況下能提供0.21ms的平均回應時間，在2000個並發線程發起2000W個100位元組大小Document的寫入請求壓力下，能夠穩定提供16W的OPS，但平均回應時間達到6.43ms。

三、測試小結
在2000個並發線程發起2000W個100位元組大小Document的寫入請求壓力下，Redis叢集能穩定提供16W的OPS，Couchbase叢集能提供穩定14W的OPS，而平均回應時間方面Redis叢集（6.43ms）明顯長於Couchbase叢集（3.81ms），即此時兩者所提供的OPS相當，但Couchbase叢集的請求處理速度已明顯反超Redis叢集。

  【大塊資料 小資料量寫入測試】 每台OPS用戶端向叢集發送50W個10KB大小的資料寫入請求，並統計OPS;RsponseTime壓測用戶端向叢集發送1W個100位元組大小的資料寫入請求,並統計回應時間。

一、 Couchbase寫入測試
六台OPS壓力用戶端分別啟動1000個並發線程和4個bucket串連數向Couchbase叢集插入50W條資料，即6000個並發線程發起300W個10KB大小的Document的插入請求，一台RsponseTime壓測用戶端在OPS壓測過程中，測試和統計Couchbase叢集的服務處理速度，測試結果如下：
Couchbase控台監控情況如下：

Couchbase叢集的資源消耗情況如下：
10.20.135.71

10.20.135.72

10.20.135.73

OPS壓測用戶端的資源消耗如下：
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

OPS壓測用戶端統計如下：
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

RsponseTime壓測用戶端統計如下：
10.20.135.66

測試結果分析：
Couchbase叢集資源消耗未達到機器瓶頸，但OPS壓測用戶端都達到滿負荷，因為沒有額外機器完成極限測試，測試結果僅能表明單台8核8G OPS壓測用戶端只能發起一千OPS左右的10K資料區塊寫入請求。因此，三台4核8G的Couchbase叢集，正常情況下能提供0.35ms的平均回應時間，在6000個並發線程發起300W個10KB大小Document的寫入請求壓力下能夠穩定提供6K以上的OPS，平均回應時間只有1.16ms，可見壓力主要集中在用戶端。

二、 Redis寫入測試
六台OPS壓力用戶端分別啟動1000個並發線程和300個並發串連數分別向Redis叢集插入50W條資料，即6000個並發線程發起300W個10KB大小的資料插入請求，一台RsponseTime壓測用戶端在OPS壓測過程中，測試和統計Redis叢集的服務處理速度，測試結果如下：
Redis叢集的資源消耗情況如下：
10.20.135.71

10.20.135.72

10.20.135.73

OPS壓測用戶端資源消耗如下：
10.20.135.57