分享 | MongoDB優(yōu)化指南
1、為什么選擇MongoDB？
1.性能
在大數(shù)據(jù)時(shí)代中，大數(shù)據(jù)量的處理已經(jīng)成了考量一個(gè)數(shù)據(jù)庫(kù)最重要的原因之一。而MongoDB的一個(gè)主要目標(biāo)就是盡可能的讓數(shù)據(jù)庫(kù)保持卓越的性能，這很大程度地決定了MongoDB的設(shè)計(jì)。在一個(gè)以傳統(tǒng)機(jī)械硬盤為主導(dǎo)的年代，硬盤很可能會(huì)成為性能的短板，而MongoDB選擇了最大程度而利用內(nèi)存資源用作緩存來(lái)?yè)Q取卓越的性能，并且會(huì)自動(dòng)選擇速度最快的索引來(lái)進(jìn)行查詢。MongoDB盡可能精簡(jiǎn)數(shù)據(jù)庫(kù)，將盡可能多的操作交給客戶端，這種方式也是MongoDB能夠保持卓越性能的原因之一。
2.擴(kuò)展
現(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)量已經(jīng)從過(guò)去的MB、GB變?yōu)榱爽F(xiàn)在的TB級(jí)別，單一的數(shù)據(jù)庫(kù)顯然已經(jīng)無(wú)法承受，擴(kuò)展性成為重要的話題，然而現(xiàn)在的開(kāi)發(fā)人員常常在選擇擴(kuò)展方式的時(shí)候犯了難，到底是選擇橫向擴(kuò)展還是縱向擴(kuò)展呢？
橫向擴(kuò)展（scale out）是以增加分區(qū)的方式將數(shù)據(jù)庫(kù)拆分成不同的區(qū)塊來(lái)分布到不同的機(jī)器中來(lái)，這樣的優(yōu)勢(shì)是擴(kuò)展成本低但管理困難。
縱向擴(kuò)展（scale up） 縱向擴(kuò)展與橫向擴(kuò)展不同的是他會(huì)將原本的服務(wù)器進(jìn)行升級(jí)，讓其擁有更強(qiáng)大的計(jì)算能力。這樣的優(yōu)勢(shì)是易于管理無(wú)需考慮擴(kuò)展帶來(lái)的眾多問(wèn)題，但缺點(diǎn)也顯而易見(jiàn)，那就是成本高。一臺(tái)大型機(jī)的價(jià)格往往非常昂貴，并且這樣的升級(jí)在數(shù)據(jù)達(dá)到極限時(shí)，可能就找不到計(jì)算能力更為強(qiáng)大的機(jī)器了。
而MongoDB選擇的是更為經(jīng)濟(jì)的橫向擴(kuò)展，他可以很容易的將數(shù)據(jù)拆分至不同的服務(wù)器中。而且在獲取數(shù)據(jù)時(shí)開(kāi)發(fā)者也無(wú)需考慮多服務(wù)器帶來(lái)的問(wèn)題，MongoDB可以將開(kāi)發(fā)者的請(qǐng)求自動(dòng)路由到正確的服務(wù)器中，讓開(kāi)發(fā)者脫離橫向擴(kuò)展帶來(lái)的弊病，更專注于程序的開(kāi)發(fā)上。
3.使用
MongoDB采用的是NoSQL的設(shè)計(jì)方式，可以更加靈活的操作數(shù)據(jù)。在進(jìn)行傳統(tǒng)的RDBMS中你一定遇到過(guò)幾十行甚至上百行的復(fù)雜SQL語(yǔ)句，傳統(tǒng)的RDBMS的SQL語(yǔ)句中包含著大量關(guān)聯(lián)，子查詢等語(yǔ)句，在增加復(fù)雜性的同時(shí)還讓性能調(diào)優(yōu)變得更加困難。MongoDB的面向文檔（document-oriented）設(shè)計(jì)中采用更為靈活的文檔來(lái)作為數(shù)據(jù)模型用來(lái)取代RDBMS中的行，面向文檔的設(shè)計(jì)讓開(kāi)發(fā)人員獲取數(shù)據(jù)的方式更加靈活，甚至于開(kāi)發(fā)人員僅用一條語(yǔ)句即可查詢復(fù)雜的嵌套關(guān)系，讓開(kāi)發(fā)人員不必為了獲取數(shù)據(jù)而絞盡腦汁。
2、NoSQL對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)思維的影響
1.預(yù)設(shè)計(jì)模式與動(dòng)態(tài)模式
傳統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)思維中，項(xiàng)目的設(shè)計(jì)階段需要對(duì)數(shù)據(jù)庫(kù)表中的字段名稱、字段類型、進(jìn)行規(guī)定，如果嘗試插入不符合設(shè)計(jì)的數(shù)據(jù)，數(shù)據(jù)庫(kù)不會(huì)接受這條數(shù)據(jù)以保證數(shù)據(jù)的完整性。
- --數(shù)據(jù)庫(kù)字段:NAME, SONG
- INSERT INTO T_INFO VALUES('John','Come Together'); --成功
- INSERT INTO T_INFO VALUES('小明', 20, 'xiaoming@111.com'); --失敗
NoSQL采用的是對(duì)集合（類似"表"）中的文檔（類似于"行"）進(jìn)行動(dòng)態(tài)追加，在創(chuàng)建集合之初不會(huì)對(duì)數(shù)據(jù)類型進(jìn)行限定，任何文檔都可以追加到任何集合中去，例如我們可以將這樣兩條文檔添加到一個(gè)集合中去：
- {"name" : "John", "song" : "Come Together"}
- {"name" : "小明", "age":"20", "email" : "xiaoming@111.com"}
MongoDB中文檔的格式類似于我們常見(jiàn)的JSON，由此可見(jiàn)，我們第一個(gè)擁有"name"、"song"兩個(gè)字段，而第二個(gè)擁有"name"、"age"、"email"三個(gè)字段，這在預(yù)設(shè)計(jì)模式中的數(shù)據(jù)庫(kù)是不可能插入成功的，但在MongoDB的動(dòng)態(tài)模式是可以的，這樣做的優(yōu)勢(shì)是我們不必為一些數(shù)量很少，但種類很多的字段單獨(dú)設(shè)計(jì)一張表，可以將他們集中在單獨(dú)一張表進(jìn)行存儲(chǔ)，但這樣做的弊病也是顯而易見(jiàn)的，我們?cè)讷@取數(shù)據(jù)時(shí)需要對(duì)同一張表的不同文檔進(jìn)行區(qū)分，增加了開(kāi)發(fā)上的代碼量。所以在設(shè)計(jì)之初需要權(quán)衡動(dòng)態(tài)模式的優(yōu)劣來(lái)選擇表中的數(shù)據(jù)類型。
2.范式化與反范式化
范式化（normalization）是關(guān)系模型的發(fā)明者埃德加·科德于1970年提出這一概念，范式化會(huì)將數(shù)據(jù)分散到不同的表中，利用關(guān)系模型進(jìn)行關(guān)聯(lián)，由此帶來(lái)的優(yōu)點(diǎn)是，在后期進(jìn)行修改時(shí)，不會(huì)影響到與其關(guān)聯(lián)的數(shù)據(jù)，僅對(duì)自身修改即可完成。
反范式化（denormalization）是針對(duì)范式化提出的相反理念，反范式化會(huì)將當(dāng)前文檔的數(shù)據(jù)集中存放在本表中，而不會(huì)采用拆分的方式進(jìn)行存儲(chǔ)。
范式化和反范式化之間不存在優(yōu)劣的問(wèn)題，范式化的好處是可以在我們寫(xiě)入、修改、刪除時(shí)的提供更高性能，而反范式化可以提高我們?cè)诓樵儠r(shí)的性能。當(dāng)然NoSQL中是不存在關(guān)聯(lián)查詢的，以此提高查詢性能，但我們依舊可以以在表中存儲(chǔ)關(guān)聯(lián)表ID的方式進(jìn)行范式化。但由此可見(jiàn)，NoSQL的理念中反范式化的地位是大于范式化的。
3、性能與用戶量
“如何能讓軟件擁有更高的性能？”，我想這是一個(gè)大部分開(kāi)發(fā)者都思考過(guò)的問(wèn)題。性能往往決定了一個(gè)軟件的質(zhì)量，如果你開(kāi)發(fā)的是一個(gè)互聯(lián)網(wǎng)產(chǎn)品，那么你的產(chǎn)品性能將更加受到考驗(yàn)，因?yàn)槟忝鎸?duì)的是廣大的互聯(lián)網(wǎng)用戶，他們可不是那么有耐心的。嚴(yán)重點(diǎn)說(shuō)，頁(yè)面的加載速度每增加一秒也許都會(huì)使你失去一部分用戶，也就是說(shuō)，加載速度和用戶量是成反比的。那么用戶能夠接受的加載速度到底是多少呢？
如圖，如果頁(yè)面加載時(shí)間超過(guò)10s那么用戶就會(huì)離開(kāi)，如果1s--10s的話就需要有提示，但如果我們的頁(yè)面沒(méi)有提示的話需要多快的加載速度呢？是的，1s 。
當(dāng)然，這是站在一個(gè)產(chǎn)品經(jīng)理的角度來(lái)說(shuō)的，但如果站在一個(gè)技術(shù)人員的角度來(lái)說(shuō)呢？加載速度和用戶量就是成正比的，你的用戶數(shù)量越多需要處理的數(shù)據(jù)當(dāng)然也就越多，加載速度當(dāng)然也就越慢。這是一件很有趣的事，所以如果你的產(chǎn)品如果是一件激動(dòng)人心的產(chǎn)品，那么作為技術(shù)人員你需要做的事就是讓軟件的性能和用戶的數(shù)量同時(shí)增長(zhǎng)，甚至性能增長(zhǎng)要快于用戶量的增長(zhǎng)。
數(shù)據(jù)庫(kù)性能對(duì)軟件整體性能的影響是不言而喻的，那么，當(dāng)我們使用MongoDB時(shí)改如何提高數(shù)據(jù)庫(kù)性能呢？
4、范式化與反范式化
在項(xiàng)目設(shè)計(jì)階段，明確集合的用途是對(duì)性能調(diào)優(yōu)非常重要的一步。
從性能優(yōu)化的角度來(lái)看，集合的設(shè)計(jì)我們需要考慮的是集合中數(shù)據(jù)的常用操作，例如我們需要設(shè)計(jì)一個(gè)日志（log）集合，日志的查看頻率不高，但寫(xiě)入頻率卻很高，那么我們就可以得到這個(gè)集合中常用的操作是更新（增刪改）。如果我們要保存的是城市列表呢？顯而易見(jiàn)，這個(gè)集合是一個(gè)查看頻率很高，但寫(xiě)入頻率很低的集合，那么常用的操作就是查詢。
對(duì)于頻繁更新和頻繁查詢的集合，我們最需要關(guān)注的重點(diǎn)是他們的范式化程度，在上篇范式化與反范式化的介紹中我們了解到，范式化與反范式化的合理運(yùn)用對(duì)于性能的提高至關(guān)重要。然而這種設(shè)計(jì)的使用非常靈活，假設(shè)現(xiàn)在我們需要存儲(chǔ)一篇圖書(shū)及其作者，在MongoDB中的關(guān)聯(lián)就可以體現(xiàn)為以下幾種形式：
1.完全分離（范式化設(shè)計(jì)）
示例1：
- {
- "_id" : ObjectId("5124b5d86041c7dca81917"),
- "title" : "如何使用MongoDB",
- "author" : [
- ObjectId("144b5d83041c7dca84416"),
- ObjectId("144b5d83041c7dca84418"),
- ObjectId("144b5d83041c7dca84420"),
- ]
- }
我們將作者(comment) 的id數(shù)組作為一個(gè)字段添加到了圖書(shū)中去。這樣的設(shè)計(jì)方式是在非關(guān)系型數(shù)據(jù)庫(kù)中常用的，也就是我們所說(shuō)的范式化設(shè)計(jì)。在MongoDB中我們將與主鍵沒(méi)有直接關(guān)系的圖書(shū)單獨(dú)提取到另一個(gè)集合，用存儲(chǔ)主鍵的方式進(jìn)行關(guān)聯(lián)查詢。當(dāng)我們要查詢文章和評(píng)論時(shí)需要先查詢到所需的文章，再?gòu)奈恼轮蝎@取評(píng)論id，最后用獲得的完整的文章及其評(píng)論。在這種情況下查詢性能顯然是不理想的。但當(dāng)某位作者的信息需要修改時(shí)，范式化的維護(hù)優(yōu)勢(shì)就凸顯出來(lái)了，我們無(wú)需考慮此作者關(guān)聯(lián)的圖書(shū)，直接進(jìn)行修改此作者的字段即可。
2.完全內(nèi)嵌（反范式化設(shè)計(jì)）
示例2：
- {
- "_id" : ObjectId("5124b5d86041c7dca81917"),
- "title" : "如何使用MongoDB",
- "author" : [
- {
- "name" : "丁磊"
- "age" : 40,
- "nationality" : "china",
- },
- {
- "name" : "馬云"
- "age" : 49,
- "nationality" : "china",
- },
- {
- "name" : "張召忠"
- "age" : 59,
- "nationality" : "china",
- },
- ]
- }
在這個(gè)示例中我們將作者的字段完全嵌入到了圖書(shū)中去，在查詢的時(shí)候直接查詢圖書(shū)即可獲得所對(duì)應(yīng)作者的全部信息，但因一個(gè)作者可能有多本著作，當(dāng)修改某位作者的信息時(shí)時(shí)，我們需要遍歷所有圖書(shū)以找到該作者，將其修改。
3.部分內(nèi)嵌（折中方案）
示例3：
- {
- "_id" : ObjectId("5124b5d86041c7dca81917"),
- "title" : "如何使用MongoDB",
- "author" : [
- {
- "_id" : ObjectId("144b5d83041c7dca84416"),
- "name" : "丁磊"
- },
- {
- "_id" : ObjectId("144b5d83041c7dca84418"),
- "name" : "馬云"
- },
- {
- "_id" : ObjectId("144b5d83041c7dca84420"),
- "name" : "張召忠"
- },
- ]
- }
這次我們將作者字段中的最常用的一部分提取出來(lái)。當(dāng)我們只需要獲得圖書(shū)和作者名時(shí)，無(wú)需再次進(jìn)入作者集合進(jìn)行查詢，僅在圖書(shū)集合查詢即可獲得。
這種方式是一種相對(duì)折中的方式，既保證了查詢效率，也保證的更新效率。但這樣的方式顯然要比前兩種較難以掌握，難點(diǎn)在于需要與實(shí)際業(yè)務(wù)進(jìn)行結(jié)合來(lái)尋找合適的提取字段。如同示例3所述，名字顯然不是一個(gè)經(jīng)常修改的字段，這樣的字段如果提取出來(lái)是沒(méi)問(wèn)題的，但如果提取出來(lái)的字段是一個(gè)經(jīng)常修改的字段（比如age）的話，我們依舊在更新這個(gè)字段時(shí)需要大范圍的尋找并依此進(jìn)行更新。
在上面三個(gè)示例中，第一個(gè)示例的更新效率是最高的，但查詢效率是最低的，而第二個(gè)示例的查詢效率最高，但更新效率最低。所以在實(shí)際的工作中我們需要根據(jù)自己實(shí)際的需要來(lái)設(shè)計(jì)表中的字段，以獲得最高的效率。
5、理解填充因子
何為填充因子？
填充因子（padding factor）是MongoDB為文檔的擴(kuò)展而預(yù)留的增長(zhǎng)空間，因?yàn)镸ongoDB的文檔是以順序表的方式存儲(chǔ)的，每個(gè)文檔之間會(huì)非常緊湊，如圖所示。
（注：圖片出處：《MongoDB The Definitive Guide》）
1.元素之間沒(méi)有多余的可增長(zhǎng)空間。
2.當(dāng)我們對(duì)順序表中某個(gè)元素的大小進(jìn)行增長(zhǎng)的時(shí)候，就會(huì)導(dǎo)致原來(lái)分配的空間不足，只能要求其向后移動(dòng)。
3.當(dāng)修改元素移動(dòng)后，后續(xù)插入的文檔都會(huì)提供一定的填充因子，以便于文檔頻繁的修改，如果沒(méi)有不再有文檔因增大而移動(dòng)的話，后續(xù)插入的文檔的填充因子會(huì)依此減小。
填充因子的理解之所以重要，是因?yàn)槲臋n的移動(dòng)非常消耗性能，頻繁的移動(dòng)會(huì)大大增加系統(tǒng)的負(fù)擔(dān)，在實(shí)際開(kāi)發(fā)中最有可能會(huì)讓文檔體積變大的因素是數(shù)組，所以如果我們的文檔會(huì)頻繁修改并增大空間的話，則一定要充分考慮填充因子。
那么如果我們的文檔是個(gè)常常會(huì)擴(kuò)展的話，應(yīng)該如何提高性能？
兩種方案
1、增加初始分配空間。在集合的屬性中包含一個(gè) usePowerOf2Sizes 屬性，當(dāng)這個(gè)選項(xiàng)為true時(shí)，系統(tǒng)會(huì)將后續(xù)插入的文檔，初始空間都分配為2的N次方。
這種分配機(jī)制適用于一個(gè)數(shù)據(jù)會(huì)頻繁變更的集合使用，他會(huì)給每個(gè)文檔留有更大的空間，但因此空間的分配不會(huì)像原來(lái)那樣高效，如果你的集合在更新時(shí)不會(huì)頻繁的出現(xiàn)移動(dòng)現(xiàn)象，這種分配方式會(huì)導(dǎo)致寫(xiě)入速度相對(duì)變慢。
2、我們可以利用數(shù)據(jù)強(qiáng)行將初始分配空間擴(kuò)大。
- db.book.insert({
- "name" : "MongoDB",
- "publishing" : "清華大學(xué)出版社",
- "author" : "john"
- "tags" : []
- "stuff" : "ggggggggggggggggggggggggggggggggggggg
- ggggggggggggggggggggggggggggggggggggg
- ggggggggggggggggggggggggggggggggggggg"
- })
是的，這樣看起來(lái)可能不太優(yōu)雅...但有時(shí)卻很有效！當(dāng)我們對(duì)這個(gè)文檔進(jìn)行增長(zhǎng)式修改時(shí)，只要將stuff字段刪掉即可。當(dāng)然，這個(gè)stuff字段隨便你怎么起名，包括里邊的填充字符當(dāng)然也是可以隨意添加的。
6、準(zhǔn)確利用索引
索引對(duì)于一個(gè)數(shù)據(jù)庫(kù)的影響相信大家一定了解，如果一個(gè)查詢命令進(jìn)入到數(shù)據(jù)庫(kù)中后，查詢優(yōu)化器沒(méi)有找到合適的索引，那么數(shù)據(jù)庫(kù)會(huì)進(jìn)行全集合掃描(在RDBMS中也叫全表掃描)，全集合查詢對(duì)于性能的影響是災(zāi)難性的。
沒(méi)有索引的查詢就如同在詞典那毫無(wú)規(guī)律的海量詞匯中獲得某個(gè)你想要的詞匯，但這個(gè)詞典是沒(méi)有目錄的，只能通過(guò)逐頁(yè)來(lái)查找。這樣的查找可能會(huì)讓你耗費(fèi)幾個(gè)小時(shí)的時(shí)間，但如果要求你查詢?cè)~匯的頻率如同用戶訪問(wèn)的頻率一樣的話。。。嘿嘿，我相信你一定會(huì)大喊“老子不干了！”。顯然計(jì)算機(jī)不會(huì)這樣喊，它一直是一個(gè)勤勤懇懇的員工，不論多么苛刻的請(qǐng)求他都會(huì)完成。所以請(qǐng)通過(guò)索引善待你的計(jì)算機(jī)：D。
在MongoDB中索引的類型與RDBMS中大體一致，我們不做過(guò)多重復(fù)，我們來(lái)看一下在MongoDB中如何才能更高效的利用索引。
6.1 索引越少越好
索引可以極大地提高查詢性能，那么索引是不是越多越好？答案是否定的，并且索引并非越多越好，而是越少越好。每當(dāng)你建立一個(gè)索引時(shí)，系統(tǒng)會(huì)為你添加一個(gè)索引表，用于索引指定的列，然而當(dāng)你對(duì)已建立索引的列進(jìn)行插入或修改時(shí)，數(shù)據(jù)庫(kù)則需要對(duì)原來(lái)的索引表進(jìn)行重新排序，重新排序的過(guò)程非常消耗性能，但應(yīng)對(duì)少量的索引壓力并不是很大，但如果索引的數(shù)量較多的話對(duì)于性能的影響可想而知。所以在創(chuàng)建索引時(shí)需要謹(jǐn)慎建立索引，要把每個(gè)索引的功能都要發(fā)揮到極致，也就是說(shuō)在可以滿足索引需求的情況下，索引的數(shù)量越少越好。
隱式索引
- //建立復(fù)合索引
- db.test.ensureIndex({"age": 1,"no": 1,"name": 1 })
我們?cè)诓樵儠r(shí)可以迅速的將age,no字段進(jìn)行排序，隱式索引指的是如果我們想要排序的字段包含在已建立的復(fù)合索引中則無(wú)需重復(fù)建立索引。
- db.test.find().sort("age": 1,"no": 1)
- db.test.find().sort("age": 1)
如以上兩個(gè)排序查詢，均可使用上面的復(fù)合索引，而不需要重新建立索引。
翻轉(zhuǎn)索引
- //建立復(fù)合索引
- db.test.ensureIndex({"age": 1})
翻轉(zhuǎn)索引很好理解，就是我們?cè)谂判虿樵儠r(shí)無(wú)需考慮索引列的方向，例如這個(gè)例子中我們?cè)诓樵儠r(shí)可以將排序條件寫(xiě)為"{'age': 0}"，依舊不會(huì)影響性能。
6.2 索引列顆粒越小越好
什么叫顆粒越小越好？在索引列中每個(gè)數(shù)據(jù)的重復(fù)數(shù)量稱為顆粒，也叫作索引的基數(shù)。如果數(shù)據(jù)的顆粒過(guò)大，索引就無(wú)法發(fā)揮該有的性能。例如，我們擁有一個(gè)"age"列索引，如果在"age"列中，20歲占了50%，如果現(xiàn)在要查詢一個(gè)20歲，名叫"Tom"的人，我們則需要在表的50%的數(shù)據(jù)中查詢，索引的作用大大降低。所以，我們?cè)诮⑺饕龝r(shí)要盡量將數(shù)據(jù)顆粒小的列放在索引左側(cè)，以保證索引發(fā)揮最大的作用。
