腾讯云国际版时序数据库 CTSDB 3.0 实战：InfluxQL 兼容、八大核心概念、真实单价与写入性能实测（2026最新）

Meta Description: 腾讯云国际版有没有时序数据库？有，叫 TencentDB for CTSDB 3.0。本文用官方公开单价表讲清它的计费公式（时序节点按内存 GB 计价、数据节点按节点数计价）、2核8G/4核16G/8核32G 三档规格、9 个数据节点起步的硬门槛、广州与新加坡两套最小配置月成本测算、41,324,262 metrics/s 的官方写入压测数据，以及从控制台建库到 Telegraf 采集、Grafana 出图的完整实操链路和八大核心概念，2026 年照着做就行。

关键词：腾讯云国际版时序数据库、TencentDB for CTSDB、CTSDB 3.0、InfluxQL、时序数据库价格、数据节点、时序节点、Telegraf、Grafana、国际版数据库选型

声明：本文价格数据采集于2026年10月，取自腾讯云国际站官方文档与定价页（USD 口径），仅供参考，价格可能变动，请以腾讯云官网为准。

一句话答案：腾讯云国际版的时序数据库叫 TencentDB for CTSDB 3.0（产品文档目录 ID 1100），它是基于 InfluxDB 1.7 模型、兼容 InfluxQL 的全托管时序数据库，写入走 8086 端口的 HTTP 行协议（line protocol），最低配置是 3 个时序节点 + 9 个数据节点，只支持包月订阅、不支持按量计费，最小配置在国内三区（北京/上海/广州）约 3,514 USD/月、在新加坡/法兰克福约 4,217 USD/月。它适合的是「带时间戳、只追加不修改、写得极快、按时间段聚合查询」的那类数据——车联网轨迹、IoT 传感器上报、运维监控指标。如果你是第一次接触时序库，可以先记住一句话：关系库存「现在是什么状态」，时序库存「过去每一秒发生了什么」。

一、先划边界：这篇和站内另外四篇数据库文章有什么不同

腾讯云国际版的数据库家族，按数据模型已经被拆成了五瓣，站内此前写过四瓣，这一篇补的是最后、也是最容易被当成「MySQL 加个时间字段」的那一瓣——时序型。

一句话区分四者：

• 数据列数固定、要强一致和复杂 JOIN → MySQL；
• 只做热点缓存、KV 读多写多 → Redis；
• 单表大到一亿行以上、要水平分片 → TDSQL；
• 文档字段各不相同、有嵌套数组、结构不稳定 → MongoDB；
• 数据永远带着时间戳进来、写进来就不再改、查询永远是「某个时间段内的聚合」 → CTSDB。

📌 判据口诀：「这条数据会不会被修改？」会改、要更新某一行 → MySQL/TDSQL；只写不改、且必带时间戳 → CTSDB。「查询里有没有 GROUP BY time(...)？」有 → CTSDB。

还有一条更直观的判断：如果你正在做的事是「把 MySQL 里按天分表的监控表删掉、换成专门的东西」，那你需要的多半就是 CTSDB。关系型数据库存时序数据的三个典型症状是——单个时间字段上建索引却越查越慢、表一天涨几千万行、定期删历史数据要写一堆清理脚本，而这恰好是时序库被造出来要解决的三个问题。

二、CTSDB 3.0 是什么：云原生架构 + 八大核心概念

官方对 CTSDB 3.0 的架构描述是「云原生架构、计算与存储分离」：数据统一通过网关写入，在数据请求层和存储层都做了资源池化；计算节点按需横向扩容，存储单元动态调整；数据会自动分层，按冷热程度分别存放在内存、磁盘、冷存储三级介质中，并自动均衡。翻译成人话就是——你买的是「算力 + 容量」两个旋钮，而不是一堆需要自己规划的机器。

要看懂后面的规格和价格，必须先掌握八个概念。它们不复杂，但决定了你的钱花在哪：

这里有两个直接影响成本和性能的关键点，是新手最容易踩的：

