近日Thumbtack發(fā)布了兩篇論文，分別為超高性能NoSQL基準(zhǔn)和NoSQL故障轉(zhuǎn)移特征；前者是分析持久性和性能的權(quán)衡，后者則是關(guān)于Aerospike、Cassandra、Couchbase和MongoDB幾個NoSQL的故障轉(zhuǎn)移特征。兩個基準(zhǔn)都嘗試測試“有高吞吐量、低延時需求的面向用戶應(yīng)用程序，這些應(yīng)用程序的數(shù)據(jù)都可以使用鍵值形式進行存儲”。

Thumback使用的是YCSB（Yahoo!Cloud Serving Benchmark）的升級版，新的YCSB改變記錄在第一篇論文的文檔中。在著眼新的基準(zhǔn)測試之前我們首先看一下原YCSB上的一件趣事：

YCSB推出不久后（1年多以前），HyperDex使用這個基準(zhǔn)對HyperDex、Redis和MongoDB幾個高性能數(shù)據(jù)庫進行測試，而得出的結(jié)果更是犀利無比 ——吞吐量秒殺風(fēng)頭正勁的MongoDB與Cassandra，趕超Redis。

為此有“熱心”的網(wǎng)友在Redis社區(qū)中發(fā)表了帖子HyperDex vs.Redis，并得到了Redis之父Salvatore Sanfilippo大神“強有力”的回復(fù)：

事實并沒有聽起來那么有趣，因為：

Redis和Memcached在單核心每秒查詢上具有或多或少的上限，Memcached允許自動的使用多核技術(shù)（這一點Redis在將來可能會實現(xiàn)），而使用Redis你需要多實例，并且這只能在網(wǎng)絡(luò)服務(wù)器中使用，當(dāng)然這些系統(tǒng)使用的都是內(nèi)存處理形式，并且通過合理的優(yōu)化。

我想說的是，我也可以修改Redis讓其返回的總是“foo”，從而達到單核心每秒15萬ops。那么真實情況應(yīng)該是這樣的：

1. 基準(zhǔn)E設(shè)計的非常粗糙，Redis并不支持，這樣的對比一點“營養(yǎng)”都沒有

2. 在所有其它的測試中，他們可能都是使用單核心Redis在對抗多核心HyperDex（或者是多節(jié)點HyperDex）。舉個例子，Redis LPUSH每秒可以輕易的插入100萬個選項進入列表，然而如果你同時使用4個實例，每個核心每秒你可能都會得到3、4百萬寫操作。然而這并不意味著我們需要在首頁上寫上“單核心每秒400萬次操作”！

3. 基準(zhǔn)測試用例的數(shù)據(jù)集可能一直都儲存在內(nèi)存中

4. 沒有公布所有方法，這樣這個測試結(jié)果無任何價值

最后我認為，使用錯誤的引導(dǎo)去塑造產(chǎn)品同樣是不好的行為，前3個月可能會有所收獲，那么之后會發(fā)生些什么？

“任何企圖同時抓兩只兔子的人，最終將毫無收獲。”

而之后Salvatore Sanfilippo更是對YCSB基準(zhǔn)做出了如下的評論：

這是我在HackerNews上對這個基準(zhǔn)YCSB發(fā)起的討論：討論地址

根本上說YCSB在構(gòu)造思路上犯了經(jīng)典的錯誤，取代使用合適的用例來獲得不同數(shù)據(jù)庫的最佳性能，它使用一個層來給不同數(shù)據(jù)庫強制數(shù)據(jù)模型。對于大多數(shù)的數(shù)據(jù)庫來說，使用的是本地數(shù)據(jù)模型，但是對于其它的（比如Redis）數(shù)據(jù)庫來說，只是在模擬使用本地操作。

同樣這個基準(zhǔn)對比的是單核心Redis和多核心Hyperdex之間的性能。

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎(chǔ)知識，讓我們一起攜手，引領(lǐng)人工智能的未來！

標(biāo)簽： 大數(shù)據(jù) 服務(wù)器 數(shù)據(jù)庫 網(wǎng)絡(luò) 網(wǎng)絡(luò)服務(wù)器 云計算

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。