docs: minor changes
This commit is contained in:
Simon Guan
parent
0175488136
commit
10ca97b6cf
|
|
@ -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 会频繁重启，始终无法恢复到正常状态。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue