MySQL與MongoDB的區別

一.MongoDB簡介

什麼是MongoDB ?
MongoDB 是由C++語言編寫的，是一個基於分佈式文件存儲的開源數據庫系統。
在高負載的狀況下，添加更多的節點，能夠保證服務器性能。
MongoDB 旨在爲WEB應用提供可擴展的高性能數據存儲解決方案。
MongoDB 將數據存儲爲一個文檔，數據結構由鍵值(key=>value)對組成。MongoDB 文檔相似於 JSON 對象。字段值能夠包含其餘文檔，數組及文檔數組。

 

主要特色
MongoDB的提供了一個面向文檔存儲，操做起來比較簡單和容易。
你能夠在MongoDB記錄中設置任何屬性的索引 (如：FirstName="Sameer",Address="8 Gandhi Road")來實現更快的排序。
你能夠經過本地或者網絡建立數據鏡像，這使得MongoDB有更強的擴展性。
若是負載的增長（須要更多的存儲空間和更強的處理能力） ，它能夠分佈在計算機網絡中的其餘節點上這就是所謂的分片。
Mongo支持豐富的查詢表達式。查詢指令使用JSON形式的標記，可輕易查詢文檔中內嵌的對象及數組。
MongoDb 使用update()命令能夠實現替換完成的文檔（數據）或者一些指定的數據字段 。
Mongodb中的Map/reduce主要是用來對數據進行批量處理和聚合操做。
Map和Reduce。Map函數調用emit(key,value)遍歷集合中全部的記錄，將key與value傳給Reduce函數進行處理。
Map函數和Reduce函數是使用Javascript編寫的，並能夠經過db.runCommand或mapreduce命令來執行MapReduce操做。
GridFS是MongoDB中的一個內置功能，能夠用於存放大量小文件。
MongoDB容許在服務端執行腳本，能夠用Javascript編寫某個函數，直接在服務端執行，也能夠把函數的定義存儲在服務端，下次直接調用便可。
MongoDB支持各類編程語言:RUBY，PYTHON，JAVA，C++，PHP，C#等多種語言。
MongoDB安裝簡單。

歷史 2007年10月，MongoDB由10gen團隊所發展。2009年2月首度推出。
2012年05月23日，MongoDB2.1 開發分支發佈了! 該版本採用全新架構，包含諸多加強。
2012年06月06日，MongoDB 2.0.6 發佈，分佈式文檔數據庫。
2013年04月23日，MongoDB 2.4.3 發佈，此版本包括了一些性能優化，功能加強以及bug修復。
2013年08月20日，MongoDB 2.4.6 發佈，是目前最新的穩定版。

MongoDB 下載
你能夠在mongodb官網下載該安裝包，地址爲： http://www.mongodb.org/downloads。MonggoDB支持如下平臺:
OS X 32-bit
OS X 64-bit
Linux 32-bit
Linux 64-bit
Windows 32-bit
Windows 64-bit
Solaris i86pc
Solaris 64

MongoDB 工具
有幾種可用於MongoDB的管理工具。

監控
MongoDB提供了網絡和系統監控工具Munin，它做爲一個插件應用於MongoDB中。
Gangila是MongoDB高性能的系統監視的工具，它做爲一個插件應用於MongoDB中。
基於圖形界面的開源工具 Cacti, 用於查看CPU負載, 網絡帶寬利用率,它也提供了一個應用於監控 MongoDB 的插件。

GUI
Fang of Mongo – 網頁式,由Django和jQuery所構成。
Futon4Mongo – 一個CouchDB Futon web的mongodb山寨版。
Mongo3 – Ruby寫成。
MongoHub – 適用於OSX的應用程序。
Opricot – 一個基於瀏覽器的MongoDB控制檯, 由PHP撰寫而成。
Database Master — Windows的mongodb管理工具
RockMongo — 最好的PHP語言的MongoDB管理工具，輕量級, 支持多國語言.

MongoDB 應用案例
下面列舉一些公司MongoDB的實際應用：
Craiglist上使用MongoDB的存檔數十億條記錄。
FourSquare，基於位置的社交網站，在Amazon EC2的服務器上使用MongoDB分享數據。
Shutterfly，以互聯網爲基礎的社會和我的出版服務，使用MongoDB的各類持久性數據存儲的要求。
bit.ly, 一個基於Web的網址縮短服務，使用MongoDB的存儲本身的數據。
spike.com，一個MTV網絡的聯營公司， spike.com使用MongoDB的。
Intuit公司，一個爲小企業和我的的軟件和服務提供商，爲小型企業使用MongoDB的跟蹤用戶的數據。
sourceforge.net，資源網站查找，建立和發佈開源軟件免費，使用MongoDB的後端存儲。
etsy.com ，一個購買和出售手工製做物品網站，使用MongoDB。
紐約時報，領先的在線新聞門戶網站之一，使用MongoDB。
CERN，著名的粒子物理研究所，歐洲核子研究中心大型強子對撞機的數據使用MongoDB。

