select count(*) from A where date>today()-30 and ID in (
select ID from B where level='VIP'
) limit start,limit

用 in 条件查询呢

nodejs + mq

@rrfeng 要这么说的话，实际上应该是 series

influxdb 插入数据格式为 insert measurement,tag=value field=value timestamp
是按照时间存储的

对于 measurement tagkey, tagvalue 和 timestamp 一样的，field 会被最新的值替换

看下丢失的都是些什么数据，和没有丢失的数据的区别是什么

时序数据库

这个 蛮有意思的

用户访问时长问题（会话时长）吧？ 实际上不管服务端统计还是客户端统计都是存在误差的，因为你无法知道用户是否还在访问你的页面，按照上面的说明， 比如我打开一个 A 页面，然后新打开 tab 访问百度，过了一个小时再回来，难道用户就真的是访问 A 页面（或者留存在 A 页面）一个小时么？

@justfly 确定么？不太敢升啊

赞，从实际业务特点出发，进行相关目标设定和分析，另，神策 和 growingio 功能确实强大

@callofmx 单机故障？ 不会是丢块吧， 反正就一直没好过。😄

@callofmx 哈哈，看来你也是有故事的人啊。之前了解到阿里，网易，搜狗，其实也这样，甚至比百度还累
不过事情确实是多，而且人员流动也很快

在百度 hadoop 运维组 待过两年,现已转其他公司开发。
先说下百度 hadoop 运维的日常，基本上每个月有一周值班 on call，一周 答疑，剩下两周开发，这是 hadoop 这边的情况（其他运维团队不一定有开发项目）。两周值班是真心累，被电话和 hi 不停的轰炸啊，然后处理各种问题，集群挂了，用户作业跑慢了或者跑不动了，队列资源较少啦，还有问你怎么使用 hadoop，总之 不是我的兴趣所在。但是同时，一旦出现问题，运维解决不来的，就要拉开发的一起解决问题，所以开发的也有值班的，也经常被我们叫起来处理问题
现在已经回来做开发，对于我个人而言还是比较舒服一些，不用处理那么多琐事

离职前，我也有几个机会 transfer 其他开发岗位，hadoop 相关的岗位还是比较缺人的哈，但是由于自身原因还是回来了。对于我来说，运维可能有这几个问题

1 开发流程不规范，毕竟不是主业
2 dirty work 太多，浪费时间太多，但是这个取决与项目与个人，看你怎么管理你自己的时间了
3 频繁的沟通，这个也确实很重要

同时可能这几方面需要考虑

1 岗位的专业能力和前景，比如 hadoop，前几年的就业前景很好，而且专业要求相对也高
2 兴趣，这个很重要，有同事对运维感兴趣，总能发现问题，解决问题，个人能力和职位提升也快
3 再考虑钱的问题

总之，运维和开发都要看具体的岗位和实际工作内容，再结合前景，个人兴趣，钱再做决定

在狼厂确实也成长不少，各个方面都在学习和进步中，但是发现自己并不适合。
胡乱之中写下的，说的不是很全面，而且可能有很多说的不对，还请谅解哈。

就是会出现充电时候，并没有提示在充电