YCSB告訴你雲端有多快

Ref: http://research.yahoo.com/files/ycsb.pdf

現在提供雲端運算的服務越來越多了, 有:
    - Apache Hadoop+HBase
    - Apache Cassandra (from Facebook)
    - Yahoo PNUTS
    - Google BigTable
    - Amazon SimpleDB
    - Microsoft Azure

傳統的關聯性資料庫, 大多有相同的規範. 但是, 雲端服務大多都有自己的設計理念, 自己的架構, 甚至大多都捨棄了SQL語法. 所以要對這些不同的雲端服務作公平的比較是非常困難的.

Yahoo提供了一個Framework: YCSB(Yahoo! Cloud Serving Benchmark) 來解決這個問題 .(http://wiki.github.com/brianfrankcooper/YCSB/)

雖然雲端的設計理念有很多不一樣
不過主要的設計方向還是一致的, 都是為了:
1. 提供非常大的使用量
2. 提供彈性的方式, 增加雲端服務的數量, 以提供更多的存取量
3. 容錯性, 可以應付所有可能發生的硬體問題, 網路問題

當然, 魚與熊掌不能兼得, 在同樣的設計方向裡面,
每個雲端服務都有他的預設情境, 所以我們必須對以下的情況做抉擇.

- Read vs Write:
為了Write, Update快速, 大多都會使用在磁碟空間中有連續性的Log架構, 去存放資料差異的Update Log, 所以要去Read經過多次Update的資料, 我們就必須要在Log中取得多筆資料之後, 才能組成一筆我們要的資料.

- 同步 vs 非同步:
因為這些架構, 為了容錯機制, 都會複製多筆資料, 在這種情況下, 修改一筆資料時, 其他的複製資料, 是不是也要做同步呢?

- Row-Based vs Column-Based:
提供Column-Based的架構, 每個Column-Family是存放在不同的檔案中, 所以撈取一整筆資料會比較慢, 但是只抓取某些Column會比Row-Based快很多. 此外, 也提供了比較有彈性的資料結構

- 快速 vs 可靠:
在做Write的時候, 大多的架構只會先暫存在記憶體中, 但是這種情況下如果發生硬體異常, 會導致該筆資料毀損, 所以到底是要為了快速還是可靠呢?

比較特別的是HBase, 雖然他選擇了快速的這個陣營, 但是因為HDFS的複製性, 他預設會複製三份資料在不同的電腦, 所以在作Write的動作時, 也會寫到三台電腦的記憶體中, 除非這三台電腦同時發生異常, 否則資料毀損的機會是很小的.


YCSB由幾個層次去對雲端服務作比較:
Tier 1—Performance :
逐漸增加Loading, 去看效能反應

Tier 2—Scaling:
當增加雲端服務的機器數量時, YCSB也等比增加Loading, 去比較效能反應是不是可以維持不變.
也會測量當雲端服務增加機器數量時, 是否會對效能造成負擔

Tier 3—Availability
當發生硬體異常或者網路問題時, 會對效能造成多大的負擔, 目前YCSB還沒辦法自動模擬這種情況.

Tier 4—Replication
各個雲端服務的資料複製數量是可以自己調整的, 這個參數會造成效能上的變化, 所以也是要作比較的. 不同機房之間的複製性, 也是非常重要的效能指標. 目前YCSB也尚為實作.


在實際評比的時候, YCSB為了公平性,  所以將所有雲端服務資料複製性的參數都調整為1, 也就是使得大家都不做資料複製.
並且提供這幾種資料分布性: Uniform, Zipfian, Latest去比較
也實作了這五種情況:Update heavy, Read heavy, Read only, Read latest, Short ranges 去比較

在架構上YCSB 是以延伸為目的, 所以我們可以自己繼承Workload去實作我們想要做的運算, 也可以實作DB Interface去測量其他的Database

看來起YCSB似乎是很公平的, 其實不然. 我覺得至少有以下的兩個情況要做修改:
1. 資料複製性對於大多數的雲端服務來說,  是一個非常重要的特性. 對於HBase來說, 少了資料複製性, 就等於少了Loading Balance, 這是多麼的重要!

2. 目前YCSB提供的DB Interface一次都是抓取一整個row的資料, 這並不符合現實的應用. 所以對於Column也必須做到, Distribution的探討, 才能客觀的反映出現實應用的效能.