专用时间序列数据库（TSDB）的想法并不新鲜。回顾该领域的历史，1999年问世的RRDTOOL可能是第一次序列数据库。但是，直到2015年，时间序列数据库才开始流行，但是在过去的几年中，时间序列数据库已成为最快的趋势数据库管理系统之一。

在2016年底，我看到信息技术的新时代已经开始。一切都建立了联系：从家用电器到工业设备，一切都变得聪明，并产生了大量数据。不仅是任何数据，还包括时间序列数据。我很快意识到，来自这些智能传感器和设备的时间序列数据的有效处理将成为技术发展的重要组成部分，因此我于2017年6月开始开发Tdengine，这是一个新的时间序列数据库系统。

当我在2017年首次启动Tdengine时，我的主要关注点是市场是否还有其他时间序列数据库的空间。我一直在思考现有数据库是否足够出色，可以运行时间序列应用程序，以及它们是否已经满足了业务需求。即使在今天，这仍然是我一直在想的事情，问自己：这个时代序列数据库真的值得我奉献和痴迷吗？

现在让我根据技术分析与您分享我的结论。我将介绍一个时间序列数据的关键要素：

可伸缩性

由于IT基础架构的扩展和物联网（IoT）的出现，数据的规模迅速增长。现代数据中心可能需要收集多达1亿个指标。作为另一个例子，每个分布式电网中的每个智能电表每分钟至少产生一个数据点，在美国，有超过1.029亿个智能电表。单台计算机不可能处理这些大量数据，因此任何用于处理时间序列数据的系统都必须是可扩展的。

但是，许多市场领先的时间序列数据库没有提供可扩展的解决方案。 Prometheus是Kubernetes环境的事实上的标准时间序列数据库，没有分布式设计，并且必须依靠皮层，Thanos或其他第三方工具来进行可伸缩。 InfluxDB仅向企业客户提供聚类，而不是作为开源软件。

为了解决这个问题，许多开发人员通过在其应用程序和TSDB服务器（例如InfluxDB或Prometheus）之间部署代理服务器来构建自己的可扩展解决方案。然后，根据时间序列ID的哈希，将收集的时间序列数据分为多个TSDB服务器。

出于数据摄入目的，这确实解决了可扩展性的问题。但与此同时，代理服务器必须合并每个基础节点的查询结果，从而提出了一个重大的技术挑战。对于某些查询，例如标准偏差，您可以合并结果 - 您必须从每个节点中检索原始数据。这意味着您需要重写整个查询引擎，这使得大量开发工作。

对流入室和时间标度的设计的仔细检查表明，它们的可伸缩性实际上是非常有限的。他们将元数据存储在中央位置，每个时间序列始终与一组标签或标签相关联。这意味着，如果您有十亿个时间序列，则系统需要存储十亿个标签。

您可能可以看到这里的问题：当您汇总多个时间序列时，系统需要确定哪个时间序列首先满足标签过滤条件，在大型数据集中，这会导致大量延迟。这被称为时间序列数据库的高心电性问题。我们如何解决这个问题？答案是用于元数据处理的分布式设计。元数据不能存储在中心位置，也不能迅速成为瓶颈。一种简单的解决方案是将分布式关系数据库用于元数据，但这使系统变得复杂，更难维护且更昂贵。

tdengine 1.x设计为将所有元数据存储在管理节点上，因此它也具有高基数。我们在TDENGINE 2.X的时间序列数据库体系结构中进行了一些改进，在每个虚拟节点而不是中央管理节点上存储标签值，但是为重新启动系统所花费的新时间序列和时间的创建仍然是主要的瓶颈。凭借新发布的Tdengine 3.0，我们终于能够完全解决高基数。

复杂

数据库是存储和分析数据的工具。但是时间序列数据处理不仅需要存储和分析。在典型的时间序列数据处理平台中，TSDB始终与流处理，缓存，数据订阅和其他工具集成。

流处理

时间序列数据是流。为了更快地了解操作或在更少的时间内检测错误，必须在系统到达系统后立即分析数据点。因此，流处理是时间序列数据的自然拟合。流处理可以是时间驱动的，以设定的间隔（称为连续查询）或数据驱动产生新的结果，每当有新的数据点到达时，都会产生新的结果。

