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

laputa73

主要學(xué)習(xí)。
也很關(guān)心mysql的單表size,早年mysql4 出國(guó)數(shù)據(jù)過文件經(jīng)常損壞的問題，就切換到oracle 了
后續(xù)mysql上沒再做過大量的數(shù)據(jù)操作。

chinafenghao

@laputa73
確實(shí)，如果mysql單表數(shù)據(jù)量太大，又是OLTP操作的話，就要繞點(diǎn)彎子了。

chinafenghao

@seesea2517
你們?cè)磾?shù)據(jù)不會(huì)增加字段？或者說重復(fù)導(dǎo)入了，需要?jiǎng)h除數(shù)據(jù)的情況？

seesea2517

回復(fù) 23# chinafenghao


    表結(jié)構(gòu)當(dāng)然是比較穩(wěn)定的了，有變動(dòng)當(dāng)然是有，但那是很少的了。另外我們按月分表存放，所以如果有變動(dòng)的話也影響不大。
數(shù)據(jù)重復(fù)這個(gè)問題誰惹的禍就誰自己解決唄，哈哈。

hero--008

目前一些初創(chuàng)型公司or中小型公司，互聯(lián)網(wǎng)公司在做數(shù)據(jù)分析時(shí)（他們可能不叫BI/DW/EDW）很多使用mysql。用商用數(shù)據(jù)庫的多數(shù)還是一些傳統(tǒng)行業(yè) 大型公司，這些公司一般都比較稱錢。BI/DW主要是基于歷史數(shù)據(jù)進(jìn)行分析、挖掘，數(shù)據(jù)變化幾率較小，因此基于MyISAM引擎的mysql表會(huì)是一個(gè)很好選擇（數(shù)據(jù)量不是超大的話）。我們這邊目前采集的日志數(shù)據(jù)會(huì)存放到Mysql中，DW還是基于oracle的。Mysql比較大的表數(shù)據(jù)量都上E了，單表存儲(chǔ)7-8G左右吧，按天進(jìn)行了分區(qū)，每月底會(huì)自動(dòng)添加下月的分區(qū)，自動(dòng)備份刪除超過三個(gè)月的分區(qū)數(shù)據(jù)。

laputa73

回復(fù) 25# hero--008
myisam類型也可以支持分區(qū)了么？
除了按時(shí)間，可以按其他字段hash分區(qū)么
那樣的話，確實(shí)可是考慮把分析部分的數(shù)據(jù)移到mysql
感覺做OLAP還是可以的


   

crazyhadoop

現(xiàn)在互聯(lián)網(wǎng)用mysql搞bi真心不給力了，還是hbase靠譜，這也源于數(shù)據(jù)的組織形式~現(xiàn)在都是非關(guān)系型的數(shù)據(jù)偏多~hbase這樣的列數(shù)據(jù)庫更有優(yōu)勢(shì)

shang2010

@hero--008

能談一下你們mysql業(yè)務(wù)是怎么做分區(qū)的么？？

syzxlyx

chinafenghao 發(fā)表于 2012-11-22 14:22
@laputa73
確實(shí)，如果mysql單表數(shù)據(jù)量太大，又是OLTP操作的話，就要繞點(diǎn)彎子了。

大家去微薄看看淘寶道歉信吧，雙十一時(shí)大家新高彩烈的，頂住壓力了，可現(xiàn)在投訴來了，分庫分表是一種手段，但肯定放棄了一些一致性要求。

yezj2004

謝謝樓主，樓主太好人了