http://www.runoob.com/mongodb/mongodb-intro.html

 

二.MongoDB和MySQL比較

MongoDB自己它還算比較年輕的一個產品，因此它的問題，就是成熟度確定沒有傳統MySQL那麼成熟穩定。因此在使用的時候，
第一，儘可能使用穩定版，不要在線上使用開發版，這是一個大原則；
另一點，備份很重要，MongoDB若是出現一些異常狀況，備份必定是要能跟上。除了經過傳統的複製的方式來作備份，離線備份也仍是要有，無論你是用什麼方式，都要有一個完整的離線備份。每每最後出現了特殊狀況，它能幫助到你；
另外，MongoDB性能的一個關鍵點就是索引，索引是否是能有比較好的使用效率，索引是否是可以放在內存中，這樣可以提高隨機讀寫的性能。若是你的索引不能徹底放在內存中，一旦出現隨機讀寫比較高的時候，它就會頻繁地進行磁盤交換，這個時候，MongoDB的性能就會急劇降低，會出現波動。
另外，MongoDB還有一個最大的缺點，就是它佔用的空間很大，由於它屬於典型空間換時間原則的類型。那麼它的磁盤空間比普通數據庫會浪費一些，並且到目前爲止它尚未實如今線壓縮功能，在MongoDB中頻繁的進行數據增刪改時，若是記錄變了，例如數據大小發生了變化，這時候容易產生一些數據碎片，出現碎片引起的結果，一個是索引會出現性能問題，
另一個就是在必定的時間後，所佔空間會莫明其妙地增大，因此要按期把數據庫作修復，按期從新作索引，這樣會提高MongoDB的穩定性和效率。在最新的版本里，它已經在實如今線壓縮，估計應該在2.0版左右，應該可以實如今線壓縮，能夠在後臺執行如今repair DataBase的一些操做。若是那樣，就解決了目前困擾咱們的大問題。

http://blog.itpub.net/642366/viewspace-1067038/

三.問題
用戶數據庫是用mongodb好，仍是用mysql好？修改
打算給一系列產品統一帳戶，程序用的是nodejs寫的，用戶數據庫大概就是記錄用戶名、密碼、電子郵箱還有一些會高併發頻繁變動的信息，這種數據庫要用mongodb仍是mysql？或者有更好的推薦嗎？

答案:
a1: mysql更通用 若是不知道選什麼就選mysql錯不了. 而mongodb的存在更多的是對於mysql的一個細分需求領域中的補充.
好比在遊戲行業中 使用json格式的mongodb基本上能夠知足全部數據結構的存儲, 並且你不再必由於擴充一個小功能而糾結新建一個表來存儲 仍是新建一個字段並用字符串來存儲(每次讀/寫都要解析/序列化成字符串存儲), mysql是否是特別傻笨粗, 而遊戲基本上前面搭好框子後面寫業務的時候 一直都是在作這些東西.

但正如我上面說的 mongodb只是一個細分需求領域的補充, 不少東西他作不了也作很差 假如你的程序哪怕有1%的功能在這裏 這都容易悲劇.

另外說一下題主問題中提供的需求見解.
看上去是統一認證系統或者認證平臺之類的需求.
通常有如下特色.
1. 數據結構簡單. 因此用mysql仍是mongodb在這裏都同樣.
2. 可能對讀性能有要求 但寫速度關係不大, 通常都是大量已註冊用戶登陸. 所以mysql必定要配合redis或者memcache, 這樣的話 mongodb稍微勝出一點, mongodb自己的讀速度有優化, 很可觀.
3. 數據結構中含有一些特殊數據 好比玩家的充值信息. mysql明顯比mongodb好的太多.
4. 日誌統計, mysql的存儲過程能夠很方便的作不少統計工做, mongodb的話就要委屈後臺小哥多寫點代碼來作統計了(實際上由於數據簡單 可能也就幾行代碼).

所以呢 根據上面幾點來講, 用mongodb的意義不大, 但具體題主的需求, 本身根據上面我列舉的幾條能夠本身再度量一下.

 

a2: 推薦mysql

更主要仍是看你怎麼用，你要很悠閒，想學習，愛折騰那就mongodb吧。

存儲用戶數據，確定也要讀取吧，還要JOIN關聯，各類查詢，分析。

用mongdb可就麻煩了，group受限，map/reduce不爽

如今的mysql也不知有沒有對mongodb對接的支持。

