1. 誰能說說mangodb 和 hbase的區別
1.Mongodb bson文檔型資料庫，整個數據都存在磁碟中，hbase是列式資料庫，集群部署時每個familycolumn保存在單獨的hdfs文件中。
2.Mongodb 主鍵是「_id」,主鍵上面可以不建索引,記錄插入的順序和存放的順序一樣，hbase的主鍵就是row key，可以是任意字元串(最大長度是 64KB，實際應用中長度一般為 10-100bytes)，在hbase內部，row key保存為位元組數組。存儲時，數據按照Row key的字典序(byte order)排序存儲。設計key時，要充分排序存儲這個特性，將經常一起讀取的行存儲放到一起。
字典序對int排序的結果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行鍵必須用0作左填充。
3.Mongodb支持二級索引，而hbase本身不支持二級索引
4.Mongodb支持集合查找，正則查找，范圍查找，支持skip和limit等等，是最像mysql的nosql資料庫，而hbase只支持三種查找：通過單個row key訪問，通過row key的range，全表掃描
5.mongodb的update是update-in-place，也就是原地更新，除非原地容納不下更新後的數據記錄。而hbase的修改和添加都是同一個命令：put，如果put傳入的row key已經存在就更新原記錄,實際上hbase內部也不是更新，它只是將這一份數據已不同的版本保存下來而已，hbase默認的保存版本的歷史數量是3。
6.mongodb的delete會將該行的數據標示為已刪除，因為mongodb在刪除記錄時並不是真把記錄從內存或文件中remove，而是將該刪除記錄數據置空（寫0或特殊數字加以標識）同時將該記錄所在地址放到一個list列表「釋放列表」中，這樣做的好就是就是如果有用戶要執行插入記錄操作時，mongodb會首先從該「釋放列表」中獲取size合適的「已刪除記錄」地址返回，這種方法會提升性能（避免了malloc內存操作），同時mongodb也使用了bucket size數組來定義多個大小size不同的列表，用於將要刪除的記錄根據其size大小放到合適的「釋放列表」中。Hbase的delete是先新建一個tombstonemarkers，然後讀的時候會和tombstonemarkers做merge，在 發生major compaction時delete的數據記錄才會真真刪除。
7.mongodb和hbase都支持maprece，不過mongodb的maprece支持不夠強大，如果沒有使用mongodb分片，maprece實際上不是並行執行的
8.mongodb支持shard分片，hbase根據row key自動負載均衡，這里shard key和row key的選取盡量用非遞增的欄位，盡量用分布均衡的欄位，因為分片都是根據范圍來選擇對應的存取server的，如果用遞增欄位很容易熱點server的產生，由於是根據key的范圍來自動分片的，如果key分布不均衡就會導致有些key根本就沒法切分，從而產生負載不均衡。
9.mongodb的讀效率比寫高，hbase默認適合寫多讀少的情況，可以通過hfile.block.cache.size配置，該配置storefile的讀緩存佔用Heap的大小百分比，0.2表示20%。該值直接影響數據讀的性能。如果寫比讀少很多，開到0.4-0.5也沒問題。如果讀寫較均衡，0.3左右。如果寫比讀多，果斷默認0.2吧。設置這個值的時候，你同時要參考hbase.regionserver.global.memstore.upperLimit，該值是memstore佔heap的最大百分比，兩個參數一個影響讀，一個影響寫。如果兩值加起來超過80-90%，會有OOM的風險，謹慎設置。
10.hbase採用的LSM思想(Log-Structured Merge-Tree)，就是將對數據的更改hold在內存中，達到指定的threadhold後將該批更改merge後批量寫入到磁碟，這樣將單個寫變成了批量寫，大大提高了寫入速度，不過這樣的話讀的時候就費勁了，需要merge disk上的數據和memory中的修改數據，這顯然降低了讀的性能。mongodb採用的是mapfile+Journal思想，如果記錄不在內存，先載入到內存，然後在內存中更改後記錄日誌，然後隔一段時間批量的寫入data文件，這樣對內存的要求較高，至少需要容納下熱點數據和索引。
2. 淘寶為什麼使用HBase及如何優化的
1 前言
hbase是從hadoop中 分離出來的apache頂級開源項目。由於它很好地用java實現了google的bigtable系統大部分特性，因此在數據量猛增的今天非常受到歡 迎。對於淘寶而言，隨著市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效插入和讀取變得越來越重要。由於淘寶擁有也許是國內最大 的單一hadoop集群(雲梯)，因此對hadoop系列的產品有比較深入的了解，也就自然希望使用hbase來做這樣一種海量數據讀寫服務。本篇文章將 對淘寶最近一年來在online應用上使用和優化hbase的情況做一次小結。
2 原因
為什麼要使用hbase？
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。
但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：
a) 數據量變得越來越多，事實上現在淘寶幾乎任何一個與用戶相關的在線業務的數據量都在億級別，每日系統調用次數從億到百億都有，且歷史數據不能輕易刪除。這需要有一個海量分布式文件系統，能對TB級甚至PB級別的數據提供在線服務
b) 數據量的增長很快且不一定能准確預計，大多數應用系統從上線起在一段時間內數據量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴展能力有比較強烈的需求，且不希望存在單點制約
c) 只需要簡單的kv讀取，沒有復雜的join等需求。但對系統的並發能力以及吞吐量、響應延時有非常高的需求，並且希望系統能夠保持強一致性
d) 通常系統的寫入非常頻繁，尤其是大量系統依賴於實時的日誌分析
e) 希望能夠快速讀取批量數據
f ) schema靈活多變，可能經常更新列屬性或新增列
g) 希望能夠方便使用，有良好且語義清晰的java介面
以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。首先它的數據由hdfs天然地做了數據冗餘，雲梯三年的穩定運行，數據100%可靠 己經證明了hdfs集群的安全性，以及服務於海量數據的能力。其次hbase本身的數據讀寫服務沒有單點的限制，服務能力可以隨伺服器的增長而線性增長， 達到幾十上百台的規模。LSM-Tree模式的設計讓hbase的寫入性能非常良好，單次寫入通常在1-3ms內即可響應完成，且性能不隨數據量的增長而 下降。
region（相當於資料庫的分表）可以ms級動態的切分和移動，保證了負載均衡性。由於hbase上的數據模型是按rowkey排序存儲的，而讀 取時會一次讀取連續的整塊數據做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要1次io就能獲取幾十上百條用戶想要的 數據。最後，淘寶大部分工程師是java背景的同學，因此hbase的api對於他們來說非常容易上手，培訓成本相對較低。
當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是 單點的，單台機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。
3 應用情況
我們從2011年3月開始研究hbase如何用於在線服務。盡管之前在一淘搜索中己經有了幾十節點的離線服務。這是因為hbase早期版本的目標就 是一個海量數據中的離線服務。2009年9月發布的0.20.0版本是一個里程碑，online應用正式成為了hbase的目標，為此hbase引入了 zookeeper來做為backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一個里程碑，基本上我們今天 看到的各大網站，如facebook/ebay/yahoo內所使用於生產的hbase都是基於這一個版本(fb所採用的0.89版本結構與0.90.x 相近)。bloomfilter等諸多屬性加入了進來，性能也有極大提升。基於此，淘寶也選用了0.90.x分支作為線上版本的基礎。
第一個上線的應用是數據魔方中的prom。prom原先是基於redis構建的，因為數據量持續增大以及需求的變化，因此我們用hbase重構了它 的存儲層。准確的說prom更適合0.92版本的hbase，因為它不僅需要高速的在線讀寫，更需要count/group by等復雜應用。但由於當時0.92版本尚未成熟，因此我們自己單獨實現了coprocessor。prom的數據導入是來源於雲梯，因此我們每天晚上花 半個小時將數據從雲梯上寫入hbase所在的hdfs，然後在web層做了一個client轉發。經過一個月的數據比對，確認了速度比之redis並未有 明顯下降，以及數據的准確性，因此得以順利上線。
第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數據傳輸平台，廣泛應用於實時日誌收集、數據實 時監控、廣告效果實時反饋、資料庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態的數據增加使hbase上compact/balance /split/recovery等諸多特性受到了極大的挑戰。TT的寫入量大約一天20TB，讀的量約為此的1.5倍，我們為此准備了20台 regionserver的集群，當然底層的hdfs是公用的，數量更為龐大（下文會提到）。每天TT會為不同的業務在hbase上建不同的表，然後往該 表上寫入數據，即使我們將region的大小上限設為1GB，最大的幾個業務也會達到數千個region這樣的規模，可以說每一分鍾都會有數次 split。在TT的上線過程中，我們修復了hbase很多關於split方面的bug，有好幾個commit到了hbase社區，同時也將社區一些最新 的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數據丟失最大的風險之一，這一點對於每個想使用hbase的開發者來 說必須牢記。hbase由於採用了LSM-Tree模型，從架構原理上來說數據幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因後面會 單獨強調。TT在預發過程中我們分別因為Meta表損壞以及split方面的bug曾經丟失過數據，因此也單獨寫了meta表恢復工具，確保今後不發生類 似問題(hbase-0.90.5以後的版本都增加了類似工具)。另外，由於我們存放TT的機房並不穩定，發生過很多次宕機事故，甚至發生過假死現象。因 此我們也著手修改了一些patch，以提高宕機恢復時間，以及增強了監控的強度。
CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現在一般歸 納為四類原因：網路原因、gc問題、命中率以及client的反序列化問題。我們現在對它們做了一些解決方案(後面會有介紹)，以更好地對慢響應有控制 力。
和Facebook類似，我們也使用了hbase做為實時計算類項目的存儲層。目前對內部己經上線了部分實時項目，比如實時頁面點擊系 統，galaxy實時交易推薦以及直播間等內部項目，用戶則是散布到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式 做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數據，同時關聯商品表等維度表計算排行(TopN)，而實時頁面點擊系統則是 基於twitter開源的storm進行開發，後台通過TT獲取實時的日誌數據，計算流將中間結果以及動態維表持久化到hbase上，比如我們將 rowkey設計為url+userid，並讀出實時的數據，從而實現實時計算各個維度上的uv。
最後要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由於它關繫到 己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數據丟失以及服務中斷是零容忍。它對compact做了優化，避免大數據量的compact在 服務時間內發生。新增了定製的filter來實現分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗餘數據的傳輸以及90%以上的讀轉化成了順序 讀。目前該集群存儲了超過百億的訂單數據以及數千億的索引數據，線上故障率為0。
隨著業務的發展，目前我們定製的hbase集群己經應用到了線上超過二十個應用，數百台伺服器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。
4 部署、運維和監控
Facebook之前曾經透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集群按用戶分為數 個集群，每個集群100台伺服器，擁有一台namenode以及分為5個機架，每個機架上一台zookeeper。可以說對於大數據量的服務這是一種優良 的架構。對於淘寶來說，由於數據量遠沒有那麼大，應用也沒有那麼核心，因此我們採用公用hdfs以及zookeeper集群的架構。每個hdfs集群盡量 不超過100台規模（這是為了盡量限制namenode單點問題）。在其上架設數個hbase集群，每個集群一個master以及一個 backupmaster。公用hdfs的好處是可以盡量減少compact的影響，以及均攤掉硬碟的成本，因為總有集群對磁碟空間要求高，也總有集群對 磁碟空間要求低，混合在一起用從成本上是比較合算的。zookeeper集群公用，每個hbase集群在zk上分屬不同的根節點。通過zk的許可權機制來保 證hbase集群的相互獨立。zk的公用原因則僅僅是為了運維方便。
由於是在線應用，運維和監控就變得更加重要，由於之前的經驗接近0，因此很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養。以下講一些我們的運維和監控經驗。
我們定製的hbase很重要的一部分功能就是增加監控。hbase本身可以發送ganglia監控數據，只是監控項遠遠不夠，並且ganglia的 展示方式並不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監控點，比如compact/split/balance/flush隊列以及各個階 段的耗時、讀寫各個階段的響應時間、讀寫次數、region的open/close，以及具體到表和region級別的讀寫次數等等。仍然將它們通過 socket的方式發送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數據的精度會越來越低，因此我們自己編寫 程序從rrd中讀出相應的數據並持久化到其它地方，然後自己用js實現了一套監控界面，將我們關心的數據以趨勢圖、餅圖等各種方式重點匯總和顯示出來，並 且可以無精度損失地查看任意歷史數據。在顯示的同時會把部分非常重要的數據，如讀寫次數、響應時間等寫入資料庫，實現波動報警等自定義的報警。經過以上措 施，保證了我們總是能先於用戶發現集群的問題並及時修復。我們利用redis高效的排序演算法實時地將每個region的讀寫次數進行排序，能夠在高負載的 情況下找到具體請求次數排名較高的那些region，並把它們移到空閑的regionserver上去。在高峰期我們能對上百台機器的數十萬個 region進行實時排序。
為了隔離應用的影響，我們在代碼層面實現了可以檢查不同client過來的連接，並且切斷某些client的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。maprece的應用也會控制在低峰期運行，比如在白天我們會關閉jobtracker等。
此外，為了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重 的工操作，因此盡量減少hbck的調用次數，盡量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外為了確保 hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。
我們會每天根蹤所有線上伺服器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低為0。另外 每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。盡管並不是每一次error都會引發問題，甚至大部分error都只是分布式系統中的正常現 象，但明白它們問題的原因是非常重要的。
5 測試與發布
因為是未知的系統，我們從一開始就非常注重測試。測試從一開始就分為性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀 寫比例，不同k/v大小，不同列族數，不同命中率，是否做presharding等等。每次運行都會持續數小時以得到准確的結果。因此我們寫了一套自動化 系統，從web上選擇不同的場景，後台會自動將測試參數傳到各台伺服器上去執行。由於是測試分布式系統，因此client也必須是分布式的。
我們判斷測試是否准確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來 的事實證明它非常有意義。因為我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被准確捕捉到，又比如某次代碼修改 使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。
功能測試上則主要是介面測試和異常測試。介面測試一般作用不是很明顯，因為hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要， 我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受 到了重視和commit。分布式系統設計的難點和復雜度都在異常處理上，我們必須認為系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查 看代碼大體定位到問題以後，在代碼層面強行拋出異常來復現它。事實證明這非常有用。
為了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每台伺服器上抓取相應的日誌並按一定規律匯總。這非常重要，避免浪費大量的時間到登錄不同的伺服器以尋找一個bug的線索。
由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發布模式。它既要避免頻繁的發布引起的不穩定，又要 避免長期不發布導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩周從內部trunk上release一個版本，該版本必須通過所有 的測試包括回歸測試，並且在release後在一個小型的集群上24小時不受甘擾不停地運行。每個月會有一次發布，發布時採用最新release的版本， 並且將現有的集群按重要性分級發布，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發布機制後，由發布帶來的不穩定因素大大下降 了，並且線上版本也能保持不落後太多。
6 改進和優化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公布了對hbase的所有改造，並且將他們內部實際使用的版本開源到了社區。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐 大，並且由於應用類型非常豐富，我們並們並沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們並不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也為社 區提交了10數個穩定性相關的patch，比較重要的有以下幾個：
https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899
還有其它一些，我們主要將patch提交到0.92版本，社區會有commitor幫助我們backport回0.90版本。所以社區從 0.90.2一直到0.90.6一共發布了5個bugfix版本後，0.90.6版本其實己經比較穩定了。建議生產環境可以考慮這個版本。
split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta 表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之後region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region 被兩個以上的regionserver所服務，那麼就可能出現這一個region所服務的數據會隨機分別寫到多台rs上，讀取的時候也會分別讀取，導致數 據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。
前面說到慢響應的問題歸納為網路原因、gc問題、命中率以及client的反序列化問題。網路原因一般是網路不穩定引起的，不過也有可能是tcp參 數設置問題，必須保證盡量減少包的延遲，如nodelay需要設置為true等，這些問題我們通過tcpmp等一系列工具專門定位過，證明tcp參數 對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將 version數設為1以增加緩存的容量，良好的balance也能幫助充分應用好每台機器的命中率。我們為此設計了表級別的balance。
由於hbase服務是單點的，即宕機一台，則該台機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。為此主要做了幾點優 化。首先是將zk的宕機發現時間盡量縮短到1分鍾，其次改進了master恢復日誌為並行恢復，大大提高了master恢復日誌的速度，然後我們修改了 openhandler中可能出現的一些超時異常，以及死鎖，去掉了日誌中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鍾甚至半小時無法重啟的問題己經被修復掉了。另外，hdfs層面我們將 socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。
hbase本身讀寫層面的優化我們目前並沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因為由於hbase本身 良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數並應用於生產環境後，都基本滿足需求。不過這是我們接下來的重要工作。
7 將來計劃
我們目前維護著淘寶內基於社區0.90.x而定製的hbase版本。接下來除繼續fix它的bug外，會維護基於0.92.x修改的版本。之所以這 樣，是因為0.92.x和0.90.x的兼容性並不是非常好，而且0.92.x修改掉的代碼非常多，粗略統計會超過30%。0.92中有我們非常看重的一 些特性。
0.92版本改進了hfile為hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文 件。現有的HFile在文件大到一定程度時，index會佔用大量的內存，並且載入文件的速度會因此下降非常多。而如果HFile不增大的 話，region就無法擴大，從而導致region數量非常多。這是我們想盡量避免的事。
0.92版本改進了通訊層協議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成為影響client性能的地方。
0.92版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
還有其它很多優化，比如改進了balance演算法、改進了compact演算法、改進了scan演算法、compact變為CF級別、動態做ddl等等特性。
除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯的特性，0.94是一個性能優化版本。它做了很多革命性工作，比如去掉root表，比如HLog進行壓縮，replication上支持多個slave集群，等等。
我們自己也有一些優化，比如自行實現的二級索引、backup策略等都會在內部版本上實現。
另外值得一提的是hdfs層面的優化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化 讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優秀的hdfs團隊來支持我們的 hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數的建議，以及幫助實現namenode的HA等。最新的測試 表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監控和調整regionserver的負載，能夠動態地將負載不足的集群上的伺服器挪到負載較高的集群中，而整個過程對用戶完全透明。
總的來說，我們的策略是盡量和社區合作，以推動hbase在整個apache生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。
3. Hadoop+HBase如何實現DB數據的緩存
您好
10g之前可以設置db_cache_size 來指定緩存大小
10g開始可以使用sga_target（當然你也可以不用，但是推薦用），來設定整個共享內存區域大小，包括緩存和共享池等。不需要再單獨設置db cache
11g可以設置memory_target，不光包括了sga，還包括了pga,是所有給oracle的內存的總和，就更方便了。
如果你使用了sga_target或者memory_target，還同時設置了db_cache_size的話，那麼你設置的db_cache_size成為了緩存的最小值。
需要分配給資料庫多大內存取決於你的業務需要，你可以通過db cache advisor的視圖，來估計是否需要更大的緩存。
4. 個性化數據存儲對HBase資料庫緩存有什麼要求么
如果是大量的寫的話HBase很適合，當然小設置沒關系。你可以通過動態擴展列來保存各種個性數據，rowkey就是userID，一次就可以把全部的個性數據拿出來再進行整合。如果讀的頻率高，建立在HBase的前面做一個緩存，不要每次都去讀HBase。
5. 什麼情況下適合使用Hbase
1.數據查詢模式已經確定，且不易改變，就是說hbase使用在某種種特定的情況下，且不能變動。
2.告訴插入，大量讀取。因為分布式系統對大量數據的存取更具優勢。
3.盡量少的有數據修改。因為hbase中的數據修改知識在後面添加一行新數據，表示覆蓋前一條，大量修改浪費大量空間。（hbase基於hdfs存儲不支持修改）
以淘寶網為例：
淘寶網有一項最近瀏覽商品的功能，用傳統的關系型資料庫有以下困難：
orderby'耗費性能大；
大量數據處理，而且無法分布處理；
需要實時看到足跡，無法滿足要求，因為數據量太大。而且不能使用緩存技巧（即把一天或者一小時前的數據處理得到結果，寫入緩存表，然後給客戶，沒有時效性）。
hbase的優勢：
有時間戳，適合告訴時間查詢；
基於行健的查詢異常快（行健可參考後面hbase的表結構），特別是最近的數據可能還在memstore里，沒有io開銷；
分布式處理。
6. hbase 存儲為什麼快
從根本上講，
hbase是列式資料庫，不是以行為連續存儲的，二是以列為連續存儲的。因此對列可以將從磁碟上連續地讀取所有記錄的某一列。充分發揮IO吞吐能力，讀取自然會很快；
hbase是基於HDFS存儲數據塊的，可以將操作分散到多個節點並行地執行；
7. Cassandra與HBase的大數據對決 誰是勝者
眾多基於Bigtable技術的開源項目正在通過不同的方式實現高擴展性、高靈活性、分布式及寬列數據存儲等功能，Cassandra和HBase就是其中的代表。
在大數據這一全新的領域里，Bigtable資料庫技術非常值得我們關注，因為這一技術是由谷歌的工程發明的，而谷歌是一家公認的非常擅長管理海量數據的
公司。如果你對此非常了解，那麼你一家知道也熟悉Cassandra和HBase這兩個Apache資料庫項目。
谷歌在2006年的一份研究報告中首次對Bigtable進行了闡述。有意思的是，這份報告當時並沒有將Bigtable作為資料庫技術，而是將其作為一
種「稀疏的分布式多維度」映射技術以存儲拍位元組級數據，並在商用硬體上運行它們。行先是以一種非常獨特的方式被索引，隨後Bigtable利用行鍵對數據
進行分割，將它們分布到集群中。列可以被迅速地定義在行中，讓Bigtable適用於大多數的非模式環境。
Cassandra和HBase都在很大程度上借鑒了早期Bigtable的定義。實際上，Cassandra起源於Bigtable和亞馬遜的
Dynamo技術，HBase將自身定位為「開源Bigtable工具」。就其本身而論，這兩個項目既有許多相同的特點，同時又有許多重大區別。
同為大數據而生
Cassandra與HBase都是NoSQL資料庫。總體上看，這意味著用戶無法使用SQL資料庫。不過，Cassandra使用的是CQL（Cassandra 查詢語言），其語法有明顯模仿SQL的痕跡。
兩者都被設計用於管理非常大的數據集。HBase文件聲稱一個HBase資料庫可以擁有數億個，甚至是數十億個行。此外，用戶還被建議繼續使用關系型資料庫。
兩者都是分布式資料庫，不僅僅是在數據的存儲方式上，在數據訪問方式上亦是如此。客戶端可以與集群中的任意節點相連，並訪問任意的數據。
兩者都宣稱擁有近似於線型的擴展能力。想要管理兩倍規模的數據嗎？用戶只需將集群中的節點擴展兩倍即可。
兩者都是通過復制來防止集群節點故障而導致出現數據損失。被寫入資料庫的行主要由單個集群節點負責（行至節點映射取決於用戶所使用的分區模式）。數據會被
鏡像到稱之為冗餘節點的其他集群成員當中（用戶可配置的復制因子會顯示數量）。如果主要節點出現了故障，那麼數據仍然可以從另外的冗餘節點中被讀取。
兩者都被稱之為列式資料庫。由於它們的名字聽起來像是關系型資料庫，因此用戶在接觸中需要在思想上進行調整，這導致用戶對它們的認知會出現混淆。最容易出
現混淆的地方是，數據在表面上最初是由行進行排列的，表的主要鍵是行鍵。但是與關系型資料庫不同，在列式資料庫中，沒兩個行需要相同的列。正如上面所說的
那樣，在表被創建後，用戶能夠快速在行中加入列。實際上，你能夠向一行中增加許多列。雖然最高上限值難以被准確地計算出來，但是用戶幾乎不可能達到這樣的
上限，即便他們加入大量列的情況下也是如此。
除了這些源於Bigtable定義的特點外，Cassandra和HBase還有一些其他的相似之處。
首先，兩者都使用相似的寫入路徑，即首先將寫入操作記錄在日誌文件中以確保持久性。即便出現寫入失敗的提示，保存在日誌當中的操作記錄可以被重新開始。隨
後，數據被寫入內存緩存中。最後，數據被通過大量的一系列寫入操作寫入到磁碟中（實際上是將內存緩存的副本拷貝至磁碟中）。Cassandra和
HBase所使用的內存和磁碟數據結構在某種程度上都是日誌結構的合並樹。Cassandra的磁碟組件是SSTable，HBase中磁碟組件的是
HFile。
兩者提供JRuby語言的命令行外殼。兩者都通過Java語言被大量寫入，這是訪問它們的主要編程語言，盡管在許多其他的編程語言中都有適合兩者的客戶端包。
當然，Cassandra 和 HBase都是Apache軟體基金會管理的開源項目，兩者都可以通過Apache License version 2.0許可證免費獲取。
相似與差別
盡管兩者有著眾多相似之處，但是它們之間還是存在著許多重大的區別。
盡管Cassandra和HBase中的節點都是對稱的，這意味著客戶端能夠與集群中的任意節點相連，但是這種對稱是不完全的。Cassandra需要用
戶將一些節點作為種子節點，讓它們在集群間通信中扮演集流點的角色。在HBase中，用戶必須讓一些節點充當主節點，它們的功能是監控和協調地區伺服器的
行動。為了確保高可用性，Cassandra採取方式是允許在集群中設置多個種子節點；HBase則是利用備用主節點，如果當前的主節點發生故障，那麼備
份主節點將成為新的主節點。
Cassandra在節點間通信中使用的是Gossip協議。目前Gossip服務已經與Cassandra軟體整合到了一起。HBase則依託完全獨立
的分布式應用Zookeeper來處理相應的任務。盡管HBase與Zookeeper一同出貨，但是用戶常常會使用預置在HBase資料庫中的
Zookeeper。
雖然Cassandra和HBase都不支持實時交易控制，但是兩者都提供了一定程度的一致性控制。HBase向用戶提供記錄級（也就是行級）的一致性。
實際上，HBase在每行都支持ACID級語義。用戶可以在HBase中鎖定一行，但是這種行為並不被鼓勵，因為這不僅影響到並發性，同時行鎖定還會導致
無法進行區域分割操作。此外，HBase還可以執行「檢查與寫入」操作，該操作在單個數據元上提供了「讀取-修改-寫入」的語義。
Cassandra免費的DataStax社區版包含有一個DataStax 操作中心。該中心提供了集群監控與管理功能，它可以檢測資料庫模式，提示鍵空間是否能夠被編輯，以及是否可以增加或刪除列族。
盡管Cassandra被描述為擁有「終極」一致性，但是讀取和寫入一致性可以在級別和區間方面進行調整。也就是說，你不僅可以配置必須成功完成操作的冗餘節點數量，還可以設置參與的冗餘節點是否跨數據中心。
此外，Cassandra還在其計算機指令系統中增加了一些輕量級的交易。Cassandra的輕量級交易採用的是「比較與集合」機制，相當於HBase
的「檢查與寫入」功能。不過，對於HBase的「讀取-修改-寫入」操作功能，Cassandra則缺乏相對應的功能。最終，Cassandra的2.0
版本增加了單獨的行級寫入功能。如果一個客戶端在一行中更新了多個列，那麼其他的客戶端將會看到所有未更新的部分，或所有更新的部分。
在Cassandra和HBase當中，主索引是行鍵，但是數據被存儲在磁碟中，這導致列族成員相互間非常接近。因此仔細規劃列族組織非常重要。為了保持
高查詢性能，有著相同訪問模式的列應該被放在在相同的列族當中。Cassandra允許用戶創建關於列值的額外次索引。這一舉措提升了對那些值具有高重復
性的列（例如存儲客戶電子郵件地址中國家地區的列）的數據訪問。HBase雖然缺乏對次索引的內置支持，但是它們有一些能夠提供次索引功能的機制。這些都
在HBase的在線參考指南和HBase社區博客中被提及。
如前所述，兩個資料庫都有發布數據操作命令的命令行外殼。由於HBase和Cassandra的殼都是以JRuby殼為基礎，因此用戶可以編寫一些腳本，
讓這些腳本能夠調用JRuby殼的所有資源與資料庫所提供的特定API進行交互。此外，Cassandra還定義了模仿自SQL的CQL。與HBase所
使用的查詢語言相比，CQL的功能更加豐富，並且可以在Cassandra的殼內直接執行。
盡管Cassandra仍然支持Thrift
API，但實際上Cassandra一直在推動讓CQL成為資料庫的主要編輯介面。Cassandra的文檔列入了一些針對Java、C#和Python
等使用CQL version
3的驅動。最終，Cassandra將可獲得一個JDBC驅動。該驅動用CQL替代了SQL，將CQL作為數據定義與數據管理語言。
HBase也支持Thrift介面和RESTful Web服務介面，不過HBase原生的Java
API向編程人員提供了豐富的功能。雖然HBase的數據操作命令沒有CQL豐富，但是HBase擁有一個「篩選」功能，該功能可以在會話的伺服器端執
行，大幅提升了掃描（搜索）的吞吐量。
HBase還引入了「協處理器」（coprocessors）這一概念，允許在HBase進程中執行用戶代碼。這基本上與關系型資料庫中的觸發和預存進程相同。目前，Cassandra還沒有類似HBase協處理器的功能。
Cassandra的文檔較HBase的更加醒目，並且擁有更加扁平化的學習曲線。設置一個開發用的Cassandra集群比設置HBase集群要更加簡單。當然，這僅對於開發與測試目的來說非常重要。
棘手之處
在必須為特定應用調整集群時，用戶需要做一些工作。在指定數據集大小、創建與管理多節點集群（通常會跨多個數據中心）的復雜度後，調整工作將變得非常棘手。用戶需要深刻理解集群的內存緩存、磁碟存儲和節點間通信之間相互影響，仔細監控集群的活動。
HBase對Zookeeper的依賴會帶來一些額外的故障點。雖然Cassandra避開了這一問題，但這並不意味著Cassandra集群的調整難度會大幅下降。我們對兩個資料庫的集群調整難點進行了對比（如附表所示）。
需要說明的是，這里並沒有確定誰是勝出者，誰是失敗者。每個資料庫的支持者都會找到一些證據來證明他們的系統優於對方。通常用戶需要對兩個資料庫進行測試，然後才能確定它們執行目標應用的情況。
8. 怎麼設置 hbase blockcache 大小
HBase上Regionserver的內存分為兩個部分，一部分作為Memstore，主要用來寫；另外一部分作為BlockCache，主要用於讀。
•寫請求會先寫入Memstore，Regionserver會給每個region提供一個Memstore，當Memstore滿64MB以後，會啟動 flush刷新到磁碟。當Memstore的總大小超過限制時（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），會強行啟動flush進程，從最大的Memstore開始flush直到低於限制。
•讀請求先到Memstore中查數據，查不到就到BlockCache中查，再查不到就會到磁碟上讀，並把讀的結果放入BlockCache。由於BlockCache採用的是LRU策略，因此BlockCache達到上限(heapsize * hfile.block.cache.size * 0.85)後，會啟動淘汰機制，淘汰掉最老的一批數據。
一個Regionserver上有一個BlockCache和N個Memstore，它們的大小之和不能大於等於heapsize * 0.8，否則HBase不能正常啟動。
默認配置下，BlockCache為0.2，而Memstore為0.4。在注重讀響應時間的應用場景下，可以將 BlockCache設置大些，Memstore設置小些，以加大緩存的命中率。
HBase RegionServer包含三個級別的Block優先順序隊列：
•Single：如果一個Block第一次被訪問，則放在這一優先順序隊列中；
•Multi：如果一個Block被多次訪問，則從Single隊列移到Multi隊列中；
•InMemory：如果一個Block是inMemory的，則放到這個隊列中。
以上將Cache分級思想的好處在於：
•首先，通過inMemory類型Cache，可以有選擇地將in-memory的column families放到RegionServer內存中，例如Meta元數據信息；
•通過區分Single和Multi類型Cache，可以防止由於Scan操作帶來的Cache頻繁顛簸，將最少使用的Block加入到淘汰演算法中。
默認配置下，對於整個BlockCache的內存，又按照以下百分比分配給Single、Multi、InMemory使用：0.25、0.50和0.25。
注意，其中InMemory隊列用於保存HBase Meta表元數據信息，因此如果將數據量很大的用戶表設置為InMemory的話，可能會導致Meta表緩存失效，進而對整個集群的性能產生影響。