先建索引, 再restore資料到新DB, 發現速度非常非常慢 

這是collection個數太多導致，在實踐中以每個collection 8KB計算（跟官方文檔裡說的不同，可能跟index有關係），256MB可以支持36000個collection。db.system.namespaces.count() 命令可以統計當前DB內的collection數目，DB可支援collection數量是由於nssize參數指定的，它指定了dbname.ns磁片檔的大小，也就指定了DB可支援的最大collection數目，ns為namespace縮寫。默認nssize為16MB。 如果重啟MongoD並修改了nssize參數，這新nssize只會對新加入的DB生效，對以前已經存在的DB不生效，如果你想對已經存在的DB採用新的nssize，必須在加大nssize重啟之後新建DB，然後把舊DB的collection 複製到新DB中。 namespace限制相關文檔：

有時候分布式集群正在遷移數據，它導致count統計結果錯誤, 請問如何解決?

第一級:默認安全寫入，確認數據寫入到內存中就返回(w=N屬於這一級)
第二級:Journal save，數據在寫入到DB磁碟文件之前，MongoDB會先把操作寫入到Journal文件，這一級指的是確認寫入了Journal文件就返回
第三級:fysnc，所有數據寫到到DB磁碟文件才返回。

一般第一級就足夠了，第二級是為了保證在機器異常斷電的情況下也不會丟失數據。安全寫入要付出性能的代碼：不安全寫入的性能大概是默認安全寫入的3倍。
使用fync參數則性能更差，一般不使用。

如果是副本集（replica set），其w=N參數，N表示安全寫入到多少個副本集才返回。

參考：

驅動程序自動修改為往mongos的多次提交。

意思是說，當前正要去接受新chunk 的shard正在刪除上一次數據遷移出的數據，不能接受新Chunk，於是本次遷移失敗。這種log里顯示的是warning，但有時候會發現shard的刪除持續了十幾天都沒完成，查看日誌，可以發現同一個chunk的刪除在不斷重複執行，重啟所有無法接受新chunk的shard可以解決這個問題。

如果採用了balancer自動均衡，那麼可以加上_waitForDelete參數，如：

{ "_id" : "balancer", "activeWindow" : { "start" : "12:00", "stop" : "19:30" }, "stopped" : false, "_waitForDelete" : true }

，這樣就不會因delete堆積而導致後續migrate失敗，當然，需要考慮到這裡的阻塞是否會影響到程序正常運轉，在實踐中慎重採用使用waitForDelete，因為發現加上它之後遷移性能非常差，可能出現卡住十幾個小時的情況，外界拿住了被遷移chunk的游標句柄，這時候刪除不能執行，阻塞了後續其它遷移操作。

游標被打開而導致被遷移數據無法及時刪除時的日誌：

2015-03-07T10:21:20.118+0800 [RangeDeleter] rangeDeleter waiting for open cursors in: cswuyg_test.cswuyg_test, min: { _id: -6665031702664277348 }, max: { _id: -6651575076051867067 }, elapsedSecs: 6131244, cursors:

這可能會卡住幾十小時，甚至一直卡住，影響後續的moveChunk操作，導致數據不均衡。

解決方法：重啟

From MongoDB 

Paging Costs

Unfortunately skip can be (very) costly and requires the server to walk from the beginning of the collection, or index, 

to get to the offset/skip position before it can start returning the page of data (limit). As the page number increases skip will 

become slower and more cpu intensive, and possibly IO bound, with larger collections.

Range based paging provides better use of indexes but does not allow you to easily jump to a specific page.

答案為:D

以上所有的命令枯萎導致讀鎖或寫鎖或兩者兼而有之。

什麼是索引鍵限制每個集合索引的最大規模和數量？

MongoDB的文檔的最大尺寸是多少?