一、開篇

淘寶之前使用的儲存層架構一直是MySQL資料庫，配合以MongDB，Tair等儲存。

MySQL由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：

(1) 資料量變得越來越多 ，事實上現在淘寶幾乎任何一個與使用者相關的線上業務的資料量都在億級別，每日系統呼叫次數從億到百億都有，且歷史資料不能輕易刪除。這需要有一個海量分散式檔案系統，能對TB級甚至PB級別的資料提供線上服務。

(2) 資料量的增長很快且不一定能準確預計 ，大多數應用系統從上線起在一段時間內資料量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴充套件能力有比較強烈的需求，且不希望存在單點制約。

(3)     只需要簡單的kv讀取，沒有複雜的join等需求。

(4)     對系統的併發能力以及吞吐量、響應延時有非常高的需求，並希望系統能保持強一致性。

(5) 通常系統的寫入非常頻繁 ，尤其是大量系統依賴於實時的日誌分析。

(6) 希望能夠快速讀取批量資料 （HBase基於行健儲存的優勢）。

(7) schema靈活多變 ，可能經常更新列屬性或新增列。

(8) 希望能夠方便使用 ，有良好且語義清晰的 java介面。

以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。

1、首先它的資料由hdfs天然地做了資料冗餘，雲梯三年的穩定執行，資料100%可靠己經證明了hdfs叢集的安全性，以及服務於海量資料的能力。

2、其次hbase本身的資料讀寫服務沒有單點的限制，服務能力可以隨伺服器的增長而線性增長，達到幾十上百臺的規模。

3、LSM-Tree模式的設計讓hbase的寫入效能非常良好，單次寫入通常在1-3ms內即可響應完成，且效能不隨資料量的增長而下降。

4、region（相當於資料庫的分表）可以ms級動態的切分和移動，保證了負載均衡性。

5、由於hbase上的資料模型是按rowkey排序儲存的，而讀取時會一次讀取連續的整塊資料做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要１次IO就能獲取幾十上百條使用者想要的資料。

6、最後，淘寶大部分工程師是java背景的同學，因此hbase的api對於他們來說非常容易上手，培訓成本相對較低。

這個問題足以說明，Hbase相對於MongDB擁有上面講到的那幾點優勢。

另外FaceBook是Hbase目前的最大的使用者，其拋棄了自創的最終一致性資料庫Cassandra而選擇了Hbase。 http://wiki.apache.org/hadoop/Hbase/PoweredBy 頁面也羅列出了很多當前正在使用HBase的大使用者。

二、NoSQL資料庫特點

1、 MongDB特點：

(1) MongDB是文件儲存 ，文件按組又分成集合。集合類似於關係資料庫中的表，不過不同

的是其不對Schema進行嚴格約束，即一個集合可以包含任何文件。

文件以BSON格式存在，這是一種JSON類文件的二進位制編碼格式，結構類似於巢狀的鍵值對，每個文件都有一個唯一的標識。

(2) MongDB選擇用記憶體對映檔案儲存 ，所以可以通過提供更大的RAM或者分配更大的虛擬記憶體可以提升MongDB的效能，可以看出高效能是貫穿MongDB設計的一個重要理念。

(3) 限制 ：因為採用記憶體對映檔案儲存，所以32位系統上資料庫的最大值不能超過2G。此外單個文件不能超過16M，說明不適合儲存大物件。還有一個MongDB資料庫最多隻能儲存8000個集合。這些約束都限制了MongDB資料庫的無限增長。

(4) 原子性 ：MongDB並不注重原子性，也沒有定義併發操作中事物完整性和隔離級別，因此在更新同一個集合時，兩個程序可能相互衝突。只有一類成為Modifier Operation的操作(主要有累加欄位、設定欄位值、刪除欄位等操作)才提供原子性。而Hbase和Hypertable等列式資料庫提供行級的原子更新和一致性狀態。

(5) 水平拓展 ：選用MongDB一個常見的原因是弱Schema集合，還有一個原因就是其良好的效能和可拓展性，最近的版本中MongDB開始支援自動分片，其支援將集合分開儲存到多臺機器上，每臺機器儲存一部分，即一個分片，故障轉移通過複製分片來實現，這使得水平拓展變得容易了許多。

(6) 支援非常豐富的查詢、支援各種索引、支援各種聚合函式、支援排序，總之拓展了關係型資料庫的許多有用的功能。

(7) 和Mapreduce結合不是很好 、當資料規模增大時，穩定性不夠好。

雖然MongDB是一種NoSQL資料庫，但是由於本身的一些特性和實際行業中的使用經驗表明，MongDB更像是介於NoSQL資料庫和記憶體資料庫之間的一種資料庫。

2、 Hbase特點：

Facebook是Hbase的最大使用者，下面是我從SIGMOD2011上facebook發表的一篇論文翻譯而來，詳細說明了他們為什麼選擇Hbase。

