有說MongoDB慢

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

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

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

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

首先，忘記SQL

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

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

如果這個(gè)事實(shí)對(duì)你是很震撼的，那說明你還沒有忘記SQL，接著忘。

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

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

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

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

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

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

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

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

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

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

文件存儲(chǔ)和表存儲(chǔ)有什么不同呢？

我舉個(gè)例子，比如我們要存儲(chǔ)用戶列表和每個(gè)用戶的道具列表。

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

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

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

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

因?yàn)镸ongoDB的方法是當(dāng)做文件存，只設(shè)計(jì)一個(gè)用戶集合，每個(gè)用戶的信息是一個(gè)文件，然后這100個(gè)道具就分開存在每個(gè)用戶的文件里。

然后來比較一下，我們?nèi)〉糜脩舻挠涗洠缓髲闹心贸?00個(gè)道具，NoSQL方法。

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

熟快熟慢？

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

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

第四、文件存儲(chǔ)的精華之處

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

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

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

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

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

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

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

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

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

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

如果是，加入NOSQL吧，我們的口號(hào)是：很暴力不SQL

還有什么好處 

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

無需多言，對(duì)MongoDB而言，這是運(yùn)維人員的工作了

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

不用對(duì)齊意味著你不用為以前表結(jié)構(gòu)變化的遷移煩惱，有些文件里有一個(gè)部分，有些沒有，這對(duì)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)象