时序数据库 (TSDB) 是一种数据库管理系统，用于存储、处理和分析时间序列数据（以下简称时序数据）。
时序数据是按时间维度顺序记录且索引的数据。像智慧城市、物联网、车联网、工业互联网等领域各种类型的设备和传感器都会产生海量的时序数据，证券市场的行情数据也是时序数据，这些数据将占世界数据总量的 90% 以上。
虽然你也可以使用关系数据库或 NoSQL 数据库来处理时序数据，但这类数据库并没有充分利用时序数据的特点，性能提升极为有限，只能依靠集群技术，投入更多的计算资源和存储资源来处理，系统的运营维护成本急剧上升。而专门构建的时序数据库充分利用了时序数据库的特点，大幅提升了数据的写入和查询速度，同时也大幅提高了数据压缩率。此外，时序数据库包含专有的时序数据分析功能和数据管理功能，使用户可以很轻松地开发应用程序。
时序数据的特点是什么？
- 时间戳：每个数据点都带有时间戳，这个时间戳对于数据的计算和分析十分重要。
- 结构化：与来自网络爬虫、微博、微信的海量数据不同，联网设备或监控系统生成的数据都是结构化的。这些数据都具有预定义的数据类型或固定长度，比如智能电表采集的电流、电压就可以用 4 字节的标准的浮点数来表示。
- 流式：数据源以近似恒定速率生成数据，如音频或视频流。这些数据流彼此独立。
- 流量平稳可预测：与电商平台或社交媒体网站的数据不同，时序数据的流量在一段时间内是稳定的，并且可以根据数据源的数量和采样周期来进行计算和预测。
- 不变性：时序数据一般都是 append-only，类似于日志数据，一般不容许而且也没有修改的必要。很少有场景，需要对采集的原始数据进行修改。
时序数据处理的挑战
时序数据通常用于比较当前数据与历史数据、检测异常、生成实时警报以及预测未来趋势。时序数据解决方案一般考虑以下问题：
- 时序数据量通常很大，因此在执行存储、索引、查询、分析等操作时变得更加困难。
- 时序数据需要实时计算和分析，以便于实时检测异常并告警。 延迟可能会导致故障和业务影响。
- 通常需要关联来自不同传感器和其他源的数据，这使情况变得更复杂。
- 不管是原始数据查询、还是聚合数据查询，时序数据的查询一般都会带上查询时间范围，一方面是根据时间范围计算聚合时间窗口，另一方面是为了更高效的检索数据，提高查询效率，避免大量无效数据的扫描。
- 数据在一段时间内的变化趋势比单个数据点重要得多。例如，考虑到网络不可靠性或传感器读数异常，我们可能会在一段时间内的某个平均值超过阈值时设置警报，而不是在单个数据点上这样做。
TDengine 这类时序数据库，是基于时序数据的特点以及应用的特点进行优化和设计的，专为解决上述问题而生。这类专业的数据库使时序数据的处理变得更加高效，性能也比通用数据库更好。
为什么需要时序数据库
随着物联网和云的出现，时序数据的量开始以前所未有的方式呈指数级增长：1. 连接设备和物联网的兴起，仪表、汽车、电梯、甚至自行车等设备都在源源不断地生成数据；2. IT 基础设施在高速增长，物理服务器、虚拟机、容器、微服务等等都会生成海量时序数据。庞大的时序数据集是关系数据库和 NoSQL 数据库面临的主要挑战，大体分为以下几个方面：
- 时序数据积累得非常快，每秒产生数百万条数据，通用数据库并不是为处理这种规模的数据而设计的。关系数据库在非常大的数据集上表现很差，NoSQL 数据库虽然解决了扩展能力，但是其通用的数据组织方式并不完全适用于对时序数据存储和查询需求，用户必须根据实际应用场景，进行特殊设计甚至大量数据冗余存储才能较好的利用资源处理请求。
- 随着数据量的增加，访问速度越来越慢。同时，大多数通用数据库为了提升查询性能，针对大量数据建立索引，由此消耗大量的系统资源。对于海量的时序数据，通用数据库无法高速加载并满足实时处理需求。
- 设备和应用在 7*24 小时不间断地生成数据——有时一天的数据量就超过 1 TB。关系数据库和 NoSQL 数据库没有针对时序数据的特点来压缩这些数据，因此，存储成本会变得很高。
上述问题主要是处理大数据集的效率问题，但通用数据库往往连时序数据应用的一些基本需求都无法支持：
- 数据生命周期管理：时序数据具有时效性，超过一定时长的数据通常不再具有价值，时序数据一旦老化，就需要对超过保存时长的数据进行批量删除处理，而不是针对单条数据的删除。
- Roll-up：用户定时聚合历史数据保存至新的数据表。原始数据和 rolled-up 的数据可能具有不同的生命周期和保留策略。
- 特殊的分析功能：除了一般数据库提供的功能外，数据库还要针对时序数据的处理进行扩展，提供累计求和、时间加权平均、移动平均、变化率等众多时序数据分析功能。
- 插值：时间序列分布会在一些时间线上，且序列会随着时间的增长往后发展。本质上是在一个固定的时间点记录数据，但如果要检查某个具体时间的设备采集的某个量，而传感器实际采集的时间不是这个时间点，这就要求数据库能够根据相邻的数据点和规则对数据进行插值。
- 连续查询：在时序应用的场景下，对于依照时间推进顺序写入的实时数据，用户有时会希望每隔一段固定时间，就能够按照一定的查询条件对该时间范围内的时序数据做一次计算（例如：对该时间范围内的数据求一次聚合计算），并将计算结果另行保存下来。因此，数据库需要提供连续查询（即一种简化的流计算能力），能够在时间窗口结束后对窗口内的数据进行计算。
- 窗口查询：时序数据常常需要根据采集时间对数据进行查询，本质上是在时间轴上划分出时间窗口，并对窗口内的数据进行聚合和查询计算。在实际生产应用中，业务场景要求的查询条件往往比这个更复杂，需要数据库能够按照不同规则、沿时间轴进行窗口划分，并对各个窗口内的时序数据分别进行聚合、选择计算等操作。
对于通用数据库，研发人员需要投入精力通过编写代码来实现这些功能。不同场景，不同数据量都需要不同的解决方案，极大增加了研发成本。因此，无论数据集的大小如何，使用专门构建的时序数据库都是最好的选择。
为什么时序数据库（TSDB）变得流行？
时序数据库（Time Series Database）并不是一个新兴的概念。追溯其历史，1999 年问世的 RRDtool 应该是最早的专用时序数据库了。在著名的数据库排行网站 DB-engines 上面，时序数据库的逐步流行起始于 2015 年，而在过去的两年，随着物联网的快速增长，时序数据库成为流行度最高的数据库。
越来越多的设备连接到互联网并不断将时序数据发送到云端，越来越多的行业开始对专门构建的时序数据库感兴趣。
从技术上讲，较旧的时序数据解决方案通常是使用过时架构的封闭系统，扩展能力不足，无法支持不断增长的数据量。在过去，一百万个数据点似乎是一个巨大的数字，但现在数百万甚至数十亿个数据点已经不足为奇了。
此外，运营数据往往被锁在封闭的传统系统中，这阻碍了业务的创新和发展，与现代的数据分析工具（如人工智能和机器学习框架）相结合非常困难，数据的价值难以被进一步挖掘。并且，将传统系统迁移到云端或其他现代技术栈中，需要付出巨大成本。
不断增长的市场需求和旧时序数据解决方案的局限性为新一代时序数据库留出了空间。在过去的 10 年里，至少有 20 个新的时序数据库发布，其中开源时序数据库尤其受欢迎。
