摘要：為了在項目中更好的使用來完成我們的業務，我們探究了性能暴力的成因以及如何更加合理的使用。的出現能夠快速的完成系統的開發于拓展需求。不同的業務會導致不同的數據庫使用情況。緩存類型根據情況選擇或高速度也是有代價的。轉自初探暴力美學

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

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

同時也為了大家初探本數據庫提供了可靠的研究學習路線讓學習曲線不會那么陡峭。
當然我們也總結了關于以golang為例的驅動解決方案，以及復雜存儲業務的解決方案。

在整個研究過程中我們發現MongoDB的存儲因為更加符合現代業務既關系復雜涉及到的實體比較多的特征。提升了整個存儲系統的IO能力。

另外BSON數據操作讓業務處理如虎添翼。更是提升了開發速度。

隨著互聯網業務爆炸式的增長，云計算的興起，業務的拓展與實現面臨著又一次新的挑戰。
MongoDB的出現能夠快速的完成系統的開發于拓展需求。提升持久化系統的吞吐量。

MongoDB相較于普通的關系型數據庫（SQL）具有簡潔的數據庫設計同時設計也是非常容易的。更加契合業務數據特征的存儲方式。

降低了很多業務存儲上的代價。在工程中應該從嚴謹的角度來給MongoDB選擇合適的業務來存儲。

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

  最為重要的一點是應用場景的不同。不同的業務會導致不同的數據庫使用情況。所以真正想要得到具體的項目解決方案，一方面要靠個人對項目的準確判斷，另一方面具體的方案確定需要根據情況做出具體的測試。

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

使用KV數據存儲（BSON）

使用方便。類似JSON操作，當然很多語言可以映射到內存里面。

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

文件存儲

每一條數據都是一個文件，文件有大小限制，如果想使用更大的文件系統請使用GridFS

提升數據存儲于業務的契合度，比如說一個帖子的文件中直接存儲回復。一次取出整個文件減少了再次查詢回復內容的時間。

查詢功能強大

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

由于使用文件的對象存儲方式，因此在索引上相對于普通的 SQL92 標準的數據庫會有一定的性能代價。推薦使用有意義的鍵值來盡量避免業務的查詢。

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

MongoDB更適合存儲關系型數據

普通的關系型數據庫更適合大量對象的數據檢索

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

  
業務描述粒度：具體到CURD應該在什么數據庫中存儲，

  描述方法: 業務類型，使用數據庫，場景舉例。

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

偏向增加的業務

用戶數據版本管理（文章，記事本等）

偏向于復雜關系數據的查詢

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

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

偏向于修改的業務

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

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

對象復雜但是存儲數據內容簡短的內容且update比較頻繁的情況。

不推薦刪除系統數據這部分會在后面給出解釋

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

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

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

因此在這里也是強烈推薦大家從MongoDB的manual開始學習。

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

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

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

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

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

  
So , do not panic.

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

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

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

  但是請注意優化不要過早。緩存類型根據情況選擇Memcache或Redis

2.高速度也是有代價的。因此要針對業務熱點做一個權衡，是否應該浪費性能在磁盤IO上。

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

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

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

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

而經過幾個月的研究學習，雖然我非常膚淺的研究了一下MongoDB但是還是總結出來了一套關于MongoDB性能的掌握，我個人認為適用的應用場景以及最低學習代價的學習方法。

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

執行指令集的性能應該是一樣的。既然大家的大環境都是一樣的，只是存儲跟查詢的方式不一樣，如果深入了解之后會發現，兩種數據庫存儲數據的方式上的差異造成了各種業務存儲選擇的多樣化。因此只有深入學習深入了解這兩種數據庫具體的核心內容才能判定到底哪個更適合你的業務。

轉自 初探MongoDB：暴力美學