這里總結(jié)下這段時(shí)間使用mongo的心得，列出了幾個(gè)需要注意的地方。

1. 系統(tǒng)參數(shù)及mongo參數(shù)設(shè)置

mongo參數(shù)主要是storageEngine和directoryperdb，這兩個(gè)參數(shù)一開(kāi)始不選定后續(xù)就無(wú)法再更改。

directoryperdb主要是將數(shù)據(jù)庫(kù)分文件夾存放，方便后續(xù)的備份及數(shù)據(jù)遷移。

storageEngine（存儲(chǔ)引擎）默認(rèn)使用的是MMAPv1，推薦使用3.0新加入的引擎wiredTiger。經(jīng)實(shí)際使用wiredTiger占用的磁盤空間是MMAP的1/5，索引大小是其1/2，查詢速度也提高很多，更重要的是該引擎提供了document級(jí)別的鎖，當(dāng)集合插入或更新數(shù)據(jù)時(shí)不需要阻塞讀操作了。唯一的問(wèn)題是市面上支持該引擎查詢的工具不多，MongoVUE無(wú)法查到該引擎存儲(chǔ)的集合，NosqlManager-mongo可以查到但需要.net環(huán)境支持。個(gè)人覺(jué)得熟悉下mongo command用mongo shell就足夠了，所以還是強(qiáng)烈推薦使用wiredTiger引擎。

2. 無(wú)需對(duì)集合進(jìn)行水平切分

由于之前一直使用關(guān)系型數(shù)據(jù)庫(kù)，關(guān)系型數(shù)據(jù)庫(kù)當(dāng)單表數(shù)據(jù)量超大時(shí)經(jīng)常使用的一直方法是對(duì)數(shù)據(jù)表進(jìn)行分表。在使用mongo時(shí)便很自然的覺(jué)得這招仍然有用。由于該系統(tǒng)的分表都是動(dòng)態(tài)生成的，做到后面發(fā)現(xiàn)這招對(duì)mongo帶來(lái)的性能提升遠(yuǎn)遠(yuǎn)抵不過(guò)維護(hù)成本的增加。

分析一下關(guān)系型數(shù)據(jù)庫(kù)分表會(huì)提高性能的最大原因是很多關(guān)系型數(shù)據(jù)庫(kù)一張表是一個(gè)文件，分表可以避免一個(gè)文件過(guò)大所造成數(shù)據(jù)提取速度變慢。但是mongo并不是這樣存儲(chǔ)的，所以這條并不成立了。

用過(guò)的都知道m(xù)ongo對(duì)索引的依賴非常大，如果集合不能一開(kāi)始就設(shè)計(jì)好，那后續(xù)索引就得寫腳本來(lái)創(chuàng)建。這里貢獻(xiàn)個(gè)給mongo大表動(dòng)態(tài)創(chuàng)建索引的腳本：

eval(function () {
var infos = [];
var collNames = db.getCollectionNames();
for (var i = 0; i < collNames.length; i++) {
var collName = collNames[i];
var collSize = db.getCollection(collName).count();
if (collSize > 1000000 && collName.indexOf(“info_”)==0) {
db.getCollection(collName).ensureIndex({publishDate:-1,blendedScore:-1,publishTime:-1,isRubbish:1},{name:”ScoreSortIdx”,background:true});
db.getCollection(collName).ensureIndex({similarNum:-1,publishTime:-1,isRubbish:1},{name:”HotSortIdx”,background:true});
db.getCollection(collName).ensureIndex({publishTime:-1,isRubbish:1},{name:”TimeSortIdx”,background:true});
infos.push(“name:” + collName + “索引創(chuàng)建成功”);
}
}
return infos;
}());