使用情景

開始之前，我們先設(shè)定這樣一個(gè)情景

1.一百萬(wàn)注冊(cè)用戶的頁(yè)游或者手游，這是不溫不火的一個(gè)狀態(tài)，剛好是數(shù)據(jù)量不上不下的一個(gè)情況。也剛好是傳統(tǒng)MySql數(shù)據(jù)庫(kù)性能開始吃緊的時(shí)候。

2.數(shù)據(jù)庫(kù)就用一臺(tái)很普通的服務(wù)器，只有一臺(tái)。讀寫分離、水平擴(kuò)展、內(nèi)存緩存都不談。一百萬(wàn)注冊(cè)用戶如果貢獻(xiàn)度和活躍度都不高，恐怕公司的日子還不是那么寬裕，能夠在數(shù)據(jù)庫(kù)上的投資也有限。

以此情景為例，設(shè)每個(gè)用戶都擁有100個(gè)道具，用戶隨時(shí)會(huì)獲得或失去道具。

我們就來看看這一億的道具怎么搞。

道具一般要使用原型、實(shí)例的設(shè)計(jì)方法，這個(gè)不屬于數(shù)據(jù)庫(kù)的范疇。

道具類型001 是屠龍刀，屠龍刀價(jià)格1500，基礎(chǔ)攻擊150，這些，我們把它們稱為道具原型，保存在原型數(shù)據(jù)文件中。

這個(gè)原型數(shù)據(jù)文件，無論是存在何種數(shù)據(jù)庫(kù)或者本地文件中，對(duì)服務(wù)器來說都不是問題，也不干擾數(shù)據(jù)庫(kù)設(shè)計(jì)，所以我們不去討論他。

關(guān)系數(shù)據(jù)庫(kù)設(shè)計(jì)方法

典型的關(guān)系數(shù)據(jù)庫(kù)設(shè)計(jì)方法：

用戶表：字段 xxx userid xxx   ，記錄數(shù)量100萬(wàn)

xxx是其他字段，userid標(biāo)示用戶

用戶道具表：字段 xxx userid itemtype xxx ,記錄數(shù)量一億

xxx是其他字段，userid 標(biāo)示

一個(gè)億的記錄數(shù)是不是看起來有點(diǎn)頭疼，mysql這個(gè)時(shí)候就要想各種辦法了。

MongoDB設(shè)計(jì)方法

但我們用mongoDB來實(shí)現(xiàn)這個(gè)需求，直接就沒有問題

首先第一個(gè)集合：users集合，用UserName 作為_id ,記錄數(shù)100萬(wàn)

然后道具的組織，我們有兩種選擇

1.在users集合的值中建立Items對(duì)象，用Bson數(shù)組保存道具(Mongo官方稱為Bson，和Json一模一樣的存儲(chǔ)方法)

方法一，沒有額外的記錄數(shù)

2.新建userItems集合，同樣用UserName作為_id 每個(gè)UserItems集合的值中建立一個(gè)Item對(duì)象，使用一個(gè)Bson數(shù)組來保存道具

方法二，多了一個(gè)集合和100萬(wàn)記錄數(shù)

我們的道具數(shù)據(jù)看起來像下面這樣:

 

{_id:xxx,Items:[ 
{Itemtype:xxx,ItemPower:xxx}, 
... 
... 
... 
]} 

 

測(cè)試方法

測(cè)試方法如下：測(cè)試客戶端隨機(jī)檢查一個(gè)用戶的道具數(shù)量，小于100加一個(gè)道具，大于100 刪除一個(gè)道具。

連續(xù)100萬(wàn)次，采用10個(gè)線程并發(fā)。

如果用關(guān)系數(shù)據(jù)庫(kù)設(shè)計(jì)方法+mysql來實(shí)現(xiàn)，這是一個(gè)很壓力很大的數(shù)據(jù)處理需求。

可是用文檔數(shù)據(jù)庫(kù)設(shè)計(jì)方法+MongoDB來實(shí)現(xiàn)，這個(gè)測(cè)試根本算不上有壓力。

注意事項(xiàng)

即使我們用了一個(gè)如此勝之不武的設(shè)計(jì)方式，你依然有可能還是能把他寫的很慢。

因?yàn)镸ongoDB在接口設(shè)計(jì)上并沒有很好的引導(dǎo)和約束，如果你不注意，你還是能把他用的非常慢。

第一個(gè)問題：Key-Value數(shù)據(jù)庫(kù)可以有好多的Key，沒錯(cuò),但對(duì)MongoDB來說，大錯(cuò)特錯(cuò)

MongoDB的索引代價(jià)很大，大到什么程度：

1.巨大的內(nèi)存占用，100萬(wàn)條索引約占50M內(nèi)存，如果這個(gè)設(shè)計(jì)中，你一個(gè)道具一條記錄，5G內(nèi)存將用于索引。

我們的屌絲情景不可能給你這樣的服務(wù)器，

2.巨大的性能損失，作為一個(gè)數(shù)據(jù)庫(kù)，所有的東西終將被寫入硬盤，沒有關(guān)系數(shù)據(jù)庫(kù)那樣的表結(jié)構(gòu)，MongoDB的索引寫入性能看起來很差，如果記錄數(shù)據(jù)較小的時(shí)候，你可以觀測(cè)到這樣震撼的景象，加一個(gè)索引，性能變成了1/2,加兩個(gè)索引，性能變成了1/3。

只有當(dāng)?shù)诙€(gè)索引的查詢不可避免，才值得增加額外索引。因?yàn)闆]索引的數(shù)據(jù)，查詢性能是加幾個(gè)零的慢，比加索引更慘。

我們既然選擇了Key-Value數(shù)據(jù)庫(kù)，應(yīng)盡量避免需要多個(gè)索引的情況。

