BlueSky高性能时序数据库误区

时序数据库不需要分析能力主流时序数据库如InfluxDB、OpenTSDB，以及一些新时序数据库例如，都只支持简单的查询，支撑简单的场景，譬如单数据源单/多指标过滤查询、单数据源单/多指标过滤聚集，多数据源过滤聚集等。是点查和聚集查询。

然而随着大数据分析、IoT、IIoT等快速发展，越来越多的应用需要更强大的分析能力，以实现模式识别、趋势预测等功能。因而时序数据需要强大的分析能力，包括和关系数据的关联聚集分析和分析（如ARIMA、趋势预测、特定模式识别、根因分析、阈值修正）等。

此外用户希望能用自己熟悉的语言譬如Python、R等对时序数据进行更复杂的处理，并充分发挥Python、R在数据分析方面的强大生态。

BlueSky高性能时序数据库关注的技术点在哪里？

快速聚合能力。时序业务一个通用的需求是聚合统计报表查询，比如哨兵系统中需要查看近一天某个接口出现异常的总次数，或者某个接口执行的大耗时时间。这样的聚合实际上就是简单的count以及max，问题是如何能快速的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合，要知道统计的原始值可能因为时间比较久远而不在内存中哈，因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合，就是在数据写进来的时候就完成基本的聚合操作。

未来技术点：异常实时检测、未来预测等等。异常实时监测主要用来监测实时异常点，比如服务器监控中对延迟响应慢的请求都会实时监控报警，再比如运动手环对心跳异常监测报警等；未来预测是另一个非常重要的领域，能够预测未来是一个很有用的事情，试想，如果在交通堵塞前3分钟预测到这个路段要堵并向发送报警，就可以一定程度上缓解交通堵塞的问题。而根据时间序列来预测未来时间会发生的事情是一件看起来水到渠成的事情，这里面会涉及到机器学习的相关知识。

时间序列数据库跨节点关联查询 join 问题

跨节点关联查询 join 问题切分之前，系统中很多列表和详情页所需的数据可以通过sql join来完成。而切分之后，数据可能分布在不同的节点上，此时join带来的问题就比较麻烦了，考虑到性能，尽量避免使用join查询。

解决这个问题的一些方法：1）全局表全局表，也可看做是"数据字典表"，就是系统中所有模块都可能依赖的一些表，为了避免跨库join查询，可以将这类表在每个数据库中都保存一份。这些数据通常很少会进行修改，所以也不担心一致性的问题。2）字段冗余一种典型的反范式设计，利用空间换时间，为了性能而避免join查询。例如：订单表保存userId时候，也将userName冗余保存一份，这样查询订单详情时就不需要再去查询"买家user表"了。

但这种方法适用场景也有限，比较适用于依赖字段比较少的情况。而冗余字段的数据一致性也较难保证，就像上面订单表的例子，买家修改了userName后，是否需要在历史订单中同步更新呢？这也要结合实际业务场景进行考虑。