易栈网-膘叔

周末两天租了个车玩玩，也算是一个经历吧，毕竟做什么事情都要有第一次的。
其实找了几个租车的网站：一嗨、神州、安飞士之类的，安飞士很早就看到过了，但听说很贵，所以就不考虑。最近就在神州和一嗨中选择了了神州。
因为看到神州上面写着第一次注册 可以优惠一天。于是就选择了自动档的车进行了测试。当然在之前我也 电话订了车，记得那时候的保险费是20，但这次首次注册的保险费则是40.。。好吧。反正免119，我也忍了。
由于驾照没拿多久，所以我后来还是补了一个：不计免赔服务费，每天30，因为是2 天，所以总计最后是279=119*2+20(服务费)+40*2（保险）+30*2（不计免赔服务费）-119
这个不计免赔还是有用的。因为还车的时候，不知道怎么着后备箱上有一道划痕，但不知道是哪来的。因为在拿车的时候正好他们的手电筒没电了，最后就粗粗的检 查一下就过了，不知道是否当时就有的，还是后来我划上的。不过因为在下面的保险杠上方部位也有一道划痕，所以，应该是原来就有的。但，无法判断了，最后因 为我买了不计免赔，就这样过了。但心里纠结啊，这是谁的问题呢？因此，如果你也要租车的话，要好好的看啊，否则有可能会赔钱哦。。。
1.4的自动档，烧油那是刷刷的。我最终开了131公里，烧了30L油（也许没这么多，这是毛估估的，因为我来不及去加油，他们要下班了，我赶时间去还车的，因此，不但毛估估了这个油，还加了50元的服务费）
然后就是一路开啊开，开啊开。。。开开开开就认识一点路了，反正沿着路一直开。一直开。。。。偶尔为了走正确的路，开了iPhone上的搜狗地图，还有语 音导航，还不错，有点准（只是以前有一次路线导航到了华东师大里面，理论上，那个路线是不允许校外车辆走的，但是因为有路名，所以也被导航上去了）
停车，家附近停车还算便宜，1小时内免费，超过1小时，小于1天，5块。去中环百联停车，前2小时免费，后面每小时5块。其他地方没停过不清楚。。。
还车的时候，最好前一小时，因为要加油，初次借车不认识加油站，得提前一点比较好，初次还车，不认识还车点。为了还车在路上乱逛了将近一小时。痛苦。而且因为我是在他们下班前还车，所以时间就更紧了。下次要记得，宁可提前一点不要赶时间啊，不然，那50就省下来了。。

最后，不知道怎么评价这次租车。。。反正还算顺利吧
租车需要：身份证、驾驶证，以及与身份证同名的信用卡（最少需要预授权3000）。租的时候，刷3000，还的时候刷1000（防止你交通违规）

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

本来。。。VPS已经换到budgetVM上面去了，但不幸的是，这两天VPS出了点问题。

结果。。。数据丢失了。
所以我现在又切换到了linode上面。果然，linode还是最好的VPS，没有之一啊。。。

准备利用google的搜索来一一恢复我这段时间的数据。当然。还有googlereader。。。
他们的support里面这么说：

Dear Customers;

We are aware that some of your systems are offline, or failing to reboot, we are working to correct this issue immediatly and we will update you once it has been completed.

This does not affect all of our customers but it appears to be ~5 Virtual Machines per Hardware Node which are failing to boot.

We will update you via your support ticket once it has been resolved. I can assure you we are working dillegintly twords a solution at this time.

Regards,

Nick Rose

Enzu Inc.

然后:

Status update: Node Maintenance Continues

Our administrators are still working on restoring your account to service. We apologize for the inconvenience.

We will be providing a 1 Month SLA Credit for this outage. Further details will arrive when your ticket is resolved.

If you do not need the data on your current vps and would like it reinstalled we can do this for you which will bring it back into service immediately. If you would prefer to wait for the admins to complete their work no further action on your part is required.

We will continue to send updates as they become available.

Thank you for your patience.
-----------------

看到这个就让我感觉纠结了

在讲今天的内容前，请允许我说几句：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差不多。。

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