安全

2.0版本程式將會支援sharding狀態下面的認證模式。

與沒有分片配置的區別

• 2.0版本以前，分片必須執行在可信任的安全模式，沒有明確的安全策略。
• 在當前版本中，shard key一旦選定後就不能再更改了。
• 所有的（不是操作多個）更新、更新插入和插入操作必須包含完整的shard key。這會對使用對映庫有些影響，因為此時你無法控制更新操作。

$where

$where在sharding下面可以使用。但是不要在$where函式中引用資料庫物件(db object)。

db.eval

db.eval()不能在分片的集合上面使用。當然，你可以在未分片的集合上面使用db.eval().在分片環境可以使用map/reduce.

getPrevError

getPrevError在分片的資料庫上面是不支援的，而且在將來的發行版本可能也不支援。如果這會給你帶來麻煩，請告訴我們。

Unique Indexes

對於一個分片的集合，你可以為shard key指定唯一的條件約束。你也可以擁有其他的唯一索引當且僅當shard key是他們的屬性的字首。換句話說，mongodb不保證在多shard環境下的唯一性。只要沒有唯一性的限制，你可以建立其他的非唯一性的索引。

規模限制

目標是支援最多1000個shards。到目前為止的對叢集測試限制在一定數目的shards（比如100）。如果以後遇到規模上的限制，更多的資訊將來會更新到這裡。

對集合的大小沒有硬編碼的限制，但是請記住前面章節的描述。你可以建立一個分片的集合，然後向裡面新增資料，相應的資料會新增到相應數量的shard中。當然，只要你的查詢可以很快的查詢到。

查詢速度

包含了shard key的查詢可以很快返回，查詢速度和以前在未分片的環境做查詢相當。

沒有包含shard key的查詢使用了分散/收斂的方法，它會將查詢發給所有的shards。當你有10個shard時效能表現還不錯，但當你有1000個shards，效能可能會很差勁（如果查詢很少的話，效能也會表現的不錯）。

對一個已經存在的集合分片

你可以對一個已經存在的集合進行分片，但是這裡有一些限制。換一種說法，如果你有一個單節點（或者單一複製組），你想把它升級到分片配置，這是可能的。

目前的限制有大小和時間。

1. 大小：在1.6版本我們設定原始集合最大大小固定在25GB（在1.8版本增大到256GB）。這個限制將來會增大也可能會取消。如果你的應用超過了這個限制，並且你也對集合做了分片，那麼它可以工作。但是所有你的資料都會從一個數據塊開始，導致初始的分發非常慢。在實際應用中，如果你的集合中包含了很多大的文件，這個限制可能會更大一些（由於統計分裂計算點的方法）。一個變通的方案，是可以在db.config.settings中增大預設資料塊大小（比如512M或者1GB），這樣就使能了初始的分裂和遷移。這樣當資料插入時，大的資料塊就自然的分裂了。
2. 時間：當對一個已經存在的集合做分片時，請知曉這個過程會花費一些時間。分片是在後臺進行的，所以其他操作不會被明顯的受到影響。無論如何，將一個大的集合中的資料進行遷移/平衡會佔用很多時間。例如一個擁有10個shard的系統中，集合中90%的資料需要遷移到其他地方以達到平衡（提醒只對大的集合做資料均衡，如果集合比較小（比如少於400MB）我們建議就不要對它分片了）。