摘要：固定集合不能被分片。為固定集合指定文檔數(shù)量限制時(shí)，必須同時(shí)指定固定集合的大小。沒有索引的集合默認(rèn)情況下，每個(gè)集合都有一個(gè)索引。

上一篇文章：MongoDB指南---13、索引類型、索引管理
下一篇文章：MongoDB指南---15、特殊的索引和集合：地理空間索引、使用GridFS存儲(chǔ)文件

本章介紹MongoDB中一些特殊的集合和索引類型，包括：

用于類隊(duì)列數(shù)據(jù)的固定集合（capped collection）；

用于緩存的TTL索引；

用于簡單字符串搜索的全文本索引；

用于二維平面和球體空間的地理空間索引；

用于存儲(chǔ)大文件的GridFS。

MongoDB中的“普通”集合是動(dòng)態(tài)創(chuàng)建的，而且可以自動(dòng)增長以容納更多的數(shù)據(jù)。MongoDB中還有另一種不同類型的集合，叫做固定集合，固定集合需要事先創(chuàng)建好，而且它的大小是固定的（如圖6-1所示）。說到固定大小的集合，有一個(gè)很有趣的問題：向一個(gè)已經(jīng)滿了的固定集合中插入數(shù)據(jù)會(huì)怎么樣？答案是，固定集合的行為類似于循環(huán)隊(duì)列。如果已經(jīng)沒有空間了，最老的文檔會(huì)被刪除以釋放空間，新插入的文檔會(huì)占據(jù)這塊空間（如圖6-2所示）。也就是說，當(dāng)固定集合被占滿時(shí)，如果再插入新文檔，固定集合會(huì)自動(dòng)將最老的文檔從集合中刪除。

圖6-1　新文檔被插入到隊(duì)列末尾

圖6-2　如果隊(duì)列已經(jīng)被占滿，那么最老的文檔會(huì)被之后插入的新文檔覆蓋
固定集合的訪問模式與MongoDB中的大部分集合不同：數(shù)據(jù)被順序?qū)懭氪疟P上的固定空間。因此它們在碟式磁盤（spinning disk）上的寫入速度非?？欤绕涫羌蠐碛袑Ｓ么疟P時(shí)（這樣就不會(huì)因?yàn)槠渌系囊恍╇S機(jī)性的寫操作而“中斷”）。

固定集合不能被分片。

固定集合可以用于記錄日志，盡管它們不夠靈活。雖然可以在創(chuàng)建時(shí)指定集合大小，但無法控制什么時(shí)候數(shù)據(jù)會(huì)被覆蓋。

不同于普通集合，固定集合必須在使用之前先顯式創(chuàng)建?？梢允褂胏reate命令創(chuàng)建固定集合。在shell中，可以使用createCollection函數(shù)：

> db.createCollection("my_collection", {"capped" : true, "size" : 100000});
{ "ok" : true }

上面的命令創(chuàng)建了一個(gè)名為my_collection大小為100 000字節(jié)的固定集合。
除了大小，createCollection還能夠指定固定集合中文檔的數(shù)量：

> db.createCollection("my_collection2",
... {"capped" : true, "size" : 100000, "max" : 100});
{ "ok" : true }

可以使用這種方式來保存最新的10則新聞，或者是將每個(gè)用戶的文檔數(shù)量限制為1000。
固定集合創(chuàng)建之后，就不能改變了（如果需要修改固定集合的屬性，只能將它刪除之后再重建）。因此，在創(chuàng)建大的固定集合之前應(yīng)該仔細(xì)想清楚它的大小。

為固定集合指定文檔數(shù)量限制時(shí)，必須同時(shí)指定固定集合的大小。不管先達(dá)到哪一個(gè)限制，之后插入的新文檔就會(huì)把最老的文檔擠出集合：固定集合的文檔數(shù)量不能超過文檔數(shù)量限制，固定集合的大小也不能超過大小限制。

創(chuàng)建固定集合時(shí)還有另一個(gè)選項(xiàng)，可以將已有的某個(gè)常規(guī)集合轉(zhuǎn)換為固定集合，可以使用convertToCapped命令實(shí)現(xiàn)。下面的例子將test集合轉(zhuǎn)換為一個(gè)大小為10 000字節(jié)的固定集合：

> db.runCommand({"convertToCapped" : "test", "size" : 10000});
{ "ok" : true }

無法將固定集合轉(zhuǎn)換為非固定集合（只能將其刪除）。