第一，Tag 和 Field 的分工不是可选项，是性能开关。官方文档明确写了：Tag 会被索引，所以按 Tag 过滤和 GROUP BY Tag 都比 Field 快得多；而 Field 的读写需要聚合计算，存储和查询开销更高，会消耗更多 CPU 和内存。判断标准是三句话——「要用来筛选 / 分组 / 做 GROUP BY 的，放 Tag；要做数学计算、算平均值最大值最小值的，放 Field；已经在 Tag 里的数据不要再往 Field 存一份。」

第二，千万别用下划线给 Field 命名。官方文档专门提醒：InfluxDB 用下划线来分隔 Field 与 Tag，所以命名时应当用连字符 - 而不是下划线 _，否则会和行协议的字段分隔符冲突。同理，Measurement 名建议全小写、用连字符分词、避免特殊字符。

官方还给了 RP（保留策略）的默认行为：每个数据库在创建时会自动生成一个默认保留策略，数据保留时间设为「永久」，之后你可以自己改成「只保留最近 N 天」。如果插入和查询时没有指定策略，用的就是默认策略。这一点很关键——默认永久保留意味着如果你不主动设 TTL，历史数据会一直堆着，而它们是要占存储的。

三、规格与购买限制：下单前必须搞清楚的五条硬规则

CTSDB 3.0 只有一种实例类型——Dedicated（独享型），官方说法是「提供更强的集群性能与容量，支持 PB 级运行」。它由两类节点拼成一台实例：时序节点（算力）+ 数据节点（容量）。

时序节点规格（负责计算）：

官方购买页给出的时序节点数量取值范围是 3–32（规格页同时标注了上限 64，以控制台实际可选为准）。

数据节点规格（负责存储）：官方固定为 15 核 60 GB，你没有选择的余地；可选数量必须是 9 的倍数——购买页列出的是 9 / 18 / 27 / 36 / 45 / 54，规格页给出的一般范围是 [9, 18, …, 2160]。单个数据节点的存储容量是 3,000 GB，所以总容量 = 数据节点数 × 3,000 GB。

下单前必须知道的五条硬规则：

1. 只能包月订阅。 CTSDB 3.0 目前只有一种计费模式——包月（预付费），独享实例不支持按量付费。这意味着没有「先跑一小时看看」的低成本试错路径。
2. 数据节点 9 个起步。 这是全篇最重要的成本悬崖：哪怕你的业务每天只写一百万条，也必须先买 9 个数据节点，也就是 27,000 GB ≈ 26.4 TiB 的存储底座。
3. 可用区固定多可用区（Multi-AZ）。 购买时可用区不可选，系统固定为多可用区部署。好处是自带跨 AZ 高可用，代价是成本里已经含了容灾，别指望通过选单 AZ 省钱。
4. 一个账号只能买一个实例。 官方购买页明确写了「Currently, an account can only purchase one instance」。多环境隔离要用 VPC/子网或标签来做，而不是再开第二台。
5. 最长可买 5 年，可按整月或整年购买，支持自动续费。

另外有一条很实用但容易被忽略的规则：网络必须选 VPC 和子网，且推荐与 CVM 同地域同 VPC——因为 CTSDB 走的是私网访问，用内网高速通道连接，延迟低且不产生公网流量费。

四、价格与计费：官方公开单价全表

CTSDB 3.0 的计费公式只有一行：

独享实例费用 = 时序节点费用 + 数据节点费用

拆开看：

• 时序节点费用 = 时序节点数量 × 单节点月费 × 购买时长
• 数据节点费用 = 数据节点数量 × 单数据节点月费 × 购买时长

这里最关键的一个设计是：两类节点的计价口径完全不同。

时序节点按内存容量线性计价——费用 = 实例规格对应的总内存容量 × 所在地域的每 GB 月单价。官方原文举例：某地域单价为 9.28571429 USD/GB/月时，一个 8 GB 内存的节点月费 = 9.28571429 × 8 = 74.28571431 USD；不同规格的节点费用随内存容量线性变化。