mysql也就是幾條SQL的事,用mongodb不一樣庫，還得在代碼裏拼數據。

嚐鮮一時爽，卻埋下了之後更多的工做量。

我我的只是用mongodb做相對獨立的小系統，好比一些數據分析，抓取，彙總的工做。

https://www.zhihu.com/question/26095333

四.1.1 MongoDB的簡單介紹
在當今的數據庫市場上，MySQL無疑是佔有一席之地的。做爲一個開源的關係型數據庫，MySQL被大量應用在各大網站後臺中，承擔着信息存儲的重要做用。2009年，甲骨文公司（Oracle）收購Sun公司，MySQL成爲Oracle旗下產品。

而MongoDB是一種文件導向的數據庫管理系統，屬於一種通稱爲NoSQL的數據庫，是10gen公司旗下的開源產品，其內部數據存儲的方式與傳統的關係型數據有很大差異。

NoSQL的全稱是Not Only SQL，也能夠理解非關係型的數據庫，是一種新型的革命式的數據庫設計方式，不過它不是爲了取代傳統的關係型數據庫而被設計的，它們分別表明了不一樣的數據庫設計思路。

雖然MongoDB背後的公司沒有Oracle強大，但其目前也正在被應用在各行各業中。MongoDB是目前被應用最普遍的NoSQL數據庫產品。

1.2 MongoDB的存儲特色
在傳統的關係型數據庫中，數據是以表單爲媒介進行存儲的，每一個表單均擁有縱向的列和橫向的行。

因而可知，相比較MySQL，MongoDB以一種直觀文檔的方式來完成數據的存儲。它很像JavaScript中定義的JSON格式，不過數據在存儲的時候MongoDB數據庫爲文檔增長了序列化的操做，最終存進磁盤的實際上是一種叫作BSON的格式，即Binary-JSON。

1.3 MongoDB的應用場景
在另外一方面，對開發者來講，若是是由於業務需求或者是項目初始階段，而致使數據的具體格式沒法明肯定義的話，MongoDB的這一鮮明特性就脫穎而出了。相比傳統的關係型數據庫，它很是容易被擴展，這也爲寫代碼帶來了極大的方便。

不過MongoDB對數據之間事務關係支持比較弱，若是業務這一方面要求比較高的話，MongoDB仍是並不適合此類型的應用。

 

另外，MongoDB出現的時機比較晚，還具有一些很是鮮明的特性。好比：

1. 它裏面自帶了一個名叫GirdFS的分佈式文件系統，這就爲MongoDB的部署提供了很大便利。而像MySQL這種比較早的數據庫，雖然市面上有不少不一樣的分表部署的方案，但這種終究不如MongoDB直接官方支持來得便捷實在。

2. 另外，MongoDB內部還自建了對map-reduce運算框架的支持，雖然這種支持從功能上看還算是比較簡單的，至關於MySQL裏GroupBy功能的擴展版，不過也爲數據的統計帶來了方便。

3. MongoDB在啓動後會將數據庫中的數據以文件映射的方式加載到內存中。若是內存資源至關豐富的話，這將極大地提升數據庫的查詢速度，畢竟內存的I/O效率比磁盤高多了。

 

可是，做爲一個新鮮的事務，MongoDB也存在着不少不足。它在爲開發人員提供了便利的狀況下，卻在運維上面臨着很多難題，好比：

1. 比起MySQL，MongoDB沒有成熟的運維經驗，須要不斷地探索。

2. MongoDB中的數據存放具備至關的隨意性，不具備MySQL在開始就定義好了。對運維人員來講，他們可能不清楚數據庫內部數據的數據格式，這也會數據庫的運維帶來了麻煩。

2. 測試目的
MongoDB與MySQL做爲兩種不一樣類型的數據庫，當其中存放的記錄愈來愈多的時候，其插入效率將會受到怎樣的影響，是本次實驗所關注的對象。

在這裏，咱們將本次實驗數據庫中數據存儲的規模定在1億條。

總結：

1. 總體上的插入速度仍是和上一回的統計數據相似：MongoDB不指定_id插入 > MySQL不指定主鍵插入 > MySQL指定主鍵插入 > MongoDB指定_id插入。

2. 從圖中能夠看出，在指定主鍵插入數據的時候，MySQL與MongoDB在不一樣數據數量級時，每秒插入的數據每隔一段時間就會有一個波動，在圖表中顯示成爲規律的毛刺現象。而在不指定插入數據時，在大多數狀況下插入速率都比較平均，但隨着數據庫中數據的增多，插入的效率在某一時段有瞬間降低，隨即又會變穩定。

3. 總體上來看，MongoDB的速率波動比MySQL的嚴重，方差變化較大。

