AerospikeDB與Redis性能比較：在AWS上的NoSQL基準測試
AerospikeDB 以低延遲和高吞吐量而聞名，已經用于 許多大型的、要求堪稱苛刻的實時平臺 。而 Redis 同樣以速度著稱，并且也經常用作緩存。有鑒于此，Aerospike團隊近日聯合擁有大數據和云架構師、AWS社區英雄、谷歌云開發專家、微軟MVP（SQL Server）等眾多頭銜的 Lynn Langit 在AWS云的虛擬機上對AerospikeDB和Redis進行了基準測試， 測試結果 已經發布在Aerospike官方博客上。而Lynn也發表了題為《 學到的經驗——在AWS云上進行NoSQL基準測試（AerospikeDB與Redis） 》的博文，對測試過程和結果進行了更為詳細的描述。
由于AerospikeDB是多線程的，而Redis是單線程的，所以為了公平起見，需要對Redis進行擴展，以便它能夠使用每個AWS EC2實例上的多個內核。在這個過程中，Lynn發現了AerospikeDB和Redis在擴展或分片的可管理性方面的差異：
- Redis需要開發人員自己管理分片并提供分片算法用于在各分片之間平衡數據；而AerospikeDB可以自動處理相當于分片的工作；
- 在Redis中，為了增加吞吐量，需要增加Redis分片的數量，并重構分片算法及重新平衡數據，這通常需要停機；而在AerospikeDB中，可以動態增加數據卷和吞吐量，無需停機，并且AerospikeDB可以自動平衡數據和流量；
- 在Redis中，如果需要復制及故障轉移功能，則需要開發人員自己在應用程序層同步數據；而在AerospikeDB中，只需設置復制因子，然后由AerospikeDB完成同步復制操作，保持即時一致性；而且AerospikeDB可以透明地完成故障轉移；
- 此外，AerospikeDB既可以完全在內存中運行，也可以利用Flash/SSD存儲的優點。
接下來，Lynn針對下列工作負載做了兩組基準測試：
- 負載一：50%-50% 讀/寫(-w RU, 50)；
- 負載二：80%-20% 讀/寫(-w RU, 80)；
- 負載三：100% 讀(-w RU, 100)。
第一組基準測試是在單個沒有永久存儲的AWS R3.8xlarge節點上進行的，測試結果如下：
（圖一）
從上圖可以看出，在運行（負載三）時，AerospikeDB和Redis性能相近，均接近1 MTPS。
第二組測試是在同樣的實例上進行的，但引入了永久性存儲。所有數據既會保存在內存中，也會存儲在EBS SSD（gp2）存儲上。在本組測試中，Lynn為AerospikeDB配置了一個新的命名空間，并使用了配置參數“data-in-memory”。 而且，為了避免寫入單個文件造成瓶頸，她還為AerospikeDB配置了12個不同的可寫入位置。對于Redis，則啟用了“appendonly”選 項。在這種模式下，一旦AOF文件增長到一定的大小，Redis就會在后臺重寫AOF文件。這時，Redis的吞吐量就會下降。為了避免這種情況出 現，Lynn將auto-aof-rewrite-min-size參數設為一個很大的值。這在一定程度上會夸大Redis的性能。在這個場景中，磁盤寫 成為瓶頸。因此，Lynn針對AerospikeDB和Redis均減少了客戶端線程的數量，保證不出現寫錯誤。測試結果如下：
（圖二）
從上圖可以看出，在運行（負載二）和（負載三）時，AerospikeDB都比Redis略快。
此外，Lynn還單獨測試了AOF重寫對吞吐量的影響，測試結果如下：
（圖三）
從上圖可以看出，AOF重寫對Redis讀寫性能均有較大的影響。
按照Lynn的說法，上述基準測試結果可能會因為云環境本身的不穩定性、調優技術和基礎設置的差異而有所不同。感興趣的讀者可以查看 原文 了解Lynn的測試步驟及配置細節。
在上述結果發布后，Redis創建者Salvatore Sanfilippo很快就以《 我們為什么不做基準測試來比較Redis和其它DB 》為題發表博文對此進行了回應。他認為，這種對比有廣告嫌疑，并提供了一些從Redis得出更好結果的方法。緊接著，Redis首席開發大使Itamar Haber也發表了題為《漏掉的經驗——在AWS云上進行NoSQL基準測試（AerospikeDB與Redis）》的博文，對Aerospike團隊 和Lynn的測試結果提出質疑，主要包含如下幾點：
- 該測試沒有使用推薦的Redis做法，比如使用管道和多鍵操作；
- 該測試沒有測試工作負載：20%-80%讀寫（ -w RU,20 ）和100%寫（-w RU,0）；
- 比較（圖一）和（圖二）可以得出：在針對（負載三）的測試中，第一次測試結果為928K TPS，第二次測試結果為860K TPS，使用了AOF并不能完全解釋這種差別；此處還有一點令人疑惑，后端使用EBS的Redis其性能（180K TPS）竟然高于只在內存中使用的Redis服務器（132K TPS）。
同時，Itamar指出，對于AOF，一個常見的做法是引入一個從屬Redis實例，專門用于持久化處理，以減輕主實例的負擔。
最后，他寫道：
比較是一件很難做對卻很容易做錯的事。