Facebook主要給出了三類應用場景： Facebook Messaging、Facebook Insight 和 FacebookMetrics System(ODS) 。Messaging 就是 Facebook 的新型訊息服務，每個月儲存1350億條訊息。Insight 是提供給開發者和網站擁有者的資料分析工具，可以幫助他們清楚瞭解到訪問者如何與他們網站互動，以便更好地優化他們的服務。ODS 則是 Facebook 內部的軟硬體狀態統計系統，對於每一個或者一組伺服器，都可以有效地從不同的維度來監控他們的狀態。這三個應用場景都有各自的特色，但簡單地來說，面臨的問題是同樣的：單機或者拆分的關係型資料庫無法滿足需求。

Facebook選擇Hadoop/Hbase的主要原因有以下幾點：

1、 可拓展性 ：可以以最小的代價、無須停機的方式增加儲存系統的容量。一些情況下我們需要快速增加系統的容量，並且能夠自動負載、利用到這些新的硬體裝置。

2、 高寫入吞吐量 ：大多數應用都需要儲存巨大量的資料，這就要求很高的寫入吞吐量。

3、 單個data center內高效能、低延遲的強一致性 ：一些重要的應用、比如訊息、要求很強的單個數據中心內的一致性，這些需求很直觀來自於使用者需求，比如展示在主頁的“未讀訊息”的數目和inbox頁面顯示的訊息就應當是高度一致的。儘管全域性強一致性的分散式系統幾乎是不可能的，但是一個系統至少能夠提供在單個數據中心內的強一致性，這能夠帶來很好的使用者體驗。

4、 高效的隨機讀取效能 ：儘管應用層的快取技術(不管是嵌入式的還是memcached方式)被廣泛應用，但是很多訪問仍然沒辦法命中快取，需要後端的儲存系統來處理，Hbase隨機讀取效能很穩定。MySQL在隨機讀取方面非常優秀，但如果Hbase結合分散式快取MemeCached或者MemBase，那麼其讀取效能就可以和MySQL比肩了。

5、 高可用性以及災難恢復 ：我們需要提供給使用者高度可用的服務，不管是遇到計劃中的事件（比如軟體升級、或者硬體/容量的增加），還是遇到一些計劃之外的事件（比如硬體失效）。我們也需要能夠容許資料中心的一些資料丟失，能夠在合理的時間範圍內切換到其他資料中心來為使用者提供服務。

6、 故障隔離 ：我們在大量的MySQL資料庫上的應用經驗表明，故障隔離是非常關鍵的。單個數據庫可以down掉，但是僅只有很小一部分使用者會被這樣的事件影響。類似地，在我們的Hadoop儲存中，單個磁碟故障僅只會影響到一小部分資料，而且系統可以很快恢復。

7、 原子的“讀-修改-寫”原語 ：原子的計數器和檢查並設定(checkand set、或者稱compare and swap)等API在構建無鎖的併發應用時非常有用，可以幫助使用者有效地解決多執行緒競爭造成的很多問題。

8、 範圍掃描 ：一些應用要求特定範圍內的行的集合的高效檢索。例如，給定使用者的最近100條訊息的檢索。

FaceBook對HDFS做了一些優化：

HDFS最初是被設計為支援一些離線Mapreduce應用的批處理檔案系統，在可拓展性和批量資料處理方面很優秀，基於一些實時性的需求，faceBook對HDFS進行了優化，目的是為了將其打造為更加通用的、低延遲的檔案系統。主要優化包括：

(1)    將單節點的NameNode改為雙節點的熱備份。不過Facebook認為這個不是很重要，他們的HDFS叢集四年來NameNode只出過一次問題，還是因為什麼交易日誌儲存在錯誤的地方。

(2)    RPC的優化。

FaceBook對Hbase也做了一些優化：

(1)    行級原子性、系統可用性的優化。個人看了一下，只能佩服faceBook。

(2)    效能優化主要從兩點進行，一個是 compaction 效能，另一個是讀效能。

讀過 BigTable 論文的應該對其 memtable 和 compaction 的特性比較熟悉。這裡主要討論了讓 minor compaction 也刪除資料的好處，以及如何做 major compaction 能夠提高合併的效能。在資料讀效能方面，文章裡主要討論了減少 IO 操作的方法，其中包括 bloom filter 和特定型別 meta 資訊（時間戳）的使用。還有很重要的一點，在部署上保持 RegionServer 和物理檔案的區域性性！

Hbase主要適用場景：

1 大資料量 （100s TB級資料） 且有快速隨機訪問的需求。

例如淘寶的交易歷史記錄。資料量巨大無容置疑，面向普通使用者的請求必然要即時響應。

2 容量的優雅擴充套件

大資料的驅使，動態擴充套件系統容量的必須的。例如：webPage DB。

