28個MongoDB NoSQL資料庫的面試問答

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

　　1. 你說的NoSQL資料庫是什麼意思？ NoSQL與RDBMS直接有什麼區別？ 為什麼要使用和不使用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. 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）而其他部分則不使用嗎？


　　可以。