28個MongoDB經典面試題詳解

MongoDB是目前最好的面向文檔的免費開源NoSQL數據庫。

如果你正準備參加MongoDB NoSQL數據庫的技術面試，你最好看看下面的MongoDB NoSQL面試問答。

這些MongoDB NoSQL面試問答涵蓋了NoSQL數據庫基本的概念，復制(Replication)，分片(Sharding)，事務和鎖，跟蹤分析工具(Profiler)，Nuances和日志等特性。

讓我們看看下面的這些MongoDB NoSQL數據庫的面試問答吧：

1. 你說的NoSQL數據庫是什么意思?NoSQL與RDBMS直接有什么區別?為什么要使用和不使用NoSQL數據庫?說一說NoSQL數據庫的幾個優點?

NoSQL是非關系型數據庫，NoSQL = Not Only SQL。

關系型數據庫采用的結構化的數據，NoSQL采用的是鍵值對的方式存儲數據。

在處理非結構化/半結構化的大數據時；在水平方向上進行擴展時；隨時應對動態增加的數據項時可以優先考慮使用NoSQL數據庫。

在考慮數據庫的成熟度；支持；分析和商業智能；管理及專業性等問題時，應優先考慮關系型數據庫。

2. NoSQL數據庫有哪些類型?

NoSQL數據庫的類型

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

3. MySQL與MongoDB之間最基本的差別是什么?

MySQL和MongoDB兩者都是免費開源的數據庫。MySQL和MongoDB有許多基本差別包括數據的表示(data representation)，查詢，關系，事務，schema的設計和定義，標準化(normalization)，速度和性能。

通過比較MySQL和MongoDB，實際上我們是在比較關系型和非關系型數據庫，即數據存儲結構不同。詳細閱讀

4. 你怎么比較MongoDB、CouchDB及CouchBase?

MongoDB和CouchDB都是面向文檔的數據庫。MongoDB和CouchDB都是開源NoSQL數據庫的最典型代表。 除了都以文檔形式存儲外它們沒有其他的共同點。MongoDB和CouchDB在數據模型實現、接口、對象存儲以及復制方法等方面有很多不同。

細節可以參見下面的鏈接：

MongDB vs CouchDB

CouchDB 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. 我應該啟動一個集群分片(sharded)還是一個非集群分片的 MongoDB 環境?

為開發便捷起見，我們建議以非集群分片(unsharded)方式開始一個 MongoDB 環境，除非一臺服務器不足以存放你的初始數據集。從非集群分片升級到集群分片(sharding)是無縫的，所以在你的數據集還不是很大的時候沒必要考慮集群分片(sharding)。

21. 分片(sharding)和復制(replication)是怎樣工作的?

每一個分片(shard)是一個分區數據的邏輯集合。分片可能由單一服務器或者集群組成，我們推薦為每一個分片(shard)使用集群。

22. 數據在什么時候才會擴展到多個分片(shard)里?

MongoDB 分片是基于區域(range)的。所以一個集合(collection)中的所有的對象都被存放到一個塊(chunk)中。只有當存在多余一個塊的時候，才會有多個分片獲取數據的選項。現在，每個默認塊的大小是 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)而其他部分則不使用嗎?

可以。

29.當更新一個正在被遷移的塊（Chunk）上的文檔時會發生什么？

更新操作會立即發生在舊的塊（Chunk）上，然后更改才會在所有權轉移前復制到新的分片上。

30.MongoDB在A:{B,C}上建立索引，查詢A:{B,C}和A:{C,B}都會使用索引嗎？

不會，只會在A:{B,C}上使用索引。

31.如果一個分片（Shard）停止或很慢的時候，發起一個查詢會怎樣？

如果一個分片停止了，除非查詢設置了“Partial”選項，否則查詢會返回一個錯誤。如果一個分片響應很慢，MongoDB會等待它的響應。

32. MongoDB支持存儲過程嗎？如果支持的話，怎么用？

MongoDB支持存儲過程，它是javascript寫的，保存在db.system.js表中。

33.如何理解MongoDB中的GridFS機制，MongoDB為何使用GridFS來存儲文件？

GridFS是一種將大型文件存儲在MongoDB中的文件規范。使用GridFS可以將大文件分隔成多個小文檔存放，這樣我們能夠有效的保存大文檔，而且解決了BSON對象有限制的問題。

更多關于MongoDB經典面試題請查看下面的相關鏈接