對固定集合可以進(jìn)行一種特殊的排序，稱為自然排序（natural sort）。自然排序返回結(jié)果集中文檔的順序就是文檔在磁盤上的順序（如圖6-3所示）。

圖6-3　使用{"$natural" : 1}進(jìn)行排序
對大多數(shù)集合來說，自然排序的意義不大，因?yàn)槲臋n的位置經(jīng)常變動(dòng)。但是，固定集合中的文檔是按照文檔被插入的順序保存的，自然順序就是文檔的插入順序。因此，自然排序得到的文檔是從舊到新排列的。當(dāng)然也可以按照從新到舊的順序排列（如圖6-4所示）。

> db.my_collection.find().sort({"$natural" : -1})

圖6-4　使用{"$natural" : -1}進(jìn)行排序

循環(huán)游標(biāo)（tailable cursor）是一種特殊的游標(biāo)，當(dāng)循環(huán)游標(biāo)的結(jié)果集被取光后，游標(biāo)不會(huì)被關(guān)閉。循環(huán)游標(biāo)的靈感來自tail -f命令（循環(huán)游標(biāo)跟這個(gè)命令有點(diǎn)兒相似），會(huì)盡可能久地持續(xù)提取輸出結(jié)果。由于循環(huán)游標(biāo)在結(jié)果集取光之后不會(huì)被關(guān)閉，因此，當(dāng)有新文檔插入到集合中時(shí)，循環(huán)游標(biāo)會(huì)繼續(xù)取到結(jié)果。由于普通集合并不維護(hù)文檔的插入順序，所以循環(huán)游標(biāo)只能用在固定集合上。
循環(huán)游標(biāo)通常用于當(dāng)文檔被插入到“工作隊(duì)列”（其實(shí)就是個(gè)固定集合）時(shí)對新插入的文檔進(jìn)行處理。如果超過10分鐘沒有新的結(jié)果，循環(huán)游標(biāo)就會(huì)被釋放，因此，當(dāng)游標(biāo)被關(guān)閉時(shí)自動(dòng)重新執(zhí)行查詢是非常重要的。下面是一個(gè)在PHP中使用循環(huán)游標(biāo)的例子（不能在mongo shell中使用循環(huán)游標(biāo)）：

$cursor = $collection->find()->tailable();

while (true) {
    if (!$cursor->hasNext()) {
        if ($cursor->dead()) {
            break;
        }
        sleep(1);
    }
    else {
        while ($cursor->hasNext()) {
            do_stuff($cursor->getNext());
        }
    }
}

這個(gè)游標(biāo)會(huì)不斷對查詢結(jié)果進(jìn)行處理，或者是等待新的查詢結(jié)果，直到游標(biāo)被關(guān)閉（超過10分鐘沒有新的結(jié)果或者人為中止查詢操作）。

默認(rèn)情況下，每個(gè)集合都有一個(gè)"_id"索引。但是，如果在調(diào)用createCollection創(chuàng)建集合時(shí)指定autoIndexId選項(xiàng)為false，創(chuàng)建集合時(shí)就不會(huì)自動(dòng)在"_id"上創(chuàng)建索引。實(shí)踐中不建議這么使用，但是對于只有插入操作的集合來說，這確實(shí)可以帶來速度的稍許提升。

如果創(chuàng)建了一個(gè)沒有"_id"索引的集合，那就永遠(yuǎn)都不能復(fù)制它所在的mongod了。復(fù)制操作要求每個(gè)集合上都要有"_id"索引（對于復(fù)制操作，能夠唯一標(biāo)識(shí)集合中的每一個(gè)文檔是非常重要的）。

在2.2版本之前，固定集合默認(rèn)是沒有"_id"索引的，除非顯式地將autoIndexId置為true。如果正在使用舊版的固定集合，要確保你的應(yīng)用程序能夠填充"_id"字段（大多數(shù)驅(qū)動(dòng)程序會(huì)自動(dòng)填充"_id"字段），然后使用ensureIndex命令創(chuàng)建"_id"索引。
記住，"_id"索引必須是唯一索引。不同于其他索引，"_id"索引一經(jīng)創(chuàng)建就無法刪除了，因此在生產(chǎn)環(huán)境中創(chuàng)建索引之前先自己實(shí)踐一下是非常重要的。所以創(chuàng)建"_id"索引必須一次成功！如果創(chuàng)建的"_id"索引不合規(guī)范，就只能刪除集合再重建了。

