爲什麼我們放棄使用MongoDB

     公司開始新項目時部分數據服務選擇使用MongoDB,而且在同事內部作了MongoDB應用的掃盲介紹,當時貌似Mysql派和MongoDB派相互之間都沒有能說服對方,所以MongoDB的使用就一直延續下來。直到幾天前,在考慮系統上線發佈和運營時,一些問題出現了。

 

1.MongoDB存儲文件會急劇增大,如果使用32位操作系統很容易達到單個文件體積上限。所以對於MongoDB必須使用64位操作系統,而在亞馬遜的EC2中只有是large以上類型的instanceCPU纔是64位。

2.MongoDB一般都推薦是多點部署,互爲鏡像,這樣保證服務的延續性和數據的安全性。所以如果需要提供穩定的服務,至少需要2EC2instance來作MongoDB服務。而實際對於我們大數據量計算操作可能在一天內累計只有大概1小時,其餘時間更多隻是少量數據查詢操作。

 

      綜合以上兩點,如果繼續使用MongoDB,至少需要兩臺large以上instance,並且是7X24小時運行,感覺是對運算能力的浪費。

      再三討論後我們決定暫時放棄MongoDB, 將這部分的運算改爲使用MapReduce 來處理。亞馬遜的MapReduce可以充分體現按需使用運算能力的特性,在使用MapReduce完成所有計算需要後,再將需要查詢使用的結果數據導入到Mysql數據庫中。這樣即滿足了那1小時內需要的運行能力,又滿足了其餘時間對計算結果的查詢需求。

 

      通過以上的事例,說明在使用雲計算平臺時,對程序開發技術的選型必須充分考慮到平臺能夠提供虛擬硬件設備的技術指標。並且需要轉變以往的設計思路,更多考慮到雲平臺方便啓動和關閉instance的特性。儘量減少7X24長時間使用相同一臺instance作服務的應用,如果這樣的服務無法避免時,應該考慮多臺冗餘,並在程序設計中去除對instance的內網ip地址耦合,當某臺instance出現故障而需要更新新的instance時,內網ip 地址變化不會導致程序無法正常運行。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章