MongoDB 在 600k 个对象上表现不佳，替代数据库？优化？

Question

我使用 node.js 和 mongodb 开始了一个新项目，将近 2 天后，我在 MongoDB 中收集了大约 600k 个对象。我已经注意到对性能的巨大(负面)影响，我开始担心是否应该尽可能转移到另一个数据库，或者是否应该坚持使用 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(R) Core(TM) i7 CPU 920 @ 2.67GHz 和 8GB RAM，它不是机架中灰尘最多的机器；)

我的想法真的快用完了，我预计接下来几周会有数百万行出现。正如您可能注意到的那样，这些行相对较小。 带分区的 MySQL 性能会更好吗？任何其他 NoSQL 数据库？

请大家说“2-8 秒并不慢”——这已经成为一个问题。当几个未缓存的请求同时到达机器时，负载会增加到 4 并且少于 10 个用户访问它。

Answer 1

感谢所有花时间思考我的问题的人。使用地理空间索引的建议似乎是我正在寻找的答案。 除了索引对 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 像素的框，它需要:

real    0m0.375s
user    0m0.348s
sys     0m0.021s

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

real    0m0.107s
user    0m0.096s
sys     0m0.012s

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

谢谢大家，Stackoverflow 太棒了! )