3 業務場景簡單，不需要關係資料庫中很多特性（例如交叉列、交叉表，事務，連線等等）

4 優化方面：合理設計rowkey。因為hbase的查詢用rowkey是最高效的，也幾乎的唯一生產環境可行的方式。所以把你的查詢請求轉換為查詢rowkey的請求吧。

HBase在淘寶的應用

個人感覺是最精華的部分，HBase在淘寶裡用在三個地方：

a）  實時推薦、實時報表、實時計費

這類應用的特點是大量資料的實時寫入以及讀取

b）  大資料量型別專案

比如歷史類或需要長期儲存的資料

c）  二次分析型別專案

Hadoop叢集做粗粒度分析，線上做二次分析，比如資料魔方。

三、NoSQL資料庫對比

1、 可拓展性

雖然所有NoSQL資料庫都承諾可拓展性，但是面對挑戰是水平卻不盡相同。

BigTable的相似產品Hbase和Hypertable暫時處於領先地位，記憶體儲存(Membase或Redis)和文件資料庫(MongDB或CouchBase)緊隨其後，他們之間的差異隨著資料量的增大而被無限放大，特別是到了PB級以後。

拓展性方面Hbase具備天生的優勢，支援自動負載均衡，故障轉移，壓縮和單伺服器多分片，而且Hbase和HDFS配合的非常好，HDFS能夠通過複製和自動平衡輕鬆容納跨越多個伺服器的大檔案。

所以所如果需要極端拓展性的話，列族NoSQL是最好的選擇。

但是話又說回來，如果你的大量資料會以驚人的快節奏出現，例如一些實時的交易資料或者廣告點選追蹤資料，那麼單靠列式儲存無法提供完美的解決方案。這個時候你需要一些更加輕快、既支援快速讀寫、又支援實時處理的儲存，沒有什麼比在記憶體裡面處理資料更快了，所以你可以在Hbase前面搭配上MongDB/Redis來進行實時資料處理以及實時的資料探勘等。其他一些實時性不是非常高的批量查詢和資料探勘可以利用Mapreduce在Hbase上進行。

2、 事務完整性和一致性

Hbase和Hypertable提供行級的原子更新以及一致性狀態，MongDB提供文件級別的原子更新，Cassandra只能提供最終一致性。

但是事務的要求並不是必須的，許多資料，比如網路流量日誌，社交網路狀態更新(微博等)，廣告點選，道路交通資料，交易資料和遊戲分數等是一次寫、多次讀，這樣的資料對事務的需求有限，甚至沒有。

有些資料雖然已更新和刪除，但是修改通常只限於單記錄而非資料集的某個範圍，有時更新非常頻繁且涉及範圍操作。如果範圍操作很常見並且需要保持更新的一致性，那麼RDBMS才是最佳選擇，如果單個條目的原子性已經足夠，那麼列式資料庫、文件資料庫和部分鍵/值儲存都可以。如果需要事務完整性但是可以容納暫時的視窗不一致，那麼最終一致性儲存也是不錯的選擇。

3、 資料模型

MongDB支援類SQL查詢、基本的關係型引用和資料庫物件，如果使用NoSQL的主要原因是可以使用寬鬆的資料結構，那麼MongDB肯定是開始使用NOSQL的最佳選擇。

很多Web為中心的業務都開始使用MongDB，主要是因為它支援靈活的資料模型(弱Schema)，同時能夠提供快速的讀寫能力。（現在敏捷開發很重要、MongoDB能更快地開發應用程式。一個明顯的原因是MongoDB沒有固定的Schema，所有花在提交、溝通和實施Schema變更的時間都省下來了）

此外MongDB對Web框架的支援非常好，比如Spring、Rails等。

最後要說明的是，MongDb非常容易上手，學習週期很短。

4、 查詢支援

挑選NoSQL主要考慮的因素除了儲存，還有查詢。

MongDB和Redis的查詢能力比較強。

像MongDB的查詢，與SQL相似，語法簡單，容易學習。MongoDB支援範圍查詢，正則表示式查詢，對子文件內屬性的查詢，可以取代原來大多數任務的SQL查詢。

像Redis的查詢，查詢方法很全，命令文件也很豐富。

Hbase只支援基於Rowkey的單條記錄查詢、基於Rowkey的範圍查詢以及全表掃描。

要注意的是幾乎所有NoSQL儲存都不支援表之間的join操作。

提到查詢不得不提到索引，MongDB本身支援二級索引，Hbase不支援二級索引，但是現在也有很多方法(最常見是藉助協處理器)可以幫助Hbase實時建立二級索引。

5、 效能

(1)    50/50讀和更新、即讀少寫多。

Cassandra最優秀，每秒執行超過1W次操作，平均讀延遲只有25ms、更新效能更好只有10ms。

