用了一陣子mongodb，作一些小結(jié)，作為將來的參考。按照以往的習(xí)慣，先作一個(gè)總覽，然后再挑出一些自己比較關(guān)注的幾個(gè)點(diǎn)，作為珠璣，加以串聯(lián)闡述。

mongodb由C＋＋寫就，其名字來自humongous這個(gè)單詞的中間部分，從名字可見其野心所在就是海量數(shù)據(jù)的處理。關(guān)于它的一個(gè)最簡潔描述為：scalable, high-performance, open source, schema-free, document-oriented database。我對(duì)于文檔型數(shù)據(jù)庫有一些個(gè)人的偏好，這種偏好是從半年前研究couchdb而來的，因?yàn)槲矣X得用它來描述一個(gè)具有個(gè)性化特征的實(shí)體對(duì)象正合適，比如網(wǎng)站上的用戶或商品書籍之類的條目。

一些概念：

跟mysqld一樣，一個(gè)mongod服務(wù)可以有建立多個(gè)數(shù)據(jù)庫，每個(gè)數(shù)據(jù)庫可以有多張表，這里的表名叫collection，每個(gè)collection可以存放多個(gè)文檔（document），每個(gè)文檔都以BSON（binary json）的形式存放于硬盤中。跟關(guān)系型數(shù)據(jù)庫不一樣的地方是，它是的以單文檔為單位存儲(chǔ)的，你可以任意給一個(gè)或一批文檔新增或刪除字段，而不會(huì)對(duì)其它文檔造成影響，這就是所謂的schema-free，這也是文檔型數(shù)據(jù)庫最主要的優(yōu)點(diǎn)。跟一般的key-value數(shù)據(jù)庫不一樣的是，它的value中存儲(chǔ)了結(jié)構(gòu)信息，所以你又可以像關(guān)系型數(shù)據(jù)庫那樣對(duì)某些域進(jìn)行讀寫、統(tǒng)計(jì)等操作?？梢哉f是兼?zhèn)淞薻ey-value數(shù)據(jù)庫的方便高效與關(guān)系型數(shù)據(jù)庫的強(qiáng)大功能。

索引

跟關(guān)系型數(shù)據(jù)庫類似，mongodb可以對(duì)某個(gè)字段建立索引，可以建立組合索引、唯一索引，也可以刪除索引。當(dāng)然建立索引就意味著增加空間開銷，我的建議是，如果你能把一個(gè)文檔作為一個(gè)對(duì)象的來考慮，在線上應(yīng)用中，你通常只要對(duì)對(duì)象ID建立一個(gè)索引即可，根據(jù)ID取出對(duì)象某些數(shù)據(jù)放在memcache即可。如果是后臺(tái)的分析需要，響應(yīng)要求不高，查詢非索引的字段即便直接掃表也費(fèi)不了太多時(shí)間。如果還受不了，就再建一個(gè)索引得了。

默認(rèn)情況下每個(gè)表都會(huì)有一個(gè)唯一索引：_id，如果插入數(shù)據(jù)時(shí)沒有指定_id，服務(wù)會(huì)自動(dòng)生成一個(gè)_id，為了充分利用已有索引，減少空間開銷，最好是自己指定一個(gè)unique的key為_id，通常用對(duì)象的ID比較合適，比如商品的ID。

capped collection

capped collection是一種特殊的表，它的建表命令為：

db.createCollection("mycoll", {capped:true, size:100000})

允許在建表之初就指定一定的空間大小，接下來的插入操作會(huì)不斷地按順序APPEND數(shù)據(jù)在這個(gè)預(yù)分配好空間的文件中，如果已經(jīng)超出空間大小，則回到文件頭覆蓋原來的數(shù)據(jù)繼續(xù)插入。這種結(jié)構(gòu)保證了插入和查詢的高效性，它不允許刪除單個(gè)記錄，更新的也有限制：不能超過原有記錄的大小。這種表效率很高，它適用于一些暫時(shí)保存數(shù)據(jù)的場合，比如網(wǎng)站中登錄用戶的session信息，又比如一些程序的監(jiān)控日志，都是屬于過了一定的時(shí)間就可以被覆蓋的數(shù)據(jù)。

復(fù)制與分片

mongodb的復(fù)制架構(gòu)跟mysql也很類似，除了包括master-slave構(gòu)型和master-master構(gòu)型之外，還有一個(gè)Replica pairs構(gòu)型，這種構(gòu)型在平?？梢韵駇aster-slave那樣工作，一但master出現(xiàn)問題，應(yīng)用會(huì)自動(dòng)了連接slave。要做復(fù)制也很簡單，我自己使用過master-slave構(gòu)型，只要在某一個(gè)服務(wù)啟動(dòng)時(shí)加上–master參數(shù)，而另一個(gè)服務(wù)加上–slave與–source參數(shù)，即可實(shí)現(xiàn)同步。

分片是個(gè)很頭疼的問題，數(shù)據(jù)量大了肯定要分片，mysql下的分片正是成為無數(shù)DBA的噩夢(mèng)。在mongodb下，文檔數(shù)據(jù)庫類似key-value數(shù)據(jù)庫那樣的易分布特性就顯現(xiàn)出來了，無論構(gòu)造分片服務(wù)，新增節(jié)點(diǎn)還是刪除節(jié)點(diǎn)都非常容易實(shí)現(xiàn)。但mongodb在這方面做還不足夠成熟，現(xiàn)在分片的工作還只做到alpha2版本（mongodb v1.1），估計(jì)還有很多問題要解決，所以只能期待，就不多說了。

性能

