易栈网-膘叔

 本来是想用mongo的geo功能来做查询，想着这个功能是它自带的，性能一定很牛叉吧？结果事实让我们非常失望。

我们做了一个简单的测试，插了1000万条数据，y=x的方式插入，即[0.00001,0.00001]~[99.99999,99.99999]，在坐标上其实就是显示成一条实现。如果我们随便指定一个坐标值，求near。你会发现其实很卡。。。20多秒才能出数据，而且还不准。

要知道我的机器可是：i7 4核，16G内存，SSD的硬盘，都这么卡，而且出来的都这么慢。

当然，其实更重要的是不准。。。我坐标[20,90],查出来的点，居然是[55,55]，这太让人伤心了。随便算了算，怎么着都应该是77左右啊。。。

估计，只能用mysql了。。。伤心。

很乱。我自己明白即可，三种查询条件。

{loc:{"$near":[121.417397,31.204075]} }
{loc : {"$within" : {"$center" : [ [121.417397,31.204075], 5]}} }
db.places.find({loc:{ $near:[ 30.28009,120.12857],$maxDistance:5}}).limit(20)

上述的内容参考与某个网站，它的基本内容如下：

最近一直在做基于LBS的项目，地标的坐标索引和基于坐标查询，一直没找到一种简单方便的方法，在做mongo索引优化的时发现竟然有Geo的索引
创建字段
建议使用方式：{ loc : [ longitude , latitude] }
也可以：{ loc : { lon :longitude, lat:latitude } }
Loc自己决定，我用poi的
建立索引
注意：每个Collection只能建立一个geospatial索引
db.places.ensureIndex( { loc : “2d” } , { min : -500 , max : 500 } )
如果db.places.ensureIndex( { loc : “2d” })，
默认值的范围是：-180到180，也就是经纬度的范围
查询
注：1.默认会按距离排序；
    2.转换 111.12 距离（一度是大约 111.12 公里）使用公里，或由 69 （对于英里）
默认取100条距离最近的点，注：默认是limit(100)
db.collection.find({loc:{$near :[ 30.28009,120.12857]}})
取正方形范围的坐标点，注意：5是坐标系的5，也就是经纬度的5，按111.12换算成公里
db.places.find({loc:{ $near:[ 30.28009,120.12857],$maxDistance:5}}).limit(20)
取指定半径的点，注意：半径5是坐标系的5，也就是经纬度的5，按111.12换算成公里
以5为半径的圆：{“Coordinate” : {“$within” : {“$center” : [ [30.28009,120.12857], 5]}} }
---------

纯笔记，别多想，测试了一下。比现在使用的好多了，我现在是：
        $criteria->order = new \CDbExpression("ACOS(SIN(({$lat} * 3.1415) / 180 ) *SIN((lat * 3.1415) / 180 ) +COS(({$lat} * 3.1415) / 180 ) * COS((lat * 3.1415) / 180 ) *COS(({$lng} * 3.1415) / 180 - (lng * 3.1415) / 180 ) ) * 6380  asc,last_activity_time DESC");

不要多想，我是用的Yii的玩意，也是一个笔记。

在mysql里面，我们偶尔会有这样的sql出现：
select userid,count(userid) as cnt from xxxxxtable group by userid;

这样的sql在mongo里怎么实现呢？其实也相对比较简单

打印出来的结果也很方便识别：

果然轻轻松松啊

这是一段时间的我的经历和笔记，看过之前的博客的人应该会看到，我在用mongo，是的，我将大量的数据用mongo存储了，但最终我还是放弃了。理由有很多，不过我还是慢慢列出来吧
1、为什么用mongo
因为当初设计数据库的时候仓促，本来认为只有2～30万的数据，但最终却发现会有200多万条，以后可能还会更加多，所以当初很多大字段都扔在了一个表里，导致如果用in查询，非常慢。所以我想用mongo，扔到内存里查询，看看效果是否会很好。

2、为什么又放弃使用mongo了
说实话，mongo在做关系查询的方面确实挺不错，但存在的问题是我的数据都是用php往mongo里导入，而mongo对于数字和字符串还是认得比较严 的。当然这都不是问题。。问题是现在没有专门的DBA，以后对数据不太容易，也不太方便管理。毕竟目前公司的整体项目，大部分都是用mysql在做处理， 所以，为了配合更多人，才放弃使用mongo（当然，也是为了节约内存）

3、mongo在使用时的优缺点
其实mongo在仅做处理这些条件查询的时候，并没有想象中的那样。当然确实很快，不过在第一次查询的时候还是有点慢的，然后在数据没有变化的时候查询数 据都在0.00x秒，不过，我真的没有太在意（其实有点在意，但因为那个条件也是用mysql生成出来的，再加上查询之前对于那些字段都得做一次强制转 换，否则对于查询的时候可能就出不来数据）

4、最终我怎么做了
既然我已经知道我原来的数据表的问题在哪里，我就想办法处理掉不就完了？于是写了一个脚本，自己将主表的数据中的几个重要的，用来查询和排序的字段拎出来，重建一个表，用来查询，将可变字段改成定长字段，为了提速。这样一来，速度比原来最少快了两个等级。

5、下一步我会怎么做
其实现在做很多事情都是偷懒了，比如对于字段是int型的时候，却还是用的where id = '1',而不是where id = 1;
所以这是后期考虑优化的地方。
当然因为将主要字段分拆成表，所以带来的另一个问题是，当更改原表的时候，需要对新表做更新处理。

6、最后说一下
原表的索引，原来达到了300多M，后来因为把数据迁到新表（做冗余），在新的表建的索引，只有70多M，而且原表因为将索引清除了，编辑和插入的数据又上了一个等级，最终还是觉得这样有优势 。

---PS
不一定要学我，我这也是自己的经历，没有什么可比和可参照性。当然你要骂我那是可以的

之前在“ Yii的又一个BUG？”提过我将数据导入到数据库时，进直接用ActiveRecord导入的，所以字段的类型都是String，后来发现问题，指定字段 为int值
这两天为了做一个查询，看了一下程序又遇到了问题：
同样的参数，同样的内容，一个查询能够有值，一个查询一点数据都没有。。。这是怎么回事？
一步步的测试下来，最后怀疑是字段类型，从$_GET回来的参数应该是字符串型而不是int，于是做了一个强制转换，数据果然就有了。我晕啊。。。大哥，你绕了我吧？
看来以后对于这类的数据，只要涉及mongo的，还是要多做一次额外的处理，否则连问题都没法发现。当然这也是因为不细心导致的。
慎记