云不等于高性能 但可以擁有高性能

在第一篇文章中，我們打破了“云不等于高性能”這個流言，并且概括了如何在一個EC2實例上以1.68美元/小時的開銷獲得百萬TPS。在本篇文章中，我們將評估4個Amazon實例的性能，場景是內存中由4個Aerospike節(jié)點組成的集群，用例則是5個不同的讀/寫負載。在這個部分中，r3.2xlarge是最好價格性能比的獲得者。

曾今有多個報告說明分布式NoSQL數(shù)據(jù)庫在虛擬和實體云基礎設施上的性能：

• Altoros Systems曾公開不同NoSQL數(shù)據(jù)庫在Amazon Extra Large Instances上的性能，文章的鏈接是：“A Vendor-independent Comparison of NoSQL Databases: Cassandra, HBase, MongoDB, Riak”（http://www.altoros.com/vendor_independent_comparison_of_nosql_databases.html）。
• Thumbtack Technology曾經在“Ultra-High Performance NoSQL Benchmarking（http://www.aerospike.com/wp-content/uploads/2013/01/Ultra-High-Performance-NoSQL-Benchmarking.pdf）”報告中指出不同NoSQL數(shù)據(jù)庫（Aerospike、MongoDB、Cassandra和Couchbase）在純內存及固態(tài)硬盤環(huán)境下實體服務器上的性能。
• 最近一篇，CloudSpectator發(fā)表了題為“Performance Analysis: Benchmarking a NoSQL Database on Bare-Metal and Virtualized Public Cloud（http://www.internap.com/resources/nosql-db-bare-metal-vs-public-cloud/）”的報告，對比了Aerospike在實體服務器（搭載SSD）及Amazon EC2和Rackspace云上的性能。

基于這一系列的基準測試，我們選擇了一個4節(jié)點Aerospike集群，當然數(shù)據(jù)完全加載在內存中，負載則使用現(xiàn)實世界中5個真實用例――從100%的寫入負載，50/50、80/20、95/5讀寫負載，再到100%的讀負載。在第一篇報告中，我們使用了百萬個對象，而在這個測試中我們將對象數(shù)量擴展到4000萬個，4個節(jié)點的Aerospike集群將比單節(jié)點部署做更多的混合讀寫負載，主要原因則是同步復制和一致性保障。

我們選用了如下4個Amazon實例：

• m1.large：Previous generation
• m3.xlarge：Current generation，并未附加網(wǎng)絡增強
• r3.2xlarge: Current generation
• r3.large：Current generation用于驗證線性擴展，在2、4、6、8節(jié)點集群上運行了一個80/20負載

結果1：Amazon R3.*根據(jù)讀負載的比例線性擴展Aerospike集群TPS

越高越好

在一個4節(jié)點的Aerospike集群上，Amazon R3.*實例在所有負載中交付了最高的吞吐量，其TPS隨負載讀的比例線性擴展。其他類型實例會在網(wǎng)絡上出現(xiàn)瓶頸，因此不能支撐更多的讀操作。

結果2：Amazon延時對比每實例TPS

越低越好

每個Amazon實例都有請求數(shù)量閾值，在這個閾值之下，操作可以在更低延時被處理。一旦達到這個值，即使可以獲得更高的吞吐量，延時也會隨著請求數(shù)量增加而惡化。

結果3：只有節(jié)點數(shù)量在一定范圍之內，Amazon R3.Large才能線性擴展Aerospike的TPS

越高越好

在80/20讀寫負載下，r3.large實例上的Aerospike TPS可隨節(jié)點數(shù)量線性擴展，2和8節(jié)點數(shù)量對應的TPS分別是2.7萬和14萬。

結果4：對比節(jié)點數(shù)量和跨Amazon實例的TPS

越低越好

結果5：使用Aerospike時，R3.2xlarge表現(xiàn)出更好的價格性能比

越低越好

取決于實例，2-67個節(jié)點被需求以提供1.5到100萬的TPS，價格分別從每月252到8552美元。當然使用年預留實例時，價格會變低，這個圖顯示了對于Aerospike來說，最好的實例就是r3.large或r3.2xlarge。而在同等性能下3.2xlarge節(jié)點數(shù)量最少，開銷最低。

下面我們將概述相關步驟，因此你可以親自驗證Amazon實例的性能并復制結果，可以看到在Amazon實例上使用Aerospike時的線性擴展、超高吞吐量和極低的延時。

按部就班的設置

• 為服務器設置實例。Aerospike服務器配置：同一個Availability Zone中使用4個同類型Amazon實例運行Aerospike。你可以使用 AWS Marketplace來創(chuàng)建這些實例。當然，你也可以選擇具備網(wǎng)絡增強的實例，使用增強網(wǎng)絡HVM的先決條件是VPC。保證security group擁有3000-3003 TCP Port用于節(jié)點間的通信，同時為了使用AMC，TCP Port 8081需要對互聯(lián)網(wǎng)開放。
• 設置Aerospike。配置mesh configuration來啟動一個4節(jié)點Aerospike集群；運行afterburner.sh（cd /opt/aerospike/bin; sudo ./afterburner.sh）來設置每個Aerospike服務器上的最佳線程數(shù)量。
• 設置系統(tǒng)。需要確定RPS為以太網(wǎng)卡使用。這可以通過eth0配置，命令是“echo f | sudo tee /sys/network/eth0/rx-0/rps_cpus”。
• 為客戶端設置實例。為客戶端主機選用4到8個Amazon實例。
• 在客戶端實例上安裝Java基準客戶端，其中一臺被用作運行AMC服務。
• 在服務器實例上啟動集群，并結束遷移，你可以在AMC中檢測遷移處理。
• 加載4000萬條記錄，每個體積都是100字節(jié)，運行Java Benchmark命令：

cd <java client>/benchmarks<br>./run_benchmarks -z 40 -n test -w I&nbsp; -o S:10 -b 10 -l 23 -k 40000000
    -latency 5,1 -h YOUR_AWS_INTERNAL_IP

開始。從多個Java基準客戶端提交均勻分布負載。PS：我們在r3.8xlarge上運行了一個單客戶端，因為它足夠滿足我們的負載需求。

自己動手測試

我們在GitHub上發(fā)布了一個基于云的腳本（https://github.com/aerospike/aws-cloudformation/blob/master/vpc.json），它打包好了一切上述設置。根據(jù)README介紹，你可以自己動手測試。它運行的速度很快，整個過程總花費大約是5.60美元。

原文鏈接：http://highscalability.com/blog/2014/8/20/part-2-the-cloud-does-equal-high-performance.html

如您需要了解AWS最新資訊或是技術文檔可訪問AWS中文技術社區(qū)；如您有更多的疑問請在AWS技術論壇提出，稍后會有專家進行答疑。 

訂閱“AWS中文技術社區(qū)”微信公眾號，實時掌握AWS技術及產品消息！

AWS中文技術社區(qū)為廣大開發(fā)者提供了一個Amazon Web Service技術交流平臺，推送AWS最新資訊、技術視頻、技術文檔、精彩技術博文等相關精彩內容，更有AWS社區(qū)專家與您直接溝通交流！快加入AWS中文技術社區(qū)，更快更好的了解AWS云計算技術。

                                                                                                            （責編/王玉平） 

生活不易，碼農辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