为什么构建时间序列数据平台？
作者：Paul Dix / 产品，开发者
2017年7月20日
导航至
请注意：本文最初发布在 DB-Engines，可在此处找到。
在大数据热潮周期的中期，在物联网尚未成为众人热议的话题之前，在 Cloud Native 成为主要术语之前，在大型企业开始着手整合其基础设施监控和指标数据之前，InfluxData 创始人 Paul Dix 开始构建一个专门的时间序列平台。快进到今天，时间序列已成为增长最快的数据库领域，市场显然已超越了定义该领域的重用的 Cassandra 和 Hbase 实现。以下是由 Paul Dix 描述的他对所观察到的问题的分析以及他为什么构建一个现代时间序列平台的原因的第一手资料。
我经常被问到：“为什么专门为时间序列构建数据库？”隐含的意思是，一个通用的 SQL 数据库可以通过对某个时间列进行排序来充当 TSDB。或者可以在像 Cassandra 这样的分布式数据库之上进行构建。虽然使用这些解决方案来解决时间序列问题是有可能的，但它们非常耗时，需要大量的开发工作。我与其他工程师交谈，看看他们都做了什么，并发现有一组共同的任务导致了对通用时间序列平台的需求。似乎每个人都正在重新发明轮子，因此看起来市场上缺乏专门针对时间序列构建的东西。
在这篇文章中，我将定义时间序列问题，阐述时间序列与其他用例和数据库工作负载的不同之处，并查看我看到的处理时间序列数据独特要求的其他方法。最后，我将探讨专门针对时间序列构建的优势。
定义时间序列问题
首先，我们来定义时间序列数据，然后看看在转向时间序列平台之前，其他人如何尝试解决这个问题。
当我提到时间序列数据时，我想到了两种不同类型的时间序列：规则和不规则。
- 规则时间序列对 DevOps 或指标空间的开发者来说很熟悉。这些是在固定时间间隔内进行的测量，比如每10秒一次。这在传感器数据用例中也很常见，比如从传感器定期读取读数。规则时间序列的重要之处在于，它们代表了一些底层原始事件流或分布的汇总。汇总在寻找模式或可视化事件数量超过您绘制像素的数据集时非常有用。
- 时间序列的第二种类型是不规则的，对应于离散事件。这可能是对API的请求、股市交易，或者任何你想在时间上追踪的事件。可以从不规则的时间序列中推断出规则的时间序列。例如，如果你想计算API在1分钟间隔的平均响应时间，你可以聚合单个请求以生成规则的时间序列。
我相信，现代的时间序列数据库需要能够处理规则和不规则的事件和指标。
时间序列的另一个特点是通常会有元数据来描述用户可能想要查询的序列。这可能包括主机名、应用程序、地区、传感器ID、建筑、股票名称、投资组合名称或任何可能用于查询时间序列的维度。将元数据添加到时间序列中允许你根据不同的维度进行切片和切块，并创建汇总。这意味着序列是描述它的元数据和有序的时间、值对元组。元数据表示为测量名称、标签键/值对和字段名称。
时间序列应用与规模
既然我们已经定义了时间序列是什么，让我们深入了解它们与其他数据库用例和工作负载的不同之处。
- 时间序列数据需要关注快速摄取。 也就是说，你总是在插入新数据。大多数情况下，这些是追加操作，你只添加最近的时间序列数据——尽管用户有时需要历史回填，在传感器数据用例中，我们经常看到延迟的数据收集。即使在这种情况下，你也通常将最近的数据追加到每个单独的序列中。
- 高精度数据保留一段时间，而中低精度数据的保留期更长。 一种思考方式是5分钟和1小时间隔的原始高精度样本和汇总。从操作上讲，这意味着你必须不断地从数据库中删除数据。高精度数据在短时间内驻留，然后应该被移除。这与普通数据库设计的处理工作负载非常不同。
- 代理或数据库本身必须从高精度数据中持续计算用于长期存储的汇总。 这些可能是简单的聚合，如第一个、最后一个、最小值、最大值、总和、计数，也可能包括更复杂的计算，如百分位数或直方图。
- 时间序列的查询模式可能与其他数据库工作负载截然不同。 在大多数情况下，查询将拉取请求时间范围内的数据范围。对于可以即时计算聚合和下采样的数据库，它们将频繁地处理许多记录以获取查询的结果集。对于时间序列用例，快速迭代许多记录以计算聚合是至关重要的。
- 服务器和应用程序监控
- 实时分析
- IoT传感器数据监控和控制
这些数据各有不同，但它们通常具有相同的总体形状。在服务器监控的情况下，我们进行定期的测量以跟踪CPU、硬盘、网络和内存利用率。通常还会测量第三方服务，如Apache、Redis、NGINX、MySQL等。序列通常包含元数据信息，如服务器名称、区域、服务名称和测量的指标。每个服务器有200个或更多测量（唯一序列）并不罕见。让我们大致了解一下一天的DevOps数据集。假设我们有100台服务器，每台服务器收集200个独特的测量值。这意味着我们有20,000个独特的序列。进一步说，假设我们每10秒收集一次数据。这意味着在一天之内，我们每个序列收集了86,400 / 10 = 8,640个值，总共是20,000 * 8,640 = 172,800,000个值。
使用SQL数据库进行时间序列的问题
许多用户最初通过将数据存储在常见的SQL RDBMS中，如PostgreSQL或MySQL，来处理时间序列。通常，他们发现这在一开始是有效的，但随着数据规模的增加，问题开始出现。如果我们以之前的服务器监控为例，有几种结构方式，但也有一些挑战。
| 结构选项 | 挑战 | 结论 |
|---|---|---|
| 创建一个表来存储所有信息，包括序列名称、值和时间。 | 如果想要搜索除特定名称以外的任何内容（如服务器、指标、服务等），则需要单独的查找索引。这种原始实现将有一个每天增加172M条新记录的表。这会迅速导致问题，因为表的体积太大。 | 对于时间序列，通常数据精度很高，但只保留很短的时间。这意味着不久你将进行与插入一样多的删除操作，这不是传统数据库设计得很好的处理方式。 |
| 每天或某个其他时间段创建一个单独的表。 | 需要开发人员编写应用程序代码来连接不同表中的数据。 | 必须编写更多代码来计算低精度数据的摘要统计信息，并定期删除旧表。 |
然后还有单台SQL服务器无法处理的问题。将时间序列的不同部分片段化到不同的服务器上是一种常见技术，但它需要更多应用程序级别的代码来处理。
结论：关系型技术并非专为解决特定的时间序列问题而设计，试图让它们解决这个问题是不切实际的。
基于分布式数据库构建
最初使用更标准的SQL数据库后，许多人会考虑分布式数据库，如Cassandra或HBase。与SQL变体一样，在Cassandra上构建时间序列解决方案需要相当多的应用程序级别的代码。
首先，您需要决定如何结构化数据。Cassandra中的行存储到一组副本中，这意味着您需要考虑如何结构化行键，以确保集群得到充分利用，同时避免在读写操作中产生热点。然后，一旦您确定了数据的排列方式，您就需要编写应用程序逻辑来对时间序列用例进行额外的查询处理。您还需要编写降采样逻辑，以处理创建可用于长期可视化的低精度样本。最后，一旦您搭建好基础，确保在查询多个时间序列和跨不同维度计算聚合时获得所需的查询性能将是一项持续的任务。
结论： 编写所有这些应用程序代码通常是一个需要具备能力的后端工程师的数月项目。
专门为时间序列构建的优势
这又把我们带回到本文的目的：为什么构建时间序列数据平台？
开发者满意度
在我们构想时间序列平台时，我们设定的一个目标就是优化用户的或开发者的时间价值。也就是说，他们解决问题的速度越快，他们就能更快地上线和运行，体验就会越好。这意味着，如果我们发现用户经常编写代码或创建项目来解决相同的问题，我们将尝试将其纳入我们的平台或数据库。开发者需要编写的代码越少，他们完成的速度就越快。
时间独特
除了明显的可用性目标外，我们还看到我们可以围绕时间序列的一些独特性来优化数据库。它是只插入的，我们需要聚合和降采样，当用户想要释放空间时，我们需要自动清除高精度数据。我们还可以构建针对时间序列数据优化的压缩。我们还以能够高效查询的方式组织了数据。在数据库级别，我们有许多可以进行的优化。
超越数据库以简化开发
专门为时间序列构建的另一个优势是，我们可以超越数据库。我们发现，大多数用户都会遇到一组需要解决的问题——如何收集数据、如何存储数据、如何处理和监控数据，以及如何可视化数据。
我们还发现，拥有一个共同的API使得社区更容易围绕我们的堆栈构建解决方案。我们有行协议来表示时间序列数据，我们的HTTP API用于写入和查询，以及Kapacitor用于处理。这意味着随着时间的推移，我们可以为最常见的用例提供预构建的组件。
我们发现，与更通用的数据库相比，我们可以获得更好的性能，同时将开发人员解决一个解决方案所需的工作量减少至少一个数量级。在我们的堆栈上，可能需要几个月才能在Cassandra或MySQL上运行的操作可能只需要一个下午。这正是我们努力实现的目标。
通过专注于时间序列，我们可以解决应用开发者的问题，使他们能够专注于在其应用程序中创建独特价值的代码。
作者简介：  |
保罗是InfluxDB的创始人。他帮助为初创公司、大型公司和像微软、谷歌、迈克菲、汤姆森路透和空军太空司令部这样的组织构建软件。他是Addison Wesley数据与分析书籍和视频系列的系列编辑。2010年，保罗为Addison Wesley写了《基于Ruby和Rails的服务导向设计》一书。2009年，他创立了纽约市机器学习聚会，现在已有超过10,000名成员。保罗在哥伦比亚大学获得了计算机科学学位。 |