数据节点按节点数量计价——费用 = 节点数 × 所在地域的单节点月单价，与单节点内部规格无关（因为规格固定 15 核 60 GB）。

官方公开单价表：

这张表里藏着一个非常整齐的规律，值得单独拎出来说：两个地域的两类节点价差系数完全一致——11.142857 ÷ 9.28571429 = 1.2，438.85714286 ÷ 365.71428571 = 1.2。也就是说，新加坡和法兰克福相对国内三区，时序节点和数据节点一律贵 20%，没有「某类节点更贵」的错配。因此地域选择是一次纯粹的整体系数决策：能放在广州就不要放新加坡，直接省 20%，且在节点配比上没有任何可以「巧妙规避」的空间。

官方算例复现（广州，3 个 16 核 64 GB 时序节点 + 9 个数据节点，购买 3 个月）：

• 时序节点费用 = 3 × (64 × 9.28571429) × 3 = 5,348.57143104 USD
• 数据节点费用 = 9 × 365.71428571 × 3 = 9,874.28571417 USD
• 实例总费用 = 5,348.57143104 + 9,874.28571417 = 15,222.85714521 USD

最小配置月成本测算（3 个 2 核 8 GB 时序节点 + 9 个数据节点，包月）：

这张测算表最重要的结论不是那个 3,514 的数字，而是它的构成：数据节点（3,291.43）占了最小配置账单的 93.7%，时序节点只占 6.3%。

这条推论直接改变了省钱的方向：在 CTSDB 上压缩计算规格几乎没用——把时序节点从 2 核 8 GB 换到 4 核 16 GB，月成本也只从 3,514 涨到 3,737（+6.3%）；真正决定账单量级的是数据节点数量和地域系数这两个变量，而它们又分别被「9 个起步」和「20% 地区差」两条规则锁死。所以这是一款买入门槛高、扩容边际成本平滑、但几乎没有「小幅降配」空间的产品——选型时先把年预算（最小配置约 4.2 万美元/年，广州）算清楚，再谈架构。

规模升级的成本曲线（广州，均为 9 个数据节点）：

可以看到：计算规格翻 8 倍（2 核 8 G → 16 核 64 G），总账单只涨 44.4%。这在一众「算力涨价、账单翻倍」的云产品里相当少见，也再次印证了那句话——在 CTSDB 里，钱主要花在容量底座上。

五、性能实测：官方白皮书里的写入与查询数据

买之前最该看的不是功能列表，而是压测白皮书。CTSDB 官方公布了一套基于 TSBS（Time Series Benchmark Suite） 的性能测试，测的是最硬的两个指标：每秒能写多少个数据点（metrics/s） 和 每秒能回答多少个查询（QPS）+ 延迟。

写入性能（测试规格：3 × 16 核 64 GB 时序节点，批量大小默认 10,000 行）：

这张表最有价值的读法不是看最大值的「四千一百万」，而是看曲线的形状：并发从 1 提到 5，吞吐量涨了 4.17 倍；从 5 到 10 只涨 27.6%；10 并发之后基本饱和，10 → 40 并发吞吐只再涨 15.2%，而客户端资源却翻了 4 倍。这说明——

📌 写入吞吐在约 10 个并发写入客户端时就已经接近饱和，再往上加并发只是徒增客户端负担。如果你的写入端出现「加线程也不涨速」的现象，不要怀疑数据库，先看是不是早过了 10 并发的拐点。

查询性能（4 种查询类型，每种测 80/160/240/320 四档并发）：

同样，延迟那一列才是重点：单机单指标的查询在 320 并发下平均延迟仍是 15 毫秒，最快的 6.56 毫秒；但从「1 台主机」扩到「8 台主机」后，同样是 320 并发，QPS 从 21,080 掉到 6,853（降 67%）、平均延迟从 15.09 ms 涨到 46.37 ms（约 3.1 倍）。这符合时序库的通用规律——查询范围（Series 数量）比查询并发更能吃掉性能。做监控大盘时，一张图上挂 8 台机器的曲线，比同时开 8 个只有 1 台机器的图要贵得多。

