上次做了一個(gè)系統(tǒng)碰到的問(wèn)題

027xiatian

從原始的apache日志分析，到入庫(kù)，到各種維度的報(bào)表統(tǒng)計(jì)，前端日志分析階段采用的是shell,perl,后端采用的是infobright,整個(gè)統(tǒng)計(jì)系統(tǒng)分成多層（分層目的也是為了高度復(fù)用，避免寫入與業(yè)務(wù)有關(guān)的代碼),
所以整個(gè)過(guò)程比較長(zhǎng)，為了捕獲每一個(gè)階段可能出現(xiàn)的異常，在每一層都會(huì)向狀態(tài)表插入該層處理是否成功的標(biāo)示，來(lái)達(dá)到后期自動(dòng)修補(bǔ)的目的。
目前統(tǒng)計(jì)系統(tǒng)出發(fā)點(diǎn)也就利用ib的高壓縮比，SQL查詢的高效,  帶來(lái)的好處也不用說(shuō)（存儲(chǔ)的壓力較小，統(tǒng)計(jì)報(bào)表的時(shí)效性優(yōu)越），在這個(gè)基礎(chǔ)之上的數(shù)據(jù)開(kāi)發(fā)的效率也比較快，只需要填寫相應(yīng)的配置項(xiàng)，SQL語(yǔ)句就可以將報(bào)表統(tǒng)計(jì)完成，將開(kāi)發(fā)人員的精力集中在業(yè)務(wù)層面，做業(yè)務(wù)層面的開(kāi)發(fā)，抽出時(shí)間，精力做業(yè)務(wù)。
弊端也相當(dāng)明顯:
   1.ICE對(duì)復(fù)雜SQL的準(zhǔn)確性有些bug，基本在目前的統(tǒng)計(jì)中，沒(méi)有采用很復(fù)雜的SQL(同過(guò)系統(tǒng)分層來(lái)解決這個(gè)問(wèn)題)
    2.數(shù)據(jù)容災(zāi)上，采取冗余備份的策略（雖然耗費(fèi)磁盤，目前也沒(méi)有好的方法來(lái)處理 了)
    3.現(xiàn)在由于表的規(guī)模已經(jīng)達(dá)到幾億級(jí)別（infobright)，做表的導(dǎo)入導(dǎo)出碰到一些問(wèn)題，ICE不支持DML, 雖然寫腳本來(lái)完成類似的insert,delete,alter的通用功能模塊，但隨著表規(guī)模的擴(kuò)大，那么這種操作的時(shí)間開(kāi)銷是越來(lái)越大��！目前有沒(méi)有其他的更好的方案呢？(目前正在找解決方法)

027xiatian

結(jié)貼，已經(jīng)通過(guò)其他的策略搞定!