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

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

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

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

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

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

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