我目前正在制作mongo，到目前为止一直很满意。我只是想更好地了解如何提高吞吐量。我的理解可能存在核心差距，我正试图填补这一点。
我目前有一个相对较小的数据集（少于5M的文档）。作为我的应用程序的一部分，我必须每天轮换数据，这意味着我将在1M和5M之间插入集合并滚动旧数据。我能够很容易地使用两个集合来实现这一点，其中一个是沙盒集合，其中新数据被抽入，完成后，我将其重命名为“直播”。集合使它非常快，我不必等待remove（）完成。
我目前的问题是，在我的服务器上，这是一个带有16GB内存的四核Linux机箱，我的数据每秒无法超过~2k更新。插入所有数据（1M +）后，我有各种后期处理，读取然后更新记录。这个过程在功能上运行良好，但无论我尝试什么，我都不能高于4K（读取+写入）一秒钟。
我已经将集合上的索引修剪为我需要的几个单字段索引，并且我尝试了各种各样的事情，例如使用单个esb ssd假脱机ec2 mediumxlarge实例，我得到相同的结果。我也尝试过分支读取/更新数据的工作进程，无论我放了多少工人，操作的最大数量都没有真正移动。
此外，我的帖子进程与mongo服务器在同一个盒子上运行，因此这里没有网络延迟等。当后期进程运行时，cpu相对安静，偶尔可能会飙升50％左右。我也注意到在这个过程中我有一个很高的锁定％，但我猜这只是因为我发布了这么多的集合更新。在我的发布过程中，锁定％statys为80 +％。
我的平均文件大小约为1.4k。集合中有6个字段级索引。典型的后期处理（使用节点）将使用字段x = y流式传输所有文档，更新该记录上的不同字段，然后保存它。在这个过程中会发生一些计算。起初我认为我的计算是瓶颈，所以我要求多个（4）节点子进程并且每个子进程不超过40％cpu。我非常有信心我的申请很好。如果我使用1或4个节点进程，则需要大约20分钟来处理1M文档。
答案 0 :(得分：2)
你可以做的不多，当你更新整个集合时，mongodb会锁定整个集合。因此在更新期间会阻止读取。
Version 3.0应该通过在WiredTiger存储引擎中引入文档级锁定来改善这一点。