hbase

Hbase是一個分散式的、持久的、強一致性的儲存系統，具有近似最優的寫效能（能使Ｉ/O利用率達到飽和）和出色的讀效能，他充分利用了磁碟的空間，支援特定列族切換可壓縮演算法。
HBase繼承自BigTable模型，只考慮單一的索引，類似於RDBMS中的主鍵，提供了伺服器端的鉤子，可以實施靈活的輔助索引解決方案。此外，它還提供了過濾器功能。減少了網路傳輸的資料量。
Hbase並未將說明性查詢語言作為核心實現的一部分，對事務的支援也有限。但其原子性和讀－修改－寫
操作在實踐中彌補了這個缺陷，他們覆蓋了大部分的使用場景並消除了在其他系統中經歷過的死鎖，等待問題。
Hbase在進行負載均衡和故障修復時對客戶端是透明的。在生產系統中，系統的可拓展性體現在系統自動伸縮的過程中。更改叢集並不涉及重新全量負載均衡和資料重分割槽，但整個處理過程完全是自動化的。

hbase 的結構以及與其他資料庫結構的差異

１．列式儲存

• 列式儲存資料庫：以列為單位聚合資料，然後將列順序的存入磁碟
• 由於列的資料結構天生是相似的，即時邏輯上有一點輕微的不同，但仍舊比按行儲存聚集在一起的資料更有利於壓縮，因為大多數的演算法只關注於有限的壓縮視窗。像增量壓縮或字首壓縮這類的專業演算法，是基於列儲存的型別定製的。因而大幅度提高了壓縮比。更好的壓縮比有利於阿紫返回結果是降低了頻寬的消耗。

２．行式儲存

• 行式儲存資料庫：連續的儲存整行

３．Hbase以列式儲存的格式在磁碟上儲存資料，但是它與傳統的列式資料庫有很大的不同，傳統的列式儲存資料庫比較適合實時存取資料庫的場景，hbase比較適合鍵值對的資料的存取，或者有序的資料存取

關係資料庫系統的問題

通常這種模式的設計能在較長的一段時間裡滿足需求。如果足夠幸運，每天有越來越多的使用者加入到網站裡面，但隨著網站使用者量的增加，共享資料庫伺服器的壓力會越來越大，然後不得不尋求解決方法
第一步　增加用於並行讀取的應用伺服器，將讀寫分離。這種方案保留了一個主資料庫伺服器，主資料伺服器只服務於寫請求這樣做主要是考慮到網站的請求主要由使用者瀏覽產生，因此寫請求遠遠小於讀請求（缺點：應用伺服器之間是共享中央資料庫的，但隨著共享中央資料庫的cpu和ｉ/o負載的上升，壓力又一次的擴大起來）
第二步　增加快取　如Memcached。現在可以講讀請求接入到高速的在記憶體快取資料的系統中，但是這種方案無法保證資料的一致性，因為使用者更新資料到資料庫中，而資料庫不會主動更新快取中的資料，所以需要儘快地同步快取和資料庫檢視，把更新快取資料與更新資料庫資料的時間最小化。（缺點：一旦主伺服器的寫效能下降，可以把主服務換成加強伺服器，與初始的主伺服器相比要花費更多的金錢。隨著網站的受歡迎程度的增加，網站需要更多新功能，本質上講：減少資料庫中的儲存資料才能優化訪問。）

總之　隨著使用者的額越來越多。負載會不斷提高，為了給使用者提供更快的資料服務。最終，不得不放棄輔助索引的使用，原因是資料量增大時，索引量也大到足以讓資料庫的效能直線下降。最後所能提供的查詢方式只剩下按照主鍵查詢。假如負載壓力再一次加大的話。此時可以考慮將資料分割槽到多個數據庫中，但是這樣以來，運維操作則會變成噩夢。綜上看來，關係型資料庫能夠在應對大型資料時顯得很力不從心，所以nosql資料庫就應運而生了。

什麼時候會考慮非關係型資料庫系統　Not-Only-SQL(NoSql)

