按照官方的說法，MongoDB是一種可擴展的高性能的開源的面向文檔（document-oriented ）的數據庫，采用C++開發。注意mongo不是mango（芒果），這個詞是從humongous中截取出來的，其野心不言而明，直指海量數據存儲。和其他很多NoSQL不太一樣，MongoDB背后有一個專門的商業公司在提供支持和推廣，有點類似MySQL AB的模式。這一系列文章，是為入門者寫的，已經對NoSQL和MongoDB有一定研究和經驗的，可以略過，或者看看如有疏漏，請留言指出。

　　面向文檔，那么什么是文檔呢？很明顯這不是我們常見的word文檔。這里說的文檔，是一種可以嵌套的數據集合。從關系數據庫的范式的概念來說，嵌套是明顯的反范式設計。范式設計的好處是消除了依賴，但是增加了關聯，查詢需要通過關聯兩張或者多張表來獲得所需要的全部數據，但是更改操作是原子的，只需要修改一個地方即可。反范式則是增加了數據冗余來提升查詢性能，但更新操作可能需要更新冗余的多處數據，需要注意一致性的問題。

　　一個典型的例子，如blog，關系數據庫中一般可以把文章設計為一張表，評論設計為一張表，那么在頁面需要展示一篇文章和其對應的評論的時候，就需要關聯查詢文章表和評論表。但是面向文檔的設計，可以將評論作為文章的一個嵌套文檔存放在一起，這不但省去了關聯查詢，由于存儲在一起，查詢的性能也可以做到更好。

　　MongoDB的面向文檔采用的是BSON，一種類似JSON的格式，但是是二進制序列化的。如上面提到的blog的文章和評論，可以做如下設計：

1. 相關數據存放在一起，針對性的查詢可以消除join，性能比分散存儲要高且方便。

　　2. 整個結構清晰自解析。所有字段名和值都存儲，所以不需要提前設計結構，key的名字和數目可以任意指定，也就是所謂的schema-free。
　　3. 由于字段名在每一行每一列都需要重復存在，會帶來一些額外的存儲消耗，這在海量數據及字段較多的時候也需要考慮。
　　4. 一個document的長度有限，1.7.2之前是4MB，目前是8MB，以后可能增長到32MB。如果有更大的數據，可以使用MongoDB底層的GridFS直接作為文件存儲。
　　5. 如果需要查找某個評論者的所有評論，則相對困難。當然，MongoDB支持任意key的索引，這也不是什么大問題。

　　像上面的一個結構，為一個文檔（document），相當于關系數據庫中的一行記錄，多個文檔組成一個集合（collection），相當于關系數據庫的表。多個集合（collection），邏輯上組織在一起，就是數據庫（database），一個MongoDB實例支持多個數據庫（database）。

　　大部分的NoSQL產品，為追求性能，一致性等，一般只能支持簡單的基于row-key的單條或者范圍查詢，但是MongoDB可以針對任意列的key創建索引，甚至是內嵌文檔里的key，從支持的查詢的靈活性上來看，更接近傳統的關系數據庫，同時還能在性能上向NoSQL看齊，加上支持復制，自動分片和Map/Reduce等功能，非常的吸引眼球，正在成為一款熱門的海量存儲產品。其背后的商業支持公司10gen，也正在不遺余力的推廣，前不久還在北京專門組織了一場技術交流會。在其首頁列舉的典型客戶里，包括foursquare，sourceforge，github等知名互聯網公司和應用，當然，也包括淘寶網。