Mongodb數據存儲優缺點

相對於Mysql來講

在項目設計的初期，我當時有了這樣的想法，同時也是在知足下面幾個條件的狀況下來選擇最終的nosql方案的：

一、需求變化頻繁：開發要更加敏捷，開發成本和維護成本要更低，要可以快速地更新進化，新功能要在最短的週期內上線。
二、客戶端/api支持，由於這直接影響開發效率
三、部署簡單
四、擴展能力強
五、節省系統資源，對cpu等資源耗費較小

知足這些要求的nosql方案，就剩下了mongodb和redis了，對於redis，我並非說他很差，而是有一個重要緣由，咱們的項目的數據處理格式都是採用JSON的形式來處理的，這一點對於後來二者之間的選擇，起到了決定性做用。

固然，Redis對豐富數據類型的操做很吸引人，能夠輕鬆解決一些應用場景，其讀寫性能也至關高，以前的版本是存儲和內存是掛鉤的，這樣若是存儲大量的數據須要消耗太多的內存，固然如今的版本已經麼有這樣的問題了。

MongoDB是一個面向文檔的數據庫，目前由10gen開發並維護，它的功能豐富，齊全，徹底能夠替代MySQL。

在我項目實施的過程當中，我總結了mongodb的一些很好的亮點：

爲何MongoDB能夠替代MySQL？

一、使用JSON風格語法，易於掌握和理解：MongoDB使用JSON的變種BSON做爲內部存儲的格式和語法。針對MongoDB的操做都使用JSON風格語法，客戶端提交或接收的數據都使用JSON形式來展示。相對於SQL來講，更加直觀，容易理解和掌握。這也是根據我本身項目的狀況出發，最後選擇了mongodb的一個緣由。

二、Schema-less，支持嵌入子文檔：MongoDB是一個Schema-free的文檔數據庫。一個數據庫能夠有多個Collection，每一個Collection是Documents的集合。Collection和Document和傳統數據庫的Table和Row並不對等。無需事先定義Collection，隨時能夠建立。Collection中能夠包含具備不一樣schema的文檔記錄。 這意味着，你上一條記錄中的文檔有3個屬性，而下一條記錄的文檔能夠有10個屬性，屬性的類型既能夠是基本的數據類型（如數字、字符串、日期等），也能夠是數組或者散列，甚至還能夠是一個子文檔（embed document）。這樣，能夠實現逆規範化（denormalizing）的數據模型，提升查詢的速度。


三、簡單易用的查詢方式：直接使用JSON，支持範圍查詢、正則表達式查詢。


四、CRUD更加簡單，支持in-place update：只要定義一個數組，而後傳遞給MongoDB的insert/update方法就可自動插入或更新；對於更新模式，MongoDB支持一個upsert選項，即：「若是記錄存在那麼更新，不然插入」。MongoDB的update方法還支持Modifier，經過Modifier可實如今服務端即時更新，省去客戶端和服務端的通信。這些modifer可讓MongoDB具備和Redis、Memcached等KV相似的功能：較之MySQL，MonoDB更加簡單快速。Modifier也是MongoDB能夠做爲對用戶行爲跟蹤的容器。在實際中使用Modifier來將用戶的交互行爲快速保存到MongoDB中以便後期進行統計分析和個性化定製


五、全部的屬性類型都支持索引，甚至數組：這可讓某些任務實現起來很是的輕鬆。在MongoDB中，「_id」屬性是主鍵，默認MongoDB會對_id建立一個惟一索引。

 

六、性能高效，速度快： MongoDB使用c++/boost編寫，在多數場合，其查詢速度對比MySQL要快的多，對於CPU佔用很是小。部署也很簡單，對大多數系統，只需下載後二進制包解壓就能夠直接運行，幾乎是零配置。


七、服務端腳本和Map/Reduce：MongoDB容許在服務端執行腳本，能夠用Javascript編寫某個函數，直接在服務端執行，也能夠把函數的定義存儲在服務端，下次直接調用便可。MongoDB不支持事務級別的鎖定，對於某些須要自定義的「原子性」操做，可使用Server side腳原本實現，此時整個MongoDB處於鎖定狀態。Map/Reduce也是MongoDB中比較吸引人的特性。Map/Reduce能夠對大數據量的表進行統計、分類、合併的工做，完成原先SQL的GroupBy等聚合函數的功能。而且Mapper和Reducer的定義都是用Javascript來定義服務端腳本。

MonoDB在數據庫表設計方面的難題，

　　內部造成了兩種意見，一種就是使用單表存儲的方式，把全部的用戶的行爲記錄存儲到一張collection表裏，這樣之後這張表可能會很大，可是開發難度低，

　　另外一種是根據用戶id將用戶記錄存儲到各自的collection中，這樣的好處很明顯，在插入數據的時候人爲的下降了每一個collection表的數量，例如一千萬條記錄分別是屬於10個用戶的，分給10個collection，每一個collection平均分配到一百萬條記錄，可是缺點顯而易見，開發難度大，

　　我看了下mongoid這個gem，沒有對collection動態建立的操做，每一個model固定對應一個collection，按照第二種設計方案，每建立一個用戶就須要動態建立一個collection。

　　mongodb要很是當心，速度太快時表有毀掉的危險，至今無解。

111