在我的使用場合下，千萬級(jí)別的文檔對(duì)象，近10G的數(shù)據(jù)，對(duì)有索引的ID的查詢不會(huì)比mysql慢，而對(duì)非索引字段的查詢，則是全面勝出。mysql實(shí)際無法勝任大數(shù)據(jù)量下任意字段的查詢，而mongodb的查詢性能實(shí)在讓我驚訝。寫入性能同樣很令人滿意，同樣寫入百萬級(jí)別的數(shù)據(jù)，mongodb比我以前試用過的couchdb要快得多，基本10分鐘以下可以解決。補(bǔ)上一句，觀察過程中mongodb都遠(yuǎn)算不上是CPU殺手。

GridFS

gridfs是mongodb一個(gè)很有趣的類似文件系統(tǒng)的東西，它可以用一大塊文件空間來存放大量的小文件，這個(gè)對(duì)于存儲(chǔ)web2.0網(wǎng)站中常見的大量小文件（如大量的用戶頭像）特別有效。使用起來也很方便，基本上跟一般的文件系統(tǒng)類似。

用合適的數(shù)據(jù)庫做適合的事情

mongodb的文檔里提到的user case包括實(shí)時(shí)分析、logging、全文搜索，國內(nèi)也有人使用mongodb來存儲(chǔ)分析網(wǎng)站日志，但我認(rèn)為mongodb用來處理有一定規(guī)模的網(wǎng)站日志其實(shí)并不合適，最主要的就是它占空間過于虛高，原來1G的日志數(shù)據(jù)它可以存成幾個(gè)G，如此下去，一個(gè)硬盤也存不了幾天的日志。另一方面，數(shù)據(jù)量大了肯定要考慮sharding，而mongodb的sharding到現(xiàn)在為止仍不太成熟。由于日志的不可更新性的，往往只需APPEND即可，又因?yàn)閷?duì)日志的操作往往只集中于一兩列，所以最合適作為日志分析的還是列存儲(chǔ)型的數(shù)據(jù)庫，特別是像infobright那樣的為數(shù)據(jù)倉庫而設(shè)計(jì)的列存儲(chǔ)數(shù)據(jù)庫。

由于mongodb不支持事務(wù)操作，所以事務(wù)要求嚴(yán)格的系統(tǒng)（如果銀行系統(tǒng)）肯定不能用它。

mongodb占用空間過大的原因，在官方的FAQ中，提到有如下幾個(gè)方面：

1、空間的預(yù)分配：為避免形成過多的硬盤碎片，mongodb每次空間不足時(shí)都會(huì)申請(qǐng)生成一大塊的硬盤空間，而且申請(qǐng)的量從64M、128M、256M那樣的指數(shù)遞增，直到2G為單個(gè)文件的最大體積。隨著數(shù)據(jù)量的增加，你可以在其數(shù)據(jù)目錄里看到這些整塊生成容量不斷遞增的文件。

2、字段名所占用的空間：為了保持每個(gè)記錄內(nèi)的結(jié)構(gòu)信息用于查詢，mongodb需要把每個(gè)字段的key-value都以BSON的形式存儲(chǔ)，如果value域相對(duì)于key域并不大，比如存放數(shù)值型的數(shù)據(jù)，則數(shù)據(jù)的overhead是最大的。一種減少空間占用的方法是把字段名盡量取短一些，這樣占用空間就小了，但這就要求在易讀性與空間占用上作為權(quán)衡了。我曾建議作者把字段名作個(gè)index，每個(gè)字段名用一個(gè)字節(jié)表示，這樣就不用擔(dān)心字段名取多長了。但作者的擔(dān)憂也不無道理，這種索引方式需要每次查詢得到結(jié)果后把索引值跟原值作一個(gè)替換，再發(fā)送到客戶端，這個(gè)替換也是挺耗費(fèi)時(shí)間的?，F(xiàn)在的實(shí)現(xiàn)算是拿空間來換取時(shí)間吧。

3、刪除記錄不釋放空間：這很容易理解，為避免記錄刪除后的數(shù)據(jù)的大規(guī)模挪動(dòng)，原記錄空間不刪除，只標(biāo)記“已刪除”即可，以后還可以重復(fù)利用。

4、可以定期運(yùn)行db.repairDatabase()來整理記錄，但這個(gè)過程會(huì)比較緩慢。

因?yàn)?a onclick="javascript:pageTracker._trackPageview('/outbound/article/www.');" href="http://www./display/DOCS/Home" target=_blank>官方文檔中對(duì)各方面的內(nèi)容已經(jīng)有很詳細(xì)的敘述，所以我并沒有再過多的引用原文與代碼，只是結(jié)合自己的使用歸納一些心得，有興趣的朋友不妨直接去翻文檔中自己感興趣的問題，超群的博客上有一個(gè)很好的入門介紹。

最后總結(jié)一句，文檔型數(shù)據(jù)庫有點(diǎn)像波粒二象性，總能在適當(dāng)?shù)臅r(shí)候表現(xiàn)出它作為關(guān)系型數(shù)據(jù)庫或key-value數(shù)據(jù)庫的優(yōu)勢來。

實(shí)戰(zhàn)案例：

昨天我訪問mongodb的python程序開始出錯(cuò)，經(jīng)常拋出AssertionError異常，經(jīng)查證只是master查詢異常，slave正常，可判斷為master的數(shù)據(jù)出了問題。

修復(fù)過程：

1、在master做db.repairDatabase()，不起作用；

2、停止slave的同步；

3、對(duì)slave作mongodump，備份數(shù)據(jù)；

4、對(duì)master作mongostore，把備份數(shù)據(jù)恢復(fù)，使用–drop參數(shù)可以先把原表刪除。

5、恢復(fù)slave的同步。