MongoDB的真正性能

最近開始研究MySQL和MongoDB，發現這方面資料很少。尤爲是真正的說到點子上的文章，太少了。

有一些對比測試的文章基本上都是瞎測，測試方法都測到了馬腿上，得出的結論基本上都是NoSQL毫無價值

容我借用Russell Smith 的那句話：不是MongoDB不行，是你不懂。

讓我來分析一下MongoDB的真正性能吧。

有說MongoDB慢

　　反對：不設其餘惟一索引的狀況下，只用_id 在普通辦公電腦上每秒插入幾萬，在普通x86服務器上每秒插入十幾萬，你好意思說這個性能低？比mysql強出一個數量級。

      贊同：檢索是真的慢，和sql數據庫不一樣，越複雜的條件搜索MangoDB越吃虧，CPU和IO的雙重壓力。面對那些直接把SQL查詢改寫成MangoDB的用法，別轉了，你不會收穫任何性能提高。

      你不行：說你不行仍是真的不行，MongoDB領導了NoSQL運動，NoSQL請注意，咱們最主要反對的就是SQL的方法論，按SQL方法使用 MangoDB你只能收穫失望。再想一想MongoDB的設計思想：文檔化。_id 就是文件名，MongoDB是個文件系統。全文檢索？別鬧了，用文件名找文件，一個文件名對應一個文件，你絕對不會失望。

那麼MongoDB究竟應該怎麼用呢？

首先，忘記SQL

你應該忘記你學過的那些優雅無敵的SQL，不是說爲了提高檢索性能，扔索引就有好處。

有一個簡單的事實以下：只有一個默認的_id 索引，此時插入性能爲1，你再加一個索引，插入性能約1/2,再加一個約1/3 ,以此類推......

若是這個事實對你是很震撼的，那說明你尚未忘記SQL，接着忘。

MongoDB的索引對插入性能有着不可忽略的拖後腿效應，因此，咱們應該使用且僅使用 _id 做爲插入key，做爲查詢key，做爲全部的那個key。

其次，直接忘記搜索這件事。

把MongoDB當作你的硬盤，給他文件名去操做文件.這就是Key-Value數據庫的作法，你稍加設計就能這麼用。

那麼其實你全部的操做能夠簡化爲兩個指令，邏輯上 就是一個字典

你給他_id,往字典裏插一個數據，或者拿一個數據。

Save({_id:xxx,.....})

FindOne({_id:xxx})

要想高性能，善用那個_id,把你原來準備當主鍵的那個玩意，hash成_id.

把你原來準備的查詢條件，什麼？查詢，拿_id來，別的全砍掉。

第3、這不是數據表

記住，這不是數據表，一個_id對應的東西不是一行數據，而是一個文件。

文件存儲和表存儲有什麼不一樣呢？

我舉個例子，好比咱們要存儲用戶列表和每一個用戶的道具列表。

數據表的作法是建一張用戶表，一張道具表，道具表裏有個字段表示他屬於哪一個用戶。

而後，你就離不開萬惡的查詢了。

而後若是一個用戶有100條道具，100萬用戶意味着道具表有一億條記錄。

這時候就開始考驗你的小數據庫了，但這都是過去式了，這一億的道具，用MongoDB，根本不是個事兒

由於MongoDB的方法是當作文件存，只設計一個用戶集合，每一個用戶的信息是一個文件，而後這100個道具就分開存在每一個用戶的文件裏。

而後來比較一下，咱們取得用戶的記錄，而後從中拿出100個道具，NoSQL方法。

查一億的表，找出屬於某個用戶的記錄。

熟快熟慢？

而後你可能回想，SQL方法，我也能夠搞個道具字段，把用戶的100個道具用某種協議打包，而後操做啊，同樣能夠取得巨大的優化呀。

沒錯，你的想法很好，你正在用NOSQL的方式用SQL。

第4、文件存儲的精華之處

若是問題止於此處，MongoDB就毫無優點可言了，若是這個方法在SQL數據庫上也是如此容易使用，那還費勁搞MongoDB幹什麼？

咱們再折騰一點，若是每一個道具還要存100條轉手記錄，你仍是能夠打包，但你這個打包字段已經1M了。

因而每次存取這個打包字段都是一個系統工程了，還要負擔1M的流量。

MongoDB這邊呢？咱們能夠直接對文件的一部分進行讀寫，好比我只返回一個用戶的第二個道具的信息，和返回第二個道具的第1~30條轉手記錄。

這，是一種怎樣的差距啊。

你想要一張美女的照片，你朋友有，可是他只有一個壓縮包，他那裏沒有解包工具，因而他把整個包傳給了你。他想問你要一張照片，可是他沒有壓縮工具，爲了存檔須要，他讓你再壓進包裏傳給他。

這個朋友就是你的用戶表的一行，若是換成真實世界的事件是多麼的難以想象，這就是在一個字段裏打包數據的問題。

MongoDB的一條記錄就是一個腦筋更正常的朋友，你要他一張照片，他從包裏找出來給你。你給他一張照片，他分門別類的放置到他的包裏去。

用文件的思惟去訪問，MongoDB是一個更好的朋友。

審視一下你項目中的大部分的數據需求，是否是均可以用這種方式去組織呢？

若是是，加入NOSQL吧，咱們的口號是：很暴力不SQL

還有什麼好處 

1.不用邏輯關心的水平切分

　　無需多言，對MongoDB而言，這是運維人員的工做了

2.不用對齊的數據結構

　　不用對齊意味着你不用爲之前表結構變化的遷移煩惱，有些文件裏有一個部分，有些沒有，這對MongoDB而言，很正常。