• 有的, shenyubao@souche.com 欢迎来简历

  • 想攒开源项目经验的小伙伴们抓紧喽, 研发工具开发职位的 80% 的工作内容都可以开源 ~~

  • 统计平台思路分析 at 2016年04月23日

    按题主描述,默认都是数据 Append-Only

    第 1 个要考虑的问题是需要不需要原始数据,如果只存结果的话,一个表处理下就好啦,如果需要保存原始数据再看下一个。 第 2 个要考虑的问题是数据量,数据量千万级以内直接 Mysql 就行,查询要求比较高的时候离线处理可以再战一段时间,如果数据超过千万级时候,再看下一个。 第 3 个要考虑的就是大数据的方案了,一种是时序数据库(InfluxDB,OpentsDB),第二种是 OLAP(Kylin,Mondrian,Druid)。 时序数据库解决这种问题更优雅一些,一般大家的运维经验普遍有限,不太敢用于生产,一般都只用于数据不太重要的监控系统。 OLAP 是比较主流的方案,你提到的场景是维度转换中的一种,查询维度可以自由转换(时间的年月日时分秒,省份的省市县等等)。

  • 分享一次排查问题的过程 at 2016年03月27日

    赞。 另外,#1 楼 @42thcoder 这种偶发的问题即使做一个工具也很难定位到,可以优化的一些地方:

    1. OneAPM 的同学可以做的更好一些,这个既然是数据库上的问题,直接就应该显示出来数据库有问题。
    2. 我们自己的链路跟踪系统开发还是挺有必要的,一些需求 OneAPM 估计做到他们的通用系统里,例如单次请求的跟踪,资源视角的视图,与我们监控系统的集成等。 链路跟踪系统实现后,调试这种问题会很轻松。 3.@besfan 在解决这个问题中花了不少时间在打日志和取消日志上,日志做的规范一些的话可能会让这个问题好解决一些,例如外部请求,数据库长请求,缓存长请求等等。
  • 看到这个广告决定购买一本

  • 游标分页的实现思路 at 2015年09月24日

    #1 楼 @billy 置顶和游标分页 的场景还是有些区别的:

    1. 置顶只需要维护少量的数据,游标分页是有可能遍历所有数据的,并且维护排序。
    2. 置顶不能保证每两次分页取到的数据不重叠,游标分页可以做到。

    LZ 的方案简单粗暴有效,思路二会更快到达瓶颈,毕竟把 ids 都取了出来。 等到数据量大了以后,缓存是要有的,能用 redis 的 zset 话最方便,不能的话继续分情况,读多写少的话,自己乖乖维护这个列表,如果读少写多的话。。。把提这个需求的产品经理拉过来,我们好好聊聊。。。。

    btw, 微博的 feed 流也没有做到准确的游标分页

  • #1 楼 @hrz3424 不好意思,暂时还支持不了远程。不过我们时间比较灵活,方便的话私下聊一下?

  • 轻轻地顶一下