感谢大家的意见、建议，我们都收下！大家如果还有问题，无论是发信还是在这里留言，我都会一一回复

@xsen 理解，其实团队之前也是有些远程的教训，我们觉得在这个时间点如果能在一起，对小伙伴对公司都是最好的，未来应该还会再开放远程的职位，如果大家有兴趣，也可以先聊聊

@vkingsea 这家伙确实有点装，我同意！：）希望有经验的小伙伴来教他怎么做好这数据库

@xsen 你说的挺对的，绝大部分公司这么做，但我们不这么做。我们不找人填坑，我们是产品做完放给大家。如果你觉得产品很 demo ，可以提意见，我们虚心接纳。不管别家公司怎样，我们坚持底层的创新。大家只看到了工资不开心，我理解、接受、改正！尽快融资给大家涨工资！

@Eds1995 最低消息 1k
-------------------------------
benchmark 写的很清楚：internal stress 2 columns, 12B/row ，一行是 12B ，这是一个 1 个 value+1 个时间戳的最简行，我需要带宽在你的基础上再除以 100 ，你看可以接受不？：）

@LeeReamond 好，谢谢建议

@wph95 不好意思，白天一直有事，回复晚了。其实你是抬杠，但是我理解：）谢谢所有建议，都收下。这里其实没有学谁，再声明一下吧，如果有合适的，2w 以上也没问题：）再声明一下吧，2w 的上限是想找一些应届的同学，工作的。。。（就不说了，怕大家不开心）

@areyoucrazytom 谢谢 热烈欢迎！

@victorc 我个人理解你，没有钱是万万不能的。

但钱融再多，做不了的还是做不了。我们其实是恰恰想找一些没有经验的、技能的，我们带他们去引人入胜之处。我们不谈情怀，谈的是做事的热情，如果你不爱你正在做的这份工作，你为何去做呢？你又如何能做好呢？

之所以言辞留有余地，在于我们没有必要排除有情怀又有愿意做适当平衡的有经验的同学。我们有最好的技术，我们有信心给大家带来更大的收益！

我突然想起很多年前，pingcap 东旭在 v2 招人的帖子。初创公司招人难，钱是问题，但其实真不是钱的问题。是我真把钱给到你，你真能带大家一起前进吗？我们能！

@xsen

远程的话，或许可以找得到经验丰富、有想法的，有所说的相同理想的人
------------------------------------------------------------------------------------
确有人才，也可以联系我们，我们可以支持 relocation 到北京。我司是中关村大街重点签约企业，对没有北京户口的同学能在公司做的好的，有很大可能解决北京户口。

@xsen 也欢迎跳板，只要大家能对上毕竟在这个时代，在一家公司做到底的人几乎不存在，我司真能成为大家的跳板，也很荣幸

@superychen 谢谢有兴趣，我给你单独介绍，发邮件就好，也可以在 request 页面留下信息。我最近准备了时间给大家，比看文档强太多嘛

当然大家若没有兴趣，也可以点个赞，哈哈

@fiveStarLaoliang 也许。公司发展会有个过程，我们依然坚信有相同理想的人终将聚在一起。

@liprais 哈哈，谢谢。

如果说幽默，那这是中国互联网高度内卷给年轻一代带来的黑色幽默。高薪的工程师并不一定能做这件事，而大厂高 P 我们见的多，他们也无一例外做不了这件事。不如让有理想和有热情的小伙伴进来，不提期权，对他们来说有成长其实是最好的“薪资”。而且我们不加班，我们倡导平衡的生活。

作为产品的作者，我们不吹 nb ，我们也欢迎在领域有经验的同学上门或远程”砸场“，支持自带任意数据库 pk ，我们愿意和同学们分享我们更快的背后的原因。

@leonhao 握手，你说的没错，选择了就好，存在即合理，我并非要否定你的选择。我不跳出业务谈技术，恰恰我结合业务帮大家展望，10 万点秒级采样的场景都是真实用户案例。我是想站在物联网领域的一般性角度分析问题，看看大家如何能做的更好。

