測試MangoDB的真正性能
有說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
【編輯推薦】
- Craigslist采用MongoDB替代MySQL
- MongoDB源碼分析--Command體系架構(gòu)
- Mongodb源碼分析--內(nèi)存文件映射(MMAP)
- 淺析Mongodb源碼之游標(biāo)Cursor
- 如何解決PHP+MySQL出現(xiàn)亂碼的現(xiàn)象
