MongoDB面試題__增強

MongoDB是目前最好的面向文檔的免費開源NoSQL數據庫。若是你正準備參加MongoDB NoSQL數據庫的技術面試，你最好看看下面的MongoDB NoSQL面試問答。這些MongoDB NoSQL面試問答涵蓋了NoSQL數據庫基本的概念，複製(Replication)，分片(Sharding)，事務和鎖，跟蹤分析工具(Profiler)，Nuances和日誌等特性。讓咱們看看下面的這些MongoDB NoSQL數據庫的面試問答吧：
1. 你說的NoSQL數據庫是什麼意思？NoSQL與RDBMS直接有什麼區別？爲何要使用和不使用NoSQL數據庫？說一說NoSQL數據庫的幾個優勢？
我寫了一篇完整的博客來回答這些問題，看這裏
 A)  NoSQL:  Not Only SQL 的縮寫,它的意思是:使用關係型數據庫的時候就用關係型數據庫,不適用的時候也沒有必要使用關係型數據庫不能夠,能夠考慮使用更加適合的數據存儲.
B)  RDBMS:關係型數據庫管理系統,它的特色是:
　　數據以表格的形式出現
　　每行爲各類記錄名稱
　　每列爲各類記錄名稱所對應的數據項
　　許多行和列組成一張表單
　　若個表組成一個database
   NoSQL:非關係型數據庫,它發展的緣由是互聯網web2.0網站的興起,特別是超大規模和高併發的SNS類型的純動態網站已經顯得力不從心,暴露出不少難以克服的問題才發展出來的,例如
　　對數據庫高併發讀寫的需求
　　對數據庫的高可擴展性和高可用性的需求
　　對海量數據的高校存儲和訪問的需求
NoSQL的特性:
　　能夠處理超大量的數據
　　運行在便宜的PC服務器集羣上
　　擊碎了性能瓶頸------經過NoSQL架構能夠省去將Web或Java應用和數據轉換成SQL友好格式的時間,執行速度更快.
　　沒有過多的操做
NoSQL的優勢:
　　易擴展性---去掉了關係數據庫的關係特性,數據之間無關係,很是容易擴展
　　大數據量,高性能-----NoSQL數據庫都有很是高的讀寫能力,尤爲在大數據量下,,一樣表現優秀,這得益於他的無關係性,數據庫的結構簡單,通常MySQL使用Query Cache,每次表的跟新Cache就失效,是一種大粒度的Cache,在針對Web2.0的交互頻繁的應用,Cache性能不高,而NoSQL的Cache是記錄級的,是一種細粒度的Cache,因此NoSQL在這個層面上來講急劇要性能高多了.
　　靈活的數據模型---NoSQL無需事先爲要存儲的數據創建字段,隨時能夠存儲自定義的數據格式.
　　高可用性------NoSQL在不太影響性能的狀況,就能夠方便的實現高可用的架構,好比Cassandra,HBase模型,經過複製模型也能實現高可用性.
C) 關係行數據庫的優點
　　保持數據的一致性(事務處理)
　　因爲以標準做爲前提,數據更新的開銷很小(相同的字段基本都只有一處)
　　能夠進行JOIN等複雜查詢
　　存在不少實際成果和專業技術信息
D)  NoSQL的應用場景:
　　但願順暢地對數據進行緩存(Cache)處理
　　但願對數組類型的數據進行高速處理
　　但願進行全保存

　　

NoSQL數據庫有哪些類型？
NoSQL數據庫有三種類型
　　鍵值存儲
它的數據以鍵值的形式存儲,雖然它的處理速度很是快,可是基本上只能經過鍵的徹底一致查詢獲取數據,根據數據的保存方式能夠分爲臨時性,永久性和二者兼具三種.
臨時性
Memcached
在內存中保存數據
能夠進行很是快速的保存和讀取處理
數據可能丟失
　　c)  永久性
　　在硬盤上保存數據
　　能夠進行很是快的保存和讀取處理(但沒法和memcached相比)
　　數據不會丟失
　　d)  二者兼具
　　Redis
　　Redis首先把數據保存到內存中,在知足特定的條件的時候將數據寫入到硬盤上,這樣既確保了內存中數據的處理速度,又能夠經過寫入硬盤來保證數據的永久性,這種類型的數據庫特別適合處理數組類型的數據.

　　面向文檔的數據庫
MongoDB,  CouchDB
不定義表結構
可使用複雜的查詢條件----面向文檔的數據庫能夠經過複雜的查詢條件來獲取數據,雖然不具有事務處理和JOIN這些關係型數據庫所具備的處理能力,但除此以外的其餘處理基本上都能實現.
　　面向列的數據庫
Cassandra, HBase
以列爲單位來存儲數據
對大量行少數列進行讀取,對全部行的特定列進行同時更新
高擴展性(特別是寫入速度)
應用十分困難
3. MySQL與MongoDB之間最基本的差異是什麼？
MySQL和MongoDB二者都是免費開源的數據庫。MySQL和MongoDB有許多基本差異包括數據的表示(data representation)，查詢，關係，事務，schema的設計和定義，標準化(normalization)，速度和性能。經過比較MySQL和MongoDB，實際上咱們是在比較關係型和非關係型數據庫。
NoSQL與關係型數據庫設計理念比較
　　關係型數據庫中的表都是存儲一些格式化的數據結構,每一個元祖字段的組成都同樣,即便不是每一個元祖都須要全部的字段,可是數據庫會爲每一個元祖分配全部的字段,這樣的結構能夠便於表與表之間進行鏈接等操做,但從另外一個角度來講它也是關係型數據庫性能瓶頸的一個因素,而非關係型數據庫以鍵值對存儲,它的結構不固定,每一個元祖能夠有不同的字段,每個元祖能夠根據須要增長一些本身的鍵值對,這樣就不會侷限於固定的結構,能夠減小一些時間和空間的開銷.

4. 你怎麼比較MongoDB、CouchDB及CouchBase?
MongoDB和CouchDB都是面向文檔的數據庫。MongoDB和CouchDB都是開源NoSQL數據庫的最典型表明。 除了都以文檔形式存儲外它們沒有其餘的共同點。MongoDB和CouchDB在數據模型實現、接口、對象存儲以及複製方法等方面有不少不一樣。
細節能夠參見下面的連接：
MongDB vs CouchDBCouchDB vs CouchBase
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）而其餘部分則不使用嗎？
能夠。