顺带一提，官方也公开了测试方法，你可以自己复现。写入测试用的工具和参数如下（示例命令）：

// 用 TSBS 的写入压测工具，10 并发，10000 行一批
cat data/influx-data-cpu-10000-30day.gz | gunzip | ./tsbs_load_influx \
  --urls=http://10.0.1.45:8086 \
  --db-name=test \
  --workers=10 \
  --user=ctsdbi-mjhiaefp \
  --password='你的密码' \
  --do-create-db=false

⚠️ 提醒：官方示例里 --workers 的调参建议是从 4–8 起步、逐步加大到吞吐不再提升；批量大小默认 10,000 行，太小会增加网络开销，太大则增加内存压力。照着这两个参数调，基本就能复现出上表的形状。

六、8 步实操：从控制台建库到 Grafana 出图

前面是「要不要买」，这一节是「买完怎么跑通」。整条链路是：买实例 → 配安全组 → 备一台同 VPC 的 CVM → 建库 → 写数据 → 查数据 → Telegraf 采集 → Grafana 出图。

第 1 步：购买实例

登录控制台进入 CTSDB，点新建。按官方购买页的参数清单，需要确认这些项：

第 2 步：配置安全组

CTSDB 走私网访问，默认端口 8086。需要双向放行：

• 在 CTSDB 的安全组入站规则里，加入 CVM 的内网 IP 与端口；
• 在 CVM 的安全组出站规则里，加入 CTSDB 的内网 IP 与端口。

这两条缺一条都会连不上，而且报错通常只是超时，很容易误判成"数据库没起来"。

第 3 步：准备一台同 VPC 的 CVM

在与 CTSDB 相同地域、相同 VPC 下购买一台 Linux CVM，登录后用它作为客户端。官方给出的私有网络地址形如 http://10.x.x.x:8086。注意：CTSDB 只能通过 VPC 访问；如果你的机器在基础网络，需要通过 Classiclink 打通。

第 4 步：建库（带 TTL 更好）

用 HTTP API 执行 InfluxQL 的 CREATE DATABASE，语法支持带 DURATION（即 TTL，单位天，必须是非零整数）：

// 建一个 180 天后自动清理的库
curl --get http://10.0.1.45:8086/query \
  --user "ctsdbi-xxxxxxxx":"你的密码" \
  --data-urlencode "pretty=true" \
  --data-urlencode 'q=CREATE DATABASE time_series_test_db WITH DURATION 180d'

DURATION 180d 的意思是数据超过 180 天由系统自动删除。开 TTL 是在 CTSDB 上最省心的一条省钱动作——你不需要写任何清理脚本，过期数据由系统定期清理。

第 5 步：写入数据（行协议）

CTSDB 3.0 用 InfluxDB 的行协议（line protocol）写入，格式是 measurement,tag=value field=value timestamp。官方示例是车联网数据：

car,id=0,city=city_0,type=type_0 speed=100,temp=20 1675236656000000000
car,id=1,city=city_1,type=type_1 speed=101,temp=21 1675236656000000000
car,id=2,city=city_0,type=type_2 speed=102,temp=22 1675236656000000000

一条数据点由三部分组成：测量名 car + 标签 id/city/type + 字段 speed/temp，末尾是纳秒时间戳。注意这里的 id、city、type 是放在逗号后的标签位置（会被索引），speed、temp 是空格后的字段位置（会被聚合计算）——这正是第二节讲的 Tag/Field 分工在真实数据上的样子。

第 6 步：查询数据

同样走 8086 端口的 HTTP API，用 InfluxQL：

// 查最近 1 小时 server1 的 CPU 空闲率均值
curl --get http://10.0.1.45:8086/query \
  --user "ctsdbi-xxxxxxxx":"你的密码" \
  --data-urlencode "db=cpu_data" \
  --data-urlencode "q=SELECT MEAN(\"usage_idle\") FROM \"cpu\" WHERE \"server\" = 'server1' AND time >= now() - 1h"

