我们这样定义时间序列数据：统一表示系统、过程或行为随时间变化的数据。试想一下：Tesla 自动驾驶、华尔街自动交易算法、智能家居、能够实现日内闪电般运抵的交通网络和纽约市警察局发布的开放数据，它们都有哪些共同点？
一方面，它们预示着我们的世界正以曲速般变化，我们捕获和解析的数据比以往更多，速度比以往更快。
但是，如果仔细观察你会发现，这些应用程序都需要一种特殊的数据：
自动驾驶汽车持续收集所处环境中的变化数据
自动交易算法持续收集市场的变化数据
智能家居系统持续监控房屋内的变化，调整温度，识别侵入者，对于使用者总是有求必应（“Alexa，播放一些轻松的音乐”）。
零售行业精确高效地监控资产运转状况，使得日内运抵的成本足够低廉且能够为绝大多数人所使用。
纽约警察局通过跟踪车辆来更好地履行其职责（例如，分析 911 报警电话的响应次数）
这些应用程序均依赖一种衡量事物随时间的变化的数据形式，这里的时间不只是一个度量标准，而是一个坐标的主坐标轴。
这就是时间序列数据，它渐渐在我们的世界中发挥更大的作用。
软件开发人员的使用模式早已反映了这一点，在过去的 24 个月中，时间序列数据库（TSDB）已经成为增长最快的类别：
数据来源：DB-Engines，2017 年 6 月. https://db-engines.com/en/ranking_categories
我们开发了一款新的开源时间序列数据库，经常有人问 TSDB 的趋势如何，他们通常会问以下三个问题：
起初，这些材料是为我们在 4 月份开源数据库大会 Percona Live 中的演讲而准备的，现在我们将其发布在本文中，并在深思熟虑后尝试具体回答一下这些问题，并尽可能分享给更多的人。
那么我们开始吧。
有些人将“时间序列数据”视为按时间顺序存储的一连串随时间推移测量相同事物的数据点，这样解释没错，但只描述了浅层信息。
其他人可能会认为是一连串与时间戳配对的数值，这些数值由一个名称和一组归类维度（或称“标签”）所定义。这也许是一种为时间序列数据建模的方式，却不是数据自身的定义。
我们继续深入。
以下是一个基础示例，设想这个传感器从三个环境中收集数据：分别是城市、农场和工厂。在这里，每一个数据源定期发送新的读数，创建一系列随时间推移收集到的测量结果。
接下来是另一个示例，这是一份纽约市的实际数据，这些数据展示了 2016 年前几秒出租车的乘坐情况。正如你所见，每一行都是在特定时间收集的“测量结果”。
2016 年前几秒纽约出租车乘坐数据。数据源：http://www.nyc.gov/html/tlc/html/about/trip_record_data.shtml
还有许多其他类型的时间序列数据，例如：DevOps 监控数据、移动 /Web 应用程序事件流、工业机器数据、科学测量结果。
这些数据集主要有以下三个共同点：
换句话说，时间序列数据的处理过程通常是伴随数据的抵达而进行的。虽然在事后需要纠正错误的数据，或处理延迟数据或无序数据，但这些都是例外情况，不属于标准范畴。
你可能会问：这与在数据库中添加字段有何区别？
那么，这取决于：你的数据集如何跟踪变化？是更新当前条目，还是插入新的条目？
当你为 sensor_x 收集新读数时，是覆盖以往的读数，还是在新的一行创建全新的读数？尽管这两种方法都能为你提供系统的当前状态，但只有第二种方法才能跟踪系统的所有状态。
简而言之：时间序列数据集跟踪整个系统的改动并不断插入新数据，而不是更新原有数据。
时间序列数据之所以如此强大，是因为将系统的每个变化都记录为新的一行，从而可以去衡量变化：分析过去的变化，监测现在的变化，以及预测未来将如何变化。
因此，我们这样定义时间序列数据：统一表示系统、过程或行为随时间变化的数据。
这不仅是一个学术上的区别：通过围绕“变化”的定义，我们可以开始找出当下我们应该收集却没有收集的时间序列数据集。
事实上，我们发现人们早已坐拥时间序列数据，但他们却没意识到这一点。
假设你正在维护一个 Web 应用程序，每次用户登录时，你可以在“users”表的某行中更新用户的“last_login”时间戳，但是如果将每次登录作为一个单独的事件处理，并随着时间推移收集这些数据又会有怎样的效果？届时你可以：跟踪历史登录活动，了解随时间推移用户使用的增减情况，根据访问 App 的频率或更多指标区分用户。
这个示例说明了一个关键点：通过保留数据固有的时间序列性质，我们能够保留有关数据随时间变化的有用信息。
（事实上，这个示例还说明了另一点：事件数据同样也是时间序列数据）
当然，按照这种方式存储数据会带来一个明显的问题：最终你会以相当快的速度得到大量的数据，时间序列数据很快会堆积起来。
数据量太大会给记录和查询操作带来严重的性能问题
这也是人们正逐渐转向时间序列数据库的原因。
你可能会问：为什么我不能用一个“常规”（也就是非时间序列）的数据库？
事实上你可以使用非时间序列数据库，也确实有人这样做：
数据源：Percona，2017 年 2 月. https://www.percona.com/blog/2017/02/10/percona-blog-poll-database-engine-using-store-time-series-data/
那么为什么大部分调查对象使用时间序列数据库而不是常规数据库呢？为什么 TSDB 如今成为增长最快的数据库？
有两个原因：（1）规模（2）可用性
规模：时间序列数据累计速度非常快。（例如，一辆联网汽车每小时能收集 25GB 数据。）常规数据库在设计之初并非处理这种规模的数据，关系型数据库处理大数据集的效果非常糟糕；NoSQ 数据库 L 可以很好地处理规模数据，但是让然比不上一个针对时间序列数据微调过的数据库。相比之下，时间序列数据库（可以基于关系型数据库或 NoSQL 数据库）将时间视作一等公民，通过提高效率来处理这种大规模数据，并带来性能的提升，包括：更高的容纳率（Ingest Rates）、更快的大规模查询（尽管有一些比其他数据库支持更多的查询）以及更好的数据压缩。
可用性：TSDB 通常还包括一些共通的对时间序列数据分析的功能和操作：数据保留策略、连续查询、灵活的时间聚合等。即使当下不考虑规模（例如，您刚开始收集数据），这些功能仍可提供更好的用户体验，使你的生活更轻松。
这就是为什么开发人员越来越多地采用时间序列数据库，并将它们用于各种使用场景的原因：
但即使如此，你仍需选择最适合你的数据模型和写入和读取模式的时间序列数据库。
使用（或不使用）TimescaleDB 的理由是什么？
如果你确实需要一个时间序列数据库，已经有相当多的现成选择。你可能对某一个感到满意，但我们并未满足。
为什么我们对最先进的仍不满足？因为我们希望在大规模数据上应用 SQL 的全部能力，现有的数据库无一具备这项能力。
具体来说，我们发现现有的时间序列数据库：
在我们的许多查询试验中表现不佳（解读：高延迟）
甚至都不支持许多其他的查询（因数据库而异）
要求我们学习一门新的查询语言（解读：不是 SQL 语言）
不能与我们现有的大多数工具合用（解读：糟糕的兼容性）
要求我们将数据分为两个数据库：一个“常规”的关系数据库，还有一个时间序列数据库（解读：操作与开发过程极为头痛）
所以我们打造了 TimescaleDB，因为我们需要它。后来其他人也想使用这个数据库，所以今年早些时候我们根据基于 Apache 2 的许可开源。
你何时应该考虑使用 TimescaleDB？如果你想：
一个普通的 SQL 接口，用于时间序列数据，甚至是大规模数据
操作简单：一个数据库同时存放关系型数据和时间序列数据
连接（JOINs） 查询时跨关系型数据和时间序列数据连接
PostgreSQL!（Timescale 的行为表现就像 PostgreSQL 一样）
查询性能，尤其是对于广泛而多样化的查询（通过强大的二级索引支持）
原生支持地理空间数据 （兼容 PostGIS）
第三方工具：Timescale 支持任何使用 SQL 的工具，包括像 Tableau 这样的 BI 工具
同样，如果满足下列条件中的任意一条，你可能不太希望使用 TimescaleDB：
但是，如果 TimescaleDB 看起来很有趣或有用，我们欢迎你进一步了解它，下载并安装，尝试一下。（亦可访问项目的 Github，欢迎 Star。）
