时序数据库发展简史

代时序数据存储系统

虽然通用关系数据库可以存储时序数据，但是由于缺乏针对时间的特殊优化，比如按时间间隔存储和检索数据等等，因此在处理这些数据时效率相对不高。

代时序数据典型来源于监控领域，直接基于平板文件的简单存储工具成为这类数据的首先存储方式。

以RRDTool，Wishper为代表，通常这类系统处理的数据模型比较单一，单机容量受限，并且内嵌于监控告案。

分布式时序数据库被这个时代需要

在国外的金融行业，时序数据库已经应用了很长一段时间，华尔街上的很多公司在 2000 年之前就开始使用时序数据库来解决金融行业的问题了。国内金融领域，特别是券商、、公募等行业，差不多近三年在 DolphinDB 的带动下才开始使用时序数据库。

在物联网行业，范围内使用时序数据库的时间还不到 10 年，国内差不多有 3 到 5 年的时间，基本都停留在阶段：通过大量使用单机版时序数据库完成数据采集、数据查询、监控等简单工作。周小华预计，在未来 5 年内，时序数据库会迎来爆发性增长。

在物联网领域，随着数据量的式增长，越来越多的场景每秒超过 50 万测点甚至 1000 万测点。对于这个量级的数据，单机版时序数据库已经无法满足业务要求了。与此同时，近几年，分布式时序数据库技术越来越成熟和完善，已经进入到大规模落地应用阶段。虽然物联网领域对于时序数据库的应用还处于比较浅的阶段，但是企业逐渐意识到数据的价值，未来会有越来越多的企业希望利用时序数据库挖掘出更多有价值的信息。

在金融领域，由于使用时序数据库的批头部客户的作用，大部分金融机构会很快意识到采用高性能时序数据库所带来的竞争优势。5 年后，时序数据库会在金融机构成为标配。

当然，任何一项技术的成熟都离不开资本的进入。周小华表示，投资机构今年对时序数据库赛道的热情高涨。据周小华介绍，投资机构对时序数据库的调研，主要关注的是短期内能否在金融领域实现快速增长，以及中长期时序数据库在物联网的应用场景的变现能力。

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

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

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

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

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

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

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