１.關係型資料庫和非關係型資料庫的異同
- 相同點：從查詢方式上的限制來說，關係型資料庫和非關係型的資料庫是基本一致的。因為最新的儲存系統不提供SQL查詢資料的手段，只提供一些比較簡單的，類似於api介面的方式來存取資料。但是也有一些工具為Nosql資料儲存提供了SQL語言的入口，用於執行一些關係型資料庫中常用的複雜條件查詢。
- 區別點：兩者在底層上是有區別的，尤其是針對於模式或者ACID事務特性，因為這是與實際的儲存架構相關的。很多這一類新系統（Nosql）首先要做的事情是：拋棄一些限制因素以提升擴充套件性。例如：他們通常不支援事務或者輔助索引。更重要的是：這一類系統沒有固定模式的，可以隨著應用的改變而靈活變化。
２．基於維度上進行考慮
簡單的挑幾種維度來區分非關係型的系統使用的條件
資料模型　資料有多種儲存方式，包括鍵值對，半結構化的列式儲存和文件結構儲存。使用者應該如何存取資料？同時資料模式能否隨著時間而變化？
儲存模型　記憶體還是持久？坦率的來說這個決定並不難，其主要原因是，我們可以將其與RDBMS進行對比，他們通常持久化儲存到磁碟中。即時需要的是純粹的記憶體模式，也仍舊有其他的解決方案。一旦考慮持久化儲存，就需要考慮選擇的方案是否會影響到訪問模式？
物理模型
分散式模式還是單機模式？這種架構看起來像什麼？是僅僅執行在單個機器上，還是分佈在多個機器上，但分佈及擴充套件原則由客戶端管理，換句話說，由使用者自己的程式碼管理？也許分散式模式僅僅是個事後的工作，並且只會在使用者需要擴充套件系統時產生問題。如果系統提供了一定的擴充套件性，那麼需要使用者採取特定的操作嗎？最簡單的而解決方案是一次增加一臺機器，並且設定好分割槽（這點對於不支援虛擬分割槽的系統非常重要），設定時需要考慮同時提高每個分割槽的能力，因為系統的每個部分都需要提供均衡的效能。
讀寫效能
使用者必須瞭解自己的應用程式的訪問模式。是讀多寫少，還是讀寫相當？或者是讀少寫多？是用範圍掃描資料好，還是用隨機讀請求資料更好？有些系統僅對這些系統的一種支援的非常好，有些系統則是對各種情況都有良好的支援。
輔助索引
輔助索引支援使用者按不同的欄位和排序方式來訪問表。這個維度覆蓋了某些完全沒有索引支援且不保證資料排序的系統（類似與HashMap），到某些可能通過外部手段簡單的支援這些功能的系統，如果儲存系統不提供這項功能，使用者的應用可以應對或自己模擬輔助索引嗎？
故障處理
機器會崩潰是一個客觀存在的問題，需要有一套資料遷移方案來應對這種情況。每個資料儲存如何進行伺服器的故障處理？故障處理完畢後是否可以正常的工作？如果替換故障伺服器，那麼恢復100%伺服器的難度有多大？從一個正在提供服務的叢集解除安裝一臺伺服器時，也會遇到類似的問題。
壓縮
當用戶需要處理TB級別的資料時，尤其當這些資料差異性很小或由可讀性文字組成的壓縮時，壓縮會帶來非常好的效果，既能節省大量的原始資料儲存。有些壓縮演算法可以江此類資料壓縮到原始檔案大小的十分之一。有可選擇的壓縮元件嗎？又有哪些壓縮演算法可用？
負載均衡
加入使用者有高讀寫吞吐率的需求，就需要考慮一套能隨著負載變化自動均衡處理能力的系統。能夠幫助使用者設計高讀寫吞吐量的程式。
原子操作的讀－修改－寫
RDBMS提供了很多這類的操作（因為它是一個集中式的面向伺服器的系統），但是這些操作在分散式系統中較難實現，這些操作可以幫助使用者避免多執行緒造成的資源競爭，也可以幫助使用者完成無共享應用伺服器的設計。有了這些比較並交換操作，或者說檢查並設定的操作，在設計系統的時候可以有效的降低客戶端的複雜度。
加鎖，等待和死鎖
眾所周知，複雜的事務處理，如兩階段的提交。會增加多個客戶端競爭同一個資源的可能性。最糟糕的情況就是死鎖，這種情況很難解決。使用者需要支援的系統採用哪種鎖模型？這種鎖模型能否避免等待和死鎖？
回顧這些維度，來綜合看一下Hbase適用在哪裡，其優勢何在，從而來正確的找到解決方案。