每日次数清零的实现 about bugs HOT 3 OPEN

刚测试：
81W文档，结构为：

{
  _id: Number(0-100000)
  jjc: Number(0-100000)
}

$set操作符

db.a.update({},{$set:{q: NumberInt(100)}},{multi:true});

初次时，耗时10秒。
当每个文档结构上都存在键值q后，再次执行，耗时4秒。比find还快。find约为6秒。当然find要涉及到解析数据、传输数据。

$inc操作符

db.a.update({},{$inc:{jjc: -1}},{multi:true});

耗时17秒。大概涉及到解析数据、计算，比$set的直接覆盖要慢不少。

一般来说每日清零，就是$set。性能还是很满意的

3月1日补充：

1. update批量更新会消耗大量的CPU；另外iowait没测，但肯定会有。
2. update默认不阻塞其他的读写。虽然整体性能会受影响，但应该不大。
3. 4秒是mongodb完全没其他事情时的测试。
4. $rename速度在12秒左右

db.a.update({},{"$rename":{"qq2":"qq3"}},{multi:true})

from bugs.

6月1日

关于$set不同类型的影响

测试在3.0.x的WT引擎下测试。分别在两台机器的SSD和HDD上进行了测试。

db.user.update({},{$set:{test:"一"}},{multi:true})

文档101万。大部分文档6字段，100字节。

表现：

1. $set字符串长度1到100，插入耗时30秒
2. $set数字1，耗时17秒
3. 无论之前是否有test字段，$set字符串耗时都一样
4. $set和旧值一样的字符串，插入耗时4秒

结论：
WT引擎下：

1. $set字符串的长短对插入性能影响不大（前提是硬盘不是瓶颈）
2. $set数字要比字符串快许多（当然他们大小也不一样，但感觉应该不是这个原因）
3. 之前的预分配优化性能，这么看WT引擎下是没什么效果了。
4. $set的值和旧值一样，会很快~（聊胜于无）
5. 测试结果在SSD和HDD上没有区别,但CPU都彪满了。（MAC很奇怪，mongodb占200%了，总CPU量仍有很多空闲，猜测是系统做了保护）

猜测：
之所以慢下来，一方面可能是WT开启了测试（压缩方面用的默认配置）。

from bugs.

我选择第三种 貌似是最省事的，性能也很好。。

from bugs.