TDengine时序数据库入门：核心概念、安装部署与运维实践

TDengine我其实关注了很久最早是在一些物联网项目里频繁听到这个名字。后来自己动手在服务器上完整部署过几次从2.x一路用到3.x踩过不少坑也摸清了一些门道。这篇就当一个系列的开篇先把最基本的东西讲透TDengine到底适合什么场景、为什么它能在这个领域站稳脚跟以及从零开始怎么把它装起来、跑起来。后面如果大家需要我再接着写数据建模、集群部署、数据迁移这些更深入的话题。写这篇文章之前我特意去翻了一圈社区里的讨论和官方文档结合自己实际部署中遇到的问题把那些网上说得云里雾里的概念和步骤重新梳理了一遍。无论你是刚接触时序数据库的初学者还是已经在其他时序数据库上折腾过、想换个方案的老手这篇文章应该都能让你少走一些弯路。1. 想清楚TDengine到底解决什么问题再动手不迟1.1 时序数据这个场景有多特殊在聊TDengine之前得先明白一个问题为什么会有“时序数据库”这种专门的数据库存在直接用MySQL、MongoDB不行吗我当初也这么想过。后来在一个设备监控项目里需要每秒采集上千台设备的状态数据包括温度、电压、运行时长、告警状态等。传统的MySQL表结构很快就撑不住了数据量一大单表几亿行写入速度直线下降查询更是慢得让人崩溃。而且这些数据还有一个特点不会频繁更新主要是不断追加新数据查询时也很少做跨设备的多表关联更多是“按设备、按时间段”取数据。这就是典型的时序数据场景。它的核心特征有三个一是数据生产速度快、量大通常以时间戳为主键二是数据格式相对固定每条记录就是“时间 一组指标 若干标签”三是业务上更关心最近一段时间的数据历史数据也需要保留但查询频率不高。用传统关系型数据库去处理这种数据等于让一个带枪的厨子去打猎能打下来但费劲不讨好。存储空间浪费严重索引维护成本高查询优化器对时间范围扫描也不擅长数据量一上来各种性能瓶颈就全暴露了。时序数据库就是专门为这种“不断产生、按时间排序、批量写入、范围查询”的数据设计的。而TDengine是这里面比较特别的一个。1.2 为什么那么多团队最后选了TDengineTDengine是涛思数据出品的一款开源时序数据库主打的就是“高性能、低门槛、云原生”。我第一次了解它时最直观的感受是国产开源软件里能把技术文档和社区氛围做得这么用心的确实不多见。它吸引人的地方我认为主要有这几点写入性能极强。因为采用列式存储加顺序写入的设计单机写入速度在百万条记录每秒级别这个数字在普通商用服务器上也能跑出来。相比传统数据库一个量级的差距。存储成本低。压缩比通常在10倍以上因为时序数据本身冗余度高TDengine还针对不同类型数据做了专门的压缩算法同样一批数据存在里面可能只有MySQL的十分之一到二十分之一大小。自带缓存、订阅、流式计算功能。它不只是存储还内置了数据订阅、连续查询和简单的流式计算能力。做物联网平台时很多原本要配合Kafka、Flink做的事情直接从TDengine里拿数据就行架构简化不少。支持SQL。这是它降低门槛的杀手锏。团队里不需要专门招一个懂时序数据库的专家会SQL就能很快上手。这一点对我来说当初是巨大的加分项。我自己是把它部署在CentOS服务器上用systemd管理的也有朋友用Docker起容器。两种方式都熟下面先带你理清安装前必须知道的事再分别讲具体的部署步骤。2. 安装前先把这些概念和版本情况搞清楚2.1 四个核心概念库、超级表、子表、时间戳TDengine里的数据组织逻辑和关系型数据库很像但有几个关键概念一定要提前理解不然建表时容易一头雾水。在TDengine 3.x版本之前它的核心抽象是“超级表STable”。超级表就是一个模板它定义了同一个设备类型的数据结构。打个比方你有100个智能电表每个电表实时上报电压、电流、功率这三个指标还带有位置、编号等标签。你可以创建一个超级表字段是“时间戳、电压、电流、功率”标签是“编号、位置”。然后每个具体的电表就是超级表下面的一张子表。这种“一个模子刻出很多表”的设计最大好处是查询和存储都能按标签去优化。你在超级表上查询某个位置的电表某段时间的电压数据它不需要扫描所有表直接按标签过滤效率高很多。3.x版本在概念上做了一些调整把库Database和超级表这一层继续强化同时引入了“原生分布式表”之类的概念但最核心的使用习惯并没有颠覆。你只要掌握三件事库对应数据库DB超级表对应一张设备的逻辑模板子表对应一个具体设备的时间序列数据。还有个核心就是时间戳。TDengine要求每张表必须有时间戳列主键就是时间戳加设备ID。这一点和传统数据库不同写入时你要保证数据是按时间顺序或近似顺序进来的乱序数据多多少少会影响性能。所以在设计采集程序时尽量按采集时间排序写入这个习惯很重要。2.2 版本那么多到底该选哪个TDengine这几年版本更新速度很快我在不同时间接触过2.4、2.6、3.0、3.1、3.2等版本。说实话版本这个问题挺容易让人选择困难。如果你是要搭建一个全新的生产环境我建议直接用3.x的最新稳定版。3.x版本在架构上有一次比较大的升级把计算和存储做了更深度的融合事务支持也更好还引入了更灵活的权限体系。而且社区维护的重心已经全面转向3.x新功能新特性基本都往这边堆2.x只会慢慢淡出。当然如果你是在维护一个老系统那就老老实实跟着原版本升级不要跨大版本硬跳。3.x和2.x的超级表模型虽然核心思路相同但在某些SQL语法、客户端连接方式上还是有差异的。比如2.x里常用的taosdump备份命令在3.x里变成了taos-tools塔奥斯工具集的一部分2.x的taos命令行连接方式到了3.x也加入了更多新的配置项。接口调用大同小异但细节上有坑后面专门写一篇兼容性分析时再细说。那怎么选具体的小版本呢我的习惯是去官方GitHub仓库的Release页面看最新的稳定版本关注它的发布说明如果有Bug修复和性能优化基本就是比较可靠的选择。不建议一上来就选择刚发布的RC版本尤其是没有太多测试时间的情况下。2.3 服务器配置和部署形态怎么定TDengine对硬件的要求总体来说不高但不同的场景差别挺大。我这里说的“场景”包括数据规模、查询并发、是否需要集群等。单机部署的话CPU四核起步内存8GB以上磁盘根据你的数据量来估。我个人的经验公式是原始数据量除以5到10再乘以1.2大致就是需要的存储空间因为压缩比在那边摆着。比如你每天产生100GB的时序数据保留30天大约3TB原始数据实际占用可能400GB到600GB就够了。操作系统方面官方支持CentOS 7/8、Ubuntu 18.04以上、Debian、麒麟等主流系统。Windows也支持但我没有在Windows上正式跑过生产环境建议生产环境还是放在Linux上性能和稳定性都更可控。部署形态上如果数据量级没到几亿条每秒单机就够了。TDengine单机的写入性能已经能顶住不少中小型项目的全部压力。需要搞集群的情况通常是数据规模很大、需要水平扩展或是对高可用有需求比如主备容灾。3.x的集群部署已经做得比较顺手但初次上手比你想象的要复杂一些涉及配置多个taosd节点并打通通讯。这篇文章先专注单机安装集群部分后面单独写。3. 两种主流安装方式的完整实测3.1 以RPM包方式在CentOS上装TDengine 3.x这是最传统也最“标准”的安装方式。我用的是CentOS 7.9服务器整个流程分几步每一步都值得认真仔细对待。第一步确保系统已安装wget和tar等基础工具如果没有就先用yum装上。第二步去官网或GitHub下载最新稳定版的RPM包。我写这篇文章时最新稳定版大概是3.3.x。下载时注意选择对应架构的包一般x86_64的服务器就选带x86_64的名字。wget https://github.com/taosdata/TDengine/releases/download/ver-3.3.6.0/TDengine-server-3.3.6.0-Linux-x86_64.rpm第三步安装RPM包sudo rpm -ivh TDengine-server-3.3.6.0-Linux-x86_64.rpm安装过程会自动创建taos用户和taos组安装taosd服务程序、taos命令行工具还会生成默认配置文件/etc/taos/taos.cfg。这一步没有复杂的交互装完就完事了。第四步启动服务。这是很多人容易漏掉的一步因为安装完并不会自动启动你得手动来sudo systemctl start taosd默认安装完还会让你执行taosd -v看一下版本号这不是必需的但可以顺手确认版本对不对。装完之后可以用systemctl status taosd查看服务状态看到active (running)就是正常。如果不对稍后会写排查办法。3.2 Docker方式安装与数据持久化如果你对容器化部署比较熟或者不想让宿主机残留一堆依赖Docker是很优雅的选择。我第一次用Docker装TDengine时犯过一个错误没有做数据目录的持久化映射容器一删数据全没了。这个坑希望大家别踩。官方Docker镜像叫tdengine/tdengine一条命令就能跑起来docker run -d --name tdengine \ -p 6030:6030 -p 6041:6041 -p 6042:6042 -p 6043:6043 -p 6044:6044 -p 6045:6045 -p 6046:6046 -p 6047:6047 -p 6048:6048 -p 6049:6049 \ -v tdengine-data:/var/lib/taos \ -v tdengine-log:/var/log/taos \ tdengine/tdengine端口方面6030是taosd服务端口客户端连接和集群通信用的6041是RESTful接口HTTP访问都走它后面的端口是taosAdapter等组件的默认端口如果你只是跑核心服务通常起6030和6041就够了。看到-v了吧这两个挂载目录非常关键。/var/lib/taos是数据目录/var/log/taos是日志目录。如果你用我上面这种命名卷的方式至少在docker volume ls里能看到数据卷容器删掉之后数据还在。但如果你愿意也可以直接映射到你指定的宿主机目录比如-v /data/tdengine:/var/lib/taos容器起来之后想进入命令行可以这样docker exec -it tdengine taos后面在Docker里执行其他命令比如运维命令也需要用docker exec套一层。3.3 安装完成后的启停、检查与基本配置无论是RPM还是Docker安装都需要了解这几个基础操作。使用systemd管理时相关命令是sudo systemctl start taosd sudo systemctl stop taosd sudo systemctl restart taosd sudo systemctl enable taosdenable这一步在初次安装后建议执行一下否则服务器重启后taosd不会自动启动到时候你可别怪系统。配置文件位于/etc/taos/taos.cfgRPM安装或容器内/etc/taos/taos.cfg。最常用的几个配置项你需要知道fqdn服务端对外提供服务的域名或IP。默认是空有时会自动解析成本机主机名。多网卡或域名解析有问题时这里最容易出状况。serverPorttaosd服务的TCP/UDP端口默认6030。一般不用改但如果你有端口冲突可以在这里调。dataDir数据文件存放目录默认/var/lib/taos。生产环境建议把数据放到单独的磁盘分区性能和安全都有保证。logDir日志目录默认/var/log/taos。locale和charset中文环境下偶尔会遇到乱码或无法启动的问题这时把这两项按系统实际值配上比如locale C对应的charset UTF-8注意这个不要随意改除非你明确知道本地字符集不匹配。改配置之后要重启taosd才生效。这里有个常见的坑修改fqdn后客户端去连接时用的是你新填的地址如果填成了localhost服务端绑定的还是旧地址很容易出现连不上的情况。改成实际IP后要确认安全组和防火墙放行对应端口。4. 首次使用建库、建表、写入与查询4.1 用taos命令行做一次全流程装好并启动服务之后第一件事是先用命令行工具连通数据库。在服务器上执行taos如果一切正常你会看到版本号和taos提示符。这就是TDengine的SQL终端语法和MySQL高度相似但下面这些命令你最好记住。先看已有的库SHOW DATABASES;初始化状态下通常只有一个information_schema库这是系统自带的。接下来我们创建一个业务库CREATE DATABASE monitor KEEP 365 DURATION 10 BUFFER 256 WAL_LEVEL 2;这条命令里几个参数特别重要KEEP 365数据保留365天超过时间会自动清理这一点超实用不用自己写定时任务删数据。DURATION 10数据按10天一个文件分片存储影响数据文件的组织和删除粒度一般不需要频繁调整。BUFFER和WAL_LEVEL跟内存和写入策略相关。WAL_LEVEL 2是默认写法表示写入先写日志再写缓存崩溃后恢复能力好一些。建完库后切到这个库USE monitor;接着建一个超级表模拟一组智能电表数据CREATE STABLE meters (ts TIMESTAMP, voltage FLOAT, current FLOAT, power FLOAT) TAGS (location BINARY(64), group_id INT);注意普通字段里是时间戳和采集数据标签是那些不随时间变化的静态属性。这样建的好处是查询时可以把标签和采集数据分开处理性能好逻辑也清楚。然后为具体的电表创建子表CREATE TABLE d001 USING meters TAGS (beijing-01, 1); CREATE TABLE d002 USING meters TAGS (shanghai-02, 2);这里d001就是子表名字beijing-01和1分别是标签值。以后采集到的数据按设备名写入对应的子表。插入几条示例数据INSERT INTO d001 VALUES (NOW, 220.1, 2.3, 506.2); INSERT INTO d002 VALUES (NOW, 219.8, 3.1, 681.4);我这里直接用NOW表示当前时间。实际生产环境建议用长整型毫秒时间戳这样采集端和控制端更好对齐。查询最近一分钟内的电压数据SELECT ts, voltage FROM meters WHERE ts NOW - 1m;注意没有再加d001这种设备名条件它查的是整个超级表也就是所有电表的数据。你会发现SQL执行的路径会自动带上标签过滤不需要你手动拼接一堆表名。再比如统计每个分组下的平均功率SELECT group_id, AVG(power) FROM meters INTERVAL(10m) GROUP BY group_id;在TDengine里INTERVAL用于时间窗口聚合这条语句的含义是每10分钟一个窗口按组算平均功率。这套语法是时序数据库操作里最常用的一套组合。4.2 用RESTful接口体验开发连接命令行验证正常后下一步就是让业务代码连上来。TDengine提供了很多种连接方式原生连接器Java、Python、Go、C等、RESTful接口、还有类似MySQL的交互协议。对新手来说最省事的是RESTful接口因为它不需要装任何额外的客户端驱动用HTTP POST就行。先验证一下RESTful接口是否正常curl -u root:taosdata -H Content-Type: application/json \ -d {sql:show databases} \ http://your-server-ip:6041/rest/sql这里的root:taosdata是默认账号和密码首次登录用的装完最好尽快改掉。your-server-ip换成你服务器的实际IP也可以是本机127.0.0.1。6041就是前面说的RESTful端口。用Python操作也就几行代码以requests为例import requests url http://your-server-ip:6041/rest/sql data {sql: SELECT ts, voltage FROM meters LIMIT 5} resp requests.post(url, auth(root, taosdata), jsondata) print(resp.json())看到返回的JSON里包含查询结果说明开发通道已经打通了。接下来你想用Python、Java还是Go做后续的开发都只是换连接器和API的问题核心SQL逻辑是一样的。这个过程中最常出错的就是端口没放行、账号密码不对、SQL语法在TDengine里有些细微差异这三个点。5. 安装部署高频问题和运维经验记录5.1 端口、防火墙和时间同步问题TDengine部署后连不上十有八九是这三个方面的问题。端口。前面提到taosd用6030RESTful用6041。如果你用systemd方式安装服务启动后先在本机执行netstat -tlnp | grep -E 6030|6041看看有没有进程在监听。本机都没起来就别怪防火墙了。确认在监听后再检查云安全组和服务器防火墙sudo firewall-cmd --permanent --add-port6030/tcp --add-port6030/udp --add-port6041/tcp sudo firewall-cmd --reload如果你做的是集群还要把后面那些端口也一起放行否则节点之间通信会失败。时间同步。时序数据库对时间校准有天生要求时间不准数据的时间戳就是乱的查询结果自然不对劲。所以一定要确认服务器开启了NTP同步timedatectl看到NTP service: active基本没问题。如果NTP没开数据写入后会发现时间戳和实际采集时间差了好几分钟排查起来特别头大。系统时区设置。TDengine默认按服务器时间处理时间戳。如果业务方要求统一到东八区一定要把系统时区设对否则你看到的时间和业务期望的时间之间会出现偏移而且这种偏移是隐性错误很难第一时间发现。5.2 磁盘配置和数据目录TDengine的性能和磁盘的关系非常密切。因为它的核心设计就是顺序写入、列式存储磁盘IO是整个系统的关键瓶颈。如果你的服务器有普通机械盘和SSD强烈建议把dataDir指向SSD分区。即使预算有限至少要保证数据目录所在分区有足够空闲空间别等到系统盘满了才知道出大事。TDengine写入过程中如果磁盘满了服务不会立刻宕掉但写入会报错、数据会丢这个现象非常隐蔽。查看磁盘使用情况和数据目录大小df -h du -sh /var/lib/taos/*如果你发现某个vnode目录特别大说明数据量主要集中在某个时间片的某个设备组上这种分布不均的情况在生产环境里需要特别留意可以做一下数据均衡或调整分区策略。另外建议养成定期备份数据的习惯。TDengine 3.x提供taos-tools里的taosdump工具可以把数据导出成文件。虽然生产环境很多团队会做集群高可用但本地备份依然是一个重要的最后安全网。后面我计划专门把taosdump的用法整理出来.5.3 日志排查和常见错误日志是运维TDengine时最重要的朋友没有之一。日志目录默认在/var/log/taosRPM方式或容器内的/var/log/taos分为taosdlog.日期.0taosd主进程的运行日志里面能看服务启动、错误、警告信息。taosdslowlog.日期.0慢查询记录。taosddebuglog.日期.0更细粒度的调试信息通常排查问题或提issue给社区时用得上。遇到连接错误比如“Unable to resolve FQDN”这种基本就是fqdn配置不对去taos.cfg里改改成IP或可解析的域名然后重启。遇到“Database not exists”或“Table not exists”大概率是没USE库或者生成的库、表名字拼错了用SHOW DATABASES; SHOW STABLES; SHOW TABLES;逐层确认。遇到“Disk is full”或写入报错去查数据盘占用和df输出清理数据或扩容。还有个比较常见的坑是内存不够导致服务自动退出。TDengine默认会占用系统一部分内存做数据缓冲和索引如果你的机器只有2GB内存还跑着其他服务很容易在这个环节出问题。建议至少4GB内存如果业务量大内存配置要更高。日志文件的查看方式sudo tail -n 100 /var/log/taos/taosdlog.$(date %Y-%m-%d).0排查时优先看今天这个日期的日志文件。文件时间戳是按天切分的不要总盯着一个文件看到底。5.4 Docker部署的几个特定问题如果你用的是Docker部署除了前面说的数据卷挂载问题还有几个特定注意点。第一容器内时区。官方镜像默认是UTC时区如果你挂载了宿主机时区文件一般能正常跟随宿主机但要确认宿主机时区是否是东八区。如果不一致业务查询时看到的时间会差好几个小时。第二容器资源限制。建议在Docker启动参数里加上--memory4g --cpus2这样能防止TDengine容器把宿主机资源吃光导致其他服务挂掉。虽然TDengine有内存自适应机制但显式限制能更好地保证整体稳定性。第三不要频繁docker stop和docker start。虽然数据在持久化卷里但突然断电似的停容器可能损坏WAL日志导致启动时恢复很慢甚至丢数据。正常停容器用优雅的方式停比如docker exec -it tdengine taos -s shutdown;然后等进程完全退出再stop容器。6. 安装后的基础配置和安全加固建议6.1 修改默认密码别让root裸奔TDengine默认的root账号密码是taosdata。这个默认密码人尽皆知暴露在公网上的服务器如果不改基本就是被人当作肉鸡敲门的节奏。修改root密码的方法很简单在taos命令行里执行ALTER USER root SET PASSWD your-new-password;改完立马生效之后所有客户端连接和RESTful请求都使用新密码。以后我还建议创建专用账号按最小权限原则分配CREATE USER appuser PASSWD app-passwd; GRANT READ ON monitor.* TO appuser;这样业务程序只读monitor库不会有误删或误改的风险。这一招在多人协作和线上环境特别实用。6.2 数据目录软链接和日志轮转很多服务器根分区不大而数据目录默认放在/var/lib/taos。如果你想把数据放到一块挂载在/data的大磁盘上一个小技巧是把数据目录做成软链接sudo systemctl stop taosd sudo mv /var/lib/taos /data/tdengine-data sudo ln -s /data/tdengine-data /var/lib/taos sudo systemctl start taosd这样做的好处是不需要改配置文件也不用担心某些版本对数据目录的硬校验。日志轮转方面TDengine自带按天分割日志但历史日志可能会越积越多。建议配合系统的logrotate或定期清理策略比如保留最近30天的日志。我自己习惯用一个cron任务每天凌晨清理超过30天的taosdlog.*这样日志不会无限膨胀把磁盘挤爆。0 2 * * * find /var/log/taos -name taosd*.log.* -mtime 30 -delete6.3 第一次启动后一定要做的三件事文章最后我把自己每次新装TDengine后都会做的三件事列出来算是一个“清单式”的习惯修改root密码创建业务专用账号并授权。检查taosd服务是否设置开机自启systemctl is-enabled taosd查看一次基础监控指标比如服务运行时间、连接数、内存占用SHOW DNODES; SHOW MNODES; SHOW DATABASES;这三件事做完一个单机TDengine实例基本就可以安心交付给业务了。回想起来我第一次把TDengine装到生产环境时最大的感觉是这东西比传统数据库“轻”太多了但轻不等于简单它有自己的设计哲学和注意事项。希望这篇分享能帮助你更快地度过初期部署时的摸索阶段。后面有机会我再接着写数据建模、集群部署、数据备份恢复这些更进阶的实操内容咱们一步步来。