SELECT MEAN(...) 就是聚合——把一段时间内的多个数据点合并成一个结果，与时序库最匹配的查询方式。常用的还有 MAX / MIN / SUM，以及按 GROUP BY time(...) 做时间分桶。官方还提供了 influx CLI 客户端和 SDK，熟悉 InfluxDB 的同学可以直接沿用原有工具链。

第 7 步：用 Telegraf 自动采集

手工写数据只适合验证，生产上通常用 Telegraf 采集主机指标直接打进 CTSDB。三步：

// 1. 在 CVM 上安装 Telegraf（CentOS 走 yum 仓库）
// 2. 生成默认配置
telegraf config > /etc/telegraf.conf

// 3. 编辑 /etc/telegraf.conf，把输出指向 CTSDB

配置里最关键的 [[outputs.influxdb]] 段落如下：

[[outputs.influxdb]]
  urls = ["http://10.1.98.53:8086"]
  database = "replicaset"
  skip_database_creation = true
  exclude_database_tag = true
  exclude_retention_policy_tag = true
  content_encoding = "identity"
  timeout = "5s"
  username = "ctsdbi-s0u*****"
  password = "*********"

几个坑点：skip_database_creation = true（数据库提前建好，别让 Telegraf 建）、content_encoding = "identity"（官方示例里明确要求，别用默认的 gzip）、exclude_database_tag / exclude_retention_policy_tag 都设为 true。启动后执行 show measurements 确认数据已写入：

telegraf --config /etc/telegraf.conf

第 8 步：用 Grafana 出图

Grafana 直接支持 InfluxDB 数据源，加一条即可。关键参数：

配置完点 Save & test，出现 datasource is working. 1 measurements found 就说明通了。

⚠️ 两个官方明确指出的坑：① Grafana（或腾讯云托管 Grafana TCMG）必须与 CTSDB 在同一个 VPC，否则网络不通；② 目前 CTSDB 3.0 尚不支持 show retention policies 接口，Grafana 添加数据源时会报一个 Network Error: Bad Request (400)——这个报错可以忽略，数据源依然能正常添加和使用，别在这里卡住。

七、备份、续费与欠费回收时间线

备份：CTSDB 3.0 支持自动备份，但官方明确写了——目前仅支持系统默认的自动备份策略，不支持自定义备份策略。你可以在控制台的「备份列表」页签查看某个时间段内的全部备份信息、点开「自动备份设置」查看系统默认策略，但不能改频率或保留时长。这意味着「备份策略可调」这个在许多云数据库上是标配的能力，在 CTSDB 3.0 上暂时没有，选型时如果合规要求你必须自定义备份窗口，这一点要先确认。

到期与欠费：CTSDB 走包月订阅，回收时间线和其他包月 TencentDB 一致：

一句话记住：到期后有整整 14 天的缓冲期可以续费救回来（前 7 天还能用、后 7 天停机但可恢复），第 15 天数据就没了。续费的起始时间是上一周期的到期时间，不会因为拖了几天而把缺口补成新的周期起点；开了自动续费且余额充足的实例会照常自动续。

退款：每个主体默认享有一次 5 天内的无条件全额退款，其余退款按非全额处理。普通自助退还的金额计算公式是：退款金额 = 当前生效订单金额 + 未开始订单金额 − 已使用资源价值——已使用部分，满一个月按整月扣、不满一个月按实际使用时长扣、不足一小时按一小时计。实例自助退还后进入「待终止」状态，保留 7 天，这 7 天内不可访问但可以通过「启动」恢复；超过保留期则彻底终止、IP 释放、不可恢复。注意两点：抵扣的代金券不可退，退款会按现金与赠送金的比例退回账户余额。

📌 这条规则对 CTSDB 3.0 特别重要，因为它是「只能包月、一个账号一个实例、最小配置就要 3,514 USD/月」的产品。5 天全额退款窗口是你唯一的低成本试错通道——真要用，就把它当成一次「五天付费试用」来规划：第一天买、第二天建库导数据、第三到五天跑真实压测，不满意在第五天之前退掉。

