数据库作为数字基础设施的根技术，已有 60 年发展历程，历经上世纪 50 年代的层次数据库、网状数据库，到上世纪 70 年代的关系型数据库，再到上世纪 90 年代的分析型数据库，2000 年的非关系型数据库，几个发展阶段，其中时序数据库，主要是针对近来火爆全球的AIOT场景而专门打造的，兴起时间倒并不长，而在一众时序数据库产品中TDengine目前所取得的成绩明显力压力压群雄，其产品升级迭代的路线非常符合时代的要求，本文我们就来为大家解读TDengine升级背后的逻辑。
在这个数字化的时代中人们对数字体验提出全量、全要素、全流程等数字化新需求，这给数据库提出新的挑战。为适应这个挑战我们看到2022年国产数据库都开始向云原生化的方向转型，而TDengineV3中优化的虚拟节点（Vnode），新增的弹性计算节点（Qnode）和流计算节点（Snode），全部是围绕云原生这个特性展开，并且特别贴合于时序数据库的实际使用场景。
基础背景-传统数据库与时序数据库的云原生转型有何不同
云原生是Do more with less理念的产物，也就是让用户以更少的操作，来实现更多更智能化的效果。目前绝大部分的传统数据库的云版本，大多以ECS中的自建数据库和云厂商托管的数据库RDS的形态存在的，这些云数据库架构使用的是传统数据库的架构，只是运行在云的基础设施上，数据库本身并没有为云做太多的改造和适配。
从技术层面上讲传统的云数据库除了实现存储和计算分离和一写多读以外，还有很强的冲动云将CPU和内存的绑定关系进行解耦，因为传统数据库的使用场景很多，CPU资源和内存资源如果作为一个整体，只能作为一个最小的单位升降级的话（一般都是1C2G的计算内存配比），对用户来说是不合理的，比如对AP类分析弄数据库，用户使用少数CPU来定期同步和更新数据。但为了避免从磁盘来读取数据的时间延迟。维表数据，或者中间结果需要缓存在内存里，需要较大内存，但对TP交易型数据库来说，数据访问一般存在热点，因此少量的内存就足够保证缓存命中率超过99%，但高峰时CPU需要弹到64c甚至更多核，CPU的需求会高于内存的需求。
因此我们看到所有数据库厂商都提出口号要实现云原生方面的转型，但是具体到不同类型的产品上讲，这个诉求是不同的，传统数据库厂商到要做将计算资源和内存分别进行池化，使得弹性能力更进一步提升，这是使用场景决定的。
我们看到时序数据库(Time Series Database)这种相对使用场景比较固定的门类，它展开云原生转型的路线实际上是围绕分布式改造和流式计算这两个核心来展开，只有把这两个点做好才符合云原生Do more with less的理念。
TDEngine云原生路线解读
正如我们前文所说，传统数据库的云原生技术升级，主要是把计算资源和内存资源全部池化，从而解决计算内存资源比例绑定而产生的浪费问题。但是时序数据库使用场景比较固定，因此基本不存在计算资源和内存资源需要解耦，并分别池化的需求。
元数据存储的分布式改造：因此我们看到TDengine3最重要的升级就是全面的分布式改造，TDengine之前版本中对于数据一直使用分布式架构处理，在时间轴上以天或周为单位对数据进行切分，同时将定量设备的数据分配给每个区（Vnode）进行处理。3.0 版本让TDengine对元数据的管理也变成了完全分布式的。
在传统数据库中RDB也就是元数据的量往往很小，因此集中式存储一般问题不大，但是在时序数据库中元数据是所以采集点的标签数据，如果是电表标签的话，那个元数据可能有上亿条，数据量级会非常大，因此TDengine 3.0的版本中管理节点不再存储每个设备或每张表的元数据了，而是把这些元数据还有时序数据完全存储在 vnode 里，之后会用 B+ 树、一致性哈希来处理。这样一来，TDengine在插入一个数据到任何一个片或者一个区时都不再需要经过任何中间节点，彻底解决了采集数据分布过多且与标签数据点乘带来的高基数问题。同时 Vnode 也可以进行拆分或合并，保证存储也可以弹性伸缩。
引入弹性计算节点Qnode，适配弹性伸缩需求：在完成元数据的分布式改造的同时，Qnode流式计算节点的引入让TDengine完全实现了计算和存储分离，Qnode 不是系统必需的节点，支持动态地启动、停止，也就是说它的计算资源可以动态地进行操控，这样就实现了存算分离。而且TDengine3.0 版本还针对容器化部署的需求，给出了详细的 Kubernetes 部署文档，只需修改两个配置文件，马上就能部署整个TDengine集群，极其简单。
增加对于流式计算的支持：流式计算是我们日常使用数据过程中所经常遇到的一种计算模式，流式计算中流的概念，一方面是指把数据当成数据流处理由数据驱动计算的完成，提升计算指标的实效性；另一方面是指将计算和传统的工作流结合，更高效的完成数据的分析、统计等工作。
比如在笔者日常的工作中就会订阅一些高净值客户的动帐情况，一旦遇到有高额的理财或者基金赎回，就会匹配一些对应的产品推荐给客户，这些推荐对于挽留客户一般都有着比较好的效果，但是对于实效性的要求也很高，因此流式计算在这方面应用比较多。
我相信TDengine3.0的版本规划时肯定是充分调研了市场的需求，因为流式计算也就是实时数据流计算，一般都要与kafka等消息队列产品搭配使用，比如我们上文所说的高净值客户的理财赎回，其实就是我们关注的一类消息，这类消息我们往往需要用消息中间件处理，而TDengine则自带了消息订阅的服务，而且TDengine3.0新引入的流计算节点Snode，还全面支持用SQL语句定义的流计算过程。这就更方面用户在此基础上更好的挖掘数据的价值，利用TDengine来简单高效得创建一体化的数据存储及处理平台。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
