摘要：為了在項(xiàng)目中更好的使用來(lái)完成我們的業(yè)務(wù)，我們探究了性能暴力的成因以及如何更加合理的使用。的出現(xiàn)能夠快速的完成系統(tǒng)的開(kāi)發(fā)于拓展需求。不同的業(yè)務(wù)會(huì)導(dǎo)致不同的數(shù)據(jù)庫(kù)使用情況。緩存類型根據(jù)情況選擇或高速度也是有代價(jià)的。轉(zhuǎn)自初探暴力美學(xué)

為了在項(xiàng)目中更好的使用MongoDB來(lái)完成我們的業(yè)務(wù)，我們探究了MongoDB性能暴力的成因以及如何更加合理的使用MongoDB。

并且簡(jiǎn)單的描述普通業(yè)務(wù)數(shù)據(jù)庫(kù)設(shè)計(jì)的簡(jiǎn)單分析方法。以及避免盲目崇拜對(duì)整體數(shù)據(jù)存儲(chǔ)與處理的分析。

同時(shí)也為了大家初探本數(shù)據(jù)庫(kù)提供了可靠的研究學(xué)習(xí)路線讓學(xué)習(xí)曲線不會(huì)那么陡峭。
當(dāng)然我們也總結(jié)了關(guān)于以golang為例的驅(qū)動(dòng)解決方案，以及復(fù)雜存儲(chǔ)業(yè)務(wù)的解決方案。

在整個(gè)研究過(guò)程中我們發(fā)現(xiàn)MongoDB的存儲(chǔ)因?yàn)楦臃犀F(xiàn)代業(yè)務(wù)既關(guān)系復(fù)雜涉及到的實(shí)體比較多的特征。提升了整個(gè)存儲(chǔ)系統(tǒng)的IO能力。

另外BSON數(shù)據(jù)操作讓業(yè)務(wù)處理如虎添翼。更是提升了開(kāi)發(fā)速度。

隨著互聯(lián)網(wǎng)業(yè)務(wù)爆炸式的增長(zhǎng)，云計(jì)算的興起，業(yè)務(wù)的拓展與實(shí)現(xiàn)面臨著又一次新的挑戰(zhàn)。
MongoDB的出現(xiàn)能夠快速的完成系統(tǒng)的開(kāi)發(fā)于拓展需求。提升持久化系統(tǒng)的吞吐量。

MongoDB相較于普通的關(guān)系型數(shù)據(jù)庫(kù)（SQL）具有簡(jiǎn)潔的數(shù)據(jù)庫(kù)設(shè)計(jì)同時(shí)設(shè)計(jì)也是非常容易的。更加契合業(yè)務(wù)數(shù)據(jù)特征的存儲(chǔ)方式。

降低了很多業(yè)務(wù)存儲(chǔ)上的代價(jià)。在工程中應(yīng)該從嚴(yán)謹(jǐn)?shù)慕嵌葋?lái)給MongoDB選擇合適的業(yè)務(wù)來(lái)存儲(chǔ)。

  
性能方面沒(méi)有必要列舉過(guò)多的數(shù)據(jù)來(lái)說(shuō)明具體的情況。一方面這些都是官方應(yīng)該干的事。另外一方面每次項(xiàng)目每個(gè)公司的硬件環(huán)境都有很大的不同，這些硬件上的不同會(huì)導(dǎo)致測(cè)試數(shù)據(jù)的結(jié)果有著天差地別的結(jié)果。

  最為重要的一點(diǎn)是應(yīng)用場(chǎng)景的不同。不同的業(yè)務(wù)會(huì)導(dǎo)致不同的數(shù)據(jù)庫(kù)使用情況。所以真正想要得到具體的項(xiàng)目解決方案，一方面要靠個(gè)人對(duì)項(xiàng)目的準(zhǔn)確判斷，另一方面具體的方案確定需要根據(jù)情況做出具體的測(cè)試。

說(shuō)到性能肯定是要從搜索Page Rank最高的結(jié)果說(shuō)起
來(lái)自博主瘋狂光纖的博文 http://www.cnblogs.com/crazylights/archive/2013/05/08/3066056.html
以及相關(guān)的實(shí)戰(zhàn)相關(guān)博文 http://www.cnblogs.com/crazylights/archive/2013/05/08/3068098.html
客觀來(lái)講，第一篇文的內(nèi)容語(yǔ)言的確是比較激進(jìn)的。缺少可觀的分析。但是第二篇文章直接上了實(shí)戰(zhàn)來(lái)直接說(shuō)明到底MongoDB性能有多暴力。但是有一點(diǎn)不可取的點(diǎn)就是第一篇說(shuō)的忘記。這個(gè)觀點(diǎn)與我的想法有點(diǎn)背道而馳，我們更應(yīng)該揚(yáng)長(zhǎng)避短結(jié)合SQL于NoSQL的優(yōu)勢(shì)來(lái)快速完成我們的需求。正片開(kāi)始。

