Merge pull request #29838 from taosdata/merge/mainto3.03
merge: from main to 3.0 branch
This commit is contained in:
Shengliang Guan
GitHub
commit
26bc7b6081
|
|
@ -304,7 +304,7 @@ Not supported
|
|||
|
||||
## Querying the Written Data
|
||||
|
||||
By running the example code from the previous section, tables will be automatically created in the power database. We can query the data using taos shell or an application. Below is an example of querying the data from the supertable and meters table using taos shell.
|
||||
By running the example code from the previous section, tables will be automatically created in the power database. We can query the data using TDengine CLI or an application. Below is an example of querying the data from the supertable and meters table using TDengine CLI.
|
||||
|
||||
```shell
|
||||
taos> show power.stables;
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ TDengine provides data subscription and consumption interfaces similar to those
|
|||
|
||||
## Creating Topics
|
||||
|
||||
Please use taos shell or refer to the [Execute SQL](../running-sql-statements/) section to execute the SQL for creating topics: `CREATE TOPIC IF NOT EXISTS topic_meters AS SELECT ts, current, voltage, phase, groupid, location FROM meters`
|
||||
Please use TDengine CLI or refer to the [Execute SQL](../running-sql-statements/) section to execute the SQL for creating topics: `CREATE TOPIC IF NOT EXISTS topic_meters AS SELECT ts, current, voltage, phase, groupid, location FROM meters`
|
||||
|
||||
The above SQL will create a subscription named topic_meters. Each record in the messages obtained using this subscription is composed of the columns selected by this query statement `SELECT ts, current, voltage, phase, groupid, location FROM meters`.
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Additionally, to accelerate the data processing process, TDengine specifically s
|
|||
|
||||
```text
|
||||
Users can use the performance testing tool taosBenchmark to assess the data compression effect of TDengine. By using the -f option to specify the write configuration file, taosBenchmark can write a specified number of CSV sample data into the specified database parameters and table structure.
|
||||
After completing the data writing, users can execute the flush database command in the taos shell to force all data to be written to the disk. Then, use the du command of the Linux operating system to get the size of the data folder of the specified vnode. Finally, divide the original data size by the actual storage data size to calculate the real compression ratio.
|
||||
After completing the data writing, users can execute the flush database command in the TDengine CLI to force all data to be written to the disk. Then, use the du command of the Linux operating system to get the size of the data folder of the specified vnode. Finally, divide the original data size by the actual storage data size to calculate the real compression ratio.
|
||||
```
|
||||
|
||||
The following command can be used to obtain the storage space occupied by TDengine.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ For dnodes wishing to join the cluster, it is essential to ensure that the param
|
|||
|
||||
### 5. Start
|
||||
|
||||
Start the first dnode, such as `h1.tdengine.com`, following the steps mentioned above. Then execute taos in the terminal to start TDengine's CLI program taos, and execute the `show dnodes` command within it to view all dnode information in the current cluster.
|
||||
Start the first dnode, such as `h1.tdengine.com`, following the steps mentioned above. Then execute taos in the terminal to start TDengine CLI program taos, and execute the `show dnodes` command within it to view all dnode information in the current cluster.
|
||||
|
||||
```shell
|
||||
taos> show dnodes;
|
||||
|
|
@ -68,7 +68,7 @@ You can see that the endpoint of the dnode node that has just started is `h1.tde
|
|||
|
||||
### 6. Adding dnode
|
||||
|
||||
Follow the steps mentioned earlier, start taosd on each physical node. Each dnode needs to configure the firstEp parameter in the taos.cfg file to the endpoint of the first node of the new cluster, which in this case is `h1.tdengine.com:6030`. On the machine where the first dnode is located, run taos in the terminal, open TDengine's CLI program taos, then log into the TDengine cluster, and execute the following SQL.
|
||||
Follow the steps mentioned earlier, start taosd on each physical node. Each dnode needs to configure the firstEp parameter in the taos.cfg file to the endpoint of the first node of the new cluster, which in this case is `h1.tdengine.com:6030`. On the machine where the first dnode is located, run taos in the terminal, open TDengine CLI program taos, then log into the TDengine cluster, and execute the following SQL.
|
||||
|
||||
```shell
|
||||
create dnode "h2.tdengine.com:6030"
|
||||
|
|
@ -84,13 +84,13 @@ In the logs, please confirm that the fqdn and port of the output dnode are consi
|
|||
|
||||
**Tips**
|
||||
|
||||
- Any dnode that has joined the cluster can serve as the firstEp for subsequent nodes to be added. The firstEp parameter only functions when that dnode first joins the cluster. After joining, the dnode will save the latest mnode's endpoint list, and subsequently, it no longer depends on this parameter. The firstEp parameter in the configuration file is mainly used for client connections, and if no parameters are set for TDengine's CLI, it will default to connecting to the node specified by firstEp.
|
||||
- Any dnode that has joined the cluster can serve as the firstEp for subsequent nodes to be added. The firstEp parameter only functions when that dnode first joins the cluster. After joining, the dnode will save the latest mnode's endpoint list, and subsequently, it no longer depends on this parameter. The firstEp parameter in the configuration file is mainly used for client connections, and if no parameters are set for TDengine CLI, it will default to connecting to the node specified by firstEp.
|
||||
- Two dnodes that have not configured the firstEp parameter will run independently after starting. At this time, it is not possible to join one dnode to another to form a cluster.
|
||||
- TDengine does not allow merging two independent clusters into a new cluster.
|
||||
|
||||
### 7. Adding mnode
|
||||
|
||||
When creating a TDengine cluster, the first dnode automatically becomes the mnode of the cluster, responsible for managing and coordinating the cluster. To achieve high availability of mnode, subsequent dnodes need to manually create mnode. Please note that a cluster can create up to 3 mnodes, and only one mnode can be created on each dnode. When the number of dnodes in the cluster reaches or exceeds 3, you can create mnode for the existing cluster. In the first dnode, first log into TDengine through the CLI program taos, then execute the following SQL.
|
||||
When creating a TDengine cluster, the first dnode automatically becomes the mnode of the cluster, responsible for managing and coordinating the cluster. To achieve high availability of mnode, subsequent dnodes need to manually create mnode. Please note that a cluster can create up to 3 mnodes, and only one mnode can be created on each dnode. When the number of dnodes in the cluster reaches or exceeds 3, you can create mnode for the existing cluster. In the first dnode, first log into TDengine through TDengine CLI program taos, then execute the following SQL.
|
||||
|
||||
```shell
|
||||
create mnode on dnode <dnodeId>
|
||||
|
|
|
|||
|
|
@ -456,7 +456,7 @@ export POD_NAME=$(kubectl get pods --namespace default \
|
|||
|
||||
kubectl --namespace default exec $POD_NAME -- taos -s "show dnodes; show mnodes"
|
||||
|
||||
3. Run into taos shell:
|
||||
3. Run into TDengine CLI:
|
||||
|
||||
kubectl --namespace default exec -it $POD_NAME -- taos
|
||||
```
|
||||
|
|
|
|||
|
|
@ -6,6 +6,9 @@ slug: /tdengine-reference/tools/tdengine-cli
|
|||
|
||||
The TDengine command line program (hereinafter referred to as TDengine CLI) is the simplest and most commonly used tool for users to operate and interact with TDengine instances. It requires the installation of either the TDengine Server package or the TDengine Client package before use.
|
||||
|
||||
## Get
|
||||
TDengine CLI is the default installation component in the TDengine server and client installation package. It can be used after installation, refer to [TDengine Installation](../../../get-started/)
|
||||
|
||||
## Startup
|
||||
|
||||
To enter the TDengine CLI, simply execute `taos` in the terminal.
|
||||
|
|
@ -29,15 +32,83 @@ To exit the TDengine CLI, execute `q`, `quit`, or `exit` and press enter.
|
|||
taos> quit
|
||||
```
|
||||
|
||||
## Command Line Parameters
|
||||
|
||||
### Basic Parameters
|
||||
|
||||
You can change the behavior of the TDengine CLI by configuring command line parameters. Below are some commonly used command line parameters:
|
||||
|
||||
- -h HOST: The FQDN of the server where the TDengine service is located, default is to connect to the local service.
|
||||
- -P PORT: Specifies the port number used by the server.
|
||||
- -u USER: Username to use when connecting.
|
||||
- -p PASSWORD: Password to use when connecting to the server.
|
||||
- -?, --help: Prints out all command line parameters.
|
||||
- -s COMMAND: SQL command executed in non-interactive mode.
|
||||
Use the `-s` parameter to execute SQL non interactively, and exit after execution. This mode is suitable for use in automated scripts.
|
||||
For example, connect to the server h1.taos.com with the following command, and execute the SQL specified by `-s`:
|
||||
```bash
|
||||
taos -h my-server -s "use db; show tables;"
|
||||
```
|
||||
|
||||
- -c CONFIGDIR: Specify the configuration file directory.
|
||||
In Linux, the default is `/etc/tao`. The default name of the configuration file in this directory is `taos.cfg`.
|
||||
Use the `-c` parameter to change the location where the `taosc` client loads the configuration file. For client configuration parameters, refer to [Client Configuration](../../components/taosc).
|
||||
The following command specifies the `taos.cfg` configuration file under `/root/cfg/` loaded by the `taosc` client.
|
||||
|
||||
```bash
|
||||
taos -c /root/cfg/
|
||||
```
|
||||
|
||||
### Advanced Parameters
|
||||
|
||||
- -a AUTHSTR: Authorization information for connecting to the server.
|
||||
- -A: Calculate authorization information using username and password.
|
||||
- -B: Set BI tool display mode, after setting, all outputs follow the format of BI tools.
|
||||
- -C: Print the configuration parameters of `taos.cfg` in the directory specified by -c.
|
||||
- -d DATABASE: Specifies the database to use when connecting to the server.
|
||||
- -E dsn: Connect to cloud services or servers providing WebSocket connections using WebSocket DSN.
|
||||
- -f FILE: Execute SQL script file in non-interactive mode. Each SQL statement in the file must occupy one line.
|
||||
- -k: Test the running status of the server, 0: unavailable, 1: network ok, 2: service ok, 3: service degraded, 4: exiting.
|
||||
- -l PKTLEN: Test packet size used during network testing.
|
||||
- -n NETROLE: Test range during network connection testing, default is `client`, options are `client`, `server`.
|
||||
- -N PKTNUM: Number of test packets used during network testing.
|
||||
- -r: Convert time columns to unsigned 64-bit integer type output (i.e., uint64_t in C language).
|
||||
- -R: Connect to the server using RESTful mode.
|
||||
- -t: Test the startup status of the server, status same as -k.
|
||||
- -w DISPLAYWIDTH: Client column display width.
|
||||
- -z TIMEZONE: Specifies the timezone, default is the local timezone.
|
||||
- -V: Print the current version number.
|
||||
|
||||
## Data Export/Import
|
||||
|
||||
### Data Export To a File
|
||||
|
||||
- You can use the symbol “>>” to export query results to a file, the syntax is: sql query statement >> 'output file name'; If no path is written for the output file, it will be output to the current directory. For example, `select * from d0 >> '/root/d0.csv';` will output the query results to /root/d0.csv.
|
||||
|
||||
### Data Import From a File
|
||||
|
||||
- You can use insert into table_name file 'input file name', to import the data file exported in the previous step back into the specified table. For example, `insert into d0 file '/root/d0.csv';` means to import all the data exported above back into the d0 table.
|
||||
|
||||
|
||||
## Execute SQL Scripts
|
||||
|
||||
In the TDengine CLI, you can run multiple SQL commands from a script file using the `source` command.
|
||||
In the TDengine CLI, you can run multiple SQL commands from a script file using the `source` command, multiple SQL statements in the script file can be written in line.
|
||||
|
||||
```sql
|
||||
taos> source <filename>;
|
||||
```
|
||||
|
||||
## Online Modification of Display Character Width
|
||||
## TDengine CLI Tips
|
||||
|
||||
### TAB Key Completion
|
||||
|
||||
- Pressing the TAB key when no command is present will list all commands supported by TDengine CLI.
|
||||
- Pressing the TAB key when preceded by a space will display the first of all possible command words at this position, pressing TAB again will switch to the next one.
|
||||
- If a string precedes the TAB key, it will search for all command words that match the prefix of this string and display the first one, pressing TAB again will switch to the next one.
|
||||
- Entering a backslash `\` + TAB key, will automatically complete to the column display mode command word `\G;`.
|
||||
|
||||
|
||||
### Modification of Display Character Width
|
||||
|
||||
You can adjust the display character width in the TDengine CLI using the following command:
|
||||
|
||||
|
|
@ -47,71 +118,16 @@ taos> SET MAX_BINARY_DISPLAY_WIDTH <nn>;
|
|||
|
||||
If the displayed content ends with ..., it indicates that the content has been truncated. You can modify the display character width with this command to display the full content.
|
||||
|
||||
## Command Line Parameters
|
||||
### Other
|
||||
|
||||
You can change the behavior of the TDengine CLI by configuring command line parameters. Below are some commonly used command line parameters:
|
||||
- You can use the up and down arrow keys to view previously entered commands.
|
||||
- In TDengine CLI, use the `alter user` command to change user passwords, the default password is `taosdata`.
|
||||
- Ctrl+C to stop a query that is in progress.
|
||||
- Execute `RESET QUERY CACHE` to clear the cache of the local table Schema.
|
||||
- Batch execute SQL statements.
|
||||
You can store a series of TDengine CLI commands (ending with a semicolon `;`, each SQL statement on a new line) in a file, and execute the command `source <file-name>` in TDengine CLI to automatically execute all SQL statements in that file.
|
||||
|
||||
- -h HOST: The FQDN of the server where the TDengine service is located, default is to connect to the local service
|
||||
- -P PORT: Specifies the port number used by the server
|
||||
- -u USER: Username to use when connecting
|
||||
- -p PASSWORD: Password to use when connecting to the server
|
||||
- -?, --help: Prints out all command line parameters
|
||||
|
||||
There are many other parameters:
|
||||
|
||||
- -a AUTHSTR: Authorization information for connecting to the server
|
||||
- -A: Calculate authorization information using username and password
|
||||
- -B: Set BI tool display mode, after setting, all outputs follow the format of BI tools
|
||||
- -c CONFIGDIR: Specify the configuration file directory, default in Linux environment is `/etc/taos`, the default name of the configuration file in this directory is `taos.cfg`
|
||||
- -C: Print the configuration parameters of `taos.cfg` in the directory specified by -c
|
||||
- -d DATABASE: Specifies the database to use when connecting to the server
|
||||
- -E dsn: Connect to cloud services or servers providing WebSocket connections using WebSocket DSN
|
||||
- -f FILE: Execute SQL script file in non-interactive mode. Each SQL statement in the file must occupy one line
|
||||
- -k: Test the running status of the server, 0: unavailable, 1: network ok, 2: service ok, 3: service degraded, 4: exiting
|
||||
- -l PKTLEN: Test packet size used during network testing
|
||||
- -n NETROLE: Test range during network connection testing, default is `client`, options are `client`, `server`
|
||||
- -N PKTNUM: Number of test packets used during network testing
|
||||
- -r: Convert time columns to unsigned 64-bit integer type output (i.e., uint64_t in C language)
|
||||
- -R: Connect to the server using RESTful mode
|
||||
- -s COMMAND: SQL command executed in non-interactive mode
|
||||
- -t: Test the startup status of the server, status same as -k
|
||||
- -w DISPLAYWIDTH: Client column display width
|
||||
- -z TIMEZONE: Specifies the timezone, default is the local timezone
|
||||
- -V: Print the current version number
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
taos -h h1.taos.com -s "use db; show tables;"
|
||||
```
|
||||
|
||||
## Configuration File
|
||||
|
||||
You can also control the behavior of the TDengine CLI through parameters set in the configuration file. For available configuration parameters, please refer to [Client Configuration](../../components/taosc)
|
||||
|
||||
## Error Code Table
|
||||
|
||||
Starting from TDengine version 3.3.4.8, TDengine CLI returns specific error codes in error messages. Users can visit the TDengine official website's error code page to find specific reasons and solutions, see: [Error Code Reference](../../error-codes/)
|
||||
|
||||
## TDengine CLI TAB Key Completion
|
||||
|
||||
- Pressing the TAB key when no command is present will list all commands supported by TDengine CLI
|
||||
- Pressing the TAB key when preceded by a space will display the first of all possible command words at this position, pressing TAB again will switch to the next one
|
||||
- If a string precedes the TAB key, it will search for all command words that match the prefix of this string and display the first one, pressing TAB again will switch to the next one
|
||||
- Entering a backslash `\` + TAB key, will automatically complete to the column display mode command word `\G;`
|
||||
|
||||
## TDengine CLI Tips
|
||||
|
||||
- You can use the up and down arrow keys to view previously entered commands
|
||||
- In TDengine CLI, use the `alter user` command to change user passwords, the default password is `taosdata`
|
||||
- Ctrl+C to stop a query that is in progress
|
||||
- Execute `RESET QUERY CACHE` to clear the cache of the local table Schema
|
||||
- Batch execute SQL statements. You can store a series of TDengine CLI commands (ending with a semicolon `;`, each SQL statement on a new line) in a file, and execute the command `source <file-name>` in TDengine CLI to automatically execute all SQL statements in that file
|
||||
|
||||
## TDengine CLI Export Query Results to a File
|
||||
|
||||
- You can use the symbol “>>” to export query results to a file, the syntax is: sql query statement >> 'output file name'; If no path is written for the output file, it will be output to the current directory. For example, select * from d0 >> '/root/d0.csv'; will output the query results to /root/d0.csv.
|
||||
|
||||
## TDengine CLI Import Data from a File into a Table
|
||||
|
||||
- You can use insert into table_name file 'input file name', to import the data file exported in the previous step back into the specified table. For example, insert into d0 file '/root/d0.csv'; means to import all the data exported above back into the d0 table.
|
||||
|
|
|
|||
|
|
@ -6,45 +6,26 @@ slug: /tdengine-reference/tools/taosdump
|
|||
|
||||
`taosdump` is a TDengine data backup/recovery tool provided for open source users, and the backed up data files adopt the standard [Apache AVRO](https://avro.apache.org/)
|
||||
Format, convenient for exchanging data with the external ecosystem.
|
||||
Taosdump provides multiple data backup and recovery options to meet different data needs, and all supported options can be viewed through --help.
|
||||
taosdump provides multiple data backup and recovery options to meet different data needs, and all supported options can be viewed through --help.
|
||||
|
||||
## Installation
|
||||
## Get
|
||||
|
||||
taosdump is the default installation component in the TDengine installation package, which can be used after installing TDengine. For how to install TDengine, please refer to [TDengine Installation](../../../get-started/)
|
||||
taosdump is the default installation component in the TDengine server and client installation package. It can be used after installation, refer to [TDengine Installation](../../../get-started/)
|
||||
|
||||
## Common Use Cases
|
||||
## Startup
|
||||
|
||||
### taosdump Backup Data
|
||||
taosdump needs to be run in the command line terminal. It must be run with parameters to indicate backup or restore operations, such as:
|
||||
``` bash
|
||||
taosdump -h my-server -D test -o /root/test/
|
||||
```
|
||||
The above command means to backup the `test` database on the `my server` machine to the `/root/test/` directory.
|
||||
|
||||
1. Backup all databases: specify the `-A` or `--all-databases` parameter;
|
||||
2. Backup multiple specified databases: use the `-D db1,db2,...` parameter;
|
||||
3. Backup certain supertables or basic tables in a specified database: use the `dbname stbname1 stbname2 tbname1 tbname2 ...` parameter, note that this input sequence starts with the database name, supports only one database, and the second and subsequent parameters are the names of the supertables or basic tables in that database, separated by spaces;
|
||||
4. Backup the system log database: TDengine clusters usually include a system database named `log`, which contains data for TDengine's own operation, taosdump does not back up the log database by default. If there is a specific need to back up the log database, you can use the `-a` or `--allow-sys` command line parameter.
|
||||
5. "Tolerant" mode backup: Versions after taosdump 1.4.1 provide the `-n` and `-L` parameters, used for backing up data without using escape characters and in "tolerant" mode, which can reduce backup data time and space occupied when table names, column names, and label names do not use escape characters. If unsure whether to use `-n` and `-L`, use the default parameters for "strict" mode backup. For an explanation of escape characters, please refer to the [official documentation](../../sql-manual/escape-characters/).
|
||||
6. If a backup file already exists in the directory specified by the `-o` parameter, to prevent data from being overwritten, taosdump will report an error and exit. Please replace it with another empty directory or clear the original data before backing up.
|
||||
7. Currently, taosdump does not support data breakpoint backup function. Once the data backup is interrupted, it needs to be started from scratch.
|
||||
If the backup takes a long time, it is recommended to use the (-S -E options) method to specify the start/end time for segmented backup.
|
||||
``` bash
|
||||
taosdump -h my-server -i /root/test/
|
||||
```
|
||||
The above command means to restore the previously backed up data files in the `/root/test/` directory to the host named `my server`.
|
||||
|
||||
:::tip
|
||||
|
||||
- Versions after taosdump 1.4.1 provide the `-I` parameter, used for parsing avro file schema and data, specifying the `-s` parameter will only parse the schema.
|
||||
- Backups after taosdump 1.4.2 use the `-B` parameter to specify the number of batches, the default value is 16384. If "Error actual dump .. batch .." occurs due to insufficient network speed or disk performance in some environments, you can try adjusting the `-B` parameter to a smaller value.
|
||||
- taosdump's export does not support interruption recovery, so the correct way to handle an unexpected termination of the process is to delete all related files that have been exported or generated.
|
||||
- taosdump's import supports interruption recovery, but when the process restarts, you may receive some "table already exists" prompts, which can be ignored.
|
||||
|
||||
:::
|
||||
|
||||
### taosdump Restore Data
|
||||
|
||||
- Restore data files from a specified path: use the `-i` parameter along with the data file path. As mentioned earlier, the same directory should not be used to back up different data sets, nor should the same path be used to back up the same data set multiple times, otherwise, the backup data will cause overwriting or multiple backups.
|
||||
- taosdump supports data recovery to a new database name with the parameter `-W`, please refer to the command line parameter description for details.
|
||||
|
||||
:::tip
|
||||
taosdump internally uses the TDengine stmt binding API to write restored data, currently using 16384 as a batch for writing. If there are many columns in the backup data, it may cause a "WAL size exceeds limit" error, in which case you can try adjusting the `-B` parameter to a smaller value.
|
||||
|
||||
:::
|
||||
|
||||
## Detailed Command Line Parameters List
|
||||
## Command Line Parameters
|
||||
|
||||
Below is the detailed command line parameters list for taosdump:
|
||||
|
||||
|
|
@ -65,8 +46,8 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
-c, --config-dir=CONFIG_DIR Configure directory. Default is /etc/taos
|
||||
-i, --inpath=INPATH Input file path.
|
||||
-o, --outpath=OUTPATH Output file path.
|
||||
-r, --resultFile=RESULTFILE DumpOut/In Result file path and name.
|
||||
-a, --allow-sys Allow to dump system database
|
||||
-r, --resultFile=RESULTFILE DumpOut/In Result file path and name.
|
||||
-a, --allow-sys Allow to dump system database.
|
||||
-A, --all-databases Dump all databases.
|
||||
-D, --databases=DATABASES Dump inputted databases. Use comma to separate
|
||||
databases' name.
|
||||
|
|
@ -98,23 +79,54 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
-n, --no-escape No escape char '`'. Default is using it.
|
||||
-Q, --dot-replace Replace dot character with underline character in
|
||||
the table name.(Version 2.5.3)
|
||||
-T, --thread-num=THREAD_NUM Number of thread for dump in file. Default is
|
||||
8.
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during
|
||||
-T, --thread-num=THREAD_NUM Number of thread for dump in file. Default is 8.
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during.
|
||||
importing data. RENAME-LIST:
|
||||
"db1=newDB1|db2=newDB2" means rename db1 to newDB1
|
||||
and rename db2 to newDB2 (Version 2.5.4)
|
||||
and rename db2 to newDB2 (Version 2.5.4).
|
||||
-k, --retry-count=VALUE Set the number of retry attempts for connection or
|
||||
query failures
|
||||
-z, --retry-sleep-ms=VALUE retry interval sleep time, unit ms
|
||||
-C, --cloud=CLOUD_DSN specify a DSN to access TDengine cloud service
|
||||
-R, --restful Use RESTful interface to connect TDengine
|
||||
query failures.
|
||||
-z, --retry-sleep-ms=VALUE retry interval sleep time, unit ms.
|
||||
-C, --cloud=CLOUD_DSN specify a DSN to access TDengine cloud service.
|
||||
-R, --restful Use RESTful interface to connect TDengine.
|
||||
-t, --timeout=SECONDS The timeout seconds for websocket to interact.
|
||||
-g, --debug Print debug info.
|
||||
-?, --help Give this help list
|
||||
--usage Give a short usage message
|
||||
-V, --version Print program version
|
||||
-?, --help Give this help list.
|
||||
--usage Give a short usage message.
|
||||
-V, --version Print program version.
|
||||
|
||||
Mandatory or optional arguments to long options are also mandatory or optional
|
||||
for any corresponding short options.
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Backup Data
|
||||
|
||||
1. Backup all databases: specify the `-A` or `--all-databases` parameter.
|
||||
2. Backup multiple specified databases: use the `-D db1,db2,...` parameter.
|
||||
3. Backup certain supertables or basic tables in a specified database: use the `dbname stbname1 stbname2 tbname1 tbname2 ...` parameter, note that this input sequence starts with the database name, supports only one database, and the second and subsequent parameters are the names of the supertables or basic tables in that database, separated by spaces.
|
||||
4. Backup the system log database: TDengine clusters usually include a system database named `log`, which contains data for TDengine's own operation, taosdump does not back up the log database by default. If there is a specific need to back up the log database, you can use the `-a` or `--allow-sys` command line parameter.
|
||||
5. "Tolerant" mode backup: Versions after taosdump 1.4.1 provide the `-n` and `-L` parameters, used for backing up data without using escape characters and in "tolerant" mode, which can reduce backup data time and space occupied when table names, column names, and label names do not use escape characters. If unsure whether to use `-n` and `-L`, use the default parameters for "strict" mode backup. For an explanation of escape characters, please refer to the [official documentation](../../sql-manual/escape-characters/)
|
||||
6. If a backup file already exists in the directory specified by the `-o` parameter, to prevent data from being overwritten, taosdump will report an error and exit. Please replace it with another empty directory or clear the original data before backing up.
|
||||
7. Currently, taosdump does not support data breakpoint backup function. Once the data backup is interrupted, it needs to be started from scratch.
|
||||
If the backup takes a long time, it is recommended to use the (-S -E options) method to specify the start/end time for segmented backup.
|
||||
|
||||
:::tip
|
||||
|
||||
- Versions after taosdump 1.4.1 provide the `-I` parameter, used for parsing avro file schema and data, specifying the `-s` parameter will only parse the schema.
|
||||
- Backups after taosdump 1.4.2 use the `-B` parameter to specify the number of batches, the default value is 16384. If "Error actual dump .. batch .." occurs due to insufficient network speed or disk performance in some environments, you can try adjusting the `-B` parameter to a smaller value.
|
||||
- taosdump's export does not support interruption recovery, so the correct way to handle an unexpected termination of the process is to delete all related files that have been exported or generated.
|
||||
- taosdump's import supports interruption recovery, but when the process restarts, you may receive some "table already exists" prompts, which can be ignored.
|
||||
|
||||
:::
|
||||
|
||||
### Restore Data
|
||||
|
||||
- Restore data files from a specified path: use the `-i` parameter along with the data file path. As mentioned earlier, the same directory should not be used to back up different data sets, nor should the same path be used to back up the same data set multiple times, otherwise, the backup data will cause overwriting or multiple backups.
|
||||
- taosdump supports data recovery to a new database name with the parameter `-W`, please refer to the command line parameter description for details.
|
||||
|
||||
:::tip
|
||||
taosdump internally uses the TDengine stmt binding API to write restored data, currently using 16384 as a batch for writing. If there are many columns in the backup data, it may cause a "WAL size exceeds limit" error, in which case you can try adjusting the `-B` parameter to a smaller value.
|
||||
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -2,30 +2,33 @@
|
|||
title: taosBenchmark Reference
|
||||
sidebar_label: taosBenchmark
|
||||
slug: /tdengine-reference/tools/taosbenchmark
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
TaosBenchmark is a performance benchmarking tool for TDengine products, providing insertion, query, and subscription performance testing for TDengine products, and outputting performance indicators.
|
||||
|
||||
## Installation
|
||||
## Get
|
||||
|
||||
taosBenchmark is the default installation component in the TDengine installation package, which can be used after installing TDengine. For how to install TDengine, please refer to [TDengine Installation](../../../get started/)
|
||||
taosBenchmark is the default installation component in the TDengine server and client installation package. It can be used after installation, refer to [TDengine Installation](../../../get-started/)
|
||||
|
||||
## Operation
|
||||
## Startup
|
||||
|
||||
### Configuration and Operation Methods
|
||||
taosbenchmark supports three operating modes:
|
||||
- No Parameter Mode
|
||||
- Command Line Mode
|
||||
- JSON Configuration File Mode
|
||||
|
||||
taosBbenchmark supports three operating modes:
|
||||
- No parameter mode
|
||||
- Command line mode
|
||||
- JSON configuration file mode
|
||||
The command-line approach is a subset of the functionality of JSON configuration files, which immediately uses the command line and then the configuration file, with the parameters specified by the command line taking precedence.
|
||||
The `Command Line Mode` is a subset of the `JSON Configuration File Mode` function. When both are used at the same time, the `Command Line Mode` takes precedence.
|
||||
|
||||
**Ensure that the TDengine cluster is running correctly before running taosBenchmark.**
|
||||
:::tip
|
||||
Ensure that the TDengine cluster is running correctly before running taosBenchmark.
|
||||
:::
|
||||
|
||||
### Running Without Command Line Arguments
|
||||
### No Parameter Mode
|
||||
|
||||
|
||||
Execute the following command to quickly experience taosBenchmark performing a write performance test on TDengine based on the default configuration.
|
||||
|
||||
```shell
|
||||
taosBenchmark
|
||||
```
|
||||
|
|
@ -33,17 +36,18 @@ taosBenchmark
|
|||
When running without parameters, taosBenchmark defaults to connecting to the TDengine cluster specified in `/etc/taos/taos.cfg `.
|
||||
After successful connection, a smart meter example database test, super meters, and 10000 sub meters will be created, with 10000 records per sub meter. If the test database already exists, it will be deleted before creating a new one.
|
||||
|
||||
### Running Using Command Line Configuration Parameters
|
||||
### Command Line Mode
|
||||
|
||||
When running taosBenchmark using command line parameters and controlling its behavior, the `-f <json file>` parameter cannot be used. All configuration parameters must be specified through the command line. Below is an example of using command line mode to test the write performance of taosBenchmark.
|
||||
The parameters supported by the command line are those frequently used in the write function. The query and subscription function does not support the command line mode.
|
||||
For example:
|
||||
|
||||
```shell
|
||||
taosBenchmark -I stmt -n 200 -t 100
|
||||
```bash
|
||||
taosBenchmark -d db -t 100 -n 1000 -T 4 -I stmt -y
|
||||
```
|
||||
|
||||
The above command `taosBenchmark` will create a database named `test`, establish a supertable `meters` within it, create 100 subtables in the supertable, and insert 200 records into each subtable using parameter binding.
|
||||
This command means that using `taosBenchmark` will create a database named `db`, create the default super table `meters`, sub table 100, and use parameter binding (stmt) to write 1000 records for each sub table.
|
||||
|
||||
### Running Using a Configuration File
|
||||
### JSON Configuration File Mode
|
||||
|
||||
Running in configuration file mode provides all functions, so parameters can be configured to run in the configuration file.
|
||||
|
||||
|
|
@ -51,42 +55,8 @@ Running in configuration file mode provides all functions, so parameters can be
|
|||
taosBenchmark -f <json file>
|
||||
```
|
||||
|
||||
**Below are a few examples of configuration files:**
|
||||
|
||||
#### JSON Configuration File Example for Insertion Scenario
|
||||
|
||||
<details>
|
||||
<summary>insert.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/insert.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Example JSON Configuration File for Query Scenario
|
||||
|
||||
<details>
|
||||
<summary>query.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/query.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Example JSON Configuration File for Subscription Scenario
|
||||
|
||||
<details>
|
||||
<summary>tmq.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/tmq.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Detailed Explanation of Command Line Parameters
|
||||
## Command Line Parameters
|
||||
|
||||
- **-f/--file \<json file>** :
|
||||
The JSON configuration file to use, specifying all parameters. This parameter cannot be used simultaneously with other command line parameters. There is no default value.
|
||||
|
|
@ -212,62 +182,7 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
Displays help information and exits. Cannot be used with other parameters.
|
||||
|
||||
|
||||
## Output performance indicators
|
||||
|
||||
#### Write indicators
|
||||
|
||||
After writing is completed, a summary performance metric will be output in the last two lines in the following format:
|
||||
``` bash
|
||||
SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second
|
||||
SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms
|
||||
```
|
||||
First line write speed statistics:
|
||||
- Spent: Total write time, in seconds, counting from the start of writing the first data to the end of the last data. This indicates that a total of 8.527298 seconds were spent
|
||||
- Real: Total write time (calling the engine), excluding the time spent preparing data for the testing framework. Purely counting the time spent on engine calls, The time spent is 8.117379 seconds. If 8.527298-8.117379=0.409919 seconds, it is the time spent preparing data for the testing framework
|
||||
- Rows: Write the total number of rows, which is 10 million pieces of data
|
||||
- Threads: The number of threads being written, which is 8 threads writing simultaneously
|
||||
- Records/second write speed = `total write time` / `total number of rows written`, real in parentheses is the same as before, indicating pure engine write speed
|
||||
|
||||
Second line single write delay statistics:
|
||||
- min: Write minimum delay
|
||||
- avg: Write normal delay
|
||||
- p90: Write delay p90 percentile delay number
|
||||
- p95: Write delay p95 percentile delay number
|
||||
- p99: Write delay p99 percentile delay number
|
||||
- max: maximum write delay
|
||||
Through this series of indicators, the distribution of write request latency can be observed
|
||||
|
||||
#### Query indicators
|
||||
The query performance test mainly outputs the QPS indicator of query request speed, and the output format is as follows:
|
||||
|
||||
``` bash
|
||||
complete query with 3 threads and 10000 query delay avg: 0.002686s min: 0.001182s max: 0.012189s p90: 0.002977s p95: 0.003493s p99: 0.004645s SQL command: select ...
|
||||
INFO: Spend 26.9530 second completed total queries: 30000, the QPS of all threads: 1113.049
|
||||
```
|
||||
|
||||
- The first line represents the percentile distribution of query execution and query request delay for each of the three threads executing 10000 queries. The SQL command is the test query statement
|
||||
- The second line indicates that the total query time is 26.9653 seconds, and the query rate per second (QPS) is 1113.049 times/second
|
||||
- If the `continue_if_fail` option is set to `yes` in the query, the last line will output the number of failed requests and error rate, the format like "error + number of failed requests (error rate)"
|
||||
- QPS = number of successful requests / time spent (in seconds)
|
||||
- Error rate = number of failed requests / (number of successful requests + number of failed requests)
|
||||
|
||||
#### Subscription metrics
|
||||
|
||||
The subscription performance test mainly outputs consumer consumption speed indicators, with the following output format:
|
||||
``` bash
|
||||
INFO: consumer id 0 has poll total msgs: 376, period rate: 37.592 msgs/s, total rows: 3760000, period rate: 375924.815 rows/s
|
||||
INFO: consumer id 1 has poll total msgs: 362, period rate: 36.131 msgs/s, total rows: 3620000, period rate: 361313.504 rows/s
|
||||
INFO: consumer id 2 has poll total msgs: 364, period rate: 36.378 msgs/s, total rows: 3640000, period rate: 363781.731 rows/s
|
||||
INFO: consumerId: 0, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 1, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 2, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: Consumed total msgs: 3000, total rows: 30000000
|
||||
```
|
||||
- Lines 1 to 3 real-time output of the current consumption speed of each consumer, msgs/s represents the number of consumption messages, each message contains multiple rows of data, and rows/s represents the consumption speed calculated by rows
|
||||
- Lines 4 to 6 show the overall statistics of each consumer after the test is completed, including the total number of messages consumed and the total number of lines
|
||||
- The overall statistics of all consumers in line 7, `msgs` represents how many messages were consumed in total, `rows` represents how many rows of data were consumed in total
|
||||
|
||||
## Configuration File Parameters Detailed Explanation
|
||||
## Configuration File Parameters
|
||||
|
||||
### General Configuration Parameters
|
||||
|
||||
|
|
@ -284,7 +199,7 @@ The parameters listed in this section apply to all functional modes.
|
|||
|
||||
- **password** : Password for connecting to the TDengine server, default value is taosdata.
|
||||
|
||||
### Configuration Parameters for Insertion Scenarios
|
||||
### Insertion Configuration Parameters
|
||||
|
||||
In insertion scenarios, `filetype` must be set to `insert`. For this parameter and other common parameters, see Common Configuration Parameters.
|
||||
|
||||
|
|
@ -299,7 +214,7 @@ In insertion scenarios, `filetype` must be set to `insert`. For this parameter a
|
|||
“continue_if_fail”: “yes”, taosBenchmark warns the user and continues writing
|
||||
“continue_if_fail”: “smart”, if the child table does not exist upon failure, taosBenchmark will create the child table and continue writing
|
||||
|
||||
#### Database Related Configuration Parameters
|
||||
#### Database Parameters
|
||||
|
||||
Parameters related to database creation are configured in the `dbinfo` section of the json configuration file, specific parameters are as follows. Other parameters correspond to those specified in TDengine's `create database`, see [../../taos-sql/database]
|
||||
|
||||
|
|
@ -307,23 +222,7 @@ Parameters related to database creation are configured in the `dbinfo` section o
|
|||
|
||||
- **drop**: Whether to delete the database before insertion, options are "yes" or "no", "no" means do not create. Default is to delete.
|
||||
|
||||
#### Stream Computing Related Configuration Parameters
|
||||
|
||||
Parameters related to stream computing are configured in the `stream` section of the json configuration file, specific parameters are as follows.
|
||||
|
||||
- **stream_name**: Name of the stream computing, mandatory.
|
||||
|
||||
- **stream_stb**: Name of the supertable corresponding to the stream computing, mandatory.
|
||||
|
||||
- **stream_sql**: SQL statement for the stream computing, mandatory.
|
||||
|
||||
- **trigger_mode**: Trigger mode for the stream computing, optional.
|
||||
|
||||
- **watermark**: Watermark for the stream computing, optional.
|
||||
|
||||
- **drop**: Whether to create stream computing, options are "yes" or "no", "no" means do not create.
|
||||
|
||||
#### Supertable Related Configuration Parameters
|
||||
#### Supertable Parameters
|
||||
|
||||
Parameters related to supertable creation are configured in the `super_tables` section of the json configuration file, specific parameters are as follows.
|
||||
|
||||
|
|
@ -357,7 +256,7 @@ Parameters related to supertable creation are configured in the `super_tables` s
|
|||
|
||||
- **childtable_limit** : Effective only when child_table_exists is yes, specifies the limit when getting the subtable list from the supertable.
|
||||
|
||||
- **interlace_rows** : Enables interlaced insertion mode and specifies the number of rows to insert into each subtable at a time. Interlaced insertion mode means inserting the number of rows specified by this parameter into each subtable in turn and repeating this process until all subtable data is inserted. The default value is 0, i.e., data is inserted into one subtable before moving to the next subtable.
|
||||
- **interlace_rows** : Enables interlaced insertion mode and specifies the number of rows to insert into each subtable at a time. Interlaced insertion mode means inserting the number of rows specified by this parameter into each subtable in turn and repeating this process until all subtable data is inserted. The default is 0, i.e., data is inserted into one subtable before moving to the next subtable.
|
||||
|
||||
- **insert_interval** : Specifies the insertion interval for interlaced insertion mode, in ms, default value is 0. Only effective when `-B/--interlace-rows` is greater than 0. It means that the data insertion thread will wait for the time interval specified by this value after inserting interlaced records for each subtable before proceeding to the next round of writing.
|
||||
|
||||
|
|
@ -385,7 +284,7 @@ Parameters related to supertable creation are configured in the `super_tables` s
|
|||
- **sqls** : Array of strings type, specifies the array of sql to be executed after the supertable is successfully created, the table name specified in sql must be prefixed with the database name, otherwise an unspecified database error will occur
|
||||
|
||||
|
||||
#### Tag and Data Column Configuration Parameters
|
||||
#### Tag and Data Columns
|
||||
|
||||
Specify the configuration parameters for tag and data columns in `super_tables` under `columns` and `tag`.
|
||||
|
||||
|
|
@ -420,7 +319,7 @@ Specify the configuration parameters for tag and data columns in `super_tables`
|
|||
|
||||
- **fillNull**: String type, specifies whether this column randomly inserts NULL values, can be specified as "true" or "false", only effective when generate_row_rule is 2.
|
||||
|
||||
#### Insertion Behavior Configuration Parameters
|
||||
#### Insertion Behavior Parameters
|
||||
|
||||
- **thread_count**: The number of threads for inserting data, default is 8.
|
||||
|
||||
|
|
@ -432,7 +331,7 @@ Specify the configuration parameters for tag and data columns in `super_tables`
|
|||
|
||||
- **confirm_parameter_prompt** : A toggle parameter that requires user confirmation after a prompt to continue. The value can be "yes" or "no", by default "no".
|
||||
|
||||
- **interlace_rows** : Enables interleaved insertion mode and specifies the number of rows to insert into each subtable at a time. Interleaved insertion mode refers to inserting the specified number of rows into each subtable in sequence and repeating this process until all subtable data has been inserted. The default value is 0, meaning data is inserted into one subtable completely before moving to the next.
|
||||
- **interlace_rows** : Enables interleaved insertion mode and specifies the number of rows to insert into each subtable at a time. Interleaved insertion mode refers to inserting the specified number of rows into each subtable in sequence and repeating this process until all subtable data has been inserted. The default is 0, meaning data is inserted into one subtable completely before moving to the next.
|
||||
This parameter can also be configured in `super_tables`; if configured, the settings in `super_tables` take higher priority and override the global settings.
|
||||
|
||||
- **insert_interval** :
|
||||
|
|
@ -442,68 +341,84 @@ Specify the configuration parameters for tag and data columns in `super_tables`
|
|||
- **num_of_records_per_req** :
|
||||
The number of data rows requested per write to TDengine, default is 30000. If set too high, the TDengine client driver will return corresponding error messages, and this parameter needs to be reduced to meet the writing requirements.
|
||||
|
||||
- **prepare_rand** : The number of unique values in the generated random data. If it is 1, it means all data are the same. The default value is 10000.
|
||||
- **prepare_rand** : The number of unique values in the generated random data. If it is 1, it means all data are the same. The default is 10000.
|
||||
|
||||
- **pre_load_tb_meta** : Whether to pre-load the meta data of subtables, values are “yes” or "no". When there are a large number of subtables, turning on this option can improve the writing speed.
|
||||
|
||||
### Configuration Parameters for Query Scenarios
|
||||
### Query Parameters
|
||||
|
||||
In query scenarios, `filetype` must be set to `query`.
|
||||
`query_times` specifies the number of times to run the query, numeric type.
|
||||
|
||||
Query scenarios can control the execution of slow query statements by setting `kill_slow_query_threshold` and `kill_slow_query_interval` parameters, where threshold controls that queries exceeding the specified exec_usec time will be killed by taosBenchmark, in seconds; interval controls the sleep time to avoid continuous slow query CPU consumption, in seconds.
|
||||
|
||||
For other common parameters, see Common Configuration Parameters.
|
||||
For other common parameters, see [General Configuration Parameters](#general-configuration-parameters)
|
||||
|
||||
#### Configuration Parameters for Executing Specified Query Statements
|
||||
|
||||
Configuration parameters for querying specified tables (can specify supertables, subtables, or regular tables) are set in `specified_table_query`.
|
||||
|
||||
`General Query`: Each SQL in `sqls` starts `threads` threads to query this SQL, Each thread exits after executing the `query_times` queries, and only after all threads executing this SQL have completed can the next SQL be executed.
|
||||
The total number of queries(`General Query`) = the number of `sqls` * `query_times` * `threads`
|
||||
- `Mixed Query` : All SQL statements in `sqls` are divided into `threads` groups, with each thread executing one group. Each SQL statement needs to execute `query_times` queries.
|
||||
The total number of queries(`Mixed Query`) = the number of `sqls` * `query_times`
|
||||
#### Specified Query
|
||||
|
||||
Configuration parameters for querying specified tables (can specify supertables, subtables, or regular tables) are set in `specified_table_query`.
|
||||
- **mixed_query** : Query Mode . "yes" is `Mixed Query`, "no" is `General Query`, default is "no".
|
||||
`General Query`:
|
||||
Each SQL in `sqls` starts `threads` threads to query this SQL, Each thread exits after executing the `query_times` queries, and only after all threads executing this SQL have completed can the next SQL be executed.
|
||||
The total number of queries(`General Query`) = the number of `sqls` * `query_times` * `threads`
|
||||
`Mixed Query`:
|
||||
All SQL statements in `sqls` are divided into `threads` groups, with each thread executing one group. Each SQL statement needs to execute `query_times` queries.
|
||||
The total number of queries(`Mixed Query`) = the number of `sqls` * `query_times`
|
||||
- **query_interval** : Query interval, in millisecond, default is 0.
|
||||
|
||||
- **threads** : Number of threads executing the SQL query, default is 1.
|
||||
|
||||
- **sqls**:
|
||||
- **sql**: The SQL command to execute, required.
|
||||
- **result**: File to save the query results, if not specified, results are not saved.
|
||||
|
||||
#### Configuration Parameters for Querying Supertables
|
||||
#### Supertables
|
||||
|
||||
Configuration parameters for querying supertables are set in `super_table_query`.
|
||||
The thread mode of the super table query is the same as the `Normal Query` mode of the specified query statement described above, except that `sqls` is filled all sub tables.
|
||||
|
||||
- **stblname** : The name of the supertable to query, required.
|
||||
|
||||
- **query_interval** : Query interval, in seconds, default is 0.
|
||||
|
||||
- **threads** : Number of threads executing the SQL query, default is 1.
|
||||
|
||||
- **sqls** :
|
||||
- **sql** : The SQL command to execute, required; for supertable queries, keep "xxxx" in the SQL command, the program will automatically replace it with all subtable names of the supertable.
|
||||
- **result** : File to save the query results, if not specified, results are not saved.
|
||||
- **Note**: The maximum number of SQL arrays configured under SQL is 100.
|
||||
|
||||
### Configuration Parameters for Subscription Scenarios
|
||||
### Subscription Parameters
|
||||
|
||||
In subscription scenarios, `filetype` must be set to `subscribe`, this parameter and other common parameters see Common Configuration Parameters.
|
||||
In the subscription scenario, `filetype` must be set to `subscribe`. For details of this parameter and other general parameters, see [General Configuration Parameters](#general-configuration-parameters)
|
||||
The subscription configuration parameters are set under `tmq_info`. The parameters are as follows:
|
||||
|
||||
#### Configuration Parameters for Executing Specified Subscription Statements
|
||||
- **concurrent**: the number of consumers who consume subscriptions, or the number of concurrent consumers. The default value is 1.
|
||||
- **create_mode**: create a consumer mode.
|
||||
Which can be sequential: create in sequence. parallel: It is created at the same time. It is required and has no default value.
|
||||
- **group_mode**: generate the consumer groupId mode.
|
||||
Which can take the value share: all consumers can only generate one groupId independent: Each consumer generates an independent groupId. If `group.id` is not set, this item is mandatory and has no default value.
|
||||
-**poll_delay**: The polling timeout time passed in by calling tmq_consumer_poll.
|
||||
The unit is milliseconds. A negative number means the default timeout is 1 second.
|
||||
-**enable.manual.commit**: whether manual submission is allowed.
|
||||
The value can be true: manual submission is allowed, after consuming messages, manually call tmq_commit_sync to complete the submission. false：Do not submit, default value: false.
|
||||
-**rows_file**: a file that stores consumption data.
|
||||
It can be a full path or a relative path with a file name.The actual saved file will be followed by the consumer serial number. For example, rows_file is result, and the actual file name is result_1 (consumer 1) result_2 (consumer 2).
|
||||
-**expect_rows**: the number of rows and data types expected to be consumed by each consumer.
|
||||
When the consumption reaches this number, the consumption will exit, and the consumption will continue without setting.
|
||||
-**topic_list**: specifies the topic list and array type of consumption.
|
||||
Example of topic list format: `{"name": "topic1", "sql": "select * from test.meters;"}`.
|
||||
name: Specify the topic name.
|
||||
sql: Specify the sql statement for creating topic, Ensure that the sql is correct, and the framework will automatically create topic.
|
||||
|
||||
Configuration parameters for subscribing to specified tables (can specify supertables, subtables, or regular tables) are set in `specified_table_query`.
|
||||
For the following parameters, see the description of [Subscription](../../../advanced-features/data-subscription/):
|
||||
- **client.id**
|
||||
- **auto.offset.reset**
|
||||
- **enable.auto.commit**
|
||||
- **enable.auto.commit**
|
||||
- **msg.with.table.name**
|
||||
- **auto.commit.interval.ms**
|
||||
- **group.id**: If this value is not specified, the groupId will be generated by the rule specified by `group_mode`. If this value is specified, the `group_mode` parameter is ignore.
|
||||
|
||||
- **threads/concurrent** : Number of threads executing the SQL, default is 1.
|
||||
|
||||
- **sqls** :
|
||||
- **sql** : The SQL command to execute, required.
|
||||
### Data Type Comparison Table
|
||||
|
||||
### Data Type Writing Comparison Table in Configuration File
|
||||
|
||||
| # | **Engine** | **taosBenchmark**
|
||||
| # | **TDengine** | **taosBenchmark**
|
||||
| --- | :----------------: | :---------------:
|
||||
| 1 | TIMESTAMP | timestamp
|
||||
| 2 | INT | int
|
||||
|
|
@ -525,3 +440,97 @@ Configuration parameters for subscribing to specified tables (can specify supert
|
|||
| 18 | JSON | json
|
||||
|
||||
Note: Data types in the taosBenchmark configuration file must be in lowercase to be recognized.
|
||||
|
||||
## Example Of Configuration Files
|
||||
|
||||
**Below are a few examples of configuration files:**
|
||||
|
||||
#### Insertion Example
|
||||
|
||||
<details>
|
||||
<summary>insert.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/insert.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Query Example
|
||||
|
||||
<details>
|
||||
<summary>query.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/query.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Subscription Example
|
||||
|
||||
<details>
|
||||
<summary>tmq.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/tmq.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Other json examples see [here](https://github.com/taosdata/TDengine/tree/main/tools/taos-tools/example)
|
||||
|
||||
## Output Performance Indicators
|
||||
|
||||
#### Write Indicators
|
||||
|
||||
After writing is completed, a summary performance metric will be output in the last two lines in the following format:
|
||||
``` bash
|
||||
SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second
|
||||
SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms
|
||||
```
|
||||
First line write speed statistics:
|
||||
- Spent: Total write time, in seconds, counting from the start of writing the first data to the end of the last data. This indicates that a total of 8.527298 seconds were spent.
|
||||
- Real: Total write time (calling the engine), excluding the time spent preparing data for the testing framework. Purely counting the time spent on engine calls, The time spent is 8.117379 seconds. If 8.527298-8.117379=0.409919 seconds, it is the time spent preparing data for the testing framework.
|
||||
- Rows: Write the total number of rows, which is 10 million pieces of data.
|
||||
- Threads: The number of threads being written, which is 8 threads writing simultaneously.
|
||||
- Records/second write speed = `total write time` / `total number of rows written`, real in parentheses is the same as before, indicating pure engine write speed.
|
||||
|
||||
Second line single write delay statistics:
|
||||
- min: Write minimum delay.
|
||||
- avg: Write normal delay.
|
||||
- p90: Write delay p90 percentile delay number.
|
||||
- p95: Write delay p95 percentile delay number.
|
||||
- p99: Write delay p99 percentile delay number.
|
||||
- max: maximum write delay.
|
||||
Through this series of indicators, the distribution of write request latency can be observed.
|
||||
|
||||
#### Query indicators
|
||||
The query performance test mainly outputs the QPS indicator of query request speed, and the output format is as follows:
|
||||
|
||||
``` bash
|
||||
complete query with 3 threads and 10000 query delay avg: 0.002686s min: 0.001182s max: 0.012189s p90: 0.002977s p95: 0.003493s p99: 0.004645s SQL command: select ...
|
||||
INFO: Spend 26.9530 second completed total queries: 30000, the QPS of all threads: 1113.049
|
||||
```
|
||||
|
||||
- The first line represents the percentile distribution of query execution and query request delay for each of the three threads executing 10000 queries. The SQL command is the test query statement.
|
||||
- The second line indicates that the total query time is 26.9653 seconds, and the query rate per second (QPS) is 1113.049 times/second.
|
||||
- If the `continue_if_fail` option is set to `yes` in the query, the last line will output the number of failed requests and error rate, the format like "error + number of failed requests (error rate)".
|
||||
- QPS = number of successful requests / time spent (in seconds)
|
||||
- Error rate = number of failed requests / (number of successful requests + number of failed requests)
|
||||
|
||||
#### Subscription indicators
|
||||
|
||||
The subscription performance test mainly outputs consumer consumption speed indicators, with the following output format:
|
||||
``` bash
|
||||
INFO: consumer id 0 has poll total msgs: 376, period rate: 37.592 msgs/s, total rows: 3760000, period rate: 375924.815 rows/s
|
||||
INFO: consumer id 1 has poll total msgs: 362, period rate: 36.131 msgs/s, total rows: 3620000, period rate: 361313.504 rows/s
|
||||
INFO: consumer id 2 has poll total msgs: 364, period rate: 36.378 msgs/s, total rows: 3640000, period rate: 363781.731 rows/s
|
||||
INFO: consumerId: 0, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 1, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 2, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: Consumed total msgs: 3000, total rows: 30000000
|
||||
```
|
||||
- Lines 1 to 3 real-time output of the current consumption speed of each consumer, msgs/s represents the number of consumption messages, each message contains multiple rows of data, and rows/s represents the consumption speed calculated by rows.
|
||||
- Lines 4 to 6 show the overall statistics of each consumer after the test is completed, including the total number of messages consumed and the total number of lines.
|
||||
- The overall statistics of all consumers in line 7, `msgs` represents how many messages were consumed in total, `rows` represents how many rows of data were consumed in total.
|
||||
|
|
@ -644,6 +644,3 @@ This section summarizes the ODBC API by functionality. For a complete ODBC API r
|
|||
- **Standard**: ODBC
|
||||
- **Function**: Closes the cursor associated with the current statement handle and releases all resources used by the cursor
|
||||
|
||||
## Integration with Third Parties
|
||||
|
||||
As an example of using the TDengine ODBC driver, you can use Power BI to analyze time-series data with TDengine. For more details, please refer to [Power BI](../../../third-party-tools/analytics/power-bi/)
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ If the client encounters a connection failure, please follow the steps below to
|
|||
|
||||
### 5. What to do if you encounter the error "Unable to resolve FQDN"?
|
||||
|
||||
This error occurs because the client or data node cannot resolve the FQDN (Fully Qualified Domain Name). For the TAOS Shell or client applications, please check the following:
|
||||
This error occurs because the client or data node cannot resolve the FQDN (Fully Qualified Domain Name). For the TDengine CLI or client applications, please check the following:
|
||||
|
||||
1. Check if the FQDN of the server you are connecting to is correct.
|
||||
2. If there is a DNS server in the network configuration, check if it is working properly
|
||||
|
|
@ -244,15 +244,15 @@ launchctl limit maxfiles
|
|||
This prompt indicates that the number of vnodes required for creating the db is not enough, exceeding the upper limit of vnodes in the dnode. By default, a dnode contains twice the number of CPU cores worth of vnodes, which can also be controlled by the supportVnodes parameter in the configuration file.
|
||||
Normally, increase the supportVnodes parameter in taos.cfg.
|
||||
|
||||
### 21 Why can data from a specified time period be queried using taos-CLI on the server, but not on the client machine?
|
||||
### 21 Why can data from a specified time period be queried using TDengine CLI on the server, but not on the client machine?
|
||||
|
||||
This issue is due to the client and server having different time zone settings. Adjusting the client's time zone to match the server's will resolve the issue.
|
||||
|
||||
### 22 The table name is confirmed to exist, but returns "table name does not exist" when writing or querying, why?
|
||||
|
||||
In TDengine, all names, including database names and table names, are case-sensitive. If these names are not enclosed in backticks (\`) in the program or taos-CLI, even if you input them in uppercase, the engine will convert them to lowercase for use. If the names are enclosed in backticks, the engine will not convert them to lowercase and will use them as is.
|
||||
In TDengine, all names, including database names and table names, are case-sensitive. If these names are not enclosed in backticks (\`) in the program or TDengine CLI, even if you input them in uppercase, the engine will convert them to lowercase for use. If the names are enclosed in backticks, the engine will not convert them to lowercase and will use them as is.
|
||||
|
||||
### 23 How to fully display field content in taos-CLI queries?
|
||||
### 23 How to fully display field content in TDengine CLI queries?
|
||||
|
||||
You can use the \G parameter for vertical display, such as `show databases\G\;` (for ease of input, press TAB after "\" to automatically complete the content).
|
||||
|
||||
|
|
@ -315,4 +315,4 @@ Problem solving: You should configure the automatic mount of the dataDir directo
|
|||
Directly querying from child table is fast. The query from super table with TAG filter is designed to meet the convenience of querying. It can filter data from multiple child tables at the same time. If the goal is to pursue performance and the child table has been clearly queried, directly querying from the sub table can achieve higher performance
|
||||
|
||||
### 35 How to view data compression ratio indicators?
|
||||
Currently, TDengine only provides compression ratios based on tables, not databases or the entire system. To view the compression ratios, execute the `SHOW TABLE DISTRIBUTED table_name;` command in the client taos-CLI. The table_name can be a super table, regular table, or subtable. For details [Click Here](https://docs.tdengine.com/tdengine-reference/sql-manual/show-commands/#show-table-distributed)
|
||||
Currently, TDengine only provides compression ratios based on tables, not databases or the entire system. To view the compression ratios, execute the `SHOW TABLE DISTRIBUTED table_name;` command in the client TDengine CLI. The table_name can be a super table, regular table, or subtable. For details [Click Here](https://docs.tdengine.com/tdengine-reference/sql-manual/show-commands/#show-table-distributed)
|
||||
|
|
@ -56,4 +56,4 @@ slug: /release-history/release-notes/3-3-2-0
|
|||
13. Upgrading to 3.3.0.0 and enabling `cachemodel` causes incorrect row count returns for `last + group by`
|
||||
14. `taos-explorer` navigation bar does not display all supertable names (Enterprise Edition only)
|
||||
15. Querying causes `taosd` to crash when compound primary key VARCHAR length exceeds 125
|
||||
16. High CPU usage by `taos CLI` and `taosAdapter`
|
||||
16. High CPU usage by `TDengine CLI` and `taosAdapter`
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ slug: /release-history/release-notes/3-3-3-0
|
|||
22. Cursor error in data filling during cache update causes taosd to exit abnormally
|
||||
23. Random incorrect results of STDDEV function calculation
|
||||
24. Unable to add offline nodes in multi-tier storage and encryption scenarios
|
||||
25. taos CLI cannot input passwords longer than 20 bytes
|
||||
25. TDengine CLI cannot input passwords longer than 20 bytes
|
||||
26. SQL write error: int data overflow
|
||||
27. Metadata consistency in scenarios of high query concurrency
|
||||
28. Attempt to solve the issue where manually clicking the stop button does not stop the task
|
||||
|
|
@ -90,4 +90,4 @@ slug: /release-history/release-notes/3-3-3-0
|
|||
59. Client memory leak
|
||||
60. Open-source users unable to modify other database options after upgrading stt_trigger value
|
||||
61. Incorrect results for NOT IN (NULL) queries
|
||||
62. taos shell and taosBenchmark unable to successfully connect to cloud service instances
|
||||
62. TDengine CLI and taosBenchmark unable to successfully connect to cloud service instances
|
||||
|
|
|
|||
|
|
@ -52,13 +52,13 @@ slug: /release-history/release-notes/3-3-4-3
|
|||
1. fix: memory leak caused by repeated addition and deletion of tables on the Windows platform.
|
||||
1. fix(stream): check the right return code for concurrent checkpoint trans.
|
||||
1. fix: the "too many session" problem while perform large concurrent queries.
|
||||
1. fix: the problem of taos shell crashing in slow query scenarios on the Windows platform.
|
||||
1. fix: the encrypted database cannot be recovered when opening the dnode log.
|
||||
1. fix: the problem that taosd cannot be started due to mnode synchronization timeout.
|
||||
1. fix: the slow sorting of file group data during snapshot synchronization leads to the inability of Vnode to recover.
|
||||
1. fix: when writing data with escape characters to a varchar field throug line protocol, taosd will crash.
|
||||
1. fix: metadata file damage caused by incorrect logic processing of error code
|
||||
1. fix: when a query statement contains multiple nested "not" conditional statements, not setting the scalar mode will lead to query errors.
|
||||
1. fix: the problem of dnode going offline due to timeout of vnode stat report.
|
||||
1. fix: taosd failed to start on servers that not support AVX instructions.
|
||||
1. fix(taosX): handle 0x09xx error codes in migration
|
||||
2. fix: the problem of TDengine CLI crashing in slow query scenarios on the Windows platform.
|
||||
3. fix: the encrypted database cannot be recovered when opening the dnode log.
|
||||
4. fix: the problem that taosd cannot be started due to mnode synchronization timeout.
|
||||
5. fix: the slow sorting of file group data during snapshot synchronization leads to the inability of Vnode to recover.
|
||||
6. fix: when writing data with escape characters to a varchar field throug line protocol, taosd will crash.
|
||||
7. fix: metadata file damage caused by incorrect logic processing of error code
|
||||
8. fix: when a query statement contains multiple nested "not" conditional statements, not setting the scalar mode will lead to query errors.
|
||||
9. fix: the problem of dnode going offline due to timeout of vnode stat report.
|
||||
10. fix: taosd failed to start on servers that not support AVX instructions.
|
||||
11. fix(taosX): handle 0x09xx error codes in migration
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ slug: /release-history/release-notes/3-3-5-0
|
|||
2. feat: refactor taosX incremental backup-restore
|
||||
3. feat: add stmt2 apis in JDBC via websocket connection
|
||||
4. feat: add stmt2 api in Rust connector
|
||||
5. feat: add error codes in error prompts in taos-CLI
|
||||
5. feat: add error codes in error prompts in TDengine CLI
|
||||
6. feat: superSet can connect TDengine with python connector
|
||||
7. feat: configurable grafana dashboards in explorer management
|
||||
8. feat: add taosX-agent in-memory cache queu capacity option
|
||||
|
|
|
|||
|
|
@ -38,6 +38,6 @@ slug: /release-history/release-notes/3.3.5.2
|
|||
20. fix: column names were not correctly copied when using SELECT * FROM subqueries
|
||||
21. fix: when performing max/min function on string type data, the results are inaccurate and taosd will crash
|
||||
22. fix: stream computing does not support the use of the HAVING clause, but no error is reported during creation
|
||||
23. fix: the version information displayed by taos shell for the server is inaccurate, such as being unable to correctly distinguish between the community edition and the enterprise edition
|
||||
23. fix: the version information displayed by TDengine CLI for the server is inaccurate, such as being unable to correctly distinguish between the community edition and the enterprise edition
|
||||
24. fix: in certain specific query scenarios, when JOIN and CAST are used together, taosd may crash
|
||||
|
||||
|
|
|
|||
|
|
@ -77,13 +77,6 @@
|
|||
<artifactId>fastjson</artifactId>
|
||||
<version>1.2.83</version>
|
||||
</dependency>
|
||||
<!-- mysql: just for test -->
|
||||
<dependency>
|
||||
<groupId>mysql</groupId>
|
||||
<artifactId>mysql-connector-java</artifactId>
|
||||
<version>8.0.28</version>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
<!-- log4j -->
|
||||
<dependency>
|
||||
<groupId>org.apache.logging.log4j</groupId>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
sidebar_label: 用Docker快速体验
|
||||
sidebar_label: 用 Docker 快速体验
|
||||
title: 用 Docker 快速体验 TDengine
|
||||
description: 使用 Docker 快速体验 TDengine 的高效写入和查询
|
||||
---
|
||||
|
|
@ -91,7 +91,7 @@ taosBenchmark 提供了丰富的选项，允许用户自定义测试参数，如
|
|||
taosBenchmark --help
|
||||
```
|
||||
|
||||
有关taosBenchmark 的详细使用方法，请参考[taosBenchmark 参考手册](../../reference/tools/taosbenchmark)
|
||||
有关 taosBenchmark 的详细使用方法，请参考 [taosBenchmark 参考手册](../../reference/tools/taosbenchmark)
|
||||
|
||||
### 体验查询
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ import Tabs from "@theme/Tabs";
|
|||
import TabItem from "@theme/TabItem";
|
||||
import PkgListV3 from "/components/PkgListV3";
|
||||
|
||||
TDengine 完整的软件包包括服务端（taosd）、应用驱动（taosc）、用于与第三方系统对接并提供 RESTful 接口的 taosAdapter、命令行程序（CLI，taos）和一些工具软件。目前 TDinsight 仅在 Linux 系统上安装和运行，后续将支持 Windows、macOS 等系统。TDengine 除了提供多种语言的连接器之外，还通过 [taosAdapter](../../reference/components/taosadapter/) 提供 [RESTful 接口](../../reference/connector/rest-api/)。
|
||||
TDengine 完整的软件包包括服务端（taosd）、应用驱动（taosc）、用于与第三方系统对接并提供 RESTful 接口的 taosAdapter、命令行程序（TDengine CLI）和一些工具软件。目前 TDinsight 仅在 Linux 系统上安装和运行，后续将支持 Windows、macOS 等系统。TDengine 除了提供多种语言的连接器之外，还通过 [taosAdapter](../../reference/components/taosadapter/) 提供 [RESTful 接口](../../reference/connector/rest-api/)。
|
||||
|
||||
为方便使用，标准的服务端安装包包含了 taosd、taosAdapter、taosc、taos、taosdump、taosBenchmark、TDinsight 安装脚本和示例代码；如果您只需要用到服务端程序和客户端连接的 C/C++ 语言支持，也可以仅下载 Lite 版本的安装包。
|
||||
|
||||
|
|
@ -17,30 +17,27 @@ TDengine 完整的软件包包括服务端（taosd）、应用驱动（taosc）
|
|||
此外，TDengine 也提供 macOS x64/m1 平台的 pkg 安装包。
|
||||
|
||||
## 运行环境要求
|
||||
|
||||
在linux系统中，运行环境最低要求如下:
|
||||
1. linux 内核版本：3.10.0-1160.83.1.el7.x86_64 或以上
|
||||
2. glibc 版本：2.17 或以上
|
||||
|
||||
linux 内核版本 - 3.10.0-1160.83.1.el7.x86_64;
|
||||
|
||||
glibc 版本 - 2.17;
|
||||
|
||||
如果通过clone源码进行编译安装，还需要满足:
|
||||
|
||||
cmake版本 - 3.26.4或以上;
|
||||
|
||||
gcc 版本 - 9.3.1或以上;
|
||||
|
||||
如果通过 Clone 源码进行编译安装，还需要满足:
|
||||
1. cmake 版本：3.26.4 或以上
|
||||
2. gcc 版本：9.3.1 或以上
|
||||
|
||||
## 安装
|
||||
|
||||
**注意**
|
||||
|
||||
从TDengine 3.0.6.0 开始，不再提供单独的 taosTools 安装包，原 taosTools 安装包中包含的工具都在 TDengine-server 安装包中，如果需要请直接下载 TDengine -server 安装包。
|
||||
从 TDengine 3.0.6.0 开始，不再提供单独的 taosTools 安装包，原 taosTools 安装包中包含的工具都在 TDengine-server 安装包中，如果需要请直接下载 TDengine-server 安装包。
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Deb 安装" value="debinst">
|
||||
|
||||
1. 从列表中下载获得 Deb 安装包；
|
||||
1. 从列表中下载获得 Deb 安装包：
|
||||
<PkgListV3 type={6}/>
|
||||
|
||||
2. 进入到安装包所在目录，执行如下的安装命令：
|
||||
|
||||
> 请将 `<version>` 替换为下载的安装包版本
|
||||
|
|
@ -53,8 +50,9 @@ sudo dpkg -i TDengine-server-<version>-Linux-x64.deb
|
|||
|
||||
<TabItem label="RPM 安装" value="rpminst">
|
||||
|
||||
1. 从列表中下载获得 RPM 安装包；
|
||||
1. 从列表中下载获得 RPM 安装包：
|
||||
<PkgListV3 type={5}/>
|
||||
|
||||
2. 进入到安装包所在目录，执行如下的安装命令：
|
||||
|
||||
> 请将 `<version>` 替换为下载的安装包版本
|
||||
|
|
@ -67,7 +65,7 @@ sudo rpm -ivh TDengine-server-<version>-Linux-x64.rpm
|
|||
|
||||
<TabItem label="tar.gz 安装" value="tarinst">
|
||||
|
||||
1. 从列表中下载获得 tar.gz 安装包；
|
||||
1. 从列表中下载获得 tar.gz 安装包：
|
||||
<PkgListV3 type={0}/>
|
||||
2. 进入到安装包所在目录，使用 `tar` 解压安装包；
|
||||
3. 进入到安装包所在目录，先解压文件后，进入子目录，执行其中的 install.sh 安装脚本。
|
||||
|
|
@ -126,14 +124,14 @@ apt-get 方式只适用于 Debian 或 Ubuntu 系统。
|
|||
**注意**
|
||||
- 目前 TDengine 在 Windows 平台上只支持 Windows Server 2016/2019 和 Windows 10/11。
|
||||
- 从 TDengine 3.1.0.0 开始，只提供 Windows 客户端安装包。如果需要 Windows 服务端安装包，请联系 TDengine 销售团队升级为企业版。
|
||||
- Windows 上需要安装 VC 运行时库，可在此下载安装 [VC运行时库](https://learn.microsoft.com/zh-cn/cpp/windows/latest-supported-vc-redist?view=msvc-170), 如果已经安装此运行库可忽略。
|
||||
- Windows 上需要安装 VC 运行时库，可在此下载安装 [VC 运行时库](https://learn.microsoft.com/zh-cn/cpp/windows/latest-supported-vc-redist?view=msvc-170)，如果已经安装此运行库可忽略。
|
||||
|
||||
按照以下步骤安装：
|
||||
|
||||
1. 从列表中下载获得 exe 安装程序；
|
||||
1. 从列表中下载获得 exe 安装程序：
|
||||
<PkgListV3 type={3}/>
|
||||
2. 运行可执行程序来安装 TDengine。
|
||||
Note: 从 3.0.1.7 开始，只提供 TDengine 客户端的 Windows 客户端的下载。想要使用TDengine 服务端的 Windows 版本，请联系销售升级为企业版本。
|
||||
Note: 从 3.0.1.7 版本开始，只提供 TDengine 客户端的 Windows 客户端的下载。想要使用 TDengine 服务端的 Windows 版本，请联系 TDengine 销售团队升级为企业版。
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="macOS 安装" value="macos">
|
||||
|
|
@ -210,12 +208,12 @@ sudo launchctl start com.tdengine.taoskeeper
|
|||
sudo launchctl start com.tdengine.taos-explorer
|
||||
```
|
||||
|
||||
你也可以直接运行 start-all.sh 脚本来启动上面的所有服务
|
||||
你也可以直接运行 `start-all.sh` 脚本来启动上面的所有服务
|
||||
```bash
|
||||
start-all.sh
|
||||
```
|
||||
|
||||
可以使用 `launchctl` 命令管理上面提到的每个 TDengine 服务，以下示例使用 `taosd` ：
|
||||
可以使用 `launchctl` 命令管理上面提到的每个 TDengine 服务，以下示例使用 `taosd` ：
|
||||
|
||||
```bash
|
||||
sudo launchctl start com.tdengine.taosd
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 通过云服务 快速体验 TDengine
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
TDengine Cloud 作为一个全托管的时序大数据云服务平台，致力于让用户迅速领略TDengine 的强大功能。该平台不仅继承了 TDengine Enterprise 的核心功能特性，还充分发挥了 TDengine 的云原生优势。TDengine Cloud 以其极致的资源弹性伸缩、高可用性、容器化部署以及按需付费等特点，灵活满足各类用户需求，为用户打造高效、可靠且经济的时序大数据处理解决方案。
|
||||
TDengine Cloud 作为一个全托管的时序大数据云服务平台，致力于让用户迅速领略 TDengine 的强大功能。该平台不仅继承了 TDengine Enterprise 的核心功能特性，还充分发挥了 TDengine 的云原生优势。TDengine Cloud 以其极致的资源弹性伸缩、高可用性、容器化部署以及按需付费等特点，灵活满足各类用户需求，为用户打造高效、可靠且经济的时序大数据处理解决方案。
|
||||
|
||||
TDengine Cloud 大幅减轻了用户在部署、运维等方面的人力负担，同时提供了全方位的企业级服务。这些服务涵盖多角色、多层次的用户管理、数据共享功能，以适应各种异构网络环境。此外，TDengine Cloud 还提供私有链接服务和极简的数据备份与恢复功能，确保数据安全无忧。
|
||||
|
||||
|
|
@ -25,11 +25,10 @@ TDengine Cloud 大幅减轻了用户在部署、运维等方面的人力负担
|
|||
|
||||
要在 TDengine Cloud 中创建 TDengine 实例，只须遵循以下 3 个简单步骤。
|
||||
|
||||
1. 第 1 步，选择公共数据库。在此步骤中，TDengine Cloud 提供了可供公共访问的智能电表等数据库。通过浏览和查询这些数据库，你可以立即体验 TDengine 的各种功能和高性能。你可以根据需求在此步骤启动数据库访问，或在后续使用过程中再进行启动。若不需要此步骤，可直接点击“下一步”按钮跳过。
|
||||
1. 选择公共数据库。在此步骤中，TDengine Cloud 提供了可供公共访问的智能电表等数据库。通过浏览和查询这些数据库，你可以立即体验 TDengine 的各种功能和高性能。你可以根据需求在此步骤启动数据库访问，或在后续使用过程中再进行启动。若不需要此步骤，可直接点击“下一步”按钮跳过。
|
||||
|
||||
2. 第 2 步，创建组织。在此步骤中，请输入一个具有意义的名称，代表你的公司或组织，这将有助于你和平台更好地管理云上资源。
|
||||
|
||||
3. 第 3 步，创建实例。在此步骤中，你需要填写实例的区域、名称、是否选择高可用选项以及计费方案等必填信息。确认无误后，点击“创建”按钮。大约等待 1min，新的TDengine 实例便会创建完成。随后，你可以在控制台中对该实例进行各种操作，如查询数据、创建订阅、创建流等。
|
||||
2. 创建组织。在此步骤中，请输入一个具有意义的名称，代表你的公司或组织，这将有助于你和平台更好地管理云上资源。
|
||||
|
||||
3. 创建实例。在此步骤中，你需要填写实例的区域、名称、是否选择高可用选项以及计费方案等必填信息。确认无误后，点击“创建”按钮。大约等待 1min，新的 TDengine 实例便会创建完成。随后，你可以在控制台中对该实例进行各种操作，如查询数据、创建订阅、创建流等。
|
||||
|
||||
TDengine Cloud 提供多种级别的计费方案，包括入门版、基础版、标准版、专业版和旗舰版，以满足不同客户的需求。如果你觉得现有计费方案无法满足自己的特定需求，请联系 TDengine Cloud 的客户支持团队，他们将为你量身定制计费方案。注册后，你将获得一定的免费额度，以便体验服务
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ import xiaot_new from './xiaot-20231007.png'
|
|||
import channel from './channel.webp'
|
||||
import official_account from './official-account.webp'
|
||||
|
||||
TDengine 完整的软件包包括服务端（taosd）、用于与第三方系统对接并提供 RESTful 接口的 taosAdapter、应用驱动（taosc）、命令行程序 (CLI，taos) 和一些工具软件。TDengine 除了提供多种语言的连接器之外，还通过 [taosAdapter](../reference/components/taosadapter) 提供 [RESTful 接口](../reference/connector/rest-api)。
|
||||
TDengine 完整的软件包包括服务端（taosd）、用于与第三方系统对接并提供 RESTful 接口的 taosAdapter、应用驱动（taosc）、命令行程序 (TDengine CLI) 和一些工具软件。TDengine 除了提供多种语言的连接器之外，还通过 [taosAdapter](../reference/components/taosadapter) 提供 [RESTful 接口](../reference/connector/rest-api)。
|
||||
|
||||
本章主要介绍如何快速设置 TDengine 环境并体验其高效写入和查询。
|
||||
|
||||
|
|
|
|||
|
|
@ -25,11 +25,11 @@ toc_max_heading_level: 4
|
|||
### 采集量
|
||||
|
||||
采集量是指通过各种传感器、设备或其他类型的采集点所获取的物理量，如电流、电压、温度、压力、GPS 等。由于这些物理量随时间不断变化，因此采集的数据类型多
|
||||
样，包括整型、浮点型、布尔型以及字符串等。随着时间的积累，存储的数据将持续增长。以智能电表为例，其中的 current（电流）、voltage（电压）和 phase（相位）便是典型的采集量。
|
||||
样，包括整型、浮点型、布尔型以及字符串等。随着时间的积累，存储的数据将持续增长。以智能电表为例，其中的 current、voltage 和 phase 便是典型的采集量。
|
||||
|
||||
### 标签
|
||||
|
||||
标签是指附着在传感器、设备或其他类型采集点上的静态属性，这些属性不会随时间发生变化，例如设备型号、颜色、设备所在地等。标签的数据类型可以是任意类型。尽管标签本身是静态的，但在实际应用中，用户可能需要对标签进行修改、删除或添加。与采集量不同，随着时间的推移，存储的标签数据量保持相对稳定，不会呈现明显的增长趋势。在智能电表的示例中，location（位置）和 Group ID（分组 ID）就是典型的标签。
|
||||
标签是指附着在传感器、设备或其他类型采集点上的静态属性，这些属性不会随时间发生变化，例如设备型号、颜色、设备所在地等。标签的数据类型可以是任意类型。尽管标签本身是静态的，但在实际应用中，用户可能需要对标签进行修改、删除或添加。与采集量不同，随着时间的推移，存储的标签数据量保持相对稳定，不会呈现明显的增长趋势。在智能电表的示例中，location 和 Group ID 就是典型的标签。
|
||||
|
||||
### 数据采集点
|
||||
|
||||
|
|
@ -49,9 +49,9 @@ toc_max_heading_level: 4
|
|||
|
||||
4. 一个数据块内部，采用列式存储，对于不同的数据类型，可以采用不同压缩算法来提高压缩率。并且，由于采集量的变化通常是缓慢的，压缩率会更高。
|
||||
|
||||
如果采用传统的方式，将多个数据采集点的数据写入一张表，由于网络延时不可控，不同数据采集点的数据到达服务器的时序是无法保证的，写入操作是要有锁保护的，而且一个数据采集点的数据是难以保证连续存储在一起的。采用一个数据采集点一张表的方式，能最大程度的保证单个数据采集点的插入和查询的性能是最优的，，而且数据压缩率最高。
|
||||
如果采用传统的方式，将多个数据采集点的数据写入一张表，由于网络延时不可控，不同数据采集点的数据到达服务器的时序是无法保证的，写入操作是要有锁保护的，而且一个数据采集点的数据是难以保证连续存储在一起的。采用一个数据采集点一张表的方式，能最大程度的保证单个数据采集点的插入和查询的性能是最优的，而且数据压缩率最高。
|
||||
|
||||
在 TDengine 中，通常使用数据采集点的名称（如：d1001）来做表名，每个数据采集点可以有多个采集量（如：current、voltage、phase 等），每个采集量对应一张表的一列。采集量的数据类型可以是整型、浮点型、字符串等。
|
||||
在 TDengine 中，通常使用数据采集点的名称（如 d1001）来做表名，每个数据采集点可以有多个采集量（如 current、voltage、phase 等），每个采集量对应一张表的一列。采集量的数据类型可以是整型、浮点型、字符串等。
|
||||
|
||||
此外，表的第一列必须是时间戳，即数据类型为 Timestamp。对于每个采集量，TDengine 将使用第一列时间戳建立索引，采用列式存储。对于复杂的设备，比如汽车，它有多个数据采集点，则需要为一辆汽车建立多张表。
|
||||
|
||||
|
|
@ -86,12 +86,12 @@ toc_max_heading_level: 4
|
|||
### 时间戳
|
||||
|
||||
时间戳在时序数据处理中扮演着至关重要的角色，特别是在应用程序需要从多个不同时区访问数据库时，这一问题变得更加复杂。在深入了解 TDengine 如何处理时间戳与时区之前，我们先介绍以下几个基本概念。
|
||||
- 本地日期时间：指特定地区的当地时间，通常表示为 yyyy-MM-dd hh:mm:ss.SSS 格 式 的 字 符 串。 这 种 时 间 表 示 不 包 含 任 何 时 区 信 息， 如“2021-07-21 12:00:00.000”。
|
||||
- 时区：地球上不同地理位置的标准时间。协调世界时（Universal Time Coordinated，UTC）或格林尼治时间是国际时间标准，其他时区通常表示为相对于 UTC 的偏移量，如“UTC+8”代表东八区时间。 UTC 时间戳：表示自 UNIX 纪 元（即 UTC 时 间 1970 年 1 月 1 日 0 点） 起 经 过的毫秒数。例如，“1700000000000”对应的日期时间是“2023-11-14 22:13:20（UTC+0）”。 在 TDengine 中保存时序数据时，实际上保存的是 UTC 时间戳。TDengine 在写入数据时，时间戳的处理分为如下两种情况。
|
||||
- RFC-3339 格式：当使用这种格式时，TDengine 能够正确解析带有时区信息的时间字符串为 UTC 时间戳。例如，“2018-10-03T14:38:05.000+08:00”会被转换为UTC 时间戳。
|
||||
- 本地日期时间：指特定地区的当地时间，通常表示为 yyyy-MM-dd hh:mm:ss.SSS 格式的字符串。这种时间表示不包含任何时区信息，如 “2021-07-21 12:00:00.000”。
|
||||
- 时区：地球上不同地理位置的标准时间。协调世界时（Universal Time Coordinated，UTC）或格林尼治时间是国际时间标准，其他时区通常表示为相对于 UTC 的偏移量，如 “UTC+8” 代表东八区时间。 UTC 时间戳：表示自 UNIX 纪元（即 UTC 时间 1970 年 1 月 1 日 0 点）起经过的毫秒数。例如，“1700000000000” 对应的日期时间是 “2023-11-14 22:13:20（UTC+0）”。 在 TDengine 中保存时序数据时，实际上保存的是 UTC 时间戳。TDengine 在写入数据时，时间戳的处理分为如下两种情况。
|
||||
- RFC-3339 格式：当使用这种格式时，TDengine 能够正确解析带有时区信息的时间字符串为 UTC 时间戳。例如，“2018-10-03T14:38:05.000+08:00” 会被转换为 UTC 时间戳。
|
||||
- 非 RFC-3339 格式：如果时间字符串不包含时区信息，TDengine 将使用应用程序所在的时区设置自动将时间转换为 UTC 时间戳。
|
||||
|
||||
在查询数据时，TDengine 客户端会根据应用程序当前的时区设置，自动将保存的UTC 时间戳转换成本地时间进行显示，确保用户在不同时区下都能看到正确的时间信息。
|
||||
在查询数据时，TDengine 客户端会根据应用程序当前的时区设置，自动将保存的 UTC 时间戳转换成本地时间进行显示，确保用户在不同时区下都能看到正确的时间信息。
|
||||
|
||||
## 数据建模
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ CREATE DATABASE power PRECISION 'ms' KEEP 3650 DURATION 10 BUFFER 16;
|
|||
- `DURATION 10` ：每 10 天的数据放在一个数据文件中
|
||||
- `BUFFER 16` ：写入使用大小为 16MB 的内存池。
|
||||
|
||||
在创建power数据库后，可以执行 USE 语句来使用切换数据库。
|
||||
在创建 power 数据库后，可以执行 USE 语句来使用切换数据库。
|
||||
|
||||
```sql
|
||||
use power;
|
||||
|
|
@ -134,10 +134,10 @@ CREATE STABLE meters (
|
|||
|
||||
在 TDengine 中，创建超级表的 SQL 语句与关系型数据库类似。例如，上面的 SQL 中，`CREATE STABLE` 为关键字，表示创建超级表；接着，`meters` 是超级表的名称；在表名后面的括号中，定义超级表的列（列名、数据类型等），规则如下：
|
||||
|
||||
1. 第 1 列必须为时间戳列。例如：`ts timestamp` 表示，时间戳列名是 `t`s，数据类型为 `timestamp`；
|
||||
2. 从第 2 列开始是采集量列。采集量的数据类型可以为整型、浮点型、字符串等。例如：`current float` 表示，采集量电流 `current`，数据类型为 `float`；
|
||||
1. 第 1 列必须为时间戳列。例如：`ts timestamp` 表示，时间戳列名是 `ts`，数据类型为 `timestamp`；
|
||||
2. 第 2 列开始是采集量列。采集量的数据类型可以为整型、浮点型、字符串等。例如：`current float` 表示，采集量电流 `current`，数据类型为 `float`。
|
||||
|
||||
最后，TAGS是关键字，表示标签，在 TAGS 后面的括号中，定义超级表的标签（标签名、数据类型等）。
|
||||
最后，TAGS 是关键字，表示标签，在 TAGS 后面的括号中，定义超级表的标签（标签名、数据类型等）。
|
||||
1. 标签的数据类型可以为整型、浮点型、字符串等。例如：`location varchar(64)` 表示，标签地区 `location`，数据类型为 `varchar(64)`；
|
||||
2. 标签的名称不能与采集量列的名称相同。
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ USING meters (
|
|||
);
|
||||
```
|
||||
|
||||
上面的 SQL 中，`CREATE TABLE` 为关键字，表示创建表；`d1001` 是子表的名称；`USING` 是关键字，表示要使用超级表作为模版；`meters` 是超级表的名称；在超级表名后的括号中，`location`, `group_id` 表示，是超级表的标签列名列表；`TAGS` 是关键字，在后面的括号中指定子表的标签列的值。`"California.SanFrancisco"` 和 `2` 表示子表 `d1001` 的位置为 `California.SanFrancisco`，分组 ID 为 `2` 。
|
||||
上面的 SQL 中，`CREATE TABLE` 为关键字，表示创建表；`d1001` 是子表的名称；`USING` 是关键字，表示要使用超级表作为模版；`meters` 是超级表的名称；在超级表名后的括号中，`location`、`group_id` 表示，是超级表的标签列名列表；`TAGS` 是关键字，在后面的括号中指定子表的标签列的值。`"California.SanFrancisco"` 和 `2` 表示子表 `d1001` 的位置为 `California.SanFrancisco`，分组 ID 为 `2`。
|
||||
|
||||
当对超级表进行写入或查询操作时，用户可以使用伪列 tbname 来指定或输出对应操作的子表名。
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ TAGS (
|
|||
);
|
||||
```
|
||||
|
||||
上面的 SQL 中，`INSERT INTO d1002` 表示，向子表 `d1002` 中写入数据；`USING meters` 表示，使用超级表 `meters` 作为模版；`TAGS ("California.SanFrancisco", 2)` 表示，子表 `d1002` 的标签值分别为 `California.SanFrancisco` 和 `2`；`VALUES (NOW, 10.2, 219, 0.32)` 表示，向子表 `d1002` 插入一行记录，值分别为NOW（当前时间戳）、10.2（电流）、219（电压）、0.32（相位）。在 TDengine 执行这条 SQL 时，如果子表 `d1002` 已经存在，则直接写入数据；当子表 `d1002` 不存在，会先自动创建子表，再写入数据。
|
||||
上面的 SQL 中，`INSERT INTO d1002` 表示，向子表 `d1002` 中写入数据；`USING meters` 表示，使用超级表 `meters` 作为模版；`TAGS ("California.SanFrancisco", 2)` 表示，子表 `d1002` 的标签值分别为 `California.SanFrancisco` 和 `2`；`VALUES (NOW, 10.2, 219, 0.32)` 表示，向子表 `d1002` 插入一行记录，值分别为 NOW（当前时间戳）、10.2（电流）、219（电压）、0.32（相位）。在 TDengine 执行这条 SQL 时，如果子表 `d1002` 已经存在，则直接写入数据；当子表 `d1002` 不存在，会先自动创建子表，再写入数据。
|
||||
|
||||
### 创建普通表
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ CREATE TABLE d1003(
|
|||
);
|
||||
```
|
||||
|
||||
上面的 SQL 表示，创建普通表 `d1003` ，表结构包括 `ts`、`current`、`voltage`、`phase`、`location`、`group_id`，共 6 个列。这样的数据模型，与关系型数据库完全一致。
|
||||
上面的 SQL 表示，创建普通表 `d1003`，表结构包括 `ts`、`current`、`voltage`、`phase`、`location`、`group_id`，共 6 个列。这样的数据模型，与关系型数据库完全一致。
|
||||
|
||||
采用普通表作为数据模型意味着静态标签数据（如 location 和 group_id）会重复存储在表的每一行中。这种做法不仅增加了存储空间的消耗，而且在进行查询时，由于无法直接利用标签数据进行过滤，查询性能会显著低于使用超级表的数据模型。
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,9 @@ toc_max_heading_level: 4
|
|||
|
||||
### 一次写入一条
|
||||
|
||||
假设设备 ID 为 d1001 的智能电表在 2018 年 10 月 3 日 14:38:05 采集到数据：电流10.3A，电压 219V，相位 0.31。在第 3 章中，我们已经在 TDengine 的 power 数据库中创建了属于超级表 meters 的子表 d1001。接下来可以通过下面的 insert 语句在子表 d1001 中写入时序数据。
|
||||
假设设备 ID 为 d1001 的智能电表在 2018 年 10 月 3 日 14:38:05 采集到数据：电流 10.3A，电压 219V，相位 0.31。在第 3 章中，我们已经在 TDengine 的 power 数据库中创建了属于超级表 meters 的子表 d1001。接下来可以通过下面的 insert 语句在子表 d1001 中写入时序数据。
|
||||
|
||||
1. 可以通过下面的 INSERT 语句向子表d1001中写入时序数据。
|
||||
1. 可以通过下面的 INSERT 语句向子表 d1001 中写入时序数据。
|
||||
|
||||
```sql
|
||||
insert into d1001 (ts, current, voltage, phase) values ( "2018-10-03 14:38:05", 10.3, 219, 0.31)
|
||||
|
|
@ -120,7 +120,7 @@ values( "d1001, "2018-10-03 14:38:05", 10.2, 220, 0.23, "California.SanFrancisco
|
|||
|
||||
## 更新
|
||||
|
||||
可以通过写入重复时间戳的一条数据来更新时序数据，新写入的数据会替换旧值。 下面的 SQL，通过指定列的方式，向子表 `d1001` 中写入 1 行数据；当子表 `d1001` 中已经存在日期时间为 `2018-10-03 14:38:05` 的数据时，`current`（电流）的新值22，会替换旧值。
|
||||
可以通过写入重复时间戳的一条数据来更新时序数据，新写入的数据会替换旧值。下面的 SQL，通过指定列的方式，向子表 `d1001` 中写入 1 行数据；当子表 `d1001` 中已经存在日期时间为 `2018-10-03 14:38:05` 的数据时，`current`（电流）的新值 22，会替换旧值。
|
||||
|
||||
```sql
|
||||
INSERT INTO d1001 (ts, current) VALUES ("2018-10-03 14:38:05", 22);
|
||||
|
|
@ -128,7 +128,7 @@ INSERT INTO d1001 (ts, current) VALUES ("2018-10-03 14:38:05", 22);
|
|||
|
||||
## 删除
|
||||
|
||||
为方便用户清理由于设备故障等原因产生的异常数据，TDengine 支持根据时间戳删除时序数据。 下面的 SQL，将超级表 `meters` 中所有时间戳早于 `2021-10-01 10:40:00.100` 的数据删除。数据删除后不可恢复，请慎重使用。为了确保删除的数据确实是自己要删除的，建议可以先使用 select 语句加 where 后的删除条件查看要删除的数据内容，确认无误后再执行 delete 。
|
||||
为方便用户清理由于设备故障等原因产生的异常数据，TDengine 支持根据时间戳删除时序数据。下面的 SQL，将超级表 `meters` 中所有时间戳早于 `2021-10-01 10:40:00.100` 的数据删除。数据删除后不可恢复，请慎重使用。为了确保删除的数据确实是自己要删除的，建议可以先使用 select 语句加 where 后的删除条件查看要删除的数据内容，确认无误后再执行 delete 。
|
||||
|
||||
```sql
|
||||
delete from meters where ts < '2021-10-01 10:40:00.100' ;
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ toc_max_heading_level: 4
|
|||
taosBenchmark --start-timestamp=1600000000000 --tables=100 --records=10000000 --time-step=10000
|
||||
```
|
||||
|
||||
上面的命令，taosBenchmark 工具在 TDengine 中生成了一个用于测试的数据库，产生共 10 亿条时序数据。时序数据的时间戳从 `1600000000000`（2020-09-13T20:26:40+08:00）开始，包含 `100` 个设备（子表），每个设备有 `10000000` 条数据，时序数据的采集频率是 10 秒/ 条。
|
||||
上面的命令，taosBenchmark 工具在 TDengine 中生成了一个用于测试的数据库，产生共 10 亿条时序数据。时序数据的时间戳从 `1600000000000`（2020-09-13T20:26:40+08:00）开始，包含 `100` 个设备（子表），每个设备有 `10000000` 条数据，时序数据的采集频率是 10 秒/条。
|
||||
|
||||
在 TDengine 中，用户可以通过 WHERE 语句指定条件，查询时序数据。以智能电表的数据为例
|
||||
|
||||
|
|
@ -74,22 +74,22 @@ GROUP BY groupid;
|
|||
Query OK, 10 row(s) in set (0.042446s)
|
||||
```
|
||||
|
||||
**注意**: group by 子句在聚合数据时，并不保证结果集按照特定顺序排列。为了获得有序的结果集，可以使用 order by 子句对结果进行排序。这样，可以根据需要调整输出结果的顺序，以满足特定的业务需求或报告要求。
|
||||
**注意**：group by 子句在聚合数据时，并不保证结果集按照特定顺序排列。为了获得有序的结果集，可以使用 order by 子句对结果进行排序。这样，可以根据需要调整输出结果的顺序，以满足特定的业务需求或报告要求。
|
||||
|
||||
TDengine 提供了多种内置的聚合函数。如下表所示：
|
||||
|
||||
| 聚合函数 | 功能说明 |
|
||||
|:----------------------:|:--------------------------------------------------------------:|
|
||||
|APERCENTILE | 统计表/超级表中指定列的值的近似百分比分位数，与 PERCENTILE 函数相似，但是返回近似结果。 |
|
||||
|AVG | 统计指定字段的平均值 |
|
||||
|COUNT | 统计指定字段的记录行数 |
|
||||
|APERCENTILE | 统计表/超级表中指定列的值的近似百分比分位数，与 PERCENTILE 函数相似，但是返回近似结果。|
|
||||
|AVG | 统计指定字段的平均值。|
|
||||
|COUNT | 统计指定字段的记录行数。|
|
||||
|ELAPSED|elapsed 函数表达了统计周期内连续的时间长度，和 twa 函数配合使用可以计算统计曲线下的面积。在通过 INTERVAL 子句指定窗口的情况下，统计在给定时间范围内的每个窗口内有数据覆盖的时间范围；如果没有 INTERVAL 子句，则返回整个给定时间范围内的有数据覆盖的时间范围。注意，ELAPSED 返回的并不是时间范围的绝对值，而是绝对值除以 time_unit 所得到的单位个数。|
|
||||
|LEASTSQUARES | 统计表中某列的值的拟合直线方程。start_val 是自变量初始值，step_val 是自变量的步长值。 |
|
||||
|LEASTSQUARES | 统计表中某列的值的拟合直线方程。start_val 是自变量初始值，step_val 是自变量的步长值。|
|
||||
|SPREAD | 统计表中某列的最大值和最小值之差。|
|
||||
|STDDEV | 统计表中某列的均方差。 |
|
||||
|SUM | 统计表/超级表中某列的和。 |
|
||||
|HYPERLOGLOG | 采用 hyperloglog 算法，返回某列的基数。该算法在数据量很大的情况下，可以明显降低内存的占用，求出来的基数是个估算值，标准误差（标准误差是多次实验，每次的平均数的标准差，不是与真实结果的误差）为 0.81%。在数据量较少的时候该算法不是很准确，可以使用 select count（data） from （select unique（col） as data from table） 的方法。 |
|
||||
|HISTOGRAM | 统计数据按照用户指定区间的分布。 |
|
||||
|STDDEV | 统计表中某列的均方差。|
|
||||
|SUM | 统计表/超级表中某列的和。|
|
||||
|HYPERLOGLOG | 采用 hyperloglog 算法，返回某列的基数。该算法在数据量很大的情况下，可以明显降低内存的占用，求出来的基数是个估算值，标准误差（标准误差是多次实验，每次的平均数的标准差，不是与真实结果的误差）为 0.81%。在数据量较少的时候该算法不是很准确，可以使用 select count(data) from (select unique(col) as data from table) 的方法。|
|
||||
|HISTOGRAM | 统计数据按照用户指定区间的分布。|
|
||||
|PERCENTILE | 统计表中某列的值百分比分位数。|
|
||||
|
||||
## 数据切分查询
|
||||
|
|
@ -101,12 +101,12 @@ PARTITION BY part_list
|
|||
|
||||
`part_list` 可以是任意的标量表达式，包括列、常量、标量函数和它们的组合。
|
||||
|
||||
TDengine 按如下方式处理数据切分子句。
|
||||
TDengine 按如下方式处理数据切分子句：
|
||||
1. 数据切分子句位于 WHERE 子句之后；
|
||||
2. 数据切分子句将表数据按指定的维度进行切分，每个切分的分片进行指定的计算。计算由之后的子句定义（窗口子句、GROUP BY 子句或 SELECT 子句）；
|
||||
3. 数据切分子句可以和窗口切分子句（或 GROUP BY 子句）一起使用，此时后面的子句作用在每个切分的分片上。
|
||||
|
||||
数据切分的 SQL 如下：s
|
||||
数据切分的 SQL 如下：
|
||||
|
||||
```sql
|
||||
SELECT location, avg(voltage)
|
||||
|
|
@ -141,6 +141,7 @@ Query OK, 10 row(s) in set (2.415961s)
|
|||
- 状态窗口（status window）
|
||||
- 会话窗口（session window）
|
||||
- 事件窗口（event window）
|
||||
- 计数窗口（count window）
|
||||
|
||||
窗口划分逻辑如下图所示：
|
||||
|
||||
|
|
@ -152,14 +153,15 @@ Query OK, 10 row(s) in set (2.415961s)
|
|||
window_clause: {
|
||||
SESSION(ts_col, tol_val)
|
||||
| STATE_WINDOW(col)
|
||||
| INTERVAL(interval_val [, interval_offset]) [SLIDING (sliding_val)] [FILL(fill_mod_and_val)]
|
||||
| INTERVAL(interval_val [, interval_offset]) [SLIDING (sliding_val)] [WATERMARK(watermark_val)] [FILL(fill_mod_and_val)]
|
||||
| EVENT_WINDOW START WITH start_trigger_condition END WITH end_trigger_condition
|
||||
| COUNT_WINDOW(count_val[, sliding_val])
|
||||
}
|
||||
```
|
||||
|
||||
**注意** 在使用窗口子句时应注意以下规则：
|
||||
1. 窗口子句位于数据切分子句之后，不可以和 GROUP BY 子句一起使用。
|
||||
2. 窗口子句将数据按窗口进行切分，对每个窗口进行 SELECT 列表中的表达式的计算，SELECT 列表中的表达式只能包含：常量；伪列：_wstart 伪列、_wend 伪列和 _wduration 伪列；聚合函数（包括选择函数和可以由参数确定输出行数的时序特有函数）
|
||||
2. 窗口子句将数据按窗口进行切分，对每个窗口进行 SELECT 列表中的表达式的计算，SELECT 列表中的表达式只能包含：常量；伪列：_wstart、_wend 和 _wduration；聚合函数：包括选择函数和可以由参数确定输出行数的时序特有函数。
|
||||
3. WHERE 语句可以指定查询的起止时间和其他过滤条件。
|
||||
|
||||
### 时间戳伪列
|
||||
|
|
@ -177,16 +179,15 @@ INTERVAL(interval_val [, interval_offset])
|
|||
```
|
||||
|
||||
时间窗口子句包括 3 个子句：
|
||||
- INTERVAL 子句：用于产生相等时间周期的窗口，interval_val 指定每个时间窗口的大小，interval_offset 指定；
|
||||
- INTERVAL 子句：用于产生相等时间周期的窗口，interval_val 指定每个时间窗口的大小，interval_offset 指定窗口偏移量；
|
||||
- SLIDING 子句：用于指定窗口向前滑动的时间；
|
||||
- FILL：用于指定窗口区间数据缺失的情况下，数据的填充模式。
|
||||
|
||||
对于时间窗口，interval_val 和 sliding_val 都表示时间段， 语法上支持三种方式。例如：
|
||||
1. INTERVAL(1s, 500a) SLIDING(1s)，带时间单位的形式，其中的时间单位是单字符表示， 分别为： a （毫秒）， b （纳秒）， d （天）， h （小时）， m （分钟）， n （月）， s （秒）， u （微秒）， w （周）， y （年）；
|
||||
对于时间窗口，interval_val 和 sliding_val 都表示时间段，语法上支持三种方式。例如：
|
||||
1. INTERVAL(1s, 500a) SLIDING(1s)，带时间单位的形式，其中的时间单位是单字符表示，分别为：a（毫秒）、b（纳秒），d（天）、h（小时）、m（分钟）、n（月）、s（秒）、u（微秒）、w（周）、y（年）；
|
||||
2. INTERVAL(1000, 500) SLIDING(1000)，不带时间单位的形式，将使用查询库的时间精度作为默认时间单位，当存在多个库时默认采用精度更高的库；
|
||||
3. INTERVAL('1s', '500a') SLIDING('1s')，带时间单位的字符串形式，字符串内部不能有任何空格等其它字符。
|
||||
|
||||
|
||||
示例 SQL 如下：
|
||||
```sql
|
||||
SELECT tbname, _wstart, _wend, avg(voltage)
|
||||
|
|
@ -220,7 +221,7 @@ Query OK, 12 row(s) in set (0.021265s)
|
|||
|
||||
#### 滑动窗口
|
||||
|
||||
每次执行的查询是一个时间窗口，时间窗口随着时间流动向前滑动。在定义连续查询的时候需要指定时间窗口（time window ）大小和每次前向增量时间（forward sliding times）。如下图，[t0s， t0e] ，[t1s ， t1e]， [t2s， t2e] 是分别是执行三次连续查询的时间窗口范围，窗口的前向滑动的时间范围 sliding time 标识 。查询过滤、聚合等操作按照每个时间窗口为独立的单位执行。
|
||||
每次执行的查询是一个时间窗口，时间窗口随着时间流动向前滑动。在定义连续查询的时候需要指定时间窗口（time window ）大小和每次前向增量时间（forward sliding times）。如下图，[t0s, t0e]、[t1s, t1e]、[t2s, t2e] 是分别是执行三次连续查询的时间窗口范围，窗口的前向滑动的时间范围 sliding time 标识。查询过滤、聚合等操作按照每个时间窗口为独立的单位执行。
|
||||
|
||||
|
||||
|
||||
|
|
@ -238,7 +239,7 @@ SELECT COUNT(*) FROM temp_tb_1 INTERVAL(1m) SLIDING(2m);
|
|||
|
||||
**使用时间窗口需要注意**
|
||||
1. 聚合时间段的窗口宽度由关键词 INTERVAL 指定，最短时间间隔 10 毫秒（10a）；并且支持偏移 offset（偏移必须小于间隔），也即时间窗口划分与“UTC 时刻 0”相比的偏移量。SLIDING 语句用于指定聚合时间段的前向增量，也即每次窗口向前滑动的时长。
|
||||
2. 使用 INTERVAL 语句时，除非极特殊的情况，都要求把客户端和服务端的 taos.cfg 配置文件中的 timezone 参数配置为相同的取值，以避免时间处理函数频繁进行跨时区转换而导致的严重性能影响。
|
||||
2. 使用 INTERVAL 语句时，除非极特殊的情况，都要求把客户端和服务端的 timezone 参数配置为相同的取值，以避免时间处理函数频繁进行跨时区转换而导致的严重性能影响。
|
||||
3. 返回的结果中时间序列严格单调递增。
|
||||
|
||||
示例：
|
||||
|
|
@ -274,7 +275,7 @@ Query OK, 11 row(s) in set (0.013153s)
|
|||
|
||||
#### 翻转窗口
|
||||
|
||||
当 SLIDING 与 INTERVAL 相等的时候，滑动窗口即为翻转窗口。翻转窗口和滑动窗口的区别在于，滑动窗口因为 interval_val 和 sliding_val 不同，不同时间窗口之间，会存在数据重叠，翻转窗口则没有数据重叠。本质上，翻转窗口就是按照 interval_val 进行了时间窗口划分，INTERVAL(1m)和INTERVAL(1m) SLIDING(1m)是等效的。
|
||||
当 SLIDING 与 INTERVAL 相等的时候，滑动窗口即为翻转窗口。翻转窗口和滑动窗口的区别在于，滑动窗口因为 interval_val 和 sliding_val 不同，不同时间窗口之间，会存在数据重叠，翻转窗口则没有数据重叠。本质上，翻转窗口就是按照 interval_val 进行了时间窗口划分，INTERVAL(1m) 和 INTERVAL(1m) SLIDING(1m) 是等效的。
|
||||
|
||||
示例：
|
||||
|
||||
|
|
@ -304,7 +305,7 @@ Query OK, 5 row(s) in set (0.016812s)
|
|||
#### FILL 子句
|
||||
|
||||
1. 不进行填充：NONE（默认填充模式）。
|
||||
2. VALUE 填充：固定值填充，此时需要指定填充的数值。例如：FILL(VALUE, 1.23)。这里需要注意，最终填充的值受由相应列的类型决定，如 FILL(VALUE, 1.23)，相应列为 INT 类型，则填充值为 1, 若查询列表中有多列需要 FILL, 则需要给每一个 FILL 列指定 VALUE, 如 `SELECT _wstart, min(c1), max(c1) FROM ... FILL(VALUE, 0, 0)`, 注意, SELECT 表达式中只有包含普通列时才需要指定 FILL VALUE, 如 `_wstart`, `_wstart+1a`, `now`, `1+1` 以及使用 partition by 时的 partition key (如 tbname)都不需要指定 VALUE, 如 `timediff(last(ts), _wstart)` 则需要指定VALUE。
|
||||
2. VALUE 填充：固定值填充，此时需要指定填充的数值。例如：FILL(VALUE, 1.23)。这里需要注意，最终填充的值受由相应列的类型决定，如 FILL(VALUE, 1.23)，相应列为 INT 类型，则填充值为 1，若查询列表中有多列需要 FILL，则需要给每一个 FILL 列指定 VALUE，如 `SELECT _wstart, min(c1), max(c1) FROM ... FILL(VALUE, 0, 0)`。注意，SELECT 表达式中只有包含普通列时才需要指定 FILL VALUE，如 `_wstart`、`_wstart+1a`、`now`、`1+1` 以及使用 partition by 时的 partition key (如 tbname)都不需要指定 VALUE,，如 `timediff(last(ts), _wstart)` 则需要指定VALUE。
|
||||
3. PREV 填充：使用前一个非 NULL 值填充数据。例如：FILL(PREV)。
|
||||
4. NULL 填充：使用 NULL 填充数据。例如：FILL(NULL)。
|
||||
5. LINEAR 填充：根据前后距离最近的非 NULL 值做线性插值填充。例如：FILL(LINEAR)。
|
||||
|
|
@ -313,11 +314,11 @@ Query OK, 5 row(s) in set (0.016812s)
|
|||
以上填充模式中，除了 NONE 模式默认不填充值之外，其他模式在查询的整个时间范围内如果没有数据 FILL 子句将被忽略，即不产生填充数据，查询结果为空。这种行为在部分模式（PREV、NEXT、LINEAR）下具有合理性，因为在这些模式下没有数据意味着无法产生填充数值。
|
||||
|
||||
对另外一些模式（NULL、VALUE）来说，理论上是可以产生填充数值的，至于需不需要输出填充数值，取决于应用的需求。所以为了满足这类需要强制填充数据或 NULL 的应用的需求，同时不破坏现有填充模式的行为兼容性，TDengine 还支持两种新的填充模式：
|
||||
1. NULL_F: 强制填充 NULL 值
|
||||
2. VALUE_F: 强制填充 VALUE 值
|
||||
1. NULL_F：强制填充 NULL 值
|
||||
2. VALUE_F：强制填充 VALUE 值
|
||||
|
||||
NULL、 NULL_F、 VALUE、 VALUE_F 这几种填充模式针对不同场景区别如下：
|
||||
1. INTERVAL 子句： NULL_F， VALUE_F 为强制填充模式；NULL， VALUE 为非强制模式。在这种模式下下各自的语义与名称相符
|
||||
NULL、NULL_F、VALUE、VALUE_F 这几种填充模式针对不同场景区别如下：
|
||||
1. INTERVAL 子句：NULL_F、VALUE_F 为强制填充模式；NULL、VALUE 为非强制模式。在这种模式下下各自的语义与名称相符
|
||||
2. 流计算中的 INTERVAL 子句：NULL_F 与 NULL 行为相同，均为非强制模式；VALUE_F 与 VALUE 行为相同，均为非强制模式。即流计算中的 INTERVAL 没有强制模式
|
||||
3. INTERP 子句：NULL 与 NULL_F 行为相同，均为强制模式；VALUE 与 VALUE_F 行为相同，均为强制模式。即 INTERP 中没有非强制模式。
|
||||
|
||||
|
|
@ -405,7 +406,7 @@ Query OK, 22 row(s) in set (0.153403s)
|
|||
|
||||
### 会话窗口
|
||||
|
||||
会话窗口根据记录的时间戳主键的值来确定是否属于同一个会话。如下图所示，如果设置时间戳的连续的间隔小于等于 12 秒，则以下 6 条记录构成 2 个会话窗口，分别是：[2019-04-28 14:22:10，2019-04-28 14:22:30]和[2019-04-28 14:23:10，2019-04-28 14:23:30]。因为 2019-04-28 14:22:30 与 2019-04-28 14:23:10 之间的时间间隔是 40 秒，超过了连续时间间隔（12 秒）。
|
||||
会话窗口根据记录的时间戳主键的值来确定是否属于同一个会话。如下图所示，如果设置时间戳的连续的间隔小于等于 12 秒，则以下 6 条记录构成 2 个会话窗口，分别是：[2019-04-28 14:22:10，2019-04-28 14:22:30] 和 [2019-04-28 14:23:10，2019-04-28 14:23:30]。因为 2019-04-28 14:22:30 与 2019-04-28 14:23:10 之间的时间间隔是 40 秒，超过了连续时间间隔（12 秒）。
|
||||
|
||||
|
||||
|
||||
|
|
@ -452,7 +453,7 @@ Query OK, 10 row(s) in set (0.043489s)
|
|||
|
||||
事件窗口无法关闭时，不构成一个窗口，不会被输出。即有数据满足 start_trigger_condition，此时窗口打开，但后续数据都不能满足 end_trigger_condition，这个窗口无法被关闭，这部分数据不够成一个窗口，不会被输出。
|
||||
|
||||
如果直接在超级表上进行事件窗口查询，TDengine 会将超级表的数据汇总成一条时间线，然后进行事件窗口的计算。 如果需要对子查询的结果集进行事件窗口查询，那么子查询的结果集需要满足按时间线输出的要求，且可以输出有效的时间戳列。
|
||||
如果直接在超级表上进行事件窗口查询，TDengine 会将超级表的数据汇总成一条时间线，然后进行事件窗口的计算。如果需要对子查询的结果集进行事件窗口查询，那么子查询的结果集需要满足按时间线输出的要求，且可以输出有效的时间戳列。
|
||||
|
||||
以下面的 SQL 语句为例，事件窗口切分如下图所示。
|
||||
|
||||
|
|
@ -474,7 +475,7 @@ EVENT_WINDOW START WITH voltage >= 225 END WITH voltage < 235
|
|||
LIMIT 5;
|
||||
```
|
||||
|
||||
上面的 SQL，查询超级表meters中，时间戳大于等于2022-01-01T00:00:00+08:00，且时间戳小于2022-01-01T00:10:00+08:00的数据；数据先按照子表名tbname进行数据切分，再根据事件窗口条件：电压大于等于 225V，且小于 235V 进行切分；最后，取每个分片的前 5 行的数据作为结果，返回子表名、窗口开始时间、窗口结束时间、窗口宽度、窗口内数据条数。查询结果如下：
|
||||
上面的 SQL，查询超级表 meters 中，时间戳大于等于 2022-01-01T00:00:00+08:00，且时间戳小于 2022-01-01T00:10:00+08:00 的数据；数据先按照子表名 tbname 进行数据切分，再根据事件窗口条件：电压大于等于 225V，且小于 235V 进行切分；最后，取每个分片的前 5 行的数据作为结果，返回子表名、窗口开始时间、窗口结束时间、窗口宽度、窗口内数据条数。查询结果如下：
|
||||
|
||||
```text
|
||||
tbname | _wstart | _wend | _wduration | count(*) |
|
||||
|
|
@ -529,25 +530,25 @@ Query OK, 10 row(s) in set (0.062794s)
|
|||
|
||||
时序数据特有函数是 TDengine 针对时序数据查询场景专门设计的一组函数。在通用数据库中，要实现类似的功能通常需要编写复杂的查询语句，而且效率较低。为了降低用户的使用成本和简化查询过程，TDengine 将这些功能以内置函数的形式提供，从而实现了高效且易于使用的时序数据处理能力。时序数据特有函数如下表所示。
|
||||
|
||||
| 函数 | 功能说明 |
|
||||
|:---------------:|:--------------------------------------------------------------------:|
|
||||
|CSUM | 累加和（Cumulative sum），忽略 NULL 值。 |
|
||||
|DERIVATIVE | 统计表中某列数值的单位变化率。其中单位时间区间的长度可以通过 time_interval 参数指定，最小可以是 1 秒（1s）；ignore_negative 参数的值可以是 0 或 1，为 1 时表示忽略负值。 |
|
||||
|DIFF | 统计表中某列的值与前一行对应值的差。 ignore_negative 取值为 0|1 ， 可以不填，默认值为 0。 不忽略负值。ignore_negative 为 1 时表示忽略负数。|
|
||||
|IRATE | 计算瞬时增长率。使用时间区间中最后两个样本数据来计算瞬时增长速率；如果这两个值呈递减关系，那么只取最后一个数用于计算，而不是使用二者差值。 |
|
||||
|MAVG | 计算连续 k 个值的移动平均数（moving average）。如果输入行数小于 k，则无结果输出。参数 k 的合法输入范围是 1≤ k ≤ 1000。|
|
||||
|STATECOUNT | 返回满足某个条件的连续记录的个数，结果作为新的一列追加在每行后面。条件根据参数计算，如果条件为 true 则加 1，条件为 false 则重置为 -1，如果数据为 NULL，跳过该条数据。 |
|
||||
| 函数 | 功能说明 |
|
||||
|:------------:|:--------------------------------------------------------------------:|
|
||||
|CSUM | 累加和（Cumulative sum），忽略 NULL 值。|
|
||||
|DERIVATIVE | 统计表中某列数值的单位变化率。其中单位时间区间的长度可以通过 time_interval 参数指定，最小可以是 1 秒（1s）；ignore_negative 参数的值可以是 0 或 1，为 1 时表示忽略负值。|
|
||||
|DIFF | 统计表中某列的值与前一行对应值的差。ignore_negative 取值为 0|1 ，可以不填，默认值为 0。不忽略负值。ignore_negative 为 1 时表示忽略负数。|
|
||||
|IRATE | 计算瞬时增长率。使用时间区间中最后两个样本数据来计算瞬时增长速率；如果这两个值呈递减关系，那么只取最后一个数用于计算，而不是使用二者差值。|
|
||||
|MAVG | 计算连续 k 个值的移动平均数（moving average）。如果输入行数小于 k，则无结果输出。参数 k 的合法输入范围是 1≤ k ≤ 1000。|
|
||||
|STATECOUNT | 返回满足某个条件的连续记录的个数，结果作为新的一列追加在每行后面。条件根据参数计算，如果条件为 true 则加 1，条件为 false 则重置为 -1，如果数据为 NULL，跳过该条数据。|
|
||||
|STATEDURATION | 返回满足某个条件的连续记录的时间长度，结果作为新的一列追加在每行后面。条件根据参数计算，如果条件为 true 则加上两个记录之间的时间长度（第一个满足条件的记录时间长度记为 0），条件为 false 则重置为 -1，如果数据为 NULL，跳过该条数据|
|
||||
|TWA | 时间加权平均函数。统计表中某列在一段时间内的时间加权平均。 |
|
||||
|TWA | 时间加权平均函数。统计表中某列在一段时间内的时间加权平均。|
|
||||
|
||||
## 嵌套查询
|
||||
|
||||
嵌套查询，也称为 subquery（子查询），是指在一个 SQL 中，内层查询的计算结果可以作为外层查询的计算对象来使用。TDengine 支持在 from 子句中使用非关联 subquery。非关联是指 subquery 不会用到父查询中的参数。在 select 查询的 from 子句之后，可以接一个独立的 select 语句，这个 select 语句被包含在英文圆括号内。通过使用嵌套查询，你可以在一个查询中引用另一个查询的结果，从而实现更复杂的数据处理和分析。以智能电表为例进行说明，SQL 如下
|
||||
|
||||
```sql
|
||||
SELECT max(voltage),*
|
||||
SELECT max(voltage), *
|
||||
FROM (
|
||||
SELECT tbname,last_row(ts),voltage,current,phase,groupid,location
|
||||
SELECT tbname, last_row(ts), voltage, current, phase, groupid, location
|
||||
FROM meters
|
||||
PARTITION BY tbname
|
||||
)
|
||||
|
|
@ -559,12 +560,12 @@ GROUP BY groupid;
|
|||
TDengine 的嵌套查询遵循以下规则：
|
||||
1. 内层查询的返回结果将作为“虚拟表”供外层查询使用，此虚拟表建议起别名，以便于外层查询中方便引用。
|
||||
2. 外层查询支持直接通过列名或列名的形式引用内层查询的列或伪列。
|
||||
3. 在内层和外层查询中，都支持普通的表间/超级表间 JOIN。内层查询的计算结果也可以再参与数据子表的 JOIN 操作。
|
||||
3. 在内层和外层查询中，都支持普通表间/超级表间 JOIN。内层查询的计算结果也可以再参与数据子表的 JOIN 操作。
|
||||
4. 内层查询支持的功能特性与非嵌套的查询语句能力是一致的。内层查询的 ORDER BY 子句一般没有意义，建议避免这样的写法以免无谓的资源消耗。
|
||||
5. 与非嵌套的查询语句相比，外层查询所能支持的功能特性存在如下限制：
|
||||
6. 如果内层查询的结果数据未提供时间戳，那么计算过程隐式依赖时间戳的函数在外层会无法正常工作。例如：INTERP， DERIVATIVE， IRATE， LAST_ROW， FIRST， LAST， TWA， STATEDURATION， TAIL， UNIQUE。
|
||||
7. 如果内层查询的结果数据不是按时间戳有序，那么计算过程依赖数据按时间有序的函数在外层会无法正常工作。例如：LEASTSQUARES， ELAPSED， INTERP， DERIVATIVE， IRATE， TWA， DIFF， STATECOUNT， STATEDURATION， CSUM， MAVG， TAIL， UNIQUE。
|
||||
8. 计算过程需要两遍扫描的函数，在外层查询中无法正常工作。例如：此类函数包括：PERCENTILE。
|
||||
6. 如果内层查询的结果数据未提供时间戳，那么计算过程隐式依赖时间戳的函数在外层会无法正常工作。例如：INTERP、DERIVATIVE、IRATE、LAST_ROW、FIRST、LAST、TWA、STATEDURATION、TAIL、UNIQUE。
|
||||
7. 如果内层查询的结果数据不是按时间戳有序，那么计算过程依赖数据按时间有序的函数在外层会无法正常工作。例如：LEASTSQUARES、ELAPSED、INTERP、DERIVATIVE、IRATE、TWA、DIFF、STATECOUNT、STATEDURATION、CSUM、MAVG、TAIL、UNIQUE。
|
||||
8. 计算过程需要两遍扫描的函数，在外层查询中无法正常工作。例如：PERCENTILE。
|
||||
|
||||
## UNION 子句
|
||||
|
||||
|
|
@ -573,11 +574,11 @@ TDengine 支持 UNION 操作符。也就是说，如果多个 SELECT 子句返
|
|||
示例：
|
||||
|
||||
```sql
|
||||
(SELECT tbname,* FROM d1 limit 1)
|
||||
(SELECT tbname, * FROM d1 limit 1)
|
||||
UNION ALL
|
||||
(SELECT tbname,* FROM d11 limit 2)
|
||||
(SELECT tbname, * FROM d11 limit 2)
|
||||
UNION ALL
|
||||
(SELECT tbname,* FROM d21 limit 3);
|
||||
(SELECT tbname, * FROM d21 limit 3);
|
||||
```
|
||||
|
||||
上面的 SQL，分别查询：子表 d1 的 1 条数据，子表 d11 的 2 条数据，子表 d21 的 3 条数据，并将结果合并。返回的结果如下：
|
||||
|
|
@ -594,7 +595,7 @@ UNION ALL
|
|||
Query OK, 6 row(s) in set (0.006438s)
|
||||
```
|
||||
|
||||
在同一个 sql 语句中，最多支持 100 个 UNION 子句。
|
||||
在同一个 SQL 语句中，最多支持 100 个 UNION 子句。
|
||||
|
||||
## 关联查询
|
||||
|
||||
|
|
@ -640,9 +641,9 @@ select a.* from meters a left asof join meters b on timetruncate(a.ts, 1s) < tim
|
|||
|
||||
### 语法说明
|
||||
|
||||
在接下来的内容中，我们将通过统一的方式并行介绍 Left Join 和 Right Join 系列。因此，在后续关于 Outer、Semi、Anti-Semi、ASOF、Window 等系列内容的介绍中，我们采用了“ Left/Right”这种表述方式来同时涵盖 Left Join 和 Right Join 的相关知识。这里的“ /”符号前的描述专指应用于 Left Join，而“ /”符号后的描述则专指应用于 Right Join。通过这种表述方式，我们可以更加清晰地展示这两种 Join 操作的特点和用法。
|
||||
在接下来的内容中，我们将通过统一的方式并行介绍 Left Join 和 Right Join 系列。因此，在后续关于 Outer、Semi、Anti-Semi、ASOF、Window 等系列内容的介绍中，我们采用了“Left/Right”这种表述方式来同时涵盖 Left Join 和 Right Join 的相关知识。这里的“/”符号前的描述专指应用于 Left Join，而“/”符号后的描述则专指应用于 Right Join。通过这种表述方式，我们可以更加清晰地展示这两种 Join 操作的特点和用法。
|
||||
|
||||
例如，当我们提及“左 / 右表”时，对于 Left Join，它特指左表，而对于 Right Join，它则特指右表。同理，当我们提及“右 / 左表”时，对于 Left Join，它特指右表，而对于 Right Join，它则特指左表。
|
||||
例如，当我们提及“左/右表”时，对于 Left Join，它特指左表，而对于 Right Join，它则特指右表。同理，当我们提及“右/左表”时，对于 Left Join，它特指右表，而对于 Right Join，它则特指左表。
|
||||
|
||||
### Join 功能
|
||||
|
||||
|
|
@ -650,13 +651,13 @@ select a.* from meters a left asof join meters b on timetruncate(a.ts, 1s) < tim
|
|||
|
||||
| Join 类型 | 定义 |
|
||||
|:------------------------:|:--------------------------------------------------------:|
|
||||
|Inner Join | 内连接，只有左右表中同时符合连接条件的数据才会被返回，可以视为两张表符合连接条件的数据的交集 |
|
||||
|Left/Right Outer Join | 左 / 右（外）连接，既包含左右表中同时符合连接条件的数据集合，也包括左 / 右表中不符合连接条件的数据集合 |
|
||||
|Left/Right Semi Join | 左 / 右半连接，通常表达的是 in、exists 的含义，即对左 / 右表任意一条数据来说，只有当右 / 左表中存在任一符合连接条件的数据时才返回左 / 右表行数据 |
|
||||
|Inner Join | 内连接，只有左右表中同时符合连接条件的数据才会被返回，可以视为两张表符合连接条件的数据的交集 |
|
||||
|Left/Right Outer Join | 左 / 右（外）连接，既包含左右表中同时符合连接条件的数据集合，也包括左 / 右表中不符合连接条件的数据集合 |
|
||||
|Left/Right Semi Join | 左 / 右半连接，通常表达的是 in、exists 的含义，即对左 / 右表任意一条数据来说，只有当右 / 左表中存在任一符合连接条件的数据时才返回左 / 右表行数据 |
|
||||
|Left/Right Anti-Semi Join | 左 / 右反连接，同左 / 右半连接的逻辑正好相反，通常表达的是 not in、not exists 的含义，即对左 / 右表任意一条数据来说，只有当右 / 左表中不存在任何符合连接条件的数据时才返回左 / 右表行数据 |
|
||||
|left/Right ASOF Join | 左 / 右不完全匹配连接，不同于其他传统 Join 操作的完全匹配模式，ASOF Join 允许以指定的匹配模式进行不完全匹配，即按照主键时间戳最接近的方式进行匹配 |
|
||||
|Left/Right Window Join | 左 / 右窗口连接，根据左 / 右表中每一行的主键时间戳和窗口边界构造窗口并据此进行窗口连接，支持在窗口内进行投影、标量和聚合操作 |
|
||||
|Full Outer Join | 全（外）连接，既包含左右表中同时符合连接条件的数据集合，也包括左右表中不符合连接条件的数据集合 |
|
||||
|left/Right ASOF Join | 左 / 右不完全匹配连接，不同于其他传统 Join 操作的完全匹配模式，ASOF Join 允许以指定的匹配模式进行不完全匹配，即按照主键时间戳最接近的方式进行匹配 |
|
||||
|Left/Right Window Join | 左 / 右窗口连接，根据左 / 右表中每一行的主键时间戳和窗口边界构造窗口并据此进行窗口连接，支持在窗口内进行投影、标量和聚合操作 |
|
||||
|Full Outer Join | 全（外）连接，既包含左右表中同时符合连接条件的数据集合，也包括左右表中不符合连接条件的数据集合 |
|
||||
|
||||
### 约束和限制
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ toc_max_heading_level: 4
|
|||
|
||||
为实现上述功能，TDengine 会为预写数据日志（Write-Ahead Logging，WAL）文件自动创建索引，以支持快速随机访问，并提供了灵活可配置的文件切换与保留机制。用户可以根据需求指定 WAL 文件的保留时间和大小。通过这些方法，WAL 被改造成一个保留事件到达顺序的、可持久化的存储引擎。对于以主题形式创建的查询，TDengine 将从 WAL 读取数据。在消费过程中，TDengine 根据当前消费进度从 WAL 直接读取数据，并使用统一的查询引擎实现过滤、变换等操作，然后将数据推送给消费者。
|
||||
|
||||
从 3.2.0.0 版本开始，数据订阅支持 vnode 迁移和分裂。 由于数据订阅依赖 wal文件，而在 vnode 迁移和分裂的过程中，wal 并不会同步过去，所以迁移或分裂后，之前没消费完的 wal数据后消费不到。所以请保证之前把数据全部消费完后，再进行 vnode 迁移或分裂，否则，消费会丢失数据。
|
||||
从 3.2.0.0 版本开始，数据订阅支持 vnode 迁移和分裂。由于数据订阅依赖 wal 文件，而在 vnode 迁移和分裂的过程中，wal 文件并不会进行同步。因此，在迁移或分裂操作完成后，您将无法继续消费之前尚未消费完 wal 数据。请务必在执行 vnode 迁移或分裂之前，将所有 wal 数据消费完毕。
|
||||
|
||||
## 主题类型
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ CREATE TOPIC [IF NOT EXISTS] topic_name as subquery
|
|||
3. 若发生表结构变更，新增的列不出现在结果中。
|
||||
4. 对于 select *，则订阅展开为创建时所有的列（子表、普通表为数据列，超级表为数据列加标签列）
|
||||
|
||||
假设需要订阅所有智能电表中电压值大于 200 的数据，而且仅仅返回时间戳、电流、电压 3 个采集量（不返回相位），那么可以通过下面的 SQL 创建 power_topic 这个主题。
|
||||
假设需要订阅所有智能电表中电压值大于 200 的数据，且仅仅返回时间戳、电流、电压 3 个采集量（不返回相位），那么可以通过下面的 SQL 创建 power_topic 这个主题。
|
||||
```sql
|
||||
CREATE TOPIC power_topic AS SELECT ts, current, voltage FROM power.meters WHERE voltage > 200;
|
||||
```
|
||||
|
|
@ -45,21 +45,21 @@ CREATE TOPIC [IF NOT EXISTS] topic_name [with meta] AS STABLE stb_name [where_co
|
|||
|
||||
与使用 `SELECT * from stbName` 订阅的区别是：
|
||||
|
||||
1. 不会限制用户的表结构变更，即表结构变更以及变更后的新数据都能够订阅到
|
||||
1. 不会限制用户的表结构变更，即表结构变更以及变更后的新数据都能够订阅到。
|
||||
2. 返回的是非结构化的数据，返回数据的结构会随着超级表的表结构变化而变化。
|
||||
3. with meta 参数可选，选择时将返回创建超级表，子表等语句，主要用于 taosx 做超级表迁移。
|
||||
4. where_condition 参数可选，选择时将用来过滤符合条件的子表，订阅这些子表。where 条件里不能有普通列，只能是 tag 或 tbname，where 条件里可以用函数，用来过滤 tag，但是不能是聚合函数，因为子表 tag 值无法做聚合。也可以是常量表达式，比如 2 > 1（订阅全部子表），或者 false（订阅 0 个子表）。
|
||||
3. with meta 参数可选，选择时将返回创建超级表，子表等语句，主要用于 taosX 做超级表迁移。
|
||||
4. where_condition 参数可选，选择时将用来过滤符合条件的子表，订阅这些子表。where 条件里不能有普通列，只能是 tag 或 tbname，where 条件里可以用函数，用来过滤 tag，但是不能是聚合函数，因为子表 tag 值无法做聚合。可以是常量表达式，比如 2 > 1（订阅全部子表），或者 false（订阅 0 个子表）。
|
||||
5. 返回数据不包含标签。
|
||||
|
||||
### 数据库主题
|
||||
|
||||
订阅一个数据库里所有数据，其语法如下
|
||||
订阅一个数据库里所有数据，其语法如下：
|
||||
```sql
|
||||
CREATE TOPIC [IF NOT EXISTS] topic_name [with meta] AS DATABASE db_name;
|
||||
```
|
||||
|
||||
通过该语句可创建一个包含数据库所有表数据的订阅
|
||||
1. with meta 参数可选，选择时将返回数据库里所有超级表，子表、普通表的元数据创建、删除、修改语句，主要用于 taosx 做数据库迁移。
|
||||
通过该语句可创建一个包含数据库所有表数据的订阅：
|
||||
1. with meta 参数可选，选择时将返回数据库里所有超级表，子表、普通表的元数据创建、删除、修改语句，主要用于 taosX 做数据库迁移。
|
||||
2. 超级表订阅和库订阅属于高级订阅模式，容易出错，如确实要使用，请咨询技术支持人员。
|
||||
|
||||
## 删除主题
|
||||
|
|
@ -128,7 +128,7 @@ TDengine 的数据订阅功能支持回放（replay）功能，允许用户按
|
|||
2023/09/22 00:00:08.000
|
||||
```
|
||||
|
||||
使用数据订阅的回放功能时需要注意如下几项。
|
||||
使用数据订阅的回放功能时需要注意如下几项：
|
||||
- 数据订阅的回放功能仅查询订阅支持数据回放，超级表和库订阅不支持回放。
|
||||
- 回放不支持进度保存。
|
||||
- 因为数据回放本身需要处理时间，所以回放的精度存在几十毫秒的误差。
|
||||
|
|
|
|||
|
|
@ -29,14 +29,14 @@ TDengine 采用时间驱动的缓存管理策略，将最新数据优先存储
|
|||
|
||||
## TDengine 的读缓存配置
|
||||
|
||||
在创建数据库时，用户可以选择是否启用缓存机制以存储该数据库中每张子表的最新数据。这一缓存机制由数据库创建参数 cachemodel 进行控制。参数 cachemodel 具有如 下 4 种情况：
|
||||
在创建数据库时，用户可以选择是否启用缓存机制以存储该数据库中每张子表的最新数据。这一缓存机制由数据库创建参数 cachemodel 进行控制。参数 cachemodel 具有如下 4 种情况：
|
||||
- none：不缓存
|
||||
- last_row：缓存子表最近一行数据，这将显著改善 last_row 函数的性能
|
||||
- last_value：缓存子表每一列最近的非 NULL 值，这将显著改善无特殊影响（比如 WHERE,ORDER BY,GROUP BY, INTERVAL）时的 last 函数的性能
|
||||
- last_value：缓存子表每一列最近的非 NULL 值，这将显著改善无特殊影响（比如 WHERE、ORDER BY、GROUP BY、INTERVAL）时的 last 函数的性能
|
||||
- both：同时缓存最近的行和列，即等同于上述 cachemodel 值为 last_row 和 last_value 的行为同时生效
|
||||
|
||||
当使用数据库读缓存时，可以使用参数 cachesize 来配置每个 vnode 的内存大小。
|
||||
- cachesize：表示每个 vnode 中用于缓存子表最近数据的内存大小。默认为 1 ，范围是[1，65536]，单位是 MB。需要根据机器内存合理配置。
|
||||
- cachesize：表示每个 vnode 中用于缓存子表最近数据的内存大小。默认为 1，范围是 [1，65536]，单位是 MB。需要根据机器内存合理配置。
|
||||
|
||||
关于数据库的具体创建，相关参数和操作说明请参考[创建数据库](../../reference/taos-sql/database/)
|
||||
|
||||
|
|
@ -48,25 +48,25 @@ TDengine 采用时间驱动的缓存管理策略，将最新数据优先存储
|
|||
# taosBenchmark -d power -Q --start-timestamp=1600000000000 --tables=10000 --records=10000 --time-step=10000 -y
|
||||
```
|
||||
|
||||
上面的命令，taosBenchmark 工具在 TDengine 中生成了一个用于测试的 电表数据库 power，产生共 10 亿条时序数据。时序数据的时间戳从 `1600000000000（2020-09-13T20:26:40+08:00）`开始，超级表为 `meter`s，包含 10000 个设备（子表），每个设备有 10000 条数据，时序数据的采集频率是 10 秒/ 条。
|
||||
上面的命令，taosBenchmark 工具在 TDengine 中生成了一个用于测试的 电表数据库 power，产生共 10 亿条时序数据。时序数据的时间戳从 `1600000000000（2020-09-13T20:26:40+08:00）` 开始，超级表为 `meters`，包含 10000 个设备（子表），每个设备有 10000 条数据，时序数据的采集频率是 10 秒/条。
|
||||
|
||||
查询任意一个电表的最新的电流和时间戳数据，执行如下 SQL
|
||||
|
||||
```sql
|
||||
taos> select last(ts,current) from meters;
|
||||
taos> select last(ts, current) from meters;
|
||||
last(ts) | last(current) |
|
||||
=================================================
|
||||
2020-09-15 00:13:10.000 | 1.1294620 |
|
||||
Query OK, 1 row(s) in set (0.353815s)
|
||||
|
||||
taos> select last_row(ts,current) from meters;
|
||||
taos> select last_row(ts, current) from meters;
|
||||
last_row(ts) | last_row(current) |
|
||||
=================================================
|
||||
2020-09-15 00:13:10.000 | 1.1294620 |
|
||||
Query OK, 1 row(s) in set (0.344070s)
|
||||
```
|
||||
|
||||
希望使用缓存来查询任意一个电表的最新时间戳数据，执行如下 SQL ，并检查数据库的缓存生效。
|
||||
希望使用缓存来查询任意一个电表的最新时间戳数据，执行如下 SQL，并检查数据库的缓存生效。
|
||||
|
||||
```sql
|
||||
taos> alter database power cachemodel 'both' ;
|
||||
|
|
@ -82,13 +82,13 @@ Query OK, 1 row(s) in set (0.000282s)
|
|||
再次查询电表的最新的实时数据，第一次查询会做缓存计算，后续的查询时延就大大缩减。
|
||||
|
||||
```sql
|
||||
taos> select last(ts,current) from meters;
|
||||
taos> select last(ts, current) from meters;
|
||||
last(ts) | last(current) |
|
||||
=================================================
|
||||
2020-09-15 00:13:10.000 | 1.1294620 |
|
||||
Query OK, 1 row(s) in set (0.044021s)
|
||||
|
||||
taos> select last_row(ts,current) from meters;
|
||||
taos> select last_row(ts, current) from meters;
|
||||
last_row(ts) | last_row(current) |
|
||||
=================================================
|
||||
2020-09-15 00:13:10.000 | 1.1294620 |
|
||||
|
|
|
|||
|
|
@ -60,20 +60,20 @@ subquery 支持会话窗口、状态窗口、时间窗口、事件窗口与计
|
|||
|
||||
3. INTERVAL 是时间窗口，又可分为滑动时间窗口和翻转时间窗口。INTERVAL 子句用于指定窗口相等时间周期，SLIDING 字句用于指定窗口向前滑动的时间。当 interval_val 与 sliding_val 相等的时候，时间窗口即为翻转时间窗口，否则为滑动时间窗口，注意：sliding_val 必须小于等于 interval_val。
|
||||
|
||||
4. EVENT_WINDOW 是事件窗口，根据开始条件和结束条件来划定窗口。当 start_trigger_condition 满足时则窗口开始，直到 end_trigger_condition 满足时窗口关闭。 start_trigger_condition 和 end_trigger_condition 可以是任意 TDengine 支持的条件表达式，且可以包含不同的列。
|
||||
4. EVENT_WINDOW 是事件窗口，根据开始条件和结束条件来划定窗口。当 start_trigger_condition 满足时则窗口开始，直到 end_trigger_condition 满足时窗口关闭。start_trigger_condition 和 end_trigger_condition 可以是任意 TDengine 支持的条件表达式，且可以包含不同的列。
|
||||
|
||||
5. COUNT_WINDOW 是计数窗口，按固定的数据行数来划分窗口。 count_val 是常量，是正整数，必须大于等于 2，小于 2147483648。 count_val 表示每个 COUNT_WINDOW 包含的最大数据行数，总数据行数不能整除 count_val 时，最后一个窗口的行数会小于 count_val 。 sliding_val 是常量，表示窗口滑动的数量，类似于 INTERVAL 的 SLIDING 。
|
||||
5. COUNT_WINDOW 是计数窗口，按固定的数据行数来划分窗口。count_val 是常量，是正整数，必须大于等于 2，小于 2147483648。count_val 表示每个 COUNT_WINDOW 包含的最大数据行数，总数据行数不能整除 count_val 时，最后一个窗口的行数会小于 count_val。sliding_val 是常量，表示窗口滑动的数量，类似于 INTERVAL 的 SLIDING 。
|
||||
|
||||
窗口的定义与时序数据窗口查询中的定义完全相同，具体可参考 TDengine 窗口函数部分。
|
||||
|
||||
如下 SQL 将创建一个流计算，执行后 TDengine 会自动创建名为avg_vol 的超级表，此流计算以 1min 为时间窗口、30s 为前向增量统计这些智能电表的平均电压，并将来自 meters 的数据的计算结果写入 avg_vol，不同分区的数据会分别创建子表并写入不同子表。
|
||||
如下 SQL 将创建一个流计算，执行后 TDengine 会自动创建名为 avg_vol 的超级表，此流计算以 1min 为时间窗口、30s 为前向增量统计这些智能电表的平均电压，并将来自 meters 的数据的计算结果写入 avg_vol，不同分区的数据会分别创建子表并写入不同子表。
|
||||
```sql
|
||||
CREATE STREAM avg_vol_s INTO avg_vol AS
|
||||
SELECT _wstart, count(*), avg(voltage) FROM power.meters PARTITION BY tbname INTERVAL(1m) SLIDING(30s);
|
||||
```
|
||||
|
||||
本节涉及的相关参数的说明如下。
|
||||
- stb_name 是保存计算结果的超级表的表名，如果该超级表不存在，则会自动创建；如果已存在，则检查列的 schema 信息。详见 6.3.8 节。
|
||||
- stb_name 是保存计算结果的超级表的表名，如果该超级表不存在，则会自动创建；如果已存在，则检查列的 schema 信息。
|
||||
- tags 子句定义了流计算中创建标签的规则。通过 tags 字段可以为每个分区对应的子表生成自定义的标签值。
|
||||
|
||||
## 流式计算的规则和策略
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ class _MyAnomalyDetectionService(AbstractAnomalyDetectionService):
|
|||
return super().set_params(params)
|
||||
```
|
||||
|
||||
将该文件保存在 `./lib/taosanalytics/algo/ad/` 目录下，然后重启 taosanode 服务。在 TDengine 命令行接口 taos 中执行 `SHOW ANODES FULL` 就能够看到新加入的算法，然后就可以通过 SQL 语句调用该算法。
|
||||
将该文件保存在 `./lib/taosanalytics/algo/ad/` 目录下，然后重启 taosanode 服务。在 TDengine CLI 中执行 `SHOW ANODES FULL` 就能够看到新加入的算法，然后就可以通过 SQL 语句调用该算法。
|
||||
|
||||
```SQL
|
||||
--- 对 col 列进行异常检测，通过指定 algo 参数为 myad 来调用新添加的异常检测类
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ import VerifyLinux from "../../14-reference/05-connector/_verify_linux.mdx";
|
|||
import VerifyMacOS from "../../14-reference/05-connector/_verify_macos.mdx";
|
||||
import VerifyWindows from "../../14-reference/05-connector/_verify_windows.mdx";
|
||||
|
||||
TDengine 提供了丰富的应用程序开发接口，为了便于用户快速开发自己的应用，TDengine 支持了多种编程语言的连接器，其中官方连接器包括支持 C/C++、Java、Python、Go、Node.js、C#、Rust、Lua（社区贡献）和 PHP （社区贡献）的连接器。这些连接器支持使用原生接口（taosc）和 REST 接口（部分语言暂不支持）连接 TDengine 集群。社区开发者也贡献了多个非官方连接器，例如 ADO.NET 连接器、Lua 连接器和 PHP 连接器。另外 TDengine 还可以直接调用 taosadapter 提供的 REST API 接口，进行数据写入和查询操作。
|
||||
TDengine 提供了丰富的应用程序开发接口，为了便于用户快速开发自己的应用，TDengine 支持了多种编程语言的连接器，其中官方连接器包括支持 C/C++、Java、Python、Go、Node.js、C#、Rust、Lua（社区贡献）和 PHP （社区贡献）的连接器。这些连接器支持使用原生接口（taosc）和 REST 接口（部分语言暂不支持）连接 TDengine 集群。社区开发者也贡献了多个非官方连接器，例如 ADO.NET 连接器、Lua 连接器和 PHP 连接器。另外 TDengine 还可以直接调用 taosAdapter 提供的 REST API 接口，进行数据写入和查询操作。
|
||||
|
||||
## 连接方式
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ TDengine 提供了丰富的应用程序开发接口，为了便于用户快速
|
|||
|
||||
|
||||
无论使用何种方式建立连接，连接器都提供了相同或相似的 API 操作数据库，都可以执行 SQL 语句，只是初始化连接的方式稍有不同，用户在使用上不会感到什么差别。
|
||||
各种连接方式和各语言连接器支持情况请参考：[连接器功能特性](../../reference/connector/#功能特性)
|
||||
各种连接方式和各语言连接器支持情况请参考 [连接器功能特性](../../reference/connector/#功能特性)
|
||||
|
||||
关键不同点在于：
|
||||
|
||||
|
|
|
|||
|
|
@ -299,7 +299,7 @@ writer.write(lineDemo, SchemalessProtocolType.LINE, SchemalessTimestampType.NANO
|
|||
|
||||
## 查询写入的数据
|
||||
|
||||
运行上节的样例代码，会在 power 数据库中自动建表，我们可以通过 taos shell 或者应用程序来查询数据。下面给出用 taos shell 查询超级表和 meters 表数据的样例。
|
||||
运行上节的样例代码，会在 power 数据库l中自动建表，我们可以通过 TDengine CLI 或者应用程序来查询数据。下面给出用 TDengine CLI 查询超级表和 meters 表数据的样例。
|
||||
|
||||
```shell
|
||||
taos> show power.stables;
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ import TabItem from "@theme/TabItem";
|
|||
TDengine 提供了类似于消息队列产品的数据订阅和消费接口。在许多场景中，采用 TDengine 的时序大数据平台，无须再集成消息队列产品，从而简化应用程序设计并降低运维成本。本章介绍各语言连接器数据订阅的相关 API 以及使用方法。 数据订阅的基础知识请参考 [数据订阅](../../advanced/subscription/)
|
||||
|
||||
## 创建主题
|
||||
请用 taos shell 或者 参考 [执行 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` 所选择的列组成。
|
||||
|
||||
|
|
|
|||
|
|
@ -5,19 +5,19 @@ description: 让开发者能够快速上手的指南
|
|||
|
||||
开发一个应用，如果你准备采用 TDengine 作为时序数据处理的工具，那么有如下几个事情要做：
|
||||
|
||||
1. 确定应用到 TDengine 的连接方式。无论你使用何种编程语言，你总是可以使用 REST 接口, 但也可以使用每种编程语言独有的连接器进行方便的连接。
|
||||
1. 确定应用到 TDengine 的连接方式。无论你使用何种编程语言，你总是可以使用 REST 接口，但也可以使用每种编程语言独有的连接器进行方便的连接。
|
||||
2. 根据自己的应用场景，确定数据模型。根据数据特征，决定建立一个还是多个库；分清静态标签、采集量，建立正确的超级表，建立子表。
|
||||
3. 决定插入数据的方式。TDengine 支持使用标准的 SQL 写入，但同时也支持 Schemaless 模式写入，这样不用手工建表，可以将数据直接写入。
|
||||
4. 根据业务要求，看需要撰写哪些 SQL 查询语句。
|
||||
5. 如果你要基于时序数据做轻量级的实时统计分析，包括各种监测看板，那么建议你采用 TDengine 3.0 的流式计算功能，而不用额外部署 Spark, Flink 等复杂的流式计算系统。
|
||||
5. 如果你要基于时序数据做轻量级的实时统计分析，包括各种监测看板，那么建议你采用 TDengine 3.0 的流式计算功能，而不用额外部署 Spark、Flink 等复杂的流式计算系统。
|
||||
6. 如果你的应用有模块需要消费插入的数据，希望有新的数据插入时，就能获取通知，那么建议你采用 TDengine 提供的数据订阅功能，而无需专门部署 Kafka 或其他消息队列软件。
|
||||
7. 在很多场景下（如车辆管理），应用需要获取每个数据采集点的最新状态，那么建议你采用 TDengine 的 Cache 功能，而不用单独部署 Redis 等缓存软件。
|
||||
8. 如果你发现 TDengine 的函数无法满足你的要求，那么你可以使用用户自定义函数（UDF）来解决问题。
|
||||
|
||||
本部分内容就是按照上述顺序组织的。为便于理解，TDengine 为每个功能和每个支持的编程语言都提供了示例代码，位于 [示例代码](https://github.com/taosdata/TDengine/tree/main/docs/examples)。所有示例代码都会有 CI 保证正确性，脚本位于 [示例代码 CI](https://github.com/taosdata/TDengine/tree/main/tests/docs-examples-test)。
|
||||
如果你希望深入了解 SQL 的使用，需要查看[SQL 手册](../reference/taos-sql/)。如果想更深入地了解各连接器的使用，请阅读[连接器参考指南](../reference/connector/)。如果还希望想将 TDengine 与第三方系统集成起来，比如 Grafana, 请参考[第三方工具](../third-party/)。
|
||||
如果你希望深入了解 SQL 的使用，需要查看 [SQL 手册](../reference/taos-sql/)。如果想更深入地了解各连接器的使用，请阅读 [连接器参考指南](../reference/connector/)。如果还希望想将 TDengine 与第三方系统集成起来，比如 Grafana，请参考 [第三方工具](../third-party/)。
|
||||
|
||||
如果在开发过程中遇到任何问题，请点击每个页面下方的["反馈问题"](https://github.com/taosdata/TDengine/issues/new/choose), 在 GitHub 上直接递交 Issue。
|
||||
如果在开发过程中遇到任何问题，请点击每个页面下方的 [反馈问题](https://github.com/taosdata/TDengine/issues/new/choose)，在 GitHub 上直接递交 Issue。
|
||||
|
||||
```mdx-code-block
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ RawDataSize = numOfTables × rowSizePerTable × rowsPerTable
|
|||
**技巧** 如何估算 TDengine 压缩率
|
||||
```text
|
||||
用户可以利用性能测试工具 taosBenchmark 来评估 TDengine 的数据压缩效果。通过使用 -f 选项指定写入配置文件，taosBenchmark 可以将指定数量的 CSV 样例数据写入指定的库参数和表结构中。
|
||||
在完成数据写入后，用户可以在 taos shell 中执行 flush database 命令，将所有数据强制写入硬盘。接着，通过 Linux 操作系统的 du 命令获取指定 vnode 的数据文件夹大小。最后，将原始数据大小除以实际存储的数据大小，即可计算出真实的压缩率。
|
||||
在完成数据写入后，用户可以在 TDengine CLI 中执行 flush database 命令，将所有数据强制写入硬盘。接着，通过 Linux 操作系统的 du 命令获取指定 vnode 的数据文件夹大小。最后，将原始数据大小除以实际存储的数据大小，即可计算出真实的压缩率。
|
||||
```
|
||||
|
||||
通过如下命令可以获得 TDengine 占用的存储空间。
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ serverPort 6030
|
|||
|
||||
#### 5. 启动
|
||||
|
||||
按照前述步骤启动第 1 个 dnode，例如 h1.taosdata.com。接着在终端中执行 taos，启动 TDengine 的 CLI 程序 taos，并在其中执行 show dnodes 命令，以查看当前集群中的所有 dnode 信息。
|
||||
按照前述步骤启动第 1 个 dnode，例如 h1.taosdata.com。接着在终端中执行 taos，启动 TDengine CLI 程序 taos，并在其中执行 show dnodes 命令，以查看当前集群中的所有 dnode 信息。
|
||||
|
||||
```shell
|
||||
taos> show dnodes;
|
||||
|
|
@ -71,7 +71,7 @@ taos> show dnodes;
|
|||
|
||||
#### 6. 添加 dnode
|
||||
|
||||
按照前述步骤，在每个物理节点启动 taosd。每个 dnode 都需要在 taos.cfg 文件中将 firstEp 参数配置为新建集群首个节点的 endpoint，在本例中是 h1.taosdata.com:6030。在第 1 个 dnode 所在机器，在终端中运行 taos，打开 TDengine 的 CLI 程序 taos，然后登录TDengine 集群，执行如下 SQL。
|
||||
按照前述步骤，在每个物理节点启动 taosd。每个 dnode 都需要在 taos.cfg 文件中将 firstEp 参数配置为新建集群首个节点的 endpoint，在本例中是 h1.taosdata.com:6030。在第 1 个 dnode 所在机器，在终端中运行 taos，打开 TDengine CLI 程序 taos，然后登录TDengine 集群，执行如下 SQL。
|
||||
|
||||
```shell
|
||||
create dnode "h2.taosdata.com:6030"
|
||||
|
|
@ -86,13 +86,13 @@ show dnodes;
|
|||
在日志中，请确认输出的 dnode 的 fqdn 和端口是否与你刚刚尝试添加的 endpoint 一致。如果不一致，请修正为正确的 endpoint。遵循上述步骤，你可以持续地将新的 dnode 逐个加入集群，从而扩展集群规模并提高整体性能。确保在添加新节点时遵循正确的流程，这有助于维持集群的稳定性和可靠性。
|
||||
|
||||
**Tips**
|
||||
- 任何已经加入集群的 dnode 都可以作为后续待加入节点的 firstEp。firstEp 参数仅仅在该 dnode 首次加入集群时起作用，加入集群后，该 dnode 会保存最新的 mnode 的 endpoint 列表，后续不再依赖这个参数。之后配置文件中的 firstEp 参数主要用于客户端连接，如果没有为 TDengine 的 CLI 设置参数，则默认连接由 firstEp 指定的节点。
|
||||
- 任何已经加入集群的 dnode 都可以作为后续待加入节点的 firstEp。firstEp 参数仅仅在该 dnode 首次加入集群时起作用，加入集群后，该 dnode 会保存最新的 mnode 的 endpoint 列表，后续不再依赖这个参数。之后配置文件中的 firstEp 参数主要用于客户端连接，如果没有为 TDengine CLI 设置参数，则默认连接由 firstEp 指定的节点。
|
||||
- 两个没有配置 firstEp 参数的 dnode 在启动后会独立运行。这时无法将其中一个dnode 加入另外一个 dnode，形成集群。
|
||||
- TDengine 不允许将两个独立的集群合并成新的集群。
|
||||
|
||||
#### 7. 添加 mnode
|
||||
|
||||
在创建 TDengine 集群时，首个 dnode 将自动成为集群的 mnode，负责集群的管理和协调工作。为了实现 mnode 的高可用性，后续添加的 dnode 需要手动创建 mnode。请注意，一个集群最多允许创建 3 个 mnode，且每个 dnode 上只能创建一个 mnode。当集群中的 dnode 数量达到或超过 3 个时，你可以为现有集群创建 mnode。在第 1个 dnode 中，首先通过 TDengine 的 CLI 程序 taos 登录 TDengine，然后执行如下 SQL。
|
||||
在创建 TDengine 集群时，首个 dnode 将自动成为集群的 mnode，负责集群的管理和协调工作。为了实现 mnode 的高可用性，后续添加的 dnode 需要手动创建 mnode。请注意，一个集群最多允许创建 3 个 mnode，且每个 dnode 上只能创建一个 mnode。当集群中的 dnode 数量达到或超过 3 个时，你可以为现有集群创建 mnode。在第 1个 dnode 中，首先通过 TDengine CLI 程序 taos 登录 TDengine，然后执行如下 SQL。
|
||||
|
||||
```shell
|
||||
create mnode on dnode <dnodeId>
|
||||
|
|
|
|||
|
|
@ -203,7 +203,7 @@ toc_max_heading_level: 4
|
|||
通过 “工具” 页面，用户可以了解如下 TDengine 周边工具的使用方法。
|
||||
- TDengine CLI。
|
||||
- taosBenchmark。
|
||||
- taosDump。
|
||||
- taosdump。
|
||||
- TDengine 与 BI 工具的集成，例如 Google Data Studio、Power BI、永洪 BI 等。
|
||||
- TDengine 与 Grafana、Seeq 的集成。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: TDengine CLI 参考手册
|
||||
sidebar_label: taos
|
||||
sidebar_label: TDengine CLI
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
|
|
@ -27,102 +27,103 @@ taos>
|
|||
```
|
||||
|
||||
进入 TDengine CLI 后，可执行各种 SQL 语句，包括插入、查询以及各种管理命令。
|
||||
退出 TDengine CLI， 执行 `q` 或 `quit` 或 `exit` 回车即可
|
||||
退出 TDengine CLI， 执行 `q` 或 `quit` 或 `exit` 回车即可。
|
||||
```shell
|
||||
taos> quit
|
||||
```
|
||||
|
||||
## 命令行参数
|
||||
|
||||
### 常用参数
|
||||
### 基础参数
|
||||
可通过配置命令行参数来改变 TDengine CLI 的行为。以下为常用的几个命令行参数：
|
||||
|
||||
- -h HOST: 要连接的 TDengine 服务端所在服务器的 FQDN, 默认值： 127.0.0.1
|
||||
- -P PORT: 指定服务端所用端口号，默认值：6030
|
||||
- -u USER: 连接时使用的用户名，默认值：root
|
||||
- -p PASSWORD: 连接服务端时使用的密码，特殊字符如 `! & ( ) < > ; |` 需使用字符 `\` 进行转义处理, 默认值：taosdata
|
||||
- -?, --help: 打印出所有命令行参数
|
||||
- -h HOST: 要连接的 TDengine 服务端所在服务器的 FQDN, 默认值： 127.0.0.1 。
|
||||
- -P PORT: 指定服务端所用端口号，默认值：6030 。
|
||||
- -u USER: 连接时使用的用户名，默认值：root 。
|
||||
- -p PASSWORD: 连接服务端时使用的密码，特殊字符如 `! & ( ) < > ; |` 需使用字符 `\` 进行转义处理, 默认值：taosdata 。
|
||||
- -?, --help: 打印出所有命令行参数。
|
||||
- -s COMMAND: 以非交互模式执行的 SQL 命令。
|
||||
|
||||
### 更多参数
|
||||
使用 `-s` 参数可进行非交互式执行 SQL，执行完成后退出，此模式适合在自动化脚本中使用。
|
||||
如以下命令连接到服务器 h1.taos.com, 执行 -s 指定的 SQL:
|
||||
```bash
|
||||
taos -h my-server -s "use db; show tables;"
|
||||
```
|
||||
|
||||
- -a AUTHSTR: 连接服务端的授权信息
|
||||
- -A: 通过用户名和密码计算授权信息
|
||||
- -B: 设置 BI 工具显示模式，设置后所有输出都遵循 BI 工具的格式进行输出
|
||||
- -c CONFIGDIR: 指定配置文件目录，Linux 环境下默认为 `/etc/taos`，该目录下的配置文件默认名称为 `taos.cfg`
|
||||
- -C: 打印 -c 指定的目录中 `taos.cfg` 的配置参数
|
||||
- -d DATABASE: 指定连接到服务端时使用的数据库
|
||||
- -E dsn: 使用 WebSocket DSN 连接云服务或者提供 WebSocket 连接的服务端
|
||||
- -f FILE: 以非交互模式执行 SQL 脚本文件。文件中一个 SQL 语句只能占一行
|
||||
- -k: 测试服务端运行状态，0: unavailable，1: network ok，2: service ok，3: service degraded，4: exiting
|
||||
- -l PKTLEN: 网络测试时使用的测试包大小
|
||||
- -n NETROLE: 网络连接测试时的测试范围，默认为 `client`, 可选值为 `client`、`server`
|
||||
- -N PKTNUM: 网络测试时使用的测试包数量
|
||||
- -r: 将时间列转化为无符号 64 位整数类型输出(即 C 语言中 uint64_t)
|
||||
- -R: 使用 RESTful 模式连接服务端
|
||||
- -s COMMAND: 以非交互模式执行的 SQL 命令
|
||||
- -t: 测试服务端启动状态，状态同-k
|
||||
- -w DISPLAYWIDTH: 客户端列显示宽度
|
||||
- -z TIMEZONE: 指定时区，默认为本地时区
|
||||
- -V: 打印出当前版本号
|
||||
- -c CONFIGDIR: 指定配置文件目录。
|
||||
|
||||
Linux 环境下默认为 `/etc/taos`，该目录下的配置文件默认名称为 `taos.cfg` 。
|
||||
使用 `-c` 参数改变 `taosc` 客户端加载配置文件的位置，客户端配置参数参考 [客户端配置](../../components/taosc) 。
|
||||
以下命令指定了 `taosc` 客户端加载 `/root/cfg/` 下的 `taos.cfg` 配置文件。
|
||||
```bash
|
||||
taos -c /root/cfg/
|
||||
```
|
||||
|
||||
### 非交互式执行
|
||||
### 高级参数
|
||||
|
||||
使用 `-s` 参数可进行非交互式执行 SQL，执行完成后退出，此模式适合在自动化脚本中使用。
|
||||
如以下命令连接到服务器 h1.taos.com, 执行 -s 指定的 SQL:
|
||||
```bash
|
||||
taos -h h1.taos.com -s "use db; show tables;"
|
||||
```
|
||||
- -a AUTHSTR: 连接服务端的授权信息。
|
||||
- -A: 通过用户名和密码计算授权信息。
|
||||
- -B: 设置 BI 工具显示模式，设置后所有输出都遵循 BI 工具的格式进行输出。
|
||||
- -C: 打印 -c 指定的目录中 `taos.cfg` 的配置参数。
|
||||
- -d DATABASE: 指定连接到服务端时使用的数据库。
|
||||
- -E dsn: 使用 WebSocket DSN 连接云服务或者提供 WebSocket 连接的服务端。
|
||||
- -f FILE: 以非交互模式执行 SQL 脚本文件。文件中一个 SQL 语句只能占一行。
|
||||
- -k: 测试服务端运行状态，0: unavailable，1: network ok，2: service ok，3: service degraded，4: exiting 。
|
||||
- -l PKTLEN: 网络测试时使用的测试包大小。
|
||||
- -n NETROLE: 网络连接测试时的测试范围，默认为 `client`, 可选值为 `client`、`server` 。
|
||||
- -N PKTNUM: 网络测试时使用的测试包数量。
|
||||
- -r: 将时间列转化为无符号 64 位整数类型输出(即 C 语言中 uint64_t) 。
|
||||
- -R: 使用 RESTful 模式连接服务端。
|
||||
- -t: 测试服务端启动状态，状态同 -k 。
|
||||
- -w DISPLAYWIDTH: 客户端列显示宽度。
|
||||
- -z TIMEZONE: 指定时区，默认为本地时区。
|
||||
- -V: 打印出当前版本号。
|
||||
|
||||
### taosc 配置文件
|
||||
|
||||
使用 `-c` 参数改变 `taosc` 客户端加载配置文件的位置，客户端配置参数参考 [客户端配置](../../components/taosc)
|
||||
以下命令指定了 `taosc` 客户端加载 `/root/cfg/` 下的 `taos.cfg` 配置文件
|
||||
```bash
|
||||
taos -c /root/cfg/
|
||||
```
|
||||
## 数据导出/导入
|
||||
|
||||
### 数据导出
|
||||
|
||||
- 可以使用符号 “>>” 导出查询结果到某个文件中，语法为： sql 查询语句 >> ‘输出文件名’; 输出文件如果不写路径的话，将输出至当前目录下。如 `select * from d0 >> ‘/root/d0.csv’;` 将把查询结果输出到 /root/d0.csv 中。
|
||||
|
||||
### 数据导入
|
||||
|
||||
- 可以使用 insert into table_name file '输入文件名'，把上一步中导出的数据文件再导入到指定表中。如 `insert into d0 file '/root/d0.csv';` 表示把上面导出的数据全部再导致至 d0 表中。
|
||||
|
||||
## 执行 SQL 脚本
|
||||
|
||||
在 TDengine CLI 里可以通过 `source` 命令来运行脚本文件中的多条 SQL 命令。
|
||||
|
||||
在 TDengine CLI 里可以通过 `source` 命令来运行脚本文件中的多条 SQL 命令，脚本文件中多条 SQL 按行书写即可
|
||||
```sql
|
||||
taos> source <filename>;
|
||||
```
|
||||
|
||||
## 数据导入/导出
|
||||
|
||||
### 导出查询结果
|
||||
## 使用小技巧
|
||||
|
||||
- 可以使用符号 “>>” 导出查询结果到某个文件中，语法为： sql 查询语句 >> ‘输出文件名’; 输出文件如果不写路径的话，将输出至当前目录下。如 select * from d0 >> ‘/root/d0.csv’; 将把查询结果输出到 /root/d0.csv 中。
|
||||
### TAB 键自动补全
|
||||
|
||||
### 数据从文件导入
|
||||
- TAB 键前为空命令状态下按 TAB 键，会列出 TDengine CLI 支持的所有命令。
|
||||
- TAB 键前为空格状态下按 TAB 键，会显示此位置可以出现的所有命令词的第一个，再次按 TAB 键切为下一个。
|
||||
- TAB 键前为字符串，会搜索与此字符串前缀匹配的所有可出现命令词，并显示第一个，再次按 TAB 键切为下一个。
|
||||
- 输入反斜杠 `\` + TAB 键, 会自动补全为列显示模式命令词 `\G;` 。
|
||||
|
||||
- 可以使用 insert into table_name file '输入文件名'，把上一步中导出的数据文件再导入到指定表中。如 insert into d0 file '/root/d0.csv'; 表示把上面导出的数据全部再导致至 d0 表中。
|
||||
|
||||
## 设置字符类型显示宽度
|
||||
|
||||
可以在 TDengine CLI 里使用如下命令调整字符显示宽度
|
||||
### 设置字符列显示宽度
|
||||
|
||||
可以在 TDengine CLI 里使用如下命令调整字符串类型字段列显示宽度，默认显示宽度为 30 个字符。
|
||||
以下命令设置了显示宽度为 120 个字符：
|
||||
```sql
|
||||
taos> SET MAX_BINARY_DISPLAY_WIDTH <nn>;
|
||||
taos> SET MAX_BINARY_DISPLAY_WIDTH 120;
|
||||
```
|
||||
|
||||
如显示的内容后面以 ... 结尾时，表示该内容已被截断，可通过本命令修改显示字符宽度以显示完整的内容。
|
||||
|
||||
## TAB 键自动补全
|
||||
### 其它
|
||||
|
||||
- TAB 键前为空命令状态下按 TAB 键，会列出 TDengine CLI 支持的所有命令
|
||||
- TAB 键前为空格状态下按 TAB 键，会显示此位置可以出现的所有命令词的第一个，再次按 TAB 键切为下一个
|
||||
- TAB 键前为字符串，会搜索与此字符串前缀匹配的所有可出现命令词，并显示第一个，再次按 TAB 键切为下一个
|
||||
- 输入反斜杠 `\` + TAB 键, 会自动补全为列显示模式命令词 `\G;`
|
||||
|
||||
## 使用小技巧
|
||||
|
||||
- 可以使用上下光标键查看历史输入的指令
|
||||
- 在 TDengine CLI 中使用 `alter user` 命令可以修改用户密码，缺省密码为 `taosdata`
|
||||
- Ctrl+C 中止正在进行中的查询
|
||||
- 执行 `RESET QUERY CACHE` 可清除本地表 Schema 的缓存
|
||||
- 批量执行 SQL 语句。可以将一系列的 TDengine CLI 命令（以英文 ; 结尾，每个 SQL 语句为一行）按行存放在文件里，在 TDengine CLI 里执行命令 `source <file-name>` 自动执行该文件里所有的 SQL 语句
|
||||
- 可以使用上下光标键查看历史输入的指令。
|
||||
- 在 TDengine CLI 中使用 `alter user` 命令可以修改用户密码，缺省密码为 `taosdata` 。
|
||||
- Ctrl+C 中止正在进行中的查询。
|
||||
- 执行 `RESET QUERY CACHE` 可清除本地表 Schema 的缓存。
|
||||
- 批量执行 SQL 语句。可以将一系列的 TDengine CLI 命令（以英文 ; 结尾，每个 SQL 语句为一行）按行存放在文件里，在 TDengine CLI 里执行命令 `source <file-name>` 自动执行该文件里所有的 SQL 语句。
|
||||
|
||||
## 错误代码表
|
||||
在 TDengine 3.3.4.8 版本后 TDengine CLI 在返回错误信息中返回了具体错误码，用户可到 TDengine 官网错误码页面查找具体原因及解决措施，见：[错误码参考表](https://docs.taosdata.com/reference/error-code/)
|
||||
|
|
|
|||
|
|
@ -8,19 +8,19 @@ taosdump 是为开源用户提供的 TDengine 数据备份/恢复工具，备份
|
|||
|
||||
## 工具获取
|
||||
|
||||
taosdump 是 TDengine 服务器及客户端安装包中默认安装组件，安装后即可使用，参考 [TDengine 安装](../../../get-started/)
|
||||
taosdump 是 TDengine 服务器及客户端安装包中默认安装组件，安装后即可使用，参考 [TDengine 安装](../../../get-started/)
|
||||
|
||||
## 运行
|
||||
taosdump 需在命令行终端中运行，运行时必须带参数，指明是备份操作或还原操作，如：
|
||||
``` bash
|
||||
taosdump -h dev126 -D test -o /root/test/
|
||||
taosdump -h my-server -D test -o /root/test/
|
||||
```
|
||||
以上命令表示备份主机名为 `dev126` 机器上的 `test` 数据库到 `/root/test/` 目录下
|
||||
以上命令表示备份主机名为 `my-server` 机器上的 `test` 数据库到 `/root/test/` 目录下。
|
||||
|
||||
``` bash
|
||||
taosdump -h dev126 -i /root/test/
|
||||
taosdump -h my-server -i /root/test/
|
||||
```
|
||||
以上命令表示把 `/root/test/` 目录下之前备份的数据文件恢复到主机名为 `dev126` 的主机上
|
||||
以上命令表示把 `/root/test/` 目录下之前备份的数据文件恢复到主机名为 `my-server` 的主机上。
|
||||
|
||||
|
||||
## 命令行参数
|
||||
|
|
@ -71,28 +71,27 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
restore, please adjust the value to a smaller one
|
||||
and try. The workable value is related to the
|
||||
length of the row and type of table schema.
|
||||
-I, --inspect inspect avro file content and print on screen
|
||||
-I, --inspect inspect avro file content and print on screen.
|
||||
-L, --loose-mode Using loose mode if the table name and column name
|
||||
use letter and number only. Default is NOT.
|
||||
-n, --no-escape No escape char '`'. Default is using it.
|
||||
-Q, --dot-replace Repalce dot character with underline character in
|
||||
the table name.(Version 2.5.3)
|
||||
-T, --thread-num=THREAD_NUM Number of thread for dump in file. Default is
|
||||
8.
|
||||
the table name.(Version 2.5.3).
|
||||
-T, --thread-num=THREAD_NUM Number of thread for dump in file. Default is 8
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during
|
||||
importing data. RENAME-LIST:
|
||||
"db1=newDB1|db2=newDB2" means rename db1 to newDB1
|
||||
and rename db2 to newDB2 (Version 2.5.4)
|
||||
and rename db2 to newDB2 (Version 2.5.4).
|
||||
-k, --retry-count=VALUE Set the number of retry attempts for connection or
|
||||
query failures
|
||||
-z, --retry-sleep-ms=VALUE retry interval sleep time, unit ms
|
||||
-C, --cloud=CLOUD_DSN specify a DSN to access TDengine cloud service
|
||||
-R, --restful Use RESTful interface to connect TDengine
|
||||
query failures.
|
||||
-z, --retry-sleep-ms=VALUE retry interval sleep time, unit ms.
|
||||
-C, --cloud=CLOUD_DSN specify a DSN to access TDengine cloud service.
|
||||
-R, --restful Use RESTful interface to connect TDengine.
|
||||
-t, --timeout=SECONDS The timeout seconds for websocket to interact.
|
||||
-g, --debug Print debug info.
|
||||
-?, --help Give this help list
|
||||
--usage Give a short usage message
|
||||
-V, --version Print program version
|
||||
-?, --help Give this help list.
|
||||
--usage Give a short usage message.
|
||||
-V, --version Print program version.
|
||||
|
||||
Mandatory or optional arguments to long options are also mandatory or optional
|
||||
for any corresponding short options.
|
||||
|
|
@ -102,15 +101,15 @@ Report bugs to <support@taosdata.com>.
|
|||
|
||||
## 常用使用场景
|
||||
|
||||
### taosdump 备份数据
|
||||
### 备份数据
|
||||
|
||||
1. 备份所有数据库：指定 `-A` 或 `--all-databases` 参数；
|
||||
2. 备份多个指定数据库：使用 `-D db1,db2,...` 参数；
|
||||
3. 备份指定数据库中某些超级表或普通表：使用 `dbname stbname1 stbname2 tbname1 tbname2 ...` 参数，注意这种输入序列第一个参数为数据库名称，且只支持一个数据库，第二个和之后的参数为该数据库中的超级表或普通表名称，中间以空格分隔；
|
||||
1. 备份所有数据库：指定 `-A` 或 `--all-databases` 参数。
|
||||
2. 备份多个指定数据库：使用 `-D db1,db2,...` 参数。
|
||||
3. 备份指定数据库中某些超级表或普通表：使用 `dbname stbname1 stbname2 tbname1 tbname2 ...` 参数，注意这种输入序列第一个参数为数据库名称，且只支持一个数据库，第二个和之后的参数为该数据库中的超级表或普通表名称，中间以空格分隔。
|
||||
4. 备份系统 log 库：TDengine 集群通常会包含一个系统数据库，名为 `log`，这个数据库内的数据为 TDengine 自我运行的数据，taosdump 默认不会对 log 库进行备份。如果有特定需求对 log 库进行备份，可以使用 `-a` 或 `--allow-sys` 命令行参数。
|
||||
5. “宽容”模式备份：taosdump 1.4.1 之后的版本提供 `-n` 参数和 `-L` 参数，用于备份数据时不使用转义字符和“宽容”模式，可以在表名、列名、标签名没使用转义字符的情况下减少备份数据时间和备份数据占用空间。如果不确定符合使用 `-n` 和 `-L` 条件时请使用默认参数进行“严格”模式进行备份。转义字符的说明请参考[官方文档](../../taos-sql/escape)。
|
||||
5. “宽容”模式备份：taosdump 1.4.1 之后的版本提供 `-n` 参数和 `-L` 参数，用于备份数据时不使用转义字符和“宽容”模式，可以在表名、列名、标签名没使用转义字符的情况下减少备份数据时间和备份数据占用空间。如果不确定符合使用 `-n` 和 `-L` 条件时请使用默认参数进行“严格”模式进行备份。转义字符的说明请参考 [官方文档](../../taos-sql/escape)
|
||||
6. `-o` 参数指定的目录下如果已存在备份文件，为防止数据被覆盖，taosdump 会报错并退出，请更换其它空目录或清空原来数据后再备份。
|
||||
7. 目前 taosdump 不支持数据断点继备功能，一旦数据备份中断，需要从头开始。如果备份需要很长时间，建议使用（-S -E 选项）指定开始/结束时间进行分段备份的方法，
|
||||
7. 目前 taosdump 不支持数据断点继备功能，一旦数据备份中断，需要从头开始。如果备份需要很长时间，建议使用（-S -E 选项）指定开始/结束时间进行分段备份的方法。
|
||||
|
||||
:::tip
|
||||
- taosdump 1.4.1 之后的版本提供 `-I` 参数，用于解析 avro 文件 schema 和数据，如果指定 `-s` 参数将只解析 schema。
|
||||
|
|
@ -120,13 +119,13 @@ Report bugs to <support@taosdata.com>.
|
|||
|
||||
:::
|
||||
|
||||
### taosdump 恢复数据
|
||||
### 恢复数据
|
||||
|
||||
- 恢复指定路径下的数据文件：使用 `-i` 参数加上数据文件所在路径。如前面提及，不应该使用同一个目录备份不同数据集合，也不应该在同一路径多次备份同一数据集，否则备份数据会造成覆盖或多次备份。
|
||||
- taosdump 支持数据恢复至新数据库名下，参数是 -W, 详细见命令行参数说明。
|
||||
|
||||
|
||||
:::tip
|
||||
taosdump 内部使用 TDengine stmt binding API 进行恢复数据的写入，为提高数据恢复性能，目前使用 16384 为一次写入批次。如果备份数据中有比较多列数据，可能会导致产生 "WAL size exceeds limit" 错误，此时可以通过使用 `-B` 参数调整为一个更小的值进行尝试。
|
||||
taosdump 内部使用 TDengine stmt binding API 进行恢复数据的写入，为提高数据恢复性能，目前使用 16384 为一次写入批次。如果备份数据中有较多列数据，可能会导致产生 "WAL size exceeds limit" 错误，此时可以通过使用 `-B` 参数调整为一个更小的值进行尝试。
|
||||
|
||||
:::
|
||||
|
|
@ -12,18 +12,13 @@ taosBenchmark 是 TDengine 服务器及客户端安装包中默认安装组件
|
|||
|
||||
## 运行
|
||||
|
||||
### 运行方式
|
||||
taosBenchmark 支持无参数、命令行、配置文件三种运行模式，`命令行` 为 `配置文件` 功能子集，两者同时使用时，以命令行方式优先。
|
||||
|
||||
taosBenchmark 支持三种运行模式:
|
||||
- 无参数模式
|
||||
- 命令行模式
|
||||
- JSON 配置文件模式
|
||||
`命令行方式` 为 `JSON 配置文件方式` 功能子集，两者都使用时，命令行方式优先。
|
||||
:::tip
|
||||
在运行 taosBenchmark 之前要确保 TDengine 集群已经在正确运行。
|
||||
:::
|
||||
|
||||
|
||||
**在运行 taosBenchmark 之前要确保 TDengine 集群已经在正确运行。**
|
||||
|
||||
### 无命令行参数运行
|
||||
### 无参数模式
|
||||
|
||||
```bash
|
||||
taosBenchmark
|
||||
|
|
@ -32,9 +27,9 @@ taosBenchmark
|
|||
在无参数运行时，taosBenchmark 默认连接 `/etc/taos/taos.cfg` 中指定的 TDengine 集群。
|
||||
连接成功后，会默认创建智能电表示例数据库 test，创建超级表 meters, 创建子表 1 万，每子写入数据 1 万条，若 test 库已存在，默认会先删再建。
|
||||
|
||||
### 使用命令行参数运行
|
||||
### 命令行模式
|
||||
|
||||
命令行支持的参数为写入功能中使用较为频繁的参数，查询与订阅功能不支持命令行方式
|
||||
命令行支持的参数为写入功能中使用较为频繁的参数，查询与订阅功能不支持命令行方式。
|
||||
示例：
|
||||
```bash
|
||||
taosBenchmark -d db -t 100 -n 1000 -T 4 -I stmt -y
|
||||
|
|
@ -42,51 +37,14 @@ taosBenchmark -d db -t 100 -n 1000 -T 4 -I stmt -y
|
|||
|
||||
此命令表示使用 `taosBenchmark` 将创建一个名为 `db` 的数据库，并建立默认超级表 `meters`，子表 100 ，使用参数绑定(stmt)方式为每张子表写入 1000 条记录。
|
||||
|
||||
### 使用配置文件运行
|
||||
### 配置文件模式
|
||||
|
||||
配置文件方式运行提供了全部功能，所有命令行参数都可以在配置文件中配置运行
|
||||
以 JSON 配置文件方式运行提供了全部功能，所有命令行参数都可以在配置文件中配置运行。
|
||||
|
||||
```bash
|
||||
taosBenchmark -f <json file>
|
||||
```
|
||||
|
||||
**下面为支持的写入、查询、订阅三大功能的配置文件示例：**
|
||||
|
||||
#### 写入场景 JSON 配置文件示例
|
||||
|
||||
<details>
|
||||
<summary>insert.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/insert.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### 查询场景 JSON 配置文件示例
|
||||
|
||||
<details>
|
||||
<summary>query.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/query.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### 订阅场景 JSON 配置文件示例
|
||||
|
||||
<details>
|
||||
<summary>tmq.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/tmq.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
查看更多 json 配置文件示例可 [点击这里](https://github.com/taosdata/TDengine/tree/main/tools/taos-tools/example)
|
||||
|
||||
## 命令行参数
|
||||
| 命令行参数 | 功能说明 |
|
||||
| ---------------------------- | ----------------------------------------------- |
|
||||
|
|
@ -129,60 +87,6 @@ taosBenchmark -f <json file>
|
|||
| -V/--version | 显示版本信息并退出。不能与其它参数混用|
|
||||
| -?/--help | 显示帮助信息并退出。不能与其它参数混用|
|
||||
|
||||
|
||||
## 输出性能指标
|
||||
|
||||
#### 写入指标
|
||||
|
||||
写入结束后会在最后两行输出总体性能指标，格式如下：
|
||||
``` bash
|
||||
SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second
|
||||
SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms
|
||||
```
|
||||
第一行写入速度统计：
|
||||
- Spent: 写入总耗时，单位秒，从开始写入第一个数据开始计时到最后一条数据结束，这里表示共花了 8.527298 秒
|
||||
- real : 写入总耗时（调用引擎），此耗时已抛去测试框架准备数据时间，纯统计在引擎调用上花费的时间，示例为 8.117379 秒，8.527298 - 8.117379 = 0.409919 秒则为测试框架准备数据消耗时间
|
||||
- rows : 写入总行数，为 1000 万条数据
|
||||
- threads: 写入线程数，这里是 8 个线程同时写入
|
||||
- records/second 写入速度 = `写入总耗时`/ `写入总行数` ， 括号中 `real` 同前，表示纯引擎写入速度
|
||||
第二行单个写入延时统计：
|
||||
- min : 写入最小延时
|
||||
- avg : 写入平时延时
|
||||
- p90 : 写入延时 p90 百分位上的延时数
|
||||
- p95 : 写入延时 p95 百分位上的延时数
|
||||
- p99 : 写入延时 p99 百分位上的延时数
|
||||
- max : 写入最大延时
|
||||
通过此系列指标，可观察到写入请求延时分布情况
|
||||
|
||||
#### 查询指标
|
||||
|
||||
查询性能测试主要输出查询请求速度 QPS 指标, 输出格式如下：
|
||||
``` bash
|
||||
complete query with 3 threads and 10000 query delay avg: 0.002686s min: 0.001182s max: 0.012189s p90: 0.002977s p95: 0.003493s p99: 0.004645s SQL command: select ...
|
||||
INFO: Spend 26.9530 second completed total queries: 30000, the QPS of all threads: 1113.049
|
||||
```
|
||||
- 第一行表示 3 个线程每个线程执行 10000 次查询及查询请求延时百分位分布情况，`SQL command` 为测试的查询语句
|
||||
- 第二行表示查询总耗时为 26.9653 秒，每秒查询率(QPS)为：1113.049 次/秒
|
||||
- 如果在查询中设置了 `continue_if_fail` 选项为 `yes`，在最后一行中会输出失败请求个数及错误率，格式 error + 失败请求个数 (错误率)
|
||||
- QPS = 成功请求数量 / 花费时间(单位秒)
|
||||
- 错误率 = 失败请求数量 /（成功请求数量 + 失败请求数量）
|
||||
|
||||
#### 订阅指标
|
||||
|
||||
订阅性能测试主要输出消费者消费速度指标，输出格式如下：
|
||||
``` bash
|
||||
INFO: consumer id 0 has poll total msgs: 376, period rate: 37.592 msgs/s, total rows: 3760000, period rate: 375924.815 rows/s
|
||||
INFO: consumer id 1 has poll total msgs: 362, period rate: 36.131 msgs/s, total rows: 3620000, period rate: 361313.504 rows/s
|
||||
INFO: consumer id 2 has poll total msgs: 364, period rate: 36.378 msgs/s, total rows: 3640000, period rate: 363781.731 rows/s
|
||||
INFO: consumerId: 0, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 1, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 2, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: Consumed total msgs: 3000, total rows: 30000000
|
||||
```
|
||||
- 1 ~ 3 行实时输出每个消费者当前的消费速度，`msgs/s` 表示消费消息个数，每个消息中包含多行数据，`rows/s` 表示按行数统计的消费速度
|
||||
- 4 ~ 6 行是测试完成后每个消费者总体统计，统计共消费了多少条消息，共计多少行
|
||||
- 第 7 行所有消费者总体统计，`msgs` 表示共消费了多少条消息， `rows` 表示共消费了多少行数据
|
||||
|
||||
## 配置文件参数
|
||||
|
||||
### 通用配置参数
|
||||
|
|
@ -192,28 +96,28 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
- **filetype** : 功能分类，可选值为 `insert`, `query` 和 `subscribe`。分别对应插入、查询和订阅功能。每个配置文件中只能指定其中之一。
|
||||
- **cfgdir** : TDengine 客户端配置文件所在的目录，默认路径是 /etc/taos 。
|
||||
|
||||
- **host** : 指定要连接的 TDengine 服务端的 FQDN，默认值为 localhost。
|
||||
- **host** : 指定要连接的 TDengine 服务端的 FQDN，默认值为 localhost 。
|
||||
|
||||
- **port** : 要连接的 TDengine 服务器的端口号，默认值为 6030。
|
||||
- **port** : 要连接的 TDengine 服务器的端口号，默认值为 6030 。
|
||||
|
||||
- **user** : 用于连接 TDengine 服务端的用户名，默认为 root。
|
||||
- **user** : 用于连接 TDengine 服务端的用户名，默认为 root 。
|
||||
|
||||
- **password** : 用于连接 TDengine 服务端的密码，默认值为 taosdata。
|
||||
|
||||
### 插入场景配置参数
|
||||
### 写入配置参数
|
||||
|
||||
插入场景下 `filetype` 必须设置为 `insert`，该参数及其它通用参数详见[通用配置参数](#通用配置参数)
|
||||
写入场景下 `filetype` 必须设置为 `insert`，该参数及其它通用参数详见 [通用配置参数](#通用配置参数)
|
||||
|
||||
- **keep_trying** : 失败后进行重试的次数，默认不重试。需使用 v3.0.9 以上版本。
|
||||
|
||||
- **trying_interval** : 失败重试间隔时间，单位为毫秒，仅在 keep_trying 指定重试后有效。需使用 v3.0.9 以上版本。
|
||||
- **childtable_from 和 childtable_to** : 指定写入子表范围，开闭区间为 [childtable_from, childtable_to).
|
||||
- **childtable_from 和 childtable_to** : 指定写入子表范围，开闭区间为 [childtable_from, childtable_to) 。
|
||||
|
||||
- **continue_if_fail** : 允许用户定义失败后行为
|
||||
- **continue_if_fail** : 允许用户定义失败后行为。
|
||||
|
||||
“continue_if_fail”: “no”, 失败 taosBenchmark 自动退出，默认行为
|
||||
“continue_if_fail”: “yes”, 失败 taosBenchmark 警告用户，并继续写入
|
||||
“continue_if_fail”: “smart”, 如果子表不存在失败，taosBenchmark 会建立子表并继续写入
|
||||
“continue_if_fail”: “no”, 失败 taosBenchmark 自动退出，默认行为。
|
||||
“continue_if_fail”: “yes”, 失败 taosBenchmark 警告用户，并继续写入。
|
||||
“continue_if_fail”: “smart”, 如果子表不存在失败，taosBenchmark 会建立子表并继续写入。
|
||||
|
||||
#### 数据库相关
|
||||
|
||||
|
|
@ -221,7 +125,7 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **name** : 数据库名。
|
||||
|
||||
- **drop** : 数据库已存在时是否删除，可选项为 "yes" 或 "no", 默认为 “yes”
|
||||
- **drop** : 数据库已存在时是否删除，可选项为 "yes" 或 "no", 默认为 “yes” 。
|
||||
|
||||
#### 超级表相关
|
||||
|
||||
|
|
@ -229,13 +133,13 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **name**: 超级表名，必须配置，没有默认值。
|
||||
|
||||
- **child_table_exists** : 子表是否已经存在，默认值为 "no"，可选值为 "yes" 或 "no"。
|
||||
- **child_table_exists** : 子表是否已经存在，默认值为 "no"，可选值为 "yes" 或 "no" 。
|
||||
|
||||
- **childtable_count** : 子表的数量，默认值为 10。
|
||||
|
||||
- **childtable_prefix** : 子表名称的前缀，必选配置项，没有默认值。
|
||||
|
||||
- **escape_character** : 超级表和子表名称中是否包含转义字符，默认值为 "no"，可选值为 "yes" 或 "no"。
|
||||
- **escape_character** : 超级表和子表名称中是否包含转义字符，默认值为 "no"，可选值为 "yes" 或 "no" 。
|
||||
|
||||
- **auto_create_table** : 仅当 insert_mode 为 taosc, rest, stmt 并且 child_table_exists 为 "no" 时生效，该参数为 "yes" 表示 taosBenchmark 在插入数据时会自动创建不存在的表；为 "no" 则表示先提前建好所有表再进行插入。
|
||||
|
||||
|
|
@ -247,7 +151,7 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **non_stop_mode** : 指定是否持续写入，若为 "yes" 则 insert_rows 失效，直到 Ctrl + C 停止程序，写入才会停止。默认值为 "no"，即写入指定数量的记录后停止。注：即使在持续写入模式下 insert_rows 失效，但其也必须被配置为一个非零正整数。
|
||||
|
||||
- **line_protocol** : 使用行协议插入数据，仅当 insert_mode 为 sml 或 sml-rest 时生效，可选项为 line, telnet, json。
|
||||
- **line_protocol** : 使用行协议插入数据，仅当 insert_mode 为 sml 或 sml-rest 时生效，可选项为 line, telnet, json 。
|
||||
|
||||
- **tcp_transfer** : telnet 模式下的通信协议，仅当 insert_mode 为 sml-rest 并且 line_protocol 为 telnet 时生效。如果不配置，则默认为 http 协议。
|
||||
|
||||
|
|
@ -267,9 +171,9 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **disorder_range** : 指定乱序数据的时间戳回退范围。所生成的乱序时间戳为非乱序情况下应该使用的时间戳减去这个范围内的一个随机值。仅在 `-O/--disorder` 指定的乱序数据百分比大于 0 时有效。
|
||||
|
||||
- **timestamp_step** : 每个子表中插入数据的时间戳步长，单位与数据库的 `precision` 一致，默认值是 1。
|
||||
- **timestamp_step** : 每个子表中插入数据的时间戳步长，单位与数据库的 `precision` 一致，默认值是 1 。
|
||||
|
||||
- **start_timestamp** : 每个子表的时间戳起始值，默认值是 now。
|
||||
- **start_timestamp** : 每个子表的时间戳起始值，默认值是 now 。
|
||||
|
||||
- **sample_format** : 样本数据文件的类型，现在只支持 "csv" 。
|
||||
|
||||
|
|
@ -279,10 +183,10 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **tags_file** : 仅当 insert_mode 为 taosc, rest 的模式下生效。 最终的 tag 的数值与 childtable_count 有关，如果 csv 文件内的 tag 数据行小于给定的子表数量，那么会循环读取 csv 文件数据直到生成 childtable_count 指定的子表数量；否则则只会读取 childtable_count 行 tag 数据。也即最终生成的子表数量为二者取小。
|
||||
|
||||
- **primary_key** : 指定超级表是否有复合主键，取值 1 和 0， 复合主键列只能是超级表的第二列，指定生成复合主键后要确保第二列符合复合主键的数据类型，否则会报错
|
||||
- **repeat_ts_min** : 数值类型，复合主键开启情况下指定生成相同时间戳记录的最小个数，生成相同时间戳记录的个数是在范围[repeat_ts_min, repeat_ts_max] 内的随机值, 最小值等于最大值时为固定个数
|
||||
- **repeat_ts_max** : 数值类型，复合主键开启情况下指定生成相同时间戳记录的最大个数
|
||||
- **sqls** : 字符串数组类型，指定超级表创建成功后要执行的 sql 数组，sql 中指定表名前面要带数据库名，否则会报未指定数据库错误
|
||||
- **primary_key** : 指定超级表是否有复合主键，取值 1 和 0， 复合主键列只能是超级表的第二列，指定生成复合主键后要确保第二列符合复合主键的数据类型，否则会报错。
|
||||
- **repeat_ts_min** : 数值类型，复合主键开启情况下指定生成相同时间戳记录的最小个数，生成相同时间戳记录的个数是在范围[repeat_ts_min, repeat_ts_max] 内的随机值, 最小值等于最大值时为固定个数。
|
||||
- **repeat_ts_max** : 数值类型，复合主键开启情况下指定生成相同时间戳记录的最大个数。
|
||||
- **sqls** : 字符串数组类型，指定超级表创建成功后要执行的 sql 数组，sql 中指定表名前面要带数据库名，否则会报未指定数据库错误。
|
||||
|
||||
|
||||
#### 标签列与数据列
|
||||
|
|
@ -308,27 +212,27 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **values** : nchar/binary 列/标签的值域，将从值中随机选择。
|
||||
|
||||
- **sma**: 将该列加入 SMA 中，值为 "yes" 或者 "no"，默认为 "no"。
|
||||
- **sma**: 将该列加入 SMA 中，值为 "yes" 或者 "no"，默认为 "no" 。
|
||||
|
||||
- **encode**: 字符串类型，指定此列两级压缩中的第一级编码算法，详细参见创建超级表
|
||||
- **encode**: 字符串类型，指定此列两级压缩中的第一级编码算法，详细参见创建超级表。
|
||||
|
||||
- **compress**: 字符串类型，指定此列两级压缩中的第二级加密算法，详细参见创建超级表
|
||||
- **compress**: 字符串类型，指定此列两级压缩中的第二级加密算法，详细参见创建超级表。
|
||||
|
||||
- **level**: 字符串类型，指定此列两级压缩中的第二级加密算法的压缩率高低，详细参见创建超级表
|
||||
- **level**: 字符串类型，指定此列两级压缩中的第二级加密算法的压缩率高低，详细参见创建超级表。
|
||||
|
||||
- **gen**: 字符串类型，指定此列生成数据的方式，不指定为随机，若指定为 “order”, 会按自然数顺序增长
|
||||
- **gen**: 字符串类型，指定此列生成数据的方式，不指定为随机，若指定为 “order”, 会按自然数顺序增长。
|
||||
|
||||
- **fillNull**: 字符串类型，指定此列是否随机插入 NULL 值，可指定为 “true” 或 "false", 只有当 generate_row_rule 为 2 时有效
|
||||
- **fillNull**: 字符串类型，指定此列是否随机插入 NULL 值，可指定为 “true” 或 "false", 只有当 generate_row_rule 为 2 时有效。
|
||||
|
||||
#### 插入行为相关
|
||||
#### 写入行为相关
|
||||
|
||||
- **thread_count** : 插入数据的线程数量，默认为 8。
|
||||
|
||||
**thread_bind_vgroup** : 写入时 vgroup 是否和写入线程绑定，绑定后可提升写入速度, 取值为 "yes" 或 "no"，默认值为 “no”, 设置为 “no” 后与原来行为一致。 当设为 “yes” 时，如果 thread_count 大于写入数据库 vgroups 数量， thread_count 自动调整为 vgroups 数量；如果 thread_count 小于 vgroups 数量，写入线程数量不做调整，一个线程写完一个 vgroup 数据后再写下一个，同时保持一个 vgroup 同时只能由一个线程写入的规则。
|
||||
- **thread_bind_vgroup** : 写入时 vgroup 是否和写入线程绑定，绑定后可提升写入速度, 取值为 "yes" 或 "no"，默认值为 “no”, 设置为 “no” 后与原来行为一致。 当设为 “yes” 时，如果 thread_count 大于写入数据库 vgroups 数量， thread_count 自动调整为 vgroups 数量；如果 thread_count 小于 vgroups 数量，写入线程数量不做调整，一个线程写完一个 vgroup 数据后再写下一个，同时保持一个 vgroup 同时只能由一个线程写入的规则。
|
||||
|
||||
- **create_table_thread_count** : 建表的线程数量，默认为 8。
|
||||
|
||||
- **result_file** : 结果输出文件的路径，默认值为 ./output.txt。
|
||||
- **result_file** : 结果输出文件的路径，默认值为 ./output.txt 。
|
||||
|
||||
- **confirm_parameter_prompt** : 开关参数，要求用户在提示后确认才能继续， 可取值 "yes" or "no"。默认值为 "no" 。
|
||||
|
||||
|
|
@ -346,15 +250,15 @@ INFO: Consumed total msgs: 3000, total rows: 30000000
|
|||
|
||||
- **pre_load_tb_meta** ：是否提前加载子表的 meta 数据，取值为 “yes” or "no"。当子表数量非常多时，打开此选项可提高写入速度。
|
||||
|
||||
### 查询场景配置参数
|
||||
### 查询配置参数
|
||||
|
||||
查询场景下 `filetype` 必须设置为 `query`。
|
||||
`query_times` 指定运行查询的次数，数值类型
|
||||
`query_times` 指定运行查询的次数，数值类型。
|
||||
|
||||
查询场景可以通过设置 `kill_slow_query_threshold` 和 `kill_slow_query_interval` 参数来控制杀掉慢查询语句的执行，threshold 控制如果 exec_usec 超过指定时间的查询将被 taosBenchmark 杀掉，单位为秒；
|
||||
查询场景可以通过设置 `kill_slow_query_threshold` 和 `kill_slow_query_interval` 参数来控制杀掉慢查询语句的执行，threshold 控制如果 exec_usec 超过指定时间的查询将被 taosBenchmark 杀掉，单位为秒。
|
||||
interval 控制休眠时间，避免持续查询慢查询消耗 CPU ，单位为秒。
|
||||
|
||||
其它通用参数详见[通用配置参数](#通用配置参数)。
|
||||
其它通用参数详见 [通用配置参数](#通用配置参数)
|
||||
|
||||
#### 执行指定查询语句
|
||||
|
||||
|
|
@ -391,23 +295,35 @@ interval 控制休眠时间，避免持续查询慢查询消耗 CPU ，单位为
|
|||
- **sqls** ：
|
||||
- **sql** : 执行的 SQL 命令，必填；对于超级表的查询 SQL，在 SQL 命令中必须保留 "xxxx"，会替换为超级下所有子表名后再执行。
|
||||
- **result** : 保存查询结果的文件，未指定则不保存。
|
||||
- **限制项** : sqls 下配置 sql 数组最大为 100 个
|
||||
- **限制项** : sqls 下配置 sql 数组最大为 100 个。
|
||||
|
||||
### 订阅场景配置参数
|
||||
### 订阅配置参数
|
||||
|
||||
订阅场景下 `filetype` 必须设置为 `subscribe`，该参数及其它通用参数详见[通用配置参数](#通用配置参数)
|
||||
订阅场景下 `filetype` 必须设置为 `subscribe`，该参数及其它通用参数详见 [通用配置参数](#通用配置参数)
|
||||
|
||||
订阅指定表（可以指定超级表、子表或者普通表）的配置参数在 `specified_table_query` 中设置。
|
||||
订阅配置参数在 `tmq_info` 项下设置，参数如下：
|
||||
|
||||
- **threads/concurrent** : 执行 SQL 的线程数，默认为 1。
|
||||
- **concurrent** : 消费订阅的消费者数量，或称并发消费数量，默认值：1。
|
||||
- **create_mode** : 创建消费者模式，可取值 sequential：顺序创建， parallel：并发同时创建，必填项，无默认值。
|
||||
- **group_mode** : 生成消费者 groupId 模式，可取值 share：所有消费者只生成一个 groupId， independent：每个消费者生成一个独立的 groupId，如果 `group.id` 未设置，此项为必填项，无默认值。
|
||||
- **poll_delay** : 调用 tmq_consumer_poll 传入的轮询超时时间，单位为毫秒，负数表示默认超时 1 秒。
|
||||
- **enable.manual.commit** : 是否允许手动提交，可取值 true：允许手动提交，每次消费完消息后手动调用 tmq_commit_sync 完成提交， false：不进行提交，默认值: false。
|
||||
- **rows_file** : 存储消费数据的文件，可以为全路径或相对路径，带文件名。实际保存的文件会在后面加上消费者序号，如 rows_file 为 result, 实际文件名为 result_1（消费者 1） result_2（消费者 2） ...
|
||||
- **expect_rows** : 期望每个消费者消费的行数，数据类型，当消费达到这个数，消费会退出，不设置会一直消费。
|
||||
- **topic_list** : 指定消费的 topic 列表，数组类型。topic 列表格式示例： `{"name": "topic1", "sql": "select * from test.meters;"}` ，name：指定 topic 名，sql：指定创建 topic 的 sql 语句，需保证 sql 正确，框架会自动创建出 topic。
|
||||
|
||||
- **sqls** ：
|
||||
- **sql** : 执行的 SQL 命令，必填。
|
||||
|
||||
以下参数透传订阅属性，参见 [订阅创建参数](../../../develop/tmq/#创建参数) 说明：
|
||||
- **client.id**
|
||||
- **auto.offset.reset**
|
||||
- **enable.auto.commit**
|
||||
- **enable.auto.commit**
|
||||
- **msg.with.table.name**
|
||||
- **auto.commit.interval.ms**
|
||||
- **group.id** : 若此值不指定，将由 `group_mode` 指定规则生成 groupId，若指定此值，`group_mode` 参数不再有效。
|
||||
|
||||
### 配置文件中数据类型书写对照表
|
||||
### 数据类型对照表
|
||||
|
||||
| # | **引擎** | **taosBenchmark**
|
||||
| # | **TDengine** | **taosBenchmark**
|
||||
| --- | :----------------: | :---------------:
|
||||
| 1 | TIMESTAMP | timestamp
|
||||
| 2 | INT | int
|
||||
|
|
@ -428,7 +344,96 @@ interval 控制休眠时间，避免持续查询慢查询消耗 CPU ，单位为
|
|||
| 17 | GEOMETRY | geometry
|
||||
| 18 | JSON | json
|
||||
|
||||
注意：taosBenchmark 配置文件中数据类型必须小写方可识别
|
||||
注意：taosBenchmark 配置文件中数据类型必须小写方可识别。
|
||||
|
||||
## 配置文件示例
|
||||
|
||||
**下面为支持的写入、查询、订阅三大功能的配置文件示例：**
|
||||
|
||||
### 写入 JSON 示例
|
||||
|
||||
<details>
|
||||
<summary>insert.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/insert.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 查询 JSON 示例
|
||||
|
||||
<details>
|
||||
<summary>query.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/query.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 订阅 JSON 示例
|
||||
|
||||
<details>
|
||||
<summary>tmq.json</summary>
|
||||
|
||||
```json
|
||||
{{#include /TDengine/tools/taos-tools/example/tmq.json}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
查看更多 json 配置文件示例可 [点击这里](https://github.com/taosdata/TDengine/tree/main/tools/taos-tools/example)
|
||||
|
||||
## 输出性能指标
|
||||
|
||||
#### 写入指标
|
||||
|
||||
写入结束后会在最后两行输出总体性能指标，格式如下：
|
||||
``` bash
|
||||
SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second
|
||||
SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms
|
||||
```
|
||||
第一行写入速度统计：
|
||||
- Spent: 写入总耗时，单位秒，从开始写入第一个数据开始计时到最后一条数据结束，这里表示共花了 8.527298 秒。
|
||||
- real : 写入总耗时（调用引擎），此耗时已抛去测试框架准备数据时间，纯统计在引擎调用上花费的时间，示例为 8.117379 秒，8.527298 - 8.117379 = 0.409919 秒则为测试框架准备数据消耗时间
|
||||
- rows : 写入总行数，为 1000 万条数据。
|
||||
- threads: 写入线程数，这里是 8 个线程同时写入。
|
||||
- records/second 写入速度 = `写入总耗时`/ `写入总行数` ， 括号中 `real` 同前，表示纯引擎写入速度。
|
||||
第二行单个写入延时统计：
|
||||
- min : 写入最小延时。
|
||||
- avg : 写入平时延时。
|
||||
- p90 : 写入延时 p90 百分位上的延时数。
|
||||
- p95 : 写入延时 p95 百分位上的延时数。
|
||||
- p99 : 写入延时 p99 百分位上的延时数。
|
||||
- max : 写入最大延时。
|
||||
通过此系列指标，可观察到写入请求延时分布情况。
|
||||
|
||||
#### 查询指标
|
||||
|
||||
查询性能测试主要输出查询请求速度 QPS 指标, 输出格式如下：
|
||||
``` bash
|
||||
complete query with 3 threads and 10000 query delay avg: 0.002686s min: 0.001182s max: 0.012189s p90: 0.002977s p95: 0.003493s p99: 0.004645s SQL command: select ...
|
||||
INFO: Spend 26.9530 second completed total queries: 30000, the QPS of all threads: 1113.049
|
||||
```
|
||||
- 第一行表示 3 个线程每个线程执行 10000 次查询及查询请求延时百分位分布情况，`SQL command` 为测试的查询语句。
|
||||
- 第二行表示查询总耗时为 26.9653 秒，每秒查询率(QPS)为：1113.049 次/秒。
|
||||
- 如果在查询中设置了 `continue_if_fail` 选项为 `yes`，在最后一行中会输出失败请求个数及错误率，格式 error + 失败请求个数 (错误率)。
|
||||
- QPS = 成功请求数量 / 花费时间(单位秒)
|
||||
- 错误率 = 失败请求数量 /（成功请求数量 + 失败请求数量）
|
||||
|
||||
#### 订阅指标
|
||||
|
||||
订阅性能测试主要输出消费者消费速度指标，输出格式如下：
|
||||
``` bash
|
||||
INFO: consumer id 0 has poll total msgs: 376, period rate: 37.592 msgs/s, total rows: 3760000, period rate: 375924.815 rows/s
|
||||
INFO: consumer id 1 has poll total msgs: 362, period rate: 36.131 msgs/s, total rows: 3620000, period rate: 361313.504 rows/s
|
||||
INFO: consumer id 2 has poll total msgs: 364, period rate: 36.378 msgs/s, total rows: 3640000, period rate: 363781.731 rows/s
|
||||
INFO: consumerId: 0, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 1, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 2, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: Consumed total msgs: 3000, total rows: 30000000
|
||||
```
|
||||
- 1 ~ 3 行实时输出每个消费者当前的消费速度，`msgs/s` 表示消费消息个数，每个消息中包含多行数据，`rows/s` 表示按行数统计的消费速度。
|
||||
- 4 ~ 6 行是测试完成后每个消费者总体统计，统计共消费了多少条消息，共计多少行。
|
||||
- 第 7 行所有消费者总体统计，`msgs` 表示共消费了多少条消息， `rows` 表示共消费了多少行数据。
|
||||
|
|
|
|||
|
|
@ -652,7 +652,3 @@ TDengine ODBC 支持两种连接 TDengine 数据库方式：WebSocket 连接与
|
|||
- **标准**: ODBC
|
||||
- **作用**: 关闭与当前语句句柄关联的游标，并释放游标所使用的所有资源
|
||||
|
||||
|
||||
## 与第三方集成
|
||||
|
||||
作为使用 TDengine ODBC driver 的一个示例，你可以使用 Power BI 与 TDengine 分析时序数据。更多细节请参考 [Power BI](../../../third-party/bi/powerbi)
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ description: 一些常见问题的解决方法汇总
|
|||
|
||||
### 5. 遇到错误 Unable to resolve FQDN” 怎么办？
|
||||
|
||||
产生这个错误，是由于客户端或数据节点无法解析 FQDN(Fully Qualified Domain Name)导致。对于 TAOS Shell 或客户端应用，请做如下检查：
|
||||
产生这个错误，是由于客户端或数据节点无法解析 FQDN(Fully Qualified Domain Name)导致。对于 TDengine CLI 或客户端应用，请做如下检查：
|
||||
|
||||
1. 请检查连接的服务器的 FQDN 是否正确，FQDN 配置参考：[一篇文章说清楚 TDengine 的 FQDN](https://www.taosdata.com/blog/2020/09/11/1824.html)
|
||||
2. 如果网络配置有 DNS server，请检查是否正常工作
|
||||
|
|
@ -247,13 +247,13 @@ launchctl limit maxfiles
|
|||
该提示是创建 db 的 vnode 数量不够了，需要的 vnode 不能超过了 dnode 中 vnode 的上限。因为系统默认是一个 dnode 中有 CPU 核数两倍的 vnode，也可以通过配置文件中的参数 supportVnodes 控制。
|
||||
正常调大 taos.cfg 中 supportVnodes 参数即可。
|
||||
|
||||
### 21 在服务器上的使用 taos-CLI 能查到指定时间段的数据，但在客户端机器上查不到？
|
||||
### 21 在服务器上的使用 TDengine CLI能查到指定时间段的数据，但在客户端机器上查不到？
|
||||
这种情况是因为客户端与服务器上设置的时区不一致导致的，调整客户端与服务器的时区一致即可解决。
|
||||
|
||||
### 22 表名确认是存在的，但在写入或查询时返回表名不存在，什么原因？
|
||||
TDengine 中的所有名称，包括数据库名、表名等都是区分大小写的，如果这些名称在程序或 taos-CLI 中没有使用反引号（`）括起来使用，即使你输入的是大写的，引擎也会转化成小写来使用，如果名称前后加上了反引号，引擎就不会再转化成小写，会保持原样来使用。
|
||||
TDengine 中的所有名称，包括数据库名、表名等都是区分大小写的，如果这些名称在程序或 TDengine CLI中没有使用反引号（`）括起来使用，即使你输入的是大写的，引擎也会转化成小写来使用，如果名称前后加上了反引号，引擎就不会再转化成小写，会保持原样来使用。
|
||||
|
||||
### 23 在 taos-CLI 中查询，字段内容不能完全显示出来怎么办？
|
||||
### 23 在 TDengine CLI中查询，字段内容不能完全显示出来怎么办？
|
||||
可以使用 \G 参数来竖式显示，如 show databases\G; （为了输入方便，在"\"后加 TAB 键，会自动补全后面的内容）
|
||||
|
||||
### 24 使用 taosBenchmark 测试工具写入数据查询很快，为什么我写入的数据查询非常慢？
|
||||
|
|
@ -311,7 +311,7 @@ TDinsight插件中展示的数据是通过taosKeeper和taosAdapter服务收集
|
|||
直接查子表更快。超级表带 TAG 过滤查询子查数据是为满足查询方便性，同时可对多个子表中数据进行过滤，如果目的是追求性能并已明确查询子表，直接从子表查性能更高
|
||||
|
||||
### 35 如何查看数据库的数据压缩率和磁盘占用指标？
|
||||
TDengine 3.3.5.0 之前的版本，只提供以表为统计单位的压缩率，数据库及整体还未提供，查看命令是在客户端 taos-CLI 中执行 `SHOW TABLE DISTRIBUTED table_name;` 命令，table_name 为要查看压缩率的表，可以为超级表、普通表及子表，详细可 [查看此处](https://docs.taosdata.com/reference/taos-sql/show/#show-table-distributed)
|
||||
TDengine 3.3.5.0 之前的版本，只提供以表为统计单位的压缩率，数据库及整体还未提供，查看命令是在客户端 TDengine CLI 中执行 `SHOW TABLE DISTRIBUTED table_name;` 命令，table_name 为要查看压缩率的表，可以为超级表、普通表及子表，详细可 [查看此处](https://docs.taosdata.com/reference/taos-sql/show/#show-table-distributed)
|
||||
|
||||
TDengine 3.3.5.0 及以上的版本，还提供了数据库整体压缩率和磁盘空间占用统计。查看数据库整体的数据压缩率和磁盘空间占用的命令为 `SHOW db_name.disk_info;`，查看数据库各个模块的磁盘空间占用的命令为 `SELECT * FROM INFORMATION_SCHEMA.INS_DISK_USAGE WHERE db_name='db_name';`，db_name 为要查看的数据库名称。详细可 [查看此处](https://docs.taosdata.com/reference/taos-sql/database/#%E6%9F%A5%E7%9C%8B-db-%E7%9A%84%E7%A3%81%E7%9B%98%E7%A9%BA%E9%97%B4%E5%8D%A0%E7%94%A8)
|
||||
|
||||
|
|
@ -324,3 +324,4 @@ TDengine 3.3.5.1 之前的版本，StartLimitInterval 为 60 秒。若在 60 秒
|
|||
|
||||
问题解决：
|
||||
1）通过 systemd 重启 taosd 服务：推荐方法是先执行命令 `systemctl reset-failed taosd.service` 重置失败计数器，然后再通过 `systemctl restart taosd.service` 重启；若需长期调整，可手动修改 /etc/systemd/system/taosd.service 文件，将 StartLimitInterval 调小或将 StartLimitBurst 调大(注：重新安装 taosd 会重置该参数，需要重新修改)，执行 `systemctl daemon-reload` 重新加载配置，然后再重启。2）也可以不通过 systemd 而是通过 taosd 命令直接重启 taosd 服务，此时不受 StartLimitInterval 和 StartLimitBurst 参数限制。
|
||||
|
||||
|
|
|
|||
|
|
@ -50,4 +50,4 @@ description: 3.3.2.0 版本说明
|
|||
13. 升级至3.3.0.0开启cachemodel后查询last+group by返回行数不正确
|
||||
14. taos-explorer导航栏未显示所有超级表名（仅企业版）
|
||||
15. 复合主键VARCHAR长度超125遇查询导致taosd异常退出
|
||||
16. taos CLI和taosAdapter占用CPU过高
|
||||
16. TDengine CLI 和taosAdapter占用CPU过高
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ description: 3.3.3.0 版本说明
|
|||
22. 缓存更新时数据填充的游标错误导致的 taosd 异常退出
|
||||
23. STDDEV 函数计算结果随机不正确的问题
|
||||
24. 多级存储以及加密场景下无法添加离线节点
|
||||
25. taos CLI 无法输入大于20字节长度的密码
|
||||
25. TDengine CLI 无法输入大于20字节长度的密码
|
||||
26. 拼接 sql 写入报错: int data overflow
|
||||
27. 大量查询并发场景下元数据的一致性
|
||||
28. 尝试解决手动点击停止按钮，任务无法停止的问题
|
||||
|
|
@ -86,4 +86,4 @@ description: 3.3.3.0 版本说明
|
|||
59. 客户端内存泄漏
|
||||
60. 开源用户修改stt_trigger值升级后无法修改其他数据库选项
|
||||
61. NOT IN (NULL) 查询结果不正确
|
||||
62. taos shell和taosBenchmark不能成功连接云服务实例
|
||||
62. TDengine CLI 和 taosBenchmark 不能成功连接云服务实例
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ description: 3.3.4.3 版本说明
|
|||
1. 修复：Windows 平台重复增删表的内存泄漏
|
||||
1. 修复：无法限制并发拉起 checkpoint 数量导致流计算消耗资源过多
|
||||
1. 修复：并发查询时的 too many session 问题
|
||||
1. 修复：Windows 平台下 taos shell 在慢查询场景中崩溃的问题
|
||||
1. 修复：Windows 平台下 TDengine CLI 在慢查询场景中崩溃的问题
|
||||
1. 修复：当打开 dnode日志时，加密数据库无法恢复的问题
|
||||
1. 修复：由于 mnode 同步超时，进而导致 taosd 无法启动的问题
|
||||
1. 修复：由于在快照同步过程中整理文件组数据的速度过慢，从而导致 Vnode（虚拟节点）无法恢复的问题
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: 3.3.5.0 版本说明
|
|||
2. 特性：taosX 增量备份与恢复
|
||||
3. 特性：JDBC WebSocket 连接支持 STMT2 接口
|
||||
4. 特性：Rust 连接器支持 STMT2 接口
|
||||
5. 特性：taos-CLI 中在错误提示中增加错误码
|
||||
5. 特性：TDengine CLI 中在错误提示中增加错误码
|
||||
6. 特性：Python 连接器对接 SuperSet
|
||||
7. 特性：Explorer 可配置 Grafana Dashboard
|
||||
8. 特性：taosX-agent 支持配置内存缓存队列长度
|
||||
|
|
|
|||
|
|
@ -37,6 +37,6 @@ description: 3.3.5.2 版本说明
|
|||
20. 修复：在使用 SELECT * FROM 子查询时，列名未能正确复制到外层查询
|
||||
21. 修复：对字符串类型数据执行 max/min 函数时，结果不准确且 taosd 可能会崩溃
|
||||
22. 修复：流式计算不支持使用 HAVING 语句，但在创建时未报告错误
|
||||
23. 修复：taos shell 显示的服务端版本信息不准确，例如无法正确区分社区版和企业版
|
||||
23. 修复：TDengine CLI 显示的服务端版本信息不准确，例如无法正确区分社区版和企业版
|
||||
24. 修复：在某些特定的查询场景下，当 JOIN 和 CAST 联合使用时，taosd 可能会崩溃
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue