易栈网-膘叔

在讲今天的内容前，请允许我说几句：what the fuck，再说一句：“你哭著對我說童話裡都是騙人的”
前两天说过为了速度我建了索引，虽然给id建了unique的索引，但是数据还是不由分说的插了重复的。好吧。因为数据在unique前就进数据库了。所以。。。我必须要再加上dropDups这个条件。

于是乎，我就先开始删除索引，然后灾难就来了：

b.archive.dropIndex({id:1,unique:true})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true},{name:"id"})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true},{"name":"id"})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({category_id:1})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"category_id":1})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"key":{"status":1}})
{ "errmsg" : "index not found", "ok" : 0 }

为什么为什么？？？？
为什么我会这么做？是因为：http://www.mongodb.org/display/DOCS/Indexes
这里面写着：

Dropping Indexes

To delete all indexes on the specified collection:

db.collection.dropIndexes();

To delete a single index:

db.collection.dropIndex({x: 1, y: -1})

Running directly as a command without helper:

// note: command was "deleteIndexes", not "dropIndexes", before MongoDB v1.3.2 // remove index with key pattern {y:1} from collection foo db.runCommand({dropIndexes:'foo', index : {y:1}}) // remove all indexes: db.runCommand({dropIndexes:'foo', index : '*'})

我晕啊。这是肿么了。。。
后来还是神仙和赵拂衣说了一句，试一下dropIndex("xxx")，果然。。。Over了。你说，你这不是忽悠人嘛 ，为了这个，我折腾了一个晚上啊。。。。
害得我当时只能dropIndexes，先删除所有的，再重建索引。。。数据又多，我等了好久好久啊。

前段时候做了个一万条数据的对比，这回做了个2000000条数据的对比：
测试方式还是和以前一样：

测试开始：
1、order by id ASC  limit 25，很常见的查询吧。每页显示25条。
没有索引的时候：0.05秒左右（1万条是0.88秒，很奇怪）
用了id,unique索引后，0.004,第一次的时候0.08，后面稳定在0.00x左右（与1W左右一致）

2、where category_id = 1 limit 25，某个条件
无索引时：24秒左右 (很夸张。。。)
有索引：第一次0.06左右，后面稳定在0.00x(x>6)，即在0.006~0.01之间(与1W左右一致）

3、where category_id = xx order by pubdate limit 25
无索引：20秒左右，最慢的一次达到了70秒
有索引的时候，与条件2差不多。。

虽然不是特别的深入测试，但这样也几乎足够了。不过，这带来另一个问题。内存消耗比较大啊。果然是吃内存大户

因为我mongo也是刚刚开始用，所以有一些地方的测试就不如很多专业人士了，但不代表我不能发言啊。。。

测试数据，11000左右，全部是int型字段（关于int型和字符串型，之前讲过了）
11000条，占用空间并不大，关键是看速度。。
11000条的数据的字段：id,pubdate,category_id,status,is_top，为什么只有这些字段 ？因为详细字段的Cache已经由redis实现，而redis不支持条件查询，所以将这些条件查询用mongo来代替了。你懂的。。为了速度。。。

测试开始：
1、order by id ASC  limit 25，很常见的查询吧。每页显示25条。
没有索引的时候：0.88秒左右
用了id,unique索引后，0.004,第一次的时候0.08，后面稳定在0.00x左右

2、where category_id = 1 limit 25，某个条件
无索引时：0.6秒左右
有索引：第一次0.06左右，后面稳定在0.00x(x>6)，即在0.006~0.01之间

3、where category_id = xx order by pubdate limit 25
无索引：0.8，最慢的一次达到了1.5秒
有索引的时候，与条件2差不多

至此第一步测试完毕，下一步测试200万左右数据。。还没有开始。因为都是真实数据，插起来比较麻烦

昨天下载了php-mongo的组件进行了安装。结果在进行limit查询的时候一直reset。。查了半天，以为是语法错误 ，但最终都没有发现任何问题。当时我下的包是：https://nodeload.github.com/mongodb/mongo-php-driver/tarball/master，嗯。这是一个最新版。文件名是：mongodb-mongo-php-driver-1.3.0beta1-15-ge426381.tar.gz，一眼就可以看出这是一个beta版。我晶。。。就因为它，害得我折腾了一个晚上

各位看官：

这两句没问题吧。。。但事实上在1.3中就会导致 直接reset。如果不加limit条件就一切正常。我算是。。。蛋疼了。

后来从pecl.php.net中搜索mongo，网址其实就是在：http://pecl.php.net/package/mongo，然后下载了1.2.12：http://pecl.php.net/get/mongo-1.2.12.tgz，下载完后重新编译，又是那两句简单的代码：
phpize
./configure
make install
然后重启。。。一切就太平了。

本来一直在用redis，也没有觉得不爽，直到我需要对数据进行排序。。。进行条件查询。
一下子问题就来了。redis不支持这种条件查询。
于是。。我先hmGetAll，然后利用usort先排一下序，然后再利用数组的slice进行切分。这么一处理。。只有3000多条数据，0.2秒就这么浪费了。我晕啊。这怎么可以。。。这不科学啊。

于是，0.001949 一下子就刺瞎了我的钛金狗眼。
因为mongo的查询没有redis那样方便。于是在hashset的这一块，和list的这一块，我还是用redis方便，毕竟可以当成一个简单的链表处理，还是很方便的。。

对于有条件的查询，还是用mongoDB会更方便一点。测试了一下。原来只需要mongodb 512M内存就足够了，哥很大方，给了他1G，小样，你还不开心？