Hbase與Oracle的比較

標籤：

http://blog.csdn.net/lucky_greenegg/article/details/47070565

 

轉自：http://www.cnblogs.com/chay1227/archive/2013/03/17/2964020.html

轉自：http://blog.csdn.net/allen879/article/details/40461227

轉自：http://blog.itpub.net/28912557/viewspace-776770/

 

由於項目需要，將原來的系統升級需要用到Hbase技術，使用了之後發現，確實很不錯。那麼問題來了，為什麼在這裡要用Hbase，而不是以前的關係型資料庫Oracle，他們各自有什麼特點，應用情境有何不同？帶著問題去學習效果會更好。

 

首先來看關係型資料庫與NoSQL的對比：

 

關係型資料庫把所有的資料都通過行和列的二元表現形式表示出來。

 

關係型資料庫的優勢：

1. 保持資料的一致性（交易處理）

2.由於以標準化為前提，資料更新的開銷很小（相同的欄位基本上都只有一處）

3. 可以進行Join等複雜查詢

其中能夠保持資料的一致性是關係型資料庫的最大優勢。

 

關係型資料庫的不足：

不擅長的處理

1. 大量資料的寫入處理

2. 為有資料更新的表做索引或表結構（schema）變更

3. 欄位不固定時應用

4. 對簡單查詢需要快速返回結果的處理

--大量資料的寫入處理

讀寫集中在一個資料庫上讓資料庫不堪重負，大部分網站已使用主從複製技術實現讀寫分離，以提高讀寫效能和讀庫的可擴充性。

所以在進行大量資料操作時，會使用資料庫主從模式。資料的寫入由主要資料庫負責，資料的讀入由從資料庫負責，可以比較簡單地通過增加從資料庫來實現規模化，但是資料的寫入卻完全沒有簡單的方法來解決規模化問題。

第一，要想將資料的寫入規模化，可以考慮把主要資料庫從一台增加到兩台，作為互相關聯複製的二元主要資料庫使用，確實這樣可以把每台主要資料庫的負荷減少一半，但是更新處理會發生衝突，可能會造成資料的不一致，為了避免這樣的問題，需要把對每個表的請求分別分配給合適的主要資料庫來處理。

第二，可以考慮把資料庫分割開來，分別放在不同的資料庫伺服器上，比如將不同的表放在不同的資料庫伺服器上，資料庫分割可以減少每台資料庫伺服器上的資料量，以便減少硬碟IO的輸入、輸出處理，實現記憶體上的高速處理。但是由於分別儲存字不同伺服器上的表之間無法進行Join處理，資料庫分割的時候就需要預先考慮這些問題，資料庫分割之後，如果一定要進行Join處理，就必須要在程式中進行關聯，這是非常困難的。

 

 

--為有資料更新的表做索引或表結構變更

在使用關係型資料庫時，為了加快查詢速度需要建立索引，為了增加必要的欄位就一定要改變表結構，為了進行這些處理，需要對錶進行共用鎖定定，這期間資料變更、更新、插入、刪除等都是無法進行的。如果需要進行一些耗時操作，例如為資料量比較大的表建立索引或是變更其表結構，就需要特別注意，長時間內資料可能無法進行更新。

 

--欄位不固定時的應用

如果欄位不固定，利用關係型資料庫也是比較困難的，有人會說，需要的時候加個欄位就可以了，這樣的方法也不是不可以，但在實際運用中每次都進行反覆的表結構變更是非常痛苦的。你也可以預先設定大量的預備欄位，但這樣的話，時間一長很容易弄不清除欄位和資料的對應狀態，即哪個欄位儲存有哪些資料。

--對簡單查詢需要快速返回結果的處理  （這裡的“簡單”指的是沒有複雜的查詢條件）

這一點稱不上是缺點，但不管怎樣，關係型資料庫並不擅長對簡單的查詢快速返回結果，因為關係型資料庫是使用專門的sql語言進行資料讀取的，它需要對sql與越南進行解析，同時還有對錶的鎖定和解鎖等這樣的額外開銷，這裡並不是說關係型資料庫的速度太慢，而只是想告訴大家若希望對簡單查詢進行高速處理，則沒有必要非使用關係型資料庫不可。

---------------------------

NoSQL資料庫

關係型資料庫應用廣泛，能進行交易處理和表串連等複雜查詢。相對地，NoSQL資料庫只應用在特定領域，基本上不進行複雜的處理，但它恰恰彌補了之前所列舉的關係型資料庫的不足之處。

優點：

 易於資料的分散

各個資料之間存在關聯是關係型資料庫得名的主要原因，為了進行join處理，關係型資料庫不得不把資料存放區在同一個伺服器內，這不利於資料的分散，這也是關係型資料庫並不擅長大資料量的寫入處理的原因。相反NoSQL資料庫原本就不支援Join處理，各個資料都是獨立設計的，很容易把資料分散在多個伺服器上，故減少了每個伺服器上的資料量，即使要處理大量資料的寫入，也變得更加容易，資料的讀入操作當然也同樣容易。

 

