在我们的设置中，我们目前有3个shard集合sharded cluster，每个shard集合都是3的副本集合。我们的写入将大幅增加以实现一个新特性，并且我们知道额外的数据是必要的。 我们的写作本质基本上都是upserts（这可能是更新），并更新我们增加一个特定的字段1。
我们的更新总是增加1，我们的数据分布的方式，并不是所有的文件都被平等对待，有些让他们的领域递增了很多。 我认为可能有效的另一种解决scheme是拥有某种types的中间人，比如一些Redis数据库（或者一些较小的mongods），我们首先对它们进行更新，大约5分钟后（或者使用一些排队系统），我们有一堆工作人员使用这些数据，并用文档更新实际的活动群集。 这将节省我们的主要群集吨写，因为它会允许某些更新繁重的文件积累他们的更新，并可以为我们节省大量的写（准确的数字，我将在不久后发布）。
那么底线是什么时候添加另一个碎片不是正确的解决scheme？
Redis当然可以用作MongoDB的caching/回写方法。
然而，添加碎片是增加应用程序写入容量的主要方式，如果您已经用尽了添加内存的选项，使用更快的磁盘等。
另外，要注意MongoDB的写locking趋势。 Mongo允许内核pipe理存储在RAM中的内容，因此执行upsert时的最佳做法是首先读取对象（以便将其存储在RAM中），然后写入对象。 如果不这样做，则会导致写锁在对象不在工作集中的情况下持续很长时间，因为它放置了写locking，然后从磁盘读取文档，写入文档（现在以ram写入），然后释放锁。 如果在写入锁之前进行读取（将对象带入RAM），所有这些都不那么干扰。