Merge pull request #30009 from taosdata/doc/contrib
docs: minor changes
This commit is contained in:
Simon Guan
GitHub
commit
0a30cb17ff
|
|
@ -4,19 +4,19 @@ sidebar_label: 文档首页
|
|||
slug: /
|
||||
---
|
||||
|
||||
TDengine 是一款[开源](https://www.taosdata.com/tdengine/open_source_time-series_database)、[高性能](https://www.taosdata.com/fast)、[云原生](https://www.taosdata.com/tdengine/cloud_native_time-series_database)的<a href="https://www.taosdata.com/" data-internallinksmanager029f6b8e52c="2" title="时序数据库" target="_blank" rel="noopener">时序数据库</a>（<a href="https://www.taosdata.com/time-series-database" data-internallinksmanager029f6b8e52c="9" title="Time Series DataBase" target="_blank" rel="noopener">Time Series Database</a>, <a href="https://www.taosdata.com/tsdb" data-internallinksmanager029f6b8e52c="8" title="TSDB" target="_blank" rel="noopener">TSDB</a>）, 它专为物联网、车联网、工业互联网、金融、IT 运维等场景优化设计。同时它还带有内建的缓存、流式计算、数据订阅等系统功能，能大幅减少系统设计的复杂度，降低研发和运营成本，是一款极简的时序数据处理平台。本文档是 TDengine 的用户手册，主要是介绍 TDengine 的基本概念、安装、使用、功能、开发接口、运营维护、TDengine 内核设计等等，它主要是面向架构师、开发工程师与系统管理员的。如果你对时序数据的基本概念、价值以及其所能带来的业务价值尚不了解，请参考[时序数据基础](./concept)。
|
||||
TDengine 是一款 [开源](https://www.taosdata.com/tdengine/open_source_time-series_database)、[高性能](https://www.taosdata.com/fast)、[云原生](https://www.taosdata.com/tdengine/cloud_native_time-series_database) 的<a href="https://www.taosdata.com/" data-internallinksmanager029f6b8e52c="2" title="时序数据库" target="_blank" rel="noopener">时序数据库</a>（<a href="https://www.taosdata.com/time-series-database" data-internallinksmanager029f6b8e52c="9" title="Time Series DataBase" target="_blank" rel="noopener">Time Series Database</a>, <a href="https://www.taosdata.com/tsdb" data-internallinksmanager029f6b8e52c="8" title="TSDB" target="_blank" rel="noopener">TSDB</a>）, 它专为物联网、车联网、工业互联网、金融、IT 运维等场景优化设计。同时它还带有内建的缓存、流式计算、数据订阅等系统功能，能大幅减少系统设计的复杂度，降低研发和运营成本，是一款极简的时序数据处理平台。本文档是 TDengine 的用户手册，主要是介绍 TDengine 的基本概念、安装、使用、功能、开发接口、运营维护、TDengine 内核设计等等，它主要是面向架构师、开发工程师与系统管理员的。如果你对时序数据的基本概念、价值以及其所能带来的业务价值尚不了解，请参考 [时序数据基础](./concept)。
|
||||
|
||||
TDengine 充分利用了时序数据的特点，提出了“一个数据采集点一张表”与“超级表”的概念，设计了创新的存储引擎，让数据的写入、查询和存储效率都得到极大的提升。为正确理解并使用 TDengine，无论你在工作中是什么角色，请您仔细阅读[数据模型](./basic/model)一章。
|
||||
TDengine 充分利用了时序数据的特点，提出了“一个数据采集点一张表”与“超级表”的概念，设计了创新的存储引擎，让数据的写入、查询和存储效率都得到极大的提升。为正确理解并使用 TDengine，无论你在工作中是什么角色，请您仔细阅读 [数据模型](./basic/model) 一章。
|
||||
|
||||
如果你是开发工程师，请一定仔细阅读[开发指南](./develop)一章，该部分对数据库连接、建模、写入、查询、流式计算、缓存、数据订阅、用户自定义函数等功能都做了详细介绍，并配有各种编程语言的示例代码。大部分情况下，只要复制粘贴示例代码，针对自己的应用稍作改动，就能跑起来。对 REST API、各种编程语言的连接器（Connector）想做更多详细了解，请看[连接器](./reference/connector)一章。
|
||||
如果你是开发工程师，请一定仔细阅读 [开发指南](./develop) 一章，该部分对数据库连接、建模、写入、查询、流式计算、缓存、数据订阅、用户自定义函数等功能都做了详细介绍，并配有各种编程语言的示例代码。大部分情况下，只要复制粘贴示例代码，针对自己的应用稍作改动，就能跑起来。对 REST API、各种编程语言的连接器（Connector）想做更多详细了解，请看 [连接器](./reference/connector) 一章。
|
||||
|
||||
我们已经生活在大数据时代，纵向扩展已经无法满足日益增长的业务需求，任何系统都必须具有水平扩展的能力，集群成为大数据以及 Database 系统的不可缺失功能。TDengine 团队不仅实现了集群功能，而且将这一重要核心功能开源。怎么部署、管理和维护 TDengine 集群，请仔细参考[运维管理](./operation)一章。
|
||||
我们已经生活在大数据时代，纵向扩展已经无法满足日益增长的业务需求，任何系统都必须具有水平扩展的能力，集群成为大数据以及 Database 系统的不可缺失功能。TDengine 团队不仅实现了集群功能，而且将这一重要核心功能开源。怎么部署、管理和维护 TDengine 集群，请仔细参考 [运维管理](./operation) 一章。
|
||||
|
||||
TDengine 采用 SQL 作为查询语言，大大降低学习成本、降低迁移成本，但同时针对时序数据场景，又做了一些扩展，以支持插值、降采样、时间加权平均等操作。[SQL 手册](./reference/taos-sql)一章详细描述了 SQL 语法、详细列出了各种支持的命令和函数。
|
||||
TDengine 采用 SQL 作为查询语言，大大降低学习成本、降低迁移成本，但同时针对时序数据场景，又做了一些扩展，以支持插值、降采样、时间加权平均等操作。[SQL 手册](./reference/taos-sql) 一章详细描述了 SQL 语法、详细列出了各种支持的命令和函数。
|
||||
|
||||
如果你是系统管理员，关心安装、升级、容错灾备、关心数据导入、导出、配置参数，如何监测 TDengine 是否健康运行，如何提升系统运行的性能，请仔细参考[运维指南](./operation)一章。
|
||||
如果你是系统管理员，关心安装、升级、容错灾备、关心数据导入、导出、配置参数，如何监测 TDengine 是否健康运行，如何提升系统运行的性能，请仔细参考 [运维指南](./operation) 一章。
|
||||
|
||||
如果你对数据库内核设计感兴趣，或是开源爱好者，建议仔细阅读[技术内幕](./tdinternal)一章。该章从分布式架构到存储引擎、查询引擎、数据订阅，再到流计算引擎都做了详细阐述。建议对照文档，查看 TDengine 在 GitHub 的源代码，对 TDengine 的设计和编码做深入了解，更欢迎加入开源社区，贡献代码。
|
||||
如果你对数据库内核设计感兴趣，或是开源爱好者，建议仔细阅读 [技术内幕](./tdinternal) 一章。该章从分布式架构到存储引擎、查询引擎、数据订阅，再到流计算引擎都做了详细阐述。建议对照文档，查看 TDengine 在 GitHub 的源代码，对 TDengine 的设计和编码做深入了解，更欢迎加入开源社区，贡献代码。
|
||||
|
||||
最后，作为一个开源软件，欢迎大家的参与。如果发现文档有任何错误、描述不清晰的地方，请在每个页面的最下方，点击“编辑本文档”直接进行修改。
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ toc_max_heading_level: 4
|
|||
|
||||
TDengine 是一个高性能、分布式的时序数据库。通过集成的缓存、数据订阅、流计算和数据清洗与转换等功能，TDengine 已经发展成为一个专为物联网、工业互联网、金融和 IT 运维等关键行业量身定制的时序大数据平台。该平台能够高效地汇聚、存储、分析、计算和分发来自海量数据采集点的大规模数据流，每日处理能力可达 TB 乃至 PB 级别。借助 TDengine，企业可以实现实时的业务监控和预警，进而发掘出有价值的商业洞察。
|
||||
|
||||
自 2019 年 7 月 以来， 涛思数据陆续将 TDengine 的不同版本开源，包括单机版（2019 年 7 月）、集群版（2020 年 8 月）以及云原生版（2022 年 8 月）。开源之后，TDengine 迅速获得了全球开发者的关注，多次在 GitHub 网站全球趋势排行榜上位居榜首，最新的关注热度见[涛思数据首页](https://www.taosdata.com/)。
|
||||
自 2019 年 7 月 以来， 涛思数据陆续将 TDengine 的不同版本开源，包括单机版（2019 年 7 月）、集群版（2020 年 8 月）以及云原生版（2022 年 8 月）。开源之后，TDengine 迅速获得了全球开发者的关注，多次在 GitHub 网站全球趋势排行榜上位居榜首，最新的关注热度见 [涛思数据首页](https://www.taosdata.com/)。
|
||||
|
||||
## TDengine 产品
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ TDengine OSS 是一个开源的高性能时序数据库，与其他时序数据
|
|||
|
||||
在 TDengine OSS 的基础上，TDengine Enterprise 提供了增强的辅助功能，包括数据的备份恢复、异地容灾、多级存储、视图、权限控制、安全加密、IP 白名单、支持 MQTT、OPC-UA、OPC-DA、PI、Wonderware、Kafka 等各种数据源。这些功能为企业提供了更为全面、安全、可靠和高效的时序数据管理解决方案。更多的细节请看 [TDengine Enterprise](https://www.taosdata.com/tdengine-pro)。
|
||||
|
||||
此外，TDengine Cloud 作为一种全托管的云服务，存储与计算分离，分开计费，为企业提供了企业级的工具和服务，彻底解决了运维难题，尤其适合中小规模的用户使用。更多的细节请看[TDengine 云服务](https://cloud.taosdata.com/?utm_source=menu&utm_medium=webcn)
|
||||
此外，TDengine Cloud 作为一种全托管的云服务，存储与计算分离，分开计费，为企业提供了企业级的工具和服务，彻底解决了运维难题，尤其适合中小规模的用户使用。更多的细节请看 [TDengine 云服务](https://cloud.taosdata.com/?utm_source=menu&utm_medium=webcn)。
|
||||
|
||||
## TDengine 主要功能与特性
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ toc_max_heading_level: 4
|
|||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
TDengine 对 SQL 语言提供了全面的支持，允许用户以熟悉的 SQL 语法进行数据的查询、插入和删除操作。 TDengine 的 SQL 还支持对数据库和数据表的管理操作，如创建、修改和删除数据库及数据表。TDengine 扩展了标准 SQL，引入了时序数据处理特有的功能，如时间序列数据的聚合查询、降采样、插值查询等，以适应时序数据的特点。这些扩展使得用户可以更高效地处理时间序列数据，进行复杂的数据分析和处理。 具体支持的 SQL 语法请参考 [TDengine SQL](../../reference/taos-sql/)
|
||||
TDengine 对 SQL 语言提供了全面的支持，允许用户以熟悉的 SQL 语法进行数据的查询、插入和删除操作。TDengine 的 SQL 还支持对数据库和数据表的管理操作，如创建、修改和删除数据库及数据表。TDengine 扩展了标准 SQL，引入了时序数据处理特有的功能，如时间序列数据的聚合查询、降采样、插值查询等，以适应时序数据的特点。这些扩展使得用户可以更高效地处理时间序列数据，进行复杂的数据分析和处理。具体支持的 SQL 语法请参考 [TDengine SQL](../../reference/taos-sql/)
|
||||
|
||||
下面介绍使用各语言连接器通过执行 SQL 完成建库、建表、写入数据和查询数据。
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ curl --location -uroot:taosdata 'http://127.0.0.1:6041/rest/sql/power' \
|
|||
```
|
||||
|
||||
**Note**
|
||||
NOW 为系统内部函数，默认为客户端所在计算机当前时间。 NOW + 1s 代表客户端当前时间往后加 1 秒，数字后面代表时间单位：a（毫秒），s（秒），m（分），h（小时），d（天），w（周），n（月），y（年）。
|
||||
NOW 为系统内部函数，默认为客户端所在计算机当前时间。NOW + 1s 代表客户端当前时间往后加 1 秒，数字后面代表时间单位：a（毫秒），s（秒），m（分），h（小时），d（天），w（周），n（月），y（年）。
|
||||
|
||||
|
||||
</TabItem>
|
||||
|
|
@ -160,7 +160,7 @@ NOW 为系统内部函数，默认为客户端所在计算机当前时间。 NOW
|
|||
```
|
||||
|
||||
**Note**
|
||||
NOW 为系统内部函数，默认为客户端所在计算机当前时间。 NOW + 1s 代表客户端当前时间往后加 1 秒，数字后面代表时间单位：a（毫秒），s（秒），m（分），h（小时），d（天），w（周），n（月），y（年）。
|
||||
NOW 为系统内部函数，默认为客户端所在计算机当前时间。NOW + 1s 代表客户端当前时间往后加 1 秒，数字后面代表时间单位：a（毫秒），s（秒），m（分），h（小时），d（天），w（周），n（月），y（年）。
|
||||
</TabItem>
|
||||
<TabItem label="REST API" value="rest">
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ import TabItem from "@theme/TabItem";
|
|||
|
||||
## 无模式写入行协议
|
||||
|
||||
TDengine 的无模式写入行协议兼容 InfluxDB 的行协议、OpenTSDB 的 telnet 行协议和 OpenTSDB 的 JSON 格式协议。InfluxDB、OpenTSDB 的标准写入协议请参考各自的官方文档。
|
||||
TDengine 的无模式写入行协议兼容 InfluxDB 的行协议、OpenTSDB 的 TELNET 行协议和 OpenTSDB 的 JSON 格式协议。InfluxDB、OpenTSDB 的标准写入协议请参考各自的官方文档。
|
||||
|
||||
下面首先以 InfluxDB 的行协议为基础，介绍 TDengine 扩展的协议内容。该协议允许用户采用更加精细的方式控制（超级表）模式。采用一个字符串来表达一个数据行，可以向写入 API 中一次传入多行字符串来实现多个数据行的批量写入，其格式约定如下。
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ tag_set 中的所有的数据自动转化为 nchar 数据类型，并不需要
|
|||
在无模式写入数据行协议中，field_set 中的每个数据项都需要对自身的数据类型进行描述，具体要求如下。
|
||||
- 如果两边有英文双引号，表示 varchar 类型，例如 "abc"。
|
||||
- 如果两边有英文双引号而且带有 L 或 l 前缀，表示 nchar 类型，例如 L" 报错信息 "。
|
||||
- 如果两边有英文双引号而且带有 G 或 g 前缀， 表 示 geometry 类型， 例 如G"Point(4.343 89.342)"。
|
||||
- 如果两边有英文双引号而且带有 G 或 g 前缀，表示 geometry 类型，例如 G"Point(4.343 89.342)"。
|
||||
- 如果两边有英文双引号而且带有 B 或 b 前缀，表示 varbinary 类型，双引号内可以为 \x 开头的十六进制或者字符串，例如 B"\x98f46e" 和 B"hello"。
|
||||
- 对于空格、等号（=）、逗号（,）、双引号（"）、反斜杠（\），前面需要使用反斜杠（\）进行转义（均为英文半角符号）。无模式写入协议的域转义规则如下表所示。
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ tag_set 中的所有的数据自动转化为 nchar 数据类型，并不需要
|
|||
| 4 | 列名 | 逗号，等号，空格 |
|
||||
| 5 | 列值 | 双引号，反斜杠 |
|
||||
|
||||
如果使用两个连续的反斜杠，则第1个反斜杠作为转义符，当只有一个反斜杠时则无须转义。无模式写入协议的反斜杠转义规则如下表所示。
|
||||
如果使用两个连续的反斜杠，则第 1 个反斜杠作为转义符，当只有一个反斜杠时则无须转义。无模式写入协议的反斜杠转义规则如下表所示。
|
||||
|
||||
| **序号** | **反斜杠** | **转义为** |
|
||||
| -------- | ------------ | ---------- |
|
||||
|
|
@ -70,10 +70,9 @@ tag_set 中的所有的数据自动转化为 nchar 数据类型，并不需要
|
|||
| 5 | i32/u32 | Int/UInt | 4 |
|
||||
| 6 | i64/i/u64/u | BigInt/BigInt/UBigInt/UBigInt | 8 |
|
||||
|
||||
- t, T, true, True, TRUE, f, F, false, False 将直接作为 BOOL 型来处理。
|
||||
- t、T、true、True、TRUE、f、F、false、False 将直接作为 BOOL 型来处理。
|
||||
|
||||
例如如下数据行表示：向名为 st 的超级表下的 t1 标签为 "3"（NCHAR）、t2 标签为 "4"（NCHAR）、t3
|
||||
标签为 "t3"（NCHAR）的数据子表，写入 c1 列为 3（BIGINT）、c2 列为 false（BOOL）、c3
|
||||
例如如下数据行表示：向名为 st 的超级表下的 t1 标签为 "3"（NCHAR）、t2 标签为 "4"（NCHAR）、t3 标签为 "t3"（NCHAR）的数据子表，写入 c1 列为 3（BIGINT）、c2 列为 false（BOOL）、c3
|
||||
列为 "passit"（BINARY）、c4 列为 4（DOUBLE）、主键时间戳为 1626006833639000000 的一行数据。
|
||||
|
||||
```json
|
||||
|
|
@ -94,30 +93,28 @@ TDengine 提供数据写入的幂等性保证，即您可以反复调用 API 进
|
|||
"measurement,tag_key1=tag_value1,tag_key2=tag_value2"
|
||||
```
|
||||
|
||||
- 需要注意的是，这里的 tag_key1, tag_key2 并不是用户输入的标签的原始顺序，而是使用了标签名称按照字符串升序排列后的结果。所以，tag_key1 并不是在行协议中输入的第一个标签。
|
||||
排列完成以后计算该字符串的 MD5 散列值 "md5_val"。然后将计算的结果与字符串组合生成表名：“t_md5_val”。其中的 “t_” 是固定的前缀，每个通过该映射关系自动生成的表都具有该前缀。
|
||||
- 需要注意的是，这里的 tag_key1、tag_key2 并不是用户输入的标签的原始顺序，而是使用了标签名称按照字符串升序排列后的结果。所以，tag_key1 并不是在行协议中输入的第一个标签。
|
||||
排列完成以后计算该字符串的 MD5 散列值 "md5_val"。然后将计算的结果与字符串组合生成表名："t_md5_val"。其中的 "t_" 是固定的前缀，每个通过该映射关系自动生成的表都具有该前缀。
|
||||
|
||||
- 如果不想用自动生成的表名，有两种指定子表名的方式(第一种优先级更高)。
|
||||
1. 通过在taos.cfg里配置 smlAutoChildTableNameDelimiter 参数来指定（`@ # 空格 回车 换行 制表符`除外)。
|
||||
1. 举例如下：配置 smlAutoChildTableNameDelimiter=- 插入数据为 st,t0=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1-4。
|
||||
2. 通过在taos.cfg里配置 smlChildTableName 参数来指定。
|
||||
1. 举例如下：配置 smlChildTableName=tname 插入数据为 st,tname=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1，注意如果多行数据 tname 相同，但是后面的 tag_set 不同，则使用第一行自动建表时指定的 tag_set，其他的行会忽略。
|
||||
- 如果不想用自动生成的表名，有两种指定子表名的方式(第一种优先级更高)。
|
||||
- 通过在 taos.cfg 里配置 smlAutoChildTableNameDelimiter 参数来指定（`@ # 空格 回车 换行 制表符` 除外)，例如配置 smlAutoChildTableNameDelimiter=- 插入数据为 st,t0=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1-4。
|
||||
- 通过在 taos.cfg 里配置 smlChildTableName 参数来指定，例如配置 smlChildTableName=tname 插入数据为 st,tname=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1，注意如果多行数据 tname 相同，但是后面的 tag_set 不同，则使用第一行自动建表时指定的 tag_set，其他的行会忽略。
|
||||
|
||||
2. 如果解析行协议获得的超级表不存在，则会创建这个超级表（不建议手动创建超级表，不然插入数据可能异常）。
|
||||
3. 如果解析行协议获得子表不存在，则 Schemaless 会按照步骤 1 或 2 确定的子表名来创建子表。
|
||||
3. 如果解析行协议获得子表不存在，则 schemaless 会按照步骤 1 或 2 确定的子表名来创建子表。
|
||||
4. 如果数据行中指定的标签列或普通列不存在，则在超级表中增加对应的标签列或普通列（只增不减）。
|
||||
5. 如果超级表中存在一些标签列或普通列未在一个数据行中被指定取值，那么这些列的值在这一行中会被置为 NULL。
|
||||
6. 对 BINARY 或 NCHAR 列，如果数据行中所提供值的长度超出了列类型的限制，自动增加该列允许存储的字符长度上限（只增不减），以保证数据的完整保存。
|
||||
7. 整个处理过程中遇到的错误会中断写入过程，并返回错误代码。
|
||||
8. 为了提高写入的效率，默认假设同一个超级表中 field_set 的顺序是一样的（第一条数据包含所有的 field，后面的数据按照这个顺序），如果顺序不一样，需要配置参数 smlDataFormat 为 false，否则，数据写入按照相同顺序写入，库中数据会异常，从3.0.3.0开始，自动检测顺序是否一致，该配置废弃。
|
||||
9. 由于sql建表表名不支持点号（.），所以schemaless也对点号（.）做了处理，如果schemaless自动建表的表名如果有点号（.），会自动替换为下划线（\_）。如果手动指定子表名的话，子表名里有点号（.），同样转化为下划线（\_）。
|
||||
10. taos.cfg 增加 smlTsDefaultName 配置（值为字符串），只在client端起作用，配置后，schemaless自动建表的时间列名字可以通过该配置设置。不配置的话，默认为 _ts。
|
||||
8. 为了提高写入的效率，默认假设同一个超级表中 field_set 的顺序是一样的（第一条数据包含所有的 field，后面的数据按照这个顺序），如果顺序不一样，需要配置参数 smlDataFormat 为 false，否则，数据写入按照相同顺序写入，库中数据会异常，从 3.0.3.0 开始，自动检测顺序是否一致，该配置废弃。
|
||||
9. 由于 sql 建表表名不支持点号（.），所以 schemaless 也对点号（.）做了处理，如果 schemaless 自动建表的表名如果有点号（.），会自动替换为下划线（\_）。如果手动指定子表名的话，子表名里有点号（.），同样转化为下划线（\_）。
|
||||
10. taos.cfg 增加 smlTsDefaultName 配置（字符串类型），只在 client 端起作用，配置后，schemaless 自动建表的时间列名字可以通过该配置设置。不配置的话，默认为 _ts。
|
||||
11. 无模式写入的数据超级表或子表名区分大小写。
|
||||
12. 无模式写入仍然遵循 TDengine 对数据结构的底层限制，例如每行数据的总长度不能超过 48KB（从 3.0.5.0 版本开始为 64KB），标签值的总长度不超过16KB。
|
||||
12. 无模式写入仍然遵循 TDengine 对数据结构的底层限制，例如每行数据的总长度不能超过 48KB（从 3.0.5.0 版本开始为 64KB），标签值的总长度不超过 16KB。
|
||||
|
||||
## 时间分辨率识别
|
||||
|
||||
无模式写入支持3个指定的模式，如下表所示：
|
||||
无模式写入支持 3 个指定的模式，如下表所示：
|
||||
|
||||
| **序号** | **值** | **说明** |
|
||||
| -------- | ------------------- | ------------------------------- |
|
||||
|
|
@ -141,13 +138,13 @@ TDengine 提供数据写入的幂等性保证，即您可以反复调用 API 进
|
|||
|
||||
## 数据模式映射规则
|
||||
|
||||
InfluxDB行协议的数据将被映射成具有模式的数据，其中，measurement映射为超级表名称，tag_set中的标签名称映射为数据模式中的标签名，field_set中的名称映射为列名称。例如下面的数据。
|
||||
InfluxDB 行协议的数据将被映射成具有模式的数据，其中，measurement 映射为超级表名称，tag_set 中的标签名称映射为数据模式中的标签名，field_set 中的名称映射为列名称。例如下面的数据。
|
||||
|
||||
```json
|
||||
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000
|
||||
```
|
||||
|
||||
该行数据映射生成一个超级表： st， 其包含了 3 个类型为 nchar 的标签，分别是：t1, t2, t3。五个数据列，分别是 ts（timestamp），c1 (bigint），c3(binary)，c2 (bool), c4 (bigint）。映射成为如下 SQL 语句：
|
||||
该行数据映射生成一个超级表：st， 其包含了 3 个类型为 nchar 的标签，分别是：t1、t2、t3。五个数据列，分别是 ts（timestamp）、c1 (bigint）、c3(binary)、c2 (bool)、c4 (bigint）。映射成为如下 SQL 语句：
|
||||
|
||||
```json
|
||||
create stable st (_ts timestamp, c1 bigint, c2 bool, c3 binary(6), c4 bigint) tags(t1 nchar(1), t2 nchar(1), t3 nchar(2))
|
||||
|
|
@ -164,7 +161,7 @@ st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4 1626006833639000000
|
|||
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4i 1626006833640000000
|
||||
```
|
||||
|
||||
第一行的数据类型映射将 c4 列定义为 Double， 但是第二行的数据又通过数值后缀方式声明该列为 BigInt， 由此会触发无模式写入的解析错误。
|
||||
第一行的数据类型映射将 c4 列定义为 Double， 但是第二行的数据又通过数值后缀方式声明该列为 bigInt， 由此会触发无模式写入的解析错误。
|
||||
|
||||
如果列前面的行协议将数据列声明为了 binary， 后续的要求长度更长的 binary 长度，此时会触发超级表模式的变更。
|
||||
|
||||
|
|
@ -299,7 +296,7 @@ writer.write(lineDemo, SchemalessProtocolType.LINE, SchemalessTimestampType.NANO
|
|||
|
||||
## 查询写入的数据
|
||||
|
||||
运行上节的样例代码，会在 power 数据库l中自动建表，我们可以通过 TDengine CLI 或者应用程序来查询数据。下面给出用 TDengine CLI 查询超级表和 meters 表数据的样例。
|
||||
运行上节的样例代码，会在 power 数据库中自动建表，我们可以通过 TDengine CLI 或者应用程序来查询数据。下面给出用 TDengine CLI 查询超级表和 meters 表数据的样例。
|
||||
|
||||
```shell
|
||||
taos> show power.stables;
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ toc_max_heading_level: 4
|
|||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
通过参数绑定方式写入数据时，能避免SQL语法解析的资源消耗，从而显著提升写入性能。参数绑定能提高写入效率的原因主要有以下几点：
|
||||
通过参数绑定方式写入数据时，能避免 SQL 语法解析的资源消耗，从而显著提升写入性能。参数绑定能提高写入效率的原因主要有以下几点：
|
||||
|
||||
- 减少解析时间：通过参数绑定，SQL 语句的结构在第一次执行时就已经确定，后续的执行只需要替换参数值，这样可以避免每次执行时都进行语法解析，从而减少解析时间。
|
||||
- 预编译：当使用参数绑定时，SQL 语句可以被预编译并缓存，后续使用不同的参数值执行时，可以直接使用预编译的版本，提高执行效率。
|
||||
|
|
@ -19,9 +19,9 @@ import TabItem from "@theme/TabItem";
|
|||
我们只推荐使用下面两种形式的 SQL 进行参数绑定写入：
|
||||
|
||||
```sql
|
||||
一、确定子表存在：
|
||||
一、确定子表存在
|
||||
1. INSERT INTO meters (tbname, ts, current, voltage, phase) VALUES(?, ?, ?, ?, ?)
|
||||
二、自动建表：
|
||||
二、自动建表
|
||||
1. INSERT INTO meters (tbname, ts, current, voltage, phase, location, group_id) VALUES(?, ?, ?, ?, ?, ?, ?)
|
||||
2. INSERT INTO ? USING meters TAGS (?, ?) VALUES (?, ?, ?, ?)
|
||||
```
|
||||
|
|
@ -50,7 +50,7 @@ import TabItem from "@theme/TabItem";
|
|||
{{#include docs/examples/java/src/main/java/com/taos/example/WSParameterBindingExtendInterfaceDemo.java:para_bind}}
|
||||
```
|
||||
|
||||
这是一个[更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/WSParameterBindingFullDemo.java)
|
||||
这是一个 [更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/WSParameterBindingFullDemo.java)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Python" value="python">
|
||||
|
|
@ -100,7 +100,7 @@ import TabItem from "@theme/TabItem";
|
|||
{{#include docs/examples/java/src/main/java/com/taos/example/ParameterBindingBasicDemo.java:para_bind}}
|
||||
```
|
||||
|
||||
这是一个[更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/ParameterBindingFullDemo.java)
|
||||
这是一个 [更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/ParameterBindingFullDemo.java)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Python" value="python">
|
||||
|
|
|
|||
|
|
@ -10,13 +10,13 @@ import TabItem from "@theme/TabItem";
|
|||
TDengine 提供了类似于消息队列产品的数据订阅和消费接口。在许多场景中，采用 TDengine 的时序大数据平台，无须再集成消息队列产品，从而简化应用程序设计并降低运维成本。本章介绍各语言连接器数据订阅的相关 API 以及使用方法。 数据订阅的基础知识请参考 [数据订阅](../../advanced/subscription/)
|
||||
|
||||
## 创建主题
|
||||
请用 TDengine CLI 或者 参考 [执行 SQL](../sql/) 章节用程序执行创建主题的 SQL：`CREATE TOPIC IF NOT EXISTS topic_meters AS SELECT ts, current, voltage, phase, groupid, location FROM meters`
|
||||
请用 TDengine CLI 或者参考 [执行 SQL](../sql/) 章节用程序执行创建主题的 SQL：`CREATE TOPIC IF NOT EXISTS topic_meters AS SELECT ts, current, voltage, phase, groupid, location FROM meters`
|
||||
|
||||
上述 SQL 将创建一个名为 topic_meters 的订阅。使用该订阅所获取的消息中的每条记录都由此查询语句 `SELECT ts, current, voltage, phase, groupid, location FROM meters` 所选择的列组成。
|
||||
|
||||
**注意**
|
||||
在 TDengine 连接器实现中，对于订阅查询，有以下限制。
|
||||
- 查询语句限制：订阅查询只能使用 select 语句，并不支持其他类型的SQL，如订阅库，订阅超级表（非 select 方式），insert、update 或 delete 等。
|
||||
- 查询语句限制：订阅查询只能使用 select 语句，并不支持其他类型的 SQL，如订阅库、订阅超级表（非 select 方式）、insert、update 或 delete 等。
|
||||
- 原始始数据查询：订阅查询只能查询原始数据，而不能查询聚合或计算结果。
|
||||
- 时间顺序限制：订阅查询只能按照时间正序查询数据。
|
||||
|
||||
|
|
@ -28,22 +28,67 @@ TDengine 消费者的概念跟 Kafka 类似，消费者通过订阅主题来接
|
|||
### 创建参数
|
||||
创建消费者的参数较多，非常灵活的支持了各种连接类型、 Offset 提交方式、压缩、重连、反序列化等特性。各语言连接器都适用的通用基础配置项如下表所示：
|
||||
|
||||
| 参数名称 | 类型 | 参数说明 | 备注 |
|
||||
| :-----------------------: | :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `td.connect.ip` | string | 服务端的 FQDN | 可以是ip或者host name |
|
||||
| `td.connect.user` | string | 用户名 | |
|
||||
| `td.connect.pass` | string | 密码 | |
|
||||
| `td.connect.port` | integer | 服务端的端口号 | |
|
||||
| `group.id` | string | 消费组 ID，同一消费组共享消费进度 | <br />**必填项**。最大长度：192，超长将截断。<br />每个topic最多可建立 100 个 consumer group |
|
||||
| `client.id` | string | 客户端 ID | 最大长度：255，超长将截断。 |
|
||||
| `auto.offset.reset` | enum | 消费组订阅的初始位置 | <br />`earliest`: default(version < 3.2.0.0);从头开始订阅; <br/>`latest`: default(version >= 3.2.0.0);仅从最新数据开始订阅; <br/>`none`: 没有提交的 offset 无法订阅 |
|
||||
| `enable.auto.commit` | boolean | 是否启用消费位点自动提交，true: 自动提交，客户端应用无需commit；false：客户端应用需要自行commit | 默认值为 true |
|
||||
| `auto.commit.interval.ms` | integer | 消费记录自动提交消费位点时间间隔，单位为毫秒 | 默认值为 5000 |
|
||||
| `msg.with.table.name` | boolean | 是否允许从消息中解析表名, 不适用于列订阅（列订阅时可将 tbname 作为列写入 subquery 语句）（从3.2.0.0版本该参数废弃，恒为true） | 默认关闭 |
|
||||
| `enable.replay` | boolean | 是否开启数据回放功能 | 默认关闭 |
|
||||
| `session.timeout.ms` | integer | consumer 心跳丢失后超时时间，超时后会触发 rebalance 逻辑，成功后该 consumer 会被删除（从3.3.3.0版本开始支持） | 默认值为 12000，取值范围 [6000， 1800000] |
|
||||
| `max.poll.interval.ms` | integer | consumer poll 拉取数据间隔的最长时间，超过该时间，会认为该 consumer 离线，触发rebalance 逻辑，成功后该 consumer 会被删除（从3.3.3.0版本开始支持） | 默认值为 300000，[1000，INT32_MAX] |
|
||||
#### td.connect.ip
|
||||
- 说明：服务端的 FQDN
|
||||
- 类型：string
|
||||
- 备注：可以是 ip 或者 host name
|
||||
|
||||
#### td.connect.user
|
||||
- 说明：用户名
|
||||
- 类型：string
|
||||
|
||||
#### td.connect.pass
|
||||
- 说明：密码
|
||||
- 类型：string
|
||||
|
||||
#### td.connect.port
|
||||
- 说明：服务端的端口号
|
||||
- 类型：integer
|
||||
|
||||
#### group.id
|
||||
- 说明：消费组 ID，同一消费组共享消费进度
|
||||
- 类型：string
|
||||
- 备注：**必填项**。最大长度：192，超长将截断。<br />每个topic最多可建立 100 个 consumer group
|
||||
|
||||
#### client.id
|
||||
- 说明：客户端 ID
|
||||
- 类型：string
|
||||
- 备注：最大长度 255，超长将截断
|
||||
|
||||
#### auto.offset.reset
|
||||
- 说明：消费组订阅的初始位置
|
||||
- 类型：enum
|
||||
- 备注：<br />`earliest`：default(version < 3.2.0.0)，从头开始订阅；<br/>`latest`：default(version >= 3.2.0.0)，仅从最新数据开始订阅；<br/>`none`：没有提交的 offset 无法订阅。
|
||||
|
||||
#### enable.auto.commit
|
||||
- 说明：是否启用消费位点自动提交
|
||||
- 类型：boolean
|
||||
- 备注：true：自动提交，客户端应用无需 commit；false：客户端应用需要自行 commit；默认值为 true。
|
||||
|
||||
#### auto.commit.interval.ms
|
||||
- 说明：消费记录自动提交消费位点时间间隔
|
||||
- 类型：integer
|
||||
- 备注：单位为毫秒，默认值为 5000
|
||||
|
||||
#### msg.with.table.name
|
||||
- 说明：是否允许从消息中解析表名
|
||||
- 类型：boolean
|
||||
- 备注：不适用于列订阅（列订阅时可将 tbname 作为列写入 subquery 语句），默认关闭。从 3.2.0.0 版本该参数废弃。
|
||||
|
||||
#### enable.replay
|
||||
- 说明：是否开启数据回放功能
|
||||
- 类型：boolean
|
||||
- 备注：默认关闭
|
||||
|
||||
#### session.timeout.ms
|
||||
- 说明：consumer 心跳丢失后超时时间
|
||||
- 类型：integer
|
||||
- 备注：超时后会触发 rebalance 逻辑，成功后该 consumer 会被删除（从 3.3.3.0 版本开始支持）。默认值为 12000，取值范围 [6000，1800000]。
|
||||
|
||||
#### max.poll.interval.ms
|
||||
- 说明：consumer poll 拉取数据间隔的最长时间
|
||||
- 类型：integer
|
||||
- 备注：超过该时间，会认为该 consumer 离线，触发 rebalance 逻辑，成功后该 consumer 会被删除（从 3.3.3.0 版本开始支持）。默认值为 300000，[1000，INT32_MAX] 。
|
||||
|
||||
下面是各语言连接器创建参数：
|
||||
<Tabs defaultValue="java" groupId="lang">
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ int32_t scalarfn_destroy() {
|
|||
```
|
||||
### 聚合函数模板
|
||||
|
||||
用C语言开发聚合函数的模板如下。
|
||||
用 C 语言开发聚合函数的模板如下。
|
||||
```c
|
||||
#include "taos.h"
|
||||
#include "taoserror.h"
|
||||
|
|
@ -292,13 +292,13 @@ select max_vol(vol1, vol2, vol3, deviceid) from battery;
|
|||
### 准备环境
|
||||
|
||||
准备环境的具体步骤如下：
|
||||
- 第1步，准备好 Python 运行环境。
|
||||
- 第2步，安装 Python 包 taospyudf。命令如下。
|
||||
- 第 1 步，准备好 Python 运行环境。
|
||||
- 第 2 步，安装 Python 包 taospyudf。命令如下。
|
||||
```shell
|
||||
pip3 install taospyudf
|
||||
```
|
||||
- 第3步，执行命令 ldconfig。
|
||||
- 第4步，启动 taosd 服务。
|
||||
- 第 3 步，执行命令 ldconfig。
|
||||
- 第 4 步，启动 taosd 服务。
|
||||
|
||||
安装过程中会编译 C++ 源码，因此系统上要有 cmake 和 gcc。编译生成的 libtaospyudf.so 文件自动会被复制到 /usr/local/lib/ 目录，因此如果是非 root 用户，安装时需加 sudo。安装完可以检查这个目录是否有了这个文件:
|
||||
|
||||
|
|
@ -323,7 +323,7 @@ def process(input: datablock) -> tuple[output_type]:
|
|||
```
|
||||
|
||||
主要参数说明如下：
|
||||
- input:datablock 类似二维矩阵，通过成员方法 data(row, col) 读取位于 row 行、col 列的 python 对象
|
||||
- input:datablock 类似二维矩阵，通过成员方法 data(row, col) 读取位于 row 行、col 列的 Python 对象
|
||||
- 返回值是一个 Python 对象元组，每个元素类型为输出类型。
|
||||
|
||||
#### 聚合函数接口
|
||||
|
|
@ -389,7 +389,7 @@ def finish(buf: bytes) -> output_type:
|
|||
|
||||
### 数据类型映射
|
||||
|
||||
下表描述了TDengine SQL 数据类型和 Python 数据类型的映射。任何类型的 NULL 值都映射成 Python 的 None 值。
|
||||
下表描述了 TDengine SQL 数据类型和 Python 数据类型的映射。任何类型的 NULL 值都映射成 Python 的 None 值。
|
||||
|
||||
| **TDengine SQL数据类型** | **Python数据类型** |
|
||||
| :-----------------------: | ------------ |
|
||||
|
|
@ -405,7 +405,7 @@ def finish(buf: bytes) -> output_type:
|
|||
|
||||
本文内容由浅入深包括 5 个示例程序，同时也包含大量实用的 debug 技巧。
|
||||
|
||||
注意：**UDF 内无法通过 print 函数输出日志，需要自己写文件或用 python 内置的 logging 库写文件**。
|
||||
注意：**UDF 内无法通过 print 函数输出日志，需要自己写文件或用 Python 内置的 logging 库写文件**。
|
||||
|
||||
#### 示例一
|
||||
|
||||
|
|
@ -652,7 +652,7 @@ tail -20 taospyudf.log
|
|||
2023-05-25 11:42:34.541 ERROR [1679419] [PyUdf::PyUdf@217] py udf load module failure. error ModuleNotFoundError: No module named 'moment'
|
||||
```
|
||||
|
||||
这是因为 “moment” 所在位置不在 python udf 插件默认的库搜索路径中。怎么确认这一点呢？通过以下命令搜索 taospyudf.log。
|
||||
这是因为 “moment” 所在位置不在 Python udf 插件默认的库搜索路径中。怎么确认这一点呢？通过以下命令搜索 taospyudf.log。
|
||||
|
||||
```shell
|
||||
grep 'sys path' taospyudf.log | tail -1
|
||||
|
|
@ -664,7 +664,7 @@ grep 'sys path' taospyudf.log | tail -1
|
|||
2023-05-25 10:58:48.554 INFO [1679419] [doPyOpen@592] python sys path: ['', '/lib/python38.zip', '/lib/python3.8', '/lib/python3.8/lib-dynload', '/lib/python3/dist-packages', '/var/lib/taos//.udf']
|
||||
```
|
||||
|
||||
发现 python udf 插件默认搜索的第三方库安装路径是： /lib/python3/dist-packages，而 moment 默认安装到了 /usr/local/lib/python3.8/dist-packages。下面我们修改 python udf 插件默认的库搜索路径。
|
||||
发现 Python udf 插件默认搜索的第三方库安装路径是： /lib/python3/dist-packages，而 moment 默认安装到了 /usr/local/lib/python3.8/dist-packages。下面我们修改 Python udf 插件默认的库搜索路径。
|
||||
先打开 python3 命令行，查看当前的 sys.path。
|
||||
|
||||
```python
|
||||
|
|
@ -754,7 +754,7 @@ create or replace aggregate function myspread as '/root/udf/myspread.py' outputt
|
|||
|
||||
这个 SQL 语句与创建标量函数的 SQL 语句有两个重要区别。
|
||||
1. 增加了 aggregate 关键字
|
||||
2. 增加了 bufsize 关键字，用来指定存储中间结果的内存大小，这个数值可以大于实际使用的数值。本例中间结果是两个浮点数组成的 tuple，序列化后实际占用大小只有 32 个字节，但指定的 bufsize 是128，可以用 python 命令行打印实际占用的字节数
|
||||
2. 增加了 bufsize 关键字，用来指定存储中间结果的内存大小，这个数值可以大于实际使用的数值。本例中间结果是两个浮点数组成的 tuple，序列化后实际占用大小只有 32 个字节，但指定的 bufsize 是128，可以用 Python 命令行打印实际占用的字节数
|
||||
|
||||
```python
|
||||
>>> len(pickle.dumps((12345.6789, 23456789.9877)))
|
||||
|
|
|
|||
|
|
@ -352,7 +352,7 @@ main 函数可以接收 5 个启动参数，依次是：
|
|||
|
||||
<details>
|
||||
|
||||
SQLWriter 类封装了拼 SQL 和写数据的逻辑。所有的表都没有提前创建，而是在发生表不存在错误的时候，再以超级表为模板批量建表，然后重新执行 INSERT 语句。对于其它错误会记录当时执行的 SQL， 以便排查错误和故障恢复。这个类也对 SQL 是否超过最大长度限制做了检查，根据 TDengine 3.0 的限制由输入参数 maxSQLLength 传入了支持的最大 SQL 长度，即 1,048,576 。
|
||||
SQLWriter 类封装了拼 SQL 和写数据的逻辑。所有的表都没有提前创建，而是在发生表不存在错误的时候，再以超级表为模板批量建表，然后重新执行 INSERT 语句。对于其它错误会记录当时执行的 SQL，以便排查错误和故障恢复。这个类也对 SQL 是否超过最大长度限制做了检查，根据 TDengine 3.0 的限制由输入参数 maxSQLLength 传入了支持的最大 SQL 长度，即 1,048,576 。
|
||||
|
||||
<summary>SQLWriter</summary>
|
||||
|
||||
|
|
@ -374,7 +374,7 @@ SQLWriter 类封装了拼 SQL 和写数据的逻辑。所有的表都没有提
|
|||
- 已安装 Python3， 推荐版本 >= 3.8
|
||||
- 已安装 taospy
|
||||
|
||||
2. 安装 faster-fifo 代替 python 内置的 multiprocessing.Queue
|
||||
2. 安装 faster-fifo 代替 Python 内置的 multiprocessing.Queue
|
||||
|
||||
```
|
||||
pip3 install faster-fifo
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ taosAdapter 提供了以下功能：
|
|||
- RESTful 接口；
|
||||
- WebSocket 连接；
|
||||
- 兼容 InfluxDB v1 格式写入；
|
||||
- 兼容 OpenTSDB JSON 和 Telnet 格式写入；
|
||||
- 兼容 OpenTSDB JSON 和 TELNET 格式写入；
|
||||
- 无缝连接到 Telegraf；
|
||||
- 无缝连接到 collectd；
|
||||
- 无缝连接到 StatsD；
|
||||
|
|
@ -44,9 +44,9 @@ taosAdapter 提供了以下功能：
|
|||
|
||||
## taosKeeper
|
||||
|
||||
taosKeeper 是 TDengine 3.0 版本中新增的监控指标导出工具，旨在方便用户对TDengine 的运行状态和性能指标进行实时监控。通过简单的配置，TDengine 能够将其运行状态、指标等信息上报给 taosKeeper。当接收到监控数据后，taosKeeper 会利用 taosAdapter 提供的 RESTful 接口，将这些数据存储到 TDengine 中。
|
||||
taosKeeper 是 TDengine 3.0 版本中新增的监控指标导出工具，旨在方便用户对 TDengine 的运行状态和性能指标进行实时监控。通过简单的配置，TDengine 能够将其运行状态、指标等信息上报给 taosKeeper。当接收到监控数据后，taosKeeper 会利用 taosAdapter 提供的 RESTful 接口，将这些数据存储到 TDengine 中。
|
||||
|
||||
taosKeeper 的一个重要价值在于，它能够将多个甚至一批 TDengine 集群的监控数据集中存储在一个统一的平台上。这使得监控软件能够轻松获取这些数据，从而实现对 TDengine 集群的全面监控和实时分析。通过 taosKeeper，用户可以更加便捷地掌握TDengine 的运行状况，及时发现并解决潜在问题，确保系统的稳定性和高效性。
|
||||
taosKeeper 的一个重要价值在于，它能够将多个甚至一批 TDengine 集群的监控数据集中存储在一个统一的平台上。这使得监控软件能够轻松获取这些数据，从而实现对 TDengine 集群的全面监控和实时分析。通过 taosKeeper，用户可以更加便捷地掌握 TDengine 的运行状况，及时发现并解决潜在问题，确保系统的稳定性和高效性。
|
||||
|
||||
## taosExplorer
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ taosKeeper 的一个重要价值在于，它能够将多个甚至一批 TDengine
|
|||
|
||||
taosX 作为 TDengine Enterprise 的数据管道功能组件，旨在为用户提供一种无须编写代码即可轻松对接第三方数据源的方法，实现数据的便捷导入。目前，taosX 已支持众多主流数据源，包括 AVEVA PI System、AVEVA Historian、OPC-UA/DA、InfluxDB、OpenTSDB、MQTT、Kafka、CSV、TDengine 2.x、TDengine 3.x、MySQL、PostgreSQL和 Oracle 等。
|
||||
|
||||
在实际使用中， 用户通常无须直接与 taosX 进行交互。 相反， 他们可以通 过taosExplorer 提供的浏览器用户界面轻松访问和使用 taosX 的强大功能。这种设计简化了操作流程，降低了使用门槛，使得用户能够更加专注于数据处理和分析，从而提高工作效率。
|
||||
在实际使用中，用户通常无须直接与 taosX 进行交互。 相反， 他们可以通过 taosExplorer 提供的浏览器用户界面轻松访问和使用 taosX 的强大功能。这种设计简化了操作流程，降低了使用门槛，使得用户能够更加专注于数据处理和分析，从而提高工作效率。
|
||||
|
||||
## taosX Agent
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ title: 容量规划
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
若计划使用 TDengine 搭建一个时序数据平台，须提前对计算资源、存储资源和网络资源进行详细规划，以确保满足业务场景的需求。通常 TDengine 会运行多个进程，包括taosd、taosadapter、taoskeeper、taos-explorer 和 taosx。
|
||||
若计划使用 TDengine 搭建一个时序数据平台，须提前对计算资源、存储资源和网络资源进行详细规划，以确保满足业务场景的需求。通常 TDengine 会运行多个进程，包括 taosd、taosadapter、taoskeeper、taos-explorer 和 taosx。
|
||||
|
||||
在这些进程中，taoskeeper、taos-explorer、taosadapter 和 taosx 的资源占用相对较少，通常不需要特别关注。此外，这些进程对存储空间的需求也较低，其占用的 CPU 和内存资源一般为 taosd 进程的十分之一到几分之一（特殊场景除外，如数据同步和历史数据迁移。在这些情况下，涛思数据的技术支持团队将提供一对一的服务）。系统管理员应定期监控这些进程的资源消耗，并及时进行相应处理。
|
||||
|
||||
在本节中，我们将重点讨论 TDengine 数据库引擎的核心进程—taosd 的资源规划。合理的资源规划将确保 taosd 进程的高效运行，从而提高整个时序数据平台的性能和稳定性。
|
||||
在本节中，我们将重点讨论 TDengine 数据库引擎的核心进程 taosd 的资源规划。合理的资源规划将确保 taosd 进程的高效运行，从而提高整个时序数据平台的性能和稳定性。
|
||||
|
||||
## 服务器内存需求
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ toc_max_heading_level: 4
|
|||
为了帮助用户更好地理解和配置这些参数，TDengine 的官方文档的数据库管理部分提供了详细说明。根据这些参数，可以估算出一个数据库所需的内存大小，具体计算方式如下（具体数值须根据实际情况进行调整）。
|
||||
vgroups ×replica × (buffer + pages × pagesize + cachesize)
|
||||
|
||||
需要明确的是，这些内存资源并非仅由单一服务器承担，而是由整个集群中的所有dnode 共同分摊，也就是说，这些资源的负担实际上是由这些 dnode 所在的服务器集群共同承担的。若集群内存在多个数据库，那么所需的内存总量还须将这些数据库的需求累加起来。更为复杂的情形在于，如果集群中的 dnode 并非一开始就全部部署完毕，而是在使用过程中随着节点负载的上升逐步添加服务器和 dnode，那么新加入的数据库可能会导致新旧 dnode 之间的负载分布不均。在这种情况下，简单地进行理论计算是不够准确的，必须考虑到各个 dnode 的实际负载状况来进行综合评估。
|
||||
需要明确的是，这些内存资源并非仅由单一服务器承担，而是由整个集群中的所有 dnode 共同分摊，也就是说，这些资源的负担实际上是由这些 dnode 所在的服务器集群共同承担的。若集群内存在多个数据库，那么所需的内存总量还须将这些数据库的需求累加起来。更为复杂的情形在于，如果集群中的 dnode 并非一开始就全部部署完毕，而是在使用过程中随着节点负载的上升逐步添加服务器和 dnode，那么新加入的数据库可能会导致新旧 dnode 之间的负载分布不均。在这种情况下，简单地进行理论计算是不够准确的，必须考虑到各个 dnode 的实际负载状况来进行综合评估。
|
||||
|
||||
系统管理员可以通过如下 SQL 查看 information_schema 库中的 ins_vnodes 表来获得所有数据库所有 vnodes 在各个 dnode 上的分布。
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ dnode_id |vgroup_id | db_name | status | role_time | start_time | restored |
|
|||
|
||||
1. 原生连接方式
|
||||
|
||||
由于客户端应用程序采用 taosc 与服务器进行通信，因此会产生一定的内存消耗。这些内存消耗主要源于：写入操作中的 SQL、表元数据信息的缓存，以及固有的结构开销。假设该数据库服务能够支持的最大表数量为 N（每个通过超级表创建的表的元数据开销约为 256B），最大并发写入线程数为 T，以及最大 SQL 语句长度为 S（通常情况下为1MB）。基于这些参数，我们可以对客户端的内存消耗进行估算（单位为 MB）。
|
||||
由于客户端应用程序采用 taosc 与服务器进行通信，因此会产生一定的内存消耗。这些内存消耗主要源于：写入操作中的 SQL、表元数据信息的缓存，以及固有的结构开销。假设该数据库服务能够支持的最大表数量为 N（每个通过超级表创建的表的元数据开销约为 256B），最大并发写入线程数为 T，以及最大 SQL 语句长度为 S（通常情况下为 1MB）。基于这些参数，我们可以对客户端的内存消耗进行估算（单位为 MB）。
|
||||
M = (T × S × 3 + (N / 4096) + 100)
|
||||
|
||||
例如，用户最大并发写入线程数为 100，子表数为 10 000 000，那么客户端的内存最低要求如下：
|
||||
|
|
@ -101,7 +101,7 @@ $ du -hd1 <dataDir>/vnode --exclude=wal
|
|||
除了存储容量的需求以外，用户可能还希望在特定容量下降低存储成本。为了满足这一需求，TDengine 推出了多级存储功能。该功能允许将近期产生且访问频率较高的数据存储在高成本存储设备上，而将时间较长且访问频率较低的数据存储在低成本存储设备上。通过这种方式，TDengine 实现了以下目标。
|
||||
- 降低存储成本：通过将海量极冷数据存储在廉价存储设备上，可以显著降低存储成本。
|
||||
- 提高写入性能：每级存储支持多个挂载点，WAL 文件也支持 0 级的多挂载点并行写入，这些措施极大地提高了写入性能（实际场景中的持续写入速度可达 3 亿测
|
||||
点 / 秒），在机械硬盘上也能获得极高的硬盘 I/O 吞吐（实测可达 2GB/s）。
|
||||
点/秒），在机械硬盘上也能获得极高的硬盘 I/O 吞吐（实测可达 2GB/s）。
|
||||
|
||||
用户可以根据冷热数据的比例来决定高速和低成本存储设备之间的容量划分。
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ TDengine 的多级存储功能在使用上还具备以下优点。
|
|||
- 集群为响应维护指令而额外需要的内部通信带宽，如从单副本切换到三副本导致的数据复制、修复指定 dnode 引发的数据复制等情况。
|
||||
|
||||
为了估算入站带宽需求，我们可以采用以下方式：
|
||||
由 于 taosc 写入在 RPC 通信过程中自带压缩功能，因此写入带宽需求相对于RESTful/WebSocket 连接方式较低。在这里，我们将基于 RESTful/WebSocket 连接方式的
|
||||
由 于 taosc 写入在 RPC 通信过程中自带压缩功能，因此写入带宽需求相对于 RESTful/WebSocket 连接方式较低。在这里，我们将基于 RESTful/WebSocket 连接方式的
|
||||
带宽需求来估算写入请求的带宽。
|
||||
|
||||
示例：1000 万块智能电表，电表每 15min 采集一次数据，每次采集的数据量为 20B，可计算出平均带宽需求为 0.22MB。
|
||||
|
|
@ -154,9 +154,9 @@ TDengine 的多级存储功能在使用上还具备以下优点。
|
|||
| taosKeeper | 6043 | TCP |
|
||||
| statsd 格式写入接口 | 6044 | TCP/UDP |
|
||||
| collectd 格式写入接口 | 6045 | TCP/UDP |
|
||||
| openTSDB Telnet 格式写入接口 | 6046 | TCP |
|
||||
| collectd 使用 openTSDB Telnet 格式写入接口 | 6047 | TCP |
|
||||
| icinga2 使用 openTSDB Telnet 格式写入接口 | 6048 | TCP |
|
||||
| tcollector 使用 openTSDB Telnet 格式写入接口 | 6049 | TCP |
|
||||
| openTSDB TELNET 格式写入接口 | 6046 | TCP |
|
||||
| collectd 使用 openTSDB TELNET 格式写入接口 | 6047 | TCP |
|
||||
| icinga2 使用 openTSDB TELNET 格式写入接口 | 6048 | TCP |
|
||||
| tcollector 使用 openTSDB TELNET 格式写入接口 | 6049 | TCP |
|
||||
| taosX | 6050, 6055 | TCP |
|
||||
| taosExplorer | 6060 | TCP |
|
||||
|
|
|
|||
|
|
@ -14,18 +14,18 @@ taosd 是 TDengine 集群中最主要的服务组件，本节介绍手动部署
|
|||
|
||||
#### 1. 清除数据
|
||||
|
||||
如果搭建集群的物理节点中存在之前的测试数据或者装过其他版本（如 1.x/2.x）的TDengine，请先将其删除，并清空所有数据。
|
||||
如果搭建集群的物理节点中存在之前的测试数据或者装过其他版本（如 1.x/2.x）的 TDengine，请先将其删除，并清空所有数据。
|
||||
|
||||
#### 2. 检查环境
|
||||
|
||||
在进行 TDengine 集群部署之前，全面检查所有 dnode 以及应用程序所在物理节点的网络设置至关重要。以下是检查步骤：
|
||||
|
||||
- 第 1 步，在每个物理节点上执行 hostname -f 命令，以查看并确认所有节点的hostname 是唯一的。对于应用程序驱动所在的节点，这一步骤可以省略。
|
||||
- 第 2 步，在每个物理节点上执行 ping host 命令，其中 host 是其他物理节点的 hostname。这一步骤旨在检测当前节点与其他物理节点之间的网络连通性。如果发现无法 ping 通，请立即检查网络和 DNS 设置。对于 Linux 操作系统，请检查 /etc/hosts 文件；对于 Windows 操作系统，请检查C:\Windows\system32\drivers\etc\hosts 文件。网络不通畅将导致无法组建集群，请务必解决此问题。
|
||||
- 第 3 步，在应用程序运行的物理节点上重复上述网络检测步骤。如果发现网络不通畅，应用程序将无法连接到 taosd 服务。此时，请仔细检查应用程序所在物理节点的DNS 设置或 hosts 文件，确保其配置正确无误。
|
||||
- 第 2 步，在每个物理节点上执行 ping host 命令，其中 host 是其他物理节点的 hostname。这一步骤旨在检测当前节点与其他物理节点之间的网络连通性。如果发现无法 ping 通，请立即检查网络和 DNS 设置。对于 Linux 操作系统，请检查 /etc/hosts 文件；对于 Windows 操作系统，请检查 `C:\Windows\system32\drivers\etc\hosts` 文件。网络不通畅将导致无法组建集群，请务必解决此问题。
|
||||
- 第 3 步，在应用程序运行的物理节点上重复上述网络检测步骤。如果发现网络不通畅，应用程序将无法连接到 taosd 服务。此时，请仔细检查应用程序所在物理节点的 DNS 设置或 hosts 文件，确保其配置正确无误。
|
||||
- 第 4 步，检查端口，确保集群中所有主机在端口 6030 上的 TCP 能够互通。
|
||||
|
||||
通过以上步骤，你可以确保所有节点在网络层面顺利通信，从而为成功部署TDengine 集群奠定坚实基础
|
||||
通过以上步骤，你可以确保所有节点在网络层面顺利通信，从而为成功部署 TDengine 集群奠定坚实基础
|
||||
|
||||
#### 3. 安装
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ taos> show dnodes;
|
|||
create dnode "h2.taosdata.com:6030"
|
||||
```
|
||||
|
||||
将新 dnode 的 endpoint 添加进集群的 endpoint 列表。需要为 `fqdn:port` 加上双引号，否则运行时出错。请注意将示例的 h2.taosdata.com:6030 替换为这个新 dnode 的 endpoint。然后执行如下 SQL 查看新节点是否成功加入。若要加入的 dnode 当前处于离线状态，请参考本节后面的 “常见问题”部分进行解决。
|
||||
将新 dnode 的 endpoint 添加进集群的 endpoint 列表。需要为 `fqdn:port` 加上双引号，否则运行时出错。请注意将示例的 h2.taosdata.com:6030 替换为这个新 dnode 的 endpoint。然后执行如下 SQL 查看新节点是否成功加入。若要加入的 dnode 当前处于离线状态，请参考本节后面的“常见问题”部分进行解决。
|
||||
|
||||
```shell
|
||||
show dnodes;
|
||||
|
|
@ -202,7 +202,7 @@ http {
|
|||
|
||||
### 部署 taosKeeper
|
||||
|
||||
如果要想使用 TDegnine 的监控功能，taosKeeper 是一个必要的组件，关于监控请参考[TDinsight](../../reference/components/tdinsight)，关于部署 taosKeeper 的细节请参考[taosKeeper参考手册](../../reference/components/taoskeeper)。
|
||||
如果要想使用 TDegnine 的监控功能，taosKeeper 是一个必要的组件，关于监控请参考 [TDinsight](../../reference/components/tdinsight)，关于部署 taosKeeper 的细节请参考 [taosKeeper 参考手册](../../reference/components/taoskeeper)。
|
||||
|
||||
### 部署 taosX
|
||||
|
||||
|
|
@ -210,11 +210,11 @@ http {
|
|||
|
||||
### 部署 taosX-Agent
|
||||
|
||||
有些数据源如 Pi, OPC 等，因为网络条件和数据源访问的限制，taosX 无法直接访问数据源，这种情况下需要部署一个代理服务 taosX-Agent，关于它的详细说明和部署请参考企业版参考手册。
|
||||
有些数据源如 PI、OPC 等，因为网络条件和数据源访问的限制，taosX 无法直接访问数据源，这种情况下需要部署一个代理服务 taosX-Agent，关于它的详细说明和部署请参考企业版参考手册。
|
||||
|
||||
### 部署 taos-Explorer
|
||||
|
||||
TDengine 提供了可视化管理 TDengine 集群的能力，要想使用图形化界面需要部署 taos-Explorer 服务，关于它的详细说明和部署请参考[taos-Explorer 参考手册](../../reference/components/explorer)
|
||||
TDengine 提供了可视化管理 TDengine 集群的能力，要想使用图形化界面需要部署 taos-Explorer 服务，关于它的详细说明和部署请参考 [taos-Explorer 参考手册](../../reference/components/explorer)
|
||||
|
||||
|
||||
## Docker 部署
|
||||
|
|
@ -299,14 +299,14 @@ echo 127.0.0.1 tdengine |sudo tee -a /etc/hosts
|
|||
taos -h tdengine -P 6030
|
||||
```
|
||||
|
||||
如果 TAOS_FQDN 被设置为与所在主机名相同，则效果与“在 host 网络模式下启动TDengine”相同。
|
||||
如果 TAOS_FQDN 被设置为与所在主机名相同，则效果与“在 host 网络模式下启动 TDengine”相同。
|
||||
|
||||
## Kubernetes 部署
|
||||
|
||||
作为面向云原生架构设计的时序数据库，TDengine 本身就支持 Kubernetes 部署。这里介绍如何使用 YAML 文件从头一步一步创建一个可用于生产使用的高可用 TDengine 集群，并重点介绍 Kubernetes 环境下 TDengine 的常用操作。本小节要求读者对 Kubernetes 有一定的了解，可以熟练运行常见的 kubectl 命令，了解 statefulset、service、pvc 等概念，对这些概念不熟悉的读者，可以先参考 Kubernetes 的官网进行学习。
|
||||
为了满足高可用的需求，集群需要满足如下要求：
|
||||
- 3 个及以上 dnode ：TDengine 的同一个 vgroup 中的多个 vnode ，不允许同时分布在一个 dnode ，所以如果创建 3 副本的数据库，则 dnode 数大于等于 3
|
||||
- 3 个 mnode ：mnode 负责整个集群的管理工作，TDengine 默认是一个 mnode。如果这个 mnode 所在的 dnode 掉线，则整个集群不可用。
|
||||
- 3 个及以上 dnode：TDengine 的同一个 vgroup 中的多个 vnode，不允许同时分布在一个 dnode ，所以如果创建 3 副本的数据库，则 dnode 数大于等于 3
|
||||
- 3 个 mnode：mnode 负责整个集群的管理工作，TDengine 默认是一个 mnode。如果这个 mnode 所在的 dnode 掉线，则整个集群不可用。
|
||||
- 数据库的 3 副本：TDengine 的副本配置是数据库级别，所以数据库 3 副本可满足在 3 个 dnode 的集群中，任意一个 dnode 下线，都不影响集群的正常使用。如果下线 dnode 个数为 2 时，此时集群不可用，因为 RAFT 无法完成选举。（企业版：在灾难恢复场景，任一节点数据文件损坏，都可以通过重新拉起 dnode 进行恢复）
|
||||
|
||||
### 前置条件
|
||||
|
|
@ -342,7 +342,7 @@ spec:
|
|||
|
||||
### 有状态服务 StatefulSet
|
||||
|
||||
根据 Kubernetes 对各类部署的说明，我们将使用 StatefulSet 作为 TDengine 的部署资源类型。 创建文件 tdengine.yaml，其中 replicas 定义集群节点的数量为 3。节点时区为中国（Asia/Shanghai），每个节点分配 5G 标准（standard）存储，你也可以根据实际情况进行相应修改。
|
||||
根据 Kubernetes 对各类部署的说明，我们将使用 StatefulSet 作为 TDengine 的部署资源类型。 创建文件 tdengine.yaml，其中 replicas 定义集群节点的数量为 3。节点时区为中国（Asia/Shanghai），每个节点分配 5GB 标准（standard）存储，你也可以根据实际情况进行相应修改。
|
||||
|
||||
请特别注意 startupProbe 的配置，在 dnode 的 Pod 掉线一段时间后，再重新启动，这个时候新上线的 dnode 会短暂不可用。如果 startupProbe 配置过小，Kubernetes 会认为该 Pod 处于不正常的状态，并尝试重启该 Pod，该 dnode 的 Pod 会频繁重启，始终无法恢复到正常状态。
|
||||
|
||||
|
|
|
|||
|
|
@ -8,41 +8,41 @@ sidebar_label: 集群维护
|
|||
|
||||
## 节点管理
|
||||
|
||||
如何管理集群节点请参考[节点管理](../../reference/taos-sql/node)
|
||||
如何管理集群节点请参考 [节点管理](../../reference/taos-sql/node)
|
||||
|
||||
## 数据重整
|
||||
|
||||
TDengine 面向多种写入场景，而很多写入场景下，TDengine 的存储会导致数据存储的放大或数据文件的空洞等。这一方面影响数据的存储效率，另一方面也会影响查询效率。为了解决上述问题，TDengine 企业版提供了对数据的重整功能，即 DATA COMPACT 功能，将存储的数据文件重新整理，删除文件空洞和无效数据，提高数据的组织度，从而提高存储和查询的效率。数据重整功能在 3.0.3.0 版本第一次发布，此后又经过了多次迭代优化，建议使用最新版本。
|
||||
TDengine 面向多种写入场景，而很多写入场景下，TDengine 的存储会导致数据存储的放大或数据文件的空洞等。这一方面影响数据的存储效率，另一方面也会影响查询效率。为了解决上述问题，TDengine 企业版提供了对数据的重整功能，即 data compact 功能，将存储的数据文件重新整理，删除文件空洞和无效数据，提高数据的组织度，从而提高存储和查询的效率。数据重整功能在 3.0.3.0 版本第一次发布，此后又经过了多次迭代优化，建议使用最新版本。
|
||||
|
||||
### 语法
|
||||
|
||||
```SQL
|
||||
COMPACT DATABASE db_name [start with 'XXXX'] [end with 'YYYY']；
|
||||
COMPACT [db_name.]VGROUPS IN (vgroup_id1, vgroup_id2, ...) [start with 'XXXX'] [end with 'YYYY']；
|
||||
SHOW COMPACTS；
|
||||
SHOW COMPACT compact_id;
|
||||
KILL COMPACT compact_id；
|
||||
compact DATABASE db_name [start with 'XXXX'] [end with 'YYYY']；
|
||||
compact [db_name.]vgroups IN (vgroup_id1, vgroup_id2, ...) [start with 'XXXX'] [end with 'YYYY']；
|
||||
show compacts；
|
||||
show compact compact_id;
|
||||
kill compact compact_id；
|
||||
```
|
||||
|
||||
### 效果
|
||||
|
||||
- 扫描并压缩指定的 DB 中所有 VGROUP 中 VNODE 的所有数据文件
|
||||
- 扫描并压缩 DB 中指定的 VGROUP 列表中 VNODE 的所有数据文件, 若 db_name 为空，则默认为当前数据库
|
||||
- COMPCAT 会删除被删除数据以及被删除的表的数据
|
||||
- COMPACT 会合并多个 STT 文件
|
||||
- 可通过 start with 关键字指定 COMPACT 数据的起始时间
|
||||
- 可通过 end with 关键字指定 COMPACT 数据的终止时间
|
||||
- COMPACT 命令会返回 COMPACT 任务的 ID
|
||||
- COMPACT 任务会在后台异步执行，可以通过 SHOW COMPACTS 命令查看 COMPACT 任务的进度
|
||||
- SHOW 命令会返回 COMPACT 任务的 ID，可以通过 KILL COMPACT 命令终止 COMPACT 任务
|
||||
- 扫描并压缩指定的 DB 中所有 vgroup 中 vnode 的所有数据文件
|
||||
- 扫描并压缩 DB 中指定的 vgroup 列表中 vnode 的所有数据文件, 若 db_name 为空，则默认为当前数据库
|
||||
- compact 会删除被删除数据以及被删除的表的数据
|
||||
- compact 会合并多个 STT 文件
|
||||
- 可通过 start with 关键字指定 compact 数据的起始时间
|
||||
- 可通过 end with 关键字指定 compact 数据的终止时间
|
||||
- compact 命令会返回 compact 任务的 ID
|
||||
- compact 任务会在后台异步执行，可以通过 show compacts 命令查看 compact 任务的进度
|
||||
- show 命令会返回 compact 任务的 ID，可以通过 kill compact 命令终止 compact 任务
|
||||
|
||||
|
||||
### 补充说明
|
||||
|
||||
- COMPACT 为异步，执行 COMPACT 命令后不会等 COMPACT 结束就会返回。如果上一个 COMPACT 没有完成则再发起一个 COMPACT 任务，则会等上一个任务完成后再返回。
|
||||
- COMPACT 可能阻塞写入，尤其是在 stt_trigger = 1 的数据库中，但不阻塞查询。
|
||||
- compact 为异步，执行 compact 命令后不会等 compact 结束就会返回。如果上一个 compact 没有完成则再发起一个 compact 任务，则会等上一个任务完成后再返回。
|
||||
- compact 可能阻塞写入，尤其是在 stt_trigger = 1 的数据库中，但不阻塞查询。
|
||||
|
||||
## Vgroup Leader 再平衡
|
||||
## vgroup leader 再平衡
|
||||
|
||||
当多副本集群中的一个或多个节点因为升级或其它原因而重启后，有可能出现集群中各个 dnode 负载不均衡的现象，极端情况下会出现所有 vgroup 的 leader 都位于同一个 dnode 的情况。为了解决这个问题，可以使用下面的命令，该命令在 3.0.4.0 版本中首次发布，建议尽可能使用最新版本。
|
||||
|
||||
|
|
@ -54,15 +54,15 @@ balance vgroup leader database <database_name>; # 再平衡一个 database 内
|
|||
|
||||
### 功能
|
||||
|
||||
尝试让一个或所有 vgroup 的 leader在各自的replica节点上均匀分布。这个命令会让 vgroup 强制重新选举，通过重新选举，在选举的过程中，改变 vgroup 的leader，通过这个方式，最终让leader均匀分布。
|
||||
尝试让一个或所有 vgroup 的 leader 在各自的 replica 节点上均匀分布。这个命令会让 vgroup 强制重新选举，通过重新选举，在选举的过程中，改变 vgroup 的 leader，通过这个方式，最终让 leader 均匀分布。
|
||||
|
||||
### 注意
|
||||
|
||||
Vgroup 选举本身带有随机性，所以通过选举的重新分布产生的均匀分布也是带有一定的概率，不会完全的均匀。该命令的副作用是影响查询和写入，在vgroup重新选举时，从开始选举到选举出新的 leader 这段时间，这 个vgroup 无法写入和查询。选举过程一般在秒级完成。所有的vgroup会依次逐个重新选举。
|
||||
vgroup 选举本身带有随机性，所以通过选举的重新分布产生的均匀分布也是带有一定的概率，不会完全的均匀。该命令的副作用是影响查询和写入，在 vgroup 重新选举时，从开始选举到选举出新的 leader 这段时间，这 个vgroup 无法写入和查询。选举过程一般在秒级完成。所有的 vgroup 会依次逐个重新选举。
|
||||
|
||||
## 恢复数据节点
|
||||
|
||||
当集群中的某个数据节点（dnode）的数据全部丢失或被破坏，比如磁盘损坏或者目录被误删除，可以通过 restore dnode 命令来恢复该数据节点上的部分或全部逻辑节点，该功能依赖多副本中的其它副本进行数据复制，所以只在集群中 dnode 数量大于等于 3 且副本数为 3 的情况下能够工作。
|
||||
当集群中的某个数据节点（dnode）的数据全部丢失或被破坏，比如磁盘损坏或者目录被误删除，可以通过 `restore dnode` 命令来恢复该数据节点上的部分或全部逻辑节点，该功能依赖多副本中的其它副本进行数据复制，所以只在集群中 dnode 数量大于等于 3 且副本数为 3 的情况下能够工作。
|
||||
|
||||
```sql
|
||||
restore dnode <dnode_id>；# 恢复dnode上的mnode，所有vnode和qnode
|
||||
|
|
@ -73,12 +73,12 @@ restore qnode on dnode <dnode_id>；# 恢复dnode上的qnode
|
|||
|
||||
### 限制
|
||||
|
||||
- 该功能是基于已有的复制功能的恢复，不是灾难恢复或者备份恢复，所以对于要恢复的 mnode 和 vnode来说，使用该命令的前提是还存在该 mnode 或 vnode 的其它两个副本仍然能够正常工作。
|
||||
- 该命令不能修复数据目录中的个别文件的损坏或者丢失。例如，如果某个 mnode 或者 vnode 中的个别文件或数据损坏，无法单独恢复损坏的某个文件或者某块数据。此时，可以选择将该 mnode/vnode 的数据全部清空再进行恢复。
|
||||
- 该功能是基于已有的复制功能的恢复，不是灾难恢复或者备份恢复，所以对于要恢复的 mnode 和 vnode 来说，使用该命令的前提是还存在该 mnode 或 vnode 的其它两个副本仍然能够正常工作。
|
||||
- 该命令不能修复数据目录中的个别文件的损坏或者丢失。例如，如果某个 mnode 或者 vnode 中的个别文件或数据损坏，无法单独恢复损坏的某个文件或者某块数据。此时，可以选择将该 mnode/vnode 的数据全部清空再进行恢复。
|
||||
|
||||
## 分裂虚拟组
|
||||
|
||||
当一个 vgroup 因为子表数过多而导致 CPU 或 Disk 资源使用量负载过高时，增加 dnode 节点后，可通过split vgroup命令把该vgroup分裂为两个虚拟组。分裂完成后，新产生的两个 vgroup 承担原来由一个 vgroup 提供的读写服务。该命令在 3.0.6.0 版本第一次发布，建议尽可能使用最新版本。
|
||||
当一个 vgroup 因为子表数过多而导致 CPU 或 Disk 资源使用量负载过高时，增加 dnode 节点后，可通过 `split vgroup` 命令把该 vgroup 分裂为两个虚拟组。分裂完成后，新产生的两个 vgroup 承担原来由一个 vgroup 提供的读写服务。该命令在 3.0.6.0 版本第一次发布，建议尽可能使用最新版本。
|
||||
|
||||
```sql
|
||||
split vgroup <vgroup_id>
|
||||
|
|
@ -87,7 +87,7 @@ split vgroup <vgroup_id>
|
|||
### 注意
|
||||
|
||||
- 单副本库虚拟组，在分裂完成后，历史时序数据总磁盘空间使用量，可能会翻倍。所以，在执行该操作之前，通过增加 dnode 节点方式，确保集群中有足够的 CPU 和磁盘资源，避免资源不足现象发生。
|
||||
- 该命令为 DB 级事务；执行过程，当前DB的其它管理事务将会被拒绝。集群中，其它DB不受影响。
|
||||
- 该命令为 DB 级事务；执行过程，当前 DB 的其它管理事务将会被拒绝。集群中，其它 DB 不受影响。
|
||||
- 分裂任务执行过程中，可持续提供读写服务；期间，可能存在可感知的短暂的读写业务中断。
|
||||
- 在分裂过程中，不支持流和订阅。分裂结束后，历史 WAL 会清空。
|
||||
- 分裂过程中，可支持节点宕机重启容错；但不支持节点磁盘故障容错。
|
||||
|
|
@ -96,8 +96,6 @@ split vgroup <vgroup_id>
|
|||
|
||||
从 3.1.1.0 版本开始，TDengine Enterprise 支持在线热更新 `supportVnodes` 这个很重要的 dnode 配置参数。这个参数的原始配置方式是在 `taos.cfg` 配置文件中，表示该 dnode 能够支持的最大的 vnode 数量。当创建一个数据库时需要分配新的 vnode，当删除一个数据库时其 vnode 都会被销毁。
|
||||
|
||||
但在线更新 `supportVnodes` 不会产生持久化，当系统重启后，允许的最大 vnode 数量仍然由 taos.cfg 中配置的 `supportVnodes` 决定。
|
||||
|
||||
如果通过在线更新或配置文件方式设置的 `supportVnodes` 小于 dnode 当前已经实际存在的 vnode 数量，已经存在的 vnode 不会受影响。但当尝试创建新的 database 时，是否能够创建成功则仍然受实际生效的 `supportVnodes` 参数决定。
|
||||
|
||||
## 双副本
|
||||
|
|
@ -106,7 +104,7 @@ split vgroup <vgroup_id>
|
|||
|
||||
### 查看 Vgroups 的状态
|
||||
|
||||
通过以下 SQL 命令参看双副本数据库中各 Vgroup 的状态：
|
||||
通过以下 SQL 命令参看双副本数据库中各 vgroup 的状态：
|
||||
|
||||
```sql
|
||||
show arbgroups;
|
||||
|
|
@ -120,15 +118,15 @@ select * from information_schema.ins_arbgroups;
|
|||
|
||||
```
|
||||
is_sync 有以下两种取值：
|
||||
- 0: Vgroup 数据未达成同步。在此状态下，如果 Vgroup 中的某一 Vnode 不可访问，另一个 Vnode 无法被指定为 `AssignedLeader` role，该 Vgroup 将无法提供服务。
|
||||
- 1: Vgroup 数据达成同步。在此状态下，如果 Vgroup 中的某一 Vnode 不可访问，另一个 Vnode 可以被指定为 `AssignedLeader` role，该 Vgroup 可以继续提供服务。
|
||||
- 0: vgroup 数据未达成同步。在此状态下，如果 vgroup 中的某一 vnode 不可访问，另一个 vnode 无法被指定为 `AssignedLeader` role，该 vgroup 将无法提供服务。
|
||||
- 1: vgroup 数据达成同步。在此状态下，如果 vgroup 中的某一 vnode 不可访问，另一个 vnode 可以被指定为 `AssignedLeader` role，该 vgroup 可以继续提供服务。
|
||||
|
||||
assigned_dnode：
|
||||
- 标识被指定为 AssignedLeader 的 Vnode 的 DnodeId
|
||||
- 未指定 AssignedLeader时，该列显示 NULL
|
||||
- 标识被指定为 AssignedLeader 的 vnode 的 DnodeId
|
||||
- 未指定 AssignedLeader 时，该列显示 NULL
|
||||
|
||||
assigned_token：
|
||||
- 标识被指定为 AssignedLeader 的 Vnode 的 Token
|
||||
- 标识被指定为 AssignedLeader 的 vnode 的 Token
|
||||
- 未指定 AssignedLeader时，该列显示 NULL
|
||||
|
||||
### 最佳实践
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 运行监控
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
为了确保集群稳定运行，TDengine 集成了多种监控指标收集机制，并通 过taosKeeper 进行汇总。taosKeeper负责接收这些数据，并将其写入一个独立的 TDengine 实例中，该实例可以与被监控的 TDengine 集群保持独立。TDengine 中的两个核心组件 taosd （数据库引擎） 和 taosX （数据接入平台）都通过相同的监控架构来实现对其运行时的监控，但各自的监控指标设计有所不同。
|
||||
为了确保集群稳定运行，TDengine 集成了多种监控指标收集机制，并通过 taosKeeper 进行汇总。taosKeeper 负责接收这些数据，并将其写入一个独立的 TDengine 实例中，该实例可以与被监控的 TDengine 集群保持独立。TDengine 中的两个核心组件 taosd （数据库引擎）和 taosX （数据接入平台）都通过相同的监控架构来实现对其运行时的监控，但各自的监控指标设计有所不同。
|
||||
|
||||
至于如何获取和使用这些监控数据，用户可以使用第三方的监测工具比如 Zabbix 来获取这些保存的系统监测数据，进而将 TDengine 的运行状况无缝集成到现有的 IT 监控系统中。也可以使用 TDengine 提供的 TDinsight 插件，使用该插件用户可以通过 Grafana 平台直观地展示和管理这些监控信息，如下图所示。这为用户提供了灵活的监控选项，以满足不同场景下的运维需求。
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ taosKeeper 的配置文件默认位于 `/etc/taos/taoskeeper.toml`。 详细配
|
|||
|
||||
通过集成 Grafana 和 TDengine 数据源插件，TDinsight 能够读取 taosKeeper 收集的监控数据。这使得用户可以在 Grafana 平台上直观地查看 TDengine 集群的状态、节点信息、读写请求以及资源使用情况等关键指标，实现数据的可视化展示。
|
||||
|
||||
以下是TDinsight 的详细使用说明，以帮助你充分利用这一强大工具。
|
||||
以下是 TDinsight 的详细使用说明，以帮助你充分利用这一强大工具。
|
||||
|
||||
#### 前置条件
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ taosKeeper 的配置文件默认位于 `/etc/taos/taoskeeper.toml`。 详细配
|
|||
|
||||
#### 导入仪表盘
|
||||
|
||||
TDengine 数据源插件已提交至 Grafana 官网，如何安装 TDengine 数据源插件和配置数据源请参考：[安装 Grafana Plugin 并配置数据源](../../third-party/visual/grafana/#安装-grafana-plugin-并配置数据源)。完成插件的安装和数据源的创建后，可以进行 TDinsight 仪表盘的导入。
|
||||
TDengine 数据源插件已提交至 Grafana 官网，如何安装 TDengine 数据源插件和配置数据源请参考 [安装 Grafana Plugin 并配置数据源](../../third-party/visual/grafana/#安装-grafana-plugin-并配置数据源)。完成插件的安装和数据源的创建后，可以进行 TDinsight 仪表盘的导入。
|
||||
|
||||
在 Grafana 的 “Home” -> “Dashboards” 页面，点击位于右上角的 “New” -> “import” 按钮，即可进入 Dashboard 的导入页面，它支持以下两种导入方式。
|
||||
- Dashboard ID：18180。
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 可视化管理工具
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
为方便用户更高效地使用和管理 TDengine，TDengine 3.0 版本推出了一个全新的可视化组件—taosExplorer。这个组件旨在帮助用户在不熟悉 SQL 的情况下，也能轻松管理 TDengine 集群。通过 taosExplorer，用户可以轻松查看 TDengine 的运行状态、浏览数据、配置数据源、实现流计算和数据订阅等功能。此外，用户还可以利用taosExplorer 进行数据的备份、复制和同步操作，以及配置用户的各种访问权限。这些功能极大地简化了数据库的使用过程，提高了用户体验。
|
||||
为方便用户更高效地使用和管理 TDengine，TDengine 3.0 版本推出了一个全新的可视化组件 taosExplorer。这个组件旨在帮助用户在不熟悉 SQL 的情况下，也能轻松管理 TDengine 集群。通过 taosExplorer，用户可以轻松查看 TDengine 的运行状态、浏览数据、配置数据源、实现流计算和数据订阅等功能。此外，用户还可以利用 taosExplorer 进行数据的备份、复制和同步操作，以及配置用户的各种访问权限。这些功能极大地简化了数据库的使用过程，提高了用户体验。
|
||||
|
||||
本节介绍可视化管理的基本功能。
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ toc_max_heading_level: 4
|
|||
|
||||
## 数据浏览器
|
||||
|
||||
点击功能列表的“数据浏览器”入口，在“数据浏览器”中可以创建和删除数据库、创建和删除超级表和子表，执行SQL语句，查看SQL语句的执行结果。此外，超级管理员还有对数据库的管理权限，其他用户不提供该功能。如下图所示：
|
||||
点击功能列表的“数据浏览器”入口，在“数据浏览器”中可以创建和删除数据库、创建和删除超级表和子表，执行 SQL 语句，查看 SQL 语句的执行结果。此外，超级管理员还有对数据库的管理权限，其他用户不提供该功能。如下图所示：
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ toc_max_heading_level: 4
|
|||
|
||||
下面通过创建数据库，来熟悉数据浏览器页面的功能和操作，接下来看创建数据库的两种方式：
|
||||
|
||||
1. 通过点击图中的 + 号，跳转到创建数据数库页面，点击 创建 按钮，如下图：
|
||||
1. 通过点击图中的 + 号，跳转到创建数据数库页面，点击“创建”按钮，如下图：
|
||||
|
||||
第一步 点击 + 号；
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ toc_max_heading_level: 4
|
|||
弟三步 点击“创建”按钮之后，如下图左边出现数据库名称则创建数据库成功。
|
||||
|
||||
|
||||
2. 通过在 Sql 编辑器中数据 sql 语句，点击 执行 按钮，如下图：
|
||||
2. 通过在 SQL 编辑器中数据 sql 语句，点击 执行 按钮，如下图：
|
||||
|
||||
第一步 输入 sql 语句；
|
||||
|
||||
|
|
@ -201,11 +201,11 @@ toc_max_heading_level: 4
|
|||
## 工具
|
||||
|
||||
通过 “工具” 页面，用户可以了解如下 TDengine 周边工具的使用方法。
|
||||
- TDengine CLI。
|
||||
- taosBenchmark。
|
||||
- taosdump。
|
||||
- TDengine 与 BI 工具的集成，例如 Google Data Studio、Power BI、永洪 BI 等。
|
||||
- TDengine 与 Grafana、Seeq 的集成。
|
||||
- TDengine CLI
|
||||
- taosBenchmark
|
||||
- taosdump
|
||||
- TDengine 与 BI 工具的集成，例如 Google Data Studio、Power BI、永洪 BI 等
|
||||
- TDengine 与 Grafana、Seeq 的集成
|
||||
|
||||
## 系统管理
|
||||
|
||||
|
|
@ -238,7 +238,7 @@ toc_max_heading_level: 4
|
|||
### 慢 SQL
|
||||
点击“系统管理”后，点击“慢 SQL”标签页，可以查看慢 SQL 执行语句日志统计与明细。
|
||||
|
||||
- 慢 SQL 明细：默认展示的是开始执行时间是一天内和执行耗时大于等于10秒的数据
|
||||
- 慢 SQL 明细：默认展示的是开始执行时间是一天内和执行耗时大于等于 10 秒的数据
|
||||
|
||||
- 慢 SQL 统计：默认展示所有的数据，可根据开始执行时间进行过滤
|
||||
|
||||
|
|
|
|||
|
|
@ -8,9 +8,7 @@ toc_max_heading_level: 4
|
|||
|
||||
# 1. 基于 taosdump 进行数据备份恢复
|
||||
|
||||
taosdump 是一个开源工具，用于支持从运行中的 TDengine 集群备份数据并将备份的数据恢复到相同或另一个正在运行的 TDengine
|
||||
集群中。taosdump 可以将数据库作为逻辑数据单元进行备份，也可以对数据库中指定时间段内的数据记录进行备份。在使用taosdump
|
||||
时，可以指定数据备份的目录路径。如果不指定目录路径，taosdump 将默认将数据备份到当前目录。
|
||||
taosdump 是一个开源工具，用于支持从运行中的 TDengine 集群备份数据并将备份的数据恢复到相同或另一个正在运行的 TDengine 集群中。taosdump 可以将数据库作为逻辑数据单元进行备份，也可以对数据库中指定时间段内的数据记录进行备份。在使用 taosdump 时，可以指定数据备份的目录路径。如果不指定目录路径，taosdump 将默认将数据备份到当前目录。
|
||||
|
||||
以下为 taosdump 执行数据备份的使用示例。
|
||||
|
||||
|
|
@ -18,14 +16,11 @@ taosdump 是一个开源工具，用于支持从运行中的 TDengine 集群备
|
|||
taosdump -h localhost -P 6030 -D dbname -o /file/path
|
||||
```
|
||||
|
||||
执行上述命令后，taosdump 会连接 localhost:6030 所在的 TDengine 集群，查询数据库 dbname 中的所有数据，并将数据备份到 /f
|
||||
ile/path 下。
|
||||
执行上述命令后，taosdump 会连接 localhost:6030 所在的 TDengine 集群，查询数据库 dbname 中的所有数据，并将数据备份到 /file/path 下。
|
||||
|
||||
在使用 taosdump 时，如果指定的存储路径已经包含数据文件，taosdump
|
||||
会提示用户并立即退出，以避免数据被覆盖。这意味着同一存储路径只能用于一次备份。如果你看到相关提示，请谨慎操作，以免误操作导致数据丢失。
|
||||
在使用 taosdump 时，如果指定的存储路径已经包含数据文件，taosdump 会提示用户并立即退出，以避免数据被覆盖。这意味着同一存储路径只能用于一次备份。如果你看到相关提示，请谨慎操作，以免误操作导致数据丢失。
|
||||
|
||||
要将本地指定文件路径中的数据文件恢复到正在运行的 TDengine 集群中，可以通过指定命令行参数和数据文件所在路径来执行 taosdump
|
||||
命令。以下为 taosdump 执行数据恢复的示例代码。
|
||||
要将本地指定文件路径中的数据文件恢复到正在运行的 TDengine 集群中，可以通过指定命令行参数和数据文件所在路径来执行 taosdump 命令。以下为 taosdump 执行数据恢复的示例代码。
|
||||
|
||||
```shell
|
||||
taosdump -i /file/path -h localhost -P 6030
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ toc_max_heading_level: 4
|
|||
|
||||
TDengine 支持 WAL 机制，实现数据的容错能力，保证数据的高可靠。TDengine 接收到应用程序的请求数据包时，会先将请求的原始数据包写入数据库日志文件，等数据成功写入数据库数据文件后，再删除相应的 WAL。这样保证了 TDengine 能够在断电等因素导致的服务重启时，从数据库日志文件中恢复数据，避免数据丢失。涉及的配置参数有如下两个：
|
||||
|
||||
- wal_level ：WAL 级别，1 表示写 WAL，但不执行 fsync ； 2 表示写 WAL，而且执行 fsync。默认值为 1。
|
||||
- wal_level：WAL 级别，1 表示写 WAL，但不执行 fsync；2 表示写 WAL，而且执行 fsync。默认值为 1。
|
||||
- wal_fsync_period：当 wal_level 设置为 2 时，执行 fsync 的周期；当 wal_fsync_period 设置为 0 时，表示每次写入，立即执行 fsync。
|
||||
|
||||
如果要 100% 保证数据不丢失，则需要将 wal_level 设置为 2，wal_fsync_period 设置为 0。这时写入速度将会下降。但如果应用程序侧启动的写数据的线程数达到一定的数量（超过 50），那么写入数据的性能也会很不错，只会比 wal_fsync_period 设置为 3000ms 下降 30% 左右。
|
||||
|
|
@ -27,10 +27,8 @@ TDengine 支持 WAL 机制，实现数据的容错能力，保证数据的高可
|
|||
|
||||
- 第 3 步，访问 TDengine 集群 B，创建一个与集群 A 中数据库 db1 参数配置相同的数据库 db2。
|
||||
|
||||
- 第 4 步，通过 Web 浏览器访问集群 B 的 taosExplorer 服务，在 “数据浏览器” 页面找到 db2，在 “查看数据库配置” 选项中可以获取该数据库的 DSN，例如 taos+ws://root:taosdata@clusterB:6041/db2
|
||||
- 第 4 步，通过 Web 浏览器访问集群 B 的 taosExplorer 服务，在 “数据浏览器” 页面找到 db2，在 “查看数据库配置” 选项中可以获取该数据库的 DSN，例如 `taos+ws://root:taosdata@clusterB:6041/db2`
|
||||
|
||||
- 第 5 步，在 taosExplorer 服务的“系统管理 - 数据同步”页面新增一个数据同步任务，在任务配置信息中填写需要同步的数据库 db1 和目标数据库 db2 的 DSN，完成创建任务后即可启动数据同步。
|
||||
|
||||
- 第 6 步，访问集群 B，可以看到集群 B 中的数据库 db2 源源不断写入来自集群 A 数据库 db1 的数据，直至两个集群的数据库数据量基本保持一致。至此，一个简单的基于
|
||||
|
||||
TDengine Enterprise 的数据灾备体系搭建完成。
|
||||
- 第 6 步，访问集群 B，可以看到集群 B 中的数据库 db2 源源不断写入来自集群 A 数据库 db1 的数据，直至两个集群的数据库数据量基本保持一致。至此，一个简单的基于 TDengine Enterprise 的数据灾备体系搭建完成。
|
||||
|
|
@ -5,10 +5,10 @@ toc_max_heading_level: 4
|
|||
---
|
||||
|
||||
本节介绍 TDengine Enterprise 特有的多级存储功能，其作用是将较近的热度较高的数据存储在高速介质上，而时间久远热度很低的数据存储在低成本介质上，达成了以下目标：
|
||||
- 降低存储成本 -- 将数据分级存储后，海量极冷数据存入廉价存储介质带来显著经济性
|
||||
- 提升写入性能 -- 得益于每级存储可支持多个挂载点，WAL 预写日志也支持 0 级的多挂载点并行写入，极大提升写入性能（实际场景测得支持持续写入每秒 3 亿测点以上），在机械硬盘上可获得极高磁盘 IO 吞吐（实测可达 2GB/s）
|
||||
- 方便维护 -- 配置好各级存储挂载点后，系统数据迁移等工作，无需人工干预；存储扩容更灵活、方便
|
||||
- 对 SQL 透明 -- 无论查询的数据是否跨级，一条 SQL 可返回所有数据，简单高效
|
||||
- **降低存储成本**：将数据分级存储后，海量极冷数据存入廉价存储介质带来显著经济性
|
||||
- **提升写入性能**：得益于每级存储可支持多个挂载点，WAL 预写日志也支持 0 级的多挂载点并行写入，极大提升写入性能（实际场景测得支持持续写入每秒 3 亿测点以上），在机械硬盘上可获得极高磁盘 IO 吞吐（实测可达 2GB/s）
|
||||
- **方便维护**：配置好各级存储挂载点后，系统数据迁移等工作，无需人工干预；存储扩容更灵活、方便
|
||||
- **对 SQL 透明**：无论查询的数据是否跨级，一条 SQL 可返回所有数据，简单高效
|
||||
|
||||
多级存储所涉及的各层存储介质都是本地存储设备。除了本地存储设备之外，TDengine Enterprise 还支持使用对象存储(S3)，将最冷的一批数据保存在最廉价的介质上，以进一步降低存储成本，并在必要时仍然可以进行查询，且数据存储在哪里也对 SQL 透明。支持对象存储在 3.3.0.0 版本中首次发布，建议使用最新版本。
|
||||
|
||||
|
|
@ -26,9 +26,11 @@ dataDir [path] <level> <primary>
|
|||
```
|
||||
|
||||
- path: 挂载点的文件夹路径。
|
||||
- level: 介质存储等级，取值为 0，1，2。 0 级存储最新的数据，1 级存储次新的数据，2 级存储最老的数据，省略默认为 0。 各级存储之间的数据流向：0 级存储 -> 1 级存储 -> 2 级存储。 同一存储等级可挂载多个硬盘，同一存储等级上的数据文件分布在该存储等级的所有硬盘上。 需要说明的是，数据在不同级别的存储介质上的移动，是由系统自动完成的，用户无需干预。
|
||||
- primary: 是否为主挂载点，0（否）或 1（是），省略默认为 1。
|
||||
- level：介质存储等级，取值为 0、1、2。 0 级存储最新的数据，1 级存储次新的数据，2 级存储最老的数据，省略默认为 0。各级存储之间的数据流向：0 级存储 -> 1 级存储 -> 2 级存储。 同一存储等级可挂载多个硬盘，同一存储等级上的数据文件分布在该存储等级的所有硬盘上。需要说明的是，数据在不同级别的存储介质上的移动，是由系统自动完成的，用户无需干预。
|
||||
- primary：是否为主挂载点，0（否）或 1（是），省略默认为 1。
|
||||
|
||||
在配置中，只允许一个主挂载点的存在（level=0，primary=1），例如采用如下的配置方式：
|
||||
|
||||
```shell
|
||||
dataDir /mnt/data1 0 1
|
||||
dataDir /mnt/data2 0 0
|
||||
|
|
@ -38,7 +40,8 @@ dataDir /mnt/data5 2 0
|
|||
dataDir /mnt/data6 2 0
|
||||
```
|
||||
|
||||
**注意** 1. 多级存储不允许跨级配置，合法的配置方案有：仅 0 级，仅 0 级+ 1 级，以及 0 级+ 1 级+ 2 级。而不允许只配置 level=0 和 level=2，而不配置 level=1。
|
||||
**注意**
|
||||
1. 多级存储不允许跨级配置，合法的配置方案有：仅 0 级、仅 0 级 + 1 级、以及 0 级 + 1 级 + 2 级。而不允许只配置 level=0 和 level=2，而不配置 level=1。
|
||||
2. 禁止手动移除使用中的挂载盘，挂载盘目前不支持非本地的网络盘。
|
||||
|
||||
### 负载均衡
|
||||
|
|
@ -74,13 +77,13 @@ dataDir /mnt/data6 2 0
|
|||
|
||||
| 参数名称 | 参数含义 |
|
||||
|:---------------------|:-----------------------------------------------|
|
||||
| s3EndPoint | 用户所在地域的 COS 服务域名，支持 http 和 https，bucket 的区域需要与 endpoint 的保持一致，否则无法访问。 |
|
||||
| s3EndPoint | 用户所在地域的 COS 服务域名，支持 http 和 https，bucket 的区域需要与 endpoint 的保持一致，否则无法访问 |
|
||||
| s3AccessKey | 冒号分隔的用户 SecretId:SecretKey。例如：AKIDsQmwsfKxTo2A6nGVXZN0UlofKn6JRRSJ:lIdoy99ygEacU7iHfogaN2Xq0yumSm1E |
|
||||
| s3BucketName | 存储桶名称，减号后面是用户注册 COS 服务的 AppId。其中 AppId 是 COS 特有，AWS 和阿里云都没有，配置时需要作为 bucket name 的一部分，使用减号分隔。参数值均为字符串类型，但不需要引号。例如：test0711-1309024725 |
|
||||
| s3UploadDelaySec | data 文件持续多长时间不再变动后上传至 s3，单位：秒。最小值：1；最大值：2592000（30天），默认值 60 秒 |
|
||||
| s3PageCacheSize | S3 page cache 缓存页数目，单位：页。最小值：4；最大值：1024*1024*1024。 ，默认值 4096|
|
||||
| s3MigrateIntervalSec | 本地数据文件自动上传 S3 的触发周期，单位为秒。最小值：600；最大值：100000。默认值 3600 |
|
||||
| s3MigrateEnabled | 是否自动进行 S3 迁移，默认值为 0，表示关闭自动 S3 迁移，可配置为 1。 |
|
||||
| s3MigrateEnabled | 是否自动进行 S3 迁移，默认值为 0，表示关闭自动 S3 迁移，可配置为 1 |
|
||||
|
||||
#### 检查配置参数可用性
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ alter_user_clause: {
|
|||
- pass：修改用户密码。
|
||||
- enable：是否启用用户。1 表示启用此用户，0 表示禁用此用户。
|
||||
- sysinfo ：用户是否可查看系统信息。1 表示可以查看系统信息，0 表示不可以查看系统信息
|
||||
- createdb：用户是否可创建数据库。1 表示可以创建数据库，0 表示不可以创建数据库。// 从 TDengine 企业版 3.3.2.0 开始支持
|
||||
- createdb：用户是否可创建数据库。1 表示可以创建数据库，0 表示不可以创建数据库。从 TDengine 企业版 3.3.2.0 开始支持。
|
||||
|
||||
如下 SQL 禁用 test 用户。
|
||||
```sql
|
||||
|
|
@ -76,7 +76,7 @@ drop user user_name
|
|||
|
||||
### 库和表的授权
|
||||
|
||||
在 TDengine 中，库和表的权限分为 read （读）和 write （写）两种。这些权限可以单独授予，也可以同时授予用户。
|
||||
在 TDengine 中，库和表的权限分为 read 和 write 两种。这些权限可以单独授予，也可以同时授予用户。
|
||||
|
||||
- read 权限：拥有 read 权限的用户仅能查询库或表中的数据，而无法对数据进行修改或删除。这种权限适用于需要访问数据但不需要对数据进行写入操作的场景，如数据分析师、报表生成器等。
|
||||
- write 权限：拥有 write 权限的用户可以向库或表中写入数据。这种权限适用于需要对数据进行写入操作的场景，如数据采集器、数据处理器等。如果只拥有 write 权限而没有 read 权限，则只能写入数据但不能查询数据。
|
||||
|
|
@ -101,10 +101,11 @@ resources ：{
|
|||
```
|
||||
|
||||
相关参数说明如下。
|
||||
- resources ：可以访问的库或表。. 之前为数据库名称，. 之后为表名称。dbname.tbname 的意思是名为 dbname 的数据库中的 tbname 表必须为普通表或超级表。dbname.* 的意思是名为 dbname 的数据库中的所有表。*.* 的意思是所有数据库中的所有表。
|
||||
- tag_f ilter：超级表的过滤条件。
|
||||
- resources：可以访问的库或表。`.` 之前为数据库名称，`.` 之后为表名称。`dbname.tbname` 的意思是名为 dbname 的数据库中的 tbname 表必须为普通表或超级表。`dbname.*` 的意思是名为 dbname 的数据库中的所有表。`*.*` 的意思是所有数据库中的所有表。
|
||||
- tag_filter：超级表的过滤条件。
|
||||
|
||||
上述 SQL 既可以授权一个库、所有库，也可以授权一个库下的普通表或超级表，还可以通过 `dbname.tbname` 和 `with` 子句的组合授权符合过滤条件的一张超级表下的所有子表。
|
||||
|
||||
上述 SQL 既可以授权一个库、所有库，也可以授权一个库下的普通表或超级表，还可以通过 dbname.tbname 和 with 子句的组合授权符合过滤条件的一张超级表下的所有子表。
|
||||
如下 SQL 将数据库 power 的 read 权限授权给用户 test。
|
||||
```sql
|
||||
grant read on power to test
|
||||
|
|
|
|||
|
|
@ -28,24 +28,24 @@ ALTER USER TEST DROP HOST HOST_NAME1
|
|||
```
|
||||
说明
|
||||
- 开源版和企业版本都能添加成功，且可以查询到，但是开源版本不会对 IP 做任何限制。
|
||||
- create user u_write pass 'taosdata1' host 'iprange1','iprange2', 可以一次添加多个 iprange, 服务端会做去重，去重的逻辑是需要 iprange 完全一样
|
||||
- 默认会把 127.0.0.1 添加到白名单列表，且在白名单列表可以查询
|
||||
- `create user u_write pass 'taosdata1' host 'iprange1','iprange2'`，可以一次添加多个 ip range，服务端会做去重，去重的逻辑是需要 ip range 完全一样
|
||||
- 默认会把 `127.0.0.1` 添加到白名单列表，且在白名单列表可以查询
|
||||
- 集群的节点 IP 集合会自动添加到白名单列表，但是查询不到。
|
||||
- taosadaper 和 taosd 不在一个机器的时候，需要把 taosadaper IP 手动添加到 taosd 白名单列表中
|
||||
- 集群情况下，各个节点 enableWhiteList 成一样，或者全为 false,或者全为 true, 要不然集群无法启动
|
||||
- 白名单变更生效时间 1s，不超过 2s, 每次变更对收发性能有些微影响（多一次判断，可以忽略），变更完之后、影响忽略不计, 变更过程中对集群没有影响，对正在访问客户端也没有影响（假设这些客户端的 IP 包含在 white list 内）
|
||||
- 如果添加两个 ip range, 192.168.1.1/16(假设为 A), 192.168.1.1/24(假设为 B), 严格来说，A 包含了 B，但是考虑情况太复杂，并不会对 A 和 B 做合并
|
||||
- 要删除的时候，必须严格匹配。 也就是如果添加的是 192.168.1.1/24, 要删除也是 192.168.1.1/24
|
||||
- 集群情况下，各个节点 enableWhiteList 成一样，或者全为 false，或者全为 true，要不然集群无法启动
|
||||
- 白名单变更生效时间 1s，不超过 2s，每次变更对收发性能有些微影响（多一次判断，可以忽略），变更完之后、影响忽略不计，变更过程中对集群没有影响，对正在访问客户端也没有影响（假设这些客户端的 IP 包含在 white list 内）
|
||||
- 如果添加两个 ip range，192.168.1.1/16(假设为 A)，192.168.1.1/24(假设为 B)，严格来说，A 包含了 B，但是考虑情况太复杂，并不会对 A 和 B 做合并
|
||||
- 要删除的时候，必须严格匹配。 也就是如果添加的是 192.168.1.1/24，要删除也是 192.168.1.1/24
|
||||
- 只有 root 才有权限对其他用户增删 ip white list
|
||||
- 兼容之前的版本，但是不支持从当前版本回退到之前版本
|
||||
- x.x.x.x/32 和 x.x.x.x 属于同一个 iprange, 显示为 x.x.x.x
|
||||
- 如果客户端拿到的 0.0.0.0/0, 说明没有开启白名单
|
||||
- x.x.x.x/32 和 x.x.x.x 属于同一个 iprange，显示为 x.x.x.x
|
||||
- 如果客户端拿到的 0.0.0.0/0，说明没有开启白名单
|
||||
- 如果白名单发生了改变， 客户端会在 heartbeat 里检测到。
|
||||
- 针对一个 user, 添加的 IP 个数上限是 2048
|
||||
- 针对一个 user，添加的 IP 个数上限是 2048
|
||||
|
||||
## 审计日志
|
||||
|
||||
TDengine 先对用户操作进行记录和管理，然后将这些作为审计日志发送给taosKeeper，再由 taosKeeper 保存至任意 TDengine 集群。管理员可通过审计日志进行安全监控、历史追溯。TDengine 的审计日志功能开启和关闭操作非常简单，只须修改TDengine 的配置文件后重启服务。审计日志的配置说明如下。
|
||||
TDengine 先对用户操作进行记录和管理，然后将这些作为审计日志发送给 taosKeeper，再由 taosKeeper 保存至任意 TDengine 集群。管理员可通过审计日志进行安全监控、历史追溯。TDengine 的审计日志功能开启和关闭操作非常简单，只须修改 TDengine 的配置文件后重启服务。审计日志的配置说明如下。
|
||||
|
||||
### taosd 配置
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ TDengine 先对用户操作进行记录和管理，然后将这些作为审计
|
|||
|
||||
| 参数名称 | 参数含义 |
|
||||
|:-------------:|:--------------------------------------------------------:|
|
||||
|audit | 是否打开审计日志，默认值为 0。1 为开启，0 为关闭 |
|
||||
|audit | 是否打开审计日志，1 为开启，0 为关闭，默认值为 0。 |
|
||||
|monitorFqdn | 接收审计日志的 taosKeeper 所在服务器的 FQDN |
|
||||
|monitorPort | 接收审计日志的 taosKeeper 服务所用端口 |
|
||||
|monitorCompaction | 上报数据时是否进行压缩 |
|
||||
|
|
@ -64,7 +64,7 @@ TDengine 先对用户操作进行记录和管理，然后将这些作为审计
|
|||
|
||||
| 参数名称 | 参数含义 |
|
||||
|:-------------:|:--------------------------------------------------------:|
|
||||
|auditDB | 用于存放审计日志的数据库的名字，默认值为 "audit" ，taosKeeper 在收到上报的审计日志后会判断该数据库是否存在，如果不存在会自动创建它 |
|
||||
|auditDB | 用于存放审计日志的数据库的名字，默认值为 "audit"，taosKeeper 在收到上报的审计日志后会判断该数据库是否存在，如果不存在会自动创建 |
|
||||
|
||||
### 数据格式
|
||||
|
||||
|
|
@ -88,19 +88,19 @@ TDengine 先对用户操作进行记录和管理，然后将这些作为审计
|
|||
taosKeeper 会依据上报的审计数据在相应的数据库中自动建立超级表用于存储数据。该超级表的定义如下
|
||||
|
||||
```sql
|
||||
CREATE STABLE operations(ts timestamp, details VARCHAR(64000)， User VARCHAR(25), Operation VARCHAR(20), db VARCHAR(65), resource VARCHAR(193), client_add(25)) TAGS (clusterID VARCHAR(64) );
|
||||
create stable operations(ts timestamp, details varchar(64000)， user varchar(25), operation varchar(20), db varchar(65), resource varchar(193), client_add(25)) tags (clusterID varchar(64) );
|
||||
```
|
||||
|
||||
其中：
|
||||
1. db为操作涉及的database，resource为操作涉及的资源。
|
||||
2. User 和 Operation 为数据列，表示哪个用户在该对象上进行了什么操作
|
||||
其中
|
||||
1. db 为操作涉及的 database，resource 为操作涉及的资源。
|
||||
2. user 和 operation 为数据列，表示哪个用户在该对象上进行了什么操作
|
||||
3. timestamp 为时间戳列，表示操作发生时的时间
|
||||
4. details 为该操作的一些补充细节，在大多数操作下是所执行的操作的SQL语句。
|
||||
5. client_add为客户端地址，包括ip和端口
|
||||
4. details 为该操作的一些补充细节，在大多数操作下是所执行的操作的 SQL 语句。
|
||||
5. client_add 为客户端地址，包括 ip 和端口
|
||||
|
||||
### 操作列表
|
||||
|
||||
目前审计日志中所记录的操作列表以及每个操作中各字段的含义如下表（注：因为每个操作的实加者即 user 字段、时间戳字段和client_add在所有操作中的含义相同，下表不包含）
|
||||
目前审计日志中所记录的操作列表以及每个操作中各字段的含义（因为每个操作的施加者，即 user、client_add、时间戳字段在所有操作中的含义相同，下表不再描述）
|
||||
|
||||
| 操作 | Operation | DB | Resource | Details |
|
||||
| ----------------| ----------| ---------| ---------| --------|
|
||||
|
|
@ -110,8 +110,8 @@ CREATE STABLE operations(ts timestamp, details VARCHAR(64000)， User VARCHAR(25
|
|||
| create stable | createStb | db name | stable name | SQL |
|
||||
| alter stable | alterStb | db name | stable name | SQL |
|
||||
| drop stable | dropStb | db name | stable name | SQL |
|
||||
| create user | createUser | NULL | 被创建的用户名 | 用户属性参数, (password除外) |
|
||||
| alter user | alterUser | NULL | 被修改的用户名 | 修改密码操作记录的是被修改的参数和新值 (password除外) ；其他操作记录SQL |
|
||||
| create user | createUser | NULL | 被创建的用户名 | 用户属性参数， (password 除外) |
|
||||
| alter user | alterUser | NULL | 被修改的用户名 | 修改密码记录被修改的参数和新值 (password 除外)，其他操作记录 SQL |
|
||||
| drop user | dropUser | NULL | 被删除的用户名 | SQL |
|
||||
| create topic | createTopic | topic 所在 DB | 创建的 topic 名字 | SQL |
|
||||
| drop topic | cropTopic | topic 所在 DB | 删除的 topic 名字 | SQL |
|
||||
|
|
@ -123,7 +123,7 @@ CREATE STABLE operations(ts timestamp, details VARCHAR(64000)， User VARCHAR(25
|
|||
| create qnode | createQnode | NULL | dnodeId | SQL |
|
||||
| drop qnode | dropQnode | NULL | dnodeId | SQL |
|
||||
| login | login | NULL | NULL | appName |
|
||||
| create stream | createStream | NULL | 所创建的 strem 名 | SQL |
|
||||
| create stream | createStream | NULL | 所创建的 stream 名 | SQL |
|
||||
| drop stream | dropStream | NULL | 所删除的 stream 名 | SQL |
|
||||
| grant privileges| grantPrivileges | NULL | 所授予的用户 | SQL |
|
||||
| remove privileges | revokePrivileges | NULL | 被收回权限的用户 | SQL |
|
||||
|
|
@ -171,7 +171,7 @@ database_option: {
|
|||
```
|
||||
|
||||
主要参数说明如下。
|
||||
encrypt_algorithm：指定数据采用的加密算法。默认是 none，即不采用加密。sm4 表示采用 SM4 加密算法
|
||||
- encrypt_algorithm：指定数据采用的加密算法。默认是 none，即不采用加密。sm4 表示采用 SM4 加密算法
|
||||
|
||||
### 查看加密配置
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ select name, `encrypt_algorithm` from ins_databases;
|
|||
|
||||
### 查看节点密钥状态
|
||||
|
||||
通过以下的SQL命令参看节点密钥状态：
|
||||
通过以下的 SQL 命令参看节点密钥状态。
|
||||
|
||||
```sql
|
||||
show encryptions;
|
||||
|
|
@ -200,12 +200,12 @@ select * from information_schema.ins_encryptions;
|
|||
```
|
||||
key_status 有三种取值：
|
||||
- 当节点未设置密钥时，状态列显示 unset。
|
||||
- 当密钥被检验成功并且加载后，状态列显示 loaded.
|
||||
- 当节点未启动，key的状态无法被探知时，状态列显示 unknown
|
||||
- 当密钥被检验成功并且加载后，状态列显示 loaded。
|
||||
- 当节点未启动，key 的状态无法被探知时，状态列显示 unknown。
|
||||
|
||||
### 更新密钥配置
|
||||
|
||||
当节点的硬件配置发生变更时，需要通过以下命令更新密钥，与离线配置密钥的命令相同：
|
||||
当节点的硬件配置发生变更时，需要通过以下命令更新密钥，与离线配置密钥的命令相同。
|
||||
|
||||
```shell
|
||||
taosd -y {encryptKey}
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ description: 使用 Prometheus 访问 TDengine
|
|||
|
||||
import Prometheus from "../../14-reference//01-components/_prometheus.mdx"
|
||||
|
||||
Prometheus 是一款流行的开源监控告警系统。Prometheus 于2016年加入了 Cloud Native Computing Foundation （云原生云计算基金会，简称 CNCF），成为继 Kubernetes 之后的第二个托管项目，该项目拥有非常活跃的开发人员和用户社区。
|
||||
Prometheus 是一款流行的开源监控告警系统。Prometheus 于 2016 年加入了 Cloud Native Computing Foundation （云原生云计算基金会，简称 CNCF），成为继 Kubernetes 之后的第二个托管项目，该项目拥有非常活跃的开发人员和用户社区。
|
||||
|
||||
Prometheus 提供了 `remote_write` 和 `remote_read` 接口来利用其它数据库产品作为它的存储引擎。为了让 Prometheus 生态圈的用户能够利用 TDengine 的高效写入和查询，TDengine 也提供了对这两个接口的支持。
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ Prometheus 提供了 `remote_write` 和 `remote_read` 接口来利用其它数
|
|||
要将 Prometheus 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- Prometheus 已经安装。安装 Prometheus 请参考[官方文档](https://prometheus.io/docs/prometheus/latest/installation/)
|
||||
- Prometheus 已经安装。安装 Prometheus 请参考 [官方文档](https://prometheus.io/docs/prometheus/latest/installation/)
|
||||
|
||||
## 配置步骤
|
||||
<Prometheus />
|
||||
|
|
|
|||
|
|
@ -15,8 +15,8 @@ Telegraf 是一款十分流行的指标采集开源软件。在数据采集和
|
|||
要将 Telegraf 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- Telegraf 已经安装。安装 Telegraf 请参考[官方文档](https://docs.influxdata.com/telegraf/v1.22/install/)
|
||||
- Telegraf 默认采集系统运行状态数据。通过使能[输入插件](https://docs.influxdata.com/telegraf/v1.22/plugins/)方式可以输出[其他格式](https://docs.influxdata.com/telegraf/v1.24/data_formats/input/)的数据到 Telegraf 再写入到 TDengine中。
|
||||
- Telegraf 已经安装。安装 Telegraf 请参考 [官方文档](https://docs.influxdata.com/telegraf/v1.22/install/)
|
||||
- Telegraf 默认采集系统运行状态数据。通过使能 [输入插件](https://docs.influxdata.com/telegraf/v1.22/plugins/)方式可以输出 [其他格式](https://docs.influxdata.com/telegraf/v1.24/data_formats/input/) 的数据到 Telegraf 再写入到 TDengine中。
|
||||
|
||||
## 配置步骤
|
||||
<Telegraf />
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ collectd 是一个用来收集系统性能的守护进程。collectd 提供各
|
|||
|
||||
要将 collectd 数据写入 TDengine，需要几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行，具体细节请参考[ taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- taosAdapter 已经安装并正常运行，具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- collectd 已经安装。安装 collectd 请参考[官方文档](https://collectd.org/download.shtml)
|
||||
|
||||
## 配置步骤
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ StatsD 是汇总和总结应用指标的一个简单的守护进程，近些年
|
|||
要将 StatsD 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- StatsD 已经安装。安装 StatsD 请参考[官方文档](https://github.com/statsd/statsd)
|
||||
- StatsD 已经安装。安装 StatsD 请参考 [官方文档](https://github.com/statsd/statsd)
|
||||
|
||||
## 配置步骤
|
||||
<StatsD />
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ icinga2 是一款开源主机、网络监控软件，最初由 Nagios 网络监
|
|||
|
||||
要将 icinga2 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考[ taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- icinga2 已经安装。安装 icinga2 请参考[官方文档](https://icinga.com/docs/icinga-2/latest/doc/02-installation/)
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- icinga2 已经安装。安装 icinga2 请参考 [官方文档](https://icinga.com/docs/icinga-2/latest/doc/02-installation/)
|
||||
|
||||
## 配置步骤
|
||||
<Icinga2 />
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ TCollector 是 openTSDB 的一部分，它用来采集客户端日志发送给
|
|||
要将 TCollector 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- TCollector 已经安装。安装 TCollector 请参考[官方文档](http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html#installation-of-tcollector)
|
||||
- TCollector 已经安装。安装 TCollector 请参考 [官方文档](http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html#installation-of-tcollector)
|
||||
|
||||
## 配置步骤
|
||||
<TCollector />
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: EMQX Broker 写入
|
|||
description: 使用 EMQX Broker 写入 TDengine
|
||||
---
|
||||
|
||||
MQTT 是流行的物联网数据传输协议，[EMQX](https://github.com/emqx/emqx)是一开源的 MQTT Broker 软件，无需任何代码，只需要在 EMQX Dashboard 里使用“规则”做简单配置，即可将 MQTT 的数据直接写入 TDengine。EMQX 支持通过 发送到 Web 服务的方式保存数据到 TDengine，也在企业版上提供原生的 TDengine 驱动实现直接保存。
|
||||
MQTT 是流行的物联网数据传输协议，[EMQX](https://github.com/emqx/emqx) 是一开源的 MQTT Broker 软件，无需任何代码，只需要在 EMQX Dashboard 里使用“规则”做简单配置，即可将 MQTT 的数据直接写入 TDengine。EMQX 支持通过 发送到 Web 服务的方式保存数据到 TDengine，也在企业版上提供原生的 TDengine 驱动实现直接保存。
|
||||
|
||||
## 前置条件
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ USE test;
|
|||
CREATE TABLE sensor_data (ts TIMESTAMP, temperature FLOAT, humidity FLOAT, volume FLOAT, pm10 FLOAT, pm25 FLOAT, so2 FLOAT, no2 FLOAT, co FLOAT, sensor_id NCHAR(255), area TINYINT, coll_time TIMESTAMP);
|
||||
```
|
||||
|
||||
注：表结构以博客[数据传输、存储、展现，EMQX + TDengine 搭建 MQTT 物联网数据可视化平台](https://www.taosdata.com/blog/2020/08/04/1722.html)为例。后续操作均以此博客场景为例进行，请你根据实际应用场景进行修改。
|
||||
注：表结构以博客 [数据传输、存储、展现，EMQX + TDengine 搭建 MQTT 物联网数据可视化平台](https://www.taosdata.com/blog/2020/08/04/1722.html) 为例。后续操作均以此博客场景为例进行，请你根据实际应用场景进行修改。
|
||||
|
||||
## 配置 EMQX 规则
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ FROM
|
|||
"sensor/data"
|
||||
```
|
||||
|
||||
其中 `payload` 代表整个消息体， `sensor/data` 为本规则选取的消息主题。
|
||||
其中 `payload` 代表整个消息体，`sensor/data` 为本规则选取的消息主题。
|
||||
|
||||
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ FROM
|
|||
|
||||
### 编辑“资源（Resource）”
|
||||
|
||||
选择“WebHook”并填写“请求 URL”为 taosAdapter 提供 REST 服务的地址，如果是本地启动的 taosadapter， 那么默认地址为：
|
||||
选择 “WebHook” 并填写“请求 URL”为 taosAdapter 提供 REST 服务的地址，如果是本地启动的 taosadapter， 那么默认地址为：
|
||||
|
||||
```
|
||||
http://127.0.0.1:6041/rest/sql
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: TDengine Kafka Connector
|
|||
description: 使用 TDengine Kafka Connector 的详细指南
|
||||
---
|
||||
|
||||
TDengine Kafka Connector 包含两个插件: TDengine Source Connector 和 TDengine Sink Connector。用户只需提供简单的配置文件，就可以将 Kafka 中指定 topic 的数据（批量或实时）同步到 TDengine， 或将 TDengine 中指定数据库的数据（批量或实时）同步到 Kafka。
|
||||
TDengine Kafka Connector 包含 TDengine Source Connector 和 TDengine Sink Connector 两个插件。用户只需提供简单的配置文件，就可以将 Kafka 中指定 topic 的数据（批量或实时）同步到 TDengine，或将 TDengine 中指定数据库的数据（批量或实时）同步到 Kafka。
|
||||
|
||||
## 什么是 Kafka Connect？
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ TDengine Source Connector 用于把数据实时地从 TDengine 读出来发送
|
|||
1. Linux 操作系统
|
||||
2. 已安装 Java 8 和 Maven
|
||||
3. 已安装 Git、curl、vi
|
||||
4. 已安装并启动 TDengine。如果还没有可参考[安装和卸载](../../../get-started/)
|
||||
4. 已安装并启动 TDengine。如果还没有可参考 [安装和卸载](../../../get-started/)
|
||||
|
||||
## 安装 Kafka
|
||||
|
||||
|
|
@ -90,9 +90,9 @@ curl http://localhost:8083/connectors
|
|||
|
||||
## TDengine Sink Connector 的使用
|
||||
|
||||
TDengine Sink Connector 的作用是同步指定 topic 的数据到 TDengine。用户无需提前创建数据库和超级表。可手动指定目标数据库的名字（见配置参数 connection.database）， 也可按一定规则生成(见配置参数 connection.database.prefix)。
|
||||
TDengine Sink Connector 的作用是同步指定 topic 的数据到 TDengine。用户无需提前创建数据库和超级表。可手动指定目标数据库的名字（见配置参数 connection.database），也可按一定规则生成(见配置参数 connection.database.prefix)。
|
||||
|
||||
TDengine Sink Connector 内部使用 TDengine [无模式写入接口](../../../develop/schemaless)写数据到 TDengine，目前支持三种格式的数据：InfluxDB 行协议格式，OpenTSDB Telnet 协议格式，和 OpenTSDB JSON 协议格式。
|
||||
TDengine Sink Connector 内部使用 TDengine [无模式写入接口](../../../develop/schemaless) 写数据到 TDengine，目前支持三种格式的数据：InfluxDB 行协议格式，OpenTSDB Telnet 协议格式，和 OpenTSDB JSON 协议格式。
|
||||
|
||||
下面的示例将主题 meters 的数据，同步到目标数据库 power。数据格式为 InfluxDB Line 协议格式。
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ taos> select * from meters;
|
|||
Query OK, 4 row(s) in set (0.004208s)
|
||||
```
|
||||
|
||||
若看到了以上数据，则说明同步成功。若没有，请检查 Kafka Connect 的日志。配置参数的详细说明见[配置参考](#配置参考)。
|
||||
若看到了以上数据，则说明同步成功。若没有，请检查 Kafka Connect 的日志。配置参数的详细说明见 [配置参考](#配置参考)。
|
||||
|
||||
## TDengine Source Connector 的使用
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ curl -X POST -d @source-demo.json http://localhost:8083/connectors -H "Content-T
|
|||
|
||||
### 查看 topic 数据
|
||||
|
||||
使用 kafka-console-consumer 命令行工具监控主题 tdengine-test-meters 中的数据。一开始会输出所有历史数据， 往 TDengine 插入两条新的数据之后，kafka-console-consumer 也立即输出了新增的两条数据。 输出数据 InfluxDB line protocol 的格式。
|
||||
使用 kafka-console-consumer 命令行工具监控主题 tdengine-test-meters 中的数据。一开始会输出所有历史数据，往 TDengine 插入两条新的数据之后，kafka-console-consumer 也立即输出了新增的两条数据。输出数据 InfluxDB line protocol 的格式。
|
||||
|
||||
```shell
|
||||
kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic tdengine-test-meters
|
||||
|
|
@ -299,7 +299,7 @@ meters,location="California.SanFrancisco",groupid=2i32 current=12.6f32,voltage=2
|
|||
......
|
||||
```
|
||||
|
||||
此时会显示所有历史数据。切换到 TDengine CLI， 插入两条新的数据：
|
||||
此时会显示所有历史数据。切换到 TDengine CLI，插入两条新的数据：
|
||||
|
||||
```sql
|
||||
USE test;
|
||||
|
|
@ -307,7 +307,7 @@ INSERT INTO d1001 VALUES (now, 13.3, 229, 0.38);
|
|||
INSERT INTO d1002 VALUES (now, 16.3, 233, 0.22);
|
||||
```
|
||||
|
||||
再切换回 kafka-console-consumer， 此时命令行窗口已经打印出刚插入的 2 条数据。
|
||||
再切换回 kafka-console-consumer，此时命令行窗口已经打印出刚插入的 2 条数据。
|
||||
|
||||
### unload 插件
|
||||
|
||||
|
|
@ -335,7 +335,7 @@ curl -X DELETE http://localhost:8083/connectors/TDengineSourceConnector
|
|||
| **参数** | **参数说明** | **设置建议** |
|
||||
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
|
||||
| producer.type | 此参数用于设置消息的发送方式，默认值为 `sync` 表示同步发送，`async` 表示异步发送。采用异步发送能够提升消息发送的吞吐量。 | async |
|
||||
| request.required.acks | 参数用于配置生产者发送消息后需要等待的确认数量。当设置为1时，表示只要领导者副本成功写入消息就会给生产者发送确认，而无需等待集群中的其他副本写入成功。这种设置可以在一定程度上保证消息的可靠性，同时也能保证一定的吞吐量。因为不需要等待所有副本都写入成功，所以可以减少生产者的等待时间，提高发送消息的效率。 | 1 |
|
||||
| request.required.acks | 参数用于配置生产者发送消息后需要等待的确认数量。当设置为 1 时，表示只要领导者副本成功写入消息就会给生产者发送确认，而无需等待集群中的其他副本写入成功。这种设置可以在一定程度上保证消息的可靠性，同时也能保证一定的吞吐量。因为不需要等待所有副本都写入成功，所以可以减少生产者的等待时间，提高发送消息的效率。 | 1 |
|
||||
| max.request.size | 该参数决定了生产者在一次请求中可以发送的最大数据量。其默认值为 1048576，也就是 1M。如果设置得太小，可能会导致频繁的网络请求，降低吞吐量。如果设置得太大，可能会导致内存占用过高，或者在网络状况不佳时增加请求失败的概率。建议设置为 100M。 | 104857600 |
|
||||
| batch.size | 此参数用于设定 batch 的大小，默认值为 16384，即 16KB。在消息发送过程中，发送到 Kafka 缓冲区中的消息会被划分成一个个的 batch。故而减小 batch 大小有助于降低消息延迟，而增大 batch 大小则有利于提升吞吐量，可根据实际的数据量大小进行合理配置。可根据实际情况进行调整，建议设置为 512K。 | 524288 |
|
||||
| buffer.memory | 此参数用于设置生产者缓冲待发送消息的内存总量。较大的缓冲区可以允许生产者积累更多的消息后批量发送，提高吞吐量，但也会增加延迟和内存使用。可根据机器资源来配置，建议配置为 1G。 | 1073741824 |
|
||||
|
|
@ -346,51 +346,51 @@ curl -X DELETE http://localhost:8083/connectors/TDengineSourceConnector
|
|||
|
||||
以下配置项对 TDengine Sink Connector 和 TDengine Source Connector 均适用。
|
||||
|
||||
1. `name`: connector 名称。
|
||||
1. `connector.class`: connector 的完整类名， 如: com.taosdata.kafka.connect.sink.TDengineSinkConnector。
|
||||
1. `tasks.max`: 最大任务数, 默认 1。
|
||||
1. `topics`: 需要同步的 topic 列表， 多个用逗号分隔, 如 `topic1,topic2`。
|
||||
1. `connection.url`: TDengine JDBC 连接字符串， 如 `jdbc:TAOS://127.0.0.1:6030`。
|
||||
1. `connection.user`： TDengine 用户名， 默认 root。
|
||||
1. `connection.password` ：TDengine 用户密码， 默认 taosdata。
|
||||
1. `connection.attempts` ：最大尝试连接次数。默认 3。
|
||||
1. `connection.backoff.ms` ： 创建连接失败重试时间隔时间，单位为 ms。 默认 5000。
|
||||
1. `data.precision`: 使用 InfluxDB 行协议格式时，时间戳的精度。可选值为：
|
||||
1. ms ： 表示毫秒
|
||||
1. us ： 表示微秒
|
||||
1. ns ： 表示纳秒
|
||||
1. `name`：connector 名称。
|
||||
1. `connector.class`：connector 的完整类名，例如如 com.taosdata.kafka.connect.sink.TDengineSinkConnector。
|
||||
1. `tasks.max`：最大任务数, 默认 1。
|
||||
1. `topics`：需要同步的 topic 列表，多个用逗号分隔, 如 `topic1,topic2`。
|
||||
1. `connection.url`：TDengine JDBC 连接字符串，如 `jdbc:TAOS://127.0.0.1:6030`。
|
||||
1. `connection.user`：TDengine 用户名，默认 root。
|
||||
1. `connection.password`：TDengine 用户密码，默认 taosdata。
|
||||
1. `connection.attempts`：最大尝试连接次数。默认 3。
|
||||
1. `connection.backoff.ms`：创建连接失败重试时间隔时间，单位为 ms。默认 5000。
|
||||
1. `data.precision`：使用 InfluxDB 行协议格式时，时间戳的精度。可选值为：
|
||||
1. ms：表示毫秒
|
||||
1. us：表示微秒
|
||||
1. ns：表示纳秒
|
||||
|
||||
### TDengine Sink Connector 特有的配置
|
||||
|
||||
1. `connection.database`： 目标数据库名。如果指定的数据库不存在会则自动创建。自动建库使用的时间精度为纳秒。默认值为 null。为 null 时目标数据库命名规则参考 `connection.database.prefix` 参数的说明
|
||||
2. `connection.database.prefix`： 当 connection.database 为 null 时, 目标数据库的前缀。可以包含占位符 '$\{topic}'。 比如 kafka_$\{topic}, 对于主题 'orders' 将写入数据库 'kafka_orders'。 默认 null。当为 null 时，目标数据库的名字和主题的名字是一致的。
|
||||
3. `batch.size`: 分批写入每批记录数。当 Sink Connector 一次接收到的数据大于这个值时将分批写入。
|
||||
4. `max.retries`: 发生错误时的最大重试次数。默认为 1。
|
||||
5. `retry.backoff.ms`: 发送错误时重试的时间间隔。单位毫秒，默认为 3000。
|
||||
6. `db.schemaless`: 数据格式，可选值为：
|
||||
1. line ：代表 InfluxDB 行协议格式
|
||||
2. json : 代表 OpenTSDB JSON 格式
|
||||
3. telnet ：代表 OpenTSDB Telnet 行协议格式
|
||||
1. `connection.database`：目标数据库名。如果指定的数据库不存在会则自动创建。自动建库使用的时间精度为纳秒。默认值为 null。为 null 时目标数据库命名规则参考 `connection.database.prefix` 参数的说明
|
||||
2. `connection.database.prefix`：当 connection.database 为 null 时, 目标数据库的前缀。可以包含占位符 '$\{topic}'。比如 kafka_$\{topic}, 对于主题 'orders' 将写入数据库 'kafka_orders'。默认 null。当为 null 时，目标数据库的名字和主题的名字是一致的。
|
||||
3. `batch.size`：分批写入每批记录数。当 Sink Connector 一次接收到的数据大于这个值时将分批写入。
|
||||
4. `max.retries`：发生错误时的最大重试次数。默认为 1。
|
||||
5. `retry.backoff.ms`：发送错误时重试的时间间隔。单位毫秒，默认为 3000。
|
||||
6. `db.schemaless`：数据格式，可选值为：
|
||||
1. line：代表 InfluxDB 行协议格式
|
||||
2. json：代表 OpenTSDB JSON 格式
|
||||
3. telnet：代表 OpenTSDB Telnet 行协议格式
|
||||
|
||||
### TDengine Source Connector 特有的配置
|
||||
|
||||
1. `connection.database`: 源数据库名称，无缺省值。
|
||||
1. `topic.prefix`： 数据导入 kafka 时使用的 topic 名称的前缀。默认为空字符串 ""。
|
||||
1. `timestamp.initial`: 数据同步起始时间。格式为'yyyy-MM-dd HH:mm:ss'，若未指定则从指定 DB 中最早的一条记录开始。
|
||||
1. `poll.interval.ms`: 检查是否有新建或删除的表的时间间隔，单位为 ms。默认为 1000。
|
||||
1. `fetch.max.rows` : 检索数据库时最大检索条数。 默认为 100。
|
||||
1. `query.interval.ms`: 从 TDengine 一次读取数据的时间跨度，需要根据表中的数据特征合理配置，避免一次查询的数据量过大或过小；在具体的环境中建议通过测试设置一个较优值，默认值为 0，即获取到当前最新时间的所有数据。
|
||||
1. `out.format` : 结果集输出格式。`line` 表示输出格式为 InfluxDB Line 协议格式，`json` 表示输出格式是 json。默认为 line。
|
||||
1. `topic.per.stable`: 如果设置为 true，表示一个超级表对应一个 Kafka topic，topic的命名规则 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`；如果设置为 false，则指定的 DB 中的所有数据进入一个 Kafka topic，topic 的命名规则为 `<topic.prefix><topic.delimiter><connection.database>`
|
||||
1. `topic.ignore.db`: topic 命名规则是否包含 database 名称，true 表示规则为 `<topic.prefix><topic.delimiter><stable.name>`，false 表示规则为 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`，默认 false。此配置项在 `topic.per.stable` 设置为 false 时不生效。
|
||||
1. `topic.delimiter`: topic 名称分割符，默认为 `-`。
|
||||
1. `read.method`: 从 TDengine 读取数据方式，query 或是 subscription。默认为 subscription。
|
||||
1. `subscription.group.id`: 指定 TDengine 数据订阅的组 id，当 `read.method` 为 subscription 时，此项为必填项。
|
||||
1. `subscription.from`: 指定 TDengine 数据订阅起始位置，latest 或是 earliest。默认为 latest。
|
||||
1. `connection.database`：源数据库名称，无缺省值。
|
||||
1. `topic.prefix`：数据导入 kafka 时使用的 topic 名称的前缀。默认为空字符串 ""。
|
||||
1. `timestamp.initial`：数据同步起始时间。格式为'yyyy-MM-dd HH:mm:ss'，若未指定则从指定 DB 中最早的一条记录开始。
|
||||
1. `poll.interval.ms`：检查是否有新建或删除的表的时间间隔，单位为 ms。默认为 1000。
|
||||
1. `fetch.max.rows`：检索数据库时最大检索条数。默认为 100。
|
||||
1. `query.interval.ms`：从 TDengine 一次读取数据的时间跨度，需要根据表中的数据特征合理配置，避免一次查询的数据量过大或过小；在具体的环境中建议通过测试设置一个较优值，默认值为 0，即获取到当前最新时间的所有数据。
|
||||
1. `out.format`：结果集输出格式。`line` 表示输出格式为 InfluxDB Line 协议格式，`json` 表示输出格式是 json。默认为 line。
|
||||
1. `topic.per.stable`：如果设置为 true，表示一个超级表对应一个 Kafka topic，topic的命名规则 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`；如果设置为 false，则指定的 DB 中的所有数据进入一个 Kafka topic，topic 的命名规则为 `<topic.prefix><topic.delimiter><connection.database>`
|
||||
1. `topic.ignore.db`：topic 命名规则是否包含 database 名称，true 表示规则为 `<topic.prefix><topic.delimiter><stable.name>`，false 表示规则为 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`，默认 false。此配置项在 `topic.per.stable` 设置为 false 时不生效。
|
||||
1. `topic.delimiter`：topic 名称分割符，默认为 `-`。
|
||||
1. `read.method`：从 TDengine 读取数据方式，query 或是 subscription。默认为 subscription。
|
||||
1. `subscription.group.id`：指定 TDengine 数据订阅的组 id，当 `read.method` 为 subscription 时，此项为必填项。
|
||||
1. `subscription.from`：指定 TDengine 数据订阅起始位置，latest 或是 earliest。默认为 latest。
|
||||
|
||||
## 其他说明
|
||||
|
||||
1. 关于如何在独立安装的 Kafka 环境使用 Kafka Connect 插件， 请参考官方文档：[https://kafka.apache.org/documentation/#connect](https://kafka.apache.org/documentation/#connect)。
|
||||
1. 关于如何在独立安装的 Kafka 环境使用 Kafka Connect 插件，请参考官方文档：[https://kafka.apache.org/documentation/#connect](https://kafka.apache.org/documentation/#connect)。
|
||||
|
||||
## 问题反馈
|
||||
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ Properties 中配置参数如下：
|
|||
- TDengineCdcParams.VALUE_DESERIALIZER：结果集反序列化方法，如果接收结果集类型是 `Flink` 的 `RowData`，仅需要设置为 `RowData`即可。可以继承 `com.taosdata.jdbc.tmq.ReferenceDeserializer`，并指定结果集 bean，实现反序列化。
|
||||
- TDengineCdcParams.TMQ_BATCH_MODE：此参数用于批量将数据推送给下游算子，如果设置为 True，创建 `TDengineCdcSource` 对象时需要指定数据类型为 `ConsumerRecords` 类型的泛型形式。
|
||||
- TDengineCdcParams.GROUP_ID：消费组 ID，同一消费组共享消费进度。最大长度：192。
|
||||
- TDengineCdcParams.AUTO_OFFSET_RESET： 消费组订阅的初始位置 （ `earliest` 从头开始订阅, `latest` 仅从最新数据开始订阅, 默认 `latest`）。
|
||||
- TDengineCdcParams.AUTO_OFFSET_RESET：消费组订阅的初始位置（ `earliest` 从头开始订阅, `latest` 仅从最新数据开始订阅, 默认 `latest`）。
|
||||
- TDengineCdcParams.ENABLE_AUTO_COMMIT：是否启用消费位点自动提交，true: 自动提交；false：依赖 `checkpoint` 时间来提交， 默认 false。
|
||||
> **注意**：自动提交模式reader获取完成数据后自动提交，不管下游算子是否正确的处理了数据，存在数据丢失的风险，主要用于为了追求高效的无状态算子场景或是数据一致性要求不高的场景。
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ Properties 中配置参数如下：
|
|||
- TDengineConfigParams.PROPERTY_KEY_RECONNECT_INTERVAL_MS：自动重连重试间隔，单位毫秒，默认值 2000。仅在 `PROPERTY_KEY_ENABLE_AUTO_RECONNECT` 为 true 时生效。
|
||||
- TDengineConfigParams.PROPERTY_KEY_RECONNECT_RETRY_COUNT：自动重连重试次数，默认值 3，仅在 `PROPERTY_KEY_ENABLE_AUTO_RECONNECT` 为 true 时生效。
|
||||
- TDengineCdcParams.TMQ_SESSION_TIMEOUT_MS：`consumer` 心跳丢失后超时时间，超时后会触发 `rebalance` 逻辑，成功后该 `consumer` 会被删除（从3.3.3.0版本开始支持）， 默认值为 12000，取值范围 [6000， 1800000]。
|
||||
- TDengineCdcParams.TMQ_MAX_POLL_INTERVAL_MS：`consumer poll` 拉取数据间隔的最长时间，超过该时间，会认为该 `consumer` 离线，触发 `rebalance` 逻辑，成功后该 `consumer` 会被删除。 默认值为 300000，[1000，INT32_MAX]。
|
||||
- TDengineCdcParams.TMQ_MAX_POLL_INTERVAL_MS：`consumer poll` 拉取数据间隔的最长时间，超过该时间，会认为该 `consumer` 离线，触发 `rebalance` 逻辑，成功后该 `consumer` 会被删除。默认值为 300000，[1000，INT32_MAX]。
|
||||
|
||||
#### 使用 CDC 连接器
|
||||
|
||||
|
|
@ -281,7 +281,7 @@ Properties 中配置参数如下：
|
|||
- TDengineConfigParams.VALUE_DESERIALIZER：接收结果集反序列化方法, 如果接收结果集类型是 `Flink` 的 `RowData`，仅需要设置为 `RowData`即可。也可继承 `TDengineSinkRecordSerializer` 并实现 `serialize` 方法，根据 接收的数据类型自定义反序列化方式。
|
||||
- TDengineConfigParams.TD_BATCH_SIZE：设置一次写入 `TDengine` 数据库的批大小 | 当到达批的数量后进行写入，或是一个checkpoint的时间也会触发写入数据库。
|
||||
- TDengineConfigParams.TD_BATCH_MODE：接收批量数据当设置为 True 时，如果数据来源是 `TDengine Source`，则使用 `SourceRecords` 泛型类型来创建 `TDengineSink` 对象；若来源是 `TDengine CDC`，则使用 `ConsumerRecords` 泛型来创建 `TDengineSink` 对象。
|
||||
- TDengineConfigParams.TD_SOURCE_TYPE：设置数据来源。 当数据来源是 `TDengine Source` 是设置为 'tdengine_source', 当来源是 `TDengine CDC` 设置为 'tdengine_cdc'。当配置 `TD_BATCH_MODE` 为 True 生效。
|
||||
- TDengineConfigParams.TD_SOURCE_TYPE：设置数据来源。当数据来源是 `TDengine Source` 是设置为 'tdengine_source', 当来源是 `TDengine CDC` 设置为 'tdengine_cdc'。当配置 `TD_BATCH_MODE` 为 True 生效。
|
||||
- TDengineConfigParams.PROPERTY_KEY_MESSAGE_WAIT_TIMEOUT: 消息超时时间, 单位 ms， 默认值为 60000。
|
||||
- TDengineConfigParams.PROPERTY_KEY_ENABLE_COMPRESSION: 传输过程是否启用压缩。true: 启用，false: 不启用。默认为 false。
|
||||
- TDengineConfigParams.PROPERTY_KEY_ENABLE_AUTO_RECONNECT: 是否启用自动重连。true: 启用，false: 不启用。默认为 false。
|
||||
|
|
@ -355,7 +355,7 @@ Properties 中配置参数如下：
|
|||
| bootstrap.servers| string | 服务器地址。|
|
||||
| topic | string | 订阅主题。||
|
||||
| td.jdbc.mode | strng | 连接器类型, cdc, sink。|
|
||||
| group.id| string| 消费组 ID，同一消费组共享消费进度。 |
|
||||
| group.id| string| 消费组 ID，同一消费组共享消费进度。|
|
||||
| auto.offset.reset| string| 消费组订阅的初始位置。<br/>`earliest`: 从头开始订阅 <br/> `latest`: 仅从最新数据开始订阅。<br/> 默认 `latest`。|
|
||||
| poll.interval_ms| integer| 拉取数据间隔, 默认 500ms。|
|
||||
| sink.db.name|string| 目标数据库名称。|
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ import TabItem from "@theme/TabItem";
|
|||
使用 Grafana 最新版本（8.5+），您可以在 Grafana 中[浏览和管理插件](https://grafana.com/docs/grafana/next/administration/plugin-management/#plugin-catalog)（对于 7.x 版本，请采用 **安装脚本** 或 **手动安装** 方式）。在 Grafana 管理界面中的 **Configurations > Plugins** 页面直接搜索 `TDengine` 并按照提示安装。
|
||||
|
||||
安装完毕后，按照指示 **Create a TDengine data source** 添加数据源，输入 TDengine 相关配置：
|
||||
- Host： TDengine 集群中提供 REST 服务的 IP 地址与端口号，默认 `http://localhost:6041`
|
||||
- Host：TDengine 集群中提供 REST 服务的 IP 地址与端口号，默认 `http://localhost:6041`
|
||||
- User：TDengine 用户名。
|
||||
- Password：TDengine 用户密码。
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ bash -c "$(curl -fsSL \
|
|||
</TabItem>
|
||||
<TabItem value="manual" label="手动安装">
|
||||
|
||||
使用 [`grafana-cli` 命令行工具](https://grafana.com/docs/grafana/latest/administration/cli/) 进行插件[安装](https://grafana.com/grafana/plugins/tdengine-datasource/?tab=installation)。
|
||||
使用 [`grafana-cli` 命令行工具](https://grafana.com/docs/grafana/latest/administration/cli/) 进行插件 [安装](https://grafana.com/grafana/plugins/tdengine-datasource/?tab=installation)。
|
||||
|
||||
```bash
|
||||
grafana-cli plugins install tdengine-datasource
|
||||
|
|
@ -92,7 +92,7 @@ GF_INSTALL_PLUGINS=tdengine-datasource
|
|||
|
||||
点击 `Add data source` 可进入新增数据源页面，在查询框中输入 TDengine， 然后点击 `select` 选择添加后会进入数据源配置页面，按照默认提示修改相应配置：
|
||||
|
||||
- Host： TDengine 集群中提供 REST 服务的 IP 地址与端口号，默认 `http://localhost:6041`
|
||||
- Host：TDengine 集群中提供 REST 服务的 IP 地址与端口号，默认 `http://localhost:6041`
|
||||
- User：TDengine 用户名。
|
||||
- Password：TDengine 用户密码。
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ TDengine 在支持标准 SQL 的基础之上，还提供了一系列满足时序
|
|||
- `partition by` 子句可以按一定的维度对数据进行切分，然后在切分出的数据空间内再进行一系列的计算。绝大多数情况可以替代 `group by`。
|
||||
- `interval` 子句用于产生相等时间周期的窗口
|
||||
- `fill` 语句指定某一窗口区间数据缺失的情况下的填充模式
|
||||
- `时间戳伪列` 如果需要在结果中输出聚合结果所对应的时间窗口信息，需要在 SELECT 子句中使用时间戳相关的伪列： 时间窗口起始时间 (_wstart), 时间窗口结束时间 (_wend) 等
|
||||
- `时间戳伪列` 如果需要在结果中输出聚合结果所对应的时间窗口信息，需要在 SELECT 子句中使用时间戳相关的伪列：时间窗口起始时间 (_wstart), 时间窗口结束时间 (_wend) 等
|
||||
|
||||
上述特性详细介绍可以参考 [特色查询](../../../reference/taos-sql/distinguished/)。
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ TDengine 在支持标准 SQL 的基础之上，还提供了一系列满足时序
|
|||
假设我们想查询一段时间内的平均电流大小，时间窗口按 `$interval` 切分，若某一时间窗口区间数据缺失，填充 null。
|
||||
- “INPUT SQL”：输入要查询的语句（该 SQL 语句的结果集应为两列多行），此处输入：`select _wstart as ts, avg(current) as current from power.meters where groupid in ($selected_groups) and ts > $from and ts < $to interval($interval) fill(null)` ，其中，from、to 和 interval 为 Grafana 内置变量，selected_groups 为自定义变量。
|
||||
- “ALIAS BY”：可设置当前查询别名。
|
||||
- “GENERATE SQL”： 点击该按钮会自动替换相应变量，并生成最终执行的语句。
|
||||
- “GENERATE SQL”：点击该按钮会自动替换相应变量，并生成最终执行的语句。
|
||||
|
||||
在顶部的自定义变量中，若选择 `selected_groups` 的值为 1，则查询 `meters` 超级表中 `groupid` 为 1 的所有设备电流平均值变化如下图：
|
||||
|
||||
|
|
@ -282,8 +282,8 @@ TDengine 在支持标准 SQL 的基础之上，还提供了一系列满足时序
|
|||
|
||||
假设我们想查询一段时间内的平均电流大小，按 `groupid` 分组展示，我们可以修改之前的 SQL 为 `select _wstart as ts, groupid, avg(current) as current from power.meters where ts > $from and ts < $to partition by groupid interval($interval) fill(null)`
|
||||
|
||||
- “Group by column(s)”： **半角**逗号分隔的 `group by` 或 `partition by` 列名。如果是 `group by` 或 `partition by` 查询语句，设置 “Group by” 列，可以展示多维数据。此处设置 “Group by” 列名为 `groupid`，可以按 `groupid` 分组展示数据。
|
||||
- “Group By Format”： `Group by` 或 `Partition by` 场景下多维数据 legend 格式化格式。例如上述 INPUT SQL，将 “Group By Format” 设置为 `groupid-{{groupid}}`，展示的 legend 名字为格式化的分组名。
|
||||
- “Group by column(s)”：**半角**逗号分隔的 `group by` 或 `partition by` 列名。如果是 `group by` 或 `partition by` 查询语句，设置 “Group by” 列，可以展示多维数据。此处设置 “Group by” 列名为 `groupid`，可以按 `groupid` 分组展示数据。
|
||||
- “Group By Format”：`Group by` 或 `Partition by` 场景下多维数据 legend 格式化格式。例如上述 INPUT SQL，将 “Group By Format” 设置为 `groupid-{{groupid}}`，展示的 legend 名字为格式化的分组名。
|
||||
|
||||
完成设置后，按照 `groupid` 分组展示如下图：
|
||||
|
||||
|
|
@ -306,10 +306,10 @@ TDengine 在支持标准 SQL 的基础之上，还提供了一系列满足时序
|
|||
|
||||
使用 TDengine 作为数据源的其他面板，可以[在此搜索](https://grafana.com/grafana/dashboards/?dataSource=tdengine-datasource)。以下是一份不完全列表：
|
||||
|
||||
- [15146](https://grafana.com/grafana/dashboards/15146)： 监控多个 TDengine 集群
|
||||
- [15155](https://grafana.com/grafana/dashboards/15155)： TDengine 告警示例
|
||||
- [15167](https://grafana.com/grafana/dashboards/15167)： TDinsight
|
||||
- [16388](https://grafana.com/grafana/dashboards/16388)： Telegraf 采集节点信息的数据展示
|
||||
- [15146](https://grafana.com/grafana/dashboards/15146)：监控多个 TDengine 集群
|
||||
- [15155](https://grafana.com/grafana/dashboards/15155)：TDengine 告警示例
|
||||
- [15167](https://grafana.com/grafana/dashboards/15167)：TDinsight
|
||||
- [16388](https://grafana.com/grafana/dashboards/16388)：Telegraf 采集节点信息的数据展示
|
||||
|
||||
## 告警配置
|
||||
|
||||
|
|
@ -357,7 +357,7 @@ from_address = sender@foxmail.com
|
|||
然后重启 Grafana 服务（以 Linux 系统为例，执行 `systemctl restart grafana-server.service`）即可添加完成
|
||||
|
||||
在 Grafana 页面找到 “Home” -> “Alerting” -> “Contact points”，创建新联络点
|
||||
“Name”： Email Contact Point
|
||||
“Name”：Email Contact Point
|
||||
“Integration”：选择联络类型，这里选择 Email，填写邮件接收地址，完成后保存联络点
|
||||
|
||||
|
||||
|
|
@ -389,9 +389,9 @@ from_address = sender@foxmail.com
|
|||
|
||||
|
||||
然后配置下列参数：
|
||||
- “Group wait”： 发送首次告警之前的等待时间。
|
||||
- “Group interval”： 发送第一个告警后，为该组发送下一批新告警的等待时间。
|
||||
- “Repeat interval”： 成功发送告警后再次重复发送告警的等待时间。
|
||||
- “Group wait”：发送首次告警之前的等待时间。
|
||||
- “Group interval”：发送第一个告警后，为该组发送下一批新告警的等待时间。
|
||||
- “Repeat interval”：成功发送告警后再次重复发送告警的等待时间。
|
||||
|
||||
### 配置告警规则
|
||||
|
||||
|
|
|
|||
|
|
@ -3,26 +3,29 @@ sidebar_label: Looker
|
|||
title: 与 Looker Studio 的集成
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
Looker Studio，作为Google旗下的一个功能强大的报表和商业智能工具，前身名为Google Data Studio。在2022年的Google Cloud Next大会上，Google将其更名为Looker Studio。这个工具凭借其丰富的数据可视化选项和多样化的数据连接能力，为用户提供了便捷的数据报表生成体验。用户可以根据预设的模板轻松创建数据报表，满足各种数据分析需求。
|
||||
Looker Studio，作为 Google 旗下的一个功能强大的报表和商业智能工具，前身名为 Google Data Studio。在 2022 年的 Google Cloud Next 大会上，Google 将其更名为 Looker Studio。这个工具凭借其丰富的数据可视化选项和多样化的数据连接能力，为用户提供了便捷的数据报表生成体验。用户可以根据预设的模板轻松创建数据报表，满足各种数据分析需求。
|
||||
|
||||
由于其简单易用的操作界面和庞大的生态系统支持，Looker Studio在数据分析领域受到众多数据科学家和专业人士的青睐。无论是初学者还是资深分析师，都可以利用Looker Studio快速构建美观且实用的数据报表，从而更好地洞察业务趋势、优化决策过程并提升整体运营效率。
|
||||
由于其简单易用的操作界面和庞大的生态系统支持，Looker Studio 在数据分析领域受到众多数据科学家和专业人士的青睐。无论是初学者还是资深分析师，都可以利用 Looker Studio 快速构建美观且实用的数据报表，从而更好地洞察业务趋势、优化决策过程并提升整体运营效率。
|
||||
|
||||
## 获取
|
||||
|
||||
目前，TDengine连接器作为Looker Studio的合作伙伴连接器（partner connector），已在Looker Studio官网上线。用户访问Looker Studio的Data Source列表时，只须输入 “TDengine”进行搜索，便可轻松找到并立即使用TDengine连接器。
|
||||
目前，TDengine 连接器作为 Looker Studio 的合作伙伴连接器（partner connector），已在 Looker Studio 官网上线。用户访问 Looker Studio 的 Data Source 列表时，只须输入 “TDengine” 进行搜索，便可轻松找到并立即使用 TDengine 连接器。
|
||||
|
||||
TDengine连接器兼容TDengine Cloud和TDengine Server两种类型的数据源。TDengine Cloud是涛思数据推出的全托管物联网和工业互联网大数据云服务平台，为用户提供一站式数据存储、处理和分析解决方案；而TDengine Server则是用户自行部署的本地版本，支持通过公网访问。以下内容将以TDengine Cloud为例进行介绍。
|
||||
TDengine 连接器兼容 TDengine Cloud 和 TDengine Server 两种类型的数据源。TDengine Cloud 是涛思数据推出的全托管物联网和工业互联网大数据云服务平台，为用户提供一站式数据存储、处理和分析解决方案；而 TDengine Server 则是用户自行部署的本地版本，支持通过公网访问。以下内容将以 TDengine Cloud 为例进行介绍。
|
||||
|
||||
## 使用
|
||||
|
||||
在Looker Studio中使用TDengine连接器的步骤如下。
|
||||
在Looker Studio中使用 TDengine 连接器的步骤如下。
|
||||
|
||||
第1步，进入TDengine连接器的详情页面后，在Data Source下拉列表中选择TDengine Cloud，然后点击Next按钮，即可进入数据源配置页面。在该页面中填写以下信息，然后点击Connect按钮。
|
||||
- URL和TDengine Cloud Token，可以从TDengine Cloud的实例列表中获取。
|
||||
第 1 步，进入TDengine连接器的详情页面后，在 Data Source 下拉列表中选择 TDengine Cloud，然后点击 Next 按钮，即可进入数据源配置页面。在该页面中填写以下信息，然后点击 Connect 按钮。
|
||||
- URL 和 TDengine Cloud Token，可以从 TDengine Cloud 的实例列表中获取。
|
||||
- 数据库名称和超级表名称。
|
||||
- 查询数据的开始时间和结束时间。
|
||||
第2步，Looker Studio会根据配置自动加载所配置的TDengine数据库下的超级表的字段和标签。
|
||||
第3步，点击页面右上角的Explore按钮，即查看从TDengine数据库中加载的数据。
|
||||
第4步，根据需求，利用Looker Studio提供的图表，进行数据可视化的配置。
|
||||
|
||||
**注意** 在第一次使用时，请根据页面提示，对Looker Studio的TDengine连接器进行访问授权。
|
||||
第 2 步，Looker Studio 会根据配置自动加载所配置的 TDengine 数据库下的超级表的字段和标签。
|
||||
|
||||
第 3 步，点击页面右上角的 Explore 按钮，即查看从 TDengine 数据库中加载的数据。
|
||||
|
||||
第 4 步，根据需求，利用 Looker Studio 提供的图表，进行数据可视化的配置。
|
||||
|
||||
**注意** 在第一次使用时，请根据页面提示，对 Looker Studio 的 TDengine 连接器进行访问授权。
|
||||
|
|
@ -29,8 +29,8 @@ Power BI 是由 Microsoft 提供的一种商业分析工具。通过配置使用
|
|||
### 使用说明
|
||||
|
||||
为了充分发挥 Power BI 在分析 TDengine中 数据方面的优势，用户需要先理解维度、度量、窗口切分查询、数据切分查询、时序和相关性等核心概念，之后通过自定义的 SQL 导入数据。
|
||||
- 维度：通常是分类（文本）数据，描述设备、测点、型号等类别信息。在 TDengine 的超级表中，使用标签列存储数据的维度信息，可以通过形如 “select distinct tbname, tag1, tag2 from supertable” 的SQL语法快速获得维度信息。
|
||||
- 度量：可以用于进行计算的定量（数值）字段，常见计算有求和、取平均值和最小值等。如果测点的采集周期为1s，那么一年就有 3000 多万条记录，把这些数据全部导入 Power BI 会严重影响其执行效率。在 TDengine 中，用户可以使用数据切分查询、窗口切分查询等语法，结合与窗口相关的伪列，把降采样后的数据导入Power BI 中，具体语法请参阅 TDengine 官方文档的特色查询功能部分。
|
||||
- 维度：通常是分类（文本）数据，描述设备、测点、型号等类别信息。在 TDengine 的超级表中，使用标签列存储数据的维度信息，可以通过形如 `select distinct tbname, tag1, tag2 from supertable` 的 SQL 语法快速获得维度信息。
|
||||
- 度量：可以用于进行计算的定量（数值）字段，常见计算有求和、取平均值和最小值等。如果测点的采集周期为 1s，那么一年就有 3000 多万条记录，把这些数据全部导入 Power BI 会严重影响其执行效率。在 TDengine 中，用户可以使用数据切分查询、窗口切分查询等语法，结合与窗口相关的伪列，把降采样后的数据导入 Power BI 中，具体语法请参阅 TDengine 官方文档的特色查询功能部分。
|
||||
- 窗口切分查询：比如温度传感器每秒采集一次数据，但须查询每隔 10min 的温度平均值，在这种场景下可以使用窗口子句来获得需要的降采样查询结果，对应的 SQL 形如 `select tbname, _wstart date，avg(temperature) temp from table interval(10m)`，其中，`_wstart` 是伪列，表示时间窗口起始时间，10m 表示时间窗口的持续时间，`avg(temperature)` 表示时间窗口内的聚合值。
|
||||
- 数据切分查询：如果需要同时获取很多温度传感器的聚合数值，可对数据进行切分，然后在切分出的数据空间内进行一系列的计算，对应的 SQL 形如 `partition by part_list`。数据切分子句最常见的用法是在超级表查询中按标签将子表数据进行切分，将每个子表的数据独立出来，形成一条条独立的时间序列，方便针对各种时序场景的统计分析。
|
||||
- 时序：在绘制曲线或者按照时间聚合数据时，通常需要引入日期表。日期表可以从 Excel 表格中导入，也可以在 TDengine 中执行 SQL 获取，例如 `select _wstart date, count(*) cnt from test.meters where ts between A and B interval(1d) fill(0)`，其中 fill 字句表示数据缺失情况下的填充模式，伪列 _wstart 则为要获取的日期列。
|
||||
|
|
@ -46,7 +46,7 @@ TDengine 采用了一种独特的数据模型，以优化时序数据的存储
|
|||
|
||||
根据如下步骤，便可以体验通过 Power BI 生成时序数据报表的功能。
|
||||
|
||||
**第 1 步**，使用 TDengine 的 taosBenchMark 快速生成1000块智能电表3天的数据，采集频率为 1s。
|
||||
**第 1 步**，使用 TDengine 的 taosBenchMark 快速生成 1000 块智能电表 3 天的数据，采集频率为 1s。
|
||||
|
||||
```shell
|
||||
taosBenchmark -t 1000 -n 259200 -S 1000 -y
|
||||
|
|
@ -76,4 +76,4 @@ select _wstart date, count(*) from test.meters interval(1d) having count(*)>0
|
|||
|
||||
**第 7 步**，制作报告。在柱状图、饼图等控件中使用这些数据。
|
||||
|
||||
由于TDengine处理时序数据的超强性能，使得用户在数据导入及每日定期刷新数据时，都可以得到非常好的体验。更多有关 Power BI 视觉效果的构建方法，请参照 Power BI 的官方文档。
|
||||
由于 TDengine 处理时序数据的超强性能，使得用户在数据导入及每日定期刷新数据时，都可以得到非常好的体验。更多有关 Power BI 视觉效果的构建方法，请参照 Power BI 的官方文档。
|
||||
|
|
@ -10,17 +10,16 @@ qStudio 是一款免费的多平台 SQL 数据分析工具，可以轻松浏览
|
|||
|
||||
使用 qStudio 连接 TDengine 需要以下几方面的准备工作。
|
||||
|
||||
- 安装 qStudio。qStudio 支持主流操作系统包括 Windows、macOS 和 Linux。请注意[下载](https://www.timestored.com/qstudio/download/)正确平台的安装包。
|
||||
- 安装 qStudio。qStudio 支持主流操作系统包括 Windows、macOS 和 Linux。请注意 [下载](https://www.timestored.com/qstudio/download/) 正确平台的安装包。
|
||||
- 安装 TDengine 实例，请确认 TDengine 正常运行，并且 taosAdapter 已经安装并正常运行，具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)。
|
||||
|
||||
## 使用 qStudio 连接 TDengine
|
||||
|
||||
1. 启动 qStudio 应用，从菜单项选择“Server” 和 “Add Server...”，然后在 Server Type 下拉框中选择 TDengine。
|
||||
1. 启动 qStudio 应用，从菜单项选择 “Server” 和 “Add Server...”，然后在 Server Type 下拉框中选择 TDengine。
|
||||
|
||||
|
||||
|
||||
2. 配置 TDengine 连接，填入主机地址、端口号、用户名和密码。如果 TDengine 部署在本机，可以只填用户名和密码，默认用户名为 root，默认密码为 taosdata。点击“Test”可以对连接是否可用进行测试。如果本机没有安装 TDengine Java
|
||||
连接器，qStudio 会提示下载安装。
|
||||
2. 配置 TDengine 连接，填入主机地址、端口号、用户名和密码。如果 TDengine 部署在本机，可以只填用户名和密码，默认用户名为 root，默认密码为 taosdata。点击 “Test” 可以对连接是否可用进行测试。如果本机没有安装 TDengine Java 连接器，qStudio 会提示下载安装。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -87,14 +87,14 @@ TDengine 为了解决实际应用中对不同数据采集点数据进行高效
|
|||
|
||||
|
||||
具体步骤说明如下。
|
||||
第 1 步，taosc 从 mnode 获取库和表的元数据信息。
|
||||
第 2 步，mnode 返回请求的元数据信息。
|
||||
第 3 步，taosc 向超级表所属的每个 vnode 发送查询请求。
|
||||
第 4 步，vnode 启动本地查询，在获得查询结果后返回查询响应。
|
||||
第 5 步，taosc 向聚合节点（在本例中为 qnode）发送查询请求。
|
||||
第 6 步，qnode 向每个 vnode 节点发送数据请求消息来拉取数据。
|
||||
第 7 步，vnode 返回本节点的查询计算结果。
|
||||
第 8 步，qnode 完成多节点数据聚合后将最终查询结果返回给客户端。
|
||||
- 第 1 步，taosc 从 mnode 获取库和表的元数据信息。
|
||||
- 第 2 步，mnode 返回请求的元数据信息。
|
||||
- 第 3 步，taosc 向超级表所属的每个 vnode 发送查询请求。
|
||||
- 第 4 步，vnode 启动本地查询，在获得查询结果后返回查询响应。
|
||||
- 第 5 步，taosc 向聚合节点（在本例中为 qnode）发送查询请求。
|
||||
- 第 6 步，qnode 向每个 vnode 节点发送数据请求消息来拉取数据。
|
||||
- 第 7 步，vnode 返回本节点的查询计算结果。
|
||||
- 第 8 步，qnode 完成多节点数据聚合后将最终查询结果返回给客户端。
|
||||
|
||||
TDengine 为了提升聚合计算速度，在 vnode 内实现了标签数据与时序数据的分离存储。首先，系统会在内存中过滤标签数据，以确定需要参与聚合操作的表的集合。这样做可以显著减少需要扫描的数据集，从而大幅提高聚合计算的速度。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue