关于tdengine:时序数据库的集群方案

当初支流的时序数据库的确集群计划大多数都抉择闭源，除了从技术角度上来看，商业的考量也是泛滥大厂必须思考的元素之一。TDengine 作为一款全自研的开源软件，继 2019 年单机版开源后，在 2020 年也发表集群版正式开源。这意味着，在集群搭建方面，对于研发资源薄弱、工夫精力都无限的企业来说，无疑是拨云见日的一则好消息。

正在苦寻计划的技术人，或者正在做技术选型的领导者们，欢送大家移步我司官网，下载和测试

返回官网，查看更多

简略的广告之后，还是要用真正的技术谈话，也为苦苦寻求技术计划的搭档们提供一种新的思路。对于 TDengine 集群的设计思路，能够从以下四方面来简略形容。（彩蛋！结尾有视频微课堂解说，不想看文字的搭档能够间接拉到最初呦～）

1、集群与次要逻辑单元

TDengine 是基于硬件、软件系统不牢靠、肯定会有故障的假如进行设计的，是基于任何单台计算机都无足够能力解决海量数据的假如进行设计的。因而 TDengine 从研发的第一天起，就依照分布式高牢靠架构进行设计，是齐全去中心化的，是程度扩大的，这样任何单台或多台服务器宕机或软件谬误都不影响零碎的服务。

通过节点虚拟化并辅以自动化负载平衡技术，TDengine 能最大限度地利用异构集群中的计算和存储资源。而且只有数据正本数大于一，无论是硬软件的降级、还是 IDC 的迁徙等都无需进行集群的服务，极大地保证系统的失常运行，并且升高了系统管理员和运维人员的工作量。

上面的示例图上有八个物理节点，每个物理节点被逻辑的划分为多个虚构节点。

图例：物理节点 (dnode)、虚构数据节点 (vnode)、虚构数据节点组 (vgroup)、虚构治理节点 (mnode)

2、一典型的操作流程

为解释 vnode, mnode, taosc 和利用之间的关系以及各自表演的角色，上面对写入数据这个典型操作的流程进行分析。

1. 利用通过 JDBC、ODBC 或其余 API 接口发动插入数据的申请。
2. taosc 会查看缓存，看是有保留有该表的 meta data。如果有，间接到第 4 步。如果没有，taosc 将向 mnode 收回 get meta-data 申请。
3. mnode 将该表的 meta-data 返回给 taosc。Meta-data 蕴含有该表的 schema, 而且还有该表所属的 vgroup 信息（vnode ID 以及所在的 dnode 的 IP 地址，如果正本数为 N，就有 N 组 vnodeID/IP)。如果 taosc 迟迟得不到 mnode 回应，而且存在多个 mnode,taosc 将向下一个 mnode 发出请求。
4. taosc 向 master vnode 发动插入申请。
5. vnode 插入数据后，给 taosc 一个应答，示意插入胜利。如果 taosc 迟迟得不到 vnode 的回应，taosc 会认为该节点曾经离线。这种状况下，如果被插入的数据库有多个正本，taosc 将向 vgroup 里下一个 vnode 收回插入申请。
6. taosc 告诉 APP，写入胜利。

3、数据分区

vnode(虚构数据节点) 保留采集的时序数据，而且查问、计算都在这些节点上进行。为便于负载平衡、数据恢复、反对异构环境，TDengine 将一个物理节点依据其计算和存储资源切分为多个 vnode。这些 vnode 的治理是 TDengine 主动实现的，对利用齐全通明。

对于独自一个数据采集点，无论其数据量多大，一个 vnode（或 vnode group, 如果正本数大于 1）有足够的计算资源和存储资源来解决（如果每秒生成一条 16 字节的记录，一年产生的原始数据不到 0.5G），因而 TDengine 将一张表的所有数据都寄存在一个 vnode 里，而不会让同一个采集点的数据分布到两个或多个 dnode 上。而且一个 vnode 可存储多张表的数据，一个 vnode 可包容的表的数目由配置参数 sessionsPerVnode 指定，缺省为 2000。设计上，一个 vnode 里所有的表都属于同一个 DB。因而一个数据库 DB 须要的 vnode 或 vgroup 的个数等于：数据库表的数目 /sessionsPerVnode。

创立 DB 时，零碎并不会马上分配资源。但当创立一张表时，零碎将看是否有曾经调配的 vnode, 而且是否有空位，如果有，立刻在该有空位的 vnode 创立表。如果没有，零碎将从集群中，依据以后的负载状况，在一个 dnode 上创立一新的 vnode, 而后创立表。如果 DB 有多个正本，零碎不是只创立一个 vnode，而是一个 vgroup(虚构数据节点组)。系统对 vnode 的数目没有任何限度，仅仅受限于物理节点自身的计算和存储资源。

sessionsPerVnode 的设置须要思考具体场景，创立 DB 时，能够个性化指定该参数。该参数不宜过大，也不宜过小。过小，极其状况，就是每个数据采集点一个 vnode, 这样导致系统数据文件过多。过大，虚拟化带来的劣势就会丢失。给定集群计算资源的状况下，整个零碎 vnode 的个数应该是 CPU 核的数目的两倍以上。

4、负载平衡

每个 dnode(物理节点) 都定时向 mnode(虚构治理节点) 报告其状态（包含硬盘空间、内存大小、CPU、网络、虚构节点个数等），因而 mnode 理解整个集群的状态。基于整体状态，当 mnode 发现某个 dnode 负载过重，它会将 dnode 上的一个或多个 vnode 挪到其余 dnode。在移动过程中，对外服务持续进行，数据插入、查问和计算操作都不受影响。负载平衡操作完结后，利用也无需重启，将主动连贯新的 vnode。

如果 mnode 一段时间没有收到 dnode 的状态报告，mnode 会认为这个 dnode 曾经离线。如果离线工夫超过肯定时长（时长由配置参数 offlineThreshold 决定），该 dnode 将被 mnode 强制剔除出集群。该 dnode 上的 vnodes 如果正本数大于一，零碎将主动在其余 dnode 上创立新的正本，以保证数据的正本数。

总结

比拟常见的对于集群计划的问题，TDengien 在设计之初就曾经思考到，这也是为什么很多企业纷纷将数据库迁徙过去的很重要的一个起因。当企业还在花十倍甚至百倍的人力物力研发和搭建本人的集成计划时，跑在后面的企业曾经借助更业余的力量和计划，实现了研发为业务赋能的承诺。

想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。