pg 的可以通过 extension 来来实现增量视图，但一般用户不懂，所以 timescale 有优势，没错。但增量其实也有增量的问题，要不 pg 为什么不放入主线呢？其中一些问题 pg 主页也列出来了。

第一，有些问题在不同场景下会有大放大：比如数据由于弱网环境，到来是有延迟的，有时甚至有按天计的大延迟。增量就是不停发生，为了保持同步，这种 naive 的机制下你必然不停同步。数据量大了，问题会非常多：比如即便是是增量，也不可能同步，相反资源的竞争会让你想减少同步的时机，这时你发现它开始玩不转。

第二，物化机制不管是对于 adhoc 查询基本无效。单一类型查询负载限制，导致你必然组合其他系统。你会想要对近期和长期数据进行复盘吗？就按你这个量，假定你有一个 1 年的数据库了，你会让你的运营会在生产节点上进行多样性的数据分析吗？ ok ，多加一个 replication 的 instance 吧，但数据库不要钱，硬件也要钱，对吧。所以，毋庸置疑，如果对这些问题进行原生的支持，一定会有更好的性价比。

当然如果说量也不大，性能也没问题，也不需要扩展，也不需考虑经费问题，确实选型此时不重要啦。

@Richard14 谢谢！

作为一个中国工程师，一直想告诉世界，我们能做最好的基础设施，没有之一。

这“闺女长大了要出阁”，我其实也挺紧张。iotbase 虽然免费开放，但还不是一个开源产品。所以我们不遵循一般开源项目地线路，先开出来，然后让用户去趟坑。我们已经有了严格的测试，我们的标准是：可以有功能没实现，但所有实现和开放的功能必须是生产级的。还有一些功能，比如 csv 格式 paload ，高可用 replication ，复合分区等，我们已经完成但尚未更新文档。所有物联网领域，我们认识到需要的一般性关系模型的功能，其他家有的没的，我们都会有，只是时间问题。但如果用户只需要基本的关系模型聚合，我们其实真很 solid 。

而且，iotbase 非常易用，2 分钟可用：半分钟解压启动，半分钟创建用户（我们安全 in core our mind ，我们没有默认用户，不创建用户，连上帝也没法使用，“妈妈再也不担心我被 default 脱库啦”），半分钟创建表，半分钟写入一条数据，半分钟 select *。作为一名数据库专家，我负责地保证，如果你是 pg/timescale 初次使用，光权数据目录准备和权限处理，没半小时，你都搞不定。

如果大家看到这个帖子愿意进来试试，我都愿意提供终身免费的企业级服务（包括从硬件选型到版本升级的所有问题）（也许要设个数量限制，哈哈）。

@joesonw 实话实话，influxdb 其实已经 out ，不管重技术层还是表示层。aggregation 其实是一个 low hanging fruit ，通常用 sql 都能组合出来，当然效率会比定制算子低一些，但通常据我所知，用户期待使用太复杂的算法的场合并不多（当然选择多总是欢迎的）。如果真要用，我建议还是一般性的 sql 模型，某些场景的 join 在现代硬件上其实可以高效的，只是现在时序厂商们的认知还没有到。单表局限场景，是可以的，但业务线发展了，还想一张表走天下，不可行。

@leonhao 所谓增量还是全量刷新，其实只是物化视图的实现细节[1]

另外，每天 1 亿其实只能算小数据，查询在 500ms 和 5ms 完成可能没直观感觉（但其实快还是能给你省钱，至少你可以把机器 instance 配置减到最低）。10 万个点，每个点数十个指标，数十秒一次上报。他们其实还想更快的数据收集，但系统做不到。你可以试一下，把你一年的数据压到 1 天（相当于你业务扩大 300 倍），看看 timescale 工作如何。

[1] https://wiki.postgresql.org/wiki/Incremental_View_Maintenance

@leonhao continuous aggregate 其实就是物化试图，本质是 pg 在后台帮你 refresh ，但是量大了，物化试图机制同样产生问题，当然有些手段可以调整，但毕竟只能治标。