筆者經驗尚淺，對於NOSql也是2014年初才正式接觸，並且很遺憾的是，接觸也只是自我學習為主，還未真正涉及到專案運用中。所以這裡標題也用到了淺析二字。如有大牛接觸過，且有幸被搜尋引擎抓到，還請大牛不吝賜教或指點一二。

1.在NoSql領域中其實存在很多解決方案。除去Mongodb 還有 HBase、memcacheDB、neo4J等，但是這幾種的設計模式各有千秋，也就是實現方式有所不同。如：Key-value、列儲存、文件儲存、圖儲存、物件儲存、xml儲存等，說白了就是儲存的資料模型不同，但是其實都是NoSql的實現。

2.接觸較多以及較為廣泛的、或者是說較為人知的一個NoSql：mongodb，曾記得是一個南京的朋友向我提起過。我這人有個毛病就是如果別人說的技術我不會，我總會記錄下來，然後不停的利用搜索引擎去需求講解以及demo。當然這些也只能暫時停留在基礎認知方面，對於真實在實際生產中是如何應用的，或者是在整體專案架構中其到底扮演什麼角色還是難以明白，以及NoSql對於目前的關係資料庫有哪些優點和不足還是不清楚。

3.其實筆者事先在網上也查了很多關於此方面的資料（mongodb 與 Mysql 的比較），並且通過實驗也大概明白了或者說基本懂了mongodb的優勢以及應用場景，所以筆者為了記錄自己學習mongodb的過程要求自己寫下部落格作為記錄。

4.網上有篇博文明確的給出了mongodb和mysql 在插入查詢以及更新效能上做了比較：

http://blog.csdn.net/e421083458/article/details/8849247

大家可以去看看，上面說mongodb在速度上是mysql的2倍，其實正如大多數人來說2倍好像有點少了，的確其實我也感覺才2倍，雖然隨著資料量的越來越大 速度的倍數肯定會增加，但是、、、、。因此自己還是需要自己親身做一下實驗。

程式設計工具：eclipse

語言：java 6.0

資料庫：Mysql  5.1

NoSql：mongoDb    win32-i386-2.6.1

驅動 Jar包：mongo-2.10.1.jar mysql-connector-java-5.1.6-bin.jar

測試1【單條插入】

測試2【100條插入-一個連線】

測試3【1000條插入-一個連線】

測試4【1000條插入-一個連線 mysql採取JDBC批量操作】

測試5【100萬條插入-一個連線 mysql採取JDBC批量操作】

以上資料我就不分析了。可想而知如果100萬條資料 如果我不用批量操作 那麼那將有多慢啊！！！！！！

其實在web的應用場景下，併發問題就是同時多個數據庫連線來對資料庫進行操作，但是這些資料並不可以使用批量操作這樣的場景來處理。

所以高併發其實類似於jdbc的 for迴圈單個插入提交一樣,而且速度會更慢。如果是這樣的話，那麼這種情況 mongodb的效率就是很高的，而且面臨高併發基本上沒有什麼壓力。

資料庫模式：使用者建立連線-資料庫引擎接受-資料庫引擎解析sql語法-對映資料模型以及關係-建模並IO插入資料庫儲存檔案

NoSql模式：使用者建立連線-NoSql引擎接受-建模IO插入檔案

其實我們可以認為 NoSql速度上比關係資料庫快 在於 資料庫引擎解析sql語法-對映資料模型以及關係-   時間都花在這些上面，當然這只是概念的說明一下，其實關係資料庫插入一條資料要比這個複雜的多，也包括事務、索性、檢查等一系列操作。

其實我們可以發現在 jdbc批量插入的原理是  將sql語句初始化好-然後將多條插入語句一併提交到資料庫-資料庫統一解析，最終入庫 然後返回使用者結果。所以批量操作節約的時間在於 傳送sql 資料庫引擎接受 以及返回結果這樣的時間。所以資料在傳送到資料庫的過程中相當耗時以及在資料中資料插入的一個整體流程中。（跑題了）

那麼我們知道了這些 ，我們可以分析一下Nosql的應用場景了。

mongo使用場合

    mongodb的主要目標是在鍵/值儲存方式（提供了高效能和高度伸縮性）以及傳統的RDBMS系統（豐富的功能）架起一座橋樑，集兩者的優勢於一身。mongo適用於以下場景：

  1.網站資料：mongo非常適合實時的插入，更新與查詢，並具備網站實時資料儲存所需的複製及高度伸縮性。

  2.快取：由於效能很高，mongo也適合作為資訊基礎設施的快取層。在系統重啟之後，由mongo搭建的持久化快取可以避免下層的資料來源過載。

  3.大尺寸、低價值的資料：使用傳統的關係資料庫儲存一些資料時可能會比較貴，在此之前，很多程式設計師往往會選擇傳統的檔案進行儲存。

  4.高伸縮性的場景：mongo非常適合由數十或者數百臺伺服器組成的資料庫。

  5.用於物件及JSON資料的儲存：mongo的BSON資料格式非常適合文件格式化的儲存及查詢。

  6.重要資料：mysql，一般資料：mongodb，臨時資料：memcache

  7.對於關係資料表而言，mongodb是提供了一個更快速的檢視view；而對於PHP程式而言，mongodb可以作為一個持久化的陣列來使用，並且這個持久化的陣列還可以支援排序、條件、限制等功能。

 8.將mongodb代替mysql的部分功能，主要一個思考點就是：把mongodb當作mysql的一個view（檢視），view是將表資料整合成業務資料的關鍵。比如說對原始資料進行報表，那麼就要先把原始資料統計後生成view，在對view進行查詢和報表。從這個意義上，mongodb提供了一個更快速，更使用的view

不適合的場景：

  a.高度事物性的系統：例如銀行或會計系統。傳統的關係型資料庫目前還是更適用於需要大量原子性複雜事務的應用程式。

  b.傳統的商業智慧應用：針對特定問題的BI資料庫會對產生高度優化的查詢方式。對於此類應用，資料倉庫可能是更合適的選擇。

  c.需要SQL的問題

  D.重要資料，關係資料

這裡需要注意的是：在實際專案中為了減小開銷傳統關係資料庫在web開發中  會採取連線池的方式 提高效率，而在mongodb中mongo例項化其實就是一個連線，預設貌似是10個，高併發會採取佇列的方式等待 執行緒安全，當然去生產環境肯定是需要配置的，否則會發生問題，且下載的mongo 32位的 預設儲存只是2個G左右(官方有詳細說明)，後續增加就會報錯。（http://blog.csdn.net/aegoose/article/details/22396243）

～～～～僅供參考 後續將對mongodb分散式進行研究，也就是多個mongodb分散式方案，目的進一步提高效率

以及會對各大型網站架構中mongodb所扮演的角色進行分析，從而定位大型專案中的角色。

（個人微訊號）  （技術公眾號）