使用KV數(shù)據(jù)存儲(chǔ)（BSON）

使用方便。類似JSON操作，當(dāng)然很多語(yǔ)言可以映射到內(nèi)存里面。

查詢修改也使用BSON，操作更加清晰。

文件存儲(chǔ)

每一條數(shù)據(jù)都是一個(gè)文件，文件有大小限制，如果想使用更大的文件系統(tǒng)請(qǐng)使用GridFS

提升數(shù)據(jù)存儲(chǔ)于業(yè)務(wù)的契合度，比如說(shuō)一個(gè)帖子的文件中直接存儲(chǔ)回復(fù)。一次取出整個(gè)文件減少了再次查詢回復(fù)內(nèi)容的時(shí)間。

查詢功能強(qiáng)大

使用BSON查詢的功能非常強(qiáng)大清晰。

由于使用文件的對(duì)象存儲(chǔ)方式，因此在索引上相對(duì)于普通的 SQL92 標(biāo)準(zhǔn)的數(shù)據(jù)庫(kù)會(huì)有一定的性能代價(jià)。推薦使用有意義的鍵值來(lái)盡量避免業(yè)務(wù)的查詢。

因?yàn)镸ongoDB有如上的特征。因此：

MongoDB更適合存儲(chǔ)關(guān)系型數(shù)據(jù)

普通的關(guān)系型數(shù)據(jù)庫(kù)更適合大量對(duì)象的數(shù)據(jù)檢索

理由在于二者索引的區(qū)別，前者不適合有大量數(shù)據(jù)掃描的查詢，后者更加擅長(zhǎng)大量數(shù)據(jù)掃描的業(yè)務(wù)。
在很多文章中MongoDB不適合有太多的skip操作（甚至還提出避免skip的方案）

  
業(yè)務(wù)描述粒度：具體到CURD應(yīng)該在什么數(shù)據(jù)庫(kù)中存儲(chǔ)，

  描述方法: 業(yè)務(wù)類型，使用數(shù)據(jù)庫(kù)，場(chǎng)景舉例。

  這里只是大概描述一下數(shù)據(jù)庫(kù)選擇的輪廓有一個(gè)選擇的概念。也只是說(shuō)了很小一部分的片面的參考。

偏向增加的業(yè)務(wù)

用戶數(shù)據(jù)版本管理（文章，記事本等）

偏向于復(fù)雜關(guān)系數(shù)據(jù)的查詢

帖子的回復(fù)（帖子的范圍： 可以評(píng)論的對(duì)象）

對(duì)象狀態(tài)改變的記錄圖 (比如說(shuō)訂單狀態(tài)改變，記錄具體時(shí)間，事件，發(fā)起者，以及其他內(nèi)容。)

偏向于修改的業(yè)務(wù)

用戶個(gè)人信息的修改（密碼，NickName等）

復(fù)雜對(duì)象的屬性修改（店鋪信息等）

對(duì)象復(fù)雜但是存儲(chǔ)數(shù)據(jù)內(nèi)容簡(jiǎn)短的內(nèi)容且update比較頻繁的情況。

不推薦刪除系統(tǒng)數(shù)據(jù)這部分會(huì)在后面給出解釋

數(shù)據(jù)永遠(yuǎn)都不要?jiǎng)h除，數(shù)據(jù)就是財(cái)富。在凌晨的時(shí)候或者負(fù)載非得低的時(shí)候停機(jī)一個(gè)小時(shí)來(lái)維護(hù)數(shù)據(jù)還是非常值得的。

之前確實(shí)參考了很多其他人寫的書(shū)，但是最后發(fā)現(xiàn)。一定還是Manual寫的是最好的。

由淺入深，講明白了基礎(chǔ)知識(shí)之后從CURD開(kāi)始一步一步的講述MongoDB是如何存儲(chǔ)數(shù)據(jù)的。

因此在這里也是強(qiáng)烈推薦大家從MongoDB的manual開(kāi)始學(xué)習(xí)。

因?yàn)檎Z(yǔ)言不同驅(qū)動(dòng)也有不同，但是對(duì)于MongoDB來(lái)說(shuō)都是對(duì)應(yīng)幾個(gè)接口的Bson操作。因此接口比較好腦補(bǔ)。如果遇到難點(diǎn)可以直接繞過(guò)去，我在2014年年末的時(shí)候就研究出來(lái)一套復(fù)雜查詢的方案。

  
只在極端情況下使用，如果你的查詢過(guò)于復(fù)雜也許你就犯了Skip過(guò)多數(shù)據(jù)的錯(cuò)誤。 http://www.philo.top/1899/11/30/788MongoDB%E5%AD%98%E5%82%A8%E8%BF%87%E7%A8%8B%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98/

