2013年6月9日 星期日

關於BigData的基本問題 - 到底要多大?要多快?

圖片來源:technode

關於BigData的基本問題 - 到底要多大?要多快? 才需要從RDB 換到Hadoop?我們常常可以看到下面這種再說明全世界一直再快速的產生資料:



但是這些東西都離我們太遠了,畢竟我們不是Facebook,我們也不是youtube,那對於一般企業來說怎樣的資料算是大?怎樣的資料量需要轉移使用Hadoop的技術呢?

首先要思考的問題是傳統資料庫在怎樣的資料量下,擁有怎樣的效能是合理的?當資料量超過多少以後,則效能才會有顯著的差異,此時才比較適合換成NoSQL Solution? 不過這個問題可能還是得分成兩種狀況來討論:
  • 資源足夠的大企業(大多以Oracle為首選標準配備)
  • 一般網路公司中小企業 (可能就是用MySQL / PostgreSQL...等選擇)


那先來看看Oracle,剛好我Google到一篇文章-What is The Maximum Datafile Size Limit In Oracle Database 10gR2 ,這篇文章參考Oracle 11g 提供的文件 Physical Database Limits,主要是再描述Oracle可以儲存多少的資料,一般來說Oracle有兩種 Database Block Size:
  • Small File Tablespace (Normal Tablespace)       : 4194303    (2^22 -1) 
  • Big File Tablespace   (New in 10gR2)                : 4294967295 (2^32 -1) 
Database Block Size
Maximum Datafile File Size
2k
4194303 * 2k    = 8 GB
4k
4194303 * 4k    = 16 GB
8k
4194303 * 8k    = 32 GB
16k
4194303 * 16k  = 64 GB
32k
4194303 * 32k  = 128 GB

Max datafile size for BIG FILE TABLESPACE would be:

Database Block Size
Maximum Datafile Size
2k
4294967295 * 2k   = 8 TB
4k
4294967295 * 4k   = 16 TB
8k
4294967295 * 8k   = 32 TB
16k
4294967295 * 16k = 64 TB
32k
4294967295 * 32k = 128 TB

如果block size 是32KB,則單表空間(DataFile Size)最大可以長到128TB,而一個數據庫最多有64K表空間,則可以計算出理論上的極限值是128TB *64 K= 8192 PB= 8EB 這是能儲存的理論極限值,但是實務上不可能會這樣使用,更何況還要考慮其他因素,比如說做系統的的FileSystem,實際硬體的儲存媒介...等。

不過知道可以存多少有意義嘛?資料庫之所以有意義,重點不是在於能儲存多少,而是這麼多資料能在多少時間內Query出來,因為資料越多Performance 一定會越糟,而傳統DB又只能用Scale Up的方式去擴增,不像Hadoop是用Scale Out的方式,關於這點我們可以參考Oracle的這篇文章,Sizing for data volume or performance or both?,近幾年來Oracle也提出不少與Hadoop借接混搭的Solution & Architecture,以及Big Data Appliance ,那他怎麼看待這個基準線呢?直接節錄結論:
You will need to worry about the processing requirements and you will need to understand the characteristics of the machine and the data. You should not size a system, or discard something as too big right away by just thinking about your raw data size. You should really, really consider Hadoop to be a system that scales processing and data storage together and use the benefits of the scale-out to balance data size with runtimes.

雖然Hadoop的硬碟花費可能會是傳統DB的 三倍以上,但是他可以透過增加機器來維持甚至增加運算的效能,所以我好奇的是Break Even point 在哪裡?怎樣的資料才需要使用這些技術? 不然這些"為了未來Scale out 做準備 "的 slogan 就只是一般商業行銷用的話術, 很多網站和企業說實在資料根本不會成長到那麼大....)


基於這個問題我開始上網找一些資料,首先先來看看業界的實際案例,到底在怎樣的資料大小下,傳統的RDB會出現無法接受的效能呢?

案例一:Hadoop World 2011: Replacing RDB/DW with Hadoop and Hive for Telco Big Data

這是國外一家電信商在做CDR分析的案例,每個月將近15TB的資料, 一年可以達到254TB


案例二:Case Study - How Rackspace Query Terabytes Of Data
  • Rackspace has more than 50K device
  • System store 800 million object (an object=email or log) within Solr
  • 9.6 billion records within Hadoop = 6.3TB compressed
  • Several hundred gigabytes of email log data

案例三:Hadoop Use Cases and Case Studies

在這裡面有列出各個產業的案例以及資料量,最低標準至少是 1TB of data / month


其實沒有一個定論,只能引用Agile與Lean的名言:No Big Design Up Front (BDUF),不要預先想太多太早最佳化,可能我們應該就像這家遊戲廠商一樣,真的遇到大量資料的問題了在想辦法轉移就好~:P




張貼留言