Hbase緊隨其後。至於MySQL，每秒執行4000左右操作的時候才和上面兩個有可比性，超過5000之後延遲迅速攀升。

(2)    95/5讀和更新、即讀多寫少。

還是Cassandra最優秀。

列式儲存連續範圍的讀取效能非常優秀，這證明和Hbase批量讀寫的效能非常好。

Hbase表現非常穩定，與每秒運算元無關，5%的更新在Hbase裡面幾乎沒有延遲。

只讀情況下MySQL效能最好，可能與快取有關。

如果結合分散式快取MemeCached或者MemBase，那麼Hbase的讀取效能就可以和MySQL比肩了。

四、選擇NoSQL儲存需要考慮的維度

1、Data model（資料模型）. Thereare many variations of how the data is stored, which include key/value stores(compare to a HashMap), semi-structured, column-oriented stores, anddocument-oriented stores. How is your application accessing the data? Can theschema evolve over time?

2、Storage model（儲存模型）.In-memory or persistent? This is fairly easy to decide on since we arecomparing with RDBMSs, which usually persist their data to permanent storage,such as physical disks. But you may explicitly need a purely in-memorysolution, and there are choices for that too. As far as persistent storage isconcerned, does this affect your access pattern in any way?

3、Consistency model（一致性模型）.Strictly or eventually consistent? The question is, how does the storage systemachieve its goals: does it have to weaken the consistency guarantees? Whilethis seems like a cursory question, it can make all the difference in certainuse-cases. It may especially affect latency, i.e., how fast the system canrespond to read and write requests. This is often measured harvest and yield.

4、Physical model（物理模型）.Distributed or single machine? What does the architecture look like - is itbuilt from distributed machines or does it only run on single machines with thedistribution handled client-side, i.e., in your own code? Maybe the distributionis only an afterthought and could cause problems once you need to scale thesystem. And if it does offer scalability, does it imply specific steps to doso? Easiest would be to add one machine at a time, while sharded setupssometimes (especially those not supporting virtual shards) require for eachshard to be increased simultaneously because each partition needs to be equallypowerful.

5、Read/writeperformance（讀寫效能）. You have to understand what your application's access patternslook like. Are you designing something that is written to a few times, but readmuch more often? Or are you expecting an equal load between reads and writes?Or are you taking in a lot of writes and just a few reads? Does it supportrange scans or is better suited doing random reads? Some of the availablesystems are advantageous for only one of these operations, while others may dowell in all of them.

6、Secondary indexes（二級索引）.Secondary indexes allow you to sort and access tables based on different fieldsand sorting orders. The options here range from systems that have absolutely nosecondary indexes and no guaranteed sorting order (like a HashMap, i.e., youneed to know the keys) to some that weakly support them, all the way to thosethat offer them out-of-the-box. Can your application cope, or emulate, if thisfeature is missing?

7、Failure handling（失敗處理）. It isa fact that machines crash, and you need to have a mitigation plan in placethat addresses machine failures (also refer to the discussion of the CAPtheorem in Consistency Models). How does each data store handle server failures?Is it able to continue operating? This is related to the "Consistencymodel" dimension above, as losing a machine may cause holes in your datastore, or even worse, make it completely unavailable. And if you are replacingthe server, how easy will it be to get back to 100% operational? Anotherscenario is decommissioning a server in a clustered setup, which would mostlikely be handled the same way.

8、Compression（壓縮）. Whenyou have to store terabytes of data, especially of the kind that consists ofprose or human readable text, it is advantageous to be able to compress thedata to gain substantial savings in required raw storage. Some compressionalgorithms can achieve a 10:1 reduction in storage space needed. Is thecompression method pluggable? What types are available?

9、Load balancing（負載均衡）. Giventhat you have a high read or write rate, you may want to invest into a storagesystem that transparently balances itself while the load shifts over time. Itmay not be the full answer to your problems, but may help you to ease into ahigh throughput application design.

10、AtomicRead-Modify-Write（原子讀修改寫操作）. While RDBMSs offer you a lot of these operations directly (becauseyou are talking to a central, single server), it can be more difficult toachieve in distributed systems. They allow you to prevent race conditions in multi-threadedor shared-nothing application server design. Having these compare and swap(CAS) or check and set operations available can reduce client-side complexity.Locking, waits and deadlocks It is a known fact that complex transactionalprocessing, like 2-phase commits, can increase the possibility of multipleclients waiting for a resource to become available. In a worst-case scenario,this can lead to deadlocks, which are hard to resolve. What kind of lockingmodel does the system you are looking at support? Can it be free of waits andtherefore deadlocks?

附上一些有用的網址：

http://www.csdn.net/article/2012-11-15/2811920-mongodb-quan-gong-lue

參考 ：

2、淘寶大資料的相關PPT。

3、Facebook的論文。

4、HBase權威指南。