請(qǐng)不要在數(shù)據(jù)庫(kù)中刪除數(shù)據(jù)。因?yàn)閞emove()函數(shù)不會(huì)刪除集合本身，同時(shí)，原有的索引也同樣不會(huì)被刪除。因此在查詢的時(shí)候就會(huì)留下一個(gè)黑洞。對(duì)于生產(chǎn)環(huán)境會(huì)有很大的問(wèn)題。

原文鏈接 http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
我不做評(píng)論，只是幾點(diǎn)需要注意

1.吐槽者所解決的問(wèn)題已經(jīng)是非常復(fù)雜的了。就類似于12306已經(jīng)達(dá)到了計(jì)算機(jī)集群的性能極限。因此只說(shuō)MongoDB的問(wèn)題是片面的。
2.這只是高手級(jí)別（CTO級(jí)別）的吐槽。解決問(wèn)題的辦法總是有的?？赡芩麄冃枰訌?fù)雜的方案
3 注意吐槽者說(shuō)的項(xiàng)目時(shí)間是在2010年吐槽時(shí)間實(shí)際在2013年。
4.他們通篇并沒(méi)有提及MongoDB使用的版本但是我相信他們用是MongoDB的官方版本，如果他們的產(chǎn)品是千萬(wàn)用戶量級(jí)的話,也許就會(huì)類似淘寶&&FaceBook一樣針對(duì)社區(qū)產(chǎn)品Fork自己應(yīng)用場(chǎng)景的Branch

  
So , do not panic.

1.比如說(shuō)用戶表的緩存。

  
新浪微博對(duì)用戶分類的方法： 1. 當(dāng)天登陸過(guò)的用戶 2. 活躍用戶  3. 不活躍的用戶

  我們可以對(duì)第一種跟第二種的情況進(jìn)行緩存，因?yàn)楹芏嘤脩魯?shù)據(jù)的查詢都關(guān)系到了User表的查詢。在高負(fù)載情況請(qǐng)建立用戶緩存。

  但是請(qǐng)注意優(yōu)化不要過(guò)早。緩存類型根據(jù)情況選擇Memcache或Redis

2.高速度也是有代價(jià)的。因此要針對(duì)業(yè)務(wù)熱點(diǎn)做一個(gè)權(quán)衡，是否應(yīng)該浪費(fèi)性能在磁盤IO上。

早在2010年的時(shí)候我在學(xué)校的圖書(shū)館里面為數(shù)不多的訂閱雜志里面發(fā)現(xiàn)了NoSQL方面的論文，那時(shí)候MongoDB也只是距離First Release剛剛一年而已，而我也只是饒有興趣的在讀里面的CAP理論，清楚的記得，數(shù)據(jù)庫(kù)也只能三選二。

再后來(lái)2011年的時(shí)候Mysql Release 5.5的版。我在寢室里面奔走相告。告訴大家性能提升了百分之55。

而當(dāng)我畢業(yè)的時(shí)候正好有一個(gè)百萬(wàn)用戶量級(jí)的需求押在了MySql+MongoDB+Golang的頭上。

話不多說(shuō)，我只看見(jiàn)了很多口炮一方面又開(kāi)始說(shuō)XX數(shù)據(jù)庫(kù)很垃圾。另一方面說(shuō)。你只是不會(huì)用而已。但是個(gè)人推崇一種更加中立的觀點(diǎn): 工程是一種妥協(xié)的藝術(shù)。所以方案的選擇沒(méi)有好壞只有根據(jù)具體情況的不同有著不同的選擇。

而經(jīng)過(guò)幾個(gè)月的研究學(xué)習(xí)，雖然我非常膚淺的研究了一下MongoDB但是還是總結(jié)出來(lái)了一套關(guān)于MongoDB性能的掌握，我個(gè)人認(rèn)為適用的應(yīng)用場(chǎng)景以及最低學(xué)習(xí)代價(jià)的學(xué)習(xí)方法。

最關(guān)鍵的是，我們所使用的大部分服務(wù)器都是基于馮諾依曼體系的，他規(guī)定了計(jì)算機(jī)核心組件就那么幾樣，特征也都是固定的，所以只要是一樣的機(jī)器。

執(zhí)行指令集的性能應(yīng)該是一樣的。既然大家的大環(huán)境都是一樣的，只是存儲(chǔ)跟查詢的方式不一樣，如果深入了解之后會(huì)發(fā)現(xiàn)，兩種數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)的方式上的差異造成了各種業(yè)務(wù)存儲(chǔ)選擇的多樣化。因此只有深入學(xué)習(xí)深入了解這兩種數(shù)據(jù)庫(kù)具體的核心內(nèi)容才能判定到底哪個(gè)更適合你的業(yè)務(wù)。

轉(zhuǎn)自 初探MongoDB：暴力美學(xué)