上一節(jié)已經(jīng)講過，對于固定集合中的內(nèi)容何時(shí)被覆蓋，你只擁有非常有限的控制權(quán)限。如果需要更加靈活的老化移出系統(tǒng)（age-out system），可以使用TTL索引（time-to-live index，具有生命周期的索引），這種索引允許為每一個(gè)文檔設(shè)置一個(gè)超時(shí)時(shí)間。一個(gè)文檔到達(dá)預(yù)設(shè)置的老化程度之后就會(huì)被刪除。這種類型的索引對于緩存問題（比如會(huì)話的保存）非常有用。
在ensureIndex中指定expireAfterSecs選項(xiàng)就可以創(chuàng)建一個(gè)TTL索引：

> // 超時(shí)時(shí)間為24小時(shí)
> db.foo.ensureIndex({"lastUpdated" : 1}, {"expireAfterSecs" : 60*60*24})

這樣就在"lastUpdated"字段上建立了一個(gè)TTL索引。如果一個(gè)文檔的"lastUpdated"字段存在并且它的值是日期類型，當(dāng)服務(wù)器時(shí)間比文檔的"lastUpdated"字段的時(shí)間晚expireAfterSecs秒時(shí)，文檔就會(huì)被刪除。
為了防止活躍的會(huì)話被刪除，可以在會(huì)話上有活動(dòng)發(fā)生時(shí)將"lastUpdated"字段的值更新為當(dāng)前時(shí)間。只要"lastUpdated"的時(shí)間距離當(dāng)前時(shí)間達(dá)到24小時(shí)，相應(yīng)的文檔就會(huì)被刪除。
MongoDB每分鐘對TTL索引進(jìn)行一次清理，所以不應(yīng)該依賴以秒為單位的時(shí)間保證索引的存活狀態(tài)?？梢允褂胏ollMod命令修改expireAfterSecs的值：

> db.runCommand({"collMod" : "someapp.cache", "expireAfterSecs" : 3600})

在一個(gè)給定的集合上可以有多個(gè)TTL索引。TTL索引不能是復(fù)合索引，但是可以像“普通”索引一樣用來優(yōu)化排序和查詢。

MongoDB有一個(gè)特殊類型的索引用于在文檔中搜索文本。前面幾章都是使用精確匹配和正則表達(dá)式來查詢字符串，但是這些技術(shù)有一些限制。使用正則表達(dá)式搜索大塊文本的速度非常慢，而且無法處理語言的理解問題（比如entry與entries應(yīng)該算是匹配的）。使用全文本索引可以非?？斓剡M(jìn)行文本搜索，就如同內(nèi)置了多種語言分詞機(jī)制的支持一樣。

創(chuàng)建任何一種索引的開銷都比較大，而創(chuàng)建全文本索引的成本更高。在一個(gè)操作頻繁的集合上創(chuàng)建全文本索引可能會(huì)導(dǎo)致MongoDB過載，所以應(yīng)該是離線狀態(tài)下創(chuàng)建全文本索引，或者是在對性能沒要求時(shí)。創(chuàng)建全文本索引時(shí)要特別小心謹(jǐn)慎，內(nèi)存可能會(huì)不夠用（除非你有SSD）。

全文本索引也會(huì)導(dǎo)致比“普通”索引更嚴(yán)重的性能問題，因?yàn)樗凶址夹枰环纸?、分詞，并且保存到一些地方。因此，可能會(huì)發(fā)現(xiàn)擁有全文本索引的集合的寫入性能比其他集合要差。全文本索引也會(huì)降低分片時(shí)的數(shù)據(jù)遷移速度：將數(shù)據(jù)遷移到其他分片時(shí)，所有文本都需要重新進(jìn)行索引。
寫作本書時(shí)，全文本索引仍然只是一個(gè)處于“試驗(yàn)階段”的功能，所以需要專門啟用這個(gè)功能才能進(jìn)行使用。啟動(dòng)MongoDB時(shí)指定--setParameter textSearch Enabled=true選項(xiàng)，或者在運(yùn)行時(shí)執(zhí)行setParameter命令，都可以啟用全文本索引：

> db.adminCommand({"setParameter" : 1, "textSearchEnabled" : true})

假如我們使用這個(gè)非官方的Hacker News JSON API（http://api.ihackernews.com）將最近的一些文章加載到了MongoDB中。
為了進(jìn)行文本搜索，首先需要?jiǎng)?chuàng)建一個(gè)"text"索引：

> db.hn.ensureIndex({"title" : "text"})

現(xiàn)在，必須通過text命令才能使用這個(gè)索引（寫作本書時(shí)，全文本索引還不能用在“普通”查詢中）：

