为什么要构建时间序列数据平台？

作者：Paul Dix / 产品, 开发者
2017 年 7 月 20 日

请注意：此博客最初发布在 DB-Engines 上，可以在此处找到。

在大数据炒作周期的中期，在物联网成为每个人最热门的话题之前，在云原生成为常用语之前，以及在大型企业开始着手消除其基础设施监控和指标数据孤岛之前，InfluxData 的创始人 Paul Dix 开始构建一个专用的时间序列平台。快进到今天，时间序列现在是 增长最快的数据库细分市场，并且市场显然正在超越当时定义该细分市场的重新利用的 Cassandra 和 Hbase 实现。以下帖子是 Paul Dix 对他亲眼目睹的问题以及他为何构建现代时间序列平台的第一手描述。

我经常被问到：“为什么要专门为时间序列构建数据库？” 其含义是，通用的 SQL 数据库可以通过按时间列排序来充当 TSDB。或者您可以构建在 Cassandra 等分布式数据库之上。虽然可以使用这些解决方案来解决时间序列问题，但它们非常耗时并且需要大量的开发工作。我与其他工程师交谈以了解他们所做的事情，并发现有一组常见的任务导致了对通用时间序列平台的需求。每个人似乎都在重复发明轮子，因此看起来市场上存在专门为时间序列构建的产品空白。

在这篇文章中，我将定义时间序列问题，阐述时间序列与其他用例和数据库工作负载的区别，并回顾我所见过的处理时间序列数据独特要求的其他方法。最后，我将探讨专门为时间序列构建的优势。

定义时间序列问题

让我们首先定义时间序列数据，然后看看在转向时间序列平台之前其他人是如何尝试解决这个问题的。

当我提到时间序列数据时，我想到了两种不同类型的时间序列：规则的和不规则的。

• 规则时间序列对于 DevOps 或指标领域的开发人员来说很熟悉。这些只是以固定的时间间隔（例如每 10 秒）进行的测量。这在传感器数据用例中也很常见，例如以规则的时间间隔从传感器读取数据。关于规则时间序列的重要之处在于，它们代表了某些底层原始事件流或分布的摘要。当查找模式或可视化事件多于您要绘制的像素的数据集时，摘要非常有用。
• 第二种类型的时间序列，不规则，对应于离散事件。这些可能是对 API 的请求、股票市场中的交易，或者您想要随时间跟踪的任何类型的事件。可以从不规则的时间序列中导出规则的时间序列。例如，如果您想计算 API 在 1 分钟间隔内的平均响应时间，您可以聚合各个请求以生成规则的时间序列。

我相信现代 TSDB 需要能够处理规则和不规则的事件和指标。

时间序列的另一部分是，通常会有描述序列的元数据，用户可能希望稍后在其中进行查询。这可以是主机名、应用程序、区域、传感器 ID、建筑物、股票名称、投资组合名称或可能需要在其上查询时间序列的任何维度。将元数据添加到时间序列允许您对它们进行切片和切块，并创建跨不同维度的摘要。这意味着一个系列是描述它的元数据以及有序的时间、值对元组。元数据表示为测量名称、标签键/值对和字段名称。

时间序列应用和规模

现在我们已经定义了什么是时间序列，让我们深入探讨是什么使它们与其他数据库用例和工作负载不同。

1. 时间序列数据需要专注于快速摄取。也就是说，您始终在插入新数据。最常见的是追加操作，您只添加最近的时间序列数据——尽管用户有时确实需要历史回填，并且在传感器数据用例中，我们经常看到滞后的数据收集。即使是后者，您通常也是将最近的数据追加到每个单独的系列中。
2. 高精度数据会保留一小段时间，而摘要数据的较长保留期则采用中精度或低精度。考虑这一点的一种方法是原始高精度样本以及 5 分钟和 1 小时间隔的摘要。在操作上，这意味着您必须不断地从数据库中删除数据。高精度数据驻留在一个短窗口内，然后应该被逐出。这与普通数据库设计用于处理的工作负载非常不同。
3. 代理或数据库本身必须不断地从高精度数据中计算摘要，以用于长期存储。这些可以是简单的聚合，如 first、last、min、max、sum、count，或者可以包括更复杂的计算，如百分位数或直方图。
4. 时间序列的查询模式可能与其他数据库工作负载大相径庭。在大多数情况下，查询将提取请求时间范围内的数据范围。对于可以动态计算聚合和下采样的数据库，它们通常会遍历许多记录以拉回查询的结果集。快速迭代许多记录以计算聚合对于时间序列用例至关重要。

