在項目設計的初期，我當時有了這樣的想法，同時也是在滿足下面幾個條件的情況下來選擇最終的nosql方案的：

1、需求變化頻繁：開發(fā)要更加敏捷，開發(fā)成本和維護成本要更低，要能夠快速地更新進化，新功能要在最短的周期內上線。
2、客戶端/api支持，因為這直接影響開發(fā)效率
3、部署簡單
4、擴展能力強
5、節(jié)省系統資源，對cpu等資源耗費較小

滿足這些要求的nosql方案，就剩下了mongodb和redis了，對于redis，我并不是說他不好，而是有一個重要原因，我們的項目的數據處理格式都是采用JSON的形式來處理的，這一點對于后來兩者之間的選擇，起到了決定性作用。

當然，Redis對豐富數據類型的操作很吸引人，可以輕松解決一些應用場景，其讀寫性能也相當高，之前的版本是存儲和內存掛鉤是掛鉤的，這樣如果存儲大量的數據需要消耗太多的內存，當然現在的版本已經么有這樣的問題了。

MongoDB是一個面向文檔的數據庫，目前由10gen開發(fā)并維護，它的功能豐富，齊全，完全可以替代MySQL。

在我項目實施的過程中，我總結了mongodb的一些很好的亮點：

為什么MongoDB可以替代MySQL？

1、使用JSON風格語法，易于掌握和理解：MongoDB使用JSON的變種BSON作為內部存儲的格式和語法。針對MongoDB的操作都使用JSON風格語法，客戶端提交或接收的數據都使用JSON形式來展現。相對于SQL來說，更加直觀，容易理解和掌握。這也是根據我自己項目的情況出發(fā)，最后選擇了mongodb的一個原因。

2、Schema-less，支持嵌入子文檔：MongoDB是一個Schema-free的文檔數據庫。一個數據庫可以有多個Collection，每個Collection是Documents的集合。Collection和Document和傳統數據庫的Table和Row并不對等。無需事先定義Collection，隨時可以創(chuàng)建。Collection中可以包含具有不同schema的文檔記錄。 這意味著，你上一條記錄中的文檔有3個屬性，而下一條記錄的文檔可以有10個屬性，屬性的類型既可以是基本的數據類型（如數字、字符串、日期等），也可以是數組或者散列，甚至還可以是一個子文檔（embed document）。這樣，可以實現逆規(guī)范化（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創(chuàng)建一個唯一索引。

6、性能高效，速度快： MongoDB使用c++/boost編寫，在多數場合，其查詢速度對比MySQL要快的多，對于CPU占用非常小。部署也很簡單，對大多數系統，只需下載后二進制包解壓就可以直接運行，幾乎是零配置。

7、服務端腳本和Map/Reduce：MongoDB允許在服務端執(zhí)行腳本，可以用Javascript編寫某個函數，直接在服務端執(zhí)行，也可以把函數的定義存儲在服務端，下次直接調用即可。MongoDB不支持事務級別的鎖定，對于某些需要自定義的“原子性”操作，可以使用Server side腳本來實現，此時整個MongoDB處于鎖定狀態(tài)。Map/Reduce也是MongoDB中比較吸引人的特性。Map/Reduce可以對大數據量的表進行統計、分類、合并的工作，完成原先SQL的GroupBy等聚合函數的功能。并且Mapper和Reducer的定義都是用Javascript來定義服務端腳本。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com