MySQL版《一周一議》之基于mysql的DW(數(shù)據(jù)倉庫)/BI(商務(wù)智能)解決方案（積分已轉(zhuǎn)賬）

chinafenghao

積分已轉(zhuǎn)賬，請注意查收！

         上上周我們開出了CU mysql板塊每周一議的話題征集帖子，關(guān)注的網(wǎng)友還是挺多的。上周是mysql板《一周一議》的第一個話題，在確定話題的時候，我也在想會不會選的這個話題難度太大，導(dǎo)致曲高和寡,但是反過來一想，如果沒有高的曲，高手是不愿意現(xiàn)身說法的，所以冒著挺大的風(fēng)險發(fā)布了第一周的話題。總的來說第一期的效果還是不錯的，謝謝各位mysqler和cuer的大力支持。

現(xiàn)在隆重宣布上周獲得《mysql技術(shù)內(nèi)幕，SQL技術(shù)編程》的用戶是：hbsycw。
其他參與討論的用戶到將至少獲得20積分,積分是需要管理員手工加，加上后會發(fā)站內(nèi)信的。

本周的話題是主要和大數(shù)據(jù)量有關(guān)系。

基于mysql的DW(數(shù)據(jù)倉庫)/BI(商務(wù)智能)解決方案。
DW和BI使用的數(shù)據(jù)庫軟件主要有以下特點：
1、數(shù)據(jù)量大  2、大量的OLAP處理  3、數(shù)據(jù)結(jié)構(gòu)的變化 4、分析需求變化 5、數(shù)據(jù)安全和備份

一個好的數(shù)據(jù)倉庫應(yīng)該有以下特點：
1、效率足夠高
2、數(shù)據(jù)質(zhì)量好
3、擴展性強

本話題主要包括以下幾個討論點。
1、你知道的mysql在DW/BI方面的應(yīng)用案例,及案例相關(guān)的架構(gòu)描述，包括數(shù)據(jù)庫倉庫模型設(shè)計和ETL相關(guān)的信息。

2、mysql在DW/BI應(yīng)用上的主要限制？

3、在管理基于mysql的DW/BI系統(tǒng)時候，你遇見的挑戰(zhàn)和解決方案？

4、如果大家沒有做過BI或者DW相關(guān)的項目，可以聊聊你管理的mysql的size情況，比如單表最大多少，單庫最大多少，在數(shù)據(jù)量上去以后出現(xiàn)的問題及解決方案等等？

活動獎勵:
1、每周會評選一位最活躍的用戶，有一本mysql相關(guān)的書籍送出,本周送出的書籍是《數(shù)據(jù)挖掘(概念與技術(shù))》由機械工業(yè)出版社出版。
2、由于是話題討論，所以每位參加者都能獲得適當(dāng)?shù)姆e分獎勵。最低20分，最高不限,^_^想要賺分的朋友也可以來湊熱鬧喲。

chinafenghao

我還是先來嘮叨幾句吧。

我知道也有那么幾個公司的DW和BI是基于mysql的。不過主要還是用來分析業(yè)務(wù)數(shù)據(jù)而不是日志，所以數(shù)據(jù)量不算很大。

如果你之前的業(yè)務(wù)數(shù)據(jù)使用的是mysql存儲，那么你DW使用mysql的話數(shù)據(jù)兼容性很好。可以通過federated和stored process來很快的實現(xiàn)ETL,并且程序的開發(fā)成本也會比較低，不會有太多新的接口技術(shù),開發(fā)在實施起來也比較快。

缺點就是對大數(shù)據(jù)量的存儲和查詢會比較老火，如果這邊的情況是當(dāng)單表上百G，單表記錄數(shù)上1E的時候，做聚合和DDL都會很慢，相對于oracle會慢很多。

infobright是個好東西，壓縮比相當(dāng)高，查詢速度也很快。不過社區(qū)版的不能DDL和DML，相當(dāng)?shù)疤郏�也不能和其他引擎的表關(guān)聯(lián)查詢也是一大限制,如果使用商業(yè)版，或者你的接受每次使用 load data infile操作的話，還是不錯的選擇。

樓下請繼續(xù)....

action08

不熟悉哦，


2、mysql在DW/BI應(yīng)用上的主要限制？

老話題，還是io，

chinafenghao

@action08
我不太認同。
我覺得還是mysql對OLAP的優(yōu)化不夠。在相同硬件下，mysql在OLAP的效率上和ORACLE有很大差距。

action08

回復(fù) 4# chinafenghao


    oracle太會吃內(nèi)存了，缺點這時就成 了優(yōu)點

chinafenghao

@action08
我說的是相同硬件情況下。mysql如果用innodb和oracle使用的內(nèi)存差不多的。oracle也不是說一定要吃你好多內(nèi)存，肯定內(nèi)存多了效率高。
我這里不是說mysql不好，我只是客觀的表達mysql在OLAP上面的不足。

對于100G的mysql表來說，給一列建立一個索引，如果表大概10列，沒列長度差不多,那么索引文件的大小應(yīng)該在1/10左右，至少5個G以上。
但是對于oracle，使用BITMAP索引，100G的數(shù)據(jù)庫，建立一個索引只有幾百M，你說OLAP取讀5G的索引塊還是讀幾百M的索引塊呢。

action08

chinafenghao 發(fā)表于 2012-11-20 10:58
@action08
我說的是相同硬件情況下。mysql如果用innodb和oracle使用的內(nèi)存差不多的。oracle也不是說一定要 ...

誰快誰慢關(guān)鍵看數(shù)據(jù)結(jié)構(gòu)的呀，不見得index file幾G的速度就比不上幾百M的。。

不僅僅是OLAP，很多程序都喜歡將很多問題交給數(shù)據(jù)庫，操作系統(tǒng)，而不是自己處理潛在的細節(jié)問題。oracle貌似做的就是這種人的市場

chinafenghao

@action08
當(dāng)然，如果你公司有能力做一個很牛B的中間件，確實可以彌補這個問題。但是對于一般的公司可能很難實現(xiàn)。我討論的只是單獨數(shù)據(jù)庫層面的處理能力。

hbsycw

回復(fù) 1# chinafenghao

感謝CU,感謝chinafenghao


   

hbsycw

本周話題很有意思，不過，對于BI/DW應(yīng)用，MYSQL應(yīng)該不是它的強項~