硬件技術的發展給存儲和數據庫軟件技術提供了新的機會。近年來SSD開始流行，那么SSD能否給Hadoop/HBase帶來性能的提升呢？來自Facebook數據團隊的工程師們做了相關的研究和實驗工作。
本文是http://hadoopblog.blogspot.com/2012/05/hadoop-and-solid-state-drives.html （需自備梯子）的翻譯並加上了一些自己的思考，版權歸原博客作者所有。
先說下SSD吧，SSD沒有傳統機械硬盤的機械尋道時間而帶來的延遲，所以IOPS性能可以達到100-200K（而15K的SAS一般在100左右），所以能提供相對於機械硬盤100+倍的的小文件讀取性能，而且在連續讀取方面也能帶來3倍左右的性能提升。但是在寫入性能方面，SSD由於擦除等因素的存在，導致寫入性能提升並不是很大，而且順序寫性能明顯由於隨機寫，所以實踐中要盡量避免隨機寫SSD。SSD的讀寫性能差距較大，而機械硬盤讀寫性能差距不大。
Use case：
Hadoop在Facebook主要有兩種使用場景：基於MapReduce的OLAP類分析型應用和簡單的key-value存儲。
前者的場景下 數據基本上是順序讀取的，不會所以用SSD可能獲益不多。多數的MapReduce任務是CPU密集型的（decompression,deserialization等），瓶頸在於data shuffle過程中的map-output-fetch，加快從HDFS中讀取文件的IO速度並不能顯著提高MapReduce任務的執行速度。可以把Map任務的輸出寫到SSD上，這樣能夠加快data shuffle中map-output-fetch的速度 ，所以說這是一個優化思路。
對於后者的場景，SSD能夠提升online-transaction-process-workload的速度是有理論依據的，所以說也是一個優化思路。
Background：
SSD的讀寫延遲和機械硬盤相比是有數量級的差距的，特別是在隨機讀寫的時候。例如在隨機讀上，SSD的隨機讀取延遲大概是30 micro-seconds（微秒），而機械硬盤隨機讀取延遲大概在5-10 milli-secondes（毫秒）。SSD能支撐100k-200k的OPS，而機械硬盤僅能支撐200-300的OPS。這意味着隨機讀寫在SSD上不是瓶頸。（這是Dhruba Borthakur的博客中的說法，但是我認為隨機寫在SSD上還是要盡量避免的。）另外一方面，現有的數據庫架構都是基於機械硬盤設計的，沒有考慮到SSD的IO代價模型。那么SSD能否給現有基於機械硬盤設計的數據庫帶來性能的提升呢？Facebook的數據團隊做了實驗。他們分別做了基於HDFS和HBase的隨機讀取實驗，看到底SSD能夠跑出什么樣的性能。
HDFS random-read on cached data:
這個實驗中，他們創建了一個兩節點的集群，一個NameNode，一個DataNode。創建一個2G的HDFS文件，文件的block大小是256M，拷貝數是1，所以一共有8個block。DataNode配置了CPU超線程，同時本地文件系統用的是XFS存放block文件。Benchmark程序也在DataNode上跑，同時打開了hdfs-read-shortcircuit功能（https://issues.apache.org/jira/browse/HDFS-2246），這樣DFSClient就會繞過與DataNode的網絡通信而直接從本地磁盤文件系統讀取數據。把這2G文件都放在操作系統的緩存中，所以整個測試過程沒有磁盤IO。用這樣的測試場景來模擬SSD的。然后分別用不同的client線程數測試，每個client線程從HDFS中讀取16K的數據。由於一共就8個block，所以DFSclient緩存了所有的BlockLocations，所以這個過程沒有與NameNode的通信。
在開始的幾輪實驗中，最大的隨機讀吞吐量大概在50K OPS，但是CPU還很空閑。他們發現在hdfs-read-shortcircuit過程中花費了非常可觀的時間在DNS查詢和metric-counters的更新上。在修改了這部分的代碼之后，他們的最大隨機讀吞吐量已經達到了 92K OPS，同時CPU接近95%的利用率。下圖是實驗結果，從中可以看出基於HDFS的數據庫並不能完全利用SSD提供的IOPS。
然后他們用profile的形式來跑HDFS的代碼顯示，DFSClient端的代碼路徑太長了，對緩存的數據隨機讀取產生了相當大的影響。使用機械硬盤的數據讀取磁盤IO時間在毫秒的數量級，那么DFSClient讀取流程的開銷可能不是那么明顯。但是當數據被存儲在操作系統的cache或者在SSD中時，DFSClient的讀取流程的開銷就比較大了，這部分需要重新設計讀取流程。另外一個思路是用C/C++實現一個read-only的client，避免現在基於Java實現的DFSClient的開銷。
HBase random-get on cached data:
然后他們做了類似的實驗在HBase上。創建了一個表，只有一個region，並且這個region所有的數據都是緩存在一台RegionServer操作系統的cache中。同樣用這樣的方法模擬SSD。用4個客戶機做random-get操作。RegionServer配置最大2000個線程，HBase的table使用lzo壓縮算法並開啟delta-encoding-fast-diff功能。同樣整個過程沒有磁盤IO。HBase的吞吐量在35K OPS左右，並且同時CPU使用沒有超過45%。在RegionServer上嚴重的鎖競爭和上下文切換使得CPU的利用率比較低。實驗結果如下圖所示。
What dose this mean
兩個實驗表明，HDFS和HBase都不能完全利用SSD提供的高效IOPS。所以要想把HDFS/HBase用在SSD上跑出很好的性能，需要對代碼進行重構，但是這需要花大量的時間。而且這個結論同樣適用於其他數據庫應用，因為現有數據庫都是基於機械磁盤的IO代價模型設計的，不適用與SSD硬盤。能夠完全利用SSD磁盤的數據庫架構需要從頭開始設計。
也有些人對這個實驗提出了一些討論和意見：
Q：35K OPS的HBase操作代表着多少次磁盤IO的OPS，一般情況下一次HBase操作並不是一次磁盤IO操作，也就是所謂的IO放大(IO amplification)。大多數數據庫IO amplification大概是1:5到1:10，主要包括record相應的索引的查詢和更新，transaction commit，index rebuild, multi-versioning checkpoints, archiving, WAN replication等。同時IO amplification也是負載相關的。
A：35K HBase OPS就代表着35K的磁盤IOPS，因為workload是純隨機讀取，沒有其他操作。
Q：可以考慮在HDFS中增加存儲設備信息作為API開發給上層。例如對於HBase應用來說，把數據文件存放在機械硬盤上，把WAL和flush file等生命周期短、經常訪問的數據存放在SSD上。有點類似於EMC他們經常說的分層存儲的概念。
A：這種思路很好，可行性也很高。但是這樣的話，瓶頸就會落到CPU核心數目越來越多，這些核心不能被高效利用。（http://pdos.csail.mit.edu/multicore/ 這個項目研究了操作系統和軟件在多核處理器上的可擴展性問題）
Q：有人提出混合存儲，可以把HDFS的block的第一個備份存在SSD上，另外兩個備份存在機械硬盤上。甚至可以指定哪個表，哪個Region，哪個HFile block存放在SSD上。然后讀取的時候首先嘗試在SSD上的數據，這樣就可以顯著提升總的讀取性能，而且不降低reliability。
A：混合存儲的思路也很好，但是一個程序只能從HDFS DataNode上獲得16K左右的隨機讀取OPS，並不能完全利用SSD提供的IOPS潛能。
Q：對於SSD來說，單一進程不能跑滿SSD的IOPS，是否可以考慮多個進程實例來共享SSD所能提供的所有的200K+的IOPS呢？
A：是的，事實上在Facebook就是在每個SSD的機器上跑多個進程實例，為的就是提高IOPS的利用率。
總結與感想：SSD改變了傳統的基於機械硬盤的IO代價模型，那么對於基於機械硬盤設計的數據庫應用來說需要重構了。對於HDFS和HBase應用來說，需要優化的空間也很大，特別是LSM（http://www.springerlink.com/content/rfkpd5yej9v5chrp/?MUD=MP）模型的提出和使用，給HBase設計和優化提供了很大的空間。同時SSD帶來了磁盤IOPS的數量級的提升，但是軟件邏輯中鎖操作使得CPU並不能跑滿，所以就提出了單台server跑多個實例的概念，即多進程的概念。Redis也是單線程邏輯，單機多進程部署，從中可以看出軟件特別是數據庫軟件開發的一種回歸。多線程程序鎖的爭用導致CPU利用率低下，使得很多程序開始考慮單線程、多進程的概念，而且降低debug的成本，提高了魯棒性。聽說Amazon推出的DynamoDB也是基於SSD的，后面看看它是怎么用的。
轉自 http://yanbohappy.sinaapp.com/?p=71