項目中我為什麼用Mongodb取代Mysql

 　　在項目設計的初期，我當時有了這樣的想法，同時也是在滿足下面幾個條件的情況下來選擇最終的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，支援範圍查詢、Regex查詢。

　　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來定義服務端指令碼。