有說MongoDB慢

反對：不設(shè)其他***索引的情況下，只用_id 在普通辦公電腦上每秒插入幾萬，在普通x86服務(wù)器上每秒插入十幾萬，你好意思說這個性能低？比mysql強(qiáng)出一個數(shù)量級。

贊同：檢索是真的慢，和sql數(shù)據(jù)庫不同，越復(fù)雜的條件搜索MangoDB越吃虧，CPU和IO的雙重壓力。面對那些直接把SQL查詢改寫成MangoDB的用法，別轉(zhuǎn)了，你不會收獲任何性能提升。

你不行：說你不行還是真的不行，MongoDB領(lǐng)導(dǎo)了NoSQL運動，NoSQL請注意，我們最主要反對的就是SQL的方法論，按SQL方法使用MangoDB你只能收獲失望。再想想MongoDB的設(shè)計思想：文檔化。_id 就是文件名，MongoDB是個文件系統(tǒng)。全文檢索？別鬧了，用文件名找文件，一個文件名對應(yīng)一個文件，你絕對不會失望。

那么MongoDB究竟應(yīng)該怎么用呢？

首先，忘記SQL

你應(yīng)該忘記你學(xué)過的那些優(yōu)雅無敵的SQL，不是說為了提升檢索性能，扔索引就有好處。

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

如果這個事實對你是很震撼的，那說明你還沒有忘記SQL，接著忘。

MongoDB的索引對插入性能有著不可忽略的拖后腿效應(yīng)，所以，我們應(yīng)該使用且僅使用 _id 作為插入key，作為查詢key，作為所有的那個key。

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

把MongoDB當(dāng)做你的硬盤，給他文件名去操作文件.這就是Key-Value數(shù)據(jù)庫的做法，你稍加設(shè)計就能這么用。

那么其實你所有的操作可以簡化為兩個指令，邏輯上 就是一個字典

你給他_id,往字典里插一個數(shù)據(jù)，或者拿一個數(shù)據(jù)。

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

要想高性能，善用那個_id,把你原來準(zhǔn)備當(dāng)主鍵的那個玩意，hash成_id.

把你原來準(zhǔn)備的查詢條件，什么？查詢，拿_id來，別的全砍掉。

第三、這不是數(shù)據(jù)表

記住，這不是數(shù)據(jù)表，一個_id對應(yīng)的東西不是一行數(shù)據(jù)，而是一個文件。

文件存儲和表存儲有什么不同呢？

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

數(shù)據(jù)表的做法是建一張用戶表，一張道具表，道具表里有個字段表示他屬于哪個用戶。

然后，你就離不開萬惡的查詢了。

然后如果一個用戶有100條道具，100萬用戶意味著道具表有一億條記錄。

這時候就開始考驗?zāi)愕男?shù)據(jù)庫了，但這都是過去式了，這一億的道具，用MongoDB，根本不是個事兒

因為MongoDB的方法是當(dāng)做文件存，只設(shè)計一個用戶集合，每個用戶的信息是一個文件，然后這100個道具就分開存在每個用戶的文件里。

然后來比較一下，我們?nèi)〉糜脩舻挠涗?，然后從中拿?00個道具，NoSQL方法。

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

熟快熟慢？

然后你可能回想，SQL方法，我也可以搞個道具字段，把用戶的100個道具用某種協(xié)議打包，然后操作啊，一樣可以取得巨大的優(yōu)化呀。

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

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

如果問題止于此處，MongoDB就毫無優(yōu)勢可言了，如果這個方法在SQL數(shù)據(jù)庫上也是如此容易使用，那還費勁搞MongoDB干什么？

我們再折騰一點，如果每個道具還要存100條轉(zhuǎn)手記錄，你還是可以打包，但你這個打包字段已經(jīng)1M了。

于是每次存取這個打包字段都是一個系統(tǒng)工程了，還要負(fù)擔(dān)1M的流量。

MongoDB這邊呢？我們可以直接對文件的一部分進(jìn)行讀寫，比如我只返回一個用戶的第二個道具的信息，和返回第二個道具的第1~30條轉(zhuǎn)手記錄。

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

你想要一張美女的照片，你朋友有，但是他只有一個壓縮包，他那里沒有解包工具，于是他把整個包傳給了你。他想問你要一張照片，但是他沒有壓縮工具，為了存檔需要，他讓你再壓進(jìn)包里傳給他。

這個朋友就是你的用戶表的一行，如果換成真實世界的事件是多么的不可思議，這就是在一個字段里打包數(shù)據(jù)的問題。

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

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

審視一下你項目中的大部分的數(shù)據(jù)需求，是不是都可以用這種方式去組織呢？

如果是，加入NOSQL吧，我們的口號是：很暴力不SQL

還有什么好處 

1.不用邏輯關(guān)心的水平切分

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

2.不用對齊的數(shù)據(jù)結(jié)構(gòu)

不用對齊意味著你不用為以前表結(jié)構(gòu)變化的遷移煩惱，有些文件里有一個部分，有些沒有，這對MongoDB而言，很正常。

原文鏈接：http://www.cnblogs.com/crazylights/archive/2013/05/08/3066056.html

【編輯推薦】

1. Craigslist采用MongoDB替代MySQL
2. MongoDB源碼分析--Command體系架構(gòu)
3. Mongodb源碼分析--內(nèi)存文件映射(MMAP)
4. 淺析Mongodb源碼之游標(biāo)Cursor
5. 如何解決PHP+MySQL出現(xiàn)亂碼的現(xiàn)象