有的，[email protected] 欢迎来简历

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

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

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

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

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

看到这个广告决定购买一本

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

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

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

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

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

轻轻地顶一下

#14 楼 @allensea 距离西溪印象城很近

少年，可以看看 https://ruby-china.org/topics/26670

#10 楼 @ailen 是的，分享的 U3D; 不做游戏，这个是一个同学工作之余学习分享的

#4 楼 @onemagicant 游泳池还是有些奢侈，羽毛球场 和 篮球场 听说都没问题。

#1 楼 @so_zengtao 为 4S 店以及小车商 提供金融服务这个正在做了 :-)

#7 楼 @issac 还招~~~