前言

如何能讓軟件擁有更高的性能？我想這是一個大部分開發(fā)者都思考過的問題。性能往往決定了一個軟件的質(zhì)量，如果你開發(fā)的是一個互聯(lián)網(wǎng)產(chǎn)品，那么你的產(chǎn)品性能將更加受到考驗，因為你面對的是廣大的互聯(lián)網(wǎng)用戶，他們可不是那么有耐心的。嚴重點說，頁面的加載速度每增加一秒也許都會使你失去一部分用戶，也就是說，加載速度和用戶量是成反比的。那么用戶能夠接受的加載速度到底是多少呢？

如圖，如果頁面加載時間超過10s那么用戶就會離開，如果1s–10s的話就需要有提示，但如果我們的頁面沒有提示的話需要多快的加載速度呢？是的，1s 。

當然，這是站在一個產(chǎn)品經(jīng)理的角度來說的，但如果站在一個技術人員的角度來說呢？加載速度和用戶量就是成正比的，你的用戶數(shù)量越多需要處理的數(shù)據(jù)當然也就越多，加載速度當然也就越慢。這是一件很有趣的事，所以如果你的產(chǎn)品如果是一件激動人心的產(chǎn)品，那么作為技術人員你需要做的事就是讓軟件的性能和用戶的數(shù)量同時增長，甚至性能增長要快于用戶量的增長。

Mongodb性能優(yōu)化

數(shù)據(jù)庫性能對軟件整體性能有著至關重要的影響，對于Mongodb數(shù)據(jù)庫常用的性能優(yōu)化方法主要有：

      1、范式化與反范式化；

      2、填充因子的使用；

      3、索引的使用；

一. 范式化與反范式化

范式是為了消除重復數(shù)據(jù)減少冗余數(shù)據(jù)，從而讓數(shù)據(jù)庫內(nèi)的數(shù)據(jù)更好的組織，讓磁盤空間得到更有效利用的一種標準化標準，滿足高等級的范式的先決條件是滿足低等級范式。在數(shù)據(jù)庫設計階段，明確集合的用途是對mongodb數(shù)據(jù)庫性能調(diào)優(yōu)非常重要的一步。根據(jù)集合中數(shù)據(jù)最常用的操作，對于頻繁更新和頻繁查詢的集合，我們最需要關注的重點是他們的范式化程度。

1.1 范式化

   1.1.1 范式化的優(yōu)點：

       1、范式化的數(shù)據(jù)庫更新起來更加快；

       2、范式化之后，只有很少的重復數(shù)據(jù)，只需要修改更少的數(shù)據(jù)；

       3、范式化的表更小，可以在內(nèi)存中執(zhí)行；

       4、很少的冗余數(shù)據(jù)，在查詢的時候需要更少的distinct或者group by語句。

   1.1.2 范式化的缺點：

       1、范式化的表，在查詢的時候經(jīng)常需要很多的關聯(lián)，因為單獨一個表內(nèi)不存在冗余和重復數(shù)據(jù)。這導致，稍微復雜一些的查詢語句在查詢范式的schema上都可能需要較多次的關聯(lián)。這會增加讓查詢的代價，也可能使一些索引策略無效。因為范式化將列存放在不同的表中，而這些列在一個表中本可以屬于同一個索引。

     1.1.3 范式化設計的例子：

       以存儲一篇圖書及其作者為例，作者的信息包括作者的姓名，年齡，國籍。使用范式化的設計如下：

“`
{
“_id” : ObjectId(“5124b5d86041c7dca81917”),
“title” : “如何使用MongoDB”,
“author” : [
ObjectId(“144b5d83041c7dca84416”),
ObjectId(“144b5d83041c7dca84418”),
ObjectId(“144b5d83041c7dca84420”),
]
}