八、成本优化：六条能真正省钱的动作

1. 地域就近就低。新加坡/法兰克福比北京/上海/广州贵整整 20%，且两类节点同系数。业务不在境外就别选境外，一年省约 8,434 美元（按最小配置算：50,605.71 − 42,171.43 ≈ 8,434 USD）。
2. 别指望缩计算节点省钱。数据节点占最小配置账单的 93.7%，时序节点只占 6.3%。想降本，先看数据节点数量和 TTL，不是先降 CPU 规格。
3. 建库时就开 TTL（DURATION）。默认保留策略是「永久」，意味着历史数据永远在涨、永远在占你花 3,291 USD/月买来的那 27 TB 里。建库时写 WITH DURATION 180d，让系统自动清过期数据——这是零成本、零脚本的一条硬省钱动作。
4. 按容量而不是按写入量定数据节点数。单节点 3,000 GB，9 个就是 27,000 GB。先算「日增数据量 × 保留天数 × 压缩后系数」，再决定要不要从 9 加到 18；压缩比是时序库的强项（重复维度 + 平滑变化的指标值），所以按原始行数估容量会高估一截。
5. 不在最小配置上做精确计算。数据节点 9 个起步、时序节点 3 个起步，已经决定了月度下限量级；如果你的业务量远小于这个底盘，CTSDB 3.0 不是性价比之选——转用 CLS（日志服务）或自建 InfluxDB/自建 Prometheus 更划算。选型要诚实面对这条门槛。
6. 写入端并发控制在 10 左右。官方压测显示 10 并发吞吐已达 3,587 万点/秒、40 并发只再涨 15.2%。多开的写入线程解决不了问题，只会占满客户端 CPU。要提吞吐，往「加时序节点」而不是「加并发」上想。

十、总结与延伸阅读

把这篇压成五句话：

1. 产品定位：腾讯云国际版的时序数据库就是 TencentDB for CTSDB 3.0（文档目录 ID 1100），基于 InfluxDB 1.7 模型、兼容 InfluxQL、走 8086 端口的 HTTP 行协议写入，适合车联网、IoT、运维监控这三类「带时间戳、只追加、按时间段聚合」的场景。
2. 规格门槛：时序节点 2核8G / 4核16G / 8核32G，3 个起；数据节点固定 15核60GB，9 个起、且必须是 9 的倍数，单节点 3,000 GB；可用区固定多可用区；一个账号只能买一个实例。
3. 价格：只能包月、不支持按量。时序节点按内存计价（国内三区 9.28571429 USD/GB/月），数据节点按节点数计价（国内三区 365.71428571 USD/节点/月）；新加坡/法兰克福一律贵 20%。最小配置约 3,514 USD/月（国内三区）/ 4,217 USD/月（境外）。
4. 成本真相：数据节点占了最小配置账单的 93.7%——钱花在容量底座上，不在算力上。降本顺序是「选对地域 → 开 TTL → 控数据节点数」，而不是缩 CPU。
5. 性能与运维：官方压测写入峰值 41,324,262 点/秒（3×16核64G、40 并发），但约 10 并发就已接近饱和；查询 320 并发下单机单指标平均延迟约 15 ms，而查询范围扩到 8 台主机后 QPS 掉 67%。备份仅支持系统默认策略；到期后有 14 天缓冲，且每个主体有一次 5 天无条件全额退款——这就是你唯一的低成本试错窗口。

如果你想继续对比站内相邻的几篇，它们和本篇正好构成「数据库家族」的完整地图：

• 文档型（JSON 结构）： 腾讯云国际版 MongoDB 文档数据库实战
• 分布式关系型（分库分表）： 分布式数据库 TDSQL for MySQL 实战
• 日志与可观测（和本篇互补的另一半）： 日志服务 CLS 实战

🚀 需要海外云服务器？通过 4.chengzicloud.cloud 访问首页，查看腾讯云国际版 CVM、Lighthouse 与数据库的完整选型与省钱攻略。

本文由 4.chengzicloud.cloud 提供，点击访问首页了解更多