所有的索引只能存在于內(nèi)存中，而讀取記錄時(shí)，也需要將Bson在內(nèi)存中處理，內(nèi)存還承擔(dān)著更重要的作用：讀取緩存。

本來就不充裕的內(nèi)存，應(yīng)該嚴(yán)格控制我們的記錄條數(shù)，能夠用Bson存儲(chǔ)的，盡量用之。

那么我們之前在MongoDB的設(shè)計(jì)中怎么還考慮第二種設(shè)計(jì)方法呢？獨(dú)立一個(gè)userItems 集合，不是又多出100萬(wàn)條記錄了嗎？

這基于另兩個(gè)考慮:a.Bson的處理是要反復(fù)硬盤和內(nèi)存交換的，如果每條記錄更小，則IO壓力更小。內(nèi)存和硬盤對(duì)服務(wù)器來說都是稀缺資源，至于多大的數(shù)據(jù)拆分到另一個(gè)集合中更劃算，這需要根據(jù)業(yè)務(wù)情況，服務(wù)器內(nèi)存、硬盤情況來測(cè)試出一個(gè)合適大小，我們暫時(shí)使用1024這個(gè)數(shù)值，單用戶的道具表肯定是會(huì)突破1024字節(jié)的，所以我們要考慮將他獨(dú)立到一個(gè)集合中

b.可以不部署分片集群，將另一個(gè)集合挪到另一個(gè)服務(wù)器上去。只要服務(wù)器可以輕松承載100萬(wàn)用戶，200萬(wàn)還會(huì)遠(yuǎn)么？在有錢部署分片集群以前，考慮第二組服務(wù)器更現(xiàn)實(shí)一些。

第二個(gè)問題：FindOne({_id:xxx})就快么？

毋庸置疑，F(xiàn)indOne({_id:xxx})就是最直接的用Key取Value。

也的確，用Key取Value 就是我們能用的唯一訪問Value的方式，其他就不叫Key-Value數(shù)據(jù)庫(kù)了。

但是，由于我們要控制Key的數(shù)量，單個(gè)Value就會(huì)比較大。

不要被FindOne({_id:xxx}).Items[3].ItemType這優(yōu)雅的代碼欺騙，這是非常慢的，他幾乎謀殺你所有的流量。

無論后面是什么 FindOne({_id:xxx})總是返回給你完整的Value,我們的100條道具，少說也有6~8K.

這樣的查詢流量已經(jīng)很大了，如果你采用MongoDB方案一設(shè)計(jì)，你的單個(gè)Value是包含一個(gè)用戶的所有數(shù)據(jù)的，他會(huì)更大。

如果查詢客戶端和數(shù)據(jù)庫(kù)服務(wù)器不在同一個(gè)機(jī)房，流量將成為一個(gè)很大的瓶頸。

我們應(yīng)該使用的查詢函數(shù)是FindOne({_id:xxx},filter),filter里面就是設(shè)置返回的過濾條件,這會(huì)在發(fā)送給你以前就過濾掉

比如FindOne({_id:xxx},{Items:{"$slice":[3,1]}})，這和上面那條優(yōu)雅的代碼是完成同樣功能，但是他消耗很少的流量

第三個(gè)問題：精細(xì)的使用Update

這和問題二相對(duì)的，不要暴力的FindOne，也盡量不要暴力的Update一整個(gè)節(jié)點(diǎn)。雖然MangoDB的性能挺暴力的，IO性能極限約等于MongoDB性能，暴力的Update就會(huì)在占用流量的同時(shí)迎接IO的性能極限。

除了創(chuàng)建節(jié)點(diǎn)時(shí)的Insert或者Save之外，所有的Update都應(yīng)該使用修改器精細(xì)修改.

比如Update({_id:xxx},{$set:{"Items.3.Item.Health":38}});//修改第三把武器的健康值

至于一次修改和批量修改，MongoDB默認(rèn)100ms flush一次(2.x),只要兩次修改比較貼近,被一起保存的可能性很高。

但是合并了肯定比不合并強(qiáng)，合并的修改肯定是一起保存，這個(gè)也要依賴于是用的開發(fā)方式，如果使用php做數(shù)據(jù)客戶端，緩存起來多次操作合并了一起提交，實(shí)現(xiàn)起來就比較復(fù)雜。

注意以上三點(diǎn)，一百萬(wàn)注冊(cè)用戶并不算很多，4G內(nèi)存，200G硬盤空間的MongoDB服務(wù)器即可輕松應(yīng)對(duì)。性能瓶頸是硬盤IO，可以很容易的使用Raid和固態(tài)硬盤提升幾倍的吞吐量。不使用大量的Js計(jì)算，CPU不會(huì)成為問題，不要讓索引膨脹，內(nèi)存不會(huì)成為問題。你根本用不著志強(qiáng)的一堆核心和海量的內(nèi)存，更多的內(nèi)存可以讓緩存的效果更好一些，可是比讀寫分離還是差遠(yuǎn)了。如果是高并發(fā)時(shí)查詢性能不足，就要采用讀寫分離的部署方式。當(dāng)IO再次成為瓶頸時(shí)，就只能采用集群部署MongoDB啟用分片功能，或者自行進(jìn)行分集合與key散列的工作。

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

【編輯推薦】

1. MongoDB 2.0 正式版發(fā)布
2. MongoDB 2.0新功能逐個(gè)看之Compact Command
3. 主流NoSQL數(shù)據(jù)庫(kù)全方位評(píng)測(cè)之MongoDB
4. 教你如何利用MySQL學(xué)習(xí)MongoDB
5. 在Windows環(huán)境下MongoDB搭建和簡(jiǎn)單操作