test> db.runCommand({"text" : "hn", "search" : "ask hn"})
{
    "queryDebugString" : "ask|hn||||||",
    "language" : "english",
    "results" : [
        {
            "score" : 2.25,
            "obj" : {
                "_id" : ObjectId("50dcab296803fa7e4f000011"),
                "title" : "Ask HN: Most valuable skills you have?",
                "url" : "/comments/4974230",
                "id" : 4974230,
                "commentCount" : 37,
                "points" : 31,
                "postedAgo" : "2 hours ago",
                "postedBy" : "bavidar"
            }
        },
        {
            "score" : 0.5625,
            "obj" : {
                "_id" : ObjectId("50dcab296803fa7e4f000001"),
                "title" : "Show HN: How I turned an old book...",
                "url" : "http://www.howacarworks.com/about",
                "id" : 4974055,
                "commentCount" : 44,
                "points" : 95,
                "postedAgo" : "2 hours ago",
                "postedBy" : "AlexMuir"
            }
        },
        {
            "score" : 0.5555555555555556,
            "obj" : {
                "_id" : ObjectId("50dcab296803fa7e4f000010"),
                "title" : "Show HN: ShotBlocker - iOS Screenshot detector...",
                "url" : "https://github.com/clayallsopp/ShotBlocker",
                "id" : 4973909,    
                "commentCount" : 10,
                "points" : 17,
                "postedAgo" : "3 hours ago",
                "postedBy" : "10char"
        }
    }
],
"stats" : {
    "nscanned" : 4,
    "nscannedObjects" : 0,
    "n" : 3,
    "timeMicros" : 89
},
"ok" : 1 } 

匹配到的文檔是按照相關(guān)性降序排列的："Ask HN"位于第一位，然后是兩個(gè)部分匹配的文檔。每個(gè)對象前面的"score"字段描述了每個(gè)結(jié)果與查詢的匹配程度。
如你所見，這個(gè)搜索是不區(qū)分大小寫不的，至少對于[a-zA-Z]這些字符是這樣。全文本索引會(huì)使用toLower將單詞變?yōu)樾懀@是與本地化相關(guān)的，所以某些語言的用戶可能會(huì)發(fā)現(xiàn)MongoDB會(huì)不可預(yù)測性地變得區(qū)分大小寫，這取決于toLower在不同字符集上的行為。MongoDB一直在努力提高對不同字符集的支持。
全文本索引只會(huì)對字符串?dāng)?shù)據(jù)進(jìn)行索引：其他的數(shù)據(jù)類型會(huì)被忽略，不會(huì)包含在索引中。一個(gè)集合上最多只能有一個(gè)全文本索引，但是全文本索引可以包含多個(gè)字段：

> db.blobs.ensureIndex({"title" : "text", "desc" : "text", "author" : "text"})

與“普通”的多鍵索引不同，全文本索引中的字段順序不重要：每個(gè)字段都被同等對待?？梢詾槊總€(gè)字段指定不同的權(quán)重來控制不同字段的相對重要性：

> db.hn.ensureIndex({"title" : "text", "desc" : "text", "author" : "text"},
... {"weights" : {"title" : 3, "author" : 2}})

默認(rèn)的權(quán)重是1，權(quán)重的范圍可以是1~1 000 000 000。使用上面的代碼設(shè)置權(quán)重之后，"title"字段成為其中最重要的字段，"author"其次，最后是"desc"（沒有指定，因此它的權(quán)重是默認(rèn)值1）。
索引一經(jīng)創(chuàng)建，就不能改變字段的權(quán)重了（除非刪除索引再重建），所以在生產(chǎn)環(huán)境中創(chuàng)建索引之前應(yīng)該先在測試數(shù)據(jù)集上實(shí)際操作一下。
對于某些集合，我們可能并不知道每個(gè)文檔所包含的字段?？梢允褂?$**"在文檔的所有字符串字段上創(chuàng)建全文本索引：這不僅會(huì)對頂級的字符串字段建立索引，也會(huì)搜索嵌套文檔和數(shù)組中的字符串字段：

> db.blobs.ensureIndex({"$**" : "text"})

也可以為"$**"設(shè)置權(quán)重：

> db.hn.ensureIndex({"whatever" : "text"},
... {"weights" : {"title" : 3, "author" : 1, "$**" : 2}})

"whatever"可以指代任何東西。在設(shè)置權(quán)重時(shí)指明了是對所有字段進(jìn)行索引，因此MongoDB并不要求你明確給出字段列表。

