用了一陣子mongodb，作一些小結，作爲將來的參考。按照以往的習慣，先作一個總覽，然後再挑出一些自己比較關注的幾個點，作爲珠璣，加以串聯闡述。
mongodb由C＋＋寫就，其名字來自humongous這個單詞的中間部分，從名字可見其野心所在就是海量數據的處理。關於它的一個最簡潔描述爲：scalable, high-performance, open source, schema-free, document-oriented database。我對於文檔型數據庫有一些個人的偏好，這種偏好是從半年前研究couchdb而來的，因爲我覺得用它來描述一個具有個性化特徵的實體對象正合適，比如網站上的用戶或商品書籍之類的條目。
一些概念：
跟mysqld一樣，一個mongod服務可以有建立多個數據庫，每個數據庫可以有多張表，這裏的表名叫collection，每個collection可以存放多個文檔（document），每個文檔都以BSON（binary json）的形式存放於硬盤中。跟關係型數據庫不一樣的地方是，它是的以單文檔爲單位存儲的，你可以任意給一個或一批文檔新增或刪除字段，而不會對其它文檔造成影響，這就是所謂的schema-free，這也是文檔型數據庫最主要的優點。跟一般的key-value數據庫不一樣的是，它的value中存儲了結構信息，所以你又可以像關係型數據庫那樣對某些域進行讀寫、統計等操作。可以說是兼備了key-value數據庫的方便高效與關係型數據庫的強大功能。
索引
跟關係型數據庫類似，mongodb可以對某個字段建立索引，可以建立組合索引、唯一索引，也可以刪除索引。當然建立索引就意味着增加空間開銷，我的建議是，如果你能把一個文檔作爲一個對象的來考慮，在線上應用中，你通常只要對對象ID建立一個索引即可，根據ID取出對象某些數據放在memcache即可。如果是後臺的分析需要，響應要求不高，查詢非索引的字段即便直接掃表也費不了太多時間。如果還受不了，就再建一個索引得了。
默認情況下每個表都會有一個唯一索引：_id，如果插入數據時沒有指定_id，服務會自動生成一個_id，爲了充分利用已有索引，減少空間開銷，最好是自己指定一個unique的key爲_id，通常用對象的ID比較合適，比如商品的ID。
capped collection
capped collection是一種特殊的表，它的建表命令爲：
db.createCollection("mycoll", {capped:true, size:100000})
允許在建表之初就指定一定的空間大小，接下來的插入操作會不斷地按順序APPEND數據在這個預分配好空間的文件中，如果已經超出空間大小，則回到文件頭覆蓋原來的數據繼續插入。這種結構保證了插入和查詢的高效性，它不允許刪除單個記錄，更新的也有限制：不能超過原有記錄的大小。這種表效率很高，它適用於一些暫時保存數據的場合，比如網站中登錄用戶的session信息，又比如一些程序的監控日誌，都是屬於過了一定的時間就可以被覆蓋的數據。
複製與分片
mongodb的複製架構跟mysql也很類似，除了包括master-slave構型和master-master構型之外，還有一個Replica pairs構型，這種構型在平常可以像master-slave那樣工作，一但master出現問題，應用會自動了連接slave。要做複製也很簡單，我自己使用過master-slave構型，只要在某一個服務啓動時加上–master參數，而另一個服務加上–slave與–source參數，即可實現同步。
分片是個很頭疼的問題，數據量大了肯定要分片，mysql下的分片正是成爲無數DBA的噩夢。在mongodb下，文檔數據庫類似key-value數據庫那樣的易分佈特性就顯現出來了，無論構造分片服務，新增節點還是刪除節點都非常容易實現。但mongodb在這方面做還不足夠成熟，現在分片的工作還只做到alpha2版本（mongodb v1.1），估計還有很多問題要解決，所以只能期待，就不多說了。
性能
在我的使用場合下，千萬級別的文檔對象，近10G的數據，對有索引的ID的查詢不會比mysql慢，而對非索引字段的查詢，則是全面勝出。mysql實際無法勝任大數據量下任意字段的查詢，而mongodb的查詢性能實在讓我驚訝。寫入性能同樣很令人滿意，同樣寫入百萬級別的數據，mongodb比我以前試用過的couchdb要快得多，基本10分鐘以下可以解決。補上一句，觀察過程中mongodb都遠算不上是CPU殺手。
GridFS
gridfs是mongodb一個很有趣的類似文件系統的東西，它可以用一大塊文件空間來存放大量的小文件，這個對於存儲web2.0網站中常見的大量小文件（如大量的用戶頭像）特別有效。使用起來也很方便，基本上跟一般的文件系統類似。
用合適的數據庫做適合的事情
mongodb的文檔裏提到的user case包括實時分析、logging、全文搜索，國內也有人使用mongodb來存儲分析網站日誌，但我認爲mongodb用來處理有一定規模的網站日誌其實並不合適，最主要的就是它佔空間過於虛高，原來1G的日誌數據它可以存成幾個G，如此下去，一個硬盤也存不了幾天的日誌。另一方面，數據量大了肯定要考慮sharding，而mongodb的sharding到現在爲止仍不太成熟。由於日誌的不可更新性的，往往只需APPEND即可，又因爲對日誌的操作往往只集中於一兩列，所以最合適作爲日誌分析的還是列存儲型的數據庫，特別是像infobright那樣的爲數據倉庫而設計的列存儲數據庫。
由於mongodb不支持事務操作，所以事務要求嚴格的系統（如果銀行系統）肯定不能用它。
mongodb佔用空間過大的原因，在官方的FAQ中，提到有如下幾個方面：
1、空間的預分配：爲避免形成過多的硬盤碎片，mongodb每次空間不足時都會申請生成一大塊的硬盤空間，而且申請的量從64M、128M、256M那樣的指數遞增，直到2G爲單個文件的最大體積。隨着數據量的增加，你可以在其數據目錄裏看到這些整塊生成容量不斷遞增的文件。
2、字段名所佔用的空間：爲了保持每個記錄內的結構信息用於查詢，mongodb需要把每個字段的key-value都以BSON的形式存儲，如果value域相對於key域並不大，比如存放數值型的數據，則數據的overhead是最大的。一種減少空間佔用的方法是把字段名儘量取短一些，這樣佔用空間就小了，但這就要求在易讀性與空間佔用上作爲權衡了。我曾建議作者把字段名作個index，每個字段名用一個字節表示，這樣就不用擔心字段名取多長了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換，再發送到客戶端，這個替換也是挺耗費時間的。現在的實現算是拿空間來換取時間吧。
3、刪除記錄不釋放空間：這很容易理解，爲避免記錄刪除後的數據的大規模挪動，原記錄空間不刪除，只標記“已刪除”即可，以後還可以重複利用。
4、可以定期運行db.repairDatabase()來整理記錄，但這個過程會比較緩慢。
因爲官方文檔中對各方面的內容已經有很詳細的敘述，所以我並沒有再過多的引用原文與代碼，只是結合自己的使用歸納一些心得，有興趣的朋友不妨直接去翻文檔中自己感興趣的問題，超羣的博客上有一個很好的入門介紹。
最後總結一句，文檔型數據庫有點像波粒二象性，總能在適當的時候表現出它作爲關係型數據庫或key-value數據庫的優勢來。
實戰案例：
昨天我訪問mongodb的python程序開始出錯，經常拋出AssertionError異常，經查證只是master查詢異常，slave正常，可判斷爲master的數據出了問題。
修復過程：
1、在master做db.repairDatabase()，不起作用；
2、停止slave的同步；
3、對slave作mongodump，備份數據；
4、對master作mongostore，把備份數據恢復，使用–drop參數可以先把原表刪除。
5、恢復slave的同步。
轉載：http://www.wentrue.net/blog/?p=772
