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

圖片來源：technode

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

How BIG is Big Data? infographic

但是這些東西都離我們太遠了，畢竟我們不是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

Big Data at Riot Games from Hadoop_Summit