在項目設計的初期，我當時有了這樣的想法，同時也是在滿足下面幾個條件的情況下來選擇最終的nosql方案的：
1、需求變化頻繁：開發要更加敏捷，開發成本和維護成本要更低，要能夠快速地更新進化，新功能要在最短的周期內上線。
2、客戶端/api支持，因為這直接影響開發效率
3、部署簡單
4、擴展能力強
5、節省系統資源，對cpu等資源耗費較小
滿足這些要求的nosql方案，就剩下了mongodb和redis了，對於redis，我並不是說他不好，而是有一個重要原因，我們的項目的數據處理格式都是采用JSON的形式來處理的，這一點對於後來兩者之間的選擇，起到了決定性作用。
當然，Redis對豐富數據類型的操作很吸引人，可以輕松解決一些應用場景，其讀寫性能也相當高，之前的版本是存儲和內存掛鉤是掛鉤的，這樣如果存儲大量的數據需要消耗太多的內存，當然現在的版本已經麼有這樣的問題了。
MongoDB是一個面向文檔的數據庫，目前由10gen開發並維護，它的功能豐富，齊全，完全可以替代MySQL。
在我項目實施的過程中，我總結了mongodb的一些很好的亮點：
為什麼MongoDB可以替代MySQL?
1、使用JSON風格語法，易於掌握和理解：MongoDB使用JSON的變種BSON作為內部存儲的格式和語法。針對MongoDB的操作都使用JSON風格語法，客戶端提交或接收的數據都使用JSON形式來展現。相對於SQL來說，更加直觀，容易理解和掌握。這也是根據我自己項目的情況出發，最後選擇了mongodb的一個原因。
2、Schema-less，支持嵌入子文檔：MongoDB是一個Schema-free的文檔數據庫。一個數據庫可以有多個Collection，每個Collection是Documents的集合。Collection和Document和傳統數據庫的Table和Row並不對等。無需事先定義Collection，隨時可以創建。Collection中可以包含具有不同schema的文檔記錄。 這意味著，你上一條記錄中的文檔有3個屬性，而下一條記錄的文檔可以有10個屬性，屬性的類型既可以是基本的數據類型(如數字、字符串、日期等)，也可以是數組或者散列，甚至還可以是一個子文檔(embed document)。這樣，可以實現逆規范化(denormalizing)的數據模型，提高查詢的速度。
3、簡單易用的查詢方式：直接使用JSON，支持范圍查詢、正則表達式查詢。
4、CRUD更加簡單，支持in-place update：只要定義一個數組，然後傳遞給MongoDB的insert/update方法就可自動插入或更新;對於更新模式，MongoDB支持一個upsert選項，即：“如果記錄存在那麼更新，否則插入”。MongoDB的update方法還支持Modifier，通過Modifier可實現在服務端即時更新，省去客戶端和服務端的通訊。這些modifer可以讓MongoDB具有和Redis、Memcached等KV類似的功能：較之MySQL，MonoDB更加簡單快速。Modifier也是MongoDB可以作為對用戶行為跟蹤的容器。在實際中使用Modifier來將用戶的交互行為快速保存到MongoDB中以便後期進行統計分析和個性化定制
5、所有的屬性類型都支持索引，甚至數組：這可以讓某些任務實現起來非常的輕松。在MongoDB中，“_id”屬性是主鍵，默認MongoDB會對_id創建一個唯一索引。
6、性能高效，速度快： MongoDB使用c++/boost編寫，在多數場合，其查詢速度對比MySQL要快的多，對於CPU占用非常小。部署也很簡單，對大多數系統，只需下載後二進制包解壓就可以直接運行，幾乎是零配置。
7、服務端腳本和Map/Reduce：MongoDB允許在服務端執行腳本，可以用Javascript編寫某個函數，直接在服務端執行，也可以把函數的定義存儲在服務端，下次直接調用即可。MongoDB不支持事務級別的鎖定，對於某些需要自定義的“原子性”操作，可以使用Server side腳本來實現，此時整個MongoDB處於鎖定狀態。Map/Reduce也是MongoDB中比較吸引人的特性。Map/Reduce可以對大數據量的表進行統計、分類、合並的工作，完成原先SQL的GroupBy等聚合函數的功能。並且Mapper和Reducer的定義都是用Javascript來定義服務端腳本。