infuxdb，Prometheus，TimeScaledB和Tdengine都支持连续查询。这对于监视仪表板非常有用，因为可以定期更新所有图表和图表。但是，并非所有数据处理要求 - 例如，可以单独查询可以满足ETL，并且时间序列数据库需要支持事件驱动的流处理。

在TDENGINE 3.0之前，市场上没有时间序列数据库对事件驱动的流处理进行开箱即用的支持。取而代之的是，时间序列数据平台与Spark，Flink或其他未用于时间序列数据设计的流程处理工具集成在一起。这些工具很难在时间序列数据集中处理数百万甚至数十亿个流，即使它们符合任务，它也以大量计算资源的价格产生。

缓存

对于许多时间序列数据应用程序，例如应用程序性能监视，特定时间的数据值并不重要。这些应用仅集中在趋势上。但是，物联网方案是一个显着且重要的例外。例如，车队管理系统总是想知道每辆卡车的当前位置。对于智能工厂，系统始终需要了解每个阀门的当前状态和每个仪表的当前读数。

大多数时间序列数据库，包括InfluxDB，TimeScaledB和Prometheus，无法自行保证可以以最小的延迟返回时间序列的最新数据点。为了使每个时间序列的当前值在没有高潜伏期的情况下返回，这些数据平台与Redis集成在一起。当新数据点到达系统时，必须将它们写入REDIS以及数据库中。尽管该解决方案确实有效，但它增加了系统的复杂性和操作成本。

另一方面，

tdengine从首次版本开始支持缓存。在许多用例中，REDIS可以完全从系统中删除，使整个数据平台运行更简单，更便宜。

数据订阅

消息队列在许多系统体系结构中起着重要作用。传入的数据点首先将其写入消息队列，然后由系统中的其他组件（包括数据库）消耗。消息队列中的数据通常保留在指定的时间段内（例如，在卡夫卡（Kafka）为7天）。这与时间序列数据库中的保留政策相同。

大多数时间序列数据库非常有效地摄入数据，每秒多达数百万个数据点。这意味着，如果时间序列数据库可以提供数据订阅功能，它们可以完全替换消息队列，再次简化系统设计并降低成本。

在时间序列数据库中，传入的数据点存储在仅附录模式下的写入日志中。一旦存储器中的数据持续到数据库，该WAL文件通常会删除，并且在系统崩溃时仅用于恢复数据。但是，如果我们不自动删除WAL文件，但请将其保留在指定的期限中，则WAL文件可以成为持续的消息队列并被其他应用程序消费。

通过WAL文件提供数据订阅具有另一个很大的好处：它可以对数据订阅进行过滤。系统可以通过仅通过满足过滤条件的数据点来节省资源。

当今可用的所有时间序列数据库中，Tdengine是唯一具有数据订阅的数据库。使用Tdengine 3.0，我们现在能够提供可比的性能和与Kafka相同的API集。

概括

虽然时间序列数据库仍然没有事件驱动的流处理，缓存和数据订阅，但开发人员被迫将其TSDB与其他工具集成在一起，以实现所需的功能。这使系统设计过于复杂，需要更多的资源，并且很难维护。这些功能在时间序列数据库内构建后，整体系统体系结构被简化并大大降低了操作成本。

云本地

云计算最美丽的事情是其弹性 - 存储和计算资源本质上是无限的，您只为所需的费用付费。这是所有应用程序（包括时间序列数据库）都转移到云的主要原因之一。

不幸的是，大多数数据库只是云的准备就绪，而不是云本地。当您购买某些数据库供应商提供的云服务（例如TimeScaledB）时，您需要告诉系统多少虚拟服务器（包括CPU和内存配置）以及您想要多少千兆字节的存储空间。即使您没有进行任何查询，您仍然被迫为计算资源付费，并且数据规模增长，您也需要决定是否购买更多资源。通过提供这种云解决方案，数据库服务提供商实际上只是转售云平台。

