时序数据是一系列带有时间戳的数据组成的序列，比如
１. 单个股票在一个时间范围内的价格
２. 某个地点在一段时间范围内的温度变化
３. 某个传感器在一段时间范围内的参数变化
等等
实际上，随着传感器的价格越来越便宜，网络的普及、智能网关和云端应用的出现，人类控制，监控物理世界的能力越来越强，越来越多的设备、传感器接入网络，从而这些设备和传感器的信息越来越容易拿到。
根据 DB-Engines的统计， Time Series DBMS是发展最为迅猛的DBMS，这也证实上上述推断：物理世界中的物体将越来越多，并且连接网络。
时序数据的特点
- 从数据量上考虑
物联网传感器首先是分布式的，然后数量还特别大，再加上采集频率通常在1s之内，所以对时序数据库的吞吐量有极高的要求
- 从查询方式上来说
查询绝大部分和时间维度有关系，也就是说查询语句里面必然有一个where time条件或者group by time range条件；
极少会出现select * 这种查询。
查询方式有：
- 查询单个序列特定时间窗口之内的数据
- 查询单个序列的单个数据点
- 查询1w个序列的单个数据点
- 查询1w个序列的特定时间窗口之内的所有数据
使用方式上考虑
单点不成线，孤木不成林，通常来说单个点必须和前后的点联系起来才具有价值，单个点不具备明显价值；也就是说删除单个点和修改单个点是极低频操作。从数据价值考虑
通常来说，数据的实时价值会随着时间的推移逐渐降低, 24小时过后，99%的时序数据不会再被查询到。
时序数据库设计的要点
- 必须支持batch写入
我们知道时序数据有高并发的特点，假设单个数据点大小为16Byte，在不支持batch写入的情况下，每次写入数据点机械磁盘都必须寻道并做数据传输，ssd可以有效支持随机写，但是ssd的随机读写的最小单位是4KiB，每个16Byte的数据都会触发一次4KiB的写，写被放大了；
除此之外，在这种场景下，ssd的寿命就非常有限了。
查询必须考虑低延迟
支持数据删除（retention）
时序数据库特别之处不仅在于其数据的存储方式，同样在于和数据的交互方式。
性能上面的考虑
高吞吐量，doc数据库和b树数据库是完全不能满足性能要求的，试想一下，10w个传感器每秒上报一个数据点，一个小时的数据点量就高达3.6亿，更别说一些精密仪器的采样时间间隔只有100毫秒，这还只是单方面的存储，如果考虑到查询就更不用提了。
可扩展性
人们经常说，sql数据库的可扩展性不如no sql数据库好，或者换种说法，acid兼容的数据库不如不兼容的数据库可扩展性好，acid兼容的数据库考虑的是怎么样acid，而不兼容的数据库就可以根据自己的需要放弃acid中的一种或者所有特性，比如我们不需要持久性，那么可以直接把数据存储在内存中，时序数据库就是考虑到时序数据的特性在是否支持acid直接进行平衡。
考虑到单个数据点的价值不大，我们就可以损失一部分持久性以换取吞吐性能