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

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

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

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

在整個研究過程中我們發(fā)現(xiàn)MongoDB的存儲因為更加符合現(xiàn)代業(yè)務(wù)既關(guān)系復(fù)雜涉及到的實體比較多的特征。提升了整個存儲系統(tǒng)的IO能力。

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

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

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

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

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

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

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

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

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

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

文件存儲

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

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

查詢功能強大

使用BSON查詢的功能非常強大清晰。

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

因為MongoDB有如上的特征。因此：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)永遠都不要刪除，數(shù)據(jù)就是財富。在凌晨的時候或者負載非得低的時候停機一個小時來維護數(shù)據(jù)還是非常值得的。

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

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

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

因為語言不同驅(qū)動也有不同，但是對于MongoDB來說都是對應(yīng)幾個接口的Bson操作。因此接口比較好腦補。如果遇到難點可以直接繞過去，我在2014年年末的時候就研究出來一套復(fù)雜查詢的方案。

  
只在極端情況下使用，如果你的查詢過于復(fù)雜也許你就犯了Skip過多數(shù)據(jù)的錯誤。 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/

請不要在數(shù)據(jù)庫中刪除數(shù)據(jù)。因為remove()函數(shù)不會刪除集合本身，同時，原有的索引也同樣不會被刪除。因此在查詢的時候就會留下一個黑洞。對于生產(chǎn)環(huán)境會有很大的問題。

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

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

  
So , do not panic.

1.比如說用戶表的緩存。

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

  我們可以對第一種跟第二種的情況進行緩存，因為很多用戶數(shù)據(jù)的查詢都關(guān)系到了User表的查詢。在高負載情況請建立用戶緩存。

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

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

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

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

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

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

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

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

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

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