要充分利用云平台提供的好处，时间序列数据库必须是云本地。为了实现这一目标，需要重新设计以下三点：

• 计算和存储的分离：在容器化的环境中，特定的容器可能随时向上或向下，但是存储的数据持续存在。传统的时间序列数据库体系结构无法应付，因为它在本地存储数据。
  此外，要运行复杂的查询或批处理处理，需要动态添加更多的计算节点以加快过程。

• 弹性：系统必须能够根据工作负载和延迟要求调整存储和计算资源。对于计算资源，这不是系统做出的艰难决定。但是存储资源是另一个故事。要向上或向下缩放分布式数据库，必须在实时数据到来或正在运行查询时合并或拆分其碎片。设计一个可以实现这一目标的系统并非易事。

• 可观察性：必须与系统的其他组件一起监视时间序列数据库的状态，因此，一个好的数据库需要提供完整的可观察性，以使操作和管理更简单。

此时，任何新开发的时间序列数据库设计都必须是云本地。虽然Tdengine的设计从第一天开始具有高度可扩展的分布式体系结构，但从3.0版开始，我们现在完全支持计算和存储的分离。

使用方便

虽然易用性是一个主观的术语，但我们可以尝试在这里列出一些标准，以获取更易于用户友好的时间序列数据库：

• 查询语言：由于SQL仍然是最受欢迎的数据库查询语言，因此SQL支持基本上消除了开发人员的学习曲线。另一方面，专有的查询语言要求开发人员使用其宝贵的时间来学习它们，并增加对其他数据库或从其他数据库的迁移成本。在Tdengine中，您可以在几乎没有更改的情况下重复使用现有的SQL查询，并且由于Tdengine的增强，甚至可以简化一些查询。

• 交互式控制台：交互式控制台是开发人员管理运行数据库或运行临时查询的最方便方法。即使在云中部署了时间序列数据库，这仍然是正确的。

• 示例代码：开发人员没有时间阅读整个文档集，只是为了学习如何使用某个功能或API。新的数据库系统必须为主要编程语言提供示例代码，开发人员可以简单地将其复制并粘贴到其应用程序中。

• 数据迁移工具：数据库管理系统需要提供方便有效的工具，以将数据输入和流出数据库。源和目标可以是远程数据中心中的文件，另一个数据库或副本，并且传输的数据可以是整个数据库，一组表或时间范围内的数据点。

是一个新的时间序列数据库的时间

考虑到以上四个主要因素，我于2017年从头开始开发一个新的时间序列数据库。经过许多迭代，Tdengine团队和我很荣幸现在已于2022年8月23日发布Tdengine 3.0。

tdengine 3.0是一个从第一天开始设计的全面，专门构建的平台，以满足下一代时间序列应用程序的需求。它具有真正的云本地时间序列数据库设计，其中计算和存储资源都分开，并且可以根据工作负载动态更改。它可以部署在公共，私人或混合云中。它的可伸缩性是前所未有的，它可以支持十亿个时间序列，同时在数据摄入率和查询延迟方面仍然超过其他时间序列数据库。

此外，TDENGINE 3.0通过其内置的缓存，流处理（事件和时间驱动）和数据订阅功能来简化系统体系结构并降低运营成本。不再需要集成多个第三方组件才能拥有时间序列数据处理所需的功能。

最重要的是，TDENGINE 3.0可帮助您深入了解与关系数据库相当的分析功能的时间序列数据，并支持标准SQL语法，并具有特定时间序列的特定扩展。

自2017年推出Tdengine以来，从1.0到2.0到3.0，它已被许多企业客户和社区用户高度认可。自从2019年7月开放源头以来，它已经在Github上聚集了20,000多颗星，并迅速在DB-Engines的时间序列数据库排名中迅速上升。

tdengine 3.0不是时间序列数据库的故事的结尾，但我们认为它可以解决当今领域的所有主要问题。如果您有兴趣自己免费尝试，则可以download the installation package或在我们的GitHub repository上查看源代码。作为开发人员，我将感谢您可能需要进一步改进产品的任何评论，反馈甚至贡献。