MongoDB在600k对象上执行错误,替代数据库? 优化?

我使用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-8secs的运行时间。 顺便说一句:在PHP执行相同的查询与内存不足的消息(256MB RAM)的死亡。

该机器是Intel(R)Core(TM)i7 CPU 920 @ 2.67GHz,带有8GB RAM,不是机架中尘土最多的机器;)

我真的没有什么想法了,而且在接下来的几个星期里我会看到成千上万的行。 正如你可能注意到的行相对较小。 MySQL的分区会更好吗? 任何其他的NoSQL数据库?

请大家关注一下“2-8秒不慢” – 这已经成为一个问题。 当两个未caching的请求同时触及机器时,负载将上升至4,并且访问该用户的用户不足10个。

感谢大家花时间思考我的问题。 使用地理空间索引的build议似乎是我正在寻找的答案。 除了这个指标对于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'} 

我比较了两个脚本。 首先从旧集合中查询一个400×400像素的框,然后花费:



实际0m0.375s
用户0m0.348s
 sys 0m0.021s


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

实际0m0.107s
用户0m0.096s
 sys 0m0.012s

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

谢谢大家,Stackoverflow的岩石! )

一个快速和肮脏的方式来提高性能(在内存/空间牺牲)将索引 “x1”,“x2”,“y1”和“y2”,但也许你应该使用地理空间索引 。