【小編碎語】有人會(huì)選擇，就有人會(huì)放棄，它是否是新型數(shù)據(jù)庫的“弄潮兒”呢？我們依舊要繼續(xù)觀望。

公司開始新項(xiàng)目時(shí)部分?jǐn)?shù)據(jù)服務(wù)選擇使用MongoDB,而且在同事內(nèi)部作了MongoDB應(yīng)用的掃盲介紹，當(dāng)時(shí)貌似Mysql派和MongoDB派相互之間都沒有能說服對方，所以MongoDB的使用就一直延續(xù)下來。直到幾天前，在考慮系統(tǒng)上線發(fā)布和運(yùn)營時(shí)，一些問題出現(xiàn)了。

1.MongoDB存儲(chǔ)文件會(huì)急劇增大，如果使用32位操作系統(tǒng)很容易達(dá)到單個(gè)文件體積上限。所以對于MongoDB必須使用64位操作系統(tǒng)，而在亞馬遜的EC2中只有是large以上類型的instance的CPU才是64位。

2.MongoDB一般都推薦是多點(diǎn)部署，互為鏡像，這樣保證服務(wù)的延續(xù)性和數(shù)據(jù)的安全性。所以如果需要提供穩(wěn)定的服務(wù)，至少需要2臺(tái)EC2的instance來作MongoDB服務(wù)。而實(shí)際對于我們大數(shù)據(jù)量計(jì)算操作可能在一天內(nèi)累計(jì)只有大概1小時(shí)，其余時(shí)間更多只是少量數(shù)據(jù)查詢操作。

綜合以上兩點(diǎn)，如果繼續(xù)使用MongoDB,至少需要兩臺(tái)large以上instance，并且是7X24小時(shí)運(yùn)行，感覺是對運(yùn)算能力的浪費(fèi)。

再三討論后我們決定暫時(shí)放棄MongoDB, 將這部分的運(yùn)算改為使用MapReduce 來處理。亞馬遜的MapReduce可以充分體現(xiàn)按需使用運(yùn)算能力的特性，在使用MapReduce完成所有計(jì)算需要后，再將需要查詢使用的結(jié)果數(shù)據(jù)導(dǎo)入到Mysql數(shù)據(jù)庫中。這樣即滿足了那1小時(shí)內(nèi)需要的運(yùn)行能力，又滿足了其余時(shí)間對計(jì)算結(jié)果的查詢需求。

通過以上的事例，說明在使用云計(jì)算平臺(tái)時(shí)，對程序開發(fā)技術(shù)的選型必須充分考慮到平臺(tái)能夠提供虛擬硬件設(shè)備的技術(shù)指標(biāo)。并且需要轉(zhuǎn)變以往的設(shè)計(jì)思路，更多考慮到云平臺(tái)方便啟動(dòng)和關(guān)閉instance的特性。盡量減少7X24長時(shí)間使用相同一臺(tái)instance作服務(wù)的應(yīng)用，如果這樣的服務(wù)無法避免時(shí)，應(yīng)該考慮多臺(tái)冗余，并在程序設(shè)計(jì)中去除對instance的內(nèi)網(wǎng)ip地址耦合，當(dāng)某臺(tái)instance出現(xiàn)故障而需要更新新的instance時(shí)，內(nèi)網(wǎng)ip 地址變化不會(huì)導(dǎo)致程序無法正常運(yùn)行。

【編輯推薦】

1. Mongodb源碼分析--內(nèi)存文件映射(MMAP)
2. 走進(jìn)MongoDB的世界 展開MongoDB的學(xué)習(xí)之旅
3. 淺析Mongodb源碼之游標(biāo)Cursor
4. 野心勃勃的NoSQL新貴 MongoDB應(yīng)用實(shí)戰(zhàn)
5. MongoDB與CouchDB全方位對比