NoSQL已經(jīng)流行了很長一段時間，那么究竟是什么場景下你才更需要用到這些“新興事物”，就比如MongoDB？下面是一些總結(jié)：

你期望一個更高的寫負(fù)載

默認(rèn)情況下，對比事務(wù)安全，MongoDB更關(guān)注高的插入速度。如果你需要加載大量低價值的業(yè)務(wù)數(shù)據(jù)，那么MongoDB將很適合你的用例。但是必須避免在要求高事務(wù)安全的情景下使用MongoDB，比如一個1000萬美元的交易。

不可靠環(huán)境保證高可用性

設(shè)置副本集（主-從服務(wù)器設(shè)置）不僅方便而且很快，此外，使用MongoDB還可以快速、安全及自動化的實現(xiàn)節(jié)點(diǎn)（或數(shù)據(jù)中心）故障轉(zhuǎn)移。

未來會有一個很大的規(guī)模

數(shù)據(jù)庫擴(kuò)展是非常有挑戰(zhàn)性的，當(dāng)單表格大小達(dá)到5-10GB時，MySQL表格性能會毫無疑問的降低。如果你需要分片并且分割你的數(shù)據(jù)庫，MongoDB將很容易實現(xiàn)這一點(diǎn)。

使用基于位置的數(shù)據(jù)查詢

MongoDB支持二維空間索引，因此可以快速及精確的從指定位置獲取數(shù)據(jù)。

非結(jié)構(gòu)化數(shù)據(jù)的爆發(fā)增長

給RDBMS增加列在有些情況下可能鎖定整個數(shù)據(jù)庫，或者增加負(fù)載從而導(dǎo)致性能下降，這個問題通常發(fā)生在表格大于1GB（更是下文提到BillRun系統(tǒng)中的痛點(diǎn)——單表格動輒幾GB）的情況下。鑒于MongoDB的弱數(shù)據(jù)結(jié)構(gòu)模式，添加1個新字段不會對舊表格有任何影響，整個過程會非?？焖伲灰虼?，在應(yīng)用程序發(fā)生改變時，你不需要專門的1個DBA去修改數(shù)據(jù)庫模式。

缺少專業(yè)的數(shù)據(jù)庫管理員

如果你沒有專業(yè)的DBA，同時你也不需要結(jié)構(gòu)化你的數(shù)據(jù)及做join查詢，MongoDB將會是你的首選。MongoDB非常適合類的持久化，類可以被序列化成JSON并儲存在MongoDB。需要注意的是，如果期望獲得一個更大的規(guī)模，你必須要了解一些最佳實踐來避免走入誤區(qū)。

BillRun——使用MongoDB的賬單系統(tǒng)|2014年2月MUG IL（來自oc666）現(xiàn)實用例學(xué)習(xí)：賬單

在上一次的ILMUG上，Ofer Cohen提出了BillRun，一個下一代基于MongoDB的開源賬單解決方案。這個賬單系統(tǒng)已被增速最快的以色列移動電話運(yùn)營商采用，每月處理超過5億的CDR（通訊記錄），Ofer分享了該系統(tǒng)如何利用MongoDB的優(yōu)勢：

PPT請訪問Slide Share

弱數(shù)據(jù)結(jié)構(gòu)模式允許系統(tǒng)快速引入新的CDR類型，BillRun負(fù)責(zé)托管所有的數(shù)據(jù)。BillRun系統(tǒng)已經(jīng)管理了TB級的表格，I/O性能受限于新字段的增加及數(shù)據(jù)體積的增長?？焖俑北炯试S更簡單地設(shè)置多數(shù)據(jù)中心DRP和HA方案。分片允許I/O超預(yù)算時的線性橫向擴(kuò)展。在CDR插入達(dá)到2000個每秒時，MongoDB非常適用于高寫入系統(tǒng)。同時，你完全可以使用findAndModify（會影響性能）以及2階段提交（應(yīng)用程序級別）來解決事務(wù)問題。面向開發(fā)者的查詢允許優(yōu)雅查詢的編寫。基于位置允許更好的分析用戶使用情況，從而更好地制定移動電話基礎(chǔ)設(shè)施的投入點(diǎn)。

總結(jié)

MongoDB是個非常不錯的工具，但是只有在適合的場景下才能爆發(fā)出壓倒性優(yōu)勢，BillRun就是一個不錯的用例。

以上所述就是本文的全部內(nèi)容了，希望大家能夠喜歡。

最新評論