作者：陶建辉|TDengine 创始人、外围开发
常常有人问我，为什么 2017 年在市场上曾经有这么多时序数据库的背景之下，你还敢去开发一款新的时序数据库？为什么你的团队都 80 多人了，五年过来，还在埋头研发 TDengine 这一款产品？周末写篇博文，与大家分享一下我的想法。
时序数据库（Time Series Database）并不是一个新兴的概念。追溯其历史，1999 年问世的 RRDtool 应该是最早的专用时序数据库了。在驰名的数据库排行网站 DB-engines 下面，时序数据库的逐渐风行起始于 2015 年，而在过来的两年，时序数据库成为风行度最高的数据库。
过来两年数据库发展趋势榜
2016 年底，我看到万物互联的时代曾经到来，高效解决各种传感器、设施产生的时序数据将成为一重要的技术畛域，因而就着手开发 TDengine 这个新的时序数据库系统，2017 年 6 月正式组建团队。
TDengine 面市以来，从 1.0 到 2.0，从外围性能开源到集群性能开源，失去了大量商业客户和社区用户的高度认可，寰球装置的 TDengine 运行实例数曾经超过 13 万，每天克隆源代码的人次都超过 1000，在寰球开发者社区产生了肯定的影响力。
刚开始守业的时候，我就进行了深刻的思考：新的时序数据库还有生存空间吗？换句话说，现有的这些数据库对利用而言是不是曾经足够好了？它们能满足业务需要吗？当初我也常常思考，时序数据库值得你死磕吗？明天我从技术的角度来剖析一下这个问题，与大家分享。
1、可扩展性 / Scalability
因为 IT 基础设施的爆炸性增长和物联网（IoT）的呈现，数据的规模正在迅速增长。一个古代的数据中心可能须要收集多达 1 亿个指标——从网络设备和服务器到虚拟机、容器和微服务的一切都在一直地发送工夫序列数据。再比方，分布式电网中的每个智能电表每分钟至多产生一个数据点，而中国的智能电表，至多有十亿个。任何一台计算机都不可能解决这么多的数据，所以任何旨在解决工夫序列数据的零碎必须是可扩大的。
然而，许多市场当先的时序数据库并没有提供可扩大的解决方案。就拿 Prometheus 来说，它能够算是用于 Kubernetes 环境的时序数据库的一个事实标准，但它并没有提供分布式的设计，而必须依附 Cortex、Thanos 或其余第三方工具来实现可扩展性。InfluxDB 有集群性能，然而只向企业客户提供，没有抉择开源。
为了解决这个问题，很多开发者的抉择是，在应用程序和时序数据库服务器（如 InfluxDB 或 Prometheus）之间部署一个代理服务器，来建设本人的可扩大的解决方案。而后依据时序 ID 的哈希值，将收集到的时序数据在多个时序数据库服务器之间调配。从数据写入角度看，这的确解决了可扩展性的问题。但对于查问，代理服务器必须合并来自每个底层节点的查问后果，而这是一个很大的技术挑战。对于一些查问，比方计算标准差，还不能只是合并后果，而是必须从每个节点检索原始数据。这意味着须要重写整个查问引擎，须要的工作量相当之大。
进一步，认真钻研一下 InfluxDB 和 TimeScaleDB 的设计，就会发现，它们的可扩展性实际上是相当无限的。它们将元数据存储在一个核心地位，每个工夫序列总是会关联一组标签或标识。这意味着，如果你有 10 亿个工夫序列，零碎就须要存储 10 亿组标签。看出问题了吗？当你要聚合多个工夫序列时，零碎须要首先确定哪些工夫序列合乎标签过滤条件，而在一个很大的数据集中，这会导致很大的提早。这就是所谓的工夫序列数据库的 High-cardinality 问题。
那么应该如何解决这个问题呢？答案就是元数据处理的分布式设计。元数据不能存储在一个核心地位，否则它很快就会成为一个瓶颈。一个简略的解决方案是，应用分布式关系数据库来解决元数据，然而这会减少零碎的复杂度，使得零碎更难保护，老本也更高了。
TDengine 1.x 的设计就是将所有元数据存储在治理节点（mnode）上，所以它也有 High-cardinality 的问题。在 TDengine 2.x 中，咱们做了一些改良，就是将标签值存储在每个虚构节点（vnode）而不是地方治理节点上, 聚合查问速度有保障，但系统启动工夫在工夫线超过千万后不可忍耐，没有齐全解决这个业内的难题。
2、复杂性 / Complex
数据库是存储和剖析数据的工具，但时序数据处理须要的可不仅仅是存储和剖析。在一个典型的时序数据处理平台中，时序数据库总是要与反对流解决、缓存、数据订阅以及其余性能的工具集成，因而整个数据处理系统是有肯定的复杂度的。
流式解决 / Stream Processing
时序数据就是一个流。为了更快地执行操作或者发现错误，咱们须要在数据点达到零碎时就进行剖析和解决，所以流解决人造适宜时序数据。流解决能够是工夫驱动的，即在设定的工夫距离内产生新的后果（在时序数据库中个别称为间断查问），也能够是事件驱动的，即只有有新的数据点达到就产生新的后果。
InfluxDB、Prometheus、TimescaleDB 和 TDengine 都反对间断查问。这对于监控仪表盘是十分有用的，因为所有的图表都能够定期更新。但间断查问并不能满足所有的数据处理要求，就像 ETL，简单事件处理，所以时序数据库须要反对事件驱动的流解决。
遗憾的是，目前市面上还没有哪款时序数据库反对。个别的形式是，将时序数据库与 Spark、Flink 或其余流解决工具集成，而这些工具并不是为时序数据处理设计的。这些工具很难解决工夫序列数据集中的数百万甚至数十亿的流，即便它们可能胜任，也要以大量的计算资源为代价。
缓存 / Caching
对于很多时序数据利用，像利用性能监控，某个特定工夫的数据值并不重要，这些利用只关注趋势。然而，物联网场景是个例外，应该特地留神。比方，一个车队管理系统总是要晓得每辆卡车的以后地位。对于一个智能工厂，零碎总是须要晓得每个阀门的以后状态和每个电表的以后读数。
大多数时序数据库，包含 InfluxDB、TimescaleDB 和 Prometheus，自身都不能保障以最小的提早返回工夫序列中最新的数据点。为了使每个工夫序列的以后值可能尽可能快地返回，没有高提早，很多开发者抉择将这些数据平台与 Redis 集成。当新的数据点达到零碎时，它们必须被同时写入 Redis 以及数据库中。这种解决方案的确无效，但减少了零碎的复杂性和运维老本。
TDengine 从其第一个版本开始就反对缓存了。在 TDengine 的很多用户案例中，Redis 能够齐全从零碎中移除，从而使整个数据平台的运行更加简略，老本更低。
数据订阅 / Data Subscription
音讯队列在很多零碎架构中有着重要的作用。传入的数据点首先被写入音讯队列，而后被零碎中的其余组件生产，包含数据库。音讯队列中的数据通常会被保留一段指定的工夫（比方 Kafka 中的 7 天）。这与时序数据库中的保留策略是一样的。某个角度上来看，存储的设计上，音讯队列与时序数据库没有实质的区别。
大多数时序数据库写入数据的效率十分高，一秒钟能够达到数百万个数据点。这意味着，如果时序数据库可能提供数据订阅性能，它们能够齐全取代音讯队列，这就再次简化了零碎的设计，进而升高了老本。
目前市场上仅仅 TDengine 提供数据订阅的性能，但现有版本订阅的性能不够，在大部分场景下，无奈将 Kafka 这类软件从零碎中剔除。
论断：没有事件驱动的流解决、缓存和数据订阅这些性能，只管时序数据库依然能够工作，但开发人员不得不将其与其余工具集成，来实现所需的性能。这使得零碎设计会相当简单，须要更多资源，也更难保护。如果时序数据库内置了这些性能，整个零碎架构就能够极大简化，运维老本也会大大降低。
3、云原生 / Cloud Native
云计算越来越风行，云计算最美好最吸引人的中央在于它的弹性——存储资源和计算资源没有下限，而咱们只须要为理论应用的资源付费。这也是所有应用程序，包含时序数据库，都在向云上转移的一个次要起因。
遗憾的是，大多数数据库只是“云就绪”（cloud-ready），而非云原生（cloud-native）。当你购买某些数据库供应商提供的云服务时，比方 TimescaleDB，你须要通知零碎你想要多少虚构服务器（包含 CPU 和内存配置），以及多少存储。即便你没有运行任何查问，你依然不得不为计算资源付费，如果你的数据规模增长了，你还须要决定是否购买更多资源。这种云解决方案，其实只是数据库服务提供商在转售云平台。
要充分利用云平台提供的劣势，时序数据库必须是云原生的。为了实现这一点，时序数据库须要从新设计。这时候要重点思考如下几点。
- 计算和存储拆散：在容器化环境中，特定的容器可能在任何时候启动或敞开，但存储的数据是长久化的。传统的数据库设计无奈应答这种状况，因为数据都存储在本地。此外，为了运行简单的查问或执行批处理，须要动静地减少更多计算节点，以放慢处理速度。
- 可伸缩性：零碎必须可能依据负载和提早要求，实现存储和计算资源的程度扩大或程度伸缩。对于计算资源来说，零碎不难做出决定。然而存储资源就不一样了。要实现分布式数据库的伸缩，当数据实时写入，或者查问正在执行的时候，数据库的分片可能须要进行合并或宰割。设计一个可能实现这一工作的零碎并不容易。
- 自动化、可观测性：时序数据库的状态必须能与零碎的其余组成部分一起被监控，所以一个好的时序数据库须要提供全面的可观测性。同时零碎必须提供便于在 K8S 下自动化治理的接口，否则经营治理将变得复杂。
当初这个时候，任何新开发的时序数据库都必须是云原生的。尽管 TDengine 的设计从第一天起就是一个具备程度扩大、高可用、高牢靠的的分布式架构，但目前的 2.x 还不能算为云原生数据库，因为它不反对存算拆散，而且在云平台的部署和治理还较为欠缺。
4、不便易用 / Ease of use
只管不便易用这个词有点主观，然而咱们能够尝试在这里列出几点，从不同方面说说一个对开发者更敌对的时序数据库应该做到哪些。
- 查询语言：因为 SQL 依然是最风行的数据库查询语言，能反对 SQL，对开发者而言就没什么应用门槛了。另一方面，专用的查询语言须要开发者破费本人贵重的工夫来学习，还会减少向其余数据库迁徙的老本。InfluxDB，OpenTSDB，Prometheus，RRDTool 等都不反对 SQL，但 TDengine 与 TimeScaleDB 反对 SQL。
- 交互式控制台：对开发者而言，应用一个交互式的控制台来治理运行的数据库或执行即席查问是最不便的。对于部署在云上的时序数据库也是如此。
- 示例代码：开发者往往不会花工夫把整个文档通读一遍，而是间接学习如何应用某个特定的个性或 API。新的数据库必须用支流的编程语言提供示例代码，开发者只须要把这些代码复制粘贴到本人的利用中，如果需要的话再依据本人的具体情况稍加批改即可。
- 数据迁徙工具：数据库管理系统须要提供一到多个不便高效的数据导入导出工具。源头和指标可能是一个文件、另一个数据库或者是近程数据中心中的一个正本。要迁徙的数据可能是整个数据库，一组表，或者是一个指定时间段中的数据点。
技术的挑战
下面我总结了目前市场上时序数据库（Time Series Database）几大亟待解决的问题，包含 Scalability，Complex，Cloud Native 与 Ease of Use。这些问题，从技术上来看，都是硬骨头，否则早被厂商解决了。有问题，那就有机会。2016 年底，我就是因为钻研后，发现 InfluxDB，TimeScaleDB，Prometheus，OpenTSDB 等有各种有余，才开始决定进入这个行业的。5 年多过来，我率领 TDengine 团队力求去解决这些问题，版本从最开始的 1.0，到 1.6，到 2.0、2.6，团队从 5 集体倒退到了 80 多人，专职研发都曾经超过 50 人。TDengine 与很多时序数据库相比，是一不错的产品，但遗憾的是，上述的问题还只是局部的解决。
作为一个深信技术能扭转世界的创始人，不解决这些问题难以入眠，难以证实本人以及整个团队的技术实力。因而在 2021 年 6 月，我决定正式启动 TDengine 3.0 的研发，投入了公司最大的资源，让所有研发同学分心新版本的研发，以解决上述技术难题为指标。TDengine 3.0 不仅要瞄准将来，成为一个云原生时序数据库，它还须要能反对 100 亿条工夫线，100 个节点，让其具备极强的程度扩大和伸缩能力，彻底解决业内的“High Cardinality”问题。内置的流式计算、数据订阅、缓存等性能在时序数据场景下，要能完胜 Spark，Kafka，Redis 等通用场景下的工具。最终的指标就是升高时序数据处理系统的总领有老本，帮忙用户挖掘出数据的价值，让最终用户胜利；而且让开发者用的棘手、用的释怀，让开发者胜利。
一年多过来，TDengine 的研发同学没日没夜的设计、编码和测试，TDengine 3.0 终于能够揭开面纱。咱们决定在 8 月 13 日召开 TDengine 开发者大会，为大家具体揭秘 TDengine 3.0 的外围设计，并将 3.0 正式公布，在 GitHub 上公开其外围源代码。咱们还邀请了业内的很多技术专家、投资人，以及咱们的用户，独特奉上一整天的精彩分享。
8 月 13 日，我在 TDengine 开发者大会上等你。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。