手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜Qcloud , 注册 | 登陆
浏览模式: 标准 | 列表2012年08月的文章

mongodb删除索引

在讲今天的内容前,请允许我说几句: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,先删除所有的,再重建索引。。。数据又多,我等了好久好久啊。

Tags: mongo

mongodb用索引与不用索引的区别(续)

前段时候做了个一万条数据的对比,这回做了个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差不多。。

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

Tags: mongo

php header 设置Cache

在手册里,关于header函数的说明是说服务端会输出一系列的头,用firebug也可以看得很清楚
一般来说,我们用header控制的情况不是特别多,毕竟不会主动去改什么:一般也就设置设置编码、跳转、压缩等,不太会过多的干涉。下载的时候也会设置头,黑黑

手册上,我们对于cache都是写着如何设置,以便让代码不被cache:


header("Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Pragma: no-cache"); // Date in the past

而且在设置的时候还得注意在header前不能有输出,否则header设置无效,但都没有写过,如何给页面设置Cache,虽然我们知道有一些办法,比如 E-TAG之类的。当然也有简单的设置:
比如我们在输出前,对内容进行md5,将它当成e-tag只要没变化,就不会有影响。也有其他的方式:

$seconds_to_cache = 3600;
$ts = gmdate("D, d M Y H:i:s", time() + $seconds_to_cache) . " GMT";
header("Expires: $ts"); header("Pragma: cache");
header("Cache-Control: max-age=$seconds_to_cache");

缓存1小时,主要是过期时间得用gmdate来设置,而不是date,这个要注意,其他都差不多。maxage要和expire能够对得上。

不算笔记的笔记。

Tags: header

粗心,又见粗心

有时候会用到gzip函数,只是有时候而已。。。
于是。。有些函数就会直接用上了。比如 :gzencode,gzdecode,gzcompress,gzuncompress,gzdeflate,gzinflate
在用的时候。。有些是想当然的。。。比如有Gzencode,就一定会有gzdecode吧?错。。。gzdecode暂时还没有正式版本支持,只存在于svn中,虽然手册上有。。但也说明了不能用

gzcompress与gzdeflate的区别,一个是基于RFC1950协议,一个是基于RFC1951,gzcompress因为是用的1950协议,手册上说了,它需要zlib库。gzdeflate就不需要
所以,gzcompress现在用的相对又少了一点。

好吧,现在说说我的粗心了,大家都知道Gzip压缩是有等级的(压缩软件都有,1~9,1最低压缩,9是最高压缩比),用9的话压缩出来的文件最小,但是解压的时候最耗CPU。所以一般 都是level4,其实就算是1也不错了。

粗心的就在于gzinflate的时候,想当然的将第二个参数length想成level了。结果一直在报错。居然我5分钟后才反应过来。NND,太粗心了。。。
第二个参数是length,不是level啊。

Tags: gzip

mongodb用索引与不用索引的区别

因为我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万左右数据。。还没有开始。因为都是真实数据,插起来比较麻烦

Tags: mongo

Records:41123456789