典型的NoSQL資料庫

臨時性KVStore for Redis（memcached、Redis）、永久性KVStore for Redis（ROMA、Redis）、面向文檔的資料庫（MongoDB、CouchDB）、面向列的資料庫（Cassandra、HBase）

一、 KVStore for Redis

它的資料是以索引值的形式儲存的，雖然它的速度非常快，但基本上只能通過鍵的完全一致查詢擷取資料，根據資料的儲存方式可以分為臨時性、永久性和兩者兼具 三種。

（1）臨時性

      所謂臨時性就是資料有可能丟失，memcached把所有資料都儲存在記憶體中，這樣儲存和讀取的速度非常快，但是當memcached停止時，資料就不存在了。由於資料儲存在記憶體中，所以無法操作超出記憶體容量的資料，舊資料會丟失。總結來說：

      。在記憶體中儲存資料

      。可以進行非常快速的儲存和讀取處理

      。資料有可能丟失

 （2）永久性

       所謂永久性就是資料不會丟失，這裡的KVStore for Redis是把資料儲存在硬碟上，與臨時性比起來，由於必然要發生對硬碟的IO操作，所以效能上還是有差距的，但資料不會丟失是它最大的優勢。總結來說：

       。在硬碟上儲存資料

       。可以進行非常快速的儲存和讀取處理（但無法與memcached相比）

       。資料不會丟失

（3） 兩者兼備

       Redis屬於這種類型。Redis有些特殊，臨時性和永久性兼具。Redis首先把資料儲存在記憶體中，在滿足特定條件（預設是 15分鐘一次以上，5分鐘內10個以上，1分鐘內10000個以上的鍵發生變更）的時候將資料寫入到硬碟中，這樣既確保了記憶體中資料的處理速度，又可以通過寫入硬碟來保證資料的永久性，這種類型的資料庫特別適合處理數群組類型的資料。總結來說：

       。同時在記憶體和硬碟上儲存資料

       。可以進行非常快速的儲存和讀取處理

       。儲存在硬碟上的資料不會消失（可以恢複）

       。適合於處理數群組類型的資料

     

二、面向文檔的資料庫

   MongoDB、CouchDB屬於這種類型，它們屬於NoSQL資料庫，但與KVStore for Redis相異。

   （1）不定義表結構

　　   即使不定義表結構，也可以像定義了表結構一樣使用，還省去了變更表結構的麻煩。

   （2）可以使用複雜的查詢條件 

　　   跟KVStore for Redis不同的是，面向文檔的資料庫可以通過複雜的查詢條件來擷取資料，雖然不具備交易處理和Join這些關係型資料庫所具有的處理能力，但初次以外的其他處理基本上都能實現。

三、 面向列的資料庫

   Cassandra、HBae、HyperTable屬於這種類型，由於近年來資料量出現爆發性增長，這種類型的NoSQL資料庫尤其引入注目。

   普通的關係型資料庫都是以行為單位來儲存資料的，擅長以行為單位的讀入處理，比如特定條件資料的擷取。因此，關係型資料庫也被成為面向行的資料庫。相反，面向列的資料庫是以列為單位來儲存資料的，擅長以列為單位讀入資料。

面向列的資料庫具有搞擴充性，即使資料增加也不會降低相應的處理速度（特別是寫入速度），所以它主要應用於需要處理大量資料的情況。另外，把它作為批次程式的儲存空間來對大量資料進行更新也是非常有用的。但由於面向列的資料庫跟現行資料庫儲存的思維方式有很大不同，故應用起來十分困難。

 

總結：關係型資料庫與NoSQL資料庫並非對立而是互補的關係，即通常情況下使用關係型資料庫，在適合使用NoSQL的時候使用NoSQL資料庫，讓NoSQL資料庫對關係型資料庫的不足進行彌補。

 

 

Hbase與Oracle比較（列式資料庫與行式資料庫）

1 主要區別

1.1、Hbase適合大量插入同時又有讀的情況

1.2、 Hbase的瓶頸是硬碟傳輸速度，Oracle的瓶頸是硬碟尋道時間。

  Hbase本質上只有一種操作，就是插入，其更新操作是插入一個帶有新的時間戳記的行，而刪除是插入一個帶有插入標記的行。其主要操作是收集記憶體中一批資料，然後批量的寫入硬碟，所以其寫入的速度主要取決於硬碟傳輸的速度。Oracle則不同，因為他經常要隨機讀寫，這樣硬碟磁頭需要不斷的尋找資料所在，所以瓶頸在於硬碟尋道時間。

 

