我的MongoDB中有一系列索引,而我认为我在这么高的CPU上运行系统的原因之一是更新索引是阻塞的。 (AWS微实例在正常操作期间以50%+ CPU运行,在重写操作期间以99.9%运行)。
我已经为快速查询准备了一些索引,现在我认为通过将索引构建转换为后台操作,我可以展示一些进一步的改进。
我不想要完全删除索引(至少我不认为我这样做)而是如果只是“未来的操作”在后台运行我会很高兴。
我查看了mongo索引构建文档http://www.mongodb.org/display/DOCS/Indexes并查看了打开后台操作的标志(见下文),但我没有看到有关如何修改现有索引的内容。
db.things.ensureIndex({x:1}, {background:true});
> db.things.ensureIndex({name:1}, {background:true, unique:true,
... dropDups:true});
我尝试使用更新的参数第二次运行原始索引命令,但是当我重新执行db.colection.getIndexes();
comant时,它不会在输出中显示'background'参数。
{
"_id" : ObjectId("4de2c1a5c9907a4e77467826"),
"ns" : "mydb.items",
"key" : {
"itemA" : 1,
"itemB" : -1,
"itemC" : -1
},
"name" : "itemA_1_itemB_-1_itemC_-1",
"v" : 0
}
我是否必须删除索引并重新开始?或者只是没有显示背景索引的参数?
来自评论的@TTT: 您希望在插入,更新或删除文档后对索引进行异步更新吗?
我想这样。我希望系统的查询速度始终最大化,所以我肯定需要索引,但也有时候我运行了数万个插入。这对整个系统来说都是一个问题,因为在更新期间Mongo的CPU使用率高达99.9%。
我认为在后台更新索引是答案,但我在MONGO文档中读到,如果重新计算索引,则在重新计算完成之前不会用于查询。
我理想的“梦境”是系统将使用“最后一个最佳索引”,直到后台更新过程完成(或者甚至只是总是使用当前最知名的索引)。
答案 0 :(得分:3)
你的索引系统听起来很理智。您看到的问题似乎是您正在使用的服务器设置的症状。
EC2 Micro实例在任何类型的持续操作方面表现都很差。提供网页很好,但任何长时间的CPU使用都会随着时间的推移而出现恶化的输出。这是因为可用的持续CPU比可用于较短操作的突发CPU小得多。
来自亚马逊的EC2页面:
该系列的实例提供少量一致的CPU资源,并允许您在有额外周期时突发CPU容量。它们非常适合于吞吐量较低的应用程序和定期消耗大量计算周期的网站。
和
最多2个EC2计算单元(用于短周期突发)
我建议您转到具有更多可用CPU的设置,例如小型实例,或者如果费用是您主要关心的问题之一,那就是Linode VPS。