MongoDB在60万个对象上表现不佳，替代DB？优化？

我使用node.js和mongodb启动了一个新项目，近两天后，我在MongoDB中收集了约60万个对象。我已经注意到对性能的巨大(负面)影响，并且我开始担心是否应该尽可能长时间地迁移到另一个数据库，或者是否应该坚持使用Mongo并进行一些(更多)优化。

基本上我是这样存储坐标的:

[x1] => 687
[y1] => 167
[x2] => 686
[y2] => 167
[c] => 0
[s] => 0
[m] => 1299430700312
[_id] => MongoId Object (
    [$id] => 4d73bd2c82bb5926780001ec
)

没有更多...而我的查询如下所示:

{'$or': [ { x1: {'$gte' : 0, '$lt' : 1000 }, y1: {'$gte' : 0, '$lt' : 1000 } , { x2: {'$gte' : 0, '$lt' : 1000 }, y2: {'$gte' : 0, '$lt' : 1000 } } ] }

我试过为每个字段设置索引:x1，y1，y1，y1以及{x1:1,y1:1},{x2:1,y2:1}。
此外，我也只提取了我需要的必填字段...但是，仍然执行约40k行结果集的查询最终需要2-8秒的运行时间。
顺便说一句:在PHP中执行相同的查询时，由于内存不足消息(256MB RAM)而终止。

该机器是Intel®Core™i7 CPU 920 @ 2.67GHz，具有8GB RAM，它不是机架中最脏的一个；)

我的想法真的用光了，接下来的几周我将看到数百万行。您可能已经注意到，行相对较小。
带分区的MySQL会更好地执行吗？还有其他NoSQL DB吗？

并且请大声疾呼“2-8秒并不慢”-这已经成为一个问题。当几个未缓存的请求同时命中计算机时，负载最多增加4个，而访问它的用户不到10个。

最佳答案

感谢所有花时间思考我的问题的人。使用地理空间索引的建议似乎是我一直在寻找的答案。
除了索引对于mongodb更有效的事实之外，查询整个盒子的方式简直是摇摇欲坠!

给出一些事实:
我刚刚开始重写代码和收集数据，并从简单的比较开始。我的数据之前看起来像这样:

[x1] => 190
[y1] => 18
[x2] => 192
[y2] => 18
[c] => 0
[s] => 0
[b] => Array (
    [0] => 0
    [1] => 0
)
[m] => 1299365242802
[r] => 32596
[_id] => MongoId Object (
    [$id] => 4d72bd7af0528ea82f000003
)

索引是:

{x1:1,y1:1}, {x2:1,y2:1}

现在我的数据如下所示:

[_id] => MongoId Object (
    [$id] => 4d825799b15953b90d000000
)
[coords] => Array (
    [x] => 190
    [y] => 18
)
[x2] => 192
[y2] => 18
[s] => 0
[c] => 0
[m] => 1299365242802
[r] => 32596

指数:

{coords:'2D'}

我比较了两个脚本。
第一个查询来自旧集合的一盒400x400像素，结果是:

真正的0m0.375s
用户0m0.348s
sys 0m0.021s


第二个脚本使用索引并查询同一框，但使用地理空间索引:

真正的0m0.107s
用户0m0.096s
SYS 0分0.012秒

那是一个巨大的差异，我的集合(每个)中只有大约3200个对象。我的实时数据库/集合现在已经包含了将近200万个对象(在线12天后)。我迫不及待要使用这些脚本对实时数据进行基准测试。对我来说看起来很有前途! :)

谢谢大家，Stackoverflow摇摇欲坠! )