總覽

Yahoo Cloud Service Benchmark是一種相當(dāng)廣泛使用的基準(zhǔn)測(cè)試工具，用于測(cè)試大量密鑰（例如1億）和少量客戶端（即由一臺(tái)計(jì)算機(jī)提供服務(wù)）的密鑰值存儲(chǔ)。

在本文中，我將研究如何使用Chronicle Map在具有128 GB內(nèi)存，雙Intel E5-2650 v2 @ 2.60GHz和六臺(tái)Samsung 840 EVO SSD的單 臺(tái)計(jì)算機(jī)上使用Chronicle Map進(jìn)行1億* 1 KB鍵/值的測(cè)試。

1 KB值由100個(gè)字節(jié)的字符串的十個(gè)字段組成。 對(duì)于更好的解決方案，原始數(shù)將是一個(gè)更好的選擇。 盡管SSD有所幫助，但峰值傳輸速率為700 MB / s，可以由兩個(gè)SATA SSD驅(qū)動(dòng)器支持。

這些基準(zhǔn)是在報(bào)告發(fā)布時(shí)使用最新版本的Chronicle Map 2.0.5a-SNAPSHOT進(jìn)行的。

微秒世界

在閱讀有關(guān)鍵值存儲(chǔ)的基準(zhǔn)時(shí)，令我感到困惑的是，它們從性能真的很重要的前提開(kāi)始。 恕我直言，大約90％的時(shí)間里，性能不是最重要的功能，只要您有足夠的性能即可。
然后，這些基準(zhǔn)測(cè)試報(bào)告繼續(xù)以毫秒（而不是微秒）報(bào)告時(shí)間，并且以數(shù)萬(wàn)而不是數(shù)十萬(wàn)或數(shù)百萬(wàn)的吞吐量進(jìn)行報(bào)告。 如果性能確實(shí)如此重要，那么他們將圍繞性能來(lái)構(gòu)建產(chǎn)品，而不是出于性能原因 ，而不是他們支持的有用功能 （例如多鍵事務(wù)性，仲裁更新和Chronicle Map不支持的其他功能）。

那么，為性能而構(gòu)建的密鑰庫(kù)如何與YCSB一起看起來(lái)呢？

吞吐量措施

“ 50/50”測(cè)試50％的隨機(jī)讀取和50％的隨機(jī)寫入，“ 95/5”測(cè)試95％的讀取至5％的寫入。 預(yù)計(jì)寫操作會(huì)更昂貴，讀操作的百分比越高，吞吐量越高。

線程數(shù) 50/50讀取/更新 95/5讀取/更新

1個(gè)	122 K /秒	245 K /秒
2	235 K /秒	414 K /秒
4	339 K /秒	750 K /秒
8	646 K /秒	1.295 M /秒
15	819 K /秒	1.452 M /秒
30	900 K /秒	1.641 M /秒

延遲時(shí)間

以下等待時(shí)間以微秒為單位，而不是毫秒。

線程：8 50/50讀取 95/5閱讀 50/50更新 95/5更新

平均	5微秒	3.9微秒	15.9微秒	11.3微秒
第95名	12微秒	8微秒	31微秒	19微秒
第99名	19微秒	14微秒	42微秒	27微秒
最壞的	67毫秒	70毫秒	67毫秒	70毫秒

注意：基準(zhǔn)測(cè)試并非旨在免費(fèi)提供GC，并會(huì)產(chǎn)生一些垃圾。 這并不是特別高，根據(jù)飛行模擬器，基準(zhǔn)本身僅使用大約1/4的CPU，但是確實(shí)會(huì)影響最糟糕的延遲。

結(jié)論

確保鍵值存儲(chǔ)具有所需的功能，但是如果性能至關(guān)重要，則尋找針對(duì)性能而設(shè)計(jì)的解決方案，因?yàn)樗赡鼙热δ墚a(chǎn)品快100倍。

其他高性能示例

Aerospike基準(zhǔn)測(cè)試 –具有超過(guò)1 M TPS，亞微秒延遲的單服務(wù)器基準(zhǔn)測(cè)試。 使用較小的100字節(jié)記錄。 NuoDB基準(zhǔn)測(cè)試 –支持跨仲裁的事務(wù)。 1 M TPS的24個(gè)節(jié)點(diǎn)。 Oracle NoSQL基準(zhǔn)測(cè)試 – 已有兩年的歷史，使用很多線程，否則效果很好。 VoltDB基準(zhǔn)測(cè)試 –未測(cè)試到1 M TPS，但很有希望。 延遲為1-2毫秒左右，報(bào)告具有99％的延遲，而其他人未包括。

有待改進(jìn)

MongoDB驅(qū)動(dòng)程序基準(zhǔn)測(cè)試 -具有1000微秒而不是毫秒。 Cassandra，HBase，Redis –顯示如果使用足夠多的服務(wù)器，則可以獲得1百萬(wàn)TPS，而1 M TPS則是288個(gè)節(jié)點(diǎn)。 包含Elasticsearch的報(bào)告–報(bào)告包含“資源節(jié)約型環(huán)境”中的運(yùn)行時(shí) Hyperdex –僅涵蓋吞吐量。 WhiteDB –報(bào)告170 K記錄的延遲（以微秒為單位），并且吞吐量適中。 包括航空航天在內(nèi)的基準(zhǔn)–報(bào)告

腳注

使用較小的值會(huì)有所幫助，我們建議嘗試使值接近100個(gè)字節(jié)。 這是95/5工作負(fù)載B（使用10×10字節(jié)字段）和5000萬(wàn)個(gè)條目（與Aerospike基準(zhǔn)測(cè)試一樣）的結(jié)果。 [OVERALL]，運(yùn)行時(shí)間（毫秒），29,542 [總體]，吞吐量（操作數(shù)/秒）， 3,385,011 [READ]，操作，94999832 [READ]，AverageLatency（us）， 1.88 [READ]，MinLatency（us）， 0 [READ]，MaxLatency（us），50201 [READ]，95thPercentileLatency（ms），0.004 [READ]，99thPercentileLatency（ms）， 0.006 [READ]，返回值= 0，48776825 [READ]，返回值= 1，46230007 [更新]，操作，5001168 [更新]，AverageLatency（us）， 8.04 [UPDATE]，MinLatency（us）， 0 [UPDATE]，MaxLatency（us），50226 [UPDATE]，95thPercentileLatency（ms），0.012 [UPDATE]，99thPercentileLatency（ms）， 0.018 [UPDATE]，Return = 0，5001168

翻譯自: https://www.javacodegeeks.com/2014/10/chronicle-map-and-yahoo-cloud-service-benchmark.html

總結(jié)

以上是生活随笔為你收集整理的纪事地图和Yahoo Cloud服务基准的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。