4. MongoDB在指定_id插入時，當插入的數據變多以後，插入效率有明顯地降低。在其餘三種的插入測試中，從開始到結束，其插入的速率在大多數的時候都固定在一個標準上。

 

分析：

1. 毛刺現象是由於，當插入的數據太多的時候，MongoDB須要將內存中的數據寫進硬盤，MySQL須要從新分表。這些操做每當數據庫中的數據達到必定量級後就會自動進行，所以每隔一段時間就會有一個明顯的毛刺。

2. MongoDB畢竟仍是新生事物，其穩定性沒有已應用多年的MySQL優秀。

3. MongoDB在指定_id插入的時候，其性能的降低仍是很厲害的。

8.1 測試結論
1. 相比較MySQL，MongoDB數據庫更適合那些讀做業較重的任務模型。MongoDB能充分利用機器的內存資源。若是機器的內存資源豐富的話，MongoDB的查詢效率會快不少。

2. 在帶」_id」插入數據的時候，MongoDB的插入效率其實並不高。若是想充分利用MongoDB性能的話，推薦採起不帶」_id」的插入方式，而後對相關字段做索引來查詢。

8.2 測試須要進一步注意的問題
對MongoDB的讀取測試考慮不周，雖然這只是一個額外的測試。在這個測試中，隨機生成大量待測試的數據頗有必要，但生成大量互不相同的數據就沒有必要了。正是這一點，把個人讀取測試規模限定在了50w條，沒能進一步進行分析。

8.3 MongoDB的優點
1. MongoDB適合那些對數據庫具體數據格式不明確或者數據庫數據格式常常變化的需求模型，並且對開發者十分友好。

2. MongoDB官方就自帶一個分佈式文件系統，能夠很方便地部署到服務器機羣上。MongoDB裏有一個Shard的概念，就是方便爲了服務器分片使用的。每增長一臺Shard，MongoDB的插入性能也會以接近倍數的方式增加，磁盤容量也很能夠很方便地擴充。

3. MongoDB還自帶了對map-reduce運算框架的支持，這也很方便進行數據的統計。

 

其餘方面的優點還在發掘中，本人也是剛剛接觸這個不久。

8.4 MongoDB的缺陷
1. 事務關係支持薄弱。這也是全部NoSQL數據庫共同的缺陷，不過NoSQL並非爲了事務關係而設計的，具體應用仍是很需求。

2. 穩定性有些欠缺，這點從上面的測試即可以看出。

3. MongoDB一方面在方便開發者的同時，另外一方面對運維人員卻提出了至關多的要求。業界並無成熟的MongoDB運維經驗，MongoDB中數據的存放格式也很隨意，等等問題都對運維人員的考驗。

http://blog.csdn.net/clh604/article/details/19608869

5、MySQL與MongoDB都是開源的經常使用數據庫，可是MySQL是傳統的關係型數據庫，MongoDB則是非關係型數據庫，也叫文檔型數據庫，是一種NoSQL的數據庫。它們各有各的優勢，關鍵是看用在什麼地方。因此咱們所熟知的那些SQL（全稱Structured Query Language）語句就不適用於MongoDB了，由於SQL語句是關係型數據庫的標準語言。

以咱們公司項目爲例，在早期的項目中，都在使用關係型數據庫，用過SQLServer,Oracle,DB2,後來所有轉向Mysql,緣由很簡單：Mysql在性能不錯的狀況下，有着開源優點。Mysql的事務性與高性能是咱們主要考慮的。後來，因爲項目要用到用戶系統，即會有大量的用戶數據進行交互－－海量存儲，Mysql的讀寫速度會有一點瓶頸，因而咱們就想到了最近發展很強勢的Nosql。在Nosql早期的memcache的發展下，又出現了不少非關係型數據庫，好比redis,mongodb。通過一段時間的測試，redis與mongodb的讀寫速度確實比Mysql有着很明顯的優點。mongodb的寫入速度大約2.5W/次每秒。

mongodb以BSON結構（二進制）進行存儲，對海量數據存儲有着很明顯的優點。下面是Mongodb與Mysql的操做命令的對比。

http://blog.csdn.net/suxinpingtao51/article/details/40981621

6、對比MySQL，你究竟在何時更須要MongoDB
摘要：對比傳統關係型數據庫，NoSQL有着很是顯著的性能和擴展性優點，然而這些優勢卻創建在一些關鍵功能的丟失之上，好比事務、join等。那麼在數據體積激增的當下，究竟哪一個數據庫纔會適合你的場景，下面看Moshe的分享。