默認(rèn)情況下，MongoDB會(huì)使用OR連接查詢中的每個(gè)詞：“ask OR hn”。這是執(zhí)行全文本查詢最有效的方式，但是也可以進(jìn)行短語的精確匹配，以及使用NOT。為了精確查詢“ask hn”這個(gè)短語，可以用雙引號將查詢內(nèi)容括起來：

> db.runCommand({text: "hn", search: ""ask hn""})
{
    "queryDebugString" : "ask|hn||||ask hn||",
    "language" : "english",
    "results" : [
        {
            "score" : 2.25,
            "obj" : {
                "_id" : ObjectId("50dcab296803fa7e4f000011"),
                "title" : "Ask HN: Most valuable skills you have?",
                "url" : "/comments/4974230",
                "id" : 4974230,
                "commentCount" : 37,
                "points" : 31,
                "postedAgo" : "2 hours ago",
                "postedBy" : "bavidar"
            }
        }
    ],
    "stats" : {
        "nscanned" : 4,
        "nscannedObjects" : 0,
        "n" : 1,
        "nfound" : 1,
        "timeMicros" : 20392
    },
    "ok" : 1
}

這比使用OR的匹配慢一些，因?yàn)镸ongoDB首先要執(zhí)行一個(gè)OR匹配，然后再對匹配結(jié)果進(jìn)行AND匹配。
可以將查詢字符串的一部分指定為字面量匹配，另一部分仍然是普通匹配：

> db.runCommand({text: "hn", search: ""ask hn" ipod"})

這會(huì)精確搜索"ask hn"這個(gè)短語，也會(huì)可選地搜索"ipod"。
也可以使用"-"字符指定特定的詞不要出現(xiàn)在搜索結(jié)果中：

> db.runCommand({text: "hn", search: "-startup vc"})

這樣就會(huì)返回匹配“vc”但是不包含“startup”這個(gè)詞的文檔。

有幾種方式可以優(yōu)化全文本搜索。如果能夠使用某些查詢條件將搜索結(jié)果的范圍變小，可以創(chuàng)建一個(gè)由其他查詢條件前綴和全文本字段組成的復(fù)合索引：

> db.blog.ensureIndex({"date" : 1, "post" : "text"})

這就是局部的全文本索引，MongoDB會(huì)基于上面例子中的"date"先將搜索范圍分散為多個(gè)比較小的樹。這樣，對于特定日期的文檔進(jìn)行全文本查詢就會(huì)快很多了。
也可以使用其他查詢條件后綴，使索引能夠覆蓋查詢。例如，如果要返回"author"和"post"字段，可以基于這兩個(gè)字段創(chuàng)建一個(gè)復(fù)合索引：

> db.blog.ensureIndex({"post" : "text", "author" : 1})

前綴和后綴形式也可以組合在一起使用：

> db.blog.ensureIndex({"date" : 1, "post" : "text", "author" : 1})

這里的前綴索引字段和后綴索引字段都不可以是多鍵字段。
創(chuàng)建全文本索引會(huì)自動(dòng)在集合上啟用usePowerOf2Sizes選項(xiàng)，這個(gè)選項(xiàng)可以控制空間的分配方式。這個(gè)選項(xiàng)能夠提高寫入速度，所以不要禁用它。

當(dāng)一個(gè)文檔被插入之后（或者索引第一次被創(chuàng)建之后），MongoDB會(huì)查找索引字段，對字符串進(jìn)行分詞，將其減小為一個(gè)基本單元（essential unit）。然后，不同語言的分詞機(jī)制是不同的，所以必須指定索引或者文檔使用的語言。文本類型的索引允許指定"default_language"選項(xiàng)，它的默認(rèn)值是"english"，可以被設(shè)置為多種其他語言（MongoDB的在線文檔提供了最新的支持語言列表）。
例如，要?jiǎng)?chuàng)建一個(gè)法語的索引，可以這么做：

> db.users.ensureIndex({"profil" : "text", "intérêts" : "text"},
... {"default_language" : "french"})

這樣，這個(gè)索引就會(huì)默認(rèn)使用法語的分詞機(jī)制，除非指定了其他的分詞機(jī)制。如果在插入文檔時(shí)指定"language"字段，就可以為每個(gè)文檔分別指定分詞時(shí)使用的語言：

> db.users.insert({"username" : "swedishChef",
... "profile" : "Bork de bork", language : "swedish"})

上一篇文章：MongoDB指南---13、索引類型、索引管理
下一篇文章：MongoDB指南---15、特殊的索引和集合：地理空間索引、使用GridFS存儲(chǔ)文件