• 服务器和应用程序监控
• 实时分析
• 物联网传感器数据监控和控制

每个应用程序的数据都不同，但它们通常采用相同的通用形状。在服务器监控案例中，我们正在进行定期测量，以跟踪 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）中来处理时间序列。通常，他们发现这种方法在一段时间内有效，但随着数据规模的增加，事情开始崩溃。如果我们采用之前的服务器监控示例，有几种方法可以构建，但存在一些挑战。

然后是扩展超出单个 SQL 服务器可以处理的范围的问题。将时间序列的片段分片到不同的服务器是一种常见的技术，但需要更多的应用程序级代码来处理它。

结论：关系技术并非旨在解决特定的时间序列问题，并且尝试让它们解决这些问题是不切实际的。

构建在分布式数据库之上

在最初使用更标准的关联数据库之后，许多人会考虑使用 Cassandra 或 HBase 等分布式数据库。与 SQL 变体一样，在 Cassandra 之上构建时间序列解决方案需要相当多的应用程序级代码。

首先，您需要决定如何构建数据。Cassandra 中的行存储到一个复制组，这意味着您需要考虑如何构建行键，以确保集群得到正确利用，而不会为写入和读取创建热点。然后，一旦您决定了如何排列数据，您就需要编写应用程序逻辑来为时间序列用例进行额外的查询处理。您最终还需要编写下采样逻辑来处理创建可用于长期可视化的低精度样本。最后，一旦您连接了基础知识，确保在查询许多时间序列和计算跨不同维度的聚合时获得所需的查询性能将是一项持续的苦差事。

结论：编写所有这些应用程序代码通常是一个需要有能力的后端工程师参与的数月项目。

专门为时间序列构建的优势

这使我们回到了这篇文章的重点：为什么要构建时间序列数据平台？

开发人员的幸福感

我们在创建时间序列平台时设想的目标之一是优化用户或开发人员实现价值的时间。也就是说，他们越快解决问题并启动并运行，体验就越好。这意味着，如果我们看到用户经常编写代码或创建项目来解决相同的问题，我们将尝试将其拉入我们的平台或数据库。开发人员解决问题所需编写的代码越少，他们完成的速度就越快。

时间很特殊

除了明显的可用性目标外，我们还看到我们可以围绕时间序列的一些特性优化数据库。它是仅插入的，我们需要聚合和下采样，我们需要在用户想要释放空间的情况下自动逐出高精度数据。我们还可以构建针对时间序列数据优化的压缩。我们还以一种可以索引标签数据以实现高效查询的方式组织数据。在数据库级别，我们可以进行许多优化。

超越数据库以简化开发

专门为时间序列构建的另一个优势是我们可以超越数据库。我们发现大多数用户都会遇到一组需要解决的常见问题——如何收集数据、如何存储数据、如何处理和监控数据以及如何可视化数据。

我们还发现，拥有一个通用的 API 使社区更容易围绕我们的堆栈构建解决方案。我们有用于表示时间序列数据的行协议、用于写入和查询的 HTTP API 以及用于处理的 Kapacitor。这意味着随着时间的推移，我们可以为最常见的用例提供预构建的组件。

我们发现，我们可以获得比更通用的数据库更好的性能，同时还可以将开发人员启动解决方案的工作量减少至少一个数量级。在 Cassandra 或 MySQL 上可能需要数月才能运行的操作，使用我们的堆栈可能只需一个下午。而这正是我们试图实现的。

通过专注于时间序列，我们可以为应用程序开发人员解决问题，以便他们可以专注于在其应用程序内部创建独特价值的代码。

关于作者：

Paul 是 InfluxDB 的创建者。他曾帮助初创公司、大型公司和 Microsoft、Google、McAfee、Thomson Reuters 和空军航天司令部等组织构建软件。他是 Addison Wesley 的数据与分析图书和视频系列的系列编辑。2010 年，Paul 为 Addison Wesley 撰写了《Service Oriented Design with Ruby and Rails》一书。2009 年，他创立了纽约市机器学习聚会，现在拥有超过 10,000 名成员。Paul 拥有哥伦比亚大学计算机科学学位。

下一步是什么？

• 阅读InfluxDB 与其他时间序列数据库的比较。
• 了解 InfluxData 如何成为现代时间序列平台
• 了解现代时间序列的价值