【編者按】隨着數據的爆發性增加，NoSQL獲得的關注已愈來愈多，然而你的用例真正須要使用NoSQL數據庫嗎？又真的適合使用NoSQL嗎？近日，Bright Aqua研發副總裁Moshe Kaplan以BillRun系統爲例，分析了MongoDB的優點和使用場景：

如下爲譯文：
NoSQL已經流行了很長一段時間，那麼到底是什麼場景下你才更須要用到這些「新興事物」，就好比MongoDB？下面是一些總結：

你指望一個更高的寫負載

默認狀況下，對比事務安全，MongoDB更關注高的插入速度。若是你須要加載大量低價值的業務數據，那麼MongoDB將很適合你的用例。可是必須避免在要求高事務安全的情景下使用MongoDB，好比一個1000萬美圓的交易。

不可靠環境保證高可用性

設置副本集（主-從服務器設置）不只方便並且很快，此外，使用MongoDB還能夠快速、安全及自動化的實現節點（或數據中心）故障轉移。

將來會有一個很大的規模

數據庫擴展是很是有挑戰性的，當單表格大小達到5-10GB時，MySQL表格性能會毫無疑問的下降。若是你須要分片而且分割你的數據庫，MongoDB將很容易實現這一點。

使用基於位置的數據查詢

MongoDB支持二維空間索引，所以能夠快速及精確的從指定位置獲取數據。

非結構化數據的爆發增加

給RDBMS增長列在有些狀況下可能鎖定整個數據庫，或者增長負載從而致使性能降低，這個問題一般發生在表格大於1GB（更是下文提到BillRun系統中的痛點——單表格動輒幾GB）的狀況下。鑑於MongoDB的弱數據結構模式，添加1個新字段不會對舊錶格有任何影響，整個過程會很是快速；所以，在應用程序發生改變時，你不須要專門的1個DBA去修改數據庫模式。

缺乏專業的數據庫管理員

若是你沒有專業的DBA，同時你也不須要結構化你的數據及作join查詢，MongoDB將會是你的首選。MongoDB很是適合類的持久化，類能夠被序列化成JSON並儲存在MongoDB。須要注意的是，若是指望得到一個更大的規模，你必需要了解一些最佳實踐來避免走入誤區。

http://www.csdn.net/article/2014-03-06/2818652-when-use-mongodb-rather-mysql

7、論MongoDB和MySQL的區別

1.MySQL來自女兒的名字；MongoDB來自humongous
2.MySQL使用Table/Row/Column；MongoDB使用Collection/Document
3.MySQL須要指定table的schema；MongoDB的collection的每一個document的schema能夠自由修改
4.MySQL支持join；MongoDB沒有join
5.MySQL使用SQL語言；MongoDB使用相似JavaScript的函數

提示：下面的文章連接裏面有相關MongoDB和MySQL的區別的視頻。

http://mp.weixin.qq.com/s?src=3&timestamp=1463216453&ver=1&signature=HodMxNvYoVUMewovM03HuiiSSUTObnyYX0HOfqSE2eT9vczsOBJ*wvSocx0dqLidKMsT9uU7UAclhzUTlyss0-2zyCmKQmsZZgim29PzaLBW2gNDZa4uayYJSAL8xR6CTLRPYIyeJlIr2xvEXUcQyA==

8、mongodb與mysql命令對比
mongodb與mysql命令對比 傳統的關係數據庫通常由數據庫（database）、表（table）、記錄（record）三個層次概念組成，MongoDB是由數據庫（database）、集合（collection）、文檔對象（document）三個層次組成。MongoDB對於關係型數據庫裏的表，可是集合中沒有列、行和關係概念，這體現了模式自由的特色。

http://wenku.baidu.com/view/b7684e650b1c59eef8c7b449.html

9、在PHP項目中使用MySql與MongoDb的一些對比
MongoDb的特色與優點很難用語言描述清楚，如下參考開源中國老大'紅薯'的一篇文章較清晰比較了一下MySql與MongoDB存儲區別
MySQL是關係型數據庫中的明星，MongoDB是文檔型數據庫中的翹楚。下面經過一個設計實例對比一下兩者：假設咱們正在維護一個手機產品庫，裏面除了包含手機的名稱，品牌等基本信息，還包含了待機時間，外觀設計等參數信息，應該如何存取數據呢？

若是使用MySQL的話，應該如何存取數據呢？

若是使用MySQL話，手機的基本信息單獨是一個表，另外因爲不一樣手機的參數信息差別很大，因此還須要一個參數表來單獨保存。

