时序数据库忽然火了起来。Facebook开源了beringei时序数据库，基于PostgreSQL打造的时序数据库TimeScaleDB也开源了。时序数据库作为物联网方向一个非常重要的服务，业界的频频发声，正说明各家企业已经迫不及待的拥抱物联网时代的到来。
时序数据库的定义
A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range)
维基百科
时序特性：
时间戳方面
通用的业务场景内以s和ms精度为主，在一些遥感等高频采集领域，时间戳可以达到ns级别。
采集端生成，可以乱序到达服务端，需要排序。
服务端写入生成，由数据到达服务端时间来决定。
采样频率方面
采集频率一般有两种，一种是周期性的时间采样频率；另外一种是事件型的采样，时间间隔随机。
数据特性：
不需要支持跨设备join。
高频读取热数据。
冷数据需要支持更紧密的压缩，甚至是降采样、有损的超高效压缩。
数据库特性：
持续高性能写入。
按照时间窗口访问数据。
数据无更新操作，只存在小规模的覆写。
数据批量过期。
基于时间range的高效查询。
不支持事务。
企业特性：高可用，高可靠，弹性伸缩。
时序数据库发展简史
第一代时序数据库
虽然通用关系数据库可以存储时序数据，但是由于缺乏针对时间的特殊优化，比如按时间间隔存储和检索数据等等，因此在处理这些数据时效率相对不高。第一代时序数据典型来源于监控领域，直接基于平板文件的简单存储工具成为这类数据的首先存储方式。以RRDTool，Wishper为代表，通常这类系统处理的数据模型比较单一，单机容量受限，并且内嵌于监控告警方案。
第二代时序数据库，基于通用存储/KV存储
伴随着大数据和Hadoop的发展，时序数据量开始迅速增长，系统业务对于处理时序数据的扩展性等方面提出更多的要求。基于通用存储/通用KV存储而专门构建的时间序列数据库开始出现，它可以按时间间隔高效地存储和处理这些数据，比如OpenTSDB，早期基于RocksDB的influxdb。
这类时序数据库在继承通用存储优势的基础上，利用时序的特性规避部分通用存储的劣势，并且在数据模型，聚合分析方面做了贴合时序的大量创新。比如OpenTSDB继承了HBase的宽表属性结合时序设计了偏移量的存储模型，利用salt缓解热点问题，InfluxDB基于range shading和hash shading的模式，通过range shading提高查询效率，通过hash shading解决热写的问题。
第三代时序数据库
垂直的基于零的时序数据库，这一代的特征是自建存储引擎，从最初的持久层就为时序场景定制设计。它们通常他们具备更加高级的数据处理能力，高效的压缩算法和符合时序特征的存储引擎。它们包括InfluxDB的1.7之后的版本，Prometheus，Tdengine，TimescaleDB，KronosDB等。
以InfluxDB为例，它采用基于时间的TSMT存储（LSMT的变体），Gorilla压缩，面向时序的窗口计算函数p99，rate，自动rollup等。
另外，虽然Tdengine和TimescaleDB的实现都分别参考了SQLite和PostgreSQL的代码，但都是源代码级别的引用和hack，而非运行时依赖，因此它们从技术角度看依然是一个全新的存储引擎。当然这两者也因此存在一些共性的问题，比如固定Schema，数据压缩比不足够好等。
除此三代以外还有一个特殊的时序数据库群体，它们产于上代MES软件的存储部分，一般情况下，它们采用.Net FrameWork，一般称自己为实时数据库或全时数据库。面向的场景类似，但一般都锁定x86架构/Windows平台，移植性很差，一般都不支持Linux，很难迁移到ARM架构上。
云厂商
AWS Timestream
Amazon在AWS re-Invent大会发布Timestream预览版。适用于 IoT 和运营应用程序等场景。提供自适应查询处理引擎快速地分析数据，自动对数据进行汇总、保留、分层和压缩处理。按照写入流量，存储空间，查询数据量的方式计费，以serverless的形式做到最低成本管理。
Azure Series Insights
微软发布时序见解预览版，提供的完全托管、端到端的存储和查询高度情景化loT时序数据解决方案。强大的可视化效果用于基于资产的数据见解和丰富的交互式临时数据分析。针对数据类型分为暖数据分析和原始数据分析，按照存储空间和查询量分别计费。
国内的云厂商方案大都参考了InfluxDB的社区版，这里就不再单独讨论。
无论是软件服务或者是云服务，更高的查询性能，更快的写入速度，更方便低成本的运维，人人想要。一旦业务规模上来，各方面的需求都应该且会被考虑到，却并不可能都被满足。做工程本质上还是不断地做Trade Off。如何取舍还是要在实际生产应用中去选择，去调整。