1.3、Hbase很適合尋找按照時間排序top n的情境

1.4、索引不同造成行為的差異。

1.5、Oracle 既可以做OLTP又可以做OLAP，但在某種極端的情況下(負荷十分之大)，就不適合了。

 

2 Hbase的局限：

 

1、只能做簡單的Key value查詢，複雜的sql統計做不到。

2、只能在row key上做快速查詢。

 

3 傳統資料庫的行式儲存

    在資料分析的情境裡面，我們經常是以某個列作為查詢條件，返回的結果經常也只是某些列，不是全部的列。行式資料庫在這種情況下的I/O效能會很差，以Oracle為例，Oracle會有一個很大的資料檔案，在這個資料檔案中，劃分了很多block，然後在每個block中放入行，行是一行一行放進去，擠在一起，然後把block塞滿，當然也會預留一些空間，用於將來update。這種結構的缺點是：當我們讀某個列的時候，比如我們只需要讀紅色標記的列的時候，不能唯讀這部分資料，我必須把整個block讀取到記憶體中，然後再把這些列的資料取出來，換句話說，我為了讀表中某些列的資料，我必須把整個列的行讀完，才可以讀到這些列。如果這些列的資料很少，比如1T的資料中只佔了100M, 為了讀100M資料卻要讀取1TB的資料到記憶體中去，則顯然是不划算。

3.1 B+索引

 

    Oracle中採用的資料訪問技術主要是B數索引：

 

從樹的跟節點出發，可以找到葉子節點，其記錄了key值對應的那行的位置。

 

對B樹的操作：

    B樹插入——分裂節點

     B數刪除——合并節點

4 列式儲存

      同一個列的資料會擠在一起，比如擠在block裡，當我需要讀某個列的時候，值需要把相關的檔案或塊讀到記憶體中去，整個列就會被讀出來，這樣I/O會少很多。

      同一個列的資料的格式比較類似，這樣可以做大幅度的壓縮。這樣節省了儲存空間，也節省了I/O,因為資料被壓縮了，這樣讀的資料量隨之也少了。 

      行式資料庫適合OLTP，反倒列式資料庫不適合OLTP。

 

 

4.1 BigTable的LSM（Log Struct Merge）索引

 

     在Hbase中日誌即資料，資料就是日誌，他們是一體化的。為什麼這麼說了，因為Hbase的更新時插入一行，刪除也是插入一行，然後打上刪除標記，則不就是日誌嗎？

     在Hbase中，有Memory Store,還有Store File，其實每個Memory Store和每個Store File就是對每個列族附加上一個B+樹(有點像Oracle的索引組織表，資料和索引是一體化的)， 也就是圖的下面是列族，上面是B+樹，當進行資料的查詢時，首先會在記憶體中memory store的B+樹中尋找，如果找不到，再到Store File中去找。

     如果找的行的資料分散在好幾個列族中，那怎麼把行的資料找全呢？那就需要找好幾個B+樹，這樣效率就比較低了。所以盡量讓每次insert的一行的列族都是稀疏的，只在某一個列族上有值，其他列族沒有值，

一，索引不同造成行為的差異
Hbase只能建立一個主鍵索引，而且之後的資料查詢也只能基於該索引進行簡單的key-value查詢；
但是Oracle可以建立任意索引，也可以按照任意列進行資料查詢。

二，Hbase適合大量插入同時又有讀的情況，讀一般為key-value查詢
大資料、高並發正合Hbase的胃口

三，Hbase的瓶頸是硬碟傳輸速度，Oracle的瓶頸是硬碟尋道時間
Hbase都是大量往硬碟上寫資料（沒有delete、update，都是insert），即使是讀資料，也是優先MemStore，所以硬碟傳輸速度成為其瓶頸；
而Oracle由於具有隨機訪問特性（select、update等），所以硬碟尋道時間成為其瓶頸，而尋道時間主要由轉速決定。

四，Hbase很適合尋找按照時間排序top n的情境
因為Hbase的資料都具有時間戳記（Hbase預設就有時間戳記）

行式儲存：

行式儲存：
資料存放在資料檔案內
資料檔案的基本組成單位：塊/頁（一行接一行存在block中，當然block不會填滿，預留空間進行行的操作，譬如：update）
塊內結構：塊頭、資料區
為了select橘紅色的列，行式資料庫會把整個block加在到記憶體，然後篩選出所需列。
而對於Hbase而言，由於資料存放區特性，資料以列族為單位進行儲存，一個檔案Block Storage的都是同一個列族的資料），
這樣，查詢會比行式資料庫最佳化很多。

另外，由於在Hbase中，同一個列裡面資料格式比較接近，或者長度相近，從而可以對資料進行大幅度的壓縮，
結果就是節省了硬碟空間，也減少了IO

Hbase與Oracle的比較