01 CREATE TABLE IF NOT EXISTS `mobiles` (
02 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
03 `name` VARCHAR(100) NOT NULL,
04 `brand` VARCHAR(100) NOT NULL,
05 PRIMARY KEY (`id`)
06 );
07
08 CREATE TABLE IF NOT EXISTS `mobile_params` (
09 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
10 `mobile_id` int(10) unsigned NOT NULL,
11 `name` varchar(100) NOT NULL,
12 `value` varchar(100) NOT NULL,
13 PRIMARY KEY (`id`)
14 );
15
16 INSERT INTO `mobiles` (`id`, `name`, `brand`) VALUES
17 (1, 'ME525', '摩托羅拉'),
18 (2, 'E7' , '諾基亞');
19
20 INSERT INTO `mobile_params` (`id`, `mobile_id`, `name`, `value`) VALUES
21 (1, 1, '待機時間', '200'),
22 (2, 1, '外觀設計', '直板'),
23 (3, 2, '待機時間', '500'),
24 (4, 2, '外觀設計', '滑蓋');
注：爲了演示方便，沒有嚴格遵照關係型數據庫的範式設計。

若是想查詢待機時間大於100小時，而且外觀設計是直板的手機，需按照以下方式查詢：

1 SELECT * FROM `mobile_params` WHERE name = '待機時間' AND value > 100;
2 SELECT * FROM `mobile_params` WHERE name = '外觀設計' AND value = '直板';
注：參數表爲了方便，把數值和字符串統一保存成字符串，實際使用時，MySQL容許在字符串類型的字段上進行數值類型的查詢，只是須要進行類型轉換，多少會影響一點性能。

兩條SQL的結果取交集獲得想要的MOBILE_IDS，再到mobiles表查詢便可：

SELECT * FROM `mobiles` WHERE mobile_id IN (MOBILE_IDS)
若是使用MongoDB的話，應該如何存取數據呢？

若是使用MongoDB的話，雖然理論上能夠採用和MySQL同樣的設計方案，但那樣的話就顯得無趣了，沒有發揮出MongoDB做爲文檔型數據庫的優勢，實際上使用MongoDB的話，和MySQL相比，形象一點來講，能夠合二爲一：

01 db.getCollection("mobiles").ensureIndex({
02 "params.name": 1,
03 "params.value": 1
04 });
05
06 db.getCollection("mobiles").insert({
07 "_id": 1,
08 "name": "ME525",
09 "brand": "摩托羅拉",
10 "params": [
11 {"name": "待機時間", "value": 200},
12 {"name": "外觀設計", "value": "直板"}
13 ]
14 });
15
16 db.getCollection("mobiles").insert({
17 "_id": 2,
18 "name": "E7",
19 "brand": "諾基亞",
20 "params": [
21 {"name": "待機時間", "value": 500},
22 {"name": "外觀設計", "value": "滑蓋"}
23 ]
24 });
若是想查詢待機時間大於100小時，而且外觀設計是直板的手機，需按照以下方式查詢：

view sourceprint?
1 db.getCollection("mobiles").find({
2 "params": {
3 $all: [
4 {$elemMatch: {"name": "待機時間", "value": {$gt: 100}}},
5 {$elemMatch: {"name": "外觀設計", "value": "直板"}}
6 ]
7 }
8 });
注：查詢中用到的$all，$elemMatch等高級用法的詳細介紹請參考官方文檔中相關說明。

MySQL須要多個表，屢次查詢才能搞定的問題，MongoDB只須要一個表，一次查詢就能搞定，對比完成，相對MySQL而言，MongoDB顯得更勝一籌，至少本例如此。

以上爲引文，看完這篇文章大概能夠了解nosql的一下特性，在建立表的時候，能夠先不用想好表的字段是什麼，在一些不是很嚴謹的詳情頁可使用在查詢速度上能夠上一個臺階，在有索引的字段查詢上也與MySql不相上下
http://mp.weixin.qq.com/s?src=3&timestamp=1463216453&ver=1&signature=jp5td-ycKfri2rb1m028aW*6H5KYa*L6KS5hxJAUSVcjuG-2Kei3LDrLixZfJ*FNVonAWMy-EGx1QRkFWU3WWhBrnAmOGEEsq9IZUq3CwJ3JR*fX0dU9OJ-76SFiGct6r-3SYzkehLDtPvXQBesVmQ==

10、28 個 MongoDB NoSQL 數據庫的面試問答

MongoDB是目前最好的面向文檔的免費開源NoSQL數據庫。若是你正準備參加MongoDB NoSQL數據庫的技術面試，你最好看看下面的MongoDB NoSQL面試問答。這些MongoDB NoSQL面試問答涵蓋了NoSQL數據庫基本的概念，複製(Replication)，分片(Sharding)，事務和鎖，跟蹤分析工具(Profiler)，Nuances和日誌等特性。讓咱們看看下面的這些MongoDB NoSQL數據庫的面試問答吧：

1. 你說的NoSQL數據庫是什麼意思？NoSQL與RDBMS直接有什麼區別？爲何要使用和不使用NoSQL數據庫？說一說NoSQL數據庫的幾個優勢？
我寫了一篇完整的博客來回答這些問題，看這裏(http://theprofessionalspoint.blogspot.in/2014/01/nosql-vs-rdbms-why-and-why-not-to-use.html)

2. NoSQL數據庫有哪些類型？
NoSQL數據庫的類型(http://theprofessionalspoint.blogspot.in/2014/01/types-and-examples-of-nosql-databases.html)

例如：MongoDB, Cassandra, CouchDB, Hypertable, Redis, Riak, Neo4j, HBASE, Couchbase, MemcacheDB, RevenDB and Voldemort are the examples of NoSQL databases.

詳細閱讀(http://theprofessionalspoint.blogspot.in/2014/01/12-best-free-and-open-source-nosql.html)。

3. MySQL與MongoDB之間最基本的差異是什麼？
MySQL和MongoDB二者都是免費開源的數據庫。MySQL和MongoDB有許多基本差異包括數據的表示(data representation)，查詢，關係，事務，schema的設計和定義，標準化(normalization)，速度和性能。經過比較MySQL和MongoDB，實際上咱們是在比較關係型和非關係型數據庫。

 

http://www.baidu.com/s?wd=數據庫%20schema
http://www.educity.cn/shujuku/625700.html

 

詳細閱讀(http://theprofessionalspoint.blogspot.in/2013/12/mysql-vs-mongodb-basic-differences.html)

4. 你怎麼比較MongoDB、CouchDB及CouchBase?
MongoDB和CouchDB都是面向文檔的數據庫。MongoDB和CouchDB都是開源NoSQL數據庫的最典型表明。 除了都以文檔形式存儲外它們沒有其餘的共同點。MongoDB和CouchDB在數據模型實現、接口、對象存儲以及複製方法等方面有不少不一樣。

細節能夠參見下面的連接：

MongDB vs CouchDB(http://theprofessionalspoint.blogspot.in/2013/12/mongodb-vs-couchdb-open-source-nosql.html)
CouchDB vs CouchBase(http://theprofessionalspoint.blogspot.in/2014/01/couchdb-vs-couchbase-differences-and.html)

5. MongoDB成爲最好NoSQL數據庫的緣由是什麼?
如下特色使得MongoDB成爲最好的NoSQL數據庫：

面向文件的

高性能

高可用性

易擴展性

豐富的查詢語言

6.32位系統上有什麼細微差異?
journaling會激活額外的內存映射文件。這將進一步抑制32位版本上的數據庫大小。所以，如今journaling在32位系統上默認是禁用的。

7. journal回放在條目(entry)不完整時(好比恰巧有一箇中途故障了)會遇到問題嗎？
每一個journal (group)的寫操做都是一致的，除非它是完整的不然在恢復過程當中它不會回放。

8. 分析器在MongoDB中的做用是什麼?
MongoDB中包括了一個能夠顯示數據庫中每一個操做性能特色的數據庫分析器。經過這個分析器你能夠找到比預期慢的查詢（或寫操做）；利用這一信息，好比，能夠肯定是否須要添加索引。

9. 名字空間（namespace）是什麼？
MongoDB存儲BSON對象在叢集（collection）中。數據庫名字和叢集名字以句點連結起來叫作名字空間（namespace）。

10. 若是用戶移除對象的屬性，該屬性是否從存儲層中刪除？
是的，用戶移除屬性而後對象會從新保存（re-save()）。

11. 可否使用日誌特徵進行安全備份？
是的。

12. 容許空值null嗎？
對於對象成員而言，是的。然而用戶不可以添加空值（null）到數據庫叢集（collection）由於空值不是對象。然而用戶可以添加空對象{}。

13. 更新操做馬上fsync到磁盤？
不會，磁盤寫操做默認是延遲執行的。寫操做可能在兩三秒（默認在60秒內）後到達磁盤。例如，若是一秒內數據庫收到一千個對一個對象遞增的操做，僅刷新磁盤一次。（注意，儘管fsync選項在命令行和通過getLastError_old是有效的）（譯者：也許是坑人的面試題？？）。

14. 如何執行事務/加鎖？
MongoDB沒有使用傳統的鎖或者複雜的帶回滾的事務，由於它設計的宗旨是輕量，快速以及可預計的高性能。能夠把它類比成MySQL MylSAM的自動提交模式。經過精簡對事務的支持，性能獲得了提高，特別是在一個可能會穿過多個服務器的系統裏。

15. 爲何個人數據文件如此龐大？
MongoDB會積極的預分配預留空間來防止文件系統碎片。

16. 啓用備份故障恢復須要多久？
從備份數據庫聲明主數據庫宕機到選出一個備份數據庫做爲新的主數據庫將花費10到30秒時間。這期間在主數據庫上的操做將會失敗--包括寫入和強一致性讀取(strong consistent read)操做。然而，你還能在第二數據庫上執行最終一致性查詢(eventually consistent query)(在slaveOk模式下)，即便在這段時間裏。

17. 什麼是master或primary？
它是當前備份集羣(replica set)中負責處理全部寫入操做的主要節點/成員。在一個備份集羣中，當失效備援(failover)事件發生時，一個另外的成員會變成primary。

18. 什麼是secondary或slave？
Seconday從當前的primary上覆制相應的操做。它是經過跟蹤複製oplog(local.oplog.rs)作到的。

19. 我必須調用getLastError來確保寫操做生效了麼？
不用。無論你有沒有調用getLastError(又叫"Safe Mode")服務器作的操做都同樣。調用getLastError只是爲了確認寫操做成功提交了。固然，你常常想獲得確認，可是寫操做的安全性和是否生效不是由這個決定的。

20. Should I start out with sharded or with a non-sharded MongoDB environment? 我應該啓動一個集羣分片（sharded）仍是一個非集羣分片的 MongoDB 環境？
爲開發便捷起見，咱們建議以非集羣分片（unsharded）方式開始一個 MongoDB 環境，除非一臺服務器不足以存放你的初始數據集。從非集羣分片升級到集羣分片（sharding）是無縫的，因此在你的數據集還不是很大的時候不必考慮集羣分片（sharding）。

21. 分片（sharding）和複製（replication）是怎樣工做的？
每個分片（shard）是一個分區數據的邏輯集合。分片可能由單一服務器或者集羣組成，咱們推薦爲每個分片（shard）使用集羣。

22. 數據在何時纔會擴展到多個分片（shard）裏？
MongoDB 分片是基於區域（range）的。因此一個集合（collection）中的全部的對象都被存放到一個塊（chunk）中。只有當存在多餘一個塊的時候，纔會有多個分片獲取數據的選項（Only when there is more than 1 chunk is there an option for multiple shards to get data.）。如今，每一個默認塊的大小是 64Mb，因此你須要至少 64 Mb 空間才能夠實施一個遷移。

23. 當我試圖更新一個正在被遷移的塊（chunk）上的文檔時會發生什麼？
更新操做會當即發生在舊的分片（shard）上，而後更改纔會在全部權轉移（ownership transfers）前複製到新的分片上。

24. 若是在一個分片（shard）中止或者很慢的時候，我發起一個查詢會怎樣？
若是一個分片（shard）中止了，除非查詢設置了「Partial」選項，不然查詢會返回一個錯誤。若是一個分片（shard）響應很慢，MongoDB則會等待它的響應。

25. 我能夠把moveChunk目錄裏的舊文件刪除嗎？
沒問題，這些文件是在分片（shard）進行均衡操做（balancing）的時候產生的臨時文件。一旦這些操做已經完成，相關的臨時文件也應該被刪除掉。但目前清理工做是須要手動的，因此請當心地考慮再釋放這些文件的空間。

26. 我怎麼查看 Mongo 正在使用的連接？
db._adminCommand("connPoolStats");

27. 若是塊移動操做（moveChunk）失敗了，我須要手動清除部分轉移的文檔嗎？
不須要，移動操做是一致（consistent）而且是肯定性的（deterministic）；一次失敗後，移動操做會不斷重試；當完成後，數據只會出如今新的分片裏（shard）。

28. 若是我在使用複製技術（replication），能夠一部分使用日誌（journaling）而其餘部分則不使用嗎？
能夠。

http://mp.weixin.qq.com/s?src=3&timestamp=1463219022&ver=1&signature=xlZQWoYDkMnaWMwK-u92oYO1d87hs6ireNQL7rWXHyb2PUiHnjixqnpK064hGZq*lwghynd-SlkSZAYgevYtJ0IgYjm0SGcueRsZXyxwjQPYhxu0*egLKaSr7aJMa9dytn-53PXXuko8sy5GCzJyiw==

延伸閱讀：
http://www.baidu.com/s?wd=MySQL%20MongoDB%20區別
http://www.sogou.com/web?query=MySQL%20MongoDB%20區別
http://www.so.com/s?q=MySQL%20MongoDB%20區別

http://weixin.sogou.com/weixin?query=mysql%20mongodb%20區別&ie=utf8&type=2&sourceid=weixinvr
http://www.csdn.net/article/2012-09-06/2809618-mysql-vs-mongodb-complete