初探MongoDB：暴力美學

AUTH：PHILO version:2.0

Abstract

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

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

同時也爲了你們初探本數據庫提供了可靠的研究學習路線讓學習曲線不會那麼陡峭。
固然咱們也總結了關於以golang爲例的驅動解決方案，以及複雜存儲業務的解決方案。

在整個研究過程當中咱們發現MongoDB的存儲由於更加符合現代業務既關係複雜涉及到的實體比較多的特徵。提高了整個存儲系統的IO能力。

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

Introduction

隨着互聯網業務爆炸式的增加，雲計算的興起，業務的拓展與實現面臨着又一次新的挑戰。
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的優點來快速完成咱們的需求。正片開始。

簡單的存儲特徵分析

1. 使用KV數據存儲（BSON）

   1. 使用方便。相似JSON操做，固然不少語言能夠映射到內存裏面。
   2. 查詢修改也使用BSON，操做更加清晰。

2. 文件存儲

   1. 每一條數據都是一個文件，文件有大小限制，若是想使用更大的文件系統請使用GridFS
   2. 提高數據存儲於業務的契合度，好比說一個帖子的文件中直接存儲回覆。一次取出整個文件減小了再次查詢回覆內容的時間。

3. 查詢功能強大

   1. 使用BSON查詢的功能很是強大清晰。
   2. 因爲使用文件的對象存儲方式，所以在索引上相對於普通的 SQL92 標準的數據庫會有必定的性能代價。推薦使用有意義的鍵值來儘可能避免業務的查詢。

由於MongoDB有如上的特徵。所以：

1. MongoDB更適合存儲關係型數據
2. 普通的關係型數據庫更適合大量對象的數據檢索

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

適應狀況的例子

業務描述粒度：具體到CURD應該在什麼數據庫中存儲，
描述方法: 業務類型，使用數據庫，場景舉例。
這裏只是大概描述一下數據庫選擇的輪廓有一個選擇的概念。也只是說了很小一部分的片面的參考。

1. 偏向增長的業務

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

3. 偏向於複雜關係數據的查詢

   1. 帖子的回覆（帖子的範圍： 能夠評論的對象）
   2. 對象狀態改變的記錄圖 (好比說訂單狀態改變，記錄具體時間，事件，發起者，以及其餘內容。)

4. 偏向於修改的業務

   1. 用戶我的信息的修改（密碼，NickName等）
   2. 複雜對象的屬性修改（店鋪信息等）
   3. 對象複雜可是存儲數據內容簡短的內容且update比較頻繁的狀況。

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

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

學習方法路線以及其餘應該注意的地方

以前確實參考了不少其餘人寫的書，可是最後發現。必定仍是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()函數不會刪除集合自己，同時，原有的索引也一樣不會被刪除。所以在查詢的時候就會留下一個黑洞。對於生產環境會有很大的問題。

關於Don’t use MongoDB

原文連接 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.

Cache必不可少

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：暴力美學