Merge branch '3.0' into refactor/TD-33926
This commit is contained in:
commit
1be6ef595d
|
@ -1,19 +1,19 @@
|
|||
name: TDengine CI Test
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches:
|
||||
- 'main'
|
||||
- '3.0'
|
||||
- '3.1'
|
||||
paths-ignore:
|
||||
- 'packaging/**'
|
||||
- 'docs/**'
|
||||
# pull_request:
|
||||
# branches:
|
||||
# - 'main'
|
||||
# - '3.0'
|
||||
# - '3.1'
|
||||
# paths-ignore:
|
||||
# - 'packaging/**'
|
||||
# - 'docs/**'
|
||||
repository_dispatch:
|
||||
types: [run-tests]
|
||||
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ github.ref }}
|
||||
group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.ref || github.event.client_payload.ref}}-${{ github.event_name == 'repository_dispatch' && 'dispatch' || ''}}
|
||||
cancel-in-progress: true
|
||||
|
||||
env:
|
||||
|
@ -65,7 +65,7 @@ jobs:
|
|||
|
||||
# check whether to run function test cases
|
||||
changed_files_non_tdgpt=$(git --no-pager diff --name-only FETCH_HEAD `git merge-base FETCH_HEAD $target_branch`|grep -v "^docs/en/"|grep -v "^docs/zh/"|grep -v ".md$" | grep -Ev "forecastoperator.c|anomalywindowoperator.c|tanalytics.h|tanalytics.c|tdgpt_cases.task|analytics" | tr '\n' ' ' ||:)
|
||||
if [ $changed_files_non_tdgpt != '' ]; then
|
||||
if [ "$changed_files_non_tdgpt" != '' ]; then
|
||||
run_function_test="true"
|
||||
else
|
||||
run_function_test="false"
|
||||
|
@ -88,7 +88,7 @@ jobs:
|
|||
env:
|
||||
IS_TDINTERNAL: ${{ needs.fetch-parameters.outputs.tdinternal }}
|
||||
RUN_RUNCTION_TEST: ${{ needs.fetch-parameters.outputs.run_function_test }}
|
||||
RUN_TDGPT_TEST: ${{ needs.fetch-parameters.outputs.run_tdgpt_tests }}
|
||||
RUN_TDGPT_TEST: ${{ needs.fetch-parameters.outputs.run_tdgpt_test }}
|
||||
SOURCE_BRANCH: ${{ needs.fetch-parameters.outputs.source_branch }}
|
||||
TARGET_BRANCH: ${{ needs.fetch-parameters.outputs.target_branch }}
|
||||
PR_NUMBER: ${{ needs.fetch-parameters.outputs.pr_number }}
|
||||
|
@ -161,20 +161,23 @@ jobs:
|
|||
cd ${{ env.WKC }}
|
||||
git submodule update --init --recursive
|
||||
- name: Output the 'file_no_doc_changed' information to the file
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' }}
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' && env.TARGET_BRANCH != '3.1' }}
|
||||
run: |
|
||||
mkdir -p ${{ env.WKDIR }}/tmp/${{ env.PR_NUMBER }}_${{ github.run_number }}
|
||||
changed_files_non_doc=$(git --no-pager diff --name-only FETCH_HEAD `git merge-base FETCH_HEAD ${{ env.TARGET_BRANCH }}`|grep -v "^docs/en/"|grep -v "^docs/zh/"|grep -v ".md$" | tr '\n' ' ' || :)
|
||||
echo $changed_files_non_doc > ${{ env.WKDIR }}/tmp/${{ env.PR_NUMBER }}_${{ github.run_number }}/docs_changed.txt
|
||||
- name: Check assert testing
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' && env.TARGET_BRANCH != '3.1' }}
|
||||
run: |
|
||||
cd ${{ env.WKC }}/tests/parallel_test
|
||||
./run_check_assert_container.sh -d ${{ env.WKDIR }}
|
||||
- name: Check void function testing
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' && env.TARGET_BRANCH != '3.1' }}
|
||||
run: |
|
||||
cd ${{ env.WKC }}/tests/parallel_test
|
||||
./run_check_void_container.sh -d ${{ env.WKDIR }}
|
||||
- name: Build docker container
|
||||
if: ${{ env.RUN_RUNCTION_TEST == 'true' }}
|
||||
run: |
|
||||
date
|
||||
rm -rf ${{ env.WKC }}/debug
|
||||
|
@ -204,18 +207,19 @@ jobs:
|
|||
echo "timeout_cmd=$timeout_cmd" >> $GITHUB_OUTPUT
|
||||
echo "extra_param=$extra_param" >> $GITHUB_OUTPUT
|
||||
- name: Run function returns with a null pointer scan testing
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' && env.TARGET_BRANCH != '3.1' }}
|
||||
run: |
|
||||
cd ${{ env.WKC }}/tests/parallel_test
|
||||
./run_scan_container.sh -d ${{ env.WKDIR }} -b ${{ env.PR_NUMBER }}_${{ github.run_number }} -f ${{ env.WKDIR }}/tmp/${{ env.PR_NUMBER }}_${{ github.run_number }}/docs_changed.txt ${{ steps.get_param.outputs.extra_param }}
|
||||
- name: Run tdgpt test cases
|
||||
if: ${{ env.IS_TDINTERNAL }} == 'false' && ${{ env.RUN_TDGPT_TEST }} == 'true'
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' && env.TARGET_BRANCH != '3.1' && env.RUN_TDGPT_TEST == 'true' }}
|
||||
run: |
|
||||
cd ${{ env.WKC }}/tests/parallel_test
|
||||
export DEFAULT_RETRY_TIME=2
|
||||
date
|
||||
timeout 600 time ./run.sh -e -m /home/m.json -t tdgpt_cases.task -b ${{ env.PR_NUMBER }}_${{ github.run_number }} -l ${{ env.WKDIR }}/log -o 300 ${{ steps.get_param.outputs.extra_param }}
|
||||
- name: Run function test cases
|
||||
if: ${{ env.RUN_RUNCTION_TEST }} == 'true'
|
||||
if: ${{ env.RUN_RUNCTION_TEST == 'true'}}
|
||||
run: |
|
||||
cd ${{ env.WKC }}/tests/parallel_test
|
||||
export DEFAULT_RETRY_TIME=2
|
||||
|
@ -224,7 +228,7 @@ jobs:
|
|||
|
||||
run-tests-on-mac:
|
||||
needs: fetch-parameters
|
||||
if: ${{ needs.fetch-parameters.outputs.run_function_test == 'false' }}
|
||||
if: ${{ needs.fetch-parameters.outputs.run_function_test == 'true' }}
|
||||
runs-on:
|
||||
group: CI
|
||||
labels: [self-hosted, macOS, ARM64, testing]
|
||||
|
@ -313,3 +317,141 @@ jobs:
|
|||
make -j10
|
||||
ctest -j10 || exit 7
|
||||
date
|
||||
|
||||
run-tests-on-windows:
|
||||
needs: fetch-parameters
|
||||
if: ${{ needs.fetch-parameters.outputs.run_function_test == 'true' }}
|
||||
runs-on:
|
||||
group: CI
|
||||
labels: [self-hosted, Windows, X64, testing]
|
||||
timeout-minutes: 126
|
||||
env:
|
||||
IS_TDINTERNAL: ${{ needs.fetch-parameters.outputs.tdinternal }}
|
||||
SOURCE_BRANCH: ${{ needs.fetch-parameters.outputs.source_branch }}
|
||||
TARGET_BRANCH: ${{ needs.fetch-parameters.outputs.target_branch }}
|
||||
PR_NUMBER: ${{ needs.fetch-parameters.outputs.pr_number }}
|
||||
WIN_INTERNAL_ROOT: "C:\\workspace\\0\\TDinternal"
|
||||
WIN_COMMUNITY_ROOT: "C:\\workspace\\0\\TDinternal\\community"
|
||||
WIN_SYSTEM_TEST_ROOT: "C:\\workspace\\0\\TDinternal\\community\\tests\\system-test"
|
||||
WIN_VS_PATH: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat"
|
||||
WIN_CPU_TYPE: "x64"
|
||||
steps:
|
||||
- name: Output the environment information
|
||||
run: |
|
||||
hostname
|
||||
taskkill /f /t /im python.exe
|
||||
taskkill /f /t /im bash.exe
|
||||
taskkill /f /t /im taosd.exe
|
||||
ipconfig
|
||||
set
|
||||
date /t
|
||||
time /t
|
||||
rd /s /Q "%WIN_INTERNAL_ROOT%\debug" || exit 0
|
||||
shell: cmd
|
||||
- name: Prepare repositories
|
||||
run: |
|
||||
:: Prepare internal repository
|
||||
if exist "%WIN_INTERNAL_ROOT%" (
|
||||
cd /d "%WIN_INTERNAL_ROOT%"
|
||||
git reset --hard
|
||||
git clean -f
|
||||
git remote prune origin
|
||||
git fetch
|
||||
git checkout "%TARGET_BRANCH%"
|
||||
) else (
|
||||
echo Directory does not exist: "%WIN_INTERNAL_ROOT%"
|
||||
exit 1
|
||||
)
|
||||
|
||||
:: Prepare community repository
|
||||
if exist "%WIN_COMMUNITY_ROOT%" (
|
||||
cd /d "%WIN_COMMUNITY_ROOT%"
|
||||
git reset --hard
|
||||
git clean -f
|
||||
git remote prune origin
|
||||
git fetch
|
||||
git checkout "%TARGET_BRANCH%"
|
||||
) else (
|
||||
echo Directory does not exist: "%WIN_COMMUNITY_ROOT%"
|
||||
exit 1
|
||||
)
|
||||
shell: cmd
|
||||
- name: Get latest codes and logs for TDinternal PR
|
||||
if: ${{ env.IS_TDINTERNAL == 'true' }}
|
||||
run: |
|
||||
cd %WIN_INTERNAL_ROOT%
|
||||
git pull origin %TARGET_BRANCH%
|
||||
git fetch origin +refs/pull/%PR_NUMBER%/merge
|
||||
git checkout -qf FETCH_HEAD
|
||||
cd %WIN_COMMUNITY_ROOT%
|
||||
git remote prune origin
|
||||
git pull
|
||||
shell: cmd
|
||||
- name: Get latest codes and logs for TDengine PR
|
||||
if: ${{ env.IS_TDINTERNAL == 'false' }}
|
||||
run: |
|
||||
cd %WIN_INTERNAL_ROOT%
|
||||
git pull origin %TARGET_BRANCH%
|
||||
cd %WIN_COMMUNITY_ROOT%
|
||||
git remote prune origin
|
||||
git pull origin %TARGET_BRANCH%
|
||||
git fetch origin +refs/pull/%PR_NUMBER%/merge
|
||||
git checkout -qf FETCH_HEAD
|
||||
shell: cmd
|
||||
- name: Output branch and log information
|
||||
run: |
|
||||
cd %WIN_INTERNAL_ROOT%
|
||||
git branch
|
||||
git log -5
|
||||
|
||||
cd %WIN_COMMUNITY_ROOT%
|
||||
git branch
|
||||
git log -5
|
||||
shell: cmd
|
||||
- name: Update submodule
|
||||
run: |
|
||||
cd %WIN_COMMUNITY_ROOT%
|
||||
git submodule update --init --recursive
|
||||
shell: cmd
|
||||
- name: Build on windows
|
||||
run: |
|
||||
echo "building ..."
|
||||
time /t
|
||||
cd %WIN_INTERNAL_ROOT%
|
||||
mkdir debug
|
||||
cd debug
|
||||
time /t
|
||||
call "%WIN_VS_PATH%" %WIN_CPU_TYPE%
|
||||
set CL=/MP8
|
||||
echo ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cmake"
|
||||
time /t
|
||||
cmake .. -G "NMake Makefiles JOM" -DBUILD_TEST=true -DBUILD_TOOLS=true || exit 7
|
||||
echo ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jom -j 6"
|
||||
time /t
|
||||
jom -j 6 || exit 8
|
||||
time /t
|
||||
|
||||
cd %WIN_COMMUNITY_ROOT%/tests/ci
|
||||
pip3 install taospy==2.7.21
|
||||
pip3 install taos-ws-py==0.3.8
|
||||
xcopy /e/y/i/f %WIN_INTERNAL_ROOT%\\debug\\build\\lib\\taos.dll C:\\Windows\\System32
|
||||
shell: cmd
|
||||
- name: Run ctest
|
||||
run: |
|
||||
echo "windows ctest ..."
|
||||
time /t
|
||||
cd %WIN_INTERNAL_ROOT%\\debug
|
||||
ctest -j 1 || exit 7
|
||||
time /t
|
||||
shell: cmd
|
||||
- name: Run function test
|
||||
run: |
|
||||
echo "windows test ..."
|
||||
xcopy /e/y/i/f "%WIN_INTERNAL_ROOT%\debug\build\lib\taos.dll" C:\Windows\System32
|
||||
ls -l "C:\Windows\System32\taos.dll"
|
||||
time /t
|
||||
cd %WIN_SYSTEM_TEST_ROOT%
|
||||
echo "testing ..."
|
||||
test-all.bat ci
|
||||
time /t
|
||||
shell: cmd
|
||||
|
|
|
@ -5,7 +5,6 @@ on:
|
|||
branches:
|
||||
- 'main'
|
||||
- '3.0'
|
||||
- '3.1'
|
||||
paths:
|
||||
- 'docs/**'
|
||||
- '*.md'
|
||||
|
|
|
@ -53,6 +53,8 @@ It is not necessary to configure your cluster specifically for active-active mod
|
|||
- The sink endpoint is the FQDN of TDengine on the secondary node.
|
||||
- You can use the native connection (port 6030) or WebSocket connection (port 6041).
|
||||
- You can specify one or more databases to replicate only the data contained in those databases. If you do not specify a database, all databases on the node are replicated except for `information_schema`, `performance_schema`, `log`, and `audit`.
|
||||
- New databases in both sides will be detected periodically to start replication, with optional `--new-database-checking-interval <SECONDS>` argument.
|
||||
- New databases checking will be disabled with `--no-new-databases`.
|
||||
|
||||
When the command is successful, the replica ID is displayed. You can use this ID to add other databases to the replication task if necessary.
|
||||
|
||||
|
@ -97,7 +99,6 @@ You can manage your active-active deployment with the following commands:
|
|||
:::note
|
||||
- This command cannot create duplicate tasks. It only adds the specified databases to the specified task.
|
||||
- The replica ID is globally unique within a taosX instance and is independent of the source/sink combination.
|
||||
|
||||
:::
|
||||
|
||||
2. Check the status of a task:
|
||||
|
@ -124,6 +125,8 @@ You can manage your active-active deployment with the following commands:
|
|||
|
||||
If you specify a database, replication for that database is stopped. If you do not specify a database, all replication tasks on the ID are stopped. If you do not specify an ID, all replication tasks on the instance are stopped.
|
||||
|
||||
Use `--no-new-databases` to not stop new-databases checking.
|
||||
|
||||
4. Restart a replication task:
|
||||
|
||||
```shell
|
||||
|
@ -132,6 +135,14 @@ You can manage your active-active deployment with the following commands:
|
|||
|
||||
If you specify a database, replication for that database is restarted. If you do not specify a database, all replication tasks in the instance are restarted. If you do not specify an ID, all replication tasks on the instance are restarted.
|
||||
|
||||
5. Update new databases checking interval:
|
||||
|
||||
```shell
|
||||
taosx replica update id --new-database-checking-interval <SECONDS>
|
||||
```
|
||||
|
||||
This command will only update the checking interval for new databases.
|
||||
|
||||
5. Check the progress of a replication task:
|
||||
|
||||
```shell
|
||||
|
|
|
@ -537,8 +537,10 @@ This document details the server error codes that may be encountered when using
|
|||
|
||||
| Error Code | Description | Possible Error Scenarios or Reasons | Recommended Actions for Users |
|
||||
| ---------- | --------------------- | ------------------------------------------------------------ | -------------------------------------------- |
|
||||
| 0x800003E6 | Consumer not exist | Consumer timeout offline | rebuild consumer to subscribe data again |
|
||||
| 0x800003EA | Consumer not ready | Consumer rebalancing | retry after 2s |
|
||||
| 0x80004000 | Invalid message | The subscribed data is illegal, generally does not occur | Check the client-side error logs for details |
|
||||
| 0x80004001 | Consumer mismatch | The vnode requested for subscription and the reassigned vnode are inconsistent, usually occurs when new consumers join the same consumer group | Internal error, not exposed to users |
|
||||
| 0x80004001 | Consumer mismatch | The vnode requested for subscription and the reassigned vnode are inconsistent, usually occurs when new consumers join the same consumer group | Internal error |
|
||||
| 0x80004002 | Consumer closed | The consumer no longer exists | Check if it has already been closed |
|
||||
| 0x80004017 | Invalid status, please subscribe topic first | tmq status invalidate | Without calling subscribe, directly poll data |
|
||||
| 0x80004100 | Stream task not exist | The stream computing task does not exist | Check the server-side error logs |
|
||||
|
|
|
@ -4,19 +4,19 @@ sidebar_label: 文档首页
|
|||
slug: /
|
||||
---
|
||||
|
||||
TDengine 是一款[开源](https://www.taosdata.com/tdengine/open_source_time-series_database)、[高性能](https://www.taosdata.com/fast)、[云原生](https://www.taosdata.com/tdengine/cloud_native_time-series_database)的<a href="https://www.taosdata.com/" data-internallinksmanager029f6b8e52c="2" title="时序数据库" target="_blank" rel="noopener">时序数据库</a>(<a href="https://www.taosdata.com/time-series-database" data-internallinksmanager029f6b8e52c="9" title="Time Series DataBase" target="_blank" rel="noopener">Time Series Database</a>, <a href="https://www.taosdata.com/tsdb" data-internallinksmanager029f6b8e52c="8" title="TSDB" target="_blank" rel="noopener">TSDB</a>), 它专为物联网、车联网、工业互联网、金融、IT 运维等场景优化设计。同时它还带有内建的缓存、流式计算、数据订阅等系统功能,能大幅减少系统设计的复杂度,降低研发和运营成本,是一款极简的时序数据处理平台。本文档是 TDengine 的用户手册,主要是介绍 TDengine 的基本概念、安装、使用、功能、开发接口、运营维护、TDengine 内核设计等等,它主要是面向架构师、开发工程师与系统管理员的。如果你对时序数据的基本概念、价值以及其所能带来的业务价值尚不了解,请参考[时序数据基础](./concept)。
|
||||
TDengine 是一款 [开源](https://www.taosdata.com/tdengine/open_source_time-series_database)、[高性能](https://www.taosdata.com/fast)、[云原生](https://www.taosdata.com/tdengine/cloud_native_time-series_database) 的<a href="https://www.taosdata.com/" data-internallinksmanager029f6b8e52c="2" title="时序数据库" target="_blank" rel="noopener">时序数据库</a>(<a href="https://www.taosdata.com/time-series-database" data-internallinksmanager029f6b8e52c="9" title="Time Series DataBase" target="_blank" rel="noopener">Time Series Database</a>, <a href="https://www.taosdata.com/tsdb" data-internallinksmanager029f6b8e52c="8" title="TSDB" target="_blank" rel="noopener">TSDB</a>), 它专为物联网、车联网、工业互联网、金融、IT 运维等场景优化设计。同时它还带有内建的缓存、流式计算、数据订阅等系统功能,能大幅减少系统设计的复杂度,降低研发和运营成本,是一款极简的时序数据处理平台。本文档是 TDengine 的用户手册,主要是介绍 TDengine 的基本概念、安装、使用、功能、开发接口、运营维护、TDengine 内核设计等等,它主要是面向架构师、开发工程师与系统管理员的。如果你对时序数据的基本概念、价值以及其所能带来的业务价值尚不了解,请参考 [时序数据基础](./concept)。
|
||||
|
||||
TDengine 充分利用了时序数据的特点,提出了“一个数据采集点一张表”与“超级表”的概念,设计了创新的存储引擎,让数据的写入、查询和存储效率都得到极大的提升。为正确理解并使用 TDengine,无论你在工作中是什么角色,请您仔细阅读[数据模型](./basic/model)一章。
|
||||
TDengine 充分利用了时序数据的特点,提出了“一个数据采集点一张表”与“超级表”的概念,设计了创新的存储引擎,让数据的写入、查询和存储效率都得到极大的提升。为正确理解并使用 TDengine,无论你在工作中是什么角色,请您仔细阅读 [数据模型](./basic/model) 一章。
|
||||
|
||||
如果你是开发工程师,请一定仔细阅读[开发指南](./develop)一章,该部分对数据库连接、建模、写入、查询、流式计算、缓存、数据订阅、用户自定义函数等功能都做了详细介绍,并配有各种编程语言的示例代码。大部分情况下,只要复制粘贴示例代码,针对自己的应用稍作改动,就能跑起来。对 REST API、各种编程语言的连接器(Connector)想做更多详细了解,请看[连接器](./reference/connector)一章。
|
||||
如果你是开发工程师,请一定仔细阅读 [开发指南](./develop) 一章,该部分对数据库连接、建模、写入、查询、流式计算、缓存、数据订阅、用户自定义函数等功能都做了详细介绍,并配有各种编程语言的示例代码。大部分情况下,只要复制粘贴示例代码,针对自己的应用稍作改动,就能跑起来。对 REST API、各种编程语言的连接器(Connector)想做更多详细了解,请看 [连接器](./reference/connector) 一章。
|
||||
|
||||
我们已经生活在大数据时代,纵向扩展已经无法满足日益增长的业务需求,任何系统都必须具有水平扩展的能力,集群成为大数据以及 Database 系统的不可缺失功能。TDengine 团队不仅实现了集群功能,而且将这一重要核心功能开源。怎么部署、管理和维护 TDengine 集群,请仔细参考[运维管理](./operation)一章。
|
||||
我们已经生活在大数据时代,纵向扩展已经无法满足日益增长的业务需求,任何系统都必须具有水平扩展的能力,集群成为大数据以及 Database 系统的不可缺失功能。TDengine 团队不仅实现了集群功能,而且将这一重要核心功能开源。怎么部署、管理和维护 TDengine 集群,请仔细参考 [运维管理](./operation) 一章。
|
||||
|
||||
TDengine 采用 SQL 作为查询语言,大大降低学习成本、降低迁移成本,但同时针对时序数据场景,又做了一些扩展,以支持插值、降采样、时间加权平均等操作。[SQL 手册](./reference/taos-sql)一章详细描述了 SQL 语法、详细列出了各种支持的命令和函数。
|
||||
TDengine 采用 SQL 作为查询语言,大大降低学习成本、降低迁移成本,但同时针对时序数据场景,又做了一些扩展,以支持插值、降采样、时间加权平均等操作。[SQL 手册](./reference/taos-sql) 一章详细描述了 SQL 语法、详细列出了各种支持的命令和函数。
|
||||
|
||||
如果你是系统管理员,关心安装、升级、容错灾备、关心数据导入、导出、配置参数,如何监测 TDengine 是否健康运行,如何提升系统运行的性能,请仔细参考[运维指南](./operation)一章。
|
||||
如果你是系统管理员,关心安装、升级、容错灾备、关心数据导入、导出、配置参数,如何监测 TDengine 是否健康运行,如何提升系统运行的性能,请仔细参考 [运维指南](./operation) 一章。
|
||||
|
||||
如果你对数据库内核设计感兴趣,或是开源爱好者,建议仔细阅读[技术内幕](./tdinternal)一章。该章从分布式架构到存储引擎、查询引擎、数据订阅,再到流计算引擎都做了详细阐述。建议对照文档,查看 TDengine 在 GitHub 的源代码,对 TDengine 的设计和编码做深入了解,更欢迎加入开源社区,贡献代码。
|
||||
如果你对数据库内核设计感兴趣,或是开源爱好者,建议仔细阅读 [技术内幕](./tdinternal) 一章。该章从分布式架构到存储引擎、查询引擎、数据订阅,再到流计算引擎都做了详细阐述。建议对照文档,查看 TDengine 在 GitHub 的源代码,对 TDengine 的设计和编码做深入了解,更欢迎加入开源社区,贡献代码。
|
||||
|
||||
最后,作为一个开源软件,欢迎大家的参与。如果发现文档有任何错误、描述不清晰的地方,请在每个页面的最下方,点击“编辑本文档”直接进行修改。
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ toc_max_heading_level: 4
|
|||
|
||||
TDengine 是一个高性能、分布式的时序数据库。通过集成的缓存、数据订阅、流计算和数据清洗与转换等功能,TDengine 已经发展成为一个专为物联网、工业互联网、金融和 IT 运维等关键行业量身定制的时序大数据平台。该平台能够高效地汇聚、存储、分析、计算和分发来自海量数据采集点的大规模数据流,每日处理能力可达 TB 乃至 PB 级别。借助 TDengine,企业可以实现实时的业务监控和预警,进而发掘出有价值的商业洞察。
|
||||
|
||||
自 2019 年 7 月 以来, 涛思数据陆续将 TDengine 的不同版本开源,包括单机版(2019 年 7 月)、集群版(2020 年 8 月)以及云原生版(2022 年 8 月)。开源之后,TDengine 迅速获得了全球开发者的关注,多次在 GitHub 网站全球趋势排行榜上位居榜首,最新的关注热度见[涛思数据首页](https://www.taosdata.com/)。
|
||||
自 2019 年 7 月 以来, 涛思数据陆续将 TDengine 的不同版本开源,包括单机版(2019 年 7 月)、集群版(2020 年 8 月)以及云原生版(2022 年 8 月)。开源之后,TDengine 迅速获得了全球开发者的关注,多次在 GitHub 网站全球趋势排行榜上位居榜首,最新的关注热度见 [涛思数据首页](https://www.taosdata.com/)。
|
||||
|
||||
## TDengine 产品
|
||||
|
||||
|
@ -16,7 +16,7 @@ TDengine OSS 是一个开源的高性能时序数据库,与其他时序数据
|
|||
|
||||
在 TDengine OSS 的基础上,TDengine Enterprise 提供了增强的辅助功能,包括数据的备份恢复、异地容灾、多级存储、视图、权限控制、安全加密、IP 白名单、支持 MQTT、OPC-UA、OPC-DA、PI、Wonderware、Kafka 等各种数据源。这些功能为企业提供了更为全面、安全、可靠和高效的时序数据管理解决方案。更多的细节请看 [TDengine Enterprise](https://www.taosdata.com/tdengine-pro)。
|
||||
|
||||
此外,TDengine Cloud 作为一种全托管的云服务,存储与计算分离,分开计费,为企业提供了企业级的工具和服务,彻底解决了运维难题,尤其适合中小规模的用户使用。更多的细节请看[TDengine 云服务](https://cloud.taosdata.com/?utm_source=menu&utm_medium=webcn)
|
||||
此外,TDengine Cloud 作为一种全托管的云服务,存储与计算分离,分开计费,为企业提供了企业级的工具和服务,彻底解决了运维难题,尤其适合中小规模的用户使用。更多的细节请看 [TDengine 云服务](https://cloud.taosdata.com/?utm_source=menu&utm_medium=webcn)。
|
||||
|
||||
## TDengine 主要功能与特性
|
||||
|
||||
|
|
|
@ -154,8 +154,8 @@ let v3 = data["voltage"].split(",");
|
|||
|
||||
如下图所示
|
||||
|
||||
* 对字段`ts`使用 split 规则拆分成日期和时间。split 规则需要设置**分隔符**和**拆分数量**,拆分后的字段命名规则为`{原字段名}_{顺序号}`。
|
||||
* 对字段`voltage`使用正则表达式 `^(?<voltage>[0-9]+)(?<voltage_unit>[a-zA-Z]+)$` 提取出电压值和电压单位,Regex 规则同解析过程中的一样,使用**命名捕获组**命名提取字段。
|
||||
* 对字段 `ts` 使用 split 规则拆分成日期和时间。split 规则需要设置 **分隔符** 和 **拆分数量**,拆分后的字段命名规则为 `{原字段名}_{顺序号}`。
|
||||
* 对字段 `voltage` 使用正则表达式 `^(?<voltage>[0-9]+)(?<voltage_unit>[a-zA-Z]+)$` 提取出电压值和电压单位,Regex 规则同解析过程中的一样,使用 **命名捕获组** 命名提取字段。
|
||||
* 对字段 `location` 使用 convert 转换,填写一个 JSON map 对象,其中 key 为字段 `current` 的值,`value` 为转换后的值。如图,`location` 字段的值 `"beijing.chaoyang.datun"` 被转换为 `"beijing.chaoyang.datunludong"`。
|
||||
|
||||

|
||||
|
|
|
@ -7,7 +7,7 @@ toc_max_heading_level: 4
|
|||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
TDengine 对 SQL 语言提供了全面的支持,允许用户以熟悉的 SQL 语法进行数据的查询、插入和删除操作。 TDengine 的 SQL 还支持对数据库和数据表的管理操作,如创建、修改和删除数据库及数据表。TDengine 扩展了标准 SQL,引入了时序数据处理特有的功能,如时间序列数据的聚合查询、降采样、插值查询等,以适应时序数据的特点。这些扩展使得用户可以更高效地处理时间序列数据,进行复杂的数据分析和处理。 具体支持的 SQL 语法请参考 [TDengine SQL](../../reference/taos-sql/)
|
||||
TDengine 对 SQL 语言提供了全面的支持,允许用户以熟悉的 SQL 语法进行数据的查询、插入和删除操作。TDengine 的 SQL 还支持对数据库和数据表的管理操作,如创建、修改和删除数据库及数据表。TDengine 扩展了标准 SQL,引入了时序数据处理特有的功能,如时间序列数据的聚合查询、降采样、插值查询等,以适应时序数据的特点。这些扩展使得用户可以更高效地处理时间序列数据,进行复杂的数据分析和处理。具体支持的 SQL 语法请参考 [TDengine SQL](../../reference/taos-sql/)
|
||||
|
||||
下面介绍使用各语言连接器通过执行 SQL 完成建库、建表、写入数据和查询数据。
|
||||
|
||||
|
@ -108,7 +108,7 @@ curl --location -uroot:taosdata 'http://127.0.0.1:6041/rest/sql/power' \
|
|||
```
|
||||
|
||||
**Note**
|
||||
NOW 为系统内部函数,默认为客户端所在计算机当前时间。 NOW + 1s 代表客户端当前时间往后加 1 秒,数字后面代表时间单位:a(毫秒),s(秒),m(分),h(小时),d(天),w(周),n(月),y(年)。
|
||||
NOW 为系统内部函数,默认为客户端所在计算机当前时间。NOW + 1s 代表客户端当前时间往后加 1 秒,数字后面代表时间单位:a(毫秒),s(秒),m(分),h(小时),d(天),w(周),n(月),y(年)。
|
||||
|
||||
|
||||
</TabItem>
|
||||
|
@ -160,7 +160,7 @@ NOW 为系统内部函数,默认为客户端所在计算机当前时间。 NOW
|
|||
```
|
||||
|
||||
**Note**
|
||||
NOW 为系统内部函数,默认为客户端所在计算机当前时间。 NOW + 1s 代表客户端当前时间往后加 1 秒,数字后面代表时间单位:a(毫秒),s(秒),m(分),h(小时),d(天),w(周),n(月),y(年)。
|
||||
NOW 为系统内部函数,默认为客户端所在计算机当前时间。NOW + 1s 代表客户端当前时间往后加 1 秒,数字后面代表时间单位:a(毫秒),s(秒),m(分),h(小时),d(天),w(周),n(月),y(年)。
|
||||
</TabItem>
|
||||
<TabItem label="REST API" value="rest">
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ import TabItem from "@theme/TabItem";
|
|||
|
||||
## 无模式写入行协议
|
||||
|
||||
TDengine 的无模式写入行协议兼容 InfluxDB 的行协议、OpenTSDB 的 telnet 行协议和 OpenTSDB 的 JSON 格式协议。InfluxDB、OpenTSDB 的标准写入协议请参考各自的官方文档。
|
||||
TDengine 的无模式写入行协议兼容 InfluxDB 的行协议、OpenTSDB 的 TELNET 行协议和 OpenTSDB 的 JSON 格式协议。InfluxDB、OpenTSDB 的标准写入协议请参考各自的官方文档。
|
||||
|
||||
下面首先以 InfluxDB 的行协议为基础,介绍 TDengine 扩展的协议内容。该协议允许用户采用更加精细的方式控制(超级表)模式。采用一个字符串来表达一个数据行,可以向写入 API 中一次传入多行字符串来实现多个数据行的批量写入,其格式约定如下。
|
||||
|
||||
|
@ -36,7 +36,7 @@ tag_set 中的所有的数据自动转化为 nchar 数据类型,并不需要
|
|||
在无模式写入数据行协议中,field_set 中的每个数据项都需要对自身的数据类型进行描述,具体要求如下。
|
||||
- 如果两边有英文双引号,表示 varchar 类型,例如 "abc"。
|
||||
- 如果两边有英文双引号而且带有 L 或 l 前缀,表示 nchar 类型,例如 L" 报错信息 "。
|
||||
- 如果两边有英文双引号而且带有 G 或 g 前缀, 表 示 geometry 类型, 例 如G"Point(4.343 89.342)"。
|
||||
- 如果两边有英文双引号而且带有 G 或 g 前缀,表示 geometry 类型,例如 G"Point(4.343 89.342)"。
|
||||
- 如果两边有英文双引号而且带有 B 或 b 前缀,表示 varbinary 类型,双引号内可以为 \x 开头的十六进制或者字符串,例如 B"\x98f46e" 和 B"hello"。
|
||||
- 对于空格、等号(=)、逗号(,)、双引号(")、反斜杠(\),前面需要使用反斜杠(\)进行转义(均为英文半角符号)。无模式写入协议的域转义规则如下表所示。
|
||||
|
||||
|
@ -48,7 +48,7 @@ tag_set 中的所有的数据自动转化为 nchar 数据类型,并不需要
|
|||
| 4 | 列名 | 逗号,等号,空格 |
|
||||
| 5 | 列值 | 双引号,反斜杠 |
|
||||
|
||||
如果使用两个连续的反斜杠,则第1个反斜杠作为转义符,当只有一个反斜杠时则无须转义。无模式写入协议的反斜杠转义规则如下表所示。
|
||||
如果使用两个连续的反斜杠,则第 1 个反斜杠作为转义符,当只有一个反斜杠时则无须转义。无模式写入协议的反斜杠转义规则如下表所示。
|
||||
|
||||
| **序号** | **反斜杠** | **转义为** |
|
||||
| -------- | ------------ | ---------- |
|
||||
|
@ -70,10 +70,9 @@ tag_set 中的所有的数据自动转化为 nchar 数据类型,并不需要
|
|||
| 5 | i32/u32 | Int/UInt | 4 |
|
||||
| 6 | i64/i/u64/u | BigInt/BigInt/UBigInt/UBigInt | 8 |
|
||||
|
||||
- t, T, true, True, TRUE, f, F, false, False 将直接作为 BOOL 型来处理。
|
||||
- t、T、true、True、TRUE、f、F、false、False 将直接作为 BOOL 型来处理。
|
||||
|
||||
例如如下数据行表示:向名为 st 的超级表下的 t1 标签为 "3"(NCHAR)、t2 标签为 "4"(NCHAR)、t3
|
||||
标签为 "t3"(NCHAR)的数据子表,写入 c1 列为 3(BIGINT)、c2 列为 false(BOOL)、c3
|
||||
例如如下数据行表示:向名为 st 的超级表下的 t1 标签为 "3"(NCHAR)、t2 标签为 "4"(NCHAR)、t3 标签为 "t3"(NCHAR)的数据子表,写入 c1 列为 3(BIGINT)、c2 列为 false(BOOL)、c3
|
||||
列为 "passit"(BINARY)、c4 列为 4(DOUBLE)、主键时间戳为 1626006833639000000 的一行数据。
|
||||
|
||||
```json
|
||||
|
@ -94,30 +93,28 @@ TDengine 提供数据写入的幂等性保证,即您可以反复调用 API 进
|
|||
"measurement,tag_key1=tag_value1,tag_key2=tag_value2"
|
||||
```
|
||||
|
||||
- 需要注意的是,这里的 tag_key1, tag_key2 并不是用户输入的标签的原始顺序,而是使用了标签名称按照字符串升序排列后的结果。所以,tag_key1 并不是在行协议中输入的第一个标签。
|
||||
排列完成以后计算该字符串的 MD5 散列值 "md5_val"。然后将计算的结果与字符串组合生成表名:“t_md5_val”。其中的 “t_” 是固定的前缀,每个通过该映射关系自动生成的表都具有该前缀。
|
||||
- 需要注意的是,这里的 tag_key1、tag_key2 并不是用户输入的标签的原始顺序,而是使用了标签名称按照字符串升序排列后的结果。所以,tag_key1 并不是在行协议中输入的第一个标签。
|
||||
排列完成以后计算该字符串的 MD5 散列值 "md5_val"。然后将计算的结果与字符串组合生成表名:"t_md5_val"。其中的 "t_" 是固定的前缀,每个通过该映射关系自动生成的表都具有该前缀。
|
||||
|
||||
- 如果不想用自动生成的表名,有两种指定子表名的方式(第一种优先级更高)。
|
||||
1. 通过在taos.cfg里配置 smlAutoChildTableNameDelimiter 参数来指定(`@ # 空格 回车 换行 制表符`除外)。
|
||||
1. 举例如下:配置 smlAutoChildTableNameDelimiter=- 插入数据为 st,t0=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1-4。
|
||||
2. 通过在taos.cfg里配置 smlChildTableName 参数来指定。
|
||||
1. 举例如下:配置 smlChildTableName=tname 插入数据为 st,tname=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1,注意如果多行数据 tname 相同,但是后面的 tag_set 不同,则使用第一行自动建表时指定的 tag_set,其他的行会忽略。
|
||||
- 如果不想用自动生成的表名,有两种指定子表名的方式(第一种优先级更高)。
|
||||
- 通过在 taos.cfg 里配置 smlAutoChildTableNameDelimiter 参数来指定(`@ # 空格 回车 换行 制表符` 除外),例如配置 smlAutoChildTableNameDelimiter=- 插入数据为 st,t0=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1-4。
|
||||
- 通过在 taos.cfg 里配置 smlChildTableName 参数来指定,例如配置 smlChildTableName=tname 插入数据为 st,tname=cpu1,t1=4 c1=3 1626006833639000000 则创建的表名为 cpu1,注意如果多行数据 tname 相同,但是后面的 tag_set 不同,则使用第一行自动建表时指定的 tag_set,其他的行会忽略。
|
||||
|
||||
2. 如果解析行协议获得的超级表不存在,则会创建这个超级表(不建议手动创建超级表,不然插入数据可能异常)。
|
||||
3. 如果解析行协议获得子表不存在,则 Schemaless 会按照步骤 1 或 2 确定的子表名来创建子表。
|
||||
3. 如果解析行协议获得子表不存在,则 schemaless 会按照步骤 1 或 2 确定的子表名来创建子表。
|
||||
4. 如果数据行中指定的标签列或普通列不存在,则在超级表中增加对应的标签列或普通列(只增不减)。
|
||||
5. 如果超级表中存在一些标签列或普通列未在一个数据行中被指定取值,那么这些列的值在这一行中会被置为 NULL。
|
||||
6. 对 BINARY 或 NCHAR 列,如果数据行中所提供值的长度超出了列类型的限制,自动增加该列允许存储的字符长度上限(只增不减),以保证数据的完整保存。
|
||||
7. 整个处理过程中遇到的错误会中断写入过程,并返回错误代码。
|
||||
8. 为了提高写入的效率,默认假设同一个超级表中 field_set 的顺序是一样的(第一条数据包含所有的 field,后面的数据按照这个顺序),如果顺序不一样,需要配置参数 smlDataFormat 为 false,否则,数据写入按照相同顺序写入,库中数据会异常,从3.0.3.0开始,自动检测顺序是否一致,该配置废弃。
|
||||
9. 由于sql建表表名不支持点号(.),所以schemaless也对点号(.)做了处理,如果schemaless自动建表的表名如果有点号(.),会自动替换为下划线(\_)。如果手动指定子表名的话,子表名里有点号(.),同样转化为下划线(\_)。
|
||||
10. taos.cfg 增加 smlTsDefaultName 配置(值为字符串),只在client端起作用,配置后,schemaless自动建表的时间列名字可以通过该配置设置。不配置的话,默认为 _ts。
|
||||
8. 为了提高写入的效率,默认假设同一个超级表中 field_set 的顺序是一样的(第一条数据包含所有的 field,后面的数据按照这个顺序),如果顺序不一样,需要配置参数 smlDataFormat 为 false,否则,数据写入按照相同顺序写入,库中数据会异常,从 3.0.3.0 开始,自动检测顺序是否一致,该配置废弃。
|
||||
9. 由于 sql 建表表名不支持点号(.),所以 schemaless 也对点号(.)做了处理,如果 schemaless 自动建表的表名如果有点号(.),会自动替换为下划线(\_)。如果手动指定子表名的话,子表名里有点号(.),同样转化为下划线(\_)。
|
||||
10. taos.cfg 增加 smlTsDefaultName 配置(字符串类型),只在 client 端起作用,配置后,schemaless 自动建表的时间列名字可以通过该配置设置。不配置的话,默认为 _ts。
|
||||
11. 无模式写入的数据超级表或子表名区分大小写。
|
||||
12. 无模式写入仍然遵循 TDengine 对数据结构的底层限制,例如每行数据的总长度不能超过 48KB(从 3.0.5.0 版本开始为 64KB),标签值的总长度不超过16KB。
|
||||
12. 无模式写入仍然遵循 TDengine 对数据结构的底层限制,例如每行数据的总长度不能超过 48KB(从 3.0.5.0 版本开始为 64KB),标签值的总长度不超过 16KB。
|
||||
|
||||
## 时间分辨率识别
|
||||
|
||||
无模式写入支持3个指定的模式,如下表所示:
|
||||
无模式写入支持 3 个指定的模式,如下表所示:
|
||||
|
||||
| **序号** | **值** | **说明** |
|
||||
| -------- | ------------------- | ------------------------------- |
|
||||
|
@ -141,13 +138,13 @@ TDengine 提供数据写入的幂等性保证,即您可以反复调用 API 进
|
|||
|
||||
## 数据模式映射规则
|
||||
|
||||
InfluxDB行协议的数据将被映射成具有模式的数据,其中,measurement映射为超级表名称,tag_set中的标签名称映射为数据模式中的标签名,field_set中的名称映射为列名称。例如下面的数据。
|
||||
InfluxDB 行协议的数据将被映射成具有模式的数据,其中,measurement 映射为超级表名称,tag_set 中的标签名称映射为数据模式中的标签名,field_set 中的名称映射为列名称。例如下面的数据。
|
||||
|
||||
```json
|
||||
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000
|
||||
```
|
||||
|
||||
该行数据映射生成一个超级表: st, 其包含了 3 个类型为 nchar 的标签,分别是:t1, t2, t3。五个数据列,分别是 ts(timestamp),c1 (bigint),c3(binary),c2 (bool), c4 (bigint)。映射成为如下 SQL 语句:
|
||||
该行数据映射生成一个超级表:st, 其包含了 3 个类型为 nchar 的标签,分别是:t1、t2、t3。五个数据列,分别是 ts(timestamp)、c1 (bigint)、c3(binary)、c2 (bool)、c4 (bigint)。映射成为如下 SQL 语句:
|
||||
|
||||
```json
|
||||
create stable st (_ts timestamp, c1 bigint, c2 bool, c3 binary(6), c4 bigint) tags(t1 nchar(1), t2 nchar(1), t3 nchar(2))
|
||||
|
@ -164,7 +161,7 @@ st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4 1626006833639000000
|
|||
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4i 1626006833640000000
|
||||
```
|
||||
|
||||
第一行的数据类型映射将 c4 列定义为 Double, 但是第二行的数据又通过数值后缀方式声明该列为 BigInt, 由此会触发无模式写入的解析错误。
|
||||
第一行的数据类型映射将 c4 列定义为 Double, 但是第二行的数据又通过数值后缀方式声明该列为 bigInt, 由此会触发无模式写入的解析错误。
|
||||
|
||||
如果列前面的行协议将数据列声明为了 binary, 后续的要求长度更长的 binary 长度,此时会触发超级表模式的变更。
|
||||
|
||||
|
@ -299,7 +296,7 @@ writer.write(lineDemo, SchemalessProtocolType.LINE, SchemalessTimestampType.NANO
|
|||
|
||||
## 查询写入的数据
|
||||
|
||||
运行上节的样例代码,会在 power 数据库l中自动建表,我们可以通过 TDengine CLI 或者应用程序来查询数据。下面给出用 TDengine CLI 查询超级表和 meters 表数据的样例。
|
||||
运行上节的样例代码,会在 power 数据库中自动建表,我们可以通过 TDengine CLI 或者应用程序来查询数据。下面给出用 TDengine CLI 查询超级表和 meters 表数据的样例。
|
||||
|
||||
```shell
|
||||
taos> show power.stables;
|
||||
|
|
|
@ -7,7 +7,7 @@ toc_max_heading_level: 4
|
|||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
通过参数绑定方式写入数据时,能避免SQL语法解析的资源消耗,从而显著提升写入性能。参数绑定能提高写入效率的原因主要有以下几点:
|
||||
通过参数绑定方式写入数据时,能避免 SQL 语法解析的资源消耗,从而显著提升写入性能。参数绑定能提高写入效率的原因主要有以下几点:
|
||||
|
||||
- 减少解析时间:通过参数绑定,SQL 语句的结构在第一次执行时就已经确定,后续的执行只需要替换参数值,这样可以避免每次执行时都进行语法解析,从而减少解析时间。
|
||||
- 预编译:当使用参数绑定时,SQL 语句可以被预编译并缓存,后续使用不同的参数值执行时,可以直接使用预编译的版本,提高执行效率。
|
||||
|
@ -19,9 +19,9 @@ import TabItem from "@theme/TabItem";
|
|||
我们只推荐使用下面两种形式的 SQL 进行参数绑定写入:
|
||||
|
||||
```sql
|
||||
一、确定子表存在:
|
||||
一、确定子表存在
|
||||
1. INSERT INTO meters (tbname, ts, current, voltage, phase) VALUES(?, ?, ?, ?, ?)
|
||||
二、自动建表:
|
||||
二、自动建表
|
||||
1. INSERT INTO meters (tbname, ts, current, voltage, phase, location, group_id) VALUES(?, ?, ?, ?, ?, ?, ?)
|
||||
2. INSERT INTO ? USING meters TAGS (?, ?) VALUES (?, ?, ?, ?)
|
||||
```
|
||||
|
@ -50,7 +50,7 @@ import TabItem from "@theme/TabItem";
|
|||
{{#include docs/examples/java/src/main/java/com/taos/example/WSParameterBindingExtendInterfaceDemo.java:para_bind}}
|
||||
```
|
||||
|
||||
这是一个[更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/WSParameterBindingFullDemo.java)
|
||||
这是一个 [更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/WSParameterBindingFullDemo.java)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Python" value="python">
|
||||
|
@ -100,7 +100,7 @@ import TabItem from "@theme/TabItem";
|
|||
{{#include docs/examples/java/src/main/java/com/taos/example/ParameterBindingBasicDemo.java:para_bind}}
|
||||
```
|
||||
|
||||
这是一个[更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/ParameterBindingFullDemo.java)
|
||||
这是一个 [更详细的参数绑定示例](https://github.com/taosdata/TDengine/blob/main/docs/examples/java/src/main/java/com/taos/example/ParameterBindingFullDemo.java)
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Python" value="python">
|
||||
|
|
|
@ -10,13 +10,13 @@ import TabItem from "@theme/TabItem";
|
|||
TDengine 提供了类似于消息队列产品的数据订阅和消费接口。在许多场景中,采用 TDengine 的时序大数据平台,无须再集成消息队列产品,从而简化应用程序设计并降低运维成本。本章介绍各语言连接器数据订阅的相关 API 以及使用方法。 数据订阅的基础知识请参考 [数据订阅](../../advanced/subscription/)
|
||||
|
||||
## 创建主题
|
||||
请用 TDengine CLI 或者 参考 [执行 SQL](../sql/) 章节用程序执行创建主题的 SQL:`CREATE TOPIC IF NOT EXISTS topic_meters AS SELECT ts, current, voltage, phase, groupid, location FROM meters`
|
||||
请用 TDengine CLI 或者参考 [执行 SQL](../sql/) 章节用程序执行创建主题的 SQL:`CREATE TOPIC IF NOT EXISTS topic_meters AS SELECT ts, current, voltage, phase, groupid, location FROM meters`
|
||||
|
||||
上述 SQL 将创建一个名为 topic_meters 的订阅。使用该订阅所获取的消息中的每条记录都由此查询语句 `SELECT ts, current, voltage, phase, groupid, location FROM meters` 所选择的列组成。
|
||||
|
||||
**注意**
|
||||
在 TDengine 连接器实现中,对于订阅查询,有以下限制。
|
||||
- 查询语句限制:订阅查询只能使用 select 语句,并不支持其他类型的SQL,如订阅库,订阅超级表(非 select 方式),insert、update 或 delete 等。
|
||||
- 查询语句限制:订阅查询只能使用 select 语句,并不支持其他类型的 SQL,如订阅库、订阅超级表(非 select 方式)、insert、update 或 delete 等。
|
||||
- 原始始数据查询:订阅查询只能查询原始数据,而不能查询聚合或计算结果。
|
||||
- 时间顺序限制:订阅查询只能按照时间正序查询数据。
|
||||
|
||||
|
@ -28,25 +28,82 @@ TDengine 消费者的概念跟 Kafka 类似,消费者通过订阅主题来接
|
|||
### 创建参数
|
||||
创建消费者的参数较多,非常灵活的支持了各种连接类型、 Offset 提交方式、压缩、重连、反序列化等特性。各语言连接器都适用的通用基础配置项如下表所示:
|
||||
|
||||
| 参数名称 | 类型 | 参数说明 | 备注 |
|
||||
| :-----------------------: | :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `td.connect.ip` | string | 服务端的 FQDN | 可以是ip或者host name |
|
||||
| `td.connect.user` | string | 用户名 | |
|
||||
| `td.connect.pass` | string | 密码 | |
|
||||
| `td.connect.port` | integer | 服务端的端口号 | |
|
||||
| `group.id` | string | 消费组 ID,同一消费组共享消费进度 | <br />**必填项**。最大长度:192,超长将截断。<br />每个topic最多可建立 100 个 consumer group |
|
||||
| `client.id` | string | 客户端 ID | 最大长度:255,超长将截断。 |
|
||||
| `auto.offset.reset` | enum | 消费组订阅的初始位置 | <br />`earliest`: default(version < 3.2.0.0);从头开始订阅; <br/>`latest`: default(version >= 3.2.0.0);仅从最新数据开始订阅; <br/>`none`: 没有提交的 offset 无法订阅 |
|
||||
| `enable.auto.commit` | boolean | 是否启用消费位点自动提交,true: 自动提交,客户端应用无需commit;false:客户端应用需要自行commit | 默认值为 true |
|
||||
| `auto.commit.interval.ms` | integer | 消费记录自动提交消费位点时间间隔,单位为毫秒 | 默认值为 5000 |
|
||||
| `msg.with.table.name` | boolean | 是否允许从消息中解析表名, 不适用于列订阅(列订阅时可将 tbname 作为列写入 subquery 语句)(从 3.2.0.0 版本该参数废弃,恒为 true) | 默认关闭 |
|
||||
| `enable.replay` | boolean | 是否开启数据回放功能 | 默认关闭 |
|
||||
| `session.timeout.ms` | integer | consumer 心跳丢失后超时时间,超时后会触发 rebalance 逻辑,成功后该 consumer 会被删除(从 3.3.3.0 版本开始支持) | 默认值为 12000,取值范围 [6000, 1800000] |
|
||||
| `max.poll.interval.ms` | integer | consumer poll 拉取数据间隔的最长时间,超过该时间,会认为该 consumer 离线,触发 rebalance 逻辑,成功后该 consumer 会被删除(从 3.3.3.0 版本开始支持) | 默认值为 300000,[1000,INT32_MAX] |
|
||||
| `fetch.max.wait.ms` | integer | 服务端单次返回数据的最大耗时(从 3.3.6.0 版本开始支持) | 默认值为 1000,[1,INT32_MAX] |
|
||||
| `min.poll.rows` | integer | 服务端单次返回数据的最小条数(从 3.3.6.0 版本开始支持) | 默认值为 4096,[1,INT32_MAX] |
|
||||
| `msg.consume.rawdata` | integer | 消费数据时拉取数据类型为二进制类型,不可做解析操作,内部参数,只用于 taosX 数据迁移(从 3.3.6.0 版本开始支持) | 默认值为 0 表示不起效, 非 0 为 起效 |
|
||||
#### td.connect.ip
|
||||
- 说明:服务端的 FQDN
|
||||
- 类型:string
|
||||
- 备注:可以是 ip 或者 host name
|
||||
|
||||
#### td.connect.user
|
||||
- 说明:用户名
|
||||
- 类型:string
|
||||
|
||||
#### td.connect.pass
|
||||
- 说明:密码
|
||||
- 类型:string
|
||||
|
||||
#### td.connect.port
|
||||
- 说明:服务端的端口号
|
||||
- 类型:integer
|
||||
|
||||
#### group.id
|
||||
- 说明:消费组 ID,同一消费组共享消费进度
|
||||
- 类型:string
|
||||
- 备注:**必填项**。最大长度:192,超长将截断。<br />每个topic最多可建立 100 个 consumer group
|
||||
|
||||
#### client.id
|
||||
- 说明:客户端 ID
|
||||
- 类型:string
|
||||
- 备注:最大长度 255,超长将截断
|
||||
|
||||
#### auto.offset.reset
|
||||
- 说明:消费组订阅的初始位置
|
||||
- 类型:enum
|
||||
- 备注:<br />`earliest`:default(version < 3.2.0.0),从头开始订阅;<br/>`latest`:default(version >= 3.2.0.0),仅从最新数据开始订阅;<br/>`none`:没有提交的 offset 无法订阅。
|
||||
|
||||
#### enable.auto.commit
|
||||
- 说明:是否启用消费位点自动提交
|
||||
- 类型:boolean
|
||||
- 备注:true:自动提交,客户端应用无需 commit;false:客户端应用需要自行 commit;默认值为 true。
|
||||
|
||||
#### auto.commit.interval.ms
|
||||
- 说明:消费记录自动提交消费位点时间间隔
|
||||
- 类型:integer
|
||||
- 备注:单位为毫秒,默认值为 5000
|
||||
|
||||
#### msg.with.table.name
|
||||
- 说明:是否允许从消息中解析表名
|
||||
- 类型:boolean
|
||||
- 备注:不适用于列订阅(列订阅时可将 tbname 作为列写入 subquery 语句),默认关闭。v3.2.0.0 该参数废弃。
|
||||
|
||||
#### enable.replay
|
||||
- 说明:是否开启数据回放功能
|
||||
- 类型:boolean
|
||||
- 备注:默认关闭
|
||||
|
||||
#### session.timeout.ms
|
||||
- 说明:consumer 心跳丢失后超时时间
|
||||
- 类型:integer
|
||||
- 备注:超时后会触发 rebalance 逻辑,成功后该 consumer 会被删除。默认值为 12000,取值范围 [6000,1800000]。v3.3.3.0 开始支持)
|
||||
|
||||
#### max.poll.interval.ms
|
||||
- 说明:consumer poll 拉取数据间隔的最长时间
|
||||
- 类型:integer
|
||||
- 备注:超过该时间,会认为该 consumer 离线,触发 rebalance 逻辑,成功后该 consumer 会被删除。默认值为 300000,[1000,INT32_MAX]。v3.3.3.0 开始支持。
|
||||
|
||||
#### fetch.max.wait.ms
|
||||
- 说明:服务端单次返回数据的最大耗时
|
||||
- 类型:integer
|
||||
- 备注:默认值为 1000,[1,INT32_MAX]。v3.3.6.0 开始支持。
|
||||
|
||||
#### min.poll.rows
|
||||
- 说明:服务端单次返回数据的最小条数
|
||||
- 类型:integer
|
||||
- 备注:默认值为 4096,[1,INT32_MAX]。v3.3.6.0 开始支持。
|
||||
|
||||
#### msg.consume.rawdata
|
||||
- 说明:消费数据时拉取数据类型为二进制类型,不可做解析操作 `内部参数,只用于 taosX 数据迁移`
|
||||
- 类型:integer
|
||||
- 备注:默认值为 0 表示不起效,非 0 为起效。v3.3.6.0 开始支持。
|
||||
|
||||
下面是各语言连接器创建参数:
|
||||
<Tabs defaultValue="java" groupId="lang">
|
||||
|
|
|
@ -107,7 +107,7 @@ int32_t scalarfn_destroy() {
|
|||
```
|
||||
### 聚合函数模板
|
||||
|
||||
用C语言开发聚合函数的模板如下。
|
||||
用 C 语言开发聚合函数的模板如下。
|
||||
```c
|
||||
#include "taos.h"
|
||||
#include "taoserror.h"
|
||||
|
@ -292,13 +292,13 @@ select max_vol(vol1, vol2, vol3, deviceid) from battery;
|
|||
### 准备环境
|
||||
|
||||
准备环境的具体步骤如下:
|
||||
- 第1步,准备好 Python 运行环境。
|
||||
- 第2步,安装 Python 包 taospyudf。命令如下。
|
||||
- 第 1 步,准备好 Python 运行环境。
|
||||
- 第 2 步,安装 Python 包 taospyudf。命令如下。
|
||||
```shell
|
||||
pip3 install taospyudf
|
||||
```
|
||||
- 第3步,执行命令 ldconfig。
|
||||
- 第4步,启动 taosd 服务。
|
||||
- 第 3 步,执行命令 ldconfig。
|
||||
- 第 4 步,启动 taosd 服务。
|
||||
|
||||
安装过程中会编译 C++ 源码,因此系统上要有 cmake 和 gcc。编译生成的 libtaospyudf.so 文件自动会被复制到 /usr/local/lib/ 目录,因此如果是非 root 用户,安装时需加 sudo。安装完可以检查这个目录是否有了这个文件:
|
||||
|
||||
|
@ -323,7 +323,7 @@ def process(input: datablock) -> tuple[output_type]:
|
|||
```
|
||||
|
||||
主要参数说明如下:
|
||||
- input:datablock 类似二维矩阵,通过成员方法 data(row, col) 读取位于 row 行、col 列的 python 对象
|
||||
- input:datablock 类似二维矩阵,通过成员方法 data(row, col) 读取位于 row 行、col 列的 Python 对象
|
||||
- 返回值是一个 Python 对象元组,每个元素类型为输出类型。
|
||||
|
||||
#### 聚合函数接口
|
||||
|
@ -389,7 +389,7 @@ def finish(buf: bytes) -> output_type:
|
|||
|
||||
### 数据类型映射
|
||||
|
||||
下表描述了TDengine SQL 数据类型和 Python 数据类型的映射。任何类型的 NULL 值都映射成 Python 的 None 值。
|
||||
下表描述了 TDengine SQL 数据类型和 Python 数据类型的映射。任何类型的 NULL 值都映射成 Python 的 None 值。
|
||||
|
||||
| **TDengine SQL数据类型** | **Python数据类型** |
|
||||
| :-----------------------: | ------------ |
|
||||
|
@ -405,7 +405,7 @@ def finish(buf: bytes) -> output_type:
|
|||
|
||||
本文内容由浅入深包括 5 个示例程序,同时也包含大量实用的 debug 技巧。
|
||||
|
||||
注意:**UDF 内无法通过 print 函数输出日志,需要自己写文件或用 python 内置的 logging 库写文件**。
|
||||
注意:**UDF 内无法通过 print 函数输出日志,需要自己写文件或用 Python 内置的 logging 库写文件**。
|
||||
|
||||
#### 示例一
|
||||
|
||||
|
@ -652,7 +652,7 @@ tail -20 taospyudf.log
|
|||
2023-05-25 11:42:34.541 ERROR [1679419] [PyUdf::PyUdf@217] py udf load module failure. error ModuleNotFoundError: No module named 'moment'
|
||||
```
|
||||
|
||||
这是因为 “moment” 所在位置不在 python udf 插件默认的库搜索路径中。怎么确认这一点呢?通过以下命令搜索 taospyudf.log。
|
||||
这是因为 “moment” 所在位置不在 Python udf 插件默认的库搜索路径中。怎么确认这一点呢?通过以下命令搜索 taospyudf.log。
|
||||
|
||||
```shell
|
||||
grep 'sys path' taospyudf.log | tail -1
|
||||
|
@ -664,7 +664,7 @@ grep 'sys path' taospyudf.log | tail -1
|
|||
2023-05-25 10:58:48.554 INFO [1679419] [doPyOpen@592] python sys path: ['', '/lib/python38.zip', '/lib/python3.8', '/lib/python3.8/lib-dynload', '/lib/python3/dist-packages', '/var/lib/taos//.udf']
|
||||
```
|
||||
|
||||
发现 python udf 插件默认搜索的第三方库安装路径是: /lib/python3/dist-packages,而 moment 默认安装到了 /usr/local/lib/python3.8/dist-packages。下面我们修改 python udf 插件默认的库搜索路径。
|
||||
发现 Python udf 插件默认搜索的第三方库安装路径是: /lib/python3/dist-packages,而 moment 默认安装到了 /usr/local/lib/python3.8/dist-packages。下面我们修改 Python udf 插件默认的库搜索路径。
|
||||
先打开 python3 命令行,查看当前的 sys.path。
|
||||
|
||||
```python
|
||||
|
@ -754,7 +754,7 @@ create or replace aggregate function myspread as '/root/udf/myspread.py' outputt
|
|||
|
||||
这个 SQL 语句与创建标量函数的 SQL 语句有两个重要区别。
|
||||
1. 增加了 aggregate 关键字
|
||||
2. 增加了 bufsize 关键字,用来指定存储中间结果的内存大小,这个数值可以大于实际使用的数值。本例中间结果是两个浮点数组成的 tuple,序列化后实际占用大小只有 32 个字节,但指定的 bufsize 是128,可以用 python 命令行打印实际占用的字节数
|
||||
2. 增加了 bufsize 关键字,用来指定存储中间结果的内存大小,这个数值可以大于实际使用的数值。本例中间结果是两个浮点数组成的 tuple,序列化后实际占用大小只有 32 个字节,但指定的 bufsize 是128,可以用 Python 命令行打印实际占用的字节数
|
||||
|
||||
```python
|
||||
>>> len(pickle.dumps((12345.6789, 23456789.9877)))
|
||||
|
|
|
@ -352,7 +352,7 @@ main 函数可以接收 5 个启动参数,依次是:
|
|||
|
||||
<details>
|
||||
|
||||
SQLWriter 类封装了拼 SQL 和写数据的逻辑。所有的表都没有提前创建,而是在发生表不存在错误的时候,再以超级表为模板批量建表,然后重新执行 INSERT 语句。对于其它错误会记录当时执行的 SQL, 以便排查错误和故障恢复。这个类也对 SQL 是否超过最大长度限制做了检查,根据 TDengine 3.0 的限制由输入参数 maxSQLLength 传入了支持的最大 SQL 长度,即 1,048,576 。
|
||||
SQLWriter 类封装了拼 SQL 和写数据的逻辑。所有的表都没有提前创建,而是在发生表不存在错误的时候,再以超级表为模板批量建表,然后重新执行 INSERT 语句。对于其它错误会记录当时执行的 SQL,以便排查错误和故障恢复。这个类也对 SQL 是否超过最大长度限制做了检查,根据 TDengine 3.0 的限制由输入参数 maxSQLLength 传入了支持的最大 SQL 长度,即 1,048,576 。
|
||||
|
||||
<summary>SQLWriter</summary>
|
||||
|
||||
|
@ -374,7 +374,7 @@ SQLWriter 类封装了拼 SQL 和写数据的逻辑。所有的表都没有提
|
|||
- 已安装 Python3, 推荐版本 >= 3.8
|
||||
- 已安装 taospy
|
||||
|
||||
2. 安装 faster-fifo 代替 python 内置的 multiprocessing.Queue
|
||||
2. 安装 faster-fifo 代替 Python 内置的 multiprocessing.Queue
|
||||
|
||||
```
|
||||
pip3 install faster-fifo
|
||||
|
|
|
@ -36,7 +36,7 @@ taosAdapter 提供了以下功能:
|
|||
- RESTful 接口;
|
||||
- WebSocket 连接;
|
||||
- 兼容 InfluxDB v1 格式写入;
|
||||
- 兼容 OpenTSDB JSON 和 Telnet 格式写入;
|
||||
- 兼容 OpenTSDB JSON 和 TELNET 格式写入;
|
||||
- 无缝连接到 Telegraf;
|
||||
- 无缝连接到 collectd;
|
||||
- 无缝连接到 StatsD;
|
||||
|
@ -44,9 +44,9 @@ taosAdapter 提供了以下功能:
|
|||
|
||||
## taosKeeper
|
||||
|
||||
taosKeeper 是 TDengine 3.0 版本中新增的监控指标导出工具,旨在方便用户对TDengine 的运行状态和性能指标进行实时监控。通过简单的配置,TDengine 能够将其运行状态、指标等信息上报给 taosKeeper。当接收到监控数据后,taosKeeper 会利用 taosAdapter 提供的 RESTful 接口,将这些数据存储到 TDengine 中。
|
||||
taosKeeper 是 TDengine 3.0 版本中新增的监控指标导出工具,旨在方便用户对 TDengine 的运行状态和性能指标进行实时监控。通过简单的配置,TDengine 能够将其运行状态、指标等信息上报给 taosKeeper。当接收到监控数据后,taosKeeper 会利用 taosAdapter 提供的 RESTful 接口,将这些数据存储到 TDengine 中。
|
||||
|
||||
taosKeeper 的一个重要价值在于,它能够将多个甚至一批 TDengine 集群的监控数据集中存储在一个统一的平台上。这使得监控软件能够轻松获取这些数据,从而实现对 TDengine 集群的全面监控和实时分析。通过 taosKeeper,用户可以更加便捷地掌握TDengine 的运行状况,及时发现并解决潜在问题,确保系统的稳定性和高效性。
|
||||
taosKeeper 的一个重要价值在于,它能够将多个甚至一批 TDengine 集群的监控数据集中存储在一个统一的平台上。这使得监控软件能够轻松获取这些数据,从而实现对 TDengine 集群的全面监控和实时分析。通过 taosKeeper,用户可以更加便捷地掌握 TDengine 的运行状况,及时发现并解决潜在问题,确保系统的稳定性和高效性。
|
||||
|
||||
## taosExplorer
|
||||
|
||||
|
@ -60,7 +60,7 @@ taosKeeper 的一个重要价值在于,它能够将多个甚至一批 TDengine
|
|||
|
||||
taosX 作为 TDengine Enterprise 的数据管道功能组件,旨在为用户提供一种无须编写代码即可轻松对接第三方数据源的方法,实现数据的便捷导入。目前,taosX 已支持众多主流数据源,包括 AVEVA PI System、AVEVA Historian、OPC-UA/DA、InfluxDB、OpenTSDB、MQTT、Kafka、CSV、TDengine 2.x、TDengine 3.x、MySQL、PostgreSQL和 Oracle 等。
|
||||
|
||||
在实际使用中, 用户通常无须直接与 taosX 进行交互。 相反, 他们可以通 过taosExplorer 提供的浏览器用户界面轻松访问和使用 taosX 的强大功能。这种设计简化了操作流程,降低了使用门槛,使得用户能够更加专注于数据处理和分析,从而提高工作效率。
|
||||
在实际使用中,用户通常无须直接与 taosX 进行交互。 相反, 他们可以通过 taosExplorer 提供的浏览器用户界面轻松访问和使用 taosX 的强大功能。这种设计简化了操作流程,降低了使用门槛,使得用户能够更加专注于数据处理和分析,从而提高工作效率。
|
||||
|
||||
## taosX Agent
|
||||
|
||||
|
@ -77,7 +77,7 @@ taosX Agent 是 TDengine Enterprise 数据管道功能的重要组成部分,
|
|||
这些应用程序负责向业务集群写入、查询业务数据以及订阅数据。应用程序可以通过以下 3 种方式与业务集群进行交互。
|
||||
- 基于 taosc 的应用程序:采用原生连接的应用程序,直接连接到业务集群,默认端口为 6030。
|
||||
- 基于 RESTful 连接的应用程序:使用 RESTful 接口访问业务集群的应用程序,需要通过 taosAdapter 进行连接,默认端口为 6041。
|
||||
- 基于 WebSkcket 连接的应用程序:采用 WebSocket 连接的应用程序,同样需要通过 taosAdapter 进行连接,默认端口为 6041。
|
||||
- 基于 WebSocket 连接的应用程序:采用 WebSocket 连接的应用程序,同样需要通过 taosAdapter 进行连接,默认端口为 6041。
|
||||
|
||||
2. 可视化/BI 工具
|
||||
|
||||
|
@ -85,4 +85,4 @@ TDengine 支持与众多可视化及 BI 工具无缝对接,如 Grafana、Power
|
|||
|
||||
3. 数据源
|
||||
|
||||
TDengine 具备强大的数据接入能力,可以对接各种数据源,如 MQTT、OPC-UA/DA、Kafka、AVEVA PI System、AVEVA Historian 等。这使得 TDengine 能够轻松整合来自不同数据源的数据,为用户提供全面、统一的数据视图。
|
||||
TDengine 具备强大的数据接入能力,可以对接各种数据源,如 MQTT、OPC-UA/DA、Kafka、AVEVA PI System、AVEVA Historian 等。这使得 TDengine 能够轻松整合来自不同数据源的数据,为用户提供全面、统一的数据视图。
|
||||
|
|
|
@ -4,11 +4,11 @@ title: 容量规划
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
若计划使用 TDengine 搭建一个时序数据平台,须提前对计算资源、存储资源和网络资源进行详细规划,以确保满足业务场景的需求。通常 TDengine 会运行多个进程,包括taosd、taosadapter、taoskeeper、taos-explorer 和 taosx。
|
||||
若计划使用 TDengine 搭建一个时序数据平台,须提前对计算资源、存储资源和网络资源进行详细规划,以确保满足业务场景的需求。通常 TDengine 会运行多个进程,包括 taosd、taosadapter、taoskeeper、taos-explorer 和 taosx。
|
||||
|
||||
在这些进程中,taoskeeper、taos-explorer、taosadapter 和 taosx 的资源占用相对较少,通常不需要特别关注。此外,这些进程对存储空间的需求也较低,其占用的 CPU 和内存资源一般为 taosd 进程的十分之一到几分之一(特殊场景除外,如数据同步和历史数据迁移。在这些情况下,涛思数据的技术支持团队将提供一对一的服务)。系统管理员应定期监控这些进程的资源消耗,并及时进行相应处理。
|
||||
|
||||
在本节中,我们将重点讨论 TDengine 数据库引擎的核心进程—taosd 的资源规划。合理的资源规划将确保 taosd 进程的高效运行,从而提高整个时序数据平台的性能和稳定性。
|
||||
在本节中,我们将重点讨论 TDengine 数据库引擎的核心进程 taosd 的资源规划。合理的资源规划将确保 taosd 进程的高效运行,从而提高整个时序数据平台的性能和稳定性。
|
||||
|
||||
## 服务器内存需求
|
||||
|
||||
|
@ -17,7 +17,7 @@ toc_max_heading_level: 4
|
|||
为了帮助用户更好地理解和配置这些参数,TDengine 的官方文档的数据库管理部分提供了详细说明。根据这些参数,可以估算出一个数据库所需的内存大小,具体计算方式如下(具体数值须根据实际情况进行调整)。
|
||||
vgroups ×replica × (buffer + pages × pagesize + cachesize)
|
||||
|
||||
需要明确的是,这些内存资源并非仅由单一服务器承担,而是由整个集群中的所有dnode 共同分摊,也就是说,这些资源的负担实际上是由这些 dnode 所在的服务器集群共同承担的。若集群内存在多个数据库,那么所需的内存总量还须将这些数据库的需求累加起来。更为复杂的情形在于,如果集群中的 dnode 并非一开始就全部部署完毕,而是在使用过程中随着节点负载的上升逐步添加服务器和 dnode,那么新加入的数据库可能会导致新旧 dnode 之间的负载分布不均。在这种情况下,简单地进行理论计算是不够准确的,必须考虑到各个 dnode 的实际负载状况来进行综合评估。
|
||||
需要明确的是,这些内存资源并非仅由单一服务器承担,而是由整个集群中的所有 dnode 共同分摊,也就是说,这些资源的负担实际上是由这些 dnode 所在的服务器集群共同承担的。若集群内存在多个数据库,那么所需的内存总量还须将这些数据库的需求累加起来。更为复杂的情形在于,如果集群中的 dnode 并非一开始就全部部署完毕,而是在使用过程中随着节点负载的上升逐步添加服务器和 dnode,那么新加入的数据库可能会导致新旧 dnode 之间的负载分布不均。在这种情况下,简单地进行理论计算是不够准确的,必须考虑到各个 dnode 的实际负载状况来进行综合评估。
|
||||
|
||||
系统管理员可以通过如下 SQL 查看 information_schema 库中的 ins_vnodes 表来获得所有数据库所有 vnodes 在各个 dnode 上的分布。
|
||||
|
||||
|
@ -33,7 +33,7 @@ dnode_id |vgroup_id | db_name | status | role_time | start_time | restored |
|
|||
|
||||
1. 原生连接方式
|
||||
|
||||
由于客户端应用程序采用 taosc 与服务器进行通信,因此会产生一定的内存消耗。这些内存消耗主要源于:写入操作中的 SQL、表元数据信息的缓存,以及固有的结构开销。假设该数据库服务能够支持的最大表数量为 N(每个通过超级表创建的表的元数据开销约为 256B),最大并发写入线程数为 T,以及最大 SQL 语句长度为 S(通常情况下为1MB)。基于这些参数,我们可以对客户端的内存消耗进行估算(单位为 MB)。
|
||||
由于客户端应用程序采用 taosc 与服务器进行通信,因此会产生一定的内存消耗。这些内存消耗主要源于:写入操作中的 SQL、表元数据信息的缓存,以及固有的结构开销。假设该数据库服务能够支持的最大表数量为 N(每个通过超级表创建的表的元数据开销约为 256B),最大并发写入线程数为 T,以及最大 SQL 语句长度为 S(通常情况下为 1MB)。基于这些参数,我们可以对客户端的内存消耗进行估算(单位为 MB)。
|
||||
M = (T × S × 3 + (N / 4096) + 100)
|
||||
|
||||
例如,用户最大并发写入线程数为 100,子表数为 10 000 000,那么客户端的内存最低要求如下:
|
||||
|
@ -101,7 +101,7 @@ $ du -hd1 <dataDir>/vnode --exclude=wal
|
|||
除了存储容量的需求以外,用户可能还希望在特定容量下降低存储成本。为了满足这一需求,TDengine 推出了多级存储功能。该功能允许将近期产生且访问频率较高的数据存储在高成本存储设备上,而将时间较长且访问频率较低的数据存储在低成本存储设备上。通过这种方式,TDengine 实现了以下目标。
|
||||
- 降低存储成本:通过将海量极冷数据存储在廉价存储设备上,可以显著降低存储成本。
|
||||
- 提高写入性能:每级存储支持多个挂载点,WAL 文件也支持 0 级的多挂载点并行写入,这些措施极大地提高了写入性能(实际场景中的持续写入速度可达 3 亿测
|
||||
点 / 秒),在机械硬盘上也能获得极高的硬盘 I/O 吞吐(实测可达 2GB/s)。
|
||||
点/秒),在机械硬盘上也能获得极高的硬盘 I/O 吞吐(实测可达 2GB/s)。
|
||||
|
||||
用户可以根据冷热数据的比例来决定高速和低成本存储设备之间的容量划分。
|
||||
|
||||
|
@ -120,7 +120,7 @@ TDengine 的多级存储功能在使用上还具备以下优点。
|
|||
- 集群为响应维护指令而额外需要的内部通信带宽,如从单副本切换到三副本导致的数据复制、修复指定 dnode 引发的数据复制等情况。
|
||||
|
||||
为了估算入站带宽需求,我们可以采用以下方式:
|
||||
由 于 taosc 写入在 RPC 通信过程中自带压缩功能,因此写入带宽需求相对于RESTful/WebSocket 连接方式较低。在这里,我们将基于 RESTful/WebSocket 连接方式的
|
||||
由 于 taosc 写入在 RPC 通信过程中自带压缩功能,因此写入带宽需求相对于 RESTful/WebSocket 连接方式较低。在这里,我们将基于 RESTful/WebSocket 连接方式的
|
||||
带宽需求来估算写入请求的带宽。
|
||||
|
||||
示例:1000 万块智能电表,电表每 15min 采集一次数据,每次采集的数据量为 20B,可计算出平均带宽需求为 0.22MB。
|
||||
|
@ -154,9 +154,9 @@ TDengine 的多级存储功能在使用上还具备以下优点。
|
|||
| taosKeeper | 6043 | TCP |
|
||||
| statsd 格式写入接口 | 6044 | TCP/UDP |
|
||||
| collectd 格式写入接口 | 6045 | TCP/UDP |
|
||||
| openTSDB Telnet 格式写入接口 | 6046 | TCP |
|
||||
| collectd 使用 openTSDB Telnet 格式写入接口 | 6047 | TCP |
|
||||
| icinga2 使用 openTSDB Telnet 格式写入接口 | 6048 | TCP |
|
||||
| tcollector 使用 openTSDB Telnet 格式写入接口 | 6049 | TCP |
|
||||
| openTSDB TELNET 格式写入接口 | 6046 | TCP |
|
||||
| collectd 使用 openTSDB TELNET 格式写入接口 | 6047 | TCP |
|
||||
| icinga2 使用 openTSDB TELNET 格式写入接口 | 6048 | TCP |
|
||||
| tcollector 使用 openTSDB TELNET 格式写入接口 | 6049 | TCP |
|
||||
| taosX | 6050, 6055 | TCP |
|
||||
| taosExplorer | 6060 | TCP |
|
||||
|
|
|
@ -14,18 +14,18 @@ taosd 是 TDengine 集群中最主要的服务组件,本节介绍手动部署
|
|||
|
||||
#### 1. 清除数据
|
||||
|
||||
如果搭建集群的物理节点中存在之前的测试数据或者装过其他版本(如 1.x/2.x)的TDengine,请先将其删除,并清空所有数据。
|
||||
如果搭建集群的物理节点中存在之前的测试数据或者装过其他版本(如 1.x/2.x)的 TDengine,请先将其删除,并清空所有数据。
|
||||
|
||||
#### 2. 检查环境
|
||||
|
||||
在进行 TDengine 集群部署之前,全面检查所有 dnode 以及应用程序所在物理节点的网络设置至关重要。以下是检查步骤:
|
||||
|
||||
- 第 1 步,在每个物理节点上执行 hostname -f 命令,以查看并确认所有节点的hostname 是唯一的。对于应用程序驱动所在的节点,这一步骤可以省略。
|
||||
- 第 2 步,在每个物理节点上执行 ping host 命令,其中 host 是其他物理节点的 hostname。这一步骤旨在检测当前节点与其他物理节点之间的网络连通性。如果发现无法 ping 通,请立即检查网络和 DNS 设置。对于 Linux 操作系统,请检查 /etc/hosts 文件;对于 Windows 操作系统,请检查C:\Windows\system32\drivers\etc\hosts 文件。网络不通畅将导致无法组建集群,请务必解决此问题。
|
||||
- 第 3 步,在应用程序运行的物理节点上重复上述网络检测步骤。如果发现网络不通畅,应用程序将无法连接到 taosd 服务。此时,请仔细检查应用程序所在物理节点的DNS 设置或 hosts 文件,确保其配置正确无误。
|
||||
- 第 2 步,在每个物理节点上执行 ping host 命令,其中 host 是其他物理节点的 hostname。这一步骤旨在检测当前节点与其他物理节点之间的网络连通性。如果发现无法 ping 通,请立即检查网络和 DNS 设置。对于 Linux 操作系统,请检查 /etc/hosts 文件;对于 Windows 操作系统,请检查 `C:\Windows\system32\drivers\etc\hosts` 文件。网络不通畅将导致无法组建集群,请务必解决此问题。
|
||||
- 第 3 步,在应用程序运行的物理节点上重复上述网络检测步骤。如果发现网络不通畅,应用程序将无法连接到 taosd 服务。此时,请仔细检查应用程序所在物理节点的 DNS 设置或 hosts 文件,确保其配置正确无误。
|
||||
- 第 4 步,检查端口,确保集群中所有主机在端口 6030 上的 TCP 能够互通。
|
||||
|
||||
通过以上步骤,你可以确保所有节点在网络层面顺利通信,从而为成功部署TDengine 集群奠定坚实基础
|
||||
通过以上步骤,你可以确保所有节点在网络层面顺利通信,从而为成功部署 TDengine 集群奠定坚实基础
|
||||
|
||||
#### 3. 安装
|
||||
|
||||
|
@ -77,7 +77,7 @@ taos> show dnodes;
|
|||
create dnode "h2.taosdata.com:6030"
|
||||
```
|
||||
|
||||
将新 dnode 的 endpoint 添加进集群的 endpoint 列表。需要为 `fqdn:port` 加上双引号,否则运行时出错。请注意将示例的 h2.taosdata.com:6030 替换为这个新 dnode 的 endpoint。然后执行如下 SQL 查看新节点是否成功加入。若要加入的 dnode 当前处于离线状态,请参考本节后面的 “常见问题”部分进行解决。
|
||||
将新 dnode 的 endpoint 添加进集群的 endpoint 列表。需要为 `fqdn:port` 加上双引号,否则运行时出错。请注意将示例的 h2.taosdata.com:6030 替换为这个新 dnode 的 endpoint。然后执行如下 SQL 查看新节点是否成功加入。若要加入的 dnode 当前处于离线状态,请参考本节后面的“常见问题”部分进行解决。
|
||||
|
||||
```shell
|
||||
show dnodes;
|
||||
|
@ -202,7 +202,7 @@ http {
|
|||
|
||||
### 部署 taosKeeper
|
||||
|
||||
如果要想使用 TDegnine 的监控功能,taosKeeper 是一个必要的组件,关于监控请参考[TDinsight](../../reference/components/tdinsight),关于部署 taosKeeper 的细节请参考[taosKeeper参考手册](../../reference/components/taoskeeper)。
|
||||
如果要想使用 TDegnine 的监控功能,taosKeeper 是一个必要的组件,关于监控请参考 [TDinsight](../../reference/components/tdinsight),关于部署 taosKeeper 的细节请参考 [taosKeeper 参考手册](../../reference/components/taoskeeper)。
|
||||
|
||||
### 部署 taosX
|
||||
|
||||
|
@ -210,11 +210,11 @@ http {
|
|||
|
||||
### 部署 taosX-Agent
|
||||
|
||||
有些数据源如 Pi, OPC 等,因为网络条件和数据源访问的限制,taosX 无法直接访问数据源,这种情况下需要部署一个代理服务 taosX-Agent,关于它的详细说明和部署请参考企业版参考手册。
|
||||
有些数据源如 PI、OPC 等,因为网络条件和数据源访问的限制,taosX 无法直接访问数据源,这种情况下需要部署一个代理服务 taosX-Agent,关于它的详细说明和部署请参考企业版参考手册。
|
||||
|
||||
### 部署 taos-Explorer
|
||||
|
||||
TDengine 提供了可视化管理 TDengine 集群的能力,要想使用图形化界面需要部署 taos-Explorer 服务,关于它的详细说明和部署请参考[taos-Explorer 参考手册](../../reference/components/explorer)
|
||||
TDengine 提供了可视化管理 TDengine 集群的能力,要想使用图形化界面需要部署 taos-Explorer 服务,关于它的详细说明和部署请参考 [taos-Explorer 参考手册](../../reference/components/explorer)
|
||||
|
||||
|
||||
## Docker 部署
|
||||
|
@ -299,14 +299,14 @@ echo 127.0.0.1 tdengine |sudo tee -a /etc/hosts
|
|||
taos -h tdengine -P 6030
|
||||
```
|
||||
|
||||
如果 TAOS_FQDN 被设置为与所在主机名相同,则效果与“在 host 网络模式下启动TDengine”相同。
|
||||
如果 TAOS_FQDN 被设置为与所在主机名相同,则效果与“在 host 网络模式下启动 TDengine”相同。
|
||||
|
||||
## Kubernetes 部署
|
||||
|
||||
作为面向云原生架构设计的时序数据库,TDengine 本身就支持 Kubernetes 部署。这里介绍如何使用 YAML 文件从头一步一步创建一个可用于生产使用的高可用 TDengine 集群,并重点介绍 Kubernetes 环境下 TDengine 的常用操作。本小节要求读者对 Kubernetes 有一定的了解,可以熟练运行常见的 kubectl 命令,了解 statefulset、service、pvc 等概念,对这些概念不熟悉的读者,可以先参考 Kubernetes 的官网进行学习。
|
||||
为了满足高可用的需求,集群需要满足如下要求:
|
||||
- 3 个及以上 dnode :TDengine 的同一个 vgroup 中的多个 vnode ,不允许同时分布在一个 dnode ,所以如果创建 3 副本的数据库,则 dnode 数大于等于 3
|
||||
- 3 个 mnode :mnode 负责整个集群的管理工作,TDengine 默认是一个 mnode。如果这个 mnode 所在的 dnode 掉线,则整个集群不可用。
|
||||
- 3 个及以上 dnode:TDengine 的同一个 vgroup 中的多个 vnode,不允许同时分布在一个 dnode ,所以如果创建 3 副本的数据库,则 dnode 数大于等于 3
|
||||
- 3 个 mnode:mnode 负责整个集群的管理工作,TDengine 默认是一个 mnode。如果这个 mnode 所在的 dnode 掉线,则整个集群不可用。
|
||||
- 数据库的 3 副本:TDengine 的副本配置是数据库级别,所以数据库 3 副本可满足在 3 个 dnode 的集群中,任意一个 dnode 下线,都不影响集群的正常使用。如果下线 dnode 个数为 2 时,此时集群不可用,因为 RAFT 无法完成选举。(企业版:在灾难恢复场景,任一节点数据文件损坏,都可以通过重新拉起 dnode 进行恢复)
|
||||
|
||||
### 前置条件
|
||||
|
@ -342,7 +342,7 @@ spec:
|
|||
|
||||
### 有状态服务 StatefulSet
|
||||
|
||||
根据 Kubernetes 对各类部署的说明,我们将使用 StatefulSet 作为 TDengine 的部署资源类型。 创建文件 tdengine.yaml,其中 replicas 定义集群节点的数量为 3。节点时区为中国(Asia/Shanghai),每个节点分配 5G 标准(standard)存储,你也可以根据实际情况进行相应修改。
|
||||
根据 Kubernetes 对各类部署的说明,我们将使用 StatefulSet 作为 TDengine 的部署资源类型。 创建文件 tdengine.yaml,其中 replicas 定义集群节点的数量为 3。节点时区为中国(Asia/Shanghai),每个节点分配 5GB 标准(standard)存储,你也可以根据实际情况进行相应修改。
|
||||
|
||||
请特别注意 startupProbe 的配置,在 dnode 的 Pod 掉线一段时间后,再重新启动,这个时候新上线的 dnode 会短暂不可用。如果 startupProbe 配置过小,Kubernetes 会认为该 Pod 处于不正常的状态,并尝试重启该 Pod,该 dnode 的 Pod 会频繁重启,始终无法恢复到正常状态。
|
||||
|
||||
|
|
|
@ -8,42 +8,42 @@ sidebar_label: 集群维护
|
|||
|
||||
## 节点管理
|
||||
|
||||
如何管理集群节点请参考[节点管理](../../reference/taos-sql/node)
|
||||
如何管理集群节点请参考 [节点管理](../../reference/taos-sql/node)
|
||||
|
||||
## 数据重整
|
||||
|
||||
TDengine 面向多种写入场景,而很多写入场景下,TDengine 的存储会导致数据存储的放大或数据文件的空洞等。这一方面影响数据的存储效率,另一方面也会影响查询效率。为了解决上述问题,TDengine 企业版提供了对数据的重整功能,即 DATA COMPACT 功能,将存储的数据文件重新整理,删除文件空洞和无效数据,提高数据的组织度,从而提高存储和查询的效率。数据重整功能在 3.0.3.0 版本第一次发布,此后又经过了多次迭代优化,建议使用最新版本。
|
||||
TDengine 面向多种写入场景,而很多写入场景下,TDengine 的存储会导致数据存储的放大或数据文件的空洞等。这一方面影响数据的存储效率,另一方面也会影响查询效率。为了解决上述问题,TDengine 企业版提供了对数据的重整功能,即 data compact 功能,将存储的数据文件重新整理,删除文件空洞和无效数据,提高数据的组织度,从而提高存储和查询的效率。数据重整功能在 3.0.3.0 版本第一次发布,此后又经过了多次迭代优化,建议使用最新版本。
|
||||
|
||||
### 语法
|
||||
|
||||
```SQL
|
||||
COMPACT DATABASE db_name [start with 'XXXX'] [end with 'YYYY'] [META_ONLY];
|
||||
COMPACT [db_name.]VGROUPS IN (vgroup_id1, vgroup_id2, ...) [start with 'XXXX'] [end with 'YYYY'] [META_ONLY];
|
||||
SHOW COMPACTS;
|
||||
SHOW COMPACT compact_id;
|
||||
KILL COMPACT compact_id;
|
||||
compact DATABASE db_name [start with 'XXXX'] [end with 'YYYY'] [META_ONLY];
|
||||
compact [db_name.]vgroups IN (vgroup_id1, vgroup_id2, ...) [start with 'XXXX'] [end with 'YYYY'] [META_ONLY];
|
||||
show compacts;
|
||||
show compact compact_id;
|
||||
kill compact compact_id;
|
||||
```
|
||||
|
||||
### 效果
|
||||
|
||||
- 扫描并压缩指定的 DB 中所有 VGROUP 中 VNODE 的所有数据文件
|
||||
- 扫描并压缩 DB 中指定的 VGROUP 列表中 VNODE 的所有数据文件, 若 db_name 为空,则默认为当前数据库
|
||||
- COMPCAT 会删除被删除数据以及被删除的表的数据
|
||||
- COMPACT 会合并多个 STT 文件
|
||||
- 可通过 start with 关键字指定 COMPACT 数据的起始时间
|
||||
- 可通过 end with 关键字指定 COMPACT 数据的终止时间
|
||||
- 可通过 `META_ONLY` 关键字指定只 compact 元数据。元数据默认情况下不会 compact。
|
||||
- COMPACT 命令会返回 COMPACT 任务的 ID
|
||||
- COMPACT 任务会在后台异步执行,可以通过 SHOW COMPACTS 命令查看 COMPACT 任务的进度
|
||||
- SHOW 命令会返回 COMPACT 任务的 ID,可以通过 KILL COMPACT 命令终止 COMPACT 任务
|
||||
- 扫描并压缩指定的 DB 中所有 vgroup 中 vnode 的所有数据文件
|
||||
- 扫描并压缩 DB 中指定的 vgroup 列表中 vnode 的所有数据文件, 若 db_name 为空,则默认为当前数据库
|
||||
- compact 会删除被删除数据以及被删除的表的数据
|
||||
- compact 会合并多个 STT 文件
|
||||
- 可通过 start with 关键字指定 compact 数据的起始时间
|
||||
- 可通过 end with 关键字指定 compact 数据的终止时间
|
||||
- 可通过 `META_ONLY` 关键字指定只 compact 元数据。元数据默认情况下不会 compact。
|
||||
- compact 命令会返回 compact 任务的 ID
|
||||
- compact 任务会在后台异步执行,可以通过 show compacts 命令查看 compact 任务的进度
|
||||
- show 命令会返回 compact 任务的 ID,可以通过 kill compact 命令终止 compact 任务
|
||||
|
||||
|
||||
### 补充说明
|
||||
|
||||
- COMPACT 为异步,执行 COMPACT 命令后不会等 COMPACT 结束就会返回。如果上一个 COMPACT 没有完成则再发起一个 COMPACT 任务,则会等上一个任务完成后再返回。
|
||||
- COMPACT 可能阻塞写入,尤其是在 stt_trigger = 1 的数据库中,但不阻塞查询。
|
||||
- compact 为异步,执行 compact 命令后不会等 compact 结束就会返回。如果上一个 compact 没有完成则再发起一个 compact 任务,则会等上一个任务完成后再返回。
|
||||
- compact 可能阻塞写入,尤其是在 stt_trigger = 1 的数据库中,但不阻塞查询。
|
||||
|
||||
## Vgroup Leader 再平衡
|
||||
## vgroup leader 再平衡
|
||||
|
||||
当多副本集群中的一个或多个节点因为升级或其它原因而重启后,有可能出现集群中各个 dnode 负载不均衡的现象,极端情况下会出现所有 vgroup 的 leader 都位于同一个 dnode 的情况。为了解决这个问题,可以使用下面的命令,该命令在 3.0.4.0 版本中首次发布,建议尽可能使用最新版本。
|
||||
|
||||
|
@ -55,15 +55,15 @@ balance vgroup leader database <database_name>; # 再平衡一个 database 内
|
|||
|
||||
### 功能
|
||||
|
||||
尝试让一个或所有 vgroup 的 leader在各自的replica节点上均匀分布。这个命令会让 vgroup 强制重新选举,通过重新选举,在选举的过程中,改变 vgroup 的leader,通过这个方式,最终让leader均匀分布。
|
||||
尝试让一个或所有 vgroup 的 leader 在各自的 replica 节点上均匀分布。这个命令会让 vgroup 强制重新选举,通过重新选举,在选举的过程中,改变 vgroup 的 leader,通过这个方式,最终让 leader 均匀分布。
|
||||
|
||||
### 注意
|
||||
|
||||
Vgroup 选举本身带有随机性,所以通过选举的重新分布产生的均匀分布也是带有一定的概率,不会完全的均匀。该命令的副作用是影响查询和写入,在vgroup重新选举时,从开始选举到选举出新的 leader 这段时间,这 个vgroup 无法写入和查询。选举过程一般在秒级完成。所有的vgroup会依次逐个重新选举。
|
||||
vgroup 选举本身带有随机性,所以通过选举的重新分布产生的均匀分布也是带有一定的概率,不会完全的均匀。该命令的副作用是影响查询和写入,在 vgroup 重新选举时,从开始选举到选举出新的 leader 这段时间,这 个vgroup 无法写入和查询。选举过程一般在秒级完成。所有的 vgroup 会依次逐个重新选举。
|
||||
|
||||
## 恢复数据节点
|
||||
|
||||
当集群中的某个数据节点(dnode)的数据全部丢失或被破坏,比如磁盘损坏或者目录被误删除,可以通过 restore dnode 命令来恢复该数据节点上的部分或全部逻辑节点,该功能依赖多副本中的其它副本进行数据复制,所以只在集群中 dnode 数量大于等于 3 且副本数为 3 的情况下能够工作。
|
||||
当集群中的某个数据节点(dnode)的数据全部丢失或被破坏,比如磁盘损坏或者目录被误删除,可以通过 `restore dnode` 命令来恢复该数据节点上的部分或全部逻辑节点,该功能依赖多副本中的其它副本进行数据复制,所以只在集群中 dnode 数量大于等于 3 且副本数为 3 的情况下能够工作。
|
||||
|
||||
```sql
|
||||
restore dnode <dnode_id>;# 恢复dnode上的mnode,所有vnode和qnode
|
||||
|
@ -74,12 +74,12 @@ restore qnode on dnode <dnode_id>;# 恢复dnode上的qnode
|
|||
|
||||
### 限制
|
||||
|
||||
- 该功能是基于已有的复制功能的恢复,不是灾难恢复或者备份恢复,所以对于要恢复的 mnode 和 vnode来说,使用该命令的前提是还存在该 mnode 或 vnode 的其它两个副本仍然能够正常工作。
|
||||
- 该命令不能修复数据目录中的个别文件的损坏或者丢失。例如,如果某个 mnode 或者 vnode 中的个别文件或数据损坏,无法单独恢复损坏的某个文件或者某块数据。此时,可以选择将该 mnode/vnode 的数据全部清空再进行恢复。
|
||||
- 该功能是基于已有的复制功能的恢复,不是灾难恢复或者备份恢复,所以对于要恢复的 mnode 和 vnode 来说,使用该命令的前提是还存在该 mnode 或 vnode 的其它两个副本仍然能够正常工作。
|
||||
- 该命令不能修复数据目录中的个别文件的损坏或者丢失。例如,如果某个 mnode 或者 vnode 中的个别文件或数据损坏,无法单独恢复损坏的某个文件或者某块数据。此时,可以选择将该 mnode/vnode 的数据全部清空再进行恢复。
|
||||
|
||||
## 分裂虚拟组
|
||||
|
||||
当一个 vgroup 因为子表数过多而导致 CPU 或 Disk 资源使用量负载过高时,增加 dnode 节点后,可通过split vgroup命令把该vgroup分裂为两个虚拟组。分裂完成后,新产生的两个 vgroup 承担原来由一个 vgroup 提供的读写服务。该命令在 3.0.6.0 版本第一次发布,建议尽可能使用最新版本。
|
||||
当一个 vgroup 因为子表数过多而导致 CPU 或 Disk 资源使用量负载过高时,增加 dnode 节点后,可通过 `split vgroup` 命令把该 vgroup 分裂为两个虚拟组。分裂完成后,新产生的两个 vgroup 承担原来由一个 vgroup 提供的读写服务。该命令在 3.0.6.0 版本第一次发布,建议尽可能使用最新版本。
|
||||
|
||||
```sql
|
||||
split vgroup <vgroup_id>
|
||||
|
@ -88,7 +88,7 @@ split vgroup <vgroup_id>
|
|||
### 注意
|
||||
|
||||
- 单副本库虚拟组,在分裂完成后,历史时序数据总磁盘空间使用量,可能会翻倍。所以,在执行该操作之前,通过增加 dnode 节点方式,确保集群中有足够的 CPU 和磁盘资源,避免资源不足现象发生。
|
||||
- 该命令为 DB 级事务;执行过程,当前DB的其它管理事务将会被拒绝。集群中,其它DB不受影响。
|
||||
- 该命令为 DB 级事务;执行过程,当前 DB 的其它管理事务将会被拒绝。集群中,其它 DB 不受影响。
|
||||
- 分裂任务执行过程中,可持续提供读写服务;期间,可能存在可感知的短暂的读写业务中断。
|
||||
- 在分裂过程中,不支持流和订阅。分裂结束后,历史 WAL 会清空。
|
||||
- 分裂过程中,可支持节点宕机重启容错;但不支持节点磁盘故障容错。
|
||||
|
@ -97,8 +97,6 @@ split vgroup <vgroup_id>
|
|||
|
||||
从 3.1.1.0 版本开始,TDengine Enterprise 支持在线热更新 `supportVnodes` 这个很重要的 dnode 配置参数。这个参数的原始配置方式是在 `taos.cfg` 配置文件中,表示该 dnode 能够支持的最大的 vnode 数量。当创建一个数据库时需要分配新的 vnode,当删除一个数据库时其 vnode 都会被销毁。
|
||||
|
||||
但在线更新 `supportVnodes` 不会产生持久化,当系统重启后,允许的最大 vnode 数量仍然由 taos.cfg 中配置的 `supportVnodes` 决定。
|
||||
|
||||
如果通过在线更新或配置文件方式设置的 `supportVnodes` 小于 dnode 当前已经实际存在的 vnode 数量,已经存在的 vnode 不会受影响。但当尝试创建新的 database 时,是否能够创建成功则仍然受实际生效的 `supportVnodes` 参数决定。
|
||||
|
||||
## 双副本
|
||||
|
@ -107,7 +105,7 @@ split vgroup <vgroup_id>
|
|||
|
||||
### 查看 Vgroups 的状态
|
||||
|
||||
通过以下 SQL 命令参看双副本数据库中各 Vgroup 的状态:
|
||||
通过以下 SQL 命令参看双副本数据库中各 vgroup 的状态:
|
||||
|
||||
```sql
|
||||
show arbgroups;
|
||||
|
@ -121,15 +119,15 @@ select * from information_schema.ins_arbgroups;
|
|||
|
||||
```
|
||||
is_sync 有以下两种取值:
|
||||
- 0: Vgroup 数据未达成同步。在此状态下,如果 Vgroup 中的某一 Vnode 不可访问,另一个 Vnode 无法被指定为 `AssignedLeader` role,该 Vgroup 将无法提供服务。
|
||||
- 1: Vgroup 数据达成同步。在此状态下,如果 Vgroup 中的某一 Vnode 不可访问,另一个 Vnode 可以被指定为 `AssignedLeader` role,该 Vgroup 可以继续提供服务。
|
||||
- 0: vgroup 数据未达成同步。在此状态下,如果 vgroup 中的某一 vnode 不可访问,另一个 vnode 无法被指定为 `AssignedLeader` role,该 vgroup 将无法提供服务。
|
||||
- 1: vgroup 数据达成同步。在此状态下,如果 vgroup 中的某一 vnode 不可访问,另一个 vnode 可以被指定为 `AssignedLeader` role,该 vgroup 可以继续提供服务。
|
||||
|
||||
assigned_dnode:
|
||||
- 标识被指定为 AssignedLeader 的 Vnode 的 DnodeId
|
||||
- 未指定 AssignedLeader时,该列显示 NULL
|
||||
- 标识被指定为 AssignedLeader 的 vnode 的 DnodeId
|
||||
- 未指定 AssignedLeader 时,该列显示 NULL
|
||||
|
||||
assigned_token:
|
||||
- 标识被指定为 AssignedLeader 的 Vnode 的 Token
|
||||
- 标识被指定为 AssignedLeader 的 vnode 的 Token
|
||||
- 未指定 AssignedLeader时,该列显示 NULL
|
||||
|
||||
### 最佳实践
|
||||
|
|
|
@ -4,7 +4,7 @@ title: 运行监控
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
为了确保集群稳定运行,TDengine 集成了多种监控指标收集机制,并通 过taosKeeper 进行汇总。taosKeeper负责接收这些数据,并将其写入一个独立的 TDengine 实例中,该实例可以与被监控的 TDengine 集群保持独立。TDengine 中的两个核心组件 taosd (数据库引擎) 和 taosX (数据接入平台)都通过相同的监控架构来实现对其运行时的监控,但各自的监控指标设计有所不同。
|
||||
为了确保集群稳定运行,TDengine 集成了多种监控指标收集机制,并通过 taosKeeper 进行汇总。taosKeeper 负责接收这些数据,并将其写入一个独立的 TDengine 实例中,该实例可以与被监控的 TDengine 集群保持独立。TDengine 中的两个核心组件 taosd (数据库引擎)和 taosX (数据接入平台)都通过相同的监控架构来实现对其运行时的监控,但各自的监控指标设计有所不同。
|
||||
|
||||
至于如何获取和使用这些监控数据,用户可以使用第三方的监测工具比如 Zabbix 来获取这些保存的系统监测数据,进而将 TDengine 的运行状况无缝集成到现有的 IT 监控系统中。也可以使用 TDengine 提供的 TDinsight 插件,使用该插件用户可以通过 Grafana 平台直观地展示和管理这些监控信息,如下图所示。这为用户提供了灵活的监控选项,以满足不同场景下的运维需求。
|
||||
|
||||
|
@ -24,7 +24,7 @@ taosKeeper 的配置文件默认位于 `/etc/taos/taoskeeper.toml`。 详细配
|
|||
|
||||
通过集成 Grafana 和 TDengine 数据源插件,TDinsight 能够读取 taosKeeper 收集的监控数据。这使得用户可以在 Grafana 平台上直观地查看 TDengine 集群的状态、节点信息、读写请求以及资源使用情况等关键指标,实现数据的可视化展示。
|
||||
|
||||
以下是TDinsight 的详细使用说明,以帮助你充分利用这一强大工具。
|
||||
以下是 TDinsight 的详细使用说明,以帮助你充分利用这一强大工具。
|
||||
|
||||
#### 前置条件
|
||||
|
||||
|
@ -40,7 +40,7 @@ taosKeeper 的配置文件默认位于 `/etc/taos/taoskeeper.toml`。 详细配
|
|||
|
||||
#### 导入仪表盘
|
||||
|
||||
TDengine 数据源插件已提交至 Grafana 官网,如何安装 TDengine 数据源插件和配置数据源请参考:[安装 Grafana Plugin 并配置数据源](../../third-party/visual/grafana/#安装-grafana-plugin-并配置数据源)。完成插件的安装和数据源的创建后,可以进行 TDinsight 仪表盘的导入。
|
||||
TDengine 数据源插件已提交至 Grafana 官网,如何安装 TDengine 数据源插件和配置数据源请参考 [安装 Grafana Plugin 并配置数据源](../../third-party/visual/grafana/#安装-grafana-plugin-并配置数据源)。完成插件的安装和数据源的创建后,可以进行 TDinsight 仪表盘的导入。
|
||||
|
||||
在 Grafana 的 “Home” -> “Dashboards” 页面,点击位于右上角的 “New” -> “import” 按钮,即可进入 Dashboard 的导入页面,它支持以下两种导入方式。
|
||||
- Dashboard ID:18180。
|
||||
|
|
|
@ -4,7 +4,7 @@ title: 可视化管理工具
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
为方便用户更高效地使用和管理 TDengine,TDengine 3.0 版本推出了一个全新的可视化组件—taosExplorer。这个组件旨在帮助用户在不熟悉 SQL 的情况下,也能轻松管理 TDengine 集群。通过 taosExplorer,用户可以轻松查看 TDengine 的运行状态、浏览数据、配置数据源、实现流计算和数据订阅等功能。此外,用户还可以利用taosExplorer 进行数据的备份、复制和同步操作,以及配置用户的各种访问权限。这些功能极大地简化了数据库的使用过程,提高了用户体验。
|
||||
为方便用户更高效地使用和管理 TDengine,TDengine 3.0 版本推出了一个全新的可视化组件 taosExplorer。这个组件旨在帮助用户在不熟悉 SQL 的情况下,也能轻松管理 TDengine 集群。通过 taosExplorer,用户可以轻松查看 TDengine 的运行状态、浏览数据、配置数据源、实现流计算和数据订阅等功能。此外,用户还可以利用 taosExplorer 进行数据的备份、复制和同步操作,以及配置用户的各种访问权限。这些功能极大地简化了数据库的使用过程,提高了用户体验。
|
||||
|
||||
本节介绍可视化管理的基本功能。
|
||||
|
||||
|
@ -30,7 +30,7 @@ toc_max_heading_level: 4
|
|||
|
||||
## 数据浏览器
|
||||
|
||||
点击功能列表的“数据浏览器”入口,在“数据浏览器”中可以创建和删除数据库、创建和删除超级表和子表,执行SQL语句,查看SQL语句的执行结果。此外,超级管理员还有对数据库的管理权限,其他用户不提供该功能。如下图所示:
|
||||
点击功能列表的“数据浏览器”入口,在“数据浏览器”中可以创建和删除数据库、创建和删除超级表和子表,执行 SQL 语句,查看 SQL 语句的执行结果。此外,超级管理员还有对数据库的管理权限,其他用户不提供该功能。如下图所示:
|
||||
|
||||

|
||||
|
||||
|
@ -38,7 +38,7 @@ toc_max_heading_level: 4
|
|||
|
||||
下面通过创建数据库,来熟悉数据浏览器页面的功能和操作,接下来看创建数据库的两种方式:
|
||||
|
||||
1. 通过点击图中的 + 号,跳转到创建数据数库页面,点击 创建 按钮,如下图:
|
||||
1. 通过点击图中的 + 号,跳转到创建数据数库页面,点击“创建”按钮,如下图:
|
||||
|
||||
第一步 点击 + 号;
|
||||

|
||||
|
@ -50,7 +50,7 @@ toc_max_heading_level: 4
|
|||
弟三步 点击“创建”按钮之后,如下图左边出现数据库名称则创建数据库成功。
|
||||

|
||||
|
||||
2. 通过在 Sql 编辑器中数据 sql 语句,点击 执行 按钮,如下图:
|
||||
2. 通过在 SQL 编辑器中数据 sql 语句,点击 执行 按钮,如下图:
|
||||
|
||||
第一步 输入 sql 语句;
|
||||

|
||||
|
@ -201,11 +201,11 @@ toc_max_heading_level: 4
|
|||
## 工具
|
||||
|
||||
通过 “工具” 页面,用户可以了解如下 TDengine 周边工具的使用方法。
|
||||
- TDengine CLI。
|
||||
- taosBenchmark。
|
||||
- taosdump。
|
||||
- TDengine 与 BI 工具的集成,例如 Google Data Studio、Power BI、永洪 BI 等。
|
||||
- TDengine 与 Grafana、Seeq 的集成。
|
||||
- TDengine CLI
|
||||
- taosBenchmark
|
||||
- taosdump
|
||||
- TDengine 与 BI 工具的集成,例如 Google Data Studio、Power BI、永洪 BI 等
|
||||
- TDengine 与 Grafana、Seeq 的集成
|
||||
|
||||
## 系统管理
|
||||
|
||||
|
@ -238,7 +238,7 @@ toc_max_heading_level: 4
|
|||
### 慢 SQL
|
||||
点击“系统管理”后,点击“慢 SQL”标签页,可以查看慢 SQL 执行语句日志统计与明细。
|
||||
|
||||
- 慢 SQL 明细:默认展示的是开始执行时间是一天内和执行耗时大于等于10秒的数据
|
||||
- 慢 SQL 明细:默认展示的是开始执行时间是一天内和执行耗时大于等于 10 秒的数据
|
||||

|
||||
- 慢 SQL 统计:默认展示所有的数据,可根据开始执行时间进行过滤
|
||||

|
||||
|
|
|
@ -8,9 +8,7 @@ toc_max_heading_level: 4
|
|||
|
||||
# 1. 基于 taosdump 进行数据备份恢复
|
||||
|
||||
taosdump 是一个开源工具,用于支持从运行中的 TDengine 集群备份数据并将备份的数据恢复到相同或另一个正在运行的 TDengine
|
||||
集群中。taosdump 可以将数据库作为逻辑数据单元进行备份,也可以对数据库中指定时间段内的数据记录进行备份。在使用taosdump
|
||||
时,可以指定数据备份的目录路径。如果不指定目录路径,taosdump 将默认将数据备份到当前目录。
|
||||
taosdump 是一个开源工具,用于支持从运行中的 TDengine 集群备份数据并将备份的数据恢复到相同或另一个正在运行的 TDengine 集群中。taosdump 可以将数据库作为逻辑数据单元进行备份,也可以对数据库中指定时间段内的数据记录进行备份。在使用 taosdump 时,可以指定数据备份的目录路径。如果不指定目录路径,taosdump 将默认将数据备份到当前目录。
|
||||
|
||||
以下为 taosdump 执行数据备份的使用示例。
|
||||
|
||||
|
@ -18,14 +16,11 @@ taosdump 是一个开源工具,用于支持从运行中的 TDengine 集群备
|
|||
taosdump -h localhost -P 6030 -D dbname -o /file/path
|
||||
```
|
||||
|
||||
执行上述命令后,taosdump 会连接 localhost:6030 所在的 TDengine 集群,查询数据库 dbname 中的所有数据,并将数据备份到 /f
|
||||
ile/path 下。
|
||||
执行上述命令后,taosdump 会连接 localhost:6030 所在的 TDengine 集群,查询数据库 dbname 中的所有数据,并将数据备份到 /file/path 下。
|
||||
|
||||
在使用 taosdump 时,如果指定的存储路径已经包含数据文件,taosdump
|
||||
会提示用户并立即退出,以避免数据被覆盖。这意味着同一存储路径只能用于一次备份。如果你看到相关提示,请谨慎操作,以免误操作导致数据丢失。
|
||||
在使用 taosdump 时,如果指定的存储路径已经包含数据文件,taosdump 会提示用户并立即退出,以避免数据被覆盖。这意味着同一存储路径只能用于一次备份。如果你看到相关提示,请谨慎操作,以免误操作导致数据丢失。
|
||||
|
||||
要将本地指定文件路径中的数据文件恢复到正在运行的 TDengine 集群中,可以通过指定命令行参数和数据文件所在路径来执行 taosdump
|
||||
命令。以下为 taosdump 执行数据恢复的示例代码。
|
||||
要将本地指定文件路径中的数据文件恢复到正在运行的 TDengine 集群中,可以通过指定命令行参数和数据文件所在路径来执行 taosdump 命令。以下为 taosdump 执行数据恢复的示例代码。
|
||||
|
||||
```shell
|
||||
taosdump -i /file/path -h localhost -P 6030
|
||||
|
|
|
@ -10,7 +10,7 @@ toc_max_heading_level: 4
|
|||
|
||||
TDengine 支持 WAL 机制,实现数据的容错能力,保证数据的高可靠。TDengine 接收到应用程序的请求数据包时,会先将请求的原始数据包写入数据库日志文件,等数据成功写入数据库数据文件后,再删除相应的 WAL。这样保证了 TDengine 能够在断电等因素导致的服务重启时,从数据库日志文件中恢复数据,避免数据丢失。涉及的配置参数有如下两个:
|
||||
|
||||
- wal_level :WAL 级别,1 表示写 WAL,但不执行 fsync ; 2 表示写 WAL,而且执行 fsync。默认值为 1。
|
||||
- wal_level:WAL 级别,1 表示写 WAL,但不执行 fsync;2 表示写 WAL,而且执行 fsync。默认值为 1。
|
||||
- wal_fsync_period:当 wal_level 设置为 2 时,执行 fsync 的周期;当 wal_fsync_period 设置为 0 时,表示每次写入,立即执行 fsync。
|
||||
|
||||
如果要 100% 保证数据不丢失,则需要将 wal_level 设置为 2,wal_fsync_period 设置为 0。这时写入速度将会下降。但如果应用程序侧启动的写数据的线程数达到一定的数量(超过 50),那么写入数据的性能也会很不错,只会比 wal_fsync_period 设置为 3000ms 下降 30% 左右。
|
||||
|
@ -27,10 +27,8 @@ TDengine 支持 WAL 机制,实现数据的容错能力,保证数据的高可
|
|||
|
||||
- 第 3 步,访问 TDengine 集群 B,创建一个与集群 A 中数据库 db1 参数配置相同的数据库 db2。
|
||||
|
||||
- 第 4 步,通过 Web 浏览器访问集群 B 的 taosExplorer 服务,在 “数据浏览器” 页面找到 db2,在 “查看数据库配置” 选项中可以获取该数据库的 DSN,例如 taos+ws://root:taosdata@clusterB:6041/db2
|
||||
- 第 4 步,通过 Web 浏览器访问集群 B 的 taosExplorer 服务,在 “数据浏览器” 页面找到 db2,在 “查看数据库配置” 选项中可以获取该数据库的 DSN,例如 `taos+ws://root:taosdata@clusterB:6041/db2`
|
||||
|
||||
- 第 5 步,在 taosExplorer 服务的“系统管理 - 数据同步”页面新增一个数据同步任务,在任务配置信息中填写需要同步的数据库 db1 和目标数据库 db2 的 DSN,完成创建任务后即可启动数据同步。
|
||||
|
||||
- 第 6 步,访问集群 B,可以看到集群 B 中的数据库 db2 源源不断写入来自集群 A 数据库 db1 的数据,直至两个集群的数据库数据量基本保持一致。至此,一个简单的基于
|
||||
|
||||
TDengine Enterprise 的数据灾备体系搭建完成。
|
||||
- 第 6 步,访问集群 B,可以看到集群 B 中的数据库 db2 源源不断写入来自集群 A 数据库 db1 的数据,直至两个集群的数据库数据量基本保持一致。至此,一个简单的基于 TDengine Enterprise 的数据灾备体系搭建完成。
|
|
@ -5,10 +5,10 @@ toc_max_heading_level: 4
|
|||
---
|
||||
|
||||
本节介绍 TDengine Enterprise 特有的多级存储功能,其作用是将较近的热度较高的数据存储在高速介质上,而时间久远热度很低的数据存储在低成本介质上,达成了以下目标:
|
||||
- 降低存储成本 -- 将数据分级存储后,海量极冷数据存入廉价存储介质带来显著经济性
|
||||
- 提升写入性能 -- 得益于每级存储可支持多个挂载点,WAL 预写日志也支持 0 级的多挂载点并行写入,极大提升写入性能(实际场景测得支持持续写入每秒 3 亿测点以上),在机械硬盘上可获得极高磁盘 IO 吞吐(实测可达 2GB/s)
|
||||
- 方便维护 -- 配置好各级存储挂载点后,系统数据迁移等工作,无需人工干预;存储扩容更灵活、方便
|
||||
- 对 SQL 透明 -- 无论查询的数据是否跨级,一条 SQL 可返回所有数据,简单高效
|
||||
- **降低存储成本**:将数据分级存储后,海量极冷数据存入廉价存储介质带来显著经济性
|
||||
- **提升写入性能**:得益于每级存储可支持多个挂载点,WAL 预写日志也支持 0 级的多挂载点并行写入,极大提升写入性能(实际场景测得支持持续写入每秒 3 亿测点以上),在机械硬盘上可获得极高磁盘 IO 吞吐(实测可达 2GB/s)
|
||||
- **方便维护**:配置好各级存储挂载点后,系统数据迁移等工作,无需人工干预;存储扩容更灵活、方便
|
||||
- **对 SQL 透明**:无论查询的数据是否跨级,一条 SQL 可返回所有数据,简单高效
|
||||
|
||||
多级存储所涉及的各层存储介质都是本地存储设备。除了本地存储设备之外,TDengine Enterprise 还支持使用对象存储(S3),将最冷的一批数据保存在最廉价的介质上,以进一步降低存储成本,并在必要时仍然可以进行查询,且数据存储在哪里也对 SQL 透明。支持对象存储在 3.3.0.0 版本中首次发布,建议使用最新版本。
|
||||
|
||||
|
@ -26,9 +26,11 @@ dataDir [path] <level> <primary>
|
|||
```
|
||||
|
||||
- path: 挂载点的文件夹路径。
|
||||
- level: 介质存储等级,取值为 0,1,2。 0 级存储最新的数据,1 级存储次新的数据,2 级存储最老的数据,省略默认为 0。 各级存储之间的数据流向:0 级存储 -> 1 级存储 -> 2 级存储。 同一存储等级可挂载多个硬盘,同一存储等级上的数据文件分布在该存储等级的所有硬盘上。 需要说明的是,数据在不同级别的存储介质上的移动,是由系统自动完成的,用户无需干预。
|
||||
- primary: 是否为主挂载点,0(否)或 1(是),省略默认为 1。
|
||||
- level:介质存储等级,取值为 0、1、2。 0 级存储最新的数据,1 级存储次新的数据,2 级存储最老的数据,省略默认为 0。各级存储之间的数据流向:0 级存储 -> 1 级存储 -> 2 级存储。 同一存储等级可挂载多个硬盘,同一存储等级上的数据文件分布在该存储等级的所有硬盘上。需要说明的是,数据在不同级别的存储介质上的移动,是由系统自动完成的,用户无需干预。
|
||||
- primary:是否为主挂载点,0(否)或 1(是),省略默认为 1。
|
||||
|
||||
在配置中,只允许一个主挂载点的存在(level=0,primary=1),例如采用如下的配置方式:
|
||||
|
||||
```shell
|
||||
dataDir /mnt/data1 0 1
|
||||
dataDir /mnt/data2 0 0
|
||||
|
@ -38,7 +40,8 @@ dataDir /mnt/data5 2 0
|
|||
dataDir /mnt/data6 2 0
|
||||
```
|
||||
|
||||
**注意** 1. 多级存储不允许跨级配置,合法的配置方案有:仅 0 级,仅 0 级+ 1 级,以及 0 级+ 1 级+ 2 级。而不允许只配置 level=0 和 level=2,而不配置 level=1。
|
||||
**注意**
|
||||
1. 多级存储不允许跨级配置,合法的配置方案有:仅 0 级、仅 0 级 + 1 级、以及 0 级 + 1 级 + 2 级。而不允许只配置 level=0 和 level=2,而不配置 level=1。
|
||||
2. 禁止手动移除使用中的挂载盘,挂载盘目前不支持非本地的网络盘。
|
||||
|
||||
### 负载均衡
|
||||
|
@ -74,13 +77,13 @@ dataDir /mnt/data6 2 0
|
|||
|
||||
| 参数名称 | 参数含义 |
|
||||
|:---------------------|:-----------------------------------------------|
|
||||
| s3EndPoint | 用户所在地域的 COS 服务域名,支持 http 和 https,bucket 的区域需要与 endpoint 的保持一致,否则无法访问。 |
|
||||
| s3EndPoint | 用户所在地域的 COS 服务域名,支持 http 和 https,bucket 的区域需要与 endpoint 的保持一致,否则无法访问 |
|
||||
| s3AccessKey | 冒号分隔的用户 SecretId:SecretKey。例如:AKIDsQmwsfKxTo2A6nGVXZN0UlofKn6JRRSJ:lIdoy99ygEacU7iHfogaN2Xq0yumSm1E |
|
||||
| s3BucketName | 存储桶名称,减号后面是用户注册 COS 服务的 AppId。其中 AppId 是 COS 特有,AWS 和阿里云都没有,配置时需要作为 bucket name 的一部分,使用减号分隔。参数值均为字符串类型,但不需要引号。例如:test0711-1309024725 |
|
||||
| s3UploadDelaySec | data 文件持续多长时间不再变动后上传至 s3,单位:秒。最小值:1;最大值:2592000(30天),默认值 60 秒 |
|
||||
| s3PageCacheSize | S3 page cache 缓存页数目,单位:页。最小值:4;最大值:1024*1024*1024。 ,默认值 4096|
|
||||
| s3MigrateIntervalSec | 本地数据文件自动上传 S3 的触发周期,单位为秒。最小值:600;最大值:100000。默认值 3600 |
|
||||
| s3MigrateEnabled | 是否自动进行 S3 迁移,默认值为 0,表示关闭自动 S3 迁移,可配置为 1。 |
|
||||
| s3MigrateEnabled | 是否自动进行 S3 迁移,默认值为 0,表示关闭自动 S3 迁移,可配置为 1 |
|
||||
|
||||
#### 检查配置参数可用性
|
||||
|
||||
|
|
|
@ -56,7 +56,7 @@ alter_user_clause: {
|
|||
- pass:修改用户密码。
|
||||
- enable:是否启用用户。1 表示启用此用户,0 表示禁用此用户。
|
||||
- sysinfo :用户是否可查看系统信息。1 表示可以查看系统信息,0 表示不可以查看系统信息
|
||||
- createdb:用户是否可创建数据库。1 表示可以创建数据库,0 表示不可以创建数据库。// 从 TDengine 企业版 3.3.2.0 开始支持
|
||||
- createdb:用户是否可创建数据库。1 表示可以创建数据库,0 表示不可以创建数据库。从 TDengine 企业版 3.3.2.0 开始支持。
|
||||
|
||||
如下 SQL 禁用 test 用户。
|
||||
```sql
|
||||
|
@ -76,7 +76,7 @@ drop user user_name
|
|||
|
||||
### 库和表的授权
|
||||
|
||||
在 TDengine 中,库和表的权限分为 read (读)和 write (写)两种。这些权限可以单独授予,也可以同时授予用户。
|
||||
在 TDengine 中,库和表的权限分为 read 和 write 两种。这些权限可以单独授予,也可以同时授予用户。
|
||||
|
||||
- read 权限:拥有 read 权限的用户仅能查询库或表中的数据,而无法对数据进行修改或删除。这种权限适用于需要访问数据但不需要对数据进行写入操作的场景,如数据分析师、报表生成器等。
|
||||
- write 权限:拥有 write 权限的用户可以向库或表中写入数据。这种权限适用于需要对数据进行写入操作的场景,如数据采集器、数据处理器等。如果只拥有 write 权限而没有 read 权限,则只能写入数据但不能查询数据。
|
||||
|
@ -101,10 +101,11 @@ resources :{
|
|||
```
|
||||
|
||||
相关参数说明如下。
|
||||
- resources :可以访问的库或表。. 之前为数据库名称,. 之后为表名称。dbname.tbname 的意思是名为 dbname 的数据库中的 tbname 表必须为普通表或超级表。dbname.* 的意思是名为 dbname 的数据库中的所有表。*.* 的意思是所有数据库中的所有表。
|
||||
- tag_f ilter:超级表的过滤条件。
|
||||
- resources:可以访问的库或表。`.` 之前为数据库名称,`.` 之后为表名称。`dbname.tbname` 的意思是名为 dbname 的数据库中的 tbname 表必须为普通表或超级表。`dbname.*` 的意思是名为 dbname 的数据库中的所有表。`*.*` 的意思是所有数据库中的所有表。
|
||||
- tag_filter:超级表的过滤条件。
|
||||
|
||||
上述 SQL 既可以授权一个库、所有库,也可以授权一个库下的普通表或超级表,还可以通过 `dbname.tbname` 和 `with` 子句的组合授权符合过滤条件的一张超级表下的所有子表。
|
||||
|
||||
上述 SQL 既可以授权一个库、所有库,也可以授权一个库下的普通表或超级表,还可以通过 dbname.tbname 和 with 子句的组合授权符合过滤条件的一张超级表下的所有子表。
|
||||
如下 SQL 将数据库 power 的 read 权限授权给用户 test。
|
||||
```sql
|
||||
grant read on power to test
|
||||
|
|
|
@ -28,24 +28,24 @@ ALTER USER TEST DROP HOST HOST_NAME1
|
|||
```
|
||||
说明
|
||||
- 开源版和企业版本都能添加成功,且可以查询到,但是开源版本不会对 IP 做任何限制。
|
||||
- create user u_write pass 'taosdata1' host 'iprange1','iprange2', 可以一次添加多个 iprange, 服务端会做去重,去重的逻辑是需要 iprange 完全一样
|
||||
- 默认会把 127.0.0.1 添加到白名单列表,且在白名单列表可以查询
|
||||
- `create user u_write pass 'taosdata1' host 'iprange1','iprange2'`,可以一次添加多个 ip range,服务端会做去重,去重的逻辑是需要 ip range 完全一样
|
||||
- 默认会把 `127.0.0.1` 添加到白名单列表,且在白名单列表可以查询
|
||||
- 集群的节点 IP 集合会自动添加到白名单列表,但是查询不到。
|
||||
- taosadaper 和 taosd 不在一个机器的时候,需要把 taosadaper IP 手动添加到 taosd 白名单列表中
|
||||
- 集群情况下,各个节点 enableWhiteList 成一样,或者全为 false,或者全为 true, 要不然集群无法启动
|
||||
- 白名单变更生效时间 1s,不超过 2s, 每次变更对收发性能有些微影响(多一次判断,可以忽略),变更完之后、影响忽略不计, 变更过程中对集群没有影响,对正在访问客户端也没有影响(假设这些客户端的 IP 包含在 white list 内)
|
||||
- 如果添加两个 ip range, 192.168.1.1/16(假设为 A), 192.168.1.1/24(假设为 B), 严格来说,A 包含了 B,但是考虑情况太复杂,并不会对 A 和 B 做合并
|
||||
- 要删除的时候,必须严格匹配。 也就是如果添加的是 192.168.1.1/24, 要删除也是 192.168.1.1/24
|
||||
- 集群情况下,各个节点 enableWhiteList 成一样,或者全为 false,或者全为 true,要不然集群无法启动
|
||||
- 白名单变更生效时间 1s,不超过 2s,每次变更对收发性能有些微影响(多一次判断,可以忽略),变更完之后、影响忽略不计,变更过程中对集群没有影响,对正在访问客户端也没有影响(假设这些客户端的 IP 包含在 white list 内)
|
||||
- 如果添加两个 ip range,192.168.1.1/16(假设为 A),192.168.1.1/24(假设为 B),严格来说,A 包含了 B,但是考虑情况太复杂,并不会对 A 和 B 做合并
|
||||
- 要删除的时候,必须严格匹配。 也就是如果添加的是 192.168.1.1/24,要删除也是 192.168.1.1/24
|
||||
- 只有 root 才有权限对其他用户增删 ip white list
|
||||
- 兼容之前的版本,但是不支持从当前版本回退到之前版本
|
||||
- x.x.x.x/32 和 x.x.x.x 属于同一个 iprange, 显示为 x.x.x.x
|
||||
- 如果客户端拿到的 0.0.0.0/0, 说明没有开启白名单
|
||||
- x.x.x.x/32 和 x.x.x.x 属于同一个 iprange,显示为 x.x.x.x
|
||||
- 如果客户端拿到的 0.0.0.0/0,说明没有开启白名单
|
||||
- 如果白名单发生了改变, 客户端会在 heartbeat 里检测到。
|
||||
- 针对一个 user, 添加的 IP 个数上限是 2048
|
||||
- 针对一个 user,添加的 IP 个数上限是 2048
|
||||
|
||||
## 审计日志
|
||||
|
||||
TDengine 先对用户操作进行记录和管理,然后将这些作为审计日志发送给taosKeeper,再由 taosKeeper 保存至任意 TDengine 集群。管理员可通过审计日志进行安全监控、历史追溯。TDengine 的审计日志功能开启和关闭操作非常简单,只须修改TDengine 的配置文件后重启服务。审计日志的配置说明如下。
|
||||
TDengine 先对用户操作进行记录和管理,然后将这些作为审计日志发送给 taosKeeper,再由 taosKeeper 保存至任意 TDengine 集群。管理员可通过审计日志进行安全监控、历史追溯。TDengine 的审计日志功能开启和关闭操作非常简单,只须修改 TDengine 的配置文件后重启服务。审计日志的配置说明如下。
|
||||
|
||||
### taosd 配置
|
||||
|
||||
|
@ -53,7 +53,7 @@ TDengine 先对用户操作进行记录和管理,然后将这些作为审计
|
|||
|
||||
| 参数名称 | 参数含义 |
|
||||
|:-------------:|:--------------------------------------------------------:|
|
||||
|audit | 是否打开审计日志,默认值为 0。1 为开启,0 为关闭 |
|
||||
|audit | 是否打开审计日志,1 为开启,0 为关闭,默认值为 0。 |
|
||||
|monitorFqdn | 接收审计日志的 taosKeeper 所在服务器的 FQDN |
|
||||
|monitorPort | 接收审计日志的 taosKeeper 服务所用端口 |
|
||||
|monitorCompaction | 上报数据时是否进行压缩 |
|
||||
|
@ -64,7 +64,7 @@ TDengine 先对用户操作进行记录和管理,然后将这些作为审计
|
|||
|
||||
| 参数名称 | 参数含义 |
|
||||
|:-------------:|:--------------------------------------------------------:|
|
||||
|auditDB | 用于存放审计日志的数据库的名字,默认值为 "audit" ,taosKeeper 在收到上报的审计日志后会判断该数据库是否存在,如果不存在会自动创建它 |
|
||||
|auditDB | 用于存放审计日志的数据库的名字,默认值为 "audit",taosKeeper 在收到上报的审计日志后会判断该数据库是否存在,如果不存在会自动创建 |
|
||||
|
||||
### 数据格式
|
||||
|
||||
|
@ -88,19 +88,19 @@ TDengine 先对用户操作进行记录和管理,然后将这些作为审计
|
|||
taosKeeper 会依据上报的审计数据在相应的数据库中自动建立超级表用于存储数据。该超级表的定义如下
|
||||
|
||||
```sql
|
||||
CREATE STABLE operations(ts timestamp, details VARCHAR(64000), User VARCHAR(25), Operation VARCHAR(20), db VARCHAR(65), resource VARCHAR(193), client_add(25)) TAGS (clusterID VARCHAR(64) );
|
||||
create stable operations(ts timestamp, details varchar(64000), user varchar(25), operation varchar(20), db varchar(65), resource varchar(193), client_add(25)) tags (clusterID varchar(64) );
|
||||
```
|
||||
|
||||
其中:
|
||||
1. db为操作涉及的database,resource为操作涉及的资源。
|
||||
2. User 和 Operation 为数据列,表示哪个用户在该对象上进行了什么操作
|
||||
其中
|
||||
1. db 为操作涉及的 database,resource 为操作涉及的资源。
|
||||
2. user 和 operation 为数据列,表示哪个用户在该对象上进行了什么操作
|
||||
3. timestamp 为时间戳列,表示操作发生时的时间
|
||||
4. details 为该操作的一些补充细节,在大多数操作下是所执行的操作的SQL语句。
|
||||
5. client_add为客户端地址,包括ip和端口
|
||||
4. details 为该操作的一些补充细节,在大多数操作下是所执行的操作的 SQL 语句。
|
||||
5. client_add 为客户端地址,包括 ip 和端口
|
||||
|
||||
### 操作列表
|
||||
|
||||
目前审计日志中所记录的操作列表以及每个操作中各字段的含义如下表(注:因为每个操作的实加者即 user 字段、时间戳字段和client_add在所有操作中的含义相同,下表不包含)
|
||||
目前审计日志中所记录的操作列表以及每个操作中各字段的含义(因为每个操作的施加者,即 user、client_add、时间戳字段在所有操作中的含义相同,下表不再描述)
|
||||
|
||||
| 操作 | Operation | DB | Resource | Details |
|
||||
| ----------------| ----------| ---------| ---------| --------|
|
||||
|
@ -110,8 +110,8 @@ CREATE STABLE operations(ts timestamp, details VARCHAR(64000), User VARCHAR(25
|
|||
| create stable | createStb | db name | stable name | SQL |
|
||||
| alter stable | alterStb | db name | stable name | SQL |
|
||||
| drop stable | dropStb | db name | stable name | SQL |
|
||||
| create user | createUser | NULL | 被创建的用户名 | 用户属性参数, (password除外) |
|
||||
| alter user | alterUser | NULL | 被修改的用户名 | 修改密码操作记录的是被修改的参数和新值 (password除外) ;其他操作记录SQL |
|
||||
| create user | createUser | NULL | 被创建的用户名 | 用户属性参数, (password 除外) |
|
||||
| alter user | alterUser | NULL | 被修改的用户名 | 修改密码记录被修改的参数和新值 (password 除外),其他操作记录 SQL |
|
||||
| drop user | dropUser | NULL | 被删除的用户名 | SQL |
|
||||
| create topic | createTopic | topic 所在 DB | 创建的 topic 名字 | SQL |
|
||||
| drop topic | cropTopic | topic 所在 DB | 删除的 topic 名字 | SQL |
|
||||
|
@ -123,7 +123,7 @@ CREATE STABLE operations(ts timestamp, details VARCHAR(64000), User VARCHAR(25
|
|||
| create qnode | createQnode | NULL | dnodeId | SQL |
|
||||
| drop qnode | dropQnode | NULL | dnodeId | SQL |
|
||||
| login | login | NULL | NULL | appName |
|
||||
| create stream | createStream | NULL | 所创建的 strem 名 | SQL |
|
||||
| create stream | createStream | NULL | 所创建的 stream 名 | SQL |
|
||||
| drop stream | dropStream | NULL | 所删除的 stream 名 | SQL |
|
||||
| grant privileges| grantPrivileges | NULL | 所授予的用户 | SQL |
|
||||
| remove privileges | revokePrivileges | NULL | 被收回权限的用户 | SQL |
|
||||
|
@ -171,7 +171,7 @@ database_option: {
|
|||
```
|
||||
|
||||
主要参数说明如下。
|
||||
encrypt_algorithm:指定数据采用的加密算法。默认是 none,即不采用加密。sm4 表示采用 SM4 加密算法
|
||||
- encrypt_algorithm:指定数据采用的加密算法。默认是 none,即不采用加密。sm4 表示采用 SM4 加密算法
|
||||
|
||||
### 查看加密配置
|
||||
|
||||
|
@ -186,7 +186,7 @@ select name, `encrypt_algorithm` from ins_databases;
|
|||
|
||||
### 查看节点密钥状态
|
||||
|
||||
通过以下的SQL命令参看节点密钥状态:
|
||||
通过以下的 SQL 命令参看节点密钥状态。
|
||||
|
||||
```sql
|
||||
show encryptions;
|
||||
|
@ -200,12 +200,12 @@ select * from information_schema.ins_encryptions;
|
|||
```
|
||||
key_status 有三种取值:
|
||||
- 当节点未设置密钥时,状态列显示 unset。
|
||||
- 当密钥被检验成功并且加载后,状态列显示 loaded.
|
||||
- 当节点未启动,key的状态无法被探知时,状态列显示 unknown
|
||||
- 当密钥被检验成功并且加载后,状态列显示 loaded。
|
||||
- 当节点未启动,key 的状态无法被探知时,状态列显示 unknown。
|
||||
|
||||
### 更新密钥配置
|
||||
|
||||
当节点的硬件配置发生变更时,需要通过以下命令更新密钥,与离线配置密钥的命令相同:
|
||||
当节点的硬件配置发生变更时,需要通过以下命令更新密钥,与离线配置密钥的命令相同。
|
||||
|
||||
```shell
|
||||
taosd -y {encryptKey}
|
||||
|
|
|
@ -81,7 +81,12 @@ taosx replica start -f source_endpoint -t sink_endpoint [database...]
|
|||
taosx replica start -f td1:6030 -t td2:6030
|
||||
```
|
||||
|
||||
该示例命令会自动创建除 information_schema、performance_schema、log、audit 库之外的同步任务。可以使用 `http://td2:6041` 指定该 endpoint 使用 websocket 接口(默认是原生接口)。也可以指定数据库同步:taosx replica start -f td1:6030 -t td2:6030 db1 仅创建指定的数据库同步任务。
|
||||
该示例命令会自动创建除 information_schema、performance_schema、log、audit 库之外的同步任务,并持续监听新增的数据库,当 td1 和 td2 中新增同名数据库时可自动启动新增数据库的数据复制任务。需要说明的是:
|
||||
|
||||
- 可以使用 `http://td2:6041` 指定该 endpoint 使用 websocket 接口(默认是原生接口)。
|
||||
- 可以使用 `--new-database-checking-interval <SECONDS>` 指定新增数据库的检查间隔,默认为 30 分钟。
|
||||
- 可以使用 `--no-new-databases` 禁用监听行为。
|
||||
- 也可以指定数据库同步:taosx replica start -f td1:6030 -t td2:6030 db1 仅创建指定的数据库同步任务。此时相当于配置了 `--no-new-databases`,不会开启新增数据库自动同步。
|
||||
|
||||
2. 方法二
|
||||
|
||||
|
@ -121,6 +126,7 @@ taosx replica stop id [db...]
|
|||
该命令作用如下:
|
||||
1. 停止指定 Replica ID 下所有或指定数据库的双副本同步任务。
|
||||
2. 使用 `taosx replica stop id1 db1` 表示停止 id1 replica 下 db1的同步任务。
|
||||
3. `--no-new-databases` 选项启用时,不停止新增数据库监听任务,仅停止当前同步中的数据库。
|
||||
|
||||
### 重启双活任务
|
||||
|
||||
|
@ -145,8 +151,8 @@ taosx replica diff id [db....]
|
|||
| replica | database | source | sink | vgroup_id | current | latest | diff |
|
||||
+---------+----------+----------+----------+-----------+---------+---------+------+
|
||||
| a | opc | td1:6030 | td2:6030 | 2 | 17600 | 17600 | 0 |
|
||||
| ad | opc | td2:6030 | td2:6030 | 3 | 17600 | 17600 | 0 |
|
||||
```
|
||||
| a | opc | td2:6030 | td2:6030 | 3 | 17600 | 17600 | 0 |
|
||||
```
|
||||
|
||||
### 删除双活任务
|
||||
|
||||
|
@ -156,6 +162,16 @@ taosx replica remove id [--force]
|
|||
|
||||
删除当前所有双活同步任务。正常情况下要想删除同步任务,需要先 stop 该任务;但当 --force 启用时,会强制停止并清除任务。
|
||||
|
||||
`--no-new-databases` 选项启用时,不会删除新增数据库同步任务,仅删除当前数据库的同步任务。当 taosx 重启后,如果删除的数据库任务对应的数据库仍然存在,则会继续创建同步任务;不重启 taosx 或者不更新双活监听任务时,也不会再新建这些数据库的同步任务。
|
||||
|
||||
### 更新双活新增数据库检查间隔
|
||||
|
||||
```shell
|
||||
taosx replica update id --new-database-checking-interval <SECONDS>
|
||||
```
|
||||
|
||||
更新双活新增数据库的检查间隔,单位为秒。
|
||||
|
||||
### 推荐使用步骤
|
||||
|
||||
1. 假定在机器 A 上运行,需要首先使用 taosx replica start 来配置 taosX,其输入参数是待同步的源端和目标端服务器地址 ,在完成配置后会自动启动同步服务和任务。此处假定 taosx 服务使用标准端口,同步任务使用原生连接。
|
||||
|
|
|
@ -6,7 +6,7 @@ description: 使用 Prometheus 访问 TDengine
|
|||
|
||||
import Prometheus from "../../14-reference//01-components/_prometheus.mdx"
|
||||
|
||||
Prometheus 是一款流行的开源监控告警系统。Prometheus 于2016年加入了 Cloud Native Computing Foundation (云原生云计算基金会,简称 CNCF),成为继 Kubernetes 之后的第二个托管项目,该项目拥有非常活跃的开发人员和用户社区。
|
||||
Prometheus 是一款流行的开源监控告警系统。Prometheus 于 2016 年加入了 Cloud Native Computing Foundation (云原生云计算基金会,简称 CNCF),成为继 Kubernetes 之后的第二个托管项目,该项目拥有非常活跃的开发人员和用户社区。
|
||||
|
||||
Prometheus 提供了 `remote_write` 和 `remote_read` 接口来利用其它数据库产品作为它的存储引擎。为了让 Prometheus 生态圈的用户能够利用 TDengine 的高效写入和查询,TDengine 也提供了对这两个接口的支持。
|
||||
|
||||
|
@ -17,7 +17,7 @@ Prometheus 提供了 `remote_write` 和 `remote_read` 接口来利用其它数
|
|||
要将 Prometheus 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- Prometheus 已经安装。安装 Prometheus 请参考[官方文档](https://prometheus.io/docs/prometheus/latest/installation/)
|
||||
- Prometheus 已经安装。安装 Prometheus 请参考 [官方文档](https://prometheus.io/docs/prometheus/latest/installation/)
|
||||
|
||||
## 配置步骤
|
||||
<Prometheus />
|
||||
|
|
|
@ -15,8 +15,8 @@ Telegraf 是一款十分流行的指标采集开源软件。在数据采集和
|
|||
要将 Telegraf 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- Telegraf 已经安装。安装 Telegraf 请参考[官方文档](https://docs.influxdata.com/telegraf/v1.22/install/)
|
||||
- Telegraf 默认采集系统运行状态数据。通过使能[输入插件](https://docs.influxdata.com/telegraf/v1.22/plugins/)方式可以输出[其他格式](https://docs.influxdata.com/telegraf/v1.24/data_formats/input/)的数据到 Telegraf 再写入到 TDengine中。
|
||||
- Telegraf 已经安装。安装 Telegraf 请参考 [官方文档](https://docs.influxdata.com/telegraf/v1.22/install/)
|
||||
- Telegraf 默认采集系统运行状态数据。通过使能 [输入插件](https://docs.influxdata.com/telegraf/v1.22/plugins/)方式可以输出 [其他格式](https://docs.influxdata.com/telegraf/v1.24/data_formats/input/) 的数据到 Telegraf 再写入到 TDengine中。
|
||||
|
||||
## 配置步骤
|
||||
<Telegraf />
|
||||
|
|
|
@ -14,7 +14,7 @@ collectd 是一个用来收集系统性能的守护进程。collectd 提供各
|
|||
|
||||
要将 collectd 数据写入 TDengine,需要几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行,具体细节请参考[ taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- taosAdapter 已经安装并正常运行,具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- collectd 已经安装。安装 collectd 请参考[官方文档](https://collectd.org/download.shtml)
|
||||
|
||||
## 配置步骤
|
||||
|
|
|
@ -15,7 +15,7 @@ StatsD 是汇总和总结应用指标的一个简单的守护进程,近些年
|
|||
要将 StatsD 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- StatsD 已经安装。安装 StatsD 请参考[官方文档](https://github.com/statsd/statsd)
|
||||
- StatsD 已经安装。安装 StatsD 请参考 [官方文档](https://github.com/statsd/statsd)
|
||||
|
||||
## 配置步骤
|
||||
<StatsD />
|
||||
|
|
|
@ -14,8 +14,8 @@ icinga2 是一款开源主机、网络监控软件,最初由 Nagios 网络监
|
|||
|
||||
要将 icinga2 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考[ taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- icinga2 已经安装。安装 icinga2 请参考[官方文档](https://icinga.com/docs/icinga-2/latest/doc/02-installation/)
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- icinga2 已经安装。安装 icinga2 请参考 [官方文档](https://icinga.com/docs/icinga-2/latest/doc/02-installation/)
|
||||
|
||||
## 配置步骤
|
||||
<Icinga2 />
|
||||
|
|
|
@ -15,7 +15,7 @@ TCollector 是 openTSDB 的一部分,它用来采集客户端日志发送给
|
|||
要将 TCollector 数据写入 TDengine 需要以下几方面的准备工作。
|
||||
- TDengine 集群已经部署并正常运行
|
||||
- taosAdapter 已经安装并正常运行。具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)
|
||||
- TCollector 已经安装。安装 TCollector 请参考[官方文档](http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html#installation-of-tcollector)
|
||||
- TCollector 已经安装。安装 TCollector 请参考 [官方文档](http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html#installation-of-tcollector)
|
||||
|
||||
## 配置步骤
|
||||
<TCollector />
|
||||
|
|
|
@ -4,7 +4,7 @@ title: EMQX Broker 写入
|
|||
description: 使用 EMQX Broker 写入 TDengine
|
||||
---
|
||||
|
||||
MQTT 是流行的物联网数据传输协议,[EMQX](https://github.com/emqx/emqx)是一开源的 MQTT Broker 软件,无需任何代码,只需要在 EMQX Dashboard 里使用“规则”做简单配置,即可将 MQTT 的数据直接写入 TDengine。EMQX 支持通过 发送到 Web 服务的方式保存数据到 TDengine,也在企业版上提供原生的 TDengine 驱动实现直接保存。
|
||||
MQTT 是流行的物联网数据传输协议,[EMQX](https://github.com/emqx/emqx) 是一开源的 MQTT Broker 软件,无需任何代码,只需要在 EMQX Dashboard 里使用“规则”做简单配置,即可将 MQTT 的数据直接写入 TDengine。EMQX 支持通过 发送到 Web 服务的方式保存数据到 TDengine,也在企业版上提供原生的 TDengine 驱动实现直接保存。
|
||||
|
||||
## 前置条件
|
||||
|
||||
|
@ -30,7 +30,7 @@ USE test;
|
|||
CREATE TABLE sensor_data (ts TIMESTAMP, temperature FLOAT, humidity FLOAT, volume FLOAT, pm10 FLOAT, pm25 FLOAT, so2 FLOAT, no2 FLOAT, co FLOAT, sensor_id NCHAR(255), area TINYINT, coll_time TIMESTAMP);
|
||||
```
|
||||
|
||||
注:表结构以博客[数据传输、存储、展现,EMQX + TDengine 搭建 MQTT 物联网数据可视化平台](https://www.taosdata.com/blog/2020/08/04/1722.html)为例。后续操作均以此博客场景为例进行,请你根据实际应用场景进行修改。
|
||||
注:表结构以博客 [数据传输、存储、展现,EMQX + TDengine 搭建 MQTT 物联网数据可视化平台](https://www.taosdata.com/blog/2020/08/04/1722.html) 为例。后续操作均以此博客场景为例进行,请你根据实际应用场景进行修改。
|
||||
|
||||
## 配置 EMQX 规则
|
||||
|
||||
|
@ -59,7 +59,7 @@ FROM
|
|||
"sensor/data"
|
||||
```
|
||||
|
||||
其中 `payload` 代表整个消息体, `sensor/data` 为本规则选取的消息主题。
|
||||
其中 `payload` 代表整个消息体,`sensor/data` 为本规则选取的消息主题。
|
||||
|
||||

|
||||
|
||||
|
@ -75,7 +75,7 @@ FROM
|
|||
|
||||
### 编辑“资源(Resource)”
|
||||
|
||||
选择“WebHook”并填写“请求 URL”为 taosAdapter 提供 REST 服务的地址,如果是本地启动的 taosadapter, 那么默认地址为:
|
||||
选择 “WebHook” 并填写“请求 URL”为 taosAdapter 提供 REST 服务的地址,如果是本地启动的 taosadapter, 那么默认地址为:
|
||||
|
||||
```
|
||||
http://127.0.0.1:6041/rest/sql
|
||||
|
|
|
@ -4,7 +4,7 @@ title: TDengine Kafka Connector
|
|||
description: 使用 TDengine Kafka Connector 的详细指南
|
||||
---
|
||||
|
||||
TDengine Kafka Connector 包含两个插件: TDengine Source Connector 和 TDengine Sink Connector。用户只需提供简单的配置文件,就可以将 Kafka 中指定 topic 的数据(批量或实时)同步到 TDengine, 或将 TDengine 中指定数据库的数据(批量或实时)同步到 Kafka。
|
||||
TDengine Kafka Connector 包含 TDengine Source Connector 和 TDengine Sink Connector 两个插件。用户只需提供简单的配置文件,就可以将 Kafka 中指定 topic 的数据(批量或实时)同步到 TDengine,或将 TDengine 中指定数据库的数据(批量或实时)同步到 Kafka。
|
||||
|
||||
## 什么是 Kafka Connect?
|
||||
|
||||
|
@ -23,7 +23,7 @@ TDengine Source Connector 用于把数据实时地从 TDengine 读出来发送
|
|||
1. Linux 操作系统
|
||||
2. 已安装 Java 8 和 Maven
|
||||
3. 已安装 Git、curl、vi
|
||||
4. 已安装并启动 TDengine。如果还没有可参考[安装和卸载](../../../get-started/)
|
||||
4. 已安装并启动 TDengine。如果还没有可参考 [安装和卸载](../../../get-started/)
|
||||
|
||||
## 安装 Kafka
|
||||
|
||||
|
@ -90,9 +90,9 @@ curl http://localhost:8083/connectors
|
|||
|
||||
## TDengine Sink Connector 的使用
|
||||
|
||||
TDengine Sink Connector 的作用是同步指定 topic 的数据到 TDengine。用户无需提前创建数据库和超级表。可手动指定目标数据库的名字(见配置参数 connection.database), 也可按一定规则生成(见配置参数 connection.database.prefix)。
|
||||
TDengine Sink Connector 的作用是同步指定 topic 的数据到 TDengine。用户无需提前创建数据库和超级表。可手动指定目标数据库的名字(见配置参数 connection.database),也可按一定规则生成(见配置参数 connection.database.prefix)。
|
||||
|
||||
TDengine Sink Connector 内部使用 TDengine [无模式写入接口](../../../develop/schemaless)写数据到 TDengine,目前支持三种格式的数据:InfluxDB 行协议格式,OpenTSDB Telnet 协议格式,和 OpenTSDB JSON 协议格式。
|
||||
TDengine Sink Connector 内部使用 TDengine [无模式写入接口](../../../develop/schemaless) 写数据到 TDengine,目前支持三种格式的数据:InfluxDB 行协议格式,OpenTSDB Telnet 协议格式,和 OpenTSDB JSON 协议格式。
|
||||
|
||||
下面的示例将主题 meters 的数据,同步到目标数据库 power。数据格式为 InfluxDB Line 协议格式。
|
||||
|
||||
|
@ -205,7 +205,7 @@ taos> select * from meters;
|
|||
Query OK, 4 row(s) in set (0.004208s)
|
||||
```
|
||||
|
||||
若看到了以上数据,则说明同步成功。若没有,请检查 Kafka Connect 的日志。配置参数的详细说明见[配置参考](#配置参考)。
|
||||
若看到了以上数据,则说明同步成功。若没有,请检查 Kafka Connect 的日志。配置参数的详细说明见 [配置参考](#配置参考)。
|
||||
|
||||
## TDengine Source Connector 的使用
|
||||
|
||||
|
@ -284,7 +284,7 @@ curl -X POST -d @source-demo.json http://localhost:8083/connectors -H "Content-T
|
|||
|
||||
### 查看 topic 数据
|
||||
|
||||
使用 kafka-console-consumer 命令行工具监控主题 tdengine-test-meters 中的数据。一开始会输出所有历史数据, 往 TDengine 插入两条新的数据之后,kafka-console-consumer 也立即输出了新增的两条数据。 输出数据 InfluxDB line protocol 的格式。
|
||||
使用 kafka-console-consumer 命令行工具监控主题 tdengine-test-meters 中的数据。一开始会输出所有历史数据,往 TDengine 插入两条新的数据之后,kafka-console-consumer 也立即输出了新增的两条数据。输出数据 InfluxDB line protocol 的格式。
|
||||
|
||||
```shell
|
||||
kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic tdengine-test-meters
|
||||
|
@ -299,7 +299,7 @@ meters,location="California.SanFrancisco",groupid=2i32 current=12.6f32,voltage=2
|
|||
......
|
||||
```
|
||||
|
||||
此时会显示所有历史数据。切换到 TDengine CLI, 插入两条新的数据:
|
||||
此时会显示所有历史数据。切换到 TDengine CLI,插入两条新的数据:
|
||||
|
||||
```sql
|
||||
USE test;
|
||||
|
@ -307,7 +307,7 @@ INSERT INTO d1001 VALUES (now, 13.3, 229, 0.38);
|
|||
INSERT INTO d1002 VALUES (now, 16.3, 233, 0.22);
|
||||
```
|
||||
|
||||
再切换回 kafka-console-consumer, 此时命令行窗口已经打印出刚插入的 2 条数据。
|
||||
再切换回 kafka-console-consumer,此时命令行窗口已经打印出刚插入的 2 条数据。
|
||||
|
||||
### unload 插件
|
||||
|
||||
|
@ -335,7 +335,7 @@ curl -X DELETE http://localhost:8083/connectors/TDengineSourceConnector
|
|||
| **参数** | **参数说明** | **设置建议** |
|
||||
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
|
||||
| producer.type | 此参数用于设置消息的发送方式,默认值为 `sync` 表示同步发送,`async` 表示异步发送。采用异步发送能够提升消息发送的吞吐量。 | async |
|
||||
| request.required.acks | 参数用于配置生产者发送消息后需要等待的确认数量。当设置为1时,表示只要领导者副本成功写入消息就会给生产者发送确认,而无需等待集群中的其他副本写入成功。这种设置可以在一定程度上保证消息的可靠性,同时也能保证一定的吞吐量。因为不需要等待所有副本都写入成功,所以可以减少生产者的等待时间,提高发送消息的效率。 | 1 |
|
||||
| request.required.acks | 参数用于配置生产者发送消息后需要等待的确认数量。当设置为 1 时,表示只要领导者副本成功写入消息就会给生产者发送确认,而无需等待集群中的其他副本写入成功。这种设置可以在一定程度上保证消息的可靠性,同时也能保证一定的吞吐量。因为不需要等待所有副本都写入成功,所以可以减少生产者的等待时间,提高发送消息的效率。 | 1 |
|
||||
| max.request.size | 该参数决定了生产者在一次请求中可以发送的最大数据量。其默认值为 1048576,也就是 1M。如果设置得太小,可能会导致频繁的网络请求,降低吞吐量。如果设置得太大,可能会导致内存占用过高,或者在网络状况不佳时增加请求失败的概率。建议设置为 100M。 | 104857600 |
|
||||
| batch.size | 此参数用于设定 batch 的大小,默认值为 16384,即 16KB。在消息发送过程中,发送到 Kafka 缓冲区中的消息会被划分成一个个的 batch。故而减小 batch 大小有助于降低消息延迟,而增大 batch 大小则有利于提升吞吐量,可根据实际的数据量大小进行合理配置。可根据实际情况进行调整,建议设置为 512K。 | 524288 |
|
||||
| buffer.memory | 此参数用于设置生产者缓冲待发送消息的内存总量。较大的缓冲区可以允许生产者积累更多的消息后批量发送,提高吞吐量,但也会增加延迟和内存使用。可根据机器资源来配置,建议配置为 1G。 | 1073741824 |
|
||||
|
@ -346,51 +346,51 @@ curl -X DELETE http://localhost:8083/connectors/TDengineSourceConnector
|
|||
|
||||
以下配置项对 TDengine Sink Connector 和 TDengine Source Connector 均适用。
|
||||
|
||||
1. `name`: connector 名称。
|
||||
1. `connector.class`: connector 的完整类名, 如: com.taosdata.kafka.connect.sink.TDengineSinkConnector。
|
||||
1. `tasks.max`: 最大任务数, 默认 1。
|
||||
1. `topics`: 需要同步的 topic 列表, 多个用逗号分隔, 如 `topic1,topic2`。
|
||||
1. `connection.url`: TDengine JDBC 连接字符串, 如 `jdbc:TAOS://127.0.0.1:6030`。
|
||||
1. `connection.user`: TDengine 用户名, 默认 root。
|
||||
1. `connection.password` :TDengine 用户密码, 默认 taosdata。
|
||||
1. `connection.attempts` :最大尝试连接次数。默认 3。
|
||||
1. `connection.backoff.ms` : 创建连接失败重试时间隔时间,单位为 ms。 默认 5000。
|
||||
1. `data.precision`: 使用 InfluxDB 行协议格式时,时间戳的精度。可选值为:
|
||||
1. ms : 表示毫秒
|
||||
1. us : 表示微秒
|
||||
1. ns : 表示纳秒
|
||||
1. `name`:connector 名称。
|
||||
1. `connector.class`:connector 的完整类名,例如如 com.taosdata.kafka.connect.sink.TDengineSinkConnector。
|
||||
1. `tasks.max`:最大任务数, 默认 1。
|
||||
1. `topics`:需要同步的 topic 列表,多个用逗号分隔, 如 `topic1,topic2`。
|
||||
1. `connection.url`:TDengine JDBC 连接字符串,如 `jdbc:TAOS://127.0.0.1:6030`。
|
||||
1. `connection.user`:TDengine 用户名,默认 root。
|
||||
1. `connection.password`:TDengine 用户密码,默认 taosdata。
|
||||
1. `connection.attempts`:最大尝试连接次数。默认 3。
|
||||
1. `connection.backoff.ms`:创建连接失败重试时间隔时间,单位为 ms。默认 5000。
|
||||
1. `data.precision`:使用 InfluxDB 行协议格式时,时间戳的精度。可选值为:
|
||||
1. ms:表示毫秒
|
||||
1. us:表示微秒
|
||||
1. ns:表示纳秒
|
||||
|
||||
### TDengine Sink Connector 特有的配置
|
||||
|
||||
1. `connection.database`: 目标数据库名。如果指定的数据库不存在会则自动创建。自动建库使用的时间精度为纳秒。默认值为 null。为 null 时目标数据库命名规则参考 `connection.database.prefix` 参数的说明
|
||||
2. `connection.database.prefix`: 当 connection.database 为 null 时, 目标数据库的前缀。可以包含占位符 '$\{topic}'。 比如 kafka_$\{topic}, 对于主题 'orders' 将写入数据库 'kafka_orders'。 默认 null。当为 null 时,目标数据库的名字和主题的名字是一致的。
|
||||
3. `batch.size`: 分批写入每批记录数。当 Sink Connector 一次接收到的数据大于这个值时将分批写入。
|
||||
4. `max.retries`: 发生错误时的最大重试次数。默认为 1。
|
||||
5. `retry.backoff.ms`: 发送错误时重试的时间间隔。单位毫秒,默认为 3000。
|
||||
6. `db.schemaless`: 数据格式,可选值为:
|
||||
1. line :代表 InfluxDB 行协议格式
|
||||
2. json : 代表 OpenTSDB JSON 格式
|
||||
3. telnet :代表 OpenTSDB Telnet 行协议格式
|
||||
1. `connection.database`:目标数据库名。如果指定的数据库不存在会则自动创建。自动建库使用的时间精度为纳秒。默认值为 null。为 null 时目标数据库命名规则参考 `connection.database.prefix` 参数的说明
|
||||
2. `connection.database.prefix`:当 connection.database 为 null 时, 目标数据库的前缀。可以包含占位符 '$\{topic}'。比如 kafka_$\{topic}, 对于主题 'orders' 将写入数据库 'kafka_orders'。默认 null。当为 null 时,目标数据库的名字和主题的名字是一致的。
|
||||
3. `batch.size`:分批写入每批记录数。当 Sink Connector 一次接收到的数据大于这个值时将分批写入。
|
||||
4. `max.retries`:发生错误时的最大重试次数。默认为 1。
|
||||
5. `retry.backoff.ms`:发送错误时重试的时间间隔。单位毫秒,默认为 3000。
|
||||
6. `db.schemaless`:数据格式,可选值为:
|
||||
1. line:代表 InfluxDB 行协议格式
|
||||
2. json:代表 OpenTSDB JSON 格式
|
||||
3. telnet:代表 OpenTSDB Telnet 行协议格式
|
||||
|
||||
### TDengine Source Connector 特有的配置
|
||||
|
||||
1. `connection.database`: 源数据库名称,无缺省值。
|
||||
1. `topic.prefix`: 数据导入 kafka 时使用的 topic 名称的前缀。默认为空字符串 ""。
|
||||
1. `timestamp.initial`: 数据同步起始时间。格式为'yyyy-MM-dd HH:mm:ss',若未指定则从指定 DB 中最早的一条记录开始。
|
||||
1. `poll.interval.ms`: 检查是否有新建或删除的表的时间间隔,单位为 ms。默认为 1000。
|
||||
1. `fetch.max.rows` : 检索数据库时最大检索条数。 默认为 100。
|
||||
1. `query.interval.ms`: 从 TDengine 一次读取数据的时间跨度,需要根据表中的数据特征合理配置,避免一次查询的数据量过大或过小;在具体的环境中建议通过测试设置一个较优值,默认值为 0,即获取到当前最新时间的所有数据。
|
||||
1. `out.format` : 结果集输出格式。`line` 表示输出格式为 InfluxDB Line 协议格式,`json` 表示输出格式是 json。默认为 line。
|
||||
1. `topic.per.stable`: 如果设置为 true,表示一个超级表对应一个 Kafka topic,topic的命名规则 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`;如果设置为 false,则指定的 DB 中的所有数据进入一个 Kafka topic,topic 的命名规则为 `<topic.prefix><topic.delimiter><connection.database>`
|
||||
1. `topic.ignore.db`: topic 命名规则是否包含 database 名称,true 表示规则为 `<topic.prefix><topic.delimiter><stable.name>`,false 表示规则为 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`,默认 false。此配置项在 `topic.per.stable` 设置为 false 时不生效。
|
||||
1. `topic.delimiter`: topic 名称分割符,默认为 `-`。
|
||||
1. `read.method`: 从 TDengine 读取数据方式,query 或是 subscription。默认为 subscription。
|
||||
1. `subscription.group.id`: 指定 TDengine 数据订阅的组 id,当 `read.method` 为 subscription 时,此项为必填项。
|
||||
1. `subscription.from`: 指定 TDengine 数据订阅起始位置,latest 或是 earliest。默认为 latest。
|
||||
1. `connection.database`:源数据库名称,无缺省值。
|
||||
1. `topic.prefix`:数据导入 kafka 时使用的 topic 名称的前缀。默认为空字符串 ""。
|
||||
1. `timestamp.initial`:数据同步起始时间。格式为'yyyy-MM-dd HH:mm:ss',若未指定则从指定 DB 中最早的一条记录开始。
|
||||
1. `poll.interval.ms`:检查是否有新建或删除的表的时间间隔,单位为 ms。默认为 1000。
|
||||
1. `fetch.max.rows`:检索数据库时最大检索条数。默认为 100。
|
||||
1. `query.interval.ms`:从 TDengine 一次读取数据的时间跨度,需要根据表中的数据特征合理配置,避免一次查询的数据量过大或过小;在具体的环境中建议通过测试设置一个较优值,默认值为 0,即获取到当前最新时间的所有数据。
|
||||
1. `out.format`:结果集输出格式。`line` 表示输出格式为 InfluxDB Line 协议格式,`json` 表示输出格式是 json。默认为 line。
|
||||
1. `topic.per.stable`:如果设置为 true,表示一个超级表对应一个 Kafka topic,topic的命名规则 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`;如果设置为 false,则指定的 DB 中的所有数据进入一个 Kafka topic,topic 的命名规则为 `<topic.prefix><topic.delimiter><connection.database>`
|
||||
1. `topic.ignore.db`:topic 命名规则是否包含 database 名称,true 表示规则为 `<topic.prefix><topic.delimiter><stable.name>`,false 表示规则为 `<topic.prefix><topic.delimiter><connection.database><topic.delimiter><stable.name>`,默认 false。此配置项在 `topic.per.stable` 设置为 false 时不生效。
|
||||
1. `topic.delimiter`:topic 名称分割符,默认为 `-`。
|
||||
1. `read.method`:从 TDengine 读取数据方式,query 或是 subscription。默认为 subscription。
|
||||
1. `subscription.group.id`:指定 TDengine 数据订阅的组 id,当 `read.method` 为 subscription 时,此项为必填项。
|
||||
1. `subscription.from`:指定 TDengine 数据订阅起始位置,latest 或是 earliest。默认为 latest。
|
||||
|
||||
## 其他说明
|
||||
|
||||
1. 关于如何在独立安装的 Kafka 环境使用 Kafka Connect 插件, 请参考官方文档:[https://kafka.apache.org/documentation/#connect](https://kafka.apache.org/documentation/#connect)。
|
||||
1. 关于如何在独立安装的 Kafka 环境使用 Kafka Connect 插件,请参考官方文档:[https://kafka.apache.org/documentation/#connect](https://kafka.apache.org/documentation/#connect)。
|
||||
|
||||
## 问题反馈
|
||||
|
||||
|
|
|
@ -222,7 +222,7 @@ Properties 中配置参数如下:
|
|||
- TDengineCdcParams.VALUE_DESERIALIZER:结果集反序列化方法,如果接收结果集类型是 `Flink` 的 `RowData`,仅需要设置为 `RowData`即可。可以继承 `com.taosdata.jdbc.tmq.ReferenceDeserializer`,并指定结果集 bean,实现反序列化。
|
||||
- TDengineCdcParams.TMQ_BATCH_MODE:此参数用于批量将数据推送给下游算子,如果设置为 True,创建 `TDengineCdcSource` 对象时需要指定数据类型为 `ConsumerRecords` 类型的泛型形式。
|
||||
- TDengineCdcParams.GROUP_ID:消费组 ID,同一消费组共享消费进度。最大长度:192。
|
||||
- TDengineCdcParams.AUTO_OFFSET_RESET: 消费组订阅的初始位置 ( `earliest` 从头开始订阅, `latest` 仅从最新数据开始订阅, 默认 `latest`)。
|
||||
- TDengineCdcParams.AUTO_OFFSET_RESET:消费组订阅的初始位置( `earliest` 从头开始订阅, `latest` 仅从最新数据开始订阅, 默认 `latest`)。
|
||||
- TDengineCdcParams.ENABLE_AUTO_COMMIT:是否启用消费位点自动提交,true: 自动提交;false:依赖 `checkpoint` 时间来提交, 默认 false。
|
||||
> **注意**:自动提交模式reader获取完成数据后自动提交,不管下游算子是否正确的处理了数据,存在数据丢失的风险,主要用于为了追求高效的无状态算子场景或是数据一致性要求不高的场景。
|
||||
|
||||
|
@ -232,7 +232,7 @@ Properties 中配置参数如下:
|
|||
- TDengineConfigParams.PROPERTY_KEY_RECONNECT_INTERVAL_MS:自动重连重试间隔,单位毫秒,默认值 2000。仅在 `PROPERTY_KEY_ENABLE_AUTO_RECONNECT` 为 true 时生效。
|
||||
- TDengineConfigParams.PROPERTY_KEY_RECONNECT_RETRY_COUNT:自动重连重试次数,默认值 3,仅在 `PROPERTY_KEY_ENABLE_AUTO_RECONNECT` 为 true 时生效。
|
||||
- TDengineCdcParams.TMQ_SESSION_TIMEOUT_MS:`consumer` 心跳丢失后超时时间,超时后会触发 `rebalance` 逻辑,成功后该 `consumer` 会被删除(从3.3.3.0版本开始支持), 默认值为 12000,取值范围 [6000, 1800000]。
|
||||
- TDengineCdcParams.TMQ_MAX_POLL_INTERVAL_MS:`consumer poll` 拉取数据间隔的最长时间,超过该时间,会认为该 `consumer` 离线,触发 `rebalance` 逻辑,成功后该 `consumer` 会被删除。 默认值为 300000,[1000,INT32_MAX]。
|
||||
- TDengineCdcParams.TMQ_MAX_POLL_INTERVAL_MS:`consumer poll` 拉取数据间隔的最长时间,超过该时间,会认为该 `consumer` 离线,触发 `rebalance` 逻辑,成功后该 `consumer` 会被删除。默认值为 300000,[1000,INT32_MAX]。
|
||||
|
||||
#### 使用 CDC 连接器
|
||||
|
||||
|
@ -279,9 +279,9 @@ Properties 中配置参数如下:
|
|||
- TDengineConfigParams.TD_SUPERTABLE_NAME:写入的超级表名称。接收的数据必须有 tbname 字段,确定写入那张子表。
|
||||
- TDengineConfigParams.TD_TABLE_NAME:写入子表或普通表的表名,此参数和TD_SUPERTABLE_NAME 仅需要设置一个即可。
|
||||
- TDengineConfigParams.VALUE_DESERIALIZER:接收结果集反序列化方法, 如果接收结果集类型是 `Flink` 的 `RowData`,仅需要设置为 `RowData`即可。也可继承 `TDengineSinkRecordSerializer` 并实现 `serialize` 方法,根据 接收的数据类型自定义反序列化方式。
|
||||
- TDengineConfigParams.TD_BATCH_SIZE:设置一次写入 `TDengine` 数据库的批大小 | 当到达批的数量后进行写入,或是一个checkpoint的时间也会触发写入数据库。
|
||||
- TDengineConfigParams.TD_BATCH_SIZE:设置一次写入 `TDengine` 数据库的批大小 | 当到达批的数量后进行写入,或是一个checkpoint的时间也会触发写入数据库。
|
||||
- TDengineConfigParams.TD_BATCH_MODE:接收批量数据当设置为 True 时,如果数据来源是 `TDengine Source`,则使用 `SourceRecords` 泛型类型来创建 `TDengineSink` 对象;若来源是 `TDengine CDC`,则使用 `ConsumerRecords` 泛型来创建 `TDengineSink` 对象。
|
||||
- TDengineConfigParams.TD_SOURCE_TYPE:设置数据来源。 当数据来源是 `TDengine Source` 是设置为 'tdengine_source', 当来源是 `TDengine CDC` 设置为 'tdengine_cdc'。当配置 `TD_BATCH_MODE` 为 True 生效。
|
||||
- TDengineConfigParams.TD_SOURCE_TYPE:设置数据来源。当数据来源是 `TDengine Source` 是设置为 'tdengine_source', 当来源是 `TDengine CDC` 设置为 'tdengine_cdc'。当配置 `TD_BATCH_MODE` 为 True 生效。
|
||||
- TDengineConfigParams.PROPERTY_KEY_MESSAGE_WAIT_TIMEOUT: 消息超时时间, 单位 ms, 默认值为 60000。
|
||||
- TDengineConfigParams.PROPERTY_KEY_ENABLE_COMPRESSION: 传输过程是否启用压缩。true: 启用,false: 不启用。默认为 false。
|
||||
- TDengineConfigParams.PROPERTY_KEY_ENABLE_AUTO_RECONNECT: 是否启用自动重连。true: 启用,false: 不启用。默认为 false。
|
||||
|
@ -355,7 +355,7 @@ Properties 中配置参数如下:
|
|||
| bootstrap.servers| string | 服务器地址。|
|
||||
| topic | string | 订阅主题。||
|
||||
| td.jdbc.mode | strng | 连接器类型, cdc, sink。|
|
||||
| group.id| string| 消费组 ID,同一消费组共享消费进度。 |
|
||||
| group.id| string| 消费组 ID,同一消费组共享消费进度。|
|
||||
| auto.offset.reset| string| 消费组订阅的初始位置。<br/>`earliest`: 从头开始订阅 <br/> `latest`: 仅从最新数据开始订阅。<br/> 默认 `latest`。|
|
||||
| poll.interval_ms| integer| 拉取数据间隔, 默认 500ms。|
|
||||
| sink.db.name|string| 目标数据库名称。|
|
||||
|
|
|
@ -32,7 +32,7 @@ import TabItem from "@theme/TabItem";
|
|||
使用 Grafana 最新版本(8.5+),您可以在 Grafana 中[浏览和管理插件](https://grafana.com/docs/grafana/next/administration/plugin-management/#plugin-catalog)(对于 7.x 版本,请采用 **安装脚本** 或 **手动安装** 方式)。在 Grafana 管理界面中的 **Configurations > Plugins** 页面直接搜索 `TDengine` 并按照提示安装。
|
||||
|
||||
安装完毕后,按照指示 **Create a TDengine data source** 添加数据源,输入 TDengine 相关配置:
|
||||
- Host: TDengine 集群中提供 REST 服务的 IP 地址与端口号,默认 `http://localhost:6041`
|
||||
- Host:TDengine 集群中提供 REST 服务的 IP 地址与端口号,默认 `http://localhost:6041`
|
||||
- User:TDengine 用户名。
|
||||
- Password:TDengine 用户密码。
|
||||
|
||||
|
@ -58,7 +58,7 @@ bash -c "$(curl -fsSL \
|
|||
</TabItem>
|
||||
<TabItem value="manual" label="手动安装">
|
||||
|
||||
使用 [`grafana-cli` 命令行工具](https://grafana.com/docs/grafana/latest/administration/cli/) 进行插件[安装](https://grafana.com/grafana/plugins/tdengine-datasource/?tab=installation)。
|
||||
使用 [`grafana-cli` 命令行工具](https://grafana.com/docs/grafana/latest/administration/cli/) 进行插件 [安装](https://grafana.com/grafana/plugins/tdengine-datasource/?tab=installation)。
|
||||
|
||||
```bash
|
||||
grafana-cli plugins install tdengine-datasource
|
||||
|
@ -92,7 +92,7 @@ GF_INSTALL_PLUGINS=tdengine-datasource
|
|||
|
||||
点击 `Add data source` 可进入新增数据源页面,在查询框中输入 TDengine, 然后点击 `select` 选择添加后会进入数据源配置页面,按照默认提示修改相应配置:
|
||||
|
||||
- Host: TDengine 集群中提供 REST 服务的 IP 地址与端口号,默认 `http://localhost:6041`
|
||||
- Host:TDengine 集群中提供 REST 服务的 IP 地址与端口号,默认 `http://localhost:6041`
|
||||
- User:TDengine 用户名。
|
||||
- Password:TDengine 用户密码。
|
||||
|
||||
|
@ -248,7 +248,7 @@ TDengine 在支持标准 SQL 的基础之上,还提供了一系列满足时序
|
|||
- `partition by` 子句可以按一定的维度对数据进行切分,然后在切分出的数据空间内再进行一系列的计算。绝大多数情况可以替代 `group by`。
|
||||
- `interval` 子句用于产生相等时间周期的窗口
|
||||
- `fill` 语句指定某一窗口区间数据缺失的情况下的填充模式
|
||||
- `时间戳伪列` 如果需要在结果中输出聚合结果所对应的时间窗口信息,需要在 SELECT 子句中使用时间戳相关的伪列: 时间窗口起始时间 (_wstart), 时间窗口结束时间 (_wend) 等
|
||||
- `时间戳伪列` 如果需要在结果中输出聚合结果所对应的时间窗口信息,需要在 SELECT 子句中使用时间戳相关的伪列:时间窗口起始时间 (_wstart), 时间窗口结束时间 (_wend) 等
|
||||
|
||||
上述特性详细介绍可以参考 [特色查询](../../../reference/taos-sql/distinguished/)。
|
||||
|
||||
|
@ -266,7 +266,7 @@ TDengine 在支持标准 SQL 的基础之上,还提供了一系列满足时序
|
|||
假设我们想查询一段时间内的平均电流大小,时间窗口按 `$interval` 切分,若某一时间窗口区间数据缺失,填充 null。
|
||||
- “INPUT SQL”:输入要查询的语句(该 SQL 语句的结果集应为两列多行),此处输入:`select _wstart as ts, avg(current) as current from power.meters where groupid in ($selected_groups) and ts > $from and ts < $to interval($interval) fill(null)` ,其中,from、to 和 interval 为 Grafana 内置变量,selected_groups 为自定义变量。
|
||||
- “ALIAS BY”:可设置当前查询别名。
|
||||
- “GENERATE SQL”: 点击该按钮会自动替换相应变量,并生成最终执行的语句。
|
||||
- “GENERATE SQL”:点击该按钮会自动替换相应变量,并生成最终执行的语句。
|
||||
|
||||
在顶部的自定义变量中,若选择 `selected_groups` 的值为 1,则查询 `meters` 超级表中 `groupid` 为 1 的所有设备电流平均值变化如下图:
|
||||
|
||||
|
@ -282,8 +282,8 @@ TDengine 在支持标准 SQL 的基础之上,还提供了一系列满足时序
|
|||
|
||||
假设我们想查询一段时间内的平均电流大小,按 `groupid` 分组展示,我们可以修改之前的 SQL 为 `select _wstart as ts, groupid, avg(current) as current from power.meters where ts > $from and ts < $to partition by groupid interval($interval) fill(null)`
|
||||
|
||||
- “Group by column(s)”: **半角**逗号分隔的 `group by` 或 `partition by` 列名。如果是 `group by` 或 `partition by` 查询语句,设置 “Group by” 列,可以展示多维数据。此处设置 “Group by” 列名为 `groupid`,可以按 `groupid` 分组展示数据。
|
||||
- “Group By Format”: `Group by` 或 `Partition by` 场景下多维数据 legend 格式化格式。例如上述 INPUT SQL,将 “Group By Format” 设置为 `groupid-{{groupid}}`,展示的 legend 名字为格式化的分组名。
|
||||
- “Group by column(s)”:**半角**逗号分隔的 `group by` 或 `partition by` 列名。如果是 `group by` 或 `partition by` 查询语句,设置 “Group by” 列,可以展示多维数据。此处设置 “Group by” 列名为 `groupid`,可以按 `groupid` 分组展示数据。
|
||||
- “Group By Format”:`Group by` 或 `Partition by` 场景下多维数据 legend 格式化格式。例如上述 INPUT SQL,将 “Group By Format” 设置为 `groupid-{{groupid}}`,展示的 legend 名字为格式化的分组名。
|
||||
|
||||
完成设置后,按照 `groupid` 分组展示如下图:
|
||||
|
||||
|
@ -306,10 +306,10 @@ TDengine 在支持标准 SQL 的基础之上,还提供了一系列满足时序
|
|||
|
||||
使用 TDengine 作为数据源的其他面板,可以[在此搜索](https://grafana.com/grafana/dashboards/?dataSource=tdengine-datasource)。以下是一份不完全列表:
|
||||
|
||||
- [15146](https://grafana.com/grafana/dashboards/15146): 监控多个 TDengine 集群
|
||||
- [15155](https://grafana.com/grafana/dashboards/15155): TDengine 告警示例
|
||||
- [15167](https://grafana.com/grafana/dashboards/15167): TDinsight
|
||||
- [16388](https://grafana.com/grafana/dashboards/16388): Telegraf 采集节点信息的数据展示
|
||||
- [15146](https://grafana.com/grafana/dashboards/15146):监控多个 TDengine 集群
|
||||
- [15155](https://grafana.com/grafana/dashboards/15155):TDengine 告警示例
|
||||
- [15167](https://grafana.com/grafana/dashboards/15167):TDinsight
|
||||
- [16388](https://grafana.com/grafana/dashboards/16388):Telegraf 采集节点信息的数据展示
|
||||
|
||||
## 告警配置
|
||||
|
||||
|
@ -357,7 +357,7 @@ from_address = sender@foxmail.com
|
|||
然后重启 Grafana 服务(以 Linux 系统为例,执行 `systemctl restart grafana-server.service`)即可添加完成
|
||||
|
||||
在 Grafana 页面找到 “Home” -> “Alerting” -> “Contact points”,创建新联络点
|
||||
“Name”: Email Contact Point
|
||||
“Name”:Email Contact Point
|
||||
“Integration”:选择联络类型,这里选择 Email,填写邮件接收地址,完成后保存联络点
|
||||
|
||||

|
||||
|
@ -389,9 +389,9 @@ from_address = sender@foxmail.com
|
|||

|
||||
|
||||
然后配置下列参数:
|
||||
- “Group wait”: 发送首次告警之前的等待时间。
|
||||
- “Group interval”: 发送第一个告警后,为该组发送下一批新告警的等待时间。
|
||||
- “Repeat interval”: 成功发送告警后再次重复发送告警的等待时间。
|
||||
- “Group wait”:发送首次告警之前的等待时间。
|
||||
- “Group interval”:发送第一个告警后,为该组发送下一批新告警的等待时间。
|
||||
- “Repeat interval”:成功发送告警后再次重复发送告警的等待时间。
|
||||
|
||||
### 配置告警规则
|
||||
|
||||
|
|
|
@ -3,26 +3,29 @@ sidebar_label: Looker
|
|||
title: 与 Looker Studio 的集成
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
Looker Studio,作为Google旗下的一个功能强大的报表和商业智能工具,前身名为Google Data Studio。在2022年的Google Cloud Next大会上,Google将其更名为Looker Studio。这个工具凭借其丰富的数据可视化选项和多样化的数据连接能力,为用户提供了便捷的数据报表生成体验。用户可以根据预设的模板轻松创建数据报表,满足各种数据分析需求。
|
||||
Looker Studio,作为 Google 旗下的一个功能强大的报表和商业智能工具,前身名为 Google Data Studio。在 2022 年的 Google Cloud Next 大会上,Google 将其更名为 Looker Studio。这个工具凭借其丰富的数据可视化选项和多样化的数据连接能力,为用户提供了便捷的数据报表生成体验。用户可以根据预设的模板轻松创建数据报表,满足各种数据分析需求。
|
||||
|
||||
由于其简单易用的操作界面和庞大的生态系统支持,Looker Studio在数据分析领域受到众多数据科学家和专业人士的青睐。无论是初学者还是资深分析师,都可以利用Looker Studio快速构建美观且实用的数据报表,从而更好地洞察业务趋势、优化决策过程并提升整体运营效率。
|
||||
由于其简单易用的操作界面和庞大的生态系统支持,Looker Studio 在数据分析领域受到众多数据科学家和专业人士的青睐。无论是初学者还是资深分析师,都可以利用 Looker Studio 快速构建美观且实用的数据报表,从而更好地洞察业务趋势、优化决策过程并提升整体运营效率。
|
||||
|
||||
## 获取
|
||||
|
||||
目前,TDengine连接器作为Looker Studio的合作伙伴连接器(partner connector),已在Looker Studio官网上线。用户访问Looker Studio的Data Source列表时,只须输入 “TDengine”进行搜索,便可轻松找到并立即使用TDengine连接器。
|
||||
目前,TDengine 连接器作为 Looker Studio 的合作伙伴连接器(partner connector),已在 Looker Studio 官网上线。用户访问 Looker Studio 的 Data Source 列表时,只须输入 “TDengine” 进行搜索,便可轻松找到并立即使用 TDengine 连接器。
|
||||
|
||||
TDengine连接器兼容TDengine Cloud和TDengine Server两种类型的数据源。TDengine Cloud是涛思数据推出的全托管物联网和工业互联网大数据云服务平台,为用户提供一站式数据存储、处理和分析解决方案;而TDengine Server则是用户自行部署的本地版本,支持通过公网访问。以下内容将以TDengine Cloud为例进行介绍。
|
||||
TDengine 连接器兼容 TDengine Cloud 和 TDengine Server 两种类型的数据源。TDengine Cloud 是涛思数据推出的全托管物联网和工业互联网大数据云服务平台,为用户提供一站式数据存储、处理和分析解决方案;而 TDengine Server 则是用户自行部署的本地版本,支持通过公网访问。以下内容将以 TDengine Cloud 为例进行介绍。
|
||||
|
||||
## 使用
|
||||
|
||||
在Looker Studio中使用TDengine连接器的步骤如下。
|
||||
在Looker Studio中使用 TDengine 连接器的步骤如下。
|
||||
|
||||
第1步,进入TDengine连接器的详情页面后,在Data Source下拉列表中选择TDengine Cloud,然后点击Next按钮,即可进入数据源配置页面。在该页面中填写以下信息,然后点击Connect按钮。
|
||||
- URL和TDengine Cloud Token,可以从TDengine Cloud的实例列表中获取。
|
||||
第 1 步,进入TDengine连接器的详情页面后,在 Data Source 下拉列表中选择 TDengine Cloud,然后点击 Next 按钮,即可进入数据源配置页面。在该页面中填写以下信息,然后点击 Connect 按钮。
|
||||
- URL 和 TDengine Cloud Token,可以从 TDengine Cloud 的实例列表中获取。
|
||||
- 数据库名称和超级表名称。
|
||||
- 查询数据的开始时间和结束时间。
|
||||
第2步,Looker Studio会根据配置自动加载所配置的TDengine数据库下的超级表的字段和标签。
|
||||
第3步,点击页面右上角的Explore按钮,即查看从TDengine数据库中加载的数据。
|
||||
第4步,根据需求,利用Looker Studio提供的图表,进行数据可视化的配置。
|
||||
|
||||
**注意** 在第一次使用时,请根据页面提示,对Looker Studio的TDengine连接器进行访问授权。
|
||||
第 2 步,Looker Studio 会根据配置自动加载所配置的 TDengine 数据库下的超级表的字段和标签。
|
||||
|
||||
第 3 步,点击页面右上角的 Explore 按钮,即查看从 TDengine 数据库中加载的数据。
|
||||
|
||||
第 4 步,根据需求,利用 Looker Studio 提供的图表,进行数据可视化的配置。
|
||||
|
||||
**注意** 在第一次使用时,请根据页面提示,对 Looker Studio 的 TDengine 连接器进行访问授权。
|
|
@ -30,7 +30,7 @@ Power BI 是由 Microsoft 提供的一种商业分析工具。通过配置使用
|
|||
|
||||
为了充分发挥 Power BI 在分析 TDengine中 数据方面的优势,用户需要先理解维度、度量、窗口切分查询、数据切分查询、时序和相关性等核心概念,之后通过自定义的 SQL 导入数据。
|
||||
- 维度:通常是分类(文本)数据,描述设备、测点、型号等类别信息。在 TDengine 的超级表中,使用标签列存储数据的维度信息,可以通过形如 `select distinct tbname, tag1, tag2 from supertable` 的 SQL 语法快速获得维度信息。
|
||||
- 度量:可以用于进行计算的定量(数值)字段,常见计算有求和、取平均值和最小值等。如果测点的采集周期为1s,那么一年就有 3000 多万条记录,把这些数据全部导入 Power BI 会严重影响其执行效率。在 TDengine 中,用户可以使用数据切分查询、窗口切分查询等语法,结合与窗口相关的伪列,把降采样后的数据导入 Power BI 中,具体语法请参阅 TDengine 官方文档的特色查询功能部分。
|
||||
- 度量:可以用于进行计算的定量(数值)字段,常见计算有求和、取平均值和最小值等。如果测点的采集周期为 1s,那么一年就有 3000 多万条记录,把这些数据全部导入 Power BI 会严重影响其执行效率。在 TDengine 中,用户可以使用数据切分查询、窗口切分查询等语法,结合与窗口相关的伪列,把降采样后的数据导入 Power BI 中,具体语法请参阅 TDengine 官方文档的特色查询功能部分。
|
||||
- 窗口切分查询:比如温度传感器每秒采集一次数据,但须查询每隔 10min 的温度平均值,在这种场景下可以使用窗口子句来获得需要的降采样查询结果,对应的 SQL 形如 `select tbname, _wstart date,avg(temperature) temp from table interval(10m)`,其中,`_wstart` 是伪列,表示时间窗口起始时间,10m 表示时间窗口的持续时间,`avg(temperature)` 表示时间窗口内的聚合值。
|
||||
- 数据切分查询:如果需要同时获取很多温度传感器的聚合数值,可对数据进行切分,然后在切分出的数据空间内进行一系列的计算,对应的 SQL 形如 `partition by part_list`。数据切分子句最常见的用法是在超级表查询中按标签将子表数据进行切分,将每个子表的数据独立出来,形成一条条独立的时间序列,方便针对各种时序场景的统计分析。
|
||||
- 时序:在绘制曲线或者按照时间聚合数据时,通常需要引入日期表。日期表可以从 Excel 表格中导入,也可以在 TDengine 中执行 SQL 获取,例如 `select _wstart date, count(*) cnt from test.meters where ts between A and B interval(1d) fill(0)`,其中 fill 字句表示数据缺失情况下的填充模式,伪列 _wstart 则为要获取的日期列。
|
||||
|
@ -76,4 +76,4 @@ select _wstart date, count(*) from test.meters interval(1d) having count(*)>0
|
|||
|
||||
**第 7 步**,制作报告。在柱状图、饼图等控件中使用这些数据。
|
||||
|
||||
由于TDengine处理时序数据的超强性能,使得用户在数据导入及每日定期刷新数据时,都可以得到非常好的体验。更多有关 Power BI 视觉效果的构建方法,请参照 Power BI 的官方文档。
|
||||
由于 TDengine 处理时序数据的超强性能,使得用户在数据导入及每日定期刷新数据时,都可以得到非常好的体验。更多有关 Power BI 视觉效果的构建方法,请参照 Power BI 的官方文档。
|
||||
|
|
|
@ -16,7 +16,7 @@ Tableau 是一款知名的商业智能工具,它支持多种数据源,可方
|
|||
|
||||
## 配置数据源
|
||||
|
||||
**第 1 步**,在Windows操作系统的开始菜单中搜索并打开“ODBC数据源(64位)”管理工具并进行配置。详细参考[配置ODBC数据源](../../../reference/connector/odbc/#配置数据源)。
|
||||
**第 1 步**,在 Windows 操作系统的开始菜单中搜索并打开“ODBC数据源(64位)”管理工具并进行配置。详细参考 [配置ODBC数据源](../../../reference/connector/odbc/#配置数据源)。
|
||||
|
||||
:::tip
|
||||
需要注意的是,在为 Tableau 配置 ODBC 数据源时,TDengine ODBC 数据源配置页面中的【数据库】配置项为必填项,需选择一个可成功连接的数据库。
|
||||
|
|
|
@ -10,7 +10,7 @@ DBeaver 是一款流行的跨平台数据库管理工具,方便开发者、数
|
|||
|
||||
使用 DBeaver 管理 TDengine 需要以下几方面的准备工作。
|
||||
|
||||
- 安装 DBeaver。DBeaver 支持主流操作系统包括 Windows、macOS 和 Linux。请注意[下载](https://dbeaver.io/download/)正确平台和版本(23.1.1+)的安装包。详细安装步骤请参考 [DBeaver 官方文档](https://github.com/dbeaver/dbeaver/wiki/Installation)。
|
||||
- 安装 DBeaver。DBeaver 支持主流操作系统包括 Windows、macOS 和 Linux。请注意 [下载](https://dbeaver.io/download/) 正确平台和版本(23.1.1+)的安装包。详细安装步骤请参考 [DBeaver 官方文档](https://github.com/dbeaver/dbeaver/wiki/Installation)。
|
||||
- 如果使用独立部署的 TDengine 集群,请确认 TDengine 正常运行,并且 taosAdapter 已经安装并正常运行,具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)。
|
||||
|
||||
## 使用 DBeaver 访问内部部署的 TDengine
|
||||
|
|
|
@ -10,17 +10,16 @@ qStudio 是一款免费的多平台 SQL 数据分析工具,可以轻松浏览
|
|||
|
||||
使用 qStudio 连接 TDengine 需要以下几方面的准备工作。
|
||||
|
||||
- 安装 qStudio。qStudio 支持主流操作系统包括 Windows、macOS 和 Linux。请注意[下载](https://www.timestored.com/qstudio/download/)正确平台的安装包。
|
||||
- 安装 qStudio。qStudio 支持主流操作系统包括 Windows、macOS 和 Linux。请注意 [下载](https://www.timestored.com/qstudio/download/) 正确平台的安装包。
|
||||
- 安装 TDengine 实例,请确认 TDengine 正常运行,并且 taosAdapter 已经安装并正常运行,具体细节请参考 [taosAdapter 的使用手册](../../../reference/components/taosadapter)。
|
||||
|
||||
## 使用 qStudio 连接 TDengine
|
||||
|
||||
1. 启动 qStudio 应用,从菜单项选择“Server” 和 “Add Server...”,然后在 Server Type 下拉框中选择 TDengine。
|
||||
1. 启动 qStudio 应用,从菜单项选择 “Server” 和 “Add Server...”,然后在 Server Type 下拉框中选择 TDengine。
|
||||
|
||||

|
||||
|
||||
2. 配置 TDengine 连接,填入主机地址、端口号、用户名和密码。如果 TDengine 部署在本机,可以只填用户名和密码,默认用户名为 root,默认密码为 taosdata。点击“Test”可以对连接是否可用进行测试。如果本机没有安装 TDengine Java
|
||||
连接器,qStudio 会提示下载安装。
|
||||
2. 配置 TDengine 连接,填入主机地址、端口号、用户名和密码。如果 TDengine 部署在本机,可以只填用户名和密码,默认用户名为 root,默认密码为 taosdata。点击 “Test” 可以对连接是否可用进行测试。如果本机没有安装 TDengine Java 连接器,qStudio 会提示下载安装。
|
||||
|
||||

|
||||
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -45,7 +45,7 @@ taosAdapter 提供了以下功能:
|
|||
|
||||
### WebSocket 接口
|
||||
|
||||
各语言连接器通过 taosAdapter 的 WebSocket 接口,能够实现 SQL 执行、无模式写入、参数绑定和数据订阅功能。参考[开发指南](../../../develop/connect/#websocket-连接)。
|
||||
各语言连接器通过 taosAdapter 的 WebSocket 接口,能够实现 SQL 执行、无模式写入、参数绑定和数据订阅功能。参考 [开发指南](../../../develop/connect/#websocket-连接)。
|
||||
|
||||
### 兼容 InfluxDB v1 写接口
|
||||
|
||||
|
@ -109,7 +109,7 @@ Prometheus 使用的由 \*NIX 内核暴露的硬件和操作系统指标的输
|
|||
|
||||
## 安装
|
||||
|
||||
taosAdapter 是 TDengine 服务端软件 的一部分,如果您使用 TDengine server 您不需要任何额外的步骤来安装 taosAdapter。您可以从[涛思数据官方网站](https://docs.taosdata.com/releases/tdengine/)下载 TDengine server 安装包。如果需要将 taosAdapter 分离部署在 TDengine server 之外的服务器上,则应该在该服务器上安装完整的 TDengine 来安装 taosAdapter。如果您需要使用源代码编译生成 taosAdapter,您可以参考[构建 taosAdapter](https://github.com/taosdata/taosadapter/blob/3.0/BUILD-CN.md)文档。
|
||||
taosAdapter 是 TDengine 服务端软件 的一部分,如果您使用 TDengine server 您不需要任何额外的步骤来安装 taosAdapter。您可以从 [涛思数据官方网站](https://docs.taosdata.com/releases/tdengine/)下载 TDengine server 安装包。如果需要将 taosAdapter 分离部署在 TDengine server 之外的服务器上,则应该在该服务器上安装完整的 TDengine 来安装 taosAdapter。如果您需要使用源代码编译生成 taosAdapter,您可以参考 [构建 taosAdapter](https://github.com/taosdata/taosadapter/blob/3.0/BUILD-CN.md)文档。
|
||||
|
||||
安装完成后使用命令 `systemctl start taosadapter` 可以启动 taosAdapter 服务。
|
||||
|
||||
|
|
|
@ -42,17 +42,17 @@ tmq+ws://root:taosdata@localhost:6030/db1?timeout=never
|
|||
- taos:使用查询接口从 TDengine 获取数据
|
||||
- tmq:启用数据订阅从 TDengine 获取数据
|
||||
- local:数据备份或恢复
|
||||
- pi: 启用 pi-connector从 pi 数据库中获取数据
|
||||
- pi:启用 pi-connector从 pi 数据库中获取数据
|
||||
- opc:启用 opc-connector 从 opc-server 中获取数据
|
||||
- mqtt: 启用 mqtt-connector 获取 mqtt-broker 中的数据
|
||||
- kafka: 启用 Kafka 连接器从 Kafka Topics 中订阅消息写入
|
||||
- influxdb: 启用 influxdb 连接器从 InfluxDB 获取数据
|
||||
- mqtt:启用 mqtt-connector 获取 mqtt-broker 中的数据
|
||||
- kafka:启用 Kafka 连接器从 Kafka Topics 中订阅消息写入
|
||||
- influxdb: 启用 influxdb 连接器从 InfluxDB 获取数据
|
||||
- csv:从 CSV 文件解析数据
|
||||
|
||||
2. +protocol 包含如下选项:
|
||||
- +ws: 当 driver 取值为 taos 或 tmq 时使用,表示使用 rest 获取数据。不使用 +ws 则表示使用原生连接获取数据,此时需要 taosx 所在的服务器安装 taosc。
|
||||
- +ua: 当 driver 取值为 opc 时使用,表示采集的数据的 opc-server 为 opc-ua
|
||||
- +da: 当 driver 取值为 opc 时使用,表示采集的数据的 opc-server 为 opc-da
|
||||
- +ws:当 driver 取值为 taos 或 tmq 时使用,表示使用 rest 获取数据。不使用 +ws 则表示使用原生连接获取数据,此时需要 taosx 所在的服务器安装 taosc。
|
||||
- +ua:当 driver 取值为 opc 时使用,表示采集的数据的 opc-server 为 opc-ua
|
||||
- +da:当 driver 取值为 opc 时使用,表示采集的数据的 opc-server 为 opc-da
|
||||
|
||||
3. host:port 表示数据源的地址和端口。
|
||||
4. object 表示具体的数据源,可以是TDengine的数据库、超级表、表,也可以是本地备份文件的路径,也可以是对应数据源服务器中的数据库。
|
||||
|
@ -251,7 +251,7 @@ d4,2017-07-14T10:40:00.006+08:00,-2.740636,10,-0.893545,7,California.LosAngles
|
|||
- `monitor.port`:`taosKeeper` 服务的端口,默认`6043`。
|
||||
- `monitor.interval`:向 `taosKeeper` 发送指标的频率,默认为每 10 秒一次,只有 1 到 10 之间的值才有效。
|
||||
- `log.path`:日志文件存放的目录。
|
||||
- `log.level`:日志级别,可选值为 "error", "warn", "info", "debug", "trace"。
|
||||
- `log.level`:日志级别,可选值为 "error"、"warn"、"info"、"debug"、"trace"。
|
||||
- `log.compress`:日志文件滚动后的文件是否进行压缩。
|
||||
- `log.rotationCount`:日志文件目录下最多保留的文件数,超出数量的旧文件被删除。
|
||||
- `log.rotationSize`:触发日志文件滚动的文件大小(单位为字节),当日志文件超出此大小后会生成一个新文件,新的日志会写入新文件。
|
||||
|
@ -401,17 +401,17 @@ taosX 会将监控指标上报给 taosKeeper,这些监控指标会被 taosKeep
|
|||
| -------------------------- | ----------------------------------------------------------------------------- |
|
||||
| sys_cpu_cores | 系统 CPU 核数 |
|
||||
| sys_total_memory | 系统总内存,单位:字节 |
|
||||
| sys_used_memory | 系统已用内存, 单位:字节 |
|
||||
| sys_available_memory | 系统可用内存, 单位:字节 |
|
||||
| sys_used_memory | 系统已用内存,单位:字节 |
|
||||
| sys_available_memory | 系统可用内存,单位:字节 |
|
||||
| process_uptime | taosX 运行时长,单位:秒 |
|
||||
| process_id | taosX 进程 ID |
|
||||
| running_tasks | taosX 当前执行任务数 |
|
||||
| completed_tasks | taosX 进程在一个监控周期(比如10s)内完成的任务数 |
|
||||
| failed_tasks | taosX 进程在一个监控周期(比如10s)内失败的任务数 |
|
||||
| process_cpu_percent | taosX 进程占用 CPU 百分比, 单位 % |
|
||||
| process_memory_percent | taosX 进程占用内存百分比, 单位 % |
|
||||
| process_disk_read_bytes | taosX 进程在一个监控周期(比如10s)内从硬盘读取的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_written_bytes | taosX 进程在一个监控周期(比如10s)内写到硬盘的字节数的平均值,单位 bytres/s |
|
||||
| completed_tasks | taosX 进程在一个监控周期(比如 10s)内完成的任务数 |
|
||||
| failed_tasks | taosX 进程在一个监控周期(比如 10s)内失败的任务数 |
|
||||
| process_cpu_percent | taosX 进程占用 CPU 百分比,单位 % |
|
||||
| process_memory_percent | taosX 进程占用内存百分比,单位 % |
|
||||
| process_disk_read_bytes | taosX 进程在一个监控周期(比如 10s)内从硬盘读取的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_written_bytes | taosX 进程在一个监控周期(比如 10s)内写到硬盘的字节数的平均值,单位 bytres/s |
|
||||
|
||||
|
||||
### Agent
|
||||
|
@ -420,15 +420,15 @@ taosX 会将监控指标上报给 taosKeeper,这些监控指标会被 taosKeep
|
|||
| -------------------------- | ----------------------------------------------------------------------------- |
|
||||
| sys_cpu_cores | 系统 CPU 核数 |
|
||||
| sys_total_memory | 系统总内存,单位:字节 |
|
||||
| sys_used_memory | 系统已用内存, 单位:字节 |
|
||||
| sys_available_memory | 系统可用内存, 单位:字节 |
|
||||
| sys_used_memory | 系统已用内存,单位:字节 |
|
||||
| sys_available_memory | 系统可用内存,单位:字节 |
|
||||
| process_uptime | agent 运行时长,单位:秒 |
|
||||
| process_id | agent 进程 id |
|
||||
| process_cpu_percent | agent 进程占用 CPU 百分比 |
|
||||
| process_memory_percent | agent 进程占用内存百分比 |
|
||||
| process_uptime | 进程启动时间,单位秒 |
|
||||
| process_disk_read_bytes | agent 进程在一个监控周期(比如10s)内从硬盘读取的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_written_bytes | agent 进程在一个监控周期(比如10s)内写到硬盘的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_read_bytes | agent 进程在一个监控周期(比如 10s)内从硬盘读取的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_written_bytes | agent 进程在一个监控周期(比如 10s)内写到硬盘的字节数的平均值,单位 bytes/s |
|
||||
|
||||
### Connector
|
||||
|
||||
|
@ -436,10 +436,10 @@ taosX 会将监控指标上报给 taosKeeper,这些监控指标会被 taosKeep
|
|||
| -------------------------- | --------------------------------------------------------------------------------- |
|
||||
| process_id | connector 进程 id |
|
||||
| process_uptime | 进程启动时间,单位秒 |
|
||||
| process_cpu_percent | 进程占用 CPU 百分比, 单位 % |
|
||||
| process_memory_percent | 进程占用内存百分比, 单位 % |
|
||||
| process_disk_read_bytes | connector 进程在一个监控周期(比如10s)内从硬盘读取的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_written_bytes | connector 进程在一个监控周期(比如10s)内写到硬盘的字节数的平均值,单位 bytes/s |
|
||||
| process_cpu_percent | 进程占用 CPU 百分比,单位 % |
|
||||
| process_memory_percent | 进程占用内存百分比,单位 % |
|
||||
| process_disk_read_bytes | connector 进程在一个监控周期(比如 10s)内从硬盘读取的字节数的平均值,单位 bytes/s |
|
||||
| process_disk_written_bytes | connector 进程在一个监控周期(比如 10s)内写到硬盘的字节数的平均值,单位 bytes/s |
|
||||
|
||||
### taosX 通用数据源任务
|
||||
|
||||
|
@ -457,7 +457,7 @@ taosX 会将监控指标上报给 taosKeeper,这些监控指标会被 taosKeep
|
|||
|
||||
| 字段 | 描述 |
|
||||
| --------------------- | -------------------------------------------------------------------- |
|
||||
| read_concurrency | 并发读取数据源的数据 worker 数, 也等于并发写入 TDengine 的 worker 数 |
|
||||
| read_concurrency | 并发读取数据源的数据 worker 数,也等于并发写入 TDengine 的 worker 数 |
|
||||
| total_stables | 需要迁移的超级表数据数量 |
|
||||
| total_updated_tags | 累计更新 tag 数 |
|
||||
| total_created_tables | 累计创建子表数 |
|
||||
|
@ -566,9 +566,9 @@ taosX Parser 插件是一个要求用 C/Rust 语言开发的 C ABI 兼容动态
|
|||
|
||||
**函数签名**:parser_resp_t parser_new(char* ctx, uint32_t len);
|
||||
|
||||
char* ctx: 用户自定义配置字符串。
|
||||
char* ctx:用户自定义配置字符串。
|
||||
|
||||
uint32_t len: 该字符串的二进制长度(不含 `\0`)。
|
||||
uint32_t len:该字符串的二进制长度(不含 `\0`)。
|
||||
|
||||
**返回值**:
|
||||
|
||||
|
@ -597,11 +597,11 @@ const char* parser_mutate(
|
|||
);
|
||||
```
|
||||
|
||||
`void* parser`: parser_new 生成的对象指针;
|
||||
`void* parser`:parser_new 生成的对象指针;
|
||||
|
||||
`const uint8_t* in_ptr`:输入 Payload 的指针;
|
||||
|
||||
`uint32_t in_len`: 输入 Payload 的 bytes 长度(不含 `\0`);
|
||||
`uint32_t in_len`:输入 Payload 的 bytes 长度(不含 `\0`);
|
||||
|
||||
`const void* uint8_t* out_ptr`:输出 JSON 字符串的指针(不含 \0)。当 out_ptr 指向为空时,表示输出为空。
|
||||
|
||||
|
@ -615,4 +615,4 @@ const char* parser_mutate(
|
|||
|
||||
**函数签名**: void parser_free(void* parser);
|
||||
|
||||
void* parser: parser_new 生成的对象指针。
|
||||
void* parser:parser_new 生成的对象指针。
|
||||
|
|
|
@ -3,23 +3,23 @@ title: taosX-Agent 参考手册
|
|||
sidebar_label: taosX-Agent
|
||||
---
|
||||
|
||||
本节讲述如何部署 `Agent` (for `taosX`)。使用之前需要安装 TDengine Enterprise 安装包之后,taosX-Agent 用于在部分数据接入场景,如 Pi, OPC UA, OPC DA 等对访问数据源有一定限制或者网络环境特殊的场景下,可以将 taosX-Agent 部署在靠近数据源的环境中甚至与数据源在相同的服务器上,由 taosX-Agent 负责从数据源读取数据并发送给 taosX。
|
||||
本节讲述如何部署 `Agent` (for `taosX`)。使用之前需要安装 TDengine Enterprise 安装包之后,taosX-Agent 用于在部分数据接入场景,如 Pi、OPC UA、OPC DA 等对访问数据源有一定限制或者网络环境特殊的场景下,可以将 taosX-Agent 部署在靠近数据源的环境中甚至与数据源在相同的服务器上,由 taosX-Agent 负责从数据源读取数据并发送给 taosX。
|
||||
|
||||
## 配置
|
||||
|
||||
`Agent` 默认的配置文件位于 `/etc/taos/agent.toml`, 包含以下配置项:
|
||||
`Agent` 默认的配置文件位于 `/etc/taos/agent.toml`,包含以下配置项:
|
||||
|
||||
- `endpoint`: 必填,`taosX` 的 GRPC 服务地址。
|
||||
- `token`: 必填,在 `Explorer` 上创建 `Agent` 时,产生的 Token。
|
||||
- `endpoint`:必填,`taosX` 的 GRPC 服务地址。
|
||||
- `token`:必填,在 `Explorer` 上创建 `Agent` 时,产生的 Token。
|
||||
- `instanceId`:当前 taosx-agent 服务的实例 ID,如果同一台机器上启动了多个 taosx-agent 实例,必须保证各个实例的实例 ID 互不相同。
|
||||
- `compression`: 非必填,可配置为 `true` 或 `false`, 默认为 `false`。配置为`true`, 则开启 `Agent` 和 `taosX` 通信数据压缩。
|
||||
- `in_memory_cache_capacity`: 非必填,表示可在内存中缓存的最大消息批次数,可配置为大于 0 的整数。默认为 `64`。
|
||||
- `compression`:非必填,可配置为 `true` 或 `false`,默认为 `false`。配置为`true`,则开启 `Agent` 和 `taosX` 通信数据压缩。
|
||||
- `in_memory_cache_capacity`:非必填,表示可在内存中缓存的最大消息批次数,可配置为大于 0 的整数。默认为 `64`。
|
||||
- `client_port_range.min`:非必填,取值范围 `[49152-65535]`,默认为 `49152`,当 agent 向 taosx 创建 socket 连接时,socket 客户端会随机监听一个端口,此配置限制了端口范围的最小值。
|
||||
- `client_port_range.max`:非必填,取值范围 `[49152-65535]`,默认为 `65535`,此配置限制了端口范围的最大值。
|
||||
- `log_level`: 非必填,日志级别,默认为 `info`, 同 `taosX` 一样,支持 `error`,`warn`,`info`,`debug`,`trace` 五级。已弃用,请使用 `log.level` 代替。
|
||||
- `log_level`:非必填,日志级别,默认为 `info`,同 `taosX` 一样,支持 `error`、`warn`、`info`、`debug`、`trace` 五级。已弃用,请使用 `log.level` 代替。
|
||||
- `log_keep_days`:非必填,日志保存天数,默认为 `30` 天。已弃用,请使用 `log.keepDays` 代替。
|
||||
- `log.path`:日志文件存放的目录。
|
||||
- `log.level`:日志级别,可选值为 "error", "warn", "info", "debug", "trace"。
|
||||
- `log.level`:日志级别,可选值为 "error"、"warn"、"info"、"debug"、"trace"。
|
||||
- `log.compress`:日志文件滚动后的文件是否进行压缩。
|
||||
- `log.rotationCount`:日志文件目录下最多保留的文件数,超出数量的旧文件被删除。
|
||||
- `log.rotationSize`:触发日志文件滚动的文件大小(单位为字节),当日志文件超出此大小后会生成一个新文件,新的日志会写入新文件。
|
||||
|
|
|
@ -13,7 +13,7 @@ taosKeeper 是 TDengine 3.0 版本监控指标的导出工具,通过简单的
|
|||
|
||||
taosKeeper 有两种安装方式:
|
||||
|
||||
- 安装 TDengine 官方安装包的同时会自动安装 taosKeeper, 详情请参考[TDengine 安装](../../../get-started/)。
|
||||
- 安装 TDengine 官方安装包的同时会自动安装 taosKeeper,详情请参考 [TDengine 安装](../../../get-started/)。
|
||||
|
||||
- 单独编译 taosKeeper 并安装,详情请参考 [taosKeeper](https://github.com/taosdata/taoskeeper) 仓库。
|
||||
|
||||
|
@ -64,7 +64,7 @@ Usage of taoskeeper v3.3.3.0:
|
|||
### 配置文件
|
||||
|
||||
taosKeeper 支持用 `taoskeeper -c <keeper config file>` 命令来指定配置文件。
|
||||
若不指定配置文件,taosKeeper 会使用默认配置文件,其路径为: `/etc/taos/taoskeeper.toml` 。
|
||||
若不指定配置文件,taosKeeper 会使用默认配置文件,其路径为:`/etc/taos/taoskeeper.toml` 。
|
||||
若既不指定 taosKeeper 配置文件,且 `/etc/taos/taoskeeper.toml` 也不存在,将使用默认配置。
|
||||
|
||||
**下面是配置文件的示例:**
|
||||
|
@ -198,7 +198,7 @@ Active: inactive (dead)
|
|||
|
||||
:::info
|
||||
|
||||
- `launchctl` 命令管理`com.tdengine.taoskeeper`需要管理员权限,务必在前面加 `sudo` 来增强安全性。
|
||||
- `launchctl` 命令管理 `com.tdengine.taoskeeper` 需要管理员权限,务必在前面加 `sudo` 来增强安全性。
|
||||
- `sudo launchctl list | grep taoskeeper` 指令返回的第一列是 `taoskeeper` 程序的 PID,若为 `-` 则说明 taoskeeper 服务未运行。
|
||||
- 故障排查:如果服务异常请查看日志获取更多信息。日志文件默认放在 `/var/log/taos` 下。
|
||||
|
||||
|
@ -314,7 +314,7 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
|
||||
##### 监控信息支持的标签
|
||||
|
||||
- `cluster_id`: 集群 id
|
||||
- `cluster_id`:集群 id
|
||||
|
||||
##### 相关指标及其含义
|
||||
|
||||
|
@ -346,15 +346,15 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
|
||||
##### 监控信息支持的标签
|
||||
|
||||
- `cluster_id`: 集群 id
|
||||
- `dnode_ep`: dnode 端点
|
||||
- `cluster_id`:集群 id
|
||||
- `dnode_ep`:dnode 端点
|
||||
- `dnode_id`:dnode id
|
||||
|
||||
##### 相关指标及其含义
|
||||
|
||||
| 指标名称 | 类型 | 含义 |
|
||||
| ------------------------------ | ------- | ---------------------------------------------------------------------------------------- |
|
||||
| taos_d_info_status | gauge | dnode 状态,标签 value 表示状态, ready 表示正常, offline 表示下线, unknown 表示未知。 |
|
||||
| taos_d_info_status | gauge | dnode 状态,标签 value 表示状态、ready 表示正常、offline 表示下线、unknown 表示未知。 |
|
||||
| taos_dnodes_info_cpu_cores | gauge | CPU 核心数 |
|
||||
| taos_dnodes_info_cpu_engine | gauge | 该 dnode 的进程所使用的 CPU 百分比(取值范围 0~100) |
|
||||
| taos_dnodes_info_cpu_system | gauge | 该 dnode 所在节点的系统使用的 CPU 百分比(取值范围 0~100) |
|
||||
|
@ -381,8 +381,8 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
|
||||
##### 监控信息支持的标签
|
||||
|
||||
- `cluster_id`: 集群 id
|
||||
- `dnode_ep`: dnode 端点
|
||||
- `cluster_id`:集群 id
|
||||
- `dnode_ep`:dnode 端点
|
||||
- `dnode_id`:dnode id
|
||||
- `data_dir_name`:数据目录名
|
||||
- `data_dir_level`:数据目录级别
|
||||
|
@ -399,8 +399,8 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
|
||||
##### 监控信息支持的标签
|
||||
|
||||
- `cluster_id`: 集群 id
|
||||
- `dnode_ep`: dnode 端点
|
||||
- `cluster_id`:集群 id
|
||||
- `dnode_ep`:dnode 端点
|
||||
- `dnode_id`:dnode id
|
||||
- `log_dir_name`:日志目录名
|
||||
|
||||
|
@ -416,8 +416,8 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
|
||||
##### 监控信息支持的标签
|
||||
|
||||
- `cluster_id`: 集群 id
|
||||
- `dnode_ep`: dnode 端点
|
||||
- `cluster_id`:集群 id
|
||||
- `dnode_ep`:dnode 端点
|
||||
- `dnode_id`:dnode id
|
||||
|
||||
##### 相关指标及其含义
|
||||
|
@ -460,7 +460,7 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
|
||||
##### 监控信息支持的标签
|
||||
|
||||
- `identify`: 节点 endpoint
|
||||
- `identify`:节点 endpoint
|
||||
|
||||
##### 相关指标及其含义
|
||||
|
||||
|
@ -474,64 +474,64 @@ taos_cluster_info_first_ep_dnode_id{cluster_id="554014120921134497"} 1
|
|||
##### taos_m_info_role
|
||||
|
||||
- **标签**:
|
||||
- `cluster_id`: 集群 id
|
||||
- `mnode_ep`: mnode 端点
|
||||
- `mnode_id`: mnode id
|
||||
- `value`: 角色值(该 mnode 的状态,取值范围:offline, follower, candidate, leader, error, learner)
|
||||
- **类型**: gauge
|
||||
- **含义**: mnode 角色
|
||||
- `cluster_id`:集群 id
|
||||
- `mnode_ep`:mnode 端点
|
||||
- `mnode_id`:mnode id
|
||||
- `value`:角色值(该 mnode 的状态,取值范围:offline、follower、candidate、leader、error、learner)
|
||||
- **类型**:gauge
|
||||
- **含义**:mnode 角色
|
||||
|
||||
##### taos_taos_sql_req_count
|
||||
|
||||
- **标签**:
|
||||
- `cluster_id`: 集群 id
|
||||
- `result`: 请求结果(取值范围: Success, Failed)
|
||||
- `sql_type`: SQL 类型(取值范围:select, insert,inserted_rows, delete)
|
||||
- `username`: 用户名
|
||||
- **类型**: gauge
|
||||
- **含义**: SQL 请求数量
|
||||
- `cluster_id`:集群 id
|
||||
- `result`:请求结果(取值范围:Success、Failed)
|
||||
- `sql_type`:SQL 类型(取值范围:select、insert、inserted_rows、delete)
|
||||
- `username`:用户名
|
||||
- **类型**:gauge
|
||||
- **含义**:SQL 请求数量
|
||||
|
||||
##### taos_taosd_sql_req_count
|
||||
|
||||
- **标签**:
|
||||
- `cluster_id`: 集群 id
|
||||
- `dnode_ep`: dnode 端点
|
||||
- `dnode_id`: dnode id
|
||||
- `result`: 请求结果(取值范围: Success, Failed)
|
||||
- `sql_type`: SQL 类型(取值范围:select, insert,inserted_rows, delete)
|
||||
- `username`: 用户名
|
||||
- `vgroup_id`: 虚拟组 id
|
||||
- **类型**: gauge
|
||||
- **含义**: SQL 请求数量
|
||||
- `cluster_id`:集群 id
|
||||
- `dnode_ep`:dnode 端点
|
||||
- `dnode_id`:dnode id
|
||||
- `result`:请求结果(取值范围:Success、Failed)
|
||||
- `sql_type`:SQL 类型(取值范围:select、insert、inserted_rows、delete)
|
||||
- `username`:用户名
|
||||
- `vgroup_id`:虚拟组 id
|
||||
- **类型**:gauge
|
||||
- **含义**:SQL 请求数量
|
||||
|
||||
##### taos_taosd_vgroups_info_status
|
||||
|
||||
- **标签**:
|
||||
- `cluster_id`: 集群 id
|
||||
- `database_name`: 数据库名称
|
||||
- `vgroup_id`: 虚拟组 id
|
||||
- **类型**: gauge
|
||||
- **含义**: 虚拟组状态。 0 为 unsynced,表示没有 leader 选出;1 为 ready。
|
||||
- `cluster_id`:集群 id
|
||||
- `database_name`:数据库名称
|
||||
- `vgroup_id`:虚拟组 id
|
||||
- **类型**:gauge
|
||||
- **含义**:虚拟组状态。 0 为 unsynced,表示没有 leader 选出;1 为 ready。
|
||||
|
||||
##### taos_taosd_vgroups_info_tables_num
|
||||
|
||||
- **标签**:
|
||||
- `cluster_id`: 集群 id
|
||||
- `database_name`: 数据库名称
|
||||
- `vgroup_id`: 虚拟组 id
|
||||
- **类型**: gauge
|
||||
- **含义**: 虚拟组表数量
|
||||
- `cluster_id`:集群 id
|
||||
- `database_name`:数据库名称
|
||||
- `vgroup_id`:虚拟组 id
|
||||
- **类型**:gauge
|
||||
- **含义**:虚拟组表数量
|
||||
|
||||
##### taos_taosd_vnodes_info_role
|
||||
|
||||
- **标签**:
|
||||
- `cluster_id`: 集群 id
|
||||
- `database_name`: 数据库名称
|
||||
- `dnode_id`: dnode id
|
||||
- `value`: 角色值(取值范围:offline, follower, candidate, leader, error, learner)
|
||||
- `vgroup_id`: 虚拟组 id
|
||||
- **类型**: gauge
|
||||
- **含义**: 虚拟节点角色
|
||||
- `cluster_id`:集群 id
|
||||
- `database_name`:数据库名称
|
||||
- `dnode_id`:dnode id
|
||||
- `value`:角色值(取值范围:offline、follower、candidate、leader、error、learner)
|
||||
- `vgroup_id`:虚拟组 id
|
||||
- **类型**:gauge
|
||||
- **含义**:虚拟节点角色
|
||||
|
||||
### 抽取配置
|
||||
|
||||
|
|
|
@ -128,7 +128,7 @@ cors = true
|
|||
- `addr`:taosExplorer 服务绑定的 IPv4 地址,默认为 `0.0.0.0`。如需修改,请配置为 `localhost` 之外的地址以对外提供服务。
|
||||
- `ipv6`:taosExplorer 服务绑定的 IPv6 地址,默认不绑定 IPv6 地址。
|
||||
- `instanceId`:当前 explorer 服务的实例 ID,如果同一台机器上启动了多个 explorer 实例,必须保证各个实例的实例 ID 互不相同。
|
||||
- `log_level`:日志级别,可选值为 "error", "warn", "info", "debug", "trace"。此参数已弃用,请使用 `log.level` 代替。
|
||||
- `log_level`:日志级别,可选值为 "error"、"warn"、"info"、"debug"、"trace"。此参数已弃用,请使用 `log.level` 代替。
|
||||
- `cluster`:TDengine 集群的 taosAdapter 地址。
|
||||
- `cluster_native`:TDengine 集群的原生连接地址,默认关闭。
|
||||
- `x_api`:taosX 的 gRPC 地址。
|
||||
|
@ -137,7 +137,7 @@ cors = true
|
|||
- `ssl.certificate`:SSL 证书(如果同时设置了 certificate 与 certificate_key 两个参数,则启用 HTTPS 服务,否则不启用)。
|
||||
- `ssl.certificate_key`:SSL 证书密钥。
|
||||
- `log.path`:日志文件存放的目录。
|
||||
- `log.level`:日志级别,可选值为 "error", "warn", "info", "debug", "trace"。
|
||||
- `log.level`:日志级别,可选值为 "error"、"warn"、"info"、"debug"、"trace"。
|
||||
- `log.compress`:日志文件滚动后的文件是否进行压缩。
|
||||
- `log.rotationCount`:日志文件目录下最多保留的文件数,超出数量的旧文件被删除。
|
||||
- `log.rotationSize`:触发日志文件滚动的文件大小(单位为字节),当日志文件超出此大小后会生成一个新文件,新的日志会写入新文件。
|
||||
|
@ -220,10 +220,10 @@ sc.exe stop taos-explorer # Windows
|
|||
|
||||
## 注册登录
|
||||
|
||||
安装好,打开浏览器,默认访问`http://ip:6060`来访问 taos-explorer 服务。如果还没有注册过,则首先进入注册界面。输入手机号获取验证码,输入正确的验证码后,即可注册成功。
|
||||
安装好,打开浏览器,默认访问 `http://ip:6060` 来访问 taos-explorer 服务。如果还没有注册过,则首先进入注册界面。输入手机号获取验证码,输入正确的验证码后,即可注册成功。
|
||||
|
||||
登录时,请使用数据库用户名和密码登录。首次使用,默认的用户名为 `root`,密码为 `taosdata`。登录成功后即可进入`数据浏览器`页面,您可以使用查看数据库、 创建数据库、创建超级表/子表等管理功能。
|
||||
|
||||
其他功能页面,如`数据写入-数据源`等页面,为企业版特有功能,您可以点击查看和简单体验,并不能实际使用。
|
||||
其他功能页面,如 `数据写入-数据源` 等页面,为企业版特有功能,您可以点击查看和简单体验,并不能实际使用。
|
||||
|
||||
如果由于网络原因无法完成注册环节,则需要在有外网的环境注册完毕,然后把注册好的 /etc/taos/explorer-register.cfg 替换到内网环境。
|
||||
如果由于网络原因无法完成注册环节,则需要在有外网的环境注册完毕,然后把注册好的 `/etc/taos/explorer-register.cfg` 替换到内网环境。
|
||||
|
|
|
@ -37,23 +37,23 @@ taos> quit
|
|||
### 基础参数
|
||||
可通过配置命令行参数来改变 TDengine CLI 的行为。以下为常用的几个命令行参数:
|
||||
|
||||
- -h HOST: 要连接的 TDengine 服务端所在服务器的 FQDN, 默认值: 127.0.0.1 。
|
||||
- -P PORT: 指定服务端所用端口号,默认值:6030 。
|
||||
- -u USER: 连接时使用的用户名,默认值:root 。
|
||||
- -p PASSWORD: 连接服务端时使用的密码,特殊字符如 `! & ( ) < > ; |` 需使用字符 `\` 进行转义处理, 默认值:taosdata 。
|
||||
- -?, --help: 打印出所有命令行参数。
|
||||
- -s COMMAND: 以非交互模式执行的 SQL 命令。
|
||||
- -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:
|
||||
如以下命令连接到服务器 h1.taos.com, 执行 -s 指定的 SQL:
|
||||
```bash
|
||||
taos -h my-server -s "use db; show tables;"
|
||||
```
|
||||
|
||||
- -c CONFIGDIR: 指定配置文件目录。
|
||||
- -c CONFIGDIR:指定配置文件目录。
|
||||
|
||||
Linux 环境下默认为 `/etc/taos`,该目录下的配置文件默认名称为 `taos.cfg` 。
|
||||
使用 `-c` 参数改变 `taosc` 客户端加载配置文件的位置,客户端配置参数参考 [客户端配置](../../components/taosc) 。
|
||||
Linux 环境下默认为 `/etc/taos`,该目录下的配置文件默认名称为 `taos.cfg`。
|
||||
使用 `-c` 参数改变 `taosc` 客户端加载配置文件的位置,客户端配置参数参考 [客户端配置](../../components/taosc)。
|
||||
以下命令指定了 `taosc` 客户端加载 `/root/cfg/` 下的 `taos.cfg` 配置文件。
|
||||
```bash
|
||||
taos -c /root/cfg/
|
||||
|
@ -61,30 +61,30 @@ taos> quit
|
|||
|
||||
### 高级参数
|
||||
|
||||
- -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: 打印出当前版本号。
|
||||
- -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:打印出当前版本号。
|
||||
|
||||
|
||||
## 数据导出/导入
|
||||
|
||||
### 数据导出
|
||||
|
||||
- 可以使用符号 “>>” 导出查询结果到某个文件中,语法为: sql 查询语句 >> ‘输出文件名’; 输出文件如果不写路径的话,将输出至当前目录下。如 `select * from d0 >> ‘/root/d0.csv’;` 将把查询结果输出到 /root/d0.csv 中。
|
||||
- 可以使用符号 “>>” 导出查询结果到某个文件中,语法为:sql 查询语句 >> ‘输出文件名’; 输出文件如果不写路径的话,将输出至当前目录下。如 `select * from d0 >> ‘/root/d0.csv’;` 将把查询结果输出到 /root/d0.csv 中。
|
||||
|
||||
### 数据导入
|
||||
|
||||
|
@ -105,7 +105,7 @@ taos> source <filename>;
|
|||
- TAB 键前为空命令状态下按 TAB 键,会列出 TDengine CLI 支持的所有命令。
|
||||
- TAB 键前为空格状态下按 TAB 键,会显示此位置可以出现的所有命令词的第一个,再次按 TAB 键切为下一个。
|
||||
- TAB 键前为字符串,会搜索与此字符串前缀匹配的所有可出现命令词,并显示第一个,再次按 TAB 键切为下一个。
|
||||
- 输入反斜杠 `\` + TAB 键, 会自动补全为列显示模式命令词 `\G;` 。
|
||||
- 输入反斜杠 `\` + TAB 键, 会自动补全为列显示模式命令词 `\G;`。
|
||||
|
||||
### 设置字符列显示宽度
|
||||
|
||||
|
@ -120,10 +120,10 @@ taos> SET MAX_BINARY_DISPLAY_WIDTH 120;
|
|||
### 其它
|
||||
|
||||
- 可以使用上下光标键查看历史输入的指令。
|
||||
- 在 TDengine CLI 中使用 `alter user` 命令可以修改用户密码,缺省密码为 `taosdata` 。
|
||||
- 在 TDengine CLI 中使用 `alter user` 命令可以修改用户密码,缺省密码为 `taosdata`。
|
||||
- Ctrl+C 中止正在进行中的查询。
|
||||
- 执行 `RESET QUERY CACHE` 可清除本地表 Schema 的缓存。
|
||||
- 批量执行 SQL 语句。可以将一系列的 TDengine CLI 命令(以英文 ; 结尾,每个 SQL 语句为一行)按行存放在文件里,在 TDengine CLI 里执行命令 `source <file-name>` 自动执行该文件里所有的 SQL 语句。
|
||||
- 批量执行 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/)
|
||||
|
|
|
@ -4,7 +4,7 @@ sidebar_label: taosdump
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
taosdump 是为开源用户提供的 TDengine 数据备份/恢复工具,备份数据文件采用标准 [ Apache AVRO ](https://avro.apache.org/) 格式,方便与外界生态交换数据。taosdump 提供多种数据备份及恢复选项来满足不同需求,可通过 --help 查看支持的全部选项。
|
||||
taosdump 是为开源用户提供的 TDengine 数据备份/恢复工具,备份数据文件采用标准 [Apache AVRO](https://avro.apache.org/) 格式,方便与外界生态交换数据。taosdump 提供多种数据备份及恢复选项来满足不同需求,可通过 --help 查看支持的全部选项。
|
||||
|
||||
## 工具获取
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ taosBenchmark 是 TDengine 服务器及客户端安装包中默认安装组件
|
|||
|
||||
## 运行
|
||||
|
||||
taosBenchmark 支持无参数、命令行、配置文件三种运行模式,`命令行` 为 `配置文件` 功能子集,两者同时使用时,以命令行方式优先。
|
||||
taosBenchmark 支持无参数、命令行、配置文件三种运行模式,`命令行` 为 `配置文件` 功能子集,两者同时使用时,以命令行方式优先。
|
||||
|
||||
:::tip
|
||||
在运行 taosBenchmark 之前要确保 TDengine 集群已经在正确运行。
|
||||
|
@ -24,18 +24,18 @@ taosBenchmark 支持无参数、命令行、配置文件三种运行模式,`
|
|||
taosBenchmark
|
||||
```
|
||||
|
||||
在无参数运行时,taosBenchmark 默认连接 `/etc/taos/taos.cfg` 中指定的 TDengine 集群。
|
||||
连接成功后,会默认创建智能电表示例数据库 test,创建超级表 meters, 创建子表 1 万,每子写入数据 1 万条,若 test 库已存在,默认会先删再建。
|
||||
在无参数运行时,taosBenchmark 默认连接 `/etc/taos/taos.cfg` 中指定的 TDengine 集群。
|
||||
连接成功后,会默认创建智能电表示例数据库 test,创建超级表 meters,创建子表 1 万,每子写入数据 1 万条,若 test 库已存在,默认会先删再建。
|
||||
|
||||
### 命令行模式
|
||||
|
||||
命令行支持的参数为写入功能中使用较为频繁的参数,查询与订阅功能不支持命令行方式。
|
||||
命令行支持的参数为写入功能中使用较为频繁的参数,查询与订阅功能不支持命令行方式。
|
||||
示例:
|
||||
```bash
|
||||
taosBenchmark -d db -t 100 -n 1000 -T 4 -I stmt -y
|
||||
```
|
||||
|
||||
此命令表示使用 `taosBenchmark` 将创建一个名为 `db` 的数据库,并建立默认超级表 `meters`,子表 100 ,使用参数绑定(stmt)方式为每张子表写入 1000 条记录。
|
||||
此命令表示使用 `taosBenchmark` 将创建一个名为 `db` 的数据库,并建立默认超级表 `meters`,子表 100,使用参数绑定(stmt)方式为每张子表写入 1000 条记录。
|
||||
|
||||
### 配置文件模式
|
||||
|
||||
|
@ -52,28 +52,28 @@ taosBenchmark -f <json file>
|
|||
| -c/--config-dir \<dir> | TDengine 集群配置文件所在的目录,默认路径是 /etc/taos |
|
||||
| -h/--host \<host> | 指定要连接的 TDengine 服务端的 FQDN,默认值为 localhost |
|
||||
| -P/--port \<port> | 要连接的 TDengine 服务器的端口号,默认值为 6030 |
|
||||
| -I/--interface \<insertMode> | 插入模式,可选项有 taosc, rest, stmt, sml, sml-rest, 分别对应普通写入、restful 接口写入、参数绑定接口写入、schemaless 接口写入、restful schemaless 接口写入 (由 taosAdapter 提供)。默认值为 taosc |
|
||||
| -I/--interface \<insertMode> | 插入模式,可选项有 taosc、rest、stmt、sml、sml-rest,分别对应普通写入、restful 接口写入、参数绑定接口写入、schemaless 接口写入、restful schemaless 接口写入 (由 taosAdapter 提供)。默认值为 taosc |
|
||||
| -u/--user \<user> | 用于连接 TDengine 服务端的用户名,默认为 root |
|
||||
| -U/--supplement-insert | 写入数据而不提前建数据库和表,默认关闭 |
|
||||
| -p/--password \<passwd> | 用于连接 TDengine 服务端的密码,默认值为 taosdata |
|
||||
| -o/--output \<file> | 结果输出文件的路径,默认值为 ./output.txt |
|
||||
| -T/--thread \<threadNum> | 插入数据的线程数量,默认为 8 |
|
||||
| -B/--interlace-rows \<rowNum> |启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程,直到所有子表的数据都插入完成。默认值为 0, 即向一张子表完成数据插入后才会向下一张子表进行数据插入 |
|
||||
| -i/--insert-interval \<timeInterval> | 指定交错插入模式的插入间隔,单位为 ms,默认值为 0。 只有当 `-B/--interlace-rows` 大于 0 时才起作用 |意味着数据插入线程在为每个子表插入隔行扫描记录后,会等待该值指定的时间间隔后再进行下一轮写入 |
|
||||
| -B/--interlace-rows \<rowNum> |启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程,直到所有子表的数据都插入完成。默认值为 0,即向一张子表完成数据插入后才会向下一张子表进行数据插入 |
|
||||
| -i/--insert-interval \<timeInterval> | 指定交错插入模式的插入间隔,单位为 ms,默认值为 0。只有当 `-B/--interlace-rows` 大于 0 时才起作用 |意味着数据插入线程在为每个子表插入隔行扫描记录后,会等待该值指定的时间间隔后再进行下一轮写入 |
|
||||
| -r/--rec-per-req \<rowNum> | 每次向 TDengine 请求写入的数据行数,默认值为 30000 |
|
||||
| -t/--tables \<tableNum> | 指定子表的数量,默认为 10000 |
|
||||
| -S/--timestampstep \<stepLength> | 每个子表中插入数据的时间戳步长,单位是 ms,默认值是 1 |
|
||||
| -n/--records \<recordNum> | 每个子表插入的记录数,默认值为 10000 |
|
||||
| -d/--database \<dbName> | 所使用的数据库的名称,默认值为 test |
|
||||
| -b/--data-type \<colType> | 指定超级表普通列数据类型, 多个使用逗号分隔,默认值: "FLOAT,INT,FLOAT" 如:`taosBenchmark -b "FLOAT,BINARY(8),NCHAR(16)"`|
|
||||
| -A/--tag-type \<tagType> | 指定超级表标签列数据类型,多个使用逗号分隔,默认值: "INT,BINARY(24)" 如:`taosBenchmark -A "INT,BINARY(8),NCHAR(8)"`|
|
||||
| -l/--columns \<colNum> | 超级表的数据列的总数量。如果同时设置了该参数和 `-b/--data-type`,则最后的结果列数为两者取大。如果本参数指定的数量大于 `-b/--data-type` 指定的列数,则未指定的列类型默认为 INT, 例如: `-l 5 -b float,double`, 那么最后的列为 `FLOAT,DOUBLE,INT,INT,INT`。如果 columns 指定的数量小于或等于 `-b/--data-type` 指定的列数,则结果为 `-b/--data-type` 指定的列和类型,例如: `-l 3 -b float,double,float,bigint`,那么最后的列为 `FLOAT,DOUBLE,FLOAT,BIGINT` |
|
||||
| -b/--data-type \<colType> | 指定超级表普通列数据类型,多个使用逗号分隔,默认值:"FLOAT,INT,FLOAT" 如:`taosBenchmark -b "FLOAT,BINARY(8),NCHAR(16)"`|
|
||||
| -A/--tag-type \<tagType> | 指定超级表标签列数据类型,多个使用逗号分隔,默认值:"INT,BINARY(24)" 如:`taosBenchmark -A "INT,BINARY(8),NCHAR(8)"`|
|
||||
| -l/--columns \<colNum> | 超级表的数据列的总数量。如果同时设置了该参数和 `-b/--data-type`,则最后的结果列数为两者取大。如果本参数指定的数量大于 `-b/--data-type` 指定的列数,则未指定的列类型默认为 INT,例如 `-l 5 -b float,double`,那么最后的列为 `FLOAT,DOUBLE,INT,INT,INT`。如果 columns 指定的数量小于或等于 `-b/--data-type` 指定的列数,则结果为 `-b/--data-type` 指定的列和类型,例如:`-l 3 -b float,double,float,bigint`,那么最后的列为 `FLOAT,DOUBLE,FLOAT,BIGINT` |
|
||||
| -L/--partial-col-num \<colNum> | 指定某些列写入数据,其他列数据为 NULL。默认所有列都写入数据 |
|
||||
| -w/--binwidth \<length> | nchar 和 binary 类型的默认长度,默认值为 64 |
|
||||
| -m/--table-prefix \<tablePrefix> | 子表名称的前缀,默认值为 "d" |
|
||||
| -E/--escape-character | 开关参数,指定在超级表和子表名称中是否使用转义字符。默认值为不使用 |
|
||||
| -C/--chinese | 开关参数,指定 nchar 和 binary 是否使用 Unicode 中文字符。默认值为不使用 |
|
||||
| -N/--normal-table | 开关参数,指定只创建普通表,不创建超级表。默认值为 false。仅当插入模式为 taosc, stmt, rest 模式下可以使用 |
|
||||
| -N/--normal-table | 开关参数,指定只创建普通表,不创建超级表。默认值为 false。仅当插入模式为 taosc、stmt、rest 模式下可以使用 |
|
||||
| -M/--random | 开关参数,插入数据为生成的随机值。默认值为 false。若配置此参数,则随机生成要插入的数据。对于数值类型的 标签列/数据列,其值为该类型取值范围内的随机值。对于 NCHAR 和 BINARY 类型的 标签列/数据列,其值为指定长度范围内的随机字符串 |
|
||||
| -x/--aggr-func | 开关参数,指示插入后查询聚合函数。默认值为 false |
|
||||
| -y/--answer-yes | 开关参数,要求用户在提示后确认才能继续 |默认值为 false 。
|
||||
|
@ -93,162 +93,162 @@ taosBenchmark -f <json file>
|
|||
|
||||
本节所列参数适用于所有功能模式。
|
||||
|
||||
- **filetype** : 功能分类,可选值为 `insert`, `query` 和 `subscribe`。分别对应插入、查询和订阅功能。每个配置文件中只能指定其中之一。
|
||||
- **cfgdir** : TDengine 客户端配置文件所在的目录,默认路径是 /etc/taos 。
|
||||
- **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。
|
||||
- **password**:用于连接 TDengine 服务端的密码,默认值为 taosdata。
|
||||
|
||||
### 写入配置参数
|
||||
|
||||
写入场景下 `filetype` 必须设置为 `insert`,该参数及其它通用参数详见 [通用配置参数](#通用配置参数)
|
||||
|
||||
- **keep_trying** : 失败后进行重试的次数,默认不重试。需使用 v3.0.9 以上版本。
|
||||
- **keep_trying**:失败后进行重试的次数,默认不重试。需使用 v3.0.9 以上版本。
|
||||
|
||||
- **trying_interval** : 失败重试间隔时间,单位为毫秒,仅在 keep_trying 指定重试后有效。需使用 v3.0.9 以上版本。
|
||||
- **childtable_from 和 childtable_to** : 指定写入子表范围,开闭区间为 [childtable_from, childtable_to) 。
|
||||
- **trying_interval**:失败重试间隔时间,单位为毫秒,仅在 keep_trying 指定重试后有效。需使用 v3.0.9 以上版本。
|
||||
- **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 会建立子表并继续写入。
|
||||
|
||||
#### 数据库相关
|
||||
|
||||
创建数据库时的相关参数在 json 配置文件中的 `dbinfo` 中配置,个别具体参数如下。其余参数均与 TDengine 中 `create database` 时所指定的数据库参数相对应,详见[../../taos-sql/database]
|
||||
|
||||
- **name** : 数据库名。
|
||||
- **name**:数据库名。
|
||||
|
||||
- **drop** : 数据库已存在时是否删除,可选项为 "yes" 或 "no", 默认为 "yes" 。
|
||||
- **drop**:数据库已存在时是否删除,可选项为 "yes" 或 "no",默认为 “yes” 。
|
||||
|
||||
#### 超级表相关
|
||||
|
||||
创建超级表时的相关参数在 json 配置文件中的 `super_tables` 中配置,具体参数如下。
|
||||
|
||||
- **name**: 超级表名,必须配置,没有默认值。
|
||||
- **name**:超级表名,必须配置,没有默认值。
|
||||
|
||||
- **child_table_exists** : 子表是否已经存在,默认值为 "no",可选值为 "yes" 或 "no" 。
|
||||
- **child_table_exists**:子表是否已经存在,默认值为 "no",可选值为 "yes" 或 "no" 。
|
||||
|
||||
- **childtable_count** : 子表的数量,默认值为 10。
|
||||
- **childtable_count**:子表的数量,默认值为 10。
|
||||
|
||||
- **childtable_prefix** : 子表名称的前缀,必选配置项,没有默认值。
|
||||
- **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" 则表示先提前建好所有表再进行插入。
|
||||
- **auto_create_table**:仅当 insert_mode 为 taosc、rest、stmt 并且 child_table_exists 为 "no" 时生效,该参数为 "yes" 表示 taosBenchmark 在插入数据时会自动创建不存在的表;为 "no" 则表示先提前建好所有表再进行插入。
|
||||
|
||||
- **batch_create_tbl_num** : 创建子表时每批次的建表数量,默认为 10。注:实际的批数不一定与该值相同,当执行的 SQL 语句大于支持的最大长度时,会自动截断再执行,继续创建。
|
||||
- **batch_create_tbl_num**:创建子表时每批次的建表数量,默认为 10。注:实际的批数不一定与该值相同,当执行的 SQL 语句大于支持的最大长度时,会自动截断再执行,继续创建。
|
||||
|
||||
- **data_source** : 数据的来源,默认为 taosBenchmark 随机产生,可以配置为 "rand" 和 "sample"。为 "sample" 时使用 sample_file 参数指定的文件内的数据。
|
||||
- **data_source**:数据的来源,默认为 taosBenchmark 随机产生,可以配置为 "rand" 和 "sample"。为 "sample" 时使用 sample_file 参数指定的文件内的数据。
|
||||
|
||||
- **insert_mode** : 插入模式,可选项有 taosc, rest, stmt, sml, sml-rest, 分别对应普通写入、restful 接口写入、参数绑定接口写入、schemaless 接口写入、restful schemaless 接口写入 (由 taosAdapter 提供)。默认值为 taosc 。
|
||||
- **insert_mode**:插入模式,可选项有 taosc、rest、stmt、sml、sml-rest,分别对应普通写入、restful 接口写入、参数绑定接口写入、schemaless 接口写入、restful schemaless 接口写入 (由 taosAdapter 提供)。默认值为 taosc 。
|
||||
|
||||
- **non_stop_mode** : 指定是否持续写入,若为 "yes" 则 insert_rows 失效,直到 Ctrl + C 停止程序,写入才会停止。默认值为 "no",即写入指定数量的记录后停止。注:即使在持续写入模式下 insert_rows 失效,但其也必须被配置为一个非零正整数。
|
||||
- **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 协议。
|
||||
- **tcp_transfer**:telnet 模式下的通信协议,仅当 insert_mode 为 sml-rest 并且 line_protocol 为 telnet 时生效。如果不配置,则默认为 http 协议。
|
||||
|
||||
- **insert_rows** : 每个子表插入的记录数,默认为 0 。
|
||||
- **insert_rows**:每个子表插入的记录数,默认为 0 。
|
||||
|
||||
- **childtable_offset** : 仅当 child_table_exists 为 yes 时生效,指定从超级表获取子表列表时的偏移量,即从第几个子表开始。
|
||||
- **childtable_offset**:仅当 child_table_exists 为 yes 时生效,指定从超级表获取子表列表时的偏移量,即从第几个子表开始。
|
||||
|
||||
- **childtable_limit** : 仅当 child_table_exists 为 yes 时生效,指定从超级表获取子表列表的上限。
|
||||
- **childtable_limit**:仅当 child_table_exists 为 yes 时生效,指定从超级表获取子表列表的上限。
|
||||
|
||||
- **interlace_rows** : 启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程,直到所有子表的数据都插入完成。默认值为 0, 即向一张子表完成数据插入后才会向下一张子表进行数据插入。
|
||||
- **interlace_rows**:启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程,直到所有子表的数据都插入完成。默认值为 0,即向一张子表完成数据插入后才会向下一张子表进行数据插入。
|
||||
|
||||
- **insert_interval** : 指定交错插入模式的插入间隔,单位为 ms,默认值为 0。 只有当 `-B/--interlace-rows` 大于 0 时才起作用。意味着数据插入线程在为每个子表插入隔行扫描记录后,会等待该值指定的时间间隔后再进行下一轮写入。
|
||||
- **insert_interval**:指定交错插入模式的插入间隔,单位为 ms,默认值为 0。只有当 `-B/--interlace-rows` 大于 0 时才起作用。意味着数据插入线程在为每个子表插入隔行扫描记录后,会等待该值指定的时间间隔后再进行下一轮写入。
|
||||
|
||||
- **partial_col_num** : 若该值为正数 n 时, 则仅向前 n 列写入,仅当 insert_mode 为 taosc 和 rest 时生效,如果 n 为 0 则是向全部列写入。
|
||||
- **partial_col_num**:若该值为正数 n 时,则仅向前 n 列写入,仅当 insert_mode 为 taosc 和 rest 时生效,如果 n 为 0 则是向全部列写入。
|
||||
|
||||
- **disorder_ratio** : 指定乱序数据的百分比概率,其值域为 [0,50]。默认为 0,即没有乱序数据。
|
||||
- **disorder_ratio**:指定乱序数据的百分比概率,其值域为 [0,50]。默认为 0,即没有乱序数据。
|
||||
|
||||
- **disorder_range** : 指定乱序数据的时间戳回退范围。所生成的乱序时间戳为非乱序情况下应该使用的时间戳减去这个范围内的一个随机值。仅在 `-O/--disorder` 指定的乱序数据百分比大于 0 时有效。
|
||||
- **disorder_range**:指定乱序数据的时间戳回退范围。所生成的乱序时间戳为非乱序情况下应该使用的时间戳减去这个范围内的一个随机值。仅在 `-O/--disorder` 指定的乱序数据百分比大于 0 时有效。
|
||||
|
||||
- **timestamp_step** : 每个子表中插入数据的时间戳步长,单位与数据库的 `precision` 一致,默认值是 1 。
|
||||
- **timestamp_step**:每个子表中插入数据的时间戳步长,单位与数据库的 `precision` 一致,默认值是 1 。
|
||||
|
||||
- **start_timestamp** : 每个子表的时间戳起始值,默认值是 now 。
|
||||
- **start_timestamp**:每个子表的时间戳起始值,默认值是 now 。
|
||||
|
||||
- **sample_format** : 样本数据文件的类型,现在只支持 "csv" 。
|
||||
- **sample_format**:样本数据文件的类型,现在只支持 "csv" 。
|
||||
|
||||
- **sample_file** : 指定 csv 格式的文件作为数据源,仅当 data_source 为 sample 时生效。若 csv 文件内的数据行数小于等于 prepared_rand,那么会循环读取 csv 文件数据直到与 prepared_rand 相同;否则则会只读取 prepared_rand 个数的行的数据。也即最终生成的数据行数为二者取小。
|
||||
- **sample_file**:指定 csv 格式的文件作为数据源,仅当 data_source 为 sample 时生效。若 csv 文件内的数据行数小于等于 prepared_rand,那么会循环读取 csv 文件数据直到与 prepared_rand 相同;否则则会只读取 prepared_rand 个数的行的数据。也即最终生成的数据行数为二者取小。
|
||||
|
||||
- **use_sample_ts** : 仅当 data_source 为 sample 时生效,表示 sample_file 指定的 csv 文件内是否包含第一列时间戳,默认为 no。 若设置为 yes, 则使用 csv 文件第一列作为时间戳,由于同一子表时间戳不能重复,生成的数据量取决于 csv 文件内的数据行数相同,此时 insert_rows 失效。
|
||||
- **use_sample_ts**:仅当 data_source 为 sample 时生效,表示 sample_file 指定的 csv 文件内是否包含第一列时间戳,默认为 no。若设置为 yes,则使用 csv 文件第一列作为时间戳,由于同一子表时间戳不能重复,生成的数据量取决于 csv 文件内的数据行数相同,此时 insert_rows 失效。
|
||||
|
||||
- **tags_file** : 仅当 insert_mode 为 taosc, rest 的模式下生效。 最终的 tag 的数值与 childtable_count 有关,如果 csv 文件内的 tag 数据行小于给定的子表数量,那么会循环读取 csv 文件数据直到生成 childtable_count 指定的子表数量;否则则只会读取 childtable_count 行 tag 数据。也即最终生成的子表数量为二者取小。
|
||||
- **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 中指定表名前面要带数据库名,否则会报未指定数据库错误。
|
||||
|
||||
|
||||
#### 标签列与数据列
|
||||
|
||||
指定超级表标签列与数据列的配置参数分别在 `super_tables` 中的 `columns` 和 `tag` 中。
|
||||
|
||||
- **type** : 指定列类型,可选值请参考 TDengine 支持的数据类型。
|
||||
- **type**:指定列类型,可选值请参考 TDengine 支持的数据类型。
|
||||
注:JSON 数据类型比较特殊,只能用于标签,当使用 JSON 类型作为 tag 时有且只能有这一个标签,此时 count 和 len 代表的意义分别是 JSON tag 内的 key-value pair 的个数和每个 KV pair 的 value 的值的长度,value 默认为 string。
|
||||
|
||||
- **len** : 指定该数据类型的长度,对 NCHAR,BINARY 和 JSON 数据类型有效。如果对其他数据类型配置了该参数,若为 0 , 则代表该列始终都是以 null 值写入;如果不为 0 则被忽略。
|
||||
- **len**:指定该数据类型的长度,对 NCHAR,BINARY 和 JSON 数据类型有效。如果对其他数据类型配置了该参数,若为 0,则代表该列始终都是以 null 值写入;如果不为 0 则被忽略。
|
||||
|
||||
- **count** : 指定该类型列连续出现的数量,例如 "count": 4096 即可生成 4096 个指定类型的列。
|
||||
- **count**:指定该类型列连续出现的数量,例如 "count":4096 即可生成 4096 个指定类型的列。
|
||||
|
||||
- **name** : 列的名字,若与 count 同时使用,比如 "name":"current", "count":3, 则 3 个列的名字分别为 current, current_2. current_3。
|
||||
- **name**:列的名字,若与 count 同时使用,比如 "name":"current","count":3,则 3 个列的名字分别为 current、current_2、current_3。
|
||||
|
||||
- **min** : 数据类型的 列/标签 的最小值。生成的值将大于或等于最小值。
|
||||
- **min**:数据类型的 列/标签 的最小值。生成的值将大于或等于最小值。
|
||||
|
||||
- **max** : 数据类型的 列/标签 的最大值。生成的值将小于最大值。
|
||||
- **max**:数据类型的 列/标签 的最大值。生成的值将小于最大值。
|
||||
|
||||
- **scalingFactor** : 浮点数精度增强因子,仅当数据类型是 float/double 时生效,有效值范围为 1 至 1000000 的正整数。用于增强生成浮点数的精度,特别是在 min 或 max 值较小的情况下。此属性按 10 的幂次增强小数点后的精度:scalingFactor 为 10 表示增强 1 位小数精度,100 表示增强 2 位,依此类推。
|
||||
- **scalingFactor**:浮点数精度增强因子,仅当数据类型是 float/double 时生效,有效值范围为 1 至 1000000 的正整数。用于增强生成浮点数的精度,特别是在 min 或 max 值较小的情况下。此属性按 10 的幂次增强小数点后的精度:scalingFactor 为 10 表示增强 1 位小数精度,100 表示增强 2 位,依此类推。
|
||||
|
||||
- **fun** : 此列数据以函数填充,目前只支持 sin 和 cos 两函数,输入参数为时间戳换算成角度值,换算公式: 角度 x = 输入的时间列ts值 % 360。同时支持系数调节,随机波动因子调节,以固定格式的表达式展现,如 fun="10\*sin(x)+100\*random(5)" , x 表示角度,取值 0 ~ 360度,增长步长与时间列步长一致。10 表示乘的系数,100 表示加或减的系数,5 表示波动幅度在 5% 的随机范围内。目前支持的数据类型为 int, bigint, float, double 四种数据类型。注意:表达式为固定模式,不可前后颠倒。
|
||||
- **fun**:此列数据以函数填充,目前只支持 sin 和 cos 两函数,输入参数为时间戳换算成角度值,换算公式:角度 x = 输入的时间列ts值 % 360。同时支持系数调节,随机波动因子调节,以固定格式的表达式展现,如 fun=“10\*sin(x)+100\*random(5)” , x 表示角度,取值 0 ~ 360度,增长步长与时间列步长一致。10 表示乘的系数,100 表示加或减的系数,5 表示波动幅度在 5% 的随机范围内。目前支持的数据类型为 int、bigint、float、double 四种数据类型。注意:表达式为固定模式,不可前后颠倒。
|
||||
|
||||
- **values** : nchar/binary 列/标签的值域,将从值中随机选择。
|
||||
- **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_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。
|
||||
- **create_table_thread_count**:建表的线程数量,默认为 8。
|
||||
|
||||
- **result_file** : 结果输出文件的路径,默认值为 ./output.txt 。
|
||||
- **result_file**:结果输出文件的路径,默认值为 ./output.txt 。
|
||||
|
||||
- **confirm_parameter_prompt** : 开关参数,要求用户在提示后确认才能继续, 可取值 "yes" or "no"。默认值为 "no" 。
|
||||
- **confirm_parameter_prompt**:开关参数,要求用户在提示后确认才能继续,可取值 "yes" or "no"。默认值为 "no" 。
|
||||
|
||||
- **interlace_rows** : 启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程,直到所有子表的数据都插入完成。默认值为 0, 即向一张子表完成数据插入后才会向下一张子表进行数据插入。
|
||||
- **interlace_rows**:启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程,直到所有子表的数据都插入完成。默认值为 0,即向一张子表完成数据插入后才会向下一张子表进行数据插入。
|
||||
在 `super_tables` 中也可以配置该参数,若配置则以 `super_tables` 中的配置为高优先级,覆盖全局设置。
|
||||
|
||||
- **insert_interval** :
|
||||
指定交错插入模式的插入间隔,单位为 ms,默认值为 0。 只有当 `-B/--interlace-rows` 大于 0 时才起作用。意味着数据插入线程在为每个子表插入隔行扫描记录后,会等待该值指定的时间间隔后再进行下一轮写入。
|
||||
- **insert_interval**:
|
||||
指定交错插入模式的插入间隔,单位为 ms,默认值为 0。只有当 `-B/--interlace-rows` 大于 0 时才起作用。意味着数据插入线程在为每个子表插入隔行扫描记录后,会等待该值指定的时间间隔后再进行下一轮写入。
|
||||
在 `super_tables` 中也可以配置该参数,若配置则以 `super_tables` 中的配置为高优先级,覆盖全局设置。
|
||||
|
||||
- **num_of_records_per_req** :
|
||||
- **num_of_records_per_req**:
|
||||
每次向 TDengine 请求写入的数据行数,默认值为 30000 。当其设置过大时,TDengine 客户端驱动会返回相应的错误信息,此时需要调低这个参数的设置以满足写入要求。
|
||||
|
||||
- **prepare_rand** : 生成的随机数据中唯一值的数量。若为 1 则表示所有数据都相同。默认值为 10000 。
|
||||
- **prepare_rand**:生成的随机数据中唯一值的数量。若为 1 则表示所有数据都相同。默认值为 10000 。
|
||||
|
||||
- **pre_load_tb_meta** :是否提前加载子表的 meta 数据,取值为 "yes" or "no"。当子表数量非常多时,打开此选项可提高写入速度。
|
||||
- **pre_load_tb_meta**:是否提前加载子表的 meta 数据,取值为 “yes” or "no"。当子表数量非常多时,打开此选项可提高写入速度。
|
||||
|
||||
### 查询配置参数
|
||||
|
||||
|
@ -256,7 +256,7 @@ taosBenchmark -f <json file>
|
|||
`query_times` 指定运行查询的次数,数值类型。
|
||||
|
||||
查询场景可以通过设置 `kill_slow_query_threshold` 和 `kill_slow_query_interval` 参数来控制杀掉慢查询语句的执行,threshold 控制如果 exec_usec 超过指定时间的查询将被 taosBenchmark 杀掉,单位为秒。
|
||||
interval 控制休眠时间,避免持续查询慢查询消耗 CPU ,单位为秒。
|
||||
interval 控制休眠时间,避免持续查询慢查询消耗 CPU,单位为秒。
|
||||
|
||||
其它通用参数详见 [通用配置参数](#通用配置参数)
|
||||
|
||||
|
@ -264,38 +264,38 @@ interval 控制休眠时间,避免持续查询慢查询消耗 CPU ,单位为
|
|||
|
||||
查询指定表(可以指定超级表、子表或普通表)的配置参数在 `specified_table_query` 中设置。
|
||||
|
||||
- **mixed_query** : 查询模式
|
||||
"yes" :`混合查询`
|
||||
"no"(默认值) :`普通查询`
|
||||
`普通查询`:`sqls` 中每个 sql 启动 `threads` 个线程查询此 sql, 执行完 `query_times` 次查询后退出,执行此 sql 的所有线程都完成后进入下一个 sql
|
||||
- **mixed_query**:查询模式
|
||||
“yes”:`混合查询`
|
||||
"no"(默认值):`普通查询`
|
||||
`普通查询`:`sqls` 中每个 sql 启动 `threads` 个线程查询此 sql,执行完 `query_times` 次查询后退出,执行此 sql 的所有线程都完成后进入下一个 sql
|
||||
`查询总次数` = `sqls` 个数 * `query_times` * `threads`
|
||||
|
||||
`混合查询`:`sqls` 中所有 sql 分成 `threads` 个组,每个线程执行一组, 每个 sql 都需执行 `query_times` 次查询
|
||||
`混合查询`:`sqls` 中所有 sql 分成 `threads` 个组,每个线程执行一组,每个 sql 都需执行 `query_times` 次查询
|
||||
`查询总次数` = `sqls` 个数 * `query_times`
|
||||
|
||||
- **query_interval** : 查询时间间隔,单位: millisecond,默认值为 0。
|
||||
- **query_interval**:查询时间间隔,单位:millisecond,默认值为 0。
|
||||
|
||||
- **threads** : 执行查询 SQL 的线程数,默认值为 1。
|
||||
- **threads**:执行查询 SQL 的线程数,默认值为 1。
|
||||
|
||||
- **sqls**:
|
||||
- **sql**: 执行的 SQL 命令,必填。
|
||||
- **result**: 保存查询结果的文件,未指定则不保存。
|
||||
- **sql**:执行的 SQL 命令,必填。
|
||||
- **result**:保存查询结果的文件,未指定则不保存。
|
||||
|
||||
#### 查询超级表
|
||||
|
||||
查询超级表的配置参数在 `super_table_query` 中设置。
|
||||
超级表查询的线程模式与上面介绍的指定查询语句查询的 `正常查询` 模式相同,不同之处是本 `sqls` 使用所有子表填充。
|
||||
查询超级表的配置参数在 `super_table_query` 中设置。
|
||||
超级表查询的线程模式与上面介绍的指定查询语句查询的 `正常查询` 模式相同,不同之处是本 `sqls` 使用所有子表填充。
|
||||
|
||||
- **stblname** : 指定要查询的超级表的名称,必填。
|
||||
- **stblname**:指定要查询的超级表的名称,必填。
|
||||
|
||||
- **query_interval** : 查询时间间隔,单位是秒,默认值为 0。
|
||||
- **query_interval**:查询时间间隔,单位是秒,默认值为 0。
|
||||
|
||||
- **threads** : 执行查询 SQL 的线程数,默认值为 1。
|
||||
- **threads**:执行查询 SQL 的线程数,默认值为 1。
|
||||
|
||||
- **sqls** :
|
||||
- **sql** : 执行的 SQL 命令,必填;对于超级表的查询 SQL,在 SQL 命令中必须保留 "xxxx",会替换为超级下所有子表名后再执行。
|
||||
- **result** : 保存查询结果的文件,未指定则不保存。
|
||||
- **限制项** : sqls 下配置 sql 数组最大为 100 个。
|
||||
- **sqls**:
|
||||
- **sql**:执行的 SQL 命令,必填;对于超级表的查询 SQL,在 SQL 命令中必须保留 "xxxx",会替换为超级下所有子表名后再执行。
|
||||
- **result**:保存查询结果的文件,未指定则不保存。
|
||||
- **限制项**:sqls 下配置 sql 数组最大为 100 个。
|
||||
|
||||
### 订阅配置参数
|
||||
|
||||
|
@ -303,14 +303,14 @@ interval 控制休眠时间,避免持续查询慢查询消耗 CPU ,单位为
|
|||
|
||||
订阅配置参数在 `tmq_info` 项下设置,参数如下:
|
||||
|
||||
- **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。
|
||||
- **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。
|
||||
|
||||
以下参数透传订阅属性,参见 [订阅创建参数](../../../develop/tmq/#创建参数) 说明:
|
||||
- **client.id**
|
||||
|
@ -319,7 +319,7 @@ interval 控制休眠时间,避免持续查询慢查询消耗 CPU ,单位为
|
|||
- **enable.auto.commit**
|
||||
- **msg.with.table.name**
|
||||
- **auto.commit.interval.ms**
|
||||
- **group.id** : 若此值不指定,将由 `group_mode` 指定规则生成 groupId,若指定此值,`group_mode` 参数不再有效。
|
||||
- **group.id**:若此值不指定,将由 `group_mode` 指定规则生成 groupId,若指定此值,`group_mode` 参数不再有效。
|
||||
|
||||
### 数据类型对照表
|
||||
|
||||
|
@ -395,28 +395,28 @@ SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thr
|
|||
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` 同前,表示纯引擎写入速度。
|
||||
- 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 : 写入最大延时。
|
||||
- min:写入最小延时。
|
||||
- avg:写入平时延时。
|
||||
- p90:写入延时 p90 百分位上的延时数。
|
||||
- p95:写入延时 p95 百分位上的延时数。
|
||||
- p99:写入延时 p99 百分位上的延时数。
|
||||
- max:写入最大延时。
|
||||
通过此系列指标,可观察到写入请求延时分布情况。
|
||||
|
||||
#### 查询指标
|
||||
|
||||
查询性能测试主要输出查询请求速度 QPS 指标, 输出格式如下:
|
||||
查询性能测试主要输出查询请求速度 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` 为测试的查询语句。
|
||||
- 第一行表示 3 个线程每个线程执行 10000 次查询及查询请求延时百分位分布情况,`SQL command` 为测试的查询语句。
|
||||
- 第二行表示查询总耗时为 26.9653 秒,每秒查询率(QPS)为:1113.049 次/秒。
|
||||
- 如果在查询中设置了 `continue_if_fail` 选项为 `yes`,在最后一行中会输出失败请求个数及错误率,格式 error + 失败请求个数 (错误率)。
|
||||
- QPS = 成功请求数量 / 花费时间(单位秒)
|
||||
|
@ -434,6 +434,6 @@ 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` 表示共消费了多少行数据。
|
||||
- 1 ~ 3 行实时输出每个消费者当前的消费速度,`msgs/s` 表示消费消息个数,每个消息中包含多行数据,`rows/s` 表示按行数统计的消费速度。
|
||||
- 4 ~ 6 行是测试完成后每个消费者总体统计,统计共消费了多少条消息,共计多少行。
|
||||
- 第 7 行所有消费者总体统计,`msgs` 表示共消费了多少条消息,`rows` 表示共消费了多少行数据。
|
||||
|
|
|
@ -12,7 +12,7 @@ description: 'TDengine 支持的数据类型: 时间戳、浮点型、JSON 类
|
|||
- 内部函数 NOW 是客户端的当前时间
|
||||
- 插入记录时,如果时间戳为 NOW,插入数据时使用提交这条记录的客户端的当前时间
|
||||
- Epoch Time:时间戳也可以是一个长整数,表示从 UTC 时间 1970-01-01 00:00:00 开始的毫秒数。相应地,如果所在 Database 的时间精度设置为“微秒”,则长整型格式的时间戳含义也就对应于从 UTC 时间 1970-01-01 00:00:00 开始的微秒数;纳秒精度逻辑相同。
|
||||
- 时间可以加减,比如 NOW-2h,表明查询时刻向前推 2 个小时(最近 2 小时)。数字后面的时间单位可以是 b(纳秒)、u(微秒)、a(毫秒)、s(秒)、m(分)、h(小时)、d(天)、w(周)。 比如 `SELECT * FROM t1 WHERE ts > NOW-2w AND ts <= NOW-1w`,表示查询两周前整整一周的数据。在指定降采样操作(Down Sampling)的时间窗口(Interval)时,时间单位还可以使用 n(自然月)和 y(自然年)。
|
||||
- 时间可以加减,比如 NOW-2h,表明查询时刻向前推 2 个小时(最近 2 小时)。数字后面的时间单位可以是 b(纳秒)、u(微秒)、a(毫秒)、s(秒)、m(分)、h(小时)、d(天)、w(周)。比如 `SELECT * FROM t1 WHERE ts > NOW-2w AND ts <= NOW-1w`,表示查询两周前整整一周的数据。在指定降采样操作(Down Sampling)的时间窗口(Interval)时,时间单位还可以使用 n(自然月)和 y(自然年)。
|
||||
|
||||
TDengine 缺省的时间戳精度是毫秒,但通过在 `CREATE DATABASE` 时传递的 `PRECISION` 参数也可以支持微秒和纳秒。
|
||||
|
||||
|
@ -24,24 +24,24 @@ CREATE DATABASE db_name PRECISION 'ns';
|
|||
|
||||
在 TDengine 中,普通表的数据模型中可使用以下数据类型。
|
||||
|
||||
| # | **类型** | **Bytes** | **说明** |
|
||||
| --- | :---------------: | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | TIMESTAMP | 8 | 时间戳。缺省精度毫秒,可支持微秒和纳秒,详细说明见上节。 |
|
||||
| 2 | INT | 4 | 整型,范围 [-2^31, 2^31-1] |
|
||||
| 3 | INT UNSIGNED | 4 | 无符号整数,[0, 2^32-1] |
|
||||
| 4 | BIGINT | 8 | 长整型,范围 [-2^63, 2^63-1] |
|
||||
| 5 | BIGINT UNSIGNED | 8 | 长整型,范围 [0, 2^64-1] |
|
||||
| 6 | FLOAT | 4 | 浮点型,有效位数 6-7,范围 [-3.4E38, 3.4E38] |
|
||||
| 7 | DOUBLE | 8 | 双精度浮点型,有效位数 15-16,范围 [-1.7E308, 1.7E308] |
|
||||
| 8 | BINARY | 自定义 | 记录单字节字符串,建议只用于处理 ASCII 可见字符,中文等多字节字符需使用 NCHAR |
|
||||
| 9 | SMALLINT | 2 | 短整型, 范围 [-32768, 32767] |
|
||||
| 10 | SMALLINT UNSIGNED | 2 | 无符号短整型,范围 [0, 65535] |
|
||||
| 11 | TINYINT | 1 | 单字节整型,范围 [-128, 127] |
|
||||
| 12 | TINYINT UNSIGNED | 1 | 无符号单字节整型,范围 [0, 255] |
|
||||
| 13 | BOOL | 1 | 布尔型,{true, false} |
|
||||
| 14 | NCHAR | 自定义 | 记录包含多字节字符在内的字符串,如中文字符。每个 NCHAR 字符占用 4 字节的存储空间。字符串两端使用单引号引用,字符串内的单引号需用转义字符 `\'`。NCHAR 使用时须指定字符串大小,类型为 NCHAR(10) 的列表示此列的字符串最多存储 10 个 NCHAR 字符。如果用户字符串长度超出声明长度,将会报错。 |
|
||||
| 15 | JSON | | JSON 数据类型, 只有 Tag 可以是 JSON 格式 |
|
||||
| 16 | VARCHAR | 自定义 | BINARY 类型的别名 |
|
||||
| # | **类型** | **Bytes** | **说明** |
|
||||
| --- | :---------------: | --------- | ---------------------- |
|
||||
| 1 | TIMESTAMP | 8 | 时间戳。缺省精度毫秒,可支持微秒和纳秒,详细说明见上节。|
|
||||
| 2 | INT | 4 | 整型,范围 [-2^31, 2^31-1] |
|
||||
| 3 | INT UNSIGNED | 4 | 无符号整数,[0, 2^32-1] |
|
||||
| 4 | BIGINT | 8 | 长整型,范围 [-2^63, 2^63-1] |
|
||||
| 5 | BIGINT UNSIGNED | 8 | 长整型,范围 [0, 2^64-1] |
|
||||
| 6 | FLOAT | 4 | 浮点型,有效位数 6-7,范围 [-3.4E38, 3.4E38] |
|
||||
| 7 | DOUBLE | 8 | 双精度浮点型,有效位数 15-16,范围 [-1.7E308, 1.7E308] |
|
||||
| 8 | BINARY | 自定义 | 记录单字节字符串,建议只用于处理 ASCII 可见字符,中文等多字节字符需使用 NCHAR|
|
||||
| 9 | SMALLINT | 2 | 短整型, 范围 [-32768, 32767] |
|
||||
| 10 | SMALLINT UNSIGNED | 2 | 无符号短整型,范围 [0, 65535] |
|
||||
| 11 | TINYINT | 1 | 单字节整型,范围 [-128, 127] |
|
||||
| 12 | TINYINT UNSIGNED | 1 | 无符号单字节整型,范围 [0, 255] |
|
||||
| 13 | BOOL | 1 | 布尔型,{true, false} |
|
||||
| 14 | NCHAR | 自定义 | 记录包含多字节字符在内的字符串,如中文字符。每个 NCHAR 字符占用 4 字节的存储空间。字符串两端使用单引号引用,字符串内的单引号需用转义字符 `\'`。NCHAR 使用时须指定字符串大小,类型为 NCHAR(10) 的列表示此列的字符串最多存储 10 个 NCHAR 字符。如果用户字符串长度超出声明长度,将会报错。|
|
||||
| 15 | JSON | | JSON 数据类型, 只有 Tag 可以是 JSON 格式 |
|
||||
| 16 | VARCHAR | 自定义 | BINARY 类型的别名 |
|
||||
| 17 | GEOMETRY | 自定义 | 几何类型,3.1.0.0 版本开始支持
|
||||
| 18 | VARBINARY | 自定义 | 可变长的二进制数据, 3.1.1.0 版本开始支持|
|
||||
|
||||
|
@ -52,14 +52,14 @@ CREATE DATABASE db_name PRECISION 'ns';
|
|||
- BINARY 类型理论上最长可以有 16,374(从 3.0.5.0 版本开始,数据列为 65,517,标签列为 16,382) 字节。BINARY 仅支持字符串输入,字符串两端需使用单引号引用。使用时须指定大小,如 BINARY(20) 定义了最长为 20 个单字节字符的字符串,每个字符占 1 字节的存储空间,总共固定占用 20 字节的空间,此时如果用户字符串超出 20 字节将会报错。对于字符串内的单引号,可以用转义字符反斜线加单引号来表示,即 `\'`。
|
||||
- GEOMETRY 类型数据列为最大长度为 65,517 字节,标签列最大长度为 16,382 字节。支持 2D 的 POINT、LINESTRING 和 POLYGON 子类型数据。长度计算方式如下表所示:
|
||||
|
||||
| # | **语法** | **最小长度** | **最大长度** | **每组坐标长度增长** |
|
||||
| # | **语法** | **最小长度** | **最大长度** | **每组坐标长度增长** |
|
||||
|---|--------------------------------------|----------|------------|--------------|
|
||||
| 1 | POINT(1.0 1.0) | 21 | 21 | 无 |
|
||||
| 1 | POINT(1.0 1.0) | 21 | 21 | 无 |
|
||||
| 2 | LINESTRING(1.0 1.0, 2.0 2.0) | 9+2*16 | 9+4094*16 | +16 |
|
||||
| 3 | POLYGON((1.0 1.0, 2.0 2.0, 1.0 1.0)) | 13+3*16 | 13+4094*16 | +16 |
|
||||
|
||||
- SQL 语句中的数值类型将依据是否存在小数点,或使用科学计数法表示,来判断数值类型是否为整型或者浮点型,因此在使用时要注意相应类型越界的情况。例如,9999999999999999999 会认为超过长整型的上边界而溢出,而 9999999999999999999.0 会被认为是有效的浮点数。
|
||||
- VARBINARY 是一种存储二进制数据的数据类型,最大长度为 65,517 字节,标签列最大长度为 16,382 字节。可以通过sql或schemaless方式写入二进制数据(需要转换为\x开头的字符串写入),也可以通过stmt方式写入(可以直接使用二进制)。显示时通过16进制\x开头。
|
||||
- VARBINARY 是一种存储二进制数据的数据类型,最大长度为 65,517 字节,标签列最大长度为 16,382 字节。可以通过sql或schemaless方式写入二进制数据(需要转换为 `\x` 开头的字符串写入),也可以通过 stmt 方式写入(可以直接使用二进制)。显示时通过16进制\x开头。
|
||||
|
||||
:::
|
||||
|
||||
|
@ -67,16 +67,16 @@ CREATE DATABASE db_name PRECISION 'ns';
|
|||
|
||||
TDengine 支持多个类型的常量,细节如下表:
|
||||
|
||||
| # | **语法** | **类型** | **说明** |
|
||||
| --- | :-----------------------------------------------: | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | [\{+ \| -}]123 | BIGINT | 整型数值的字面量的类型均为 BIGINT。如果用户输入超过了 BIGINT 的表示范围,TDengine 按 BIGINT 对数值进行截断。 |
|
||||
| 2 | 123.45 | DOUBLE | 浮点数值的字面量的类型均为 DOUBLE。TDengine 依据是否存在小数点,或使用科学计数法表示,来判断数值类型是否为整型或者浮点型。 |
|
||||
| 3 | 1.2E3 | DOUBLE | 科学计数法的字面量的类型为 DOUBLE。 |
|
||||
| 4 | 'abc' | BINARY | 单引号括住的内容为字符串字面值,其类型为 BINARY,BINARY 的 Size 为实际的字符个数。对于字符串内的单引号,可以用转义字符反斜线加单引号来表示,即 `\'`。 |
|
||||
| 5 | "abc" | BINARY | 双引号括住的内容为字符串字面值,其类型为 BINARY,BINARY 的 Size 为实际的字符个数。对于字符串内的双引号,可以用转义字符反斜线加单引号来表示,即 `\"`。 |
|
||||
| 6 | TIMESTAMP \{'literal' \| "literal"} | TIMESTAMP | TIMESTAMP 关键字表示后面的字符串字面量需要被解释为 TIMESTAMP 类型。字符串需要满足 YYYY-MM-DD HH:mm:ss.MS 格式,其时间分辨率为当前数据库的时间分辨率。 |
|
||||
| 7 | \{TRUE \| FALSE} | BOOL | 布尔类型字面量。 |
|
||||
| 8 | \{'' \| "" \| '\t' \| "\t" \| ' ' \| " " \| NULL } | -- | 空值字面量。可以用于任意类型。 |
|
||||
| # | **语法** | **类型** | **说明** |
|
||||
| --- | :-----------------------------------------------: | --------- | -------------------------------------------------------------------------------- |
|
||||
| 1 | [\{+ \| -}]123 | BIGINT | 整型数值的字面量的类型均为 BIGINT。如果用户输入超过了 BIGINT 的表示范围,TDengine 按 BIGINT 对数值进行截断。 |
|
||||
| 2 | 123.45 | DOUBLE | 浮点数值的字面量的类型均为 DOUBLE。TDengine 依据是否存在小数点,或使用科学计数法表示,来判断数值类型是否为整型或者浮点型。|
|
||||
| 3 | 1.2E3 | DOUBLE | 科学计数法的字面量的类型为 DOUBLE。|
|
||||
| 4 | 'abc' | BINARY | 单引号括住的内容为字符串字面值,其类型为 BINARY,BINARY 的 Size 为实际的字符个数。对于字符串内的单引号,可以用转义字符反斜线加单引号来表示,即 `\'`。|
|
||||
| 5 | "abc" | BINARY | 双引号括住的内容为字符串字面值,其类型为 BINARY,BINARY 的 Size 为实际的字符个数。对于字符串内的双引号,可以用转义字符反斜线加单引号来表示,即 `\"`。|
|
||||
| 6 | TIMESTAMP \{'literal' \| "literal"} | TIMESTAMP | TIMESTAMP 关键字表示后面的字符串字面量需要被解释为 TIMESTAMP 类型。字符串需要满足 YYYY-MM-DD HH:mm:ss.MS 格式,其时间分辨率为当前数据库的时间分辨率。|
|
||||
| 7 | \{TRUE \| FALSE} | BOOL | 布尔类型字面量。 |
|
||||
| 8 | \{'' \| "" \| '\t' \| "\t" \| ' ' \| " " \| NULL } | -- | 空值字面量。可以用于任意类型。|
|
||||
|
||||
:::note
|
||||
|
||||
|
|
|
@ -46,13 +46,13 @@ database_option: {
|
|||
### 参数说明
|
||||
|
||||
- VGROUPS:数据库中初始 vgroup 的数目。
|
||||
- PRECISION:数据库的时间戳精度。ms 表示毫秒,us 表示微秒,ns 表示纳秒,默认 ms 毫秒。
|
||||
- PRECISION:数据库的时间戳精度。ms 表示毫秒、us 表示微秒、ns 表示纳秒、默认 ms 毫秒。
|
||||
- REPLICA:表示数据库副本数,取值为 1、2 或 3,默认为 1; 2 仅在企业版 3.3.0.0 及以后版本中可用。在集群中使用,副本数必须小于或等于 DNODE 的数目。且使用时存在以下限制:
|
||||
- 暂不支持对双副本数据库相关 Vgroup 进行 SPLITE VGROUP 或 REDISTRIBUTE VGROUP 操作
|
||||
- 单副本数据库可变更为双副本数据库,但不支持从双副本变更为其它副本数,也不支持从三副本变更为双副本
|
||||
- BUFFER: 一个 VNODE 写入内存池大小,单位为 MB,默认为 256,最小为 3,最大为 16384。
|
||||
- PAGES:一个 VNODE 中元数据存储引擎的缓存页个数,默认为 256,最小 64。一个 VNODE 元数据存储占用 PAGESIZE \* PAGES,默认情况下为 1MB 内存。
|
||||
- PAGESIZE:一个 VNODE 中元数据存储引擎的页大小,单位为 KB,默认为 4 KB。范围为 1 到 16384,即 1 KB 到 16 MB。
|
||||
- BUFFER:一个 vnode 写入内存池大小,单位为 MB,默认为 256,最小为 3,最大为 16384。
|
||||
- PAGES:一个 vnode 中元数据存储引擎的缓存页个数,默认为 256,最小 64。一个 vnode 元数据存储占用 PAGESIZE \* PAGES,默认情况下为 1MB 内存。
|
||||
- PAGESIZE:一个 vnode 中元数据存储引擎的页大小,单位为 KB,默认为 4 KB。范围为 1 到 16384,即 1 KB 到 16 MB。
|
||||
- CACHEMODEL:表示是否在内存中缓存子表的最近数据。默认为 none。
|
||||
- none:表示不缓存。
|
||||
- last_row:表示缓存子表最近一行数据。这将显著改善 LAST_ROW 函数的性能表现。
|
||||
|
@ -76,17 +76,17 @@ database_option: {
|
|||
- 1:表示只可以创建一张超级表。
|
||||
- TABLE_PREFIX:当其为正值时,在决定把一个表分配到哪个 vgroup 时要忽略表名中指定长度的前缀;当其为负值时,在决定把一个表分配到哪个 vgroup 时只使用表名中指定长度的前缀;例如,假定表名为 "v30001",当 TSDB_PREFIX = 2 时 使用 "0001" 来决定分配到哪个 vgroup ,当 TSDB_PREFIX = -2 时使用 "v3" 来决定分配到哪个 vgroup
|
||||
- TABLE_SUFFIX:当其为正值时,在决定把一个表分配到哪个 vgroup 时要忽略表名中指定长度的后缀;当其为负值时,在决定把一个表分配到哪个 vgroup 时只使用表名中指定长度的后缀;例如,假定表名为 "v30001",当 TSDB_SUFFIX = 2 时 使用 "v300" 来决定分配到哪个 vgroup ,当 TSDB_SUFFIX = -2 时使用 "01" 来决定分配到哪个 vgroup。
|
||||
- TSDB_PAGESIZE:一个 VNODE 中时序数据存储引擎的页大小,单位为 KB,默认为 4 KB。范围为 1 到 16384,即 1 KB到 16 MB。
|
||||
- DNODES:指定 VNODE 所在的 DNODE 列表,如 '1,2,3',以逗号区分且字符间不能有空格,仅企业版支持。
|
||||
- TSDB_PAGESIZE:一个 vnode 中时序数据存储引擎的页大小,单位为 KB,默认为 4 KB。范围为 1 到 16384,即 1 KB到 16 MB。
|
||||
- DNODES:指定 vnode 所在的 DNODE 列表,如 '1,2,3',以逗号区分且字符间不能有空格,仅企业版支持。
|
||||
- WAL_LEVEL:WAL 级别,默认为 1。
|
||||
- 1:写 WAL,但不执行 fsync。
|
||||
- 2:写 WAL,而且执行 fsync。
|
||||
- WAL_FSYNC_PERIOD:当 WAL_LEVEL 参数设置为 2 时,用于设置落盘的周期。默认为 3000,单位毫秒。最小为 0,表示每次写入立即落盘;最大为 180000,即三分钟。
|
||||
- WAL_RETENTION_PERIOD: 为了数据订阅消费,需要 WAL 日志文件额外保留的最大时长策略。WAL 日志清理,不受订阅客户端消费状态影响。单位为 s。默认为 3600,表示在 WAL 保留最近 3600 秒的数据,请根据数据订阅的需要修改这个参数为适当值。
|
||||
- WAL_RETENTION_PERIOD:为了数据订阅消费,需要 WAL 日志文件额外保留的最大时长策略。WAL 日志清理,不受订阅客户端消费状态影响。单位为 s。默认为 3600,表示在 WAL 保留最近 3600 秒的数据,请根据数据订阅的需要修改这个参数为适当值。
|
||||
- WAL_RETENTION_SIZE:为了数据订阅消费,需要 WAL 日志文件额外保留的最大累计大小策略。单位为 KB。默认为 0,表示累计大小无上限。
|
||||
- COMPACT_INTERVAL:自动 compact 触发周期(从 1970-01-01T00:00:00Z 开始切分的时间周期)。取值范围:0 或 [10m, keep2],单位:m(分钟),h(小时),d(天)。不加时间单位默认单位为天,默认值为 0,即不触发自动 compact 功能。如果 db 中有未完成的 compact 任务,不重复下发 compact 任务。仅企业版 3.3.5.0 版本开始支持。
|
||||
- COMPACT_TIME_RANGE:自动 compact 任务触发的 compact 时间范围,取值范围:[-keep2, -duration],单位:m(分钟),h(小时),d(天)。不加时间单位时默认单位为天,默认值为 [0, 0]。取默认值 [0, 0] 时,如果 COMPACT_INTERVAL 大于 0,会按照 [-keep2, -duration] 下发自动 compact。因此,要关闭自动 compact 功能,需要将 COMPACT_INTERVAL 设置为 0。仅企业版 3.3.5.0 版本开始支持。
|
||||
- COMPACT_TIME_OFFSET:自动 compact 任务触发的 compact 时间相对本地时间的偏移量。取值范围:[0,23],单位: h(小时),默认值为 0。以 UTC 0 时区为例,如果 COMPACT_INTERVAL 为 1d,当 COMPACT_TIME_OFFSET 为 0 时,在每天 0 点下发自动 compact,如果 COMPACT_TIME_OFFSET 为 2,在每天 2 点下发自动 compact。仅企业版 3.3.5.0 版本开始支持。
|
||||
- COMPACT_TIME_OFFSET:自动 compact 任务触发的 compact 时间相对本地时间的偏移量。取值范围:[0, 23],单位:h(小时),默认值为 0。以 UTC 0 时区为例,如果 COMPACT_INTERVAL 为 1d,当 COMPACT_TIME_OFFSET 为 0 时,在每天 0 点下发自动 compact,如果 COMPACT_TIME_OFFSET 为 2,在每天 2 点下发自动 compact。仅企业版 3.3.5.0 版本开始支持。
|
||||
-
|
||||
|
||||
### 创建数据库示例
|
||||
|
|
|
@ -41,7 +41,7 @@ table_option: {
|
|||
|
||||
**使用说明**
|
||||
|
||||
1. 表(列)名命名规则参见[名称命名规则](./19-limit.md#名称命名规则)。
|
||||
1. 表(列)名命名规则参见 [名称命名规则](./19-limit.md#名称命名规则)。
|
||||
2. 表名最大长度为 192。
|
||||
3. 表的第一个字段必须是 TIMESTAMP,并且系统自动将其设为主键。
|
||||
4. 除时间戳主键列之外,还可以通过 PRIMARY KEY 关键字指定第二列为额外的主键列,该列与时间戳列共同组成复合主键。当设置了复合主键时,两条记录的时间戳列与 PRIMARY KEY 列都相同,才会被认为是重复记录,数据库只保留最新的一条;否则视为两条记录,全部保留。注意:被指定为主键列的第二列必须为整型或字符串类型(VARCHAR)。
|
||||
|
|
|
@ -99,11 +99,11 @@ Hints 是用户控制单个语句查询优化的一种手段,当 Hint 不适
|
|||
| :-----------: | -------------- | -------------------------- | -----------------------------|
|
||||
| BATCH_SCAN | 无 | 采用批量读表的方式 | 超级表 JOIN 语句 |
|
||||
| NO_BATCH_SCAN | 无 | 采用顺序读表的方式 | 超级表 JOIN 语句 |
|
||||
| SORT_FOR_GROUP| 无 | 采用sort方式进行分组, 与PARTITION_FIRST冲突 | partition by 列表有普通列时 |
|
||||
| PARTITION_FIRST| 无 | 在聚合之前使用PARTITION计算分组, 与SORT_FOR_GROUP冲突 | partition by 列表有普通列时 |
|
||||
| PARA_TABLES_SORT| 无 | 超级表的数据按时间戳排序时, 不使用临时磁盘空间, 只使用内存。当子表数量多, 行长比较大时候, 会使用大量内存, 可能发生OOM | 超级表的数据按时间戳排序时 |
|
||||
| SMALLDATA_TS_SORT| 无 | 超级表的数据按时间戳排序时, 查询列长度大于等于256, 但是行数不多, 使用这个提示, 可以提高性能 | 超级表的数据按时间戳排序时 |
|
||||
| SKIP_TSMA | 无 | 用于显示的禁用TSMA查询优化 | 带Agg函数的查询语句 |
|
||||
| SORT_FOR_GROUP| 无 | 采用 sort 方式进行分组,与 PARTITION_FIRST 冲突 | partition by 列表有普通列时 |
|
||||
| PARTITION_FIRST| 无 | 在聚合之前使用 PARTITION 计算分组,与 SORT_FOR_GROUP 冲突 | partition by 列表有普通列时 |
|
||||
| PARA_TABLES_SORT| 无 | 超级表的数据按时间戳排序时,不使用临时磁盘空间,只使用内存。当子表数量多,行长比较大时候,会使用大量内存,可能发生 OOM | 超级表的数据按时间戳排序时 |
|
||||
| SMALLDATA_TS_SORT| 无 | 超级表的数据按时间戳排序时,查询列长度大于等于 256,但是行数不多,使用这个提示,可以提高性能 | 超级表的数据按时间戳排序时 |
|
||||
| SKIP_TSMA | 无 | 用于显示的禁用 TSMA 查询优化 | 带 Agg 函数的查询语句 |
|
||||
|
||||
举例:
|
||||
|
||||
|
@ -321,13 +321,13 @@ NULLS 语法用来指定 NULL 值在排序中输出的位置。NULLS LAST 是升
|
|||
|
||||
## LIMIT
|
||||
|
||||
LIMIT 控制输出条数,OFFSET 指定从第几条之后开始输出。LIMIT/OFFSET 对结果集的执行顺序在 ORDER BY 之后。LIMIT 5 OFFSET 2 可以简写为 LIMIT 2, 5,都输出第 3 行到第 7 行数据。
|
||||
LIMIT 控制输出条数,OFFSET 指定从第几条之后开始输出。LIMIT/OFFSET 对结果集的执行顺序在 ORDER BY 之后。`LIMIT 5 OFFSET 2` 可以简写为 `LIMIT 2, 5`,都输出第 3 行到第 7 行数据。
|
||||
|
||||
在有 PARTITION BY/GROUP BY 子句时,LIMIT 控制的是每个切分的分片中的输出,而不是总的结果集输出。
|
||||
|
||||
## SLIMIT
|
||||
|
||||
SLIMIT 和 PARTITION BY/GROUP BY 子句一起使用,用来控制输出的分片的数量。SLIMIT 5 SOFFSET 2 可以简写为 SLIMIT 2, 5,都表示输出第 3 个到第 7 个分片。
|
||||
SLIMIT 和 PARTITION BY/GROUP BY 子句一起使用,用来控制输出的分片的数量。`SLIMIT 5 SOFFSET 2` 可以简写为 SLIMIT `2, 5`,都表示输出第 3 个到第 7 个分片。
|
||||
|
||||
需要注意,如果有 ORDER BY 子句,则输出只有一个分片。
|
||||
|
||||
|
@ -484,8 +484,8 @@ SELECT ... FROM (SELECT ... FROM ...) ...;
|
|||
- 内层查询的 ORDER BY 子句一般没有意义,建议避免这样的写法以免无谓的资源消耗。
|
||||
- 与非嵌套的查询语句相比,外层查询所能支持的功能特性存在如下限制:
|
||||
- 计算函数部分:
|
||||
- 如果内层查询的结果数据未提供时间戳,那么计算过程隐式依赖时间戳的函数在外层会无法正常工作。例如:INTERP, DERIVATIVE, IRATE, LAST_ROW, FIRST, LAST, TWA, STATEDURATION, TAIL, UNIQUE。
|
||||
- 如果内层查询的结果数据不是按时间戳有序,那么计算过程依赖数据按时间有序的函数在外层会无法正常工作。例如:LEASTSQUARES, ELAPSED, INTERP, DERIVATIVE, IRATE, TWA, DIFF, STATECOUNT, STATEDURATION, CSUM, MAVG, TAIL, UNIQUE。
|
||||
- 如果内层查询的结果数据未提供时间戳,那么计算过程隐式依赖时间戳的函数在外层会无法正常工作。例如:INTERP、DERIVATIVE、IRATE、LAST_ROW、FIRST、LAST、TWA、STATEDURATION、TAIL、UNIQUE。
|
||||
- 如果内层查询的结果数据不是按时间戳有序,那么计算过程依赖数据按时间有序的函数在外层会无法正常工作。例如:LEASTSQUARES、ELAPSED、INTERP、DERIVATIVE、IRATE、TWA、DIFF、STATECOUNT、STATEDURATION、CSUM、MAVG、TAIL、UNIQUE。
|
||||
- 计算过程需要两遍扫描的函数,在外层查询中无法正常工作。例如:此类函数包括:PERCENTILE。
|
||||
|
||||
:::
|
||||
|
@ -520,7 +520,7 @@ SELECT * FROM tb1 WHERE ts >= NOW - 1h;
|
|||
SELECT * FROM tb1 WHERE ts > '2018-06-01 08:00:00.000' AND ts <= '2018-06-02 08:00:00.000' AND col3 LIKE '%nny' ORDER BY ts DESC;
|
||||
```
|
||||
|
||||
查询 col1 与 col2 的和,并取名 complex, 时间大于 2018-06-01 08:00:00.000, col2 大于 1.2,结果输出仅仅 10 条记录,从第 5 条开始:
|
||||
查询 col1 与 col2 的和,并取名 complex,时间大于 2018-06-01 08:00:00.000,col2 大于 1.2,结果输出仅仅 10 条记录,从第 5 条开始:
|
||||
|
||||
```
|
||||
SELECT (col1 + col2) AS 'complex' FROM tb1 WHERE ts > '2018-06-01 08:00:00.000' AND col2 > 1.2 LIMIT 10 OFFSET 5;
|
||||
|
|
|
@ -41,7 +41,7 @@ SHOW INDEXES FROM [db_name.]tbl_name;
|
|||
|
||||
## 使用说明
|
||||
|
||||
1. 索引使用得当能够提升数据过滤的效率,目前支持的过滤算子有 `=`, `>`, `>=`, `<`, `<=`。如果查询过滤条件中使用了这些算子,则索引能够明显提升查询效率。但如果查询过滤条件中使用的是其它算子,则索引起不到作用,查询效率没有变化。未来会逐步添加更多的算子。
|
||||
1. 索引使用得当能够提升数据过滤的效率,目前支持的过滤算子有 `=`、`>`、`>=`、`<`、`<=`。如果查询过滤条件中使用了这些算子,则索引能够明显提升查询效率。但如果查询过滤条件中使用的是其它算子,则索引起不到作用,查询效率没有变化。未来会逐步添加更多的算子。
|
||||
|
||||
2. 针对一个 tag 列只能建立一个索引,如果重复创建索引则会报错。
|
||||
|
||||
|
@ -55,4 +55,4 @@ SHOW INDEXES FROM [db_name.]tbl_name;
|
|||
|
||||
7. 如果某个 tag 列的唯一值较少时,不建议对其建立索引,这种情况下收效甚微。
|
||||
|
||||
8. 新建立的超级表,会给第一列tag,随机生成一个indexNewName, 生成规则是:tag0的name + 23个byte, 在系统表可以查,也可以按需要drop,行为和其他列tag 的索引一样
|
||||
8. 新建立的超级表,会给第一列 tag,随机生成一个indexNewName,生成规则是:tag0的name + 23个byte,在系统表可以查,也可以按需要drop,行为和其他列 tag 的索引一样
|
||||
|
|
|
@ -14,19 +14,19 @@ title: "删除数据"
|
|||
DELETE FROM [ db_name. ] tb_name [WHERE condition];
|
||||
```
|
||||
|
||||
**功能:** 删除指定表或超级表中的数据记录
|
||||
**功能**:删除指定表或超级表中的数据记录
|
||||
|
||||
**参数:**
|
||||
**参数**:
|
||||
|
||||
- `db_name` : 可选参数,指定要删除表所在的数据库名,不填写则在当前数据库中
|
||||
- `tb_name` : 必填参数,指定要删除数据的表名,可以是普通表、子表,也可以是超级表。
|
||||
- `condition`: 可选参数,指定删除数据的过滤条件,不指定过滤条件则为表中所有数据,请慎重使用。特别说明,这里的 where 条件中只支持对第一列时间列的过滤。
|
||||
- `db_name` :可选参数,指定要删除表所在的数据库名,不填写则在当前数据库中
|
||||
- `tb_name` :必填参数,指定要删除数据的表名,可以是普通表、子表,也可以是超级表。
|
||||
- `condition`:可选参数,指定删除数据的过滤条件,不指定过滤条件则为表中所有数据,请慎重使用。特别说明,这里的 where 条件中只支持对第一列时间列的过滤。
|
||||
|
||||
**特别说明:**
|
||||
**特别说明**:
|
||||
|
||||
数据删除后不可恢复,请慎重使用。为了确保删除的数据确实是自己要删除的,建议可以先使用 `select` 语句加 `where` 后的删除条件查看要删除的数据内容,确认无误后再执行 `delete` 命令。
|
||||
|
||||
**示例:**
|
||||
**示例**:
|
||||
|
||||
`meters` 是一个超级表,`groupid` 是 int 类型的 tag 列,现在要删除 `meters` 表中时间小于 2021-10-01 10:40:00.100 的所有数据,sql 如下:
|
||||
|
||||
|
|
|
@ -193,7 +193,7 @@ ROUND(expr[, digits])
|
|||
- `digits` 小于零表示丢掉小数位,并将数字四舍五入到小数点左侧 `digits` 位。若小数点左侧的位数小于 `digits`位,返回 0。
|
||||
- 由于暂未支持 DECIMAL 类型,所以该函数会用 DOUBLE 和 FLOAT 来表示包含小数的结果,但是 DOUBLE 和 FLOAT 是有精度上限的,当位数太多时使用该函数可能没有意义。
|
||||
- 只能与普通列,选择(Selection)、投影(Projection)函数一起使用,不能与聚合(Aggregation)函数一起使用。
|
||||
- `digits` 从 3.3.3.0 版本开始支持。
|
||||
- `digits` 从 v3.3.3.0 开始支持。
|
||||
|
||||
**举例**:
|
||||
```sql
|
||||
|
@ -269,7 +269,7 @@ PI()
|
|||
|
||||
**功能说明**:返回圆周率 π 的值。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -298,7 +298,7 @@ TRUNCATE(expr, digits)
|
|||
|
||||
**功能说明**:获得指定字段按照指定位数截断的值。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:与 `expr` 字段的原始数据类型一致。
|
||||
|
||||
|
@ -338,7 +338,7 @@ EXP(expr)
|
|||
```
|
||||
**功能说明**:返回 e(自然对数的底)的指定乘方后的值。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -367,7 +367,7 @@ LN(expr)
|
|||
|
||||
**功能说明**:返回指定参数的自然对数。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -397,7 +397,7 @@ MOD(expr1, expr2)
|
|||
|
||||
**功能说明**:计算 expr1 % expr2 的结果。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -432,7 +432,7 @@ RAND([seed])
|
|||
|
||||
**功能说明**:返回一个从0到1均匀分布的随机数。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -477,7 +477,7 @@ SIGN(expr)
|
|||
|
||||
**功能说明**:返回指定参数的符号。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:与指定字段的原始数据类型一致。
|
||||
|
||||
|
@ -490,8 +490,8 @@ SIGN(expr)
|
|||
**使用说明**:
|
||||
- 如果 `expr` 为负,返回 -1。
|
||||
- 如果 `expr` 为正,返回 1。
|
||||
- 如果 `expr` 为 0 ,返回 0。
|
||||
- 如果 `expr` 为 NULL ,返回 NULL。
|
||||
- 如果 `expr` 为 0,返回 0。
|
||||
- 如果 `expr` 为 NULL,返回 NULL。
|
||||
- 只能与普通列,选择(Selection)、投影(Projection)函数一起使用,不能与聚合(Aggregation)函数一起使用。
|
||||
|
||||
**举例**:
|
||||
|
@ -519,7 +519,7 @@ DEGREES(expr)
|
|||
|
||||
**功能说明**:计算指定参数由弧度值转为角度后的值。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -549,7 +549,7 @@ RADIANS(expr)
|
|||
|
||||
**功能说明**:计算指定参数由角度值转为弧度后的值。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:DOUBLE。
|
||||
|
||||
|
@ -721,7 +721,7 @@ TRIM([remstr FROM] expr)
|
|||
|
||||
**功能说明**:返回去掉了所有 remstr 前缀或后缀的字符串 epxr。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:与输入字段 epxr 的原始类型相同。
|
||||
|
||||
|
@ -738,9 +738,9 @@ TRIM([remstr FROM] expr)
|
|||
- LEADING 将移除字符串开头的指定字符。
|
||||
- TRAILING 将移除字符串末尾的指定字符。
|
||||
- BOTH(默认值)将移除字符串开头和末尾的指定字符。
|
||||
- 第二个可选变量 [remstr] 指定要裁剪掉的字符串:
|
||||
- 第二个可选变量[remstr]指定要裁剪掉的字符串:
|
||||
- 如果不指定 remstr,默认裁剪空格。
|
||||
- remstr 可以指定多个字符,如 trim('ab' from 'abacd') ,此时会将 'ab' 看做一个整体来裁剪,得到裁剪结果 'acd'。
|
||||
- remstr 可以指定多个字符,如 trim('ab' from 'abacd'),此时会将 'ab' 看做一个整体来裁剪,得到裁剪结果 'acd'。
|
||||
- 若 expr 为 NULL,返回 NULL。
|
||||
- 该函数是多字节安全的。
|
||||
|
||||
|
@ -773,7 +773,7 @@ taos> select trim(both 'b' from 'bbbbbabbbbbb');
|
|||
SUBSTRING/SUBSTR(expr, pos [, len])
|
||||
SUBSTRING/SUBSTR(expr FROM pos [FOR len])
|
||||
```
|
||||
**功能说明**:返回字符串 `expr` 在 `pos` 位置开始的子串,若指定了 `len` ,则返回在 `pos` 位置开始,长度为 `len` 的子串。
|
||||
**功能说明**:返回字符串 `expr` 在 `pos` 位置开始的子串,若指定了 `len`,则返回在 `pos` 位置开始,长度为 `len` 的子串。
|
||||
|
||||
**返回结果类型**:与输入字段 `expr` 的原始类型相同。
|
||||
|
||||
|
@ -794,8 +794,8 @@ SUBSTRING/SUBSTR(expr FROM pos [FOR len])
|
|||
- 若 `len` 小于 1,返回空串。
|
||||
- `pos` 是 1-base 的,若 `pos` 为 0,返回空串。
|
||||
- 若 `pos` + `len` 大于 `len(expr)`,返回从 `pos` 开始到字符串结尾的子串,等同于执行 `substring(expr, pos)`。
|
||||
- `SUBSTRING` 函数等价于 `SUBSTR`,从 3.3.3.0 版本开始支持。
|
||||
- `SUBSTRING/SUBSTR(expr FROM pos [FOR len])` 语法从 3.3.3.0 版本开始支持。
|
||||
- `SUBSTRING` 函数等价于 `SUBSTR`,从 v3.3.3.0 开始支持。
|
||||
- `SUBSTRING/SUBSTR(expr FROM pos [FOR len])` 语法从 v3.3.3.0 开始支持。
|
||||
|
||||
**举例**:
|
||||
```sql
|
||||
|
@ -832,12 +832,12 @@ SUBSTRING_INDEX(expr, delim, count)
|
|||
|
||||
**功能说明**:返回字符串 `expr` 在出现指定次数分隔符的位置截取的子串。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:与输入字段 `expr` 的原始类型相同。
|
||||
|
||||
**适用数据类型**:
|
||||
- `expr`:VARCHA、 NCHAR。
|
||||
- `expr`:VARCHAR、NCHAR。
|
||||
- `delim`:VARCHAR、NCHAR。
|
||||
- `count`:INTEGER。
|
||||
|
||||
|
@ -887,18 +887,18 @@ CHAR(expr1 [, expr2] [, epxr3] ...)
|
|||
|
||||
**功能说明**:将输入参数当作整数,并返回这些整数在 ASCII 编码中对应的字符。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:VARCHAR。
|
||||
|
||||
**适用数据类型**:整数类型,VARCHAR,NCHAR。
|
||||
**适用数据类型**:整数类型,VARCHAR、NCHAR。
|
||||
|
||||
**嵌套子查询支持**:适用于内层查询和外层查询。
|
||||
|
||||
**适用于**:表和超级表。
|
||||
|
||||
**使用说明**:
|
||||
- 输入的值超过 255 会被转化成多字节的结果,如 `CHAR(256)` 等同于 `CHAR(1,0)`,`CHAR(256 * 256)` 等同于 `CHAR(1,0,0)`。
|
||||
- 输入的值超过 255 会被转化成多字节的结果,如 `CHAR(256)` 等同于 `CHAR(1,0)`、`CHAR(256 * 256)` 等同于 `CHAR(1,0,0)`。
|
||||
- 输入参数的 NULL 值会被跳过。
|
||||
- 输入参数若为字符串类型,会将其转换为数值类型处理。
|
||||
- 若输入的参数对应的字符为不可打印字符,返回值中仍有该参数对应的字符,但是可能无法显示出来。
|
||||
|
@ -934,7 +934,7 @@ ASCII(expr)
|
|||
|
||||
**功能说明**:返回字符串第一个字符的 ASCII 码。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果数据类型**:BIGINT。
|
||||
|
||||
|
@ -963,7 +963,7 @@ POSITION(expr1 IN expr2)
|
|||
|
||||
**功能说明**:计算字符串 `expr1` 在字符串 `expr2` 中的位置。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:BIGINT。
|
||||
|
||||
|
@ -1007,7 +1007,7 @@ REPLACE(expr, from_str, to_str)
|
|||
```
|
||||
**功能说明**:将字符串中的 `from_str` 全部替换为 `to_str`。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:与输入字段 `expr` 的原始类型相同。
|
||||
|
||||
|
@ -1039,7 +1039,7 @@ REPEAT(expr, count)
|
|||
```
|
||||
**功能说明**:返回将字符串重复指定次数得到的字符串。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:与输入字段 `expr` 的原始类型相同。
|
||||
|
||||
|
@ -1081,7 +1081,7 @@ CAST(expr AS type_name)
|
|||
|
||||
**返回结果类型**:CAST 中指定的类型(type_name)。
|
||||
|
||||
**适用数据类型**:输入参数 expr 的类型可以是除JSON和VARBINARY外的所有类型。如果 type_name 为 VARBINARY,则 expr 只能是 VARCHAR 类型。
|
||||
**适用数据类型**:输入参数 expr 的类型可以是除 JSON 和 VARBINARY 外的所有类型。如果 type_name 为 VARBINARY,则 expr 只能是 VARCHAR 类型。
|
||||
|
||||
**嵌套子查询支持**:适用于内层查询和外层查询。
|
||||
|
||||
|
@ -1091,9 +1091,9 @@ CAST(expr AS type_name)
|
|||
|
||||
- 对于不能支持的类型转换会直接报错。
|
||||
- 对于类型支持但某些值无法正确转换的情况,对应的转换后的值以转换函数输出为准。目前可能遇到的几种情况:
|
||||
1)字符串类型转换数值类型时可能出现的无效字符情况,例如 "a" 可能转为 0,但不会报错。
|
||||
2)转换到数值类型时,数值大于 type_name 可表示的范围时,则会溢出,但不会报错。
|
||||
3)转换到字符串类型时,如果转换后长度超过 type_name 中指定的长度,则会截断,但不会报错。
|
||||
- 字符串类型转换数值类型时可能出现的无效字符情况,例如 "a" 可能转为 0,但不会报错。
|
||||
- 转换到数值类型时,数值大于 type_name 可表示的范围时,则会溢出,但不会报错。
|
||||
- 转换到字符串类型时,如果转换后长度超过 type_name 中指定的长度,则会截断,但不会报错。
|
||||
|
||||
#### TO_ISO8601
|
||||
|
||||
|
@ -1113,8 +1113,8 @@ TO_ISO8601(expr [, timezone])
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- timezone 参数允许输入的时区格式为:[z/Z, +/-hhmm, +/-hh, +/-hh:mm]。例如 TO_ISO8601(1, "+00:00")。
|
||||
- 输入时间戳的精度由所查询表的精度确定,若未指定表,则精度为毫秒。
|
||||
- timezone 参数允许输入的时区格式为:[z/Z, +/-hhmm, +/-hh, +/-hh:mm]。例如,TO_ISO8601(1, "+00:00")。
|
||||
- 输入时间戳的精度由所查询表的精度确定,若未指定表,则精度为毫秒.
|
||||
|
||||
|
||||
#### TO_JSON
|
||||
|
@ -1127,7 +1127,7 @@ TO_JSON(str_literal)
|
|||
|
||||
**返回结果数据类型**:JSON。
|
||||
|
||||
**适用数据类型**:JSON 字符串,形如 '\{ "literal" : literal }'。'\{}' 表示空值。键必须为字符串字面量,值可以为数值字面量、字符串字面量、布尔字面量或空值字面量。str_literal 中不支持转义符。
|
||||
**适用数据类型**:JSON 字符串,形如 '\{ "literal" : literal }'。'\{}'表示空值。键必须为字符串字面量,值可以为数值字面量、字符串字面量、布尔字面量或空值字面量。str_literal 中不支持转义符。
|
||||
|
||||
**嵌套子查询支持**:适用于内层查询和外层查询。
|
||||
|
||||
|
@ -1167,9 +1167,9 @@ return_timestamp: {
|
|||
TO_CHAR(ts, format_str_literal)
|
||||
```
|
||||
|
||||
**功能说明**:将timestamp类型按照指定格式转换为字符串。
|
||||
**功能说明**:将 timestamp 类型按照指定格式转换为字符串。
|
||||
|
||||
**使用说明**:ver-3.2.2.0
|
||||
**使用说明**:vv3.2.2.0
|
||||
|
||||
**返回结果数据类型**:VARCHAR。
|
||||
|
||||
|
@ -1185,16 +1185,16 @@ TO_CHAR(ts, format_str_literal)
|
|||
| ------------------- | ----------------------------------------- | ------------------------- |
|
||||
| AM,am,PM,pm | 无点分隔的上午下午 | 07:00:00am |
|
||||
| A.M.,a.m.,P.M.,p.m. | 有点分隔的上午下午 | 07:00:00a.m. |
|
||||
| YYYY,yyyy | 年,4个及以上数字 | 2023-10-10 |
|
||||
| YYY,yyy | 年,最后3位数字 | 023-10-10 |
|
||||
| YY,yy | 年,最后2位数字 | 23-10-10 |
|
||||
| YYYY,yyyy | 年,4 个及以上数字 | 2023-10-10 |
|
||||
| YYY,yyy | 年,最后 3 位数字 | 023-10-10 |
|
||||
| YY,yy | 年,最后 2 位数字 | 23-10-10 |
|
||||
| Y,y | 年,最后一位数字 | 3-10-10 |
|
||||
| MONTH | 月,全大写 | 2023-JANUARY-01 |
|
||||
| Month | 月,首字母大写 | 2023-January-01 |
|
||||
| month | 月,全小写 | 2023-january-01 |
|
||||
| MON | 月,缩写,全大写(三个字符) | JAN, SEP |
|
||||
| Mon | 月,缩写,首字母大写 | Jan, Sep |
|
||||
| mon | 月,缩写,全小写 | jan, sep |
|
||||
| MON | 月,缩写,全大写(三个字符) | JAN、SEP |
|
||||
| Mon | 月,缩写,首字母大写 | Jan、Sep |
|
||||
| mon | 月,缩写,全小写 | jan、sep |
|
||||
| MM,mm | 月,数字 01-12 | 2023-01-01 |
|
||||
| DD,dd | 月日,01-31 | |
|
||||
| DAY | 周日,全大写 | MONDAY |
|
||||
|
@ -1206,7 +1206,7 @@ TO_CHAR(ts, format_str_literal)
|
|||
| DDD | 年日,001-366 | |
|
||||
| D,d | 周日,数字,1-7,Sunday(1) to Saturday(7) | |
|
||||
| HH24,hh24 | 小时,00-23 | 2023-01-30 23:59:59 |
|
||||
| hh12,HH12, hh, HH | 小时,01-12 | 2023-01-30 12:59:59PM |
|
||||
| hh12,HH12,hh,HH | 小时,01-12 | 2023-01-30 12:59:59PM |
|
||||
| MI,mi | 分钟,00-59 | |
|
||||
| SS,ss | 秒,00-59 | |
|
||||
| MS,ms | 毫秒,000-999 | |
|
||||
|
@ -1215,10 +1215,10 @@ TO_CHAR(ts, format_str_literal)
|
|||
| TZH,tzh | 时区小时 | 2023-01-30 11:59:59PM +08 |
|
||||
|
||||
**使用说明**:
|
||||
- `Month`、`Day` 等的输出格式是左对齐的,右侧添加空格,如 `2023-OCTOBER -01`、`2023-SEPTEMBER-01`,9 月是月份中英文字母数最长的,因此 9 月没有空格。星期类似。
|
||||
- 使用 `ms`、`us`、`ns` 时,以上三种格式的输出只在精度上不同,比如 ts 为 `1697182085123`,`ms` 的输出为 `123`,`us` 的输出为 `123000`,`ns` 的输出为 `123000000`。
|
||||
- `Month`、`Day`等的输出格式是左对齐的,右侧添加空格,如 `2023-OCTOBER -01`、`2023-SEPTEMBER-01`,9 月是月份中英文字母数最长的,因此 9 月没有空格。星期类似。
|
||||
- 使用`ms`、`us`、`ns`时,以上三种格式的输出只在精度上不同,比如 ts 为 `1697182085123`,`ms` 的输出为 `123`,`us` 的输出为 `123000`,`ns` 的输出为 `123000000`。
|
||||
- 时间格式中无法匹配规则的内容会直接输出。如果想要在格式串中指定某些能够匹配规则的部分不做转换,可以使用双引号,如 `to_char(ts, 'yyyy-mm-dd "is formated by yyyy-mm-dd"')`。如果想要输出双引号,那么在双引号之前加一个反斜杠,如 `to_char(ts, '\"yyyy-mm-dd\"')` 将会输出 `"2023-10-10"`。
|
||||
- 那些输出是数字的格式,如 `YYYY`、`DD`,大写与小写意义相同,即 `yyyy` 和 `YYYY` 可以互换。
|
||||
- 那些输出是数字的格式,如`YYYY`、`DD`,大写与小写意义相同,即 `yyyy` 和 `YYYY` 可以互换。
|
||||
- 推荐在时间格式中带时区信息,如果不带则默认输出的时区为服务端或客户端所配置的时区。
|
||||
- 输入时间戳的精度由所查询表的精度确定,若未指定表,则精度为毫秒。
|
||||
|
||||
|
@ -1230,7 +1230,7 @@ TO_TIMESTAMP(ts_str_literal, format_str_literal)
|
|||
|
||||
**功能说明**:将字符串按照指定格式转化为时间戳。
|
||||
|
||||
**使用说明**:ver-3.2.2.0
|
||||
**使用说明**:v3.2.2.0
|
||||
|
||||
**返回结果数据类型**:TIMESTAMP。
|
||||
|
||||
|
@ -1245,7 +1245,7 @@ TO_TIMESTAMP(ts_str_literal, format_str_literal)
|
|||
**使用说明**:
|
||||
- 若 `ms`、`us`、`ns` 同时指定,那么结果时间戳包含上述三个字段的和,如 `to_timestamp('2023-10-10 10:10:10.123.000456.000000789', 'yyyy-mm-dd hh:mi:ss.ms.us.ns')` 输出为 `2023-10-10 10:10:10.123456789`对应的时间戳。
|
||||
- `MONTH`、`MON`、`DAY`、`DY` 以及其他输出为数字的格式的大小写意义相同,如 `to_timestamp('2023-JANUARY-01', 'YYYY-month-dd')`,`month`可以被替换为 `MONTH` 或者 `Month`。
|
||||
- 如果同一字段被指定了多次,那么前面的指定将会被覆盖,如 `to_timestamp('2023-22-10-10', 'yyyy-yy-MM-dd')`,输出年份是`2022`。
|
||||
- 如果同一字段被指定了多次,那么前面的指定将会被覆盖,如 `to_timestamp('2023-22-10-10', 'yyyy-yy-MM-dd')`,输出年份是 `2022`。
|
||||
- 为避免转换时使用了非预期的时区,推荐在时间中携带时区信息,例如 '2023-10-10 10:10:10+08',如果未指定时区则默认时区为服务端或客户端指定的时区。
|
||||
- 如果没有指定完整的时间,那么默认时间值为指定或默认时区的 `1970-01-01 00:00:00`,未指定部分使用该默认值中的对应部分。暂不支持只指定年日而不指定月日的格式,如 'yyyy-mm-DDD',支持'yyyy-mm-DD'。
|
||||
- 如果格式串中有`AM`、`PM`等,那么小时必须是 12 小时制,范围必须是 01-12。
|
||||
|
@ -1293,10 +1293,10 @@ TIMEDIFF(expr1, expr2 [, time_unit])
|
|||
**返回结果类型**:BIGINT。
|
||||
|
||||
**适用数据类型**:
|
||||
- `expr1`:表示时间戳的 BIGIN、 TIMESTAMP 类型,或符合 ISO8601/RFC3339 标准的日期时间格式的 VARCHAR、NCHAR 类型。
|
||||
- `expr1`:表示时间戳的 BIGINT、TIMESTAMP 类型,或符合 ISO8601/RFC3339 标准的日期时间格式的 VARCHAR、NCHAR 类型。
|
||||
- `expr2`:表示时间戳的 BIGINT、TIMESTAMP 类型,或符合 ISO8601/RFC3339 标准的日期时间格式的 VARCHAR、NCHAR 类型。
|
||||
- `time_unit`:见使用说明。
|
||||
- 3.3.3.0 版本之前该函数结果为时间戳 `expr1` 和 `expr2` 的差值的绝对值,结果为正数。
|
||||
- v3.3.3.0 之前该函数结果为时间戳 `expr1` 和 `expr2` 的差值的绝对值,结果为正数。
|
||||
|
||||
**嵌套子查询支持**:适用于内层查询和外层查询。
|
||||
|
||||
|
@ -1351,8 +1351,9 @@ use_current_timezone: {
|
|||
值 0 表示使用 UTC 时区进行截断,值 1 表示使用当前时区进行截断。
|
||||
例如客户端所配置时区为 UTC+0800,则 TIMETRUNCATE('2020-01-01 23:00:00', 1d, 0) 返回结果为东八区时间 '2020-01-01 08:00:00'。
|
||||
而使用 TIMETRUNCATE('2020-01-01 23:00:00', 1d, 1) 时,返回结果为东八区时间 '2020-01-01 00:00:00'。
|
||||
当不指定 use_current_timezone 时,use_current_timezone 默认值为 1 。
|
||||
- 当将时间值截断到一周(1w)时,timetruncate 的计算是基于 Unix 时间戳(1970年1月1日00:00:00 UTC)进行的。Unix 时间戳始于星期四,因此所有截断后的日期都是星期四。
|
||||
当不指定 use_current_timezone 时,use_current_timezone 默认值为 1。
|
||||
- 当将时间值截断到一周(1w)时,timetruncate 的计算是基于 Unix 时间戳(1970年1月1日00:00:00 UTC)进行的。Unix 时间戳始于星期四,
|
||||
因此所有截断后的日期都是星期四。
|
||||
|
||||
|
||||
#### TIMEZONE
|
||||
|
@ -1396,13 +1397,13 @@ WEEK(expr [, mode])
|
|||
```
|
||||
**功能说明**:返回输入日期的周数。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:BIGINT。
|
||||
|
||||
**适用数据类型**:
|
||||
- `expr`:表示时间戳的 BIGINT、TIMESTAMP 类型,或符合 ISO8601/RFC3339 标准的日期时间格式的 VARCHAR、NCHAR 类型。
|
||||
- `mode`:0-7 之间的整数。
|
||||
- `mode`:0 - 7 之间的整数。
|
||||
|
||||
**嵌套子查询支持**:适用于内层查询和外层查询。
|
||||
|
||||
|
@ -1410,8 +1411,8 @@ WEEK(expr [, mode])
|
|||
|
||||
**使用说明**:
|
||||
- 若 `expr` 为 NULL,返回 NULL。
|
||||
- 输入时间戳的精度由所查询表的精度确定,若未指定表,则精度为毫秒。
|
||||
- `mode` 用来指定一周是从周日开始还是周一开始,以及指定返回值范围是 1-53 还是 0-53。下表详细描述不同的 mode 对应的计算方法:
|
||||
- 输入时间戳的精度由所查询表的精度确定,若未指定表,则精度为毫秒.
|
||||
- `mode` 用来指定一周是从周日开始还是周一开始,以及指定返回值范围是 1 - 53 还是 0 - 53。下表详细描述不同的 mode 对应的计算方法:
|
||||
|
||||
| Mode | 每周的第一天 | 返回值范围 | 第 1 周的计算方法 |
|
||||
| ---- | ------ | ------ | ------------------ |
|
||||
|
@ -1423,12 +1424,12 @@ WEEK(expr [, mode])
|
|||
| 5 | 周一 | 0 - 53 | 第一个包含周一的周为第 1 周 |
|
||||
| 6 | 周日 | 1 - 53 | 第一个包含四天及以上的周为第 1 周 |
|
||||
| 7 | 周一 | 1 - 53 | 第一个包含周一的周为第 1 周 |
|
||||
- 当返回值范围为 0-53 时,第 1 周之前的日期为第 0 周。
|
||||
- 当返回值范围为 1-53 时,第 1 周之前的日期为上一年的最后一周。
|
||||
- 以 `2000-01-01` 为例,
|
||||
- 在 `mode=0`时返回值为 `0`,因为该年第一个周日为 `2000-01-02`,从 `2000-01-02` 起才是第一周,所以 `2000-01-01`为第 0 周,返回 0。
|
||||
- 在 `mode=1`时返回值为 `0`,因为 `2000-01-01` 所在的周只有两天,分别是 `2000-01-01(周六)` 和 `2000-01-02(周日)`,所以 `2000-01-03` 起才是第一周,`2000-01-01`为第 0 周,返回 0。
|
||||
- 在 `mode=2`时返回值为 `52`,因为从 `2000-01-02` 起才是第一周,并且返回值范围为 1-53,所以 `2000-01-01` 算做上一年的最后一周,即 1999 年的第 52 周,返回 52。
|
||||
- 当返回值范围为 0 - 53 时,第 1 周之前的日期为第 0 周。
|
||||
- 当返回值范围为 1 - 53 时,第 1 周之前的日期为上一年的最后一周。
|
||||
- 以`2000-01-01`为例,
|
||||
- 在 `mode=0` 时返回值为 `0`,因为该年第一个周日为 `2000-01-02`,从 `2000-01-02` 起才是第 1 周,所以 `2000-01-01` 为第 0 周,返回 0。
|
||||
- 在 `mode=1` 时返回值为 `0`,因为 `2000-01-01` 所在的周只有两天,分别是 `2000-01-01(周六)` 和 `2000-01-02(周日)`,所以 `2000-01-03` 起才是第一周,`2000-01-01`为第 0 周,返回 0。
|
||||
- 在 `mode=2` 时返回值为 `52`,因为从 `2000-01-02` 起才是第 1 周,并且返回值范围为 1-53,所以 `2000-01-01` 算做上一年的最后一周,即 1999 年的第 52 周,返回 52。
|
||||
|
||||
**举例**:
|
||||
```sql
|
||||
|
@ -1459,7 +1460,7 @@ WEEKOFYEAR(expr)
|
|||
```
|
||||
**功能说明**:返回输入日期的周数。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:BIGINT。
|
||||
|
||||
|
@ -1472,7 +1473,7 @@ WEEKOFYEAR(expr)
|
|||
**使用说明**:
|
||||
- 等同于`WEEK(expr, 3)`,即在每周第一天是周一,返回值范围为 1-53,第一个包含四天及以上的周为第 1 周的条件下判断输入日期的周数。
|
||||
- 若 `expr` 为 NULL,返回 NULL。
|
||||
- 输入时间戳的精度由所查询表的精度确定,若未指定表,则精度为毫秒。
|
||||
- 输入时间戳的精度由所查询表的精度确定,未未指定表,则精度为毫秒。
|
||||
|
||||
**举例**:
|
||||
```sql
|
||||
|
@ -1488,11 +1489,11 @@ WEEKDAY(expr)
|
|||
```
|
||||
**功能说明**:返回输入日期是周几。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:BIGINT。
|
||||
|
||||
**适用数据类型**:表示 表示时间戳的 BIGINT、TIMESTAMP 类型,或符合 ISO8601/RFC3339 标准的日期时间格式的 VARCHAR、NCHAR 类型。
|
||||
**适用数据类型**:表示时间戳的 BIGINT、TIMESTAMP 类型,或符合 ISO8601/RFC3339 标准的日期时间格式的 VARCHAR、NCHAR 类型。
|
||||
|
||||
**嵌套子查询支持**:适用于内层查询和外层查询。
|
||||
|
||||
|
@ -1517,7 +1518,7 @@ DAYOFWEEK(expr)
|
|||
```
|
||||
**功能说明**:返回输入日期是周几。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回结果类型**:BIGINT。
|
||||
|
||||
|
@ -1567,9 +1568,9 @@ algo_type: {
|
|||
**适用于**:表和超级表。
|
||||
|
||||
**说明**:
|
||||
- p 值范围是 [0,100],当为 0 时等同于 MIN,为 100 时等同于 MAX。
|
||||
- algo_type 取值为 "default" 或 "t-digest"。输入为 "default" 时函数使用基于直方图算法进行计算。输入为 "t-digest" 时使用t-digest算法计算分位数的近似结果。如果不指定 algo_type 则使用 "default" 算法。
|
||||
- "t-digest" 算法的近似结果对于输入数据顺序敏感,对超级表查询时不同的输入排序结果可能会有微小的误差。
|
||||
- p 值范围是 [0,100],当为 0 时等同 于 MIN,为 100 时等同于 MAX。
|
||||
- algo_type 取值为 "default" 或 "t-digest"。输入为 "default" 时函数使用基于直方图算法进行计算。输入为 "t-digest" 时使用 t-digest 算法计算分位数的近似结果。如果不指定 algo_type 则使用 "default" 算法。
|
||||
- t-digest 算法的近似结果对于输入数据顺序敏感,对超级表查询时不同的输入排序结果可能会有微小的误差。
|
||||
|
||||
### AVG
|
||||
|
||||
|
@ -1602,7 +1603,7 @@ COUNT({* | expr})
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- 可以使用星号(\*)来替代具体的字段,使用星号(\*)返回全部记录数量。
|
||||
- 可以使用星号 (\*) 来替代具体的字段,使用星号 (\*) 返回全部记录数量。
|
||||
- 如果统计字段是具体的列,则返回该列中非 NULL 值的记录数量。
|
||||
|
||||
|
||||
|
@ -1628,7 +1629,7 @@ ELAPSED(ts_primary_key [, time_unit])
|
|||
- order by asc/desc 不影响差值的计算结果。
|
||||
- 对于超级表,需要和 group by tbname 子句组合使用,不可以直接使用。
|
||||
- 对于普通表,不支持和 group by 子句组合使用。
|
||||
- 对于嵌套查询,仅当内层查询会输出隐式时间戳列时有效。例如 select elapsed(ts) from (select diff(value) from sub1) 语句,diff 函数会让内层查询输出隐式时间戳列,此为主键列,可以用于 elapsed 函数的第一个参数。相反,例如 select elapsed(ts) from (select * from sub1) 语句,ts 列输出到外层时已经没有了主键列的含义,无法使用 elapsed 函数。此外,elapsed 函数作为一个与时间线强依赖的函数,形如 select elapsed(ts) from (select diff(value) from st group by tbname)尽 管会返回一条计算结果,但并无实际意义,这种用法后续也将被限制。
|
||||
- 对于嵌套查询,仅当内层查询会输出隐式时间戳列时有效。例如 `select elapsed(ts) from (select diff(value) from sub1)` 语句,diff 函数会让内层查询输出隐式时间戳列,此为主键列,可以用于 elapsed 函数的第一个参数。相反,例如 `select elapsed(ts) from (select * from sub1)` 语句,ts 列输出到外层时已经没有了主键列的含义,无法使用 elapsed 函数。此外,elapsed 函数作为一个与时间线强依赖的函数,形如 `select elapsed(ts) from (select diff(value) from st group by tbname)` 尽管会返回一条计算结果,但并无实际意义,这种用法后续也将被限制。
|
||||
- 不支持与 leastsquares、diff、derivative、top、bottom、last_row、interp 等函数混合使用。
|
||||
|
||||
|
||||
|
@ -1677,7 +1678,7 @@ STDDEV/STDDEV_POP(expr)
|
|||
**适用于**:表和超级表。
|
||||
|
||||
**说明**:
|
||||
- `STDDEV_POP` 函数等价于 `STDDEV` 函数,从 3.3.3.0 版本开始支持。
|
||||
- `STDDEV_POP` 函数等价于 `STDDEV` 函数,从 v3.3.3.0 开始支持。
|
||||
|
||||
**举例**:
|
||||
```sql
|
||||
|
@ -1702,7 +1703,7 @@ VAR_POP(expr)
|
|||
|
||||
**功能说明**:统计表中某列的总体方差。
|
||||
|
||||
**使用说明**:ver-3.3.3.0
|
||||
**版本**:v3.3.3.0
|
||||
|
||||
**返回数据类型**:DOUBLE。
|
||||
|
||||
|
@ -1710,7 +1711,7 @@ VAR_POP(expr)
|
|||
|
||||
**适用于**:表和超级表。
|
||||
|
||||
**举例**:
|
||||
**举例**:
|
||||
```sql
|
||||
taos> select id from test_var;
|
||||
id |
|
||||
|
@ -1749,7 +1750,7 @@ HYPERLOGLOG(expr)
|
|||
|
||||
**功能说明**:
|
||||
- 采用 hyperloglog 算法,返回某列的基数。该算法在数据量很大的情况下,可以明显降低内存的占用,求出来的基数是个估算值,标准误差(标准误差是多次实验,每次的平均数的标准差,不是与真实结果的误差)为 0.81%。
|
||||
- 在数据量较少的时候该算法不是很准确,可以使用 select count(data) from (select unique(col) as data from table) 的方法。
|
||||
- 在数据量较少的时候该算法不是很准确,可以使用 `select count(data) from (select unique(col) as data from table)` 的方法。
|
||||
|
||||
**返回结果类型**:INTEGER。
|
||||
|
||||
|
@ -1779,13 +1780,13 @@ HISTOGRAM(expr,bin_type, bin_description, normalized)
|
|||
用户指定 bin 的具体数值。
|
||||
|
||||
- "linear_bin": "\{"start": 0.0, "width": 5.0, "count": 5, "infinity": true}"
|
||||
"start" 表示数据起始点,"width" 表示每次 bin 偏移量, "count" 为 bin 的总数,"infinity" 表示是否添加(-inf, inf)作为区间起点和终点,
|
||||
"start" 表示数据起始点,"width" 表示每次 bin 偏移量,"count" 为 bin 的总数,"infinity" 表示是否添加(-inf, inf)作为区间起点和终点,
|
||||
生成区间为[-inf, 0.0, 5.0, 10.0, 15.0, 20.0, +inf]。
|
||||
|
||||
- "log_bin": "\{"start":1.0, "factor": 2.0, "count": 5, "infinity": true}"
|
||||
"start" 表示数据起始点,"factor" 表示按指数递增的因子,"count" 为 bin 的总数,"infinity" 表示是否添加(-inf, inf)作为区间起点和终点,
|
||||
生成区间为[-inf, 1.0, 2.0, 4.0, 8.0, 16.0, +inf]。
|
||||
- normalized 是否将返回结果归一化到 0~1 之间 。有效输入为 0 和 1。
|
||||
- normalized 是否将返回结果归一化到 0~1 之间。有效输入为 0 和 1。
|
||||
|
||||
|
||||
### PERCENTILE
|
||||
|
@ -1804,9 +1805,9 @@ PERCENTILE(expr, p [, p1] ... )
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- *P*值取值范围 0≤*P*≤100,为 0 的时候等同于 MIN,为 100 的时候等同于 MAX;
|
||||
- 同时计算针对同一列的多个分位数时,建议使用一个PERCENTILE函数和多个参数的方式,能很大程度上降低查询的响应时间。
|
||||
比如,使用查询SELECT percentile(col, 90, 95, 99) FROM table,性能会优于SELECT percentile(col, 90), percentile(col, 95), percentile(col, 99) from table。
|
||||
- *P* 值取值范围 0≤*P*≤100,为 0 的时候等同于 MIN,为 100 的时候等同于 MAX;
|
||||
- 同时计算针对同一列的多个分位数时,建议使用一个 PERCENTILE 函数和多个参数的方式,能很大程度上降低查询的响应时间。
|
||||
比如,使用查询 `SELECT percentile(col, 90, 95, 99) FROM table`,性能会优于 `SELECT percentile(col, 90), percentile(col, 95), percentile(col, 99) from table`。
|
||||
|
||||
|
||||
## 选择函数
|
||||
|
@ -1829,7 +1830,7 @@ BOTTOM(expr, k)
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- *k*值取值范围 1≤*k*≤100。
|
||||
- *k* 值取值范围 1≤*k*≤100。
|
||||
- 系统同时返回该记录关联的时间戳列。
|
||||
- 限制:BOTTOM 函数不支持 FILL 子句。
|
||||
|
||||
|
@ -1849,8 +1850,8 @@ FIRST(expr)
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- 如果要返回各个列的首个(时间戳最小)非 NULL 值,可以使用 FIRST(\*);查询超级表,且multiResultFunctionStarReturnTags设置为 0 (默认值) 时,FIRST(\*) 只返回超级表的普通列;设置为 1 时,返回超级表的普通列和标签列。
|
||||
- 如果结果集中的某列全部为 NULL 值,则该列的返回结果也是 NULL。
|
||||
- 如果要返回各个列的首个(时间戳最小)非 NULL 值,可以使用 FIRST(\*) 查询超级表,且 multiResultFunctionStarReturnTags 设置为 0 (默认值) 时,FIRST(\*) 只返回超级表的普通列;设置为 1 时,返回超级表的普通列和标签列。
|
||||
- 如果结果集中的某列全部为 NULL 值,则该列的返回结果也是 NULL;
|
||||
- 如果结果集中所有列全部为 NULL 值,则不返回结果。
|
||||
- 对于存在复合主键的表的查询,若最小时间戳的数据有多条,则只有对应的复合主键最小的数据被返回。
|
||||
|
||||
|
@ -1877,18 +1878,18 @@ ignore_null_values: {
|
|||
|
||||
- INTERP 用于在指定时间断面获取指定列的记录值,如果该时间断面不存在符合条件的行数据,那么会根据 FILL 参数的设定进行插值。
|
||||
- INTERP 的输入数据为指定列的数据,可以通过条件语句(where 子句)来对原始列数据进行过滤,如果没有指定过滤条件则输入为全部数据。
|
||||
- INTERP SQL 查询需要同时与 RANGE,EVERY 和 FILL 关键字一起使用;流计算不能使用 RANGE,需要 EVERY 和 FILL 关键字一起使用。
|
||||
- INTERP SQL 查询需要同时与 RANGE、EVERY 和 FILL 关键字一起使用;流计算不能使用 RANGE,需要 EVERY 和 FILL 关键字一起使用。
|
||||
- INTERP 的输出时间范围根据 RANGE(timestamp1, timestamp2) 字段来指定,需满足 timestamp1 \<= timestamp2。其中 timestamp1 为输出时间范围的起始值,即如果 timestamp1 时刻符合插值条件则 timestamp1 为输出的第一条记录,timestamp2 为输出时间范围的结束值,即输出的最后一条记录的 timestamp 不能大于 timestamp2。
|
||||
- INTERP 根据 EVERY(time_unit) 字段来确定输出时间范围内的结果条数,即从 timestamp1 开始每隔固定长度的时间(time_unit 值)进行插值,time_unit 可取值时间单位:1a(毫秒),1s(秒),1m(分),1h(小时),1d(天),1w(周)。例如 EVERY(500a) 将对于指定数据每500毫秒间隔进行一次插值。
|
||||
- INTERP 根据 FILL 字段来决定在每个符合输出条件的时刻如何进行插值。关于 FILL 子句如何使用请参考 [FILL 子句](../distinguished/#fill-子句)
|
||||
- INTERP 可以在 RANGE 字段中只指定唯一的时间戳对单个时间点进行插值,在这种情况下,EVERY 字段可以省略。例如 SELECT INTERP(col) FROM tb RANGE('2023-01-01 00:00:00') FILL(linear)。
|
||||
- INTERP 作用于超级表时,会将该超级表下的所有子表数据按照主键列排序后进行插值计算,也可以搭配 PARTITION BY tbname 使用,将结果强制规约到单个时间线。
|
||||
- INTERP 可以与伪列 _irowts 一起使用,返回插值点所对应的时间戳(3.0.2.0 版本以后支持)。
|
||||
- INTERP 可以与伪列 _isfilled 一起使用,显示返回结果是否为原始记录或插值算法产生的数据(3.0.3.0 版本以后支持)。
|
||||
- INTERP 可以与伪列 _irowts 一起使用,返回插值点所对应的时间戳(v3.0.2.0 以后支持)。
|
||||
- INTERP 可以与伪列 _isfilled 一起使用,显示返回结果是否为原始记录或插值算法产生的数据(v3.0.3.0 以后支持)。
|
||||
- INTERP 对于带复合主键的表的查询,若存在相同时间戳的数据,则只有对应的复合主键最小的数据参与运算。
|
||||
- INTERP 查询支持 NEAR FILL 模式,即当需要 FILL 时,使用距离当前时间点最近的数据进行插值,当前后时间戳与当前时间断面一样近时,FILL 前一行的值。此模式在流计算中和窗口查询中不支持。例如 SELECT INTERP(col) FROM tb RANGE('2023-01-01 00:00:00', '2023-01-01 00:10:00') FILL(NEAR)(3.3.4.9 版本及以后支持)。
|
||||
- INTERP 只有在使用 FILL PREV/NEXT/NEAR 模式时才可以使用伪列 `_irowts_origin`。`_irowts_origin` 在 3.3.4.9 版本及以后支持。
|
||||
- INTERP `RANGE`子句从 3.3.4.9 版本开始支持时间范围的扩展,如 `RANGE('2023-01-01 00:00:00', 10s)` 表示只能使用时间点 '2023-01-01 00:00:00' 周边 10s 内的数据进行插值,FILL PREV/NEXT/NEAR 分别表示从时间点开始向前/向后/前后在时间范围内查找数据,若时间点周边在指定时间范围内没有数据,则使用 FILL 指定的默认值进行插值,因此此时 FILL 子句必须同时指定默认值。例如 SELECT INTERP(col) FROM tb RANGE('2023-01-01 00:00:00', 10s) FILL(PREV, 1)。从 3.3.6.0 版本开始支持时间区间和时间范围的组合,对于时间区间内的每个断面进行插值时都需要满足时间范围的要求,在此之前的版本仅支持时间点和时间范围的组合。时间范围的值域规则与 EVERY 类似,单位不能是年或月,值必须大于 0,不能带引号。使用该扩展时,不支持除 FILL PREV/NEXT/NEAR 外的其他 FILL 模式。
|
||||
- INTERP 查询支持 NEAR FILL 模式,即当需要 FILL 时,使用距离当前时间点最近的数据进行插值,当前后时间戳与当前时间断面一样近时,FILL 前一行的值。此模式在流计算中和窗口查询中不支持。例如 SELECT INTERP(col) FROM tb RANGE('2023-01-01 00:00:00', '2023-01-01 00:10:00') FILL(NEAR)(v3.3.4.9 及以后支持)。
|
||||
- INTERP 只有在使用 FILL PREV/NEXT/NEAR 模式时才可以使用伪列 `_irowts_origin`。`_irowts_origin` 在 v3.3.4.9 以后支持。
|
||||
- INTERP `RANGE`子句从 v3.3.4.9 开始支持时间范围的扩展,如 `RANGE('2023-01-01 00:00:00', 10s)` 表示只能使用时间点 '2023-01-01 00:00:00' 周边 10s 内的数据进行插值,FILL PREV/NEXT/NEAR 分别表示从时间点开始向前/向后/前后在时间范围内查找数据,若时间点周边在指定时间范围内没有数据,则使用 FILL 指定的默认值进行插值,因此此时 FILL 子句必须同时指定默认值。例如 SELECT INTERP(col) FROM tb RANGE('2023-01-01 00:00:00', 10s) FILL(PREV, 1)。从 v3.3.6.0 开始支持时间区间和时间范围的组合,对于时间区间内的每个断面进行插值时都需要满足时间范围的要求,在此之前的版本仅支持时间点和时间范围的组合。时间范围的值域规则与 EVERY 类似,单位不能是年或月,值必须大于 0,不能带引号。使用该扩展时,不支持除 `FILL PREV/NEXT/NEAR` 外的其他 FILL 模式。
|
||||
|
||||
### LAST
|
||||
|
||||
|
@ -1947,7 +1948,7 @@ MAX(expr)
|
|||
**适用于**:表和超级表。
|
||||
|
||||
**使用说明**:
|
||||
- max 函数可以接受字符串作为输入参数,当输入参数为字符串类型时,返回最大的字符串值,从 3.3.3.0 版本开始支持,之前的版本不支持字符串参数。
|
||||
- max 函数可以接受字符串作为输入参数,当输入参数为字符串类型时,返回最大的字符串值,从 v3.3.3.0 开始支持,之前的版本不支持字符串参数。
|
||||
|
||||
### MIN
|
||||
|
||||
|
@ -1964,7 +1965,7 @@ MIN(expr)
|
|||
**适用于**:表和超级表。
|
||||
|
||||
**使用说明**:
|
||||
- min 函数可以接受字符串作为输入参数,当输入参数为字符串类型时,返回最大的字符串值,从 3.3.3.0 版本开始支持,之前的版本不支持字符串参数。
|
||||
- min 函数可以接受字符串作为输入参数,当输入参数为字符串类型时,返回最大的字符串值,从 v3.3.3.0 开始支持,之前的版本不支持字符串参数。
|
||||
|
||||
### MODE
|
||||
|
||||
|
@ -2031,7 +2032,7 @@ TOP(expr, k)
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- *k* 取值范围 1≤*k*≤100。
|
||||
- *k* 值取值范围 1≤*k*≤100。
|
||||
- 系统同时返回该记录关联的时间戳列。
|
||||
- 限制:TOP 函数不支持 FILL 子句。
|
||||
|
||||
|
@ -2055,7 +2056,7 @@ UNIQUE(expr)
|
|||
COLS(func(expr), output_expr1, [, output_expr2] ... )
|
||||
```
|
||||
|
||||
**功能说明**:在选择函数 func(expr) 执行结果所在数据行上,执行表达式 output_expr1, [, output_expr2],返回其结果,func(expr)结果不输出。
|
||||
**功能说明**:在选择函数 func(expr) 执行结果所在数据行上,执行表达式 output_expr1, [, output_expr2],返回其结果,func(expr) 结果不输出。
|
||||
|
||||
**返回数据类型**:返回多列数据,每列数据类型为对应表达式返回结果的类型。
|
||||
|
||||
|
@ -2063,12 +2064,12 @@ COLS(func(expr), output_expr1, [, output_expr2] ... )
|
|||
|
||||
**适用于**:表和超级表。
|
||||
|
||||
**使用说明:**
|
||||
- func 函数类型:必须是单行选择函数(输出结果为一行的选择函数,例如 last 是单行选择函数, 但 top 是多行选择函数)。
|
||||
- 主要用于一个 sql 中获取多个选择函数结果关联列的场景,例如: select cols(max(c0), ts), cols(max(c1), ts) from ...可用于获取 c0, c1 列最大值的不同 ts 值。
|
||||
- 注意, 函数 func 的结果并没有返回,如需输出 func 结果,可额外增加输出列,如: select fist(ts), cols(first(ts), c1) from ...
|
||||
- 输出只有一列时,可以对 cols 函数设置别名。例如: "select cols(first(ts), c1) as c11 from ..."
|
||||
- 输出一列或者多列时,可以对 cols 函数的每个输出列设置命名。例如: "select cols(first(ts), c1 as c11, c2 as c22)"
|
||||
**使用说明**:
|
||||
- func 函数类型:必须是单行选择函数(输出结果为一行的选择函数,例如 last 是单行选择函数,但 top 是多行选择函数)。
|
||||
- 主要用于一个 sql 中获取多个选择函数结果关联列的场景,例如 `select cols(max(c0), ts), cols(max(c1), ts) from ...` 可用于获取 c0、c1 列最大值的不同 ts 值。
|
||||
- 注意,函数 func 的结果并没有返回,如需输出 func 结果,可额外增加输出列,如 `select fist(ts), cols(first(ts), c1) from ...`
|
||||
- 输出只有一列时,可以对 cols 函数设置别名。例如 `select cols(first(ts), c1) as c11 from ...`
|
||||
- 输出一列或者多列时,可以对 cols 函数的每个输出列设置命名。例如 `select cols(first(ts), c1 as c11, c2 as c22)`
|
||||
|
||||
|
||||
## 时序数据特有函数
|
||||
|
@ -2083,7 +2084,7 @@ CSUM(expr)
|
|||
|
||||
**功能说明**:累加和(Cumulative sum),忽略 NULL 值。
|
||||
|
||||
**返回结果类型**:输入列如果是整数类型返回值为长整型 (int64_t),浮点数返回值为双精度浮点数(Double)。无符号整数类型返回值为无符号长整型(uint64_t)。
|
||||
**返回结果类型**:输入列如果是整数类型返回值为长整型(bigint),浮点数返回值为双精度浮点数(double)。无符号整数类型返回值为无符号长整型(unsigned bigint)。
|
||||
|
||||
**适用数据类型**:数值类型。
|
||||
|
||||
|
@ -2118,7 +2119,7 @@ ignore_negative: {
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- 可以与选择相关联的列一起使用,例如 select \_rowts, DERIVATIVE(col1, 1s, 1) from tb1。
|
||||
- 可以与选择相关联的列一起使用。例如 `select \_rowts, DERIVATIVE(col1, 1s, 1) from tb1`。
|
||||
|
||||
### DIFF
|
||||
|
||||
|
@ -2133,14 +2134,14 @@ ignore_option: {
|
|||
}
|
||||
```
|
||||
|
||||
**功能说明**:统计表中特定列与之前行的当前列有效值之差。ignore_option 取值为 0|1|2|3,可以不填,默认值为 0。
|
||||
- `0` 表示不忽略(diff 结果)负值不忽略 null 值
|
||||
- `1` 表示(diff 结果)负值作为 null 值
|
||||
- `2` 表示不忽略(diff 结果)负值但忽略 null 值
|
||||
- `3` 表示忽略(diff 结果)负值且忽略 null 值
|
||||
**功能说明**:统计表中特定列与之前行的当前列有效值之差。ignore_option 取值为 0|1|2|3,可以不填,默认值为 0。
|
||||
- `0` 表示 diff 结果不忽略负值不忽略 null 值
|
||||
- `1` 表示 diff 结果的负值作为 null 值
|
||||
- `2` 表示 diff 结果不忽略负值但忽略 null 值
|
||||
- `3` 表示 diff 结果忽略负值且忽略 null 值
|
||||
- 对于存在复合主键的表的查询,若时间戳相同的数据存在多条,则只有对应的复合主键最小的数据参与运算。
|
||||
|
||||
**返回数据类型**:bool、时间戳及整型数值类型均返回 int64,浮点类型返回 double,若 diff 结果溢出则返回溢出后的值。
|
||||
**返回数据类型**:bool、时间戳及整型数值类型均返回 bigint,浮点类型返回 double,若 diff 结果溢出则返回溢出后的值。
|
||||
|
||||
**适用数据类型**:数值类型、时间戳和 bool 类型。
|
||||
|
||||
|
@ -2152,9 +2153,9 @@ ignore_option: {
|
|||
- 数值类型 diff 结果为对应的算术差值;时间戳类型根据数据库的时间戳精度进行差值计算;bool 类型计算差值时 true 视为 1,false 视为 0。
|
||||
- 如当前行数据为 null 或者没有找到同列前一个有效数据时,diff 结果为 null。
|
||||
- 忽略负值时(ignore_option 设置为 1 或 3 ),如果 diff 结果为负值,则结果设置为 null,然后根据 null 值过滤规则进行过滤。
|
||||
- 当 diff 结果发生溢出时,结果是否是 `应该忽略的负值` 取决于逻辑运算结果是正数还是负数,例如 9223372036854775800 - (-9223372036854775806) 的值超出 BIGINT 的范围 ,diff 结果会显示溢出值 -10,但并不会被作为负值忽略。
|
||||
- 单个语句中可以使用单个或者多个 diff,并且每个 diff 可以指定相同或不同的 ignore_option ,当单个语句中存在多个 diff 时当且仅当某行所有 diff 的结果都为 null ,并且 ignore_option 都设置为忽略 null 值,该行才从结果集中剔除。
|
||||
- 可以选择与相关联的列一起使用。例如 select _rowts, DIFF() from。
|
||||
- 当 diff 结果发生溢出时,结果是否是 `应该忽略的负值` 取决于逻辑运算结果是正数还是负数,例如 9223372036854775800 - (-9223372036854775806) 的值超出 BIGINT 的范围,diff 结果会显示溢出值 -10,但并不会被作为负值忽略。
|
||||
- 单个语句中可以使用单个或者多个 diff,并且每个 diff 可以指定相同或不同的 ignore_option,当单个语句中存在多个 diff 时当且仅当某行所有 diff 的结果都为 null,并且 ignore_option 都设置为忽略 null 值,该行才从结果集中剔除。
|
||||
- 可以选择与相关联的列一起使用。例如 `select _rowts, DIFF() from`。
|
||||
- 当没有复合主键时,如果不同的子表有相同时间戳的数据,会提示 "Duplicate timestamps not allowed"。
|
||||
- 当使用复合主键时,不同子表的时间戳和主键组合可能相同,使用哪一行取决于先找到哪一行,这意味着在这种情况下多次运行 diff() 的结果可能会不同。
|
||||
|
||||
|
@ -2218,7 +2219,7 @@ STATECOUNT(expr, oper, val)
|
|||
|
||||
**使用说明**:
|
||||
|
||||
- 不能和窗口操作一起使用,例如 interval/state_window/session_window。
|
||||
- 不能和窗口操作一起使用,例如 `interval/state_window/session_window`。
|
||||
|
||||
|
||||
### STATEDURATION
|
||||
|
@ -2296,7 +2297,7 @@ SELECT SERVER_VERSION();
|
|||
SELECT SERVER_STATUS();
|
||||
```
|
||||
|
||||
**说明**:检测服务端是否所有 dnode 都在线,如果是则返回成功,否则返回无法建立连接的错误。如果想要查询集群的状态,推荐使用 `SHOW CLUSTER ALIVE;`,与 `SELECT SERVER_STATUS();` 不同,当集群中的部分节点不可用时,它不会返回错误,而是返回不同的状态码,详见:[SHOW CLUSTER ALIVE](https://docs.taosdata.com/reference/taos-sql/show/#show-cluster-alive)
|
||||
**说明**:检测服务端是否所有 dnode 都在线,如果是则返回成功,否则返回无法建立连接的错误。如果想要查询集群的状态,推荐使用 `SHOW CLUSTER ALIVE` 与 `SELECT SERVER_STATUS()` 不同,当集群中的部分节点不可用时,它不会返回错误,而是返回不同的状态码,详见:[SHOW CLUSTER ALIVE](https://docs.taosdata.com/reference/taos-sql/show/#show-cluster-alive)
|
||||
|
||||
### CURRENT_USER
|
||||
|
||||
|
@ -2309,7 +2310,7 @@ SELECT CURRENT_USER();
|
|||
|
||||
## Geometry 函数
|
||||
|
||||
### Geometry 输入函数:
|
||||
### Geometry 输入函数
|
||||
|
||||
#### ST_GeomFromText
|
||||
|
||||
|
@ -2323,7 +2324,7 @@ ST_GeomFromText(VARCHAR WKT expr)
|
|||
|
||||
**适用数据类型**:VARCHAR。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:输入可以是 WKT 字符串之一,例如点(POINT)、线串(LINESTRING)、多边形(POLYGON)、多点集(MULTIPOINT)、多线串(MULTILINESTRING)、多多边形(MULTIPOLYGON)、几何集合(GEOMETRYCOLLECTION)。输出是以二进制字符串形式定义的 GEOMETRY 数据类型。
|
||||
|
||||
|
@ -2341,7 +2342,7 @@ ST_AsText(GEOMETRY geom)
|
|||
|
||||
**适用数据类型**:GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:输出可以是 WKT 字符串之一,例如点(POINT)、线串(LINESTRING)、多边形(POLYGON)、多点集(MULTIPOINT)、多线串(MULTILINESTRING)、多多边形(MULTIPOLYGON)、几何集合(GEOMETRYCOLLECTION)。
|
||||
|
||||
|
@ -2359,7 +2360,7 @@ ST_Intersects(GEOMETRY geomA, GEOMETRY geomB)
|
|||
|
||||
**适用数据类型**:GEOMETRY、GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:如果两个几何对象有任何一个共享点,则它们相交。
|
||||
|
||||
|
@ -2375,7 +2376,7 @@ ST_Equals(GEOMETRY geomA, GEOMETRY geomB)
|
|||
|
||||
**适用数据类型**:GEOMETRY、GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:"空间相等"意味着 ST_Contains(A,B) = true 和 ST_Contains(B,A) = true,并且点的顺序可能不同,但表示相同的几何结构。
|
||||
|
||||
|
@ -2391,7 +2392,7 @@ ST_Touches(GEOMETRY geomA, GEOMETRY geomB)
|
|||
|
||||
**适用数据类型**:GEOMETRY、GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:A 和 B 至少有一个公共点,并且这些公共点位于至少一个边界中。对于点/点输入,关系始终为 FALSE,因为点没有边界。
|
||||
|
||||
|
@ -2407,7 +2408,7 @@ ST_Covers(GEOMETRY geomA, GEOMETRY geomB)
|
|||
|
||||
**适用数据类型**:GEOMETRY、GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:A 包含 B 意味着 B 中的没有点位于 A 的外部(在外部)。
|
||||
|
||||
|
@ -2421,9 +2422,9 @@ ST_Contains(GEOMETRY geomA, GEOMETRY geomB)
|
|||
|
||||
**返回值类型**:BOOL。
|
||||
|
||||
**适用数据类型**:GEOMETRY,GEOMETRY。
|
||||
**适用数据类型**:GEOMETRY、GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:A 包含 B 当且仅当 B 的所有点位于 A 的内部(即位于内部或边界上)(或等效地,B 的没有点位于 A 的外部),并且 A 和 B 的内部至少有一个公共点。
|
||||
|
||||
|
@ -2439,6 +2440,6 @@ ST_ContainsProperly(GEOMETRY geomA, GEOMETRY geomB)
|
|||
|
||||
**适用数据类型**:GEOMETRY、GEOMETRY。
|
||||
|
||||
**适用表类型**:表和超级表。
|
||||
**适用表类型**:标准表和超表。
|
||||
|
||||
**使用说明**:B 的没有点位于 A 的边界或外部。
|
||||
|
|
|
@ -54,9 +54,9 @@ window_clause: {
|
|||
```
|
||||
|
||||
其中,interval_val 和 sliding_val 都表示时间段,interval_offset 表示窗口偏移量,interval_offset 必须小于 interval_val,语法上支持三种方式,举例说明如下:
|
||||
- INTERVAL(1s, 500a) SLIDING(1s), 自带时间单位的形式,其中的时间单位是单字符表示, 分别为: a (毫秒), b (纳秒), d (天), h (小时), m (分钟), n (月), s (秒), u (微秒), w (周), y (年).
|
||||
- INTERVAL(1000, 500) SLIDING(1000), 不带时间单位的形式,将使用查询库的时间精度作为默认时间单位,当存在多个库时默认采用精度更高的库.
|
||||
- INTERVAL('1s', '500a') SLIDING('1s'), 自带时间单位的字符串形式,字符串内部不能有任何空格等其它字符.
|
||||
- `INTERVAL(1s, 500a) SLIDING(1s)` 自带时间单位的形式,其中的时间单位是单字符表示,分别为: a (毫秒)、b (纳秒)、d (天)、h (小时)、m (分钟)、n (月)、s (秒)、u (微秒)、w (周)、y (年)。
|
||||
- `INTERVAL(1000, 500) SLIDING(1000)` 不带时间单位的形式,将使用查询库的时间精度作为默认时间单位,当存在多个库时默认采用精度更高的库。
|
||||
- `INTERVAL('1s', '500a') SLIDING('1s')` 自带时间单位的字符串形式,字符串内部不能有任何空格等其它字符。
|
||||
|
||||
|
||||
### 窗口子句的规则
|
||||
|
@ -76,19 +76,19 @@ window_clause: {
|
|||
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。
|
||||
3. PREV 填充:使用前一个非 NULL 值填充数据。例如:FILL(PREV)。
|
||||
4. NULL 填充:使用 NULL 填充数据。例如:FILL(NULL)。
|
||||
5. LINEAR 填充:根据前后距离最近的非 NULL 值做线性插值填充。例如:FILL(LINEAR)。
|
||||
6. NEXT 填充:使用下一个非 NULL 值填充数据。例如:FILL(NEXT)。
|
||||
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)。
|
||||
6. NEXT 填充:使用下一个非 NULL 值填充数据。例如 FILL(NEXT)。
|
||||
|
||||
以上填充模式中,除了 NONE 模式默认不填充值之外,其他模式在查询的整个时间范围内如果没有数据 FILL 子句将被忽略,即不产生填充数据,查询结果为空。这种行为在部分模式(PREV、NEXT、LINEAR)下具有合理性,因为在这些模式下没有数据意味着无法产生填充数值。而对另外一些模式(NULL、VALUE)来说,理论上是可以产生填充数值的,至于需不需要输出填充数值,取决于应用的需求。所以为了满足这类需要强制填充数据或 NULL 的应用的需求,同时不破坏现有填充模式的行为兼容性,从 3.0.3.0 版本开始,增加了两种新的填充模式:
|
||||
以上填充模式中,除了 NONE 模式默认不填充值之外,其他模式在查询的整个时间范围内如果没有数据 FILL 子句将被忽略,即不产生填充数据,查询结果为空。这种行为在部分模式(PREV、NEXT、LINEAR)下具有合理性,因为在这些模式下没有数据意味着无法产生填充数值。而对另外一些模式(NULL、VALUE)来说,理论上是可以产生填充数值的,至于需不需要输出填充数值,取决于应用的需求。所以为了满足这类需要强制填充数据或 NULL 的应用的需求,同时不破坏现有填充模式的行为兼容性,从 v3.0.3.0 开始,增加了两种新的填充模式:
|
||||
|
||||
7. NULL_F: 强制填充 NULL 值
|
||||
8. VALUE_F: 强制填充 VALUE 值
|
||||
7. NULL_F:强制填充 NULL 值
|
||||
8. VALUE_F:强制填充 VALUE 值
|
||||
|
||||
NULL, NULL_F, VALUE, VALUE_F 这几种填充模式针对不同场景区别如下:
|
||||
- INTERVAL 子句: NULL_F, VALUE_F 为强制填充模式;NULL, VALUE 为非强制模式。在这种模式下下各自的语义与名称相符
|
||||
NULL、NULL_F、VALUE、 VALUE_F 这几种填充模式针对不同场景区别如下:
|
||||
- INTERVAL 子句:NULL_F、VALUE_F 为强制填充模式;NULL、VALUE 为非强制模式。在这种模式下下各自的语义与名称相符
|
||||
- 流计算中的 INTERVAL 子句:NULL_F 与 NULL 行为相同,均为非强制模式;VALUE_F 与 VALUE 行为相同,均为非强制模式。即流计算中的 INTERVAL 没有强制模式
|
||||
- INTERP 子句:NULL 与 NULL_F 行为相同,均为强制模式;VALUE 与 VALUE_F 行为相同,均为强制模式。即 INTERP 中没有非强制模式。
|
||||
|
||||
|
@ -104,7 +104,7 @@ NULL, NULL_F, VALUE, VALUE_F 这几种填充模式针对不同场景区别如下
|
|||
|
||||
时间窗口又可分为滑动时间窗口和翻转时间窗口。
|
||||
|
||||
INTERVAL 子句用于产生相等时间周期的窗口,SLIDING 用以指定窗口向前滑动的时间。每次执行的查询是一个时间窗口,时间窗口随着时间流动向前滑动。在定义连续查询的时候需要指定时间窗口(time window )大小和每次前向增量时间(forward sliding times)。如图,[t0s, t0e] ,[t1s , t1e], [t2s, t2e] 是分别是执行三次连续查询的时间窗口范围,窗口的前向滑动的时间范围 sliding time 标识 。查询过滤、聚合等操作按照每个时间窗口为独立的单位执行。当 SLIDING 与 INTERVAL 相等的时候,滑动窗口即为翻转窗口。
|
||||
INTERVAL 子句用于产生相等时间周期的窗口,SLIDING 用以指定窗口向前滑动的时间。每次执行的查询是一个时间窗口,时间窗口随着时间流动向前滑动。在定义连续查询的时候需要指定时间窗口(time window )大小和每次前向增量时间(forward sliding times)。如图,[t0s, t0e] ,[t1s , t1e],[t2s, t2e] 是分别是执行三次连续查询的时间窗口范围,窗口的前向滑动的时间范围 sliding time 标识 。查询过滤、聚合等操作按照每个时间窗口为独立的单位执行。当 SLIDING 与 INTERVAL 相等的时候,滑动窗口即为翻转窗口。
|
||||
|
||||

|
||||
|
||||
|
@ -139,21 +139,21 @@ SELECT COUNT(*) FROM meters WHERE _rowts - voltage > 1000000;
|
|||
- 使用 INTERVAL 语句时,除非极特殊的情况,都要求把客户端和服务端的 taos.cfg 配置文件中的 timezone 参数配置为相同的取值,以避免时间处理函数频繁进行跨时区转换而导致的严重性能影响。
|
||||
- 返回的结果中时间序列严格单调递增。
|
||||
- 使用 AUTO 作为窗口偏移量时,如果 WHERE 时间条件比较复杂,比如多个 AND/OR/IN 互相组合,那么 AUTO 可能不生效,这种情况可以通过手动指定窗口偏移量进行解决。
|
||||
- 使用 AUTO 作为窗口偏移量时,如果窗口宽度的单位是 d (天), n (月), w (周), y (年),比如: INTERVAL(1d, AUTO), INTERVAL(3w, AUTO),此时 TSMA 优化无法生效。如果目标表上手动创建了TSMA,语句会报错退出;这种情况下,可以显式指定 Hint SKIP_TSMA 或者不使用 AUTO 作为窗口偏移量。
|
||||
- 使用 AUTO 作为窗口偏移量时,如果窗口宽度的单位是 d (天)、n (月)、w (周)、y (年),比如 `INTERVAL(1d, AUTO)`、`INTERVAL(3w, AUTO)`,此时 TSMA 优化无法生效。如果目标表上手动创建了 TSMA,语句会报错退出;这种情况下,可以显式指定 Hint SKIP_TSMA 或者不使用 AUTO 作为窗口偏移量。
|
||||
|
||||
### 状态窗口
|
||||
|
||||
使用整数(布尔值)或字符串来标识产生记录时候设备的状态量。产生的记录如果具有相同的状态量数值则归属于同一个状态窗口,数值改变后该窗口关闭。如下图所示,根据状态量确定的状态窗口分别是[2019-04-28 14:22:07,2019-04-28 14:22:10]和[2019-04-28 14:22:11,2019-04-28 14:22:12]两个。
|
||||
使用整数(布尔值)或字符串来标识产生记录时候设备的状态量。产生的记录如果具有相同的状态量数值则归属于同一个状态窗口,数值改变后该窗口关闭。如下图所示,根据状态量确定的状态窗口分别是 [2019-04-28 14:22:07,2019-04-28 14:22:10] 和 [2019-04-28 14:22:11,2019-04-28 14:22:12] 两个。
|
||||
|
||||

|
||||
|
||||
使用 STATE_WINDOW 来确定状态窗口划分的列。例如:
|
||||
使用 STATE_WINDOW 来确定状态窗口划分的列。例如
|
||||
|
||||
```
|
||||
SELECT COUNT(*), FIRST(ts), status FROM temp_tb_1 STATE_WINDOW(status);
|
||||
```
|
||||
|
||||
仅关心 status 为 2 时的状态窗口的信息。例如:
|
||||
仅关心 status 为 2 时的状态窗口的信息。例如
|
||||
|
||||
```
|
||||
SELECT * FROM (SELECT COUNT(*) AS cnt, FIRST(ts) AS fst, status FROM temp_tb_1 STATE_WINDOW(status)) t WHERE status = 2;
|
||||
|
@ -165,7 +165,7 @@ TDengine 还支持将 CASE 表达式用在状态量,可以表达某个状态
|
|||
SELECT tbname, _wstart, CASE WHEN voltage >= 205 and voltage <= 235 THEN 1 ELSE 0 END status FROM meters PARTITION BY tbname STATE_WINDOW(CASE WHEN voltage >= 205 and voltage <= 235 THEN 1 ELSE 0 END);
|
||||
```
|
||||
|
||||
状态窗口支持使用 TRUE_FOR 参数来设定窗口的最小持续时长。如果某个状态窗口的宽度低于该设定值,则会自动舍弃,不返回任何计算结果。例如,设置最短持续时长为 3s:
|
||||
状态窗口支持使用 TRUE_FOR 参数来设定窗口的最小持续时长。如果某个状态窗口的宽度低于该设定值,则会自动舍弃,不返回任何计算结果。例如,设置最短持续时长为 3s。
|
||||
|
||||
```
|
||||
SELECT COUNT(*), FIRST(ts), status FROM temp_tb_1 STATE_WINDOW(status) TRUE_FOR (3s);
|
||||
|
@ -173,7 +173,7 @@ SELECT COUNT(*), FIRST(ts), status FROM temp_tb_1 STATE_WINDOW(status) TRUE_FOR
|
|||
|
||||
### 会话窗口
|
||||
|
||||
会话窗口根据记录的时间戳主键的值来确定是否属于同一个会话。如下图所示,如果设置时间戳的连续的间隔小于等于 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 秒)。
|
||||
|
||||

|
||||
|
||||
|
@ -186,11 +186,11 @@ SELECT COUNT(*), FIRST(ts) FROM temp_tb_1 SESSION(ts, tol_val);
|
|||
|
||||
### 事件窗口
|
||||
|
||||
事件窗口根据开始条件和结束条件来划定窗口,当start_trigger_condition满足时则窗口开始,直到end_trigger_condition满足时窗口关闭。start_trigger_condition和end_trigger_condition可以是任意 TDengine 支持的条件表达式,且可以包含不同的列。
|
||||
事件窗口根据开始条件和结束条件来划定窗口,当 start_trigger_condition 满足时则窗口开始,直到 end_trigger_condition 满足时窗口关闭。start_trigger_condition 和 end_trigger_condition 可以是任意 TDengine 支持的条件表达式,且可以包含不同的列。
|
||||
|
||||
事件窗口可以仅包含一条数据。即当一条数据同时满足start_trigger_condition和end_trigger_condition,且当前不在一个窗口内时,这条数据自己构成了一个窗口。
|
||||
事件窗口可以仅包含一条数据。即当一条数据同时满足 start_trigger_condition 和 end_trigger_condition,且当前不在一个窗口内时,这条数据自己构成了一个窗口。
|
||||
|
||||
事件窗口无法关闭时,不构成一个窗口,不会被输出。即有数据满足start_trigger_condition,此时窗口打开,但后续数据都不能满足end_trigger_condition,这个窗口无法被关闭,这部分数据不够成一个窗口,不会被输出。
|
||||
事件窗口无法关闭时,不构成一个窗口,不会被输出。即有数据满足 start_trigger_condition,此时窗口打开,但后续数据都不能满足 end_trigger_condition,这个窗口无法被关闭,这部分数据不够成一个窗口,不会被输出。
|
||||
|
||||
如果直接在超级表上进行事件窗口查询,TDengine 会将超级表的数据汇总成一条时间线,然后进行事件窗口的计算。
|
||||
如果需要对子查询的结果集进行事件窗口查询,那么子查询的结果集需要满足按时间线输出的要求,且可以输出有效的时间戳列。
|
||||
|
@ -202,7 +202,7 @@ select _wstart, _wend, count(*) from t event_window start with c1 > 0 end with c
|
|||
|
||||

|
||||
|
||||
事件窗口支持使用 TRUE_FOR 参数来设定窗口的最小持续时长。如果某个事件窗口的宽度低于该设定值,则会自动舍弃,不返回任何计算结果。例如,设置最短持续时长为 3s:
|
||||
事件窗口支持使用 TRUE_FOR 参数来设定窗口的最小持续时长。如果某个事件窗口的宽度低于该设定值,则会自动舍弃,不返回任何计算结果。例如,设置最短持续时长为 3s。
|
||||
|
||||
```
|
||||
select _wstart, _wend, count(*) from t event_window start with c1 > 0 end with c2 < 10 true_for (3s);
|
||||
|
@ -210,7 +210,7 @@ select _wstart, _wend, count(*) from t event_window start with c1 > 0 end with c
|
|||
|
||||
### 计数窗口
|
||||
|
||||
计数窗口按固定的数据行数来划分窗口。默认将数据按时间戳排序,再按照count_val的值,将数据划分为多个窗口,然后做聚合计算。count_val表示每个count window包含的最大数据行数,总数据行数不能整除count_val时,最后一个窗口的行数会小于count_val。sliding_val是常量,表示窗口滑动的数量,类似于 interval的SLIDING。
|
||||
计数窗口按固定的数据行数来划分窗口。默认将数据按时间戳排序,再按照 count_val 的值,将数据划分为多个窗口,然后做聚合计算。count_val 表示每个 count window 包含的最大数据行数,总数据行数不能整除 count_val 时,最后一个窗口的行数会小于 count_val。sliding_val 是常量,表示窗口滑动的数量,类似于 interval 的 SLIDING。
|
||||
|
||||
以下面的 SQL 语句为例,计数窗口切分如图所示:
|
||||
```sql
|
||||
|
@ -223,7 +223,7 @@ select _wstart, _wend, count(*) from t count_window(4);
|
|||
|
||||
### 时间戳伪列
|
||||
|
||||
窗口聚合查询结果中,如果 SQL 语句中没有指定输出查询结果中的时间戳列,那么最终结果中不会自动包含窗口的时间列信息。如果需要在结果中输出聚合结果所对应的时间窗口信息,需要在 SELECT 子句中使用时间戳相关的伪列: 时间窗口起始时间 (\_WSTART), 时间窗口结束时间 (\_WEND), 时间窗口持续时间 (\_WDURATION), 以及查询整体窗口相关的伪列: 查询窗口起始时间(\_QSTART) 和查询窗口结束时间(\_QEND)。需要注意的是时间窗口起始时间和结束时间均是闭区间,时间窗口持续时间是数据当前时间分辨率下的数值。例如,如果当前数据库的时间分辨率是毫秒,那么结果中 500 就表示当前时间窗口的持续时间是 500毫秒 (500 ms)。
|
||||
窗口聚合查询结果中,如果 SQL 语句中没有指定输出查询结果中的时间戳列,那么最终结果中不会自动包含窗口的时间列信息。如果需要在结果中输出聚合结果所对应的时间窗口信息,需要在 SELECT 子句中使用时间戳相关的伪列:时间窗口起始时间 (\_WSTART),时间窗口结束时间 (\_WEND),时间窗口持续时间 (\_WDURATION),以及查询整体窗口相关的伪列:查询窗口起始时间(\_QSTART) 和查询窗口结束时间(\_QEND)。需要注意的是时间窗口起始时间和结束时间均是闭区间,时间窗口持续时间是数据当前时间分辨率下的数值。例如,如果当前数据库的时间分辨率是毫秒,那么结果中 500 就表示当前时间窗口的持续时间是 500毫秒 (500 ms)。
|
||||
|
||||
### 示例
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ TDengine 3.0.0.0 开始对消息队列做了大幅的优化和增强以简化用
|
|||
|
||||
TDengine 创建 topic 的个数上限通过参数 tmqMaxTopicNum 控制,默认 20 个。
|
||||
|
||||
TDengine 使用 SQL 创建一个 topic,共有三种类型的 topic:
|
||||
TDengine 使用 SQL 创建一个 topic,共有三种类型的 topic。
|
||||
|
||||
### 查询 topic
|
||||
|
||||
|
@ -20,12 +20,13 @@ TDengine 使用 SQL 创建一个 topic,共有三种类型的 topic:
|
|||
CREATE TOPIC [IF NOT EXISTS] topic_name as subquery
|
||||
```
|
||||
|
||||
通过 `SELECT` 语句订阅(包括 `SELECT *`,或 `SELECT ts, c1` 等指定查询订阅,可以带条件过滤、标量函数计算,但不支持聚合函数、不支持时间窗口聚合)。需要注意的是:
|
||||
通过 `SELECT` 语句订阅(包括 `SELECT *` 或 `SELECT ts, c1` 等指定查询订阅,可以带条件过滤、标量函数计算,但不支持聚合函数、不支持时间窗口聚合)。需要注意的是:
|
||||
|
||||
- 该类型 TOPIC 一旦创建则订阅数据的结构确定。
|
||||
- 被订阅或用于计算的列或标签不可被删除(`ALTER table DROP`)、修改(`ALTER table MODIFY`)。
|
||||
- 若发生表结构变更,新增的列不出现在结果中。
|
||||
- 对于 select \*,则订阅展开为创建时所有的列(子表、普通表为数据列,超级表为数据列加标签列)
|
||||
- 对于 select \*,则订阅展开为创建时所有的列(子表、普通表为数据列,超级表为数据列加标签列)。
|
||||
|
||||
### 超级表 topic
|
||||
|
||||
语法:
|
||||
|
@ -38,8 +39,8 @@ CREATE TOPIC [IF NOT EXISTS] topic_name [with meta] AS STABLE stb_name [where_co
|
|||
|
||||
- 不会限制用户的表结构变更。
|
||||
- 返回的是非结构化的数据:返回数据的结构会随之超级表的表结构变化而变化。
|
||||
- with meta 参数可选,选择时将返回创建超级表,子表等语句,主要用于taosx做超级表迁移
|
||||
- where_condition 参数可选,选择时将用来过滤符合条件的子表,订阅这些子表。where 条件里不能有普通列,只能是tag或tbname,where条件里可以用函数,用来过滤tag,但是不能是聚合函数,因为子表tag值无法做聚合。也可以是常量表达式,比如 2 > 1(订阅全部子表),或者 false(订阅0个子表)
|
||||
- with meta 参数可选,选择时将返回创建超级表,子表等语句,主要用于 taosX 做超级表迁移。
|
||||
- where_condition 参数可选,选择时将用来过滤符合条件的子表,订阅这些子表。where 条件里不能有普通列,只能是 tag 或 tbname,where 条件里可以用函数,用来过滤 tag,但是不能是聚合函数,因为子表 tag 值无法做聚合。也可以是常量表达式,比如 2 > 1(订阅全部子表),或者 false(订阅 0 个子表)
|
||||
- 返回数据不包含标签。
|
||||
|
||||
### 数据库 topic
|
||||
|
@ -52,9 +53,9 @@ CREATE TOPIC [IF NOT EXISTS] topic_name [with meta] AS DATABASE db_name;
|
|||
|
||||
通过该语句可创建一个包含数据库所有表数据的订阅
|
||||
|
||||
- with meta 参数可选,选择时将返回创建数据库里所有超级表,子表的语句,主要用于taosx做数据库迁移
|
||||
- with meta 参数可选,选择时将返回创建数据库里所有超级表,子表的语句,主要用于 taosX 做数据库迁移。
|
||||
|
||||
说明: 超级表订阅和库订阅属于高级订阅模式,容易出错,如确实要使用,请咨询专业人员。
|
||||
说明:超级表订阅和库订阅属于高级订阅模式,容易出错,如确实要使用,请咨询 TDengine 运维团队。
|
||||
|
||||
## 删除 topic
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@ stream_options: {
|
|||
|
||||
```
|
||||
|
||||
其中 subquery 是 select 普通查询语法的子集:
|
||||
其中 subquery 是 select 普通查询语法的子集。
|
||||
|
||||
```sql
|
||||
subquery: SELECT select_list
|
||||
|
@ -32,7 +32,7 @@ subquery: SELECT select_list
|
|||
|
||||
支持会话窗口、状态窗口、滑动窗口、事件窗口和计数窗口。其中,状态窗口、事件窗口和计数窗口搭配超级表时必须与 partition by tbname 一起使用。对于数据源表是复合主键的流,不支持状态窗口、事件窗口、计数窗口的计算。
|
||||
|
||||
stb_name 是保存计算结果的超级表的表名,如果该超级表不存在,会自动创建;如果已存在,则检查列的schema信息。详见 [写入已存在的超级表](#写入已存在的超级表) 。
|
||||
stb_name 是保存计算结果的超级表的表名,如果该超级表不存在,会自动创建;如果已存在,则检查列的 schema 信息。详见 [写入已存在的超级表](#写入已存在的超级表)。
|
||||
|
||||
TAGS 子句定义了流计算中创建TAG的规则,可以为每个 partition 对应的子表生成自定义的TAG值,详见 [自定义 TAG](#自定义 TAG)
|
||||
```sql
|
||||
|
@ -62,9 +62,9 @@ window_clause: {
|
|||
|
||||
- INTERVAL 是时间窗口,又可分为滑动时间窗口和翻转时间窗口。INTERVAL 子句用于指定窗口相等时间周期,SLIDING 字句用于指定窗口向前滑动的时间。当 interval_val 与 sliding_val 相等的时候,时间窗口即为翻转时间窗口,否则为滑动时间窗口,注意:sliding_val 必须小于等于 interval_val。
|
||||
|
||||
- EVENT_WINDOW 是事件窗口,根据开始条件和结束条件来划定窗口。当 start_trigger_condition 满足时则窗口开始,直到 end_trigger_condition 满足时窗口关闭。 start_trigger_condition 和 end_trigger_condition 可以是任意 TDengine 支持的条件表达式,且可以包含不同的列。
|
||||
- EVENT_WINDOW 是事件窗口,根据开始条件和结束条件来划定窗口。当 start_trigger_condition 满足时则窗口开始,直到 end_trigger_condition 满足时窗口关闭。start_trigger_condition 和 end_trigger_condition 可以是任意 TDengine 支持的条件表达式,且可以包含不同的列。
|
||||
|
||||
- COUNT_WINDOW 是计数窗口,按固定的数据行数来划分窗口。 count_val 是常量,是正整数,必须大于等于2,小于2147483648。 count_val 表示每个 COUNT_WINDOW 包含的最大数据行数,总数据行数不能整除 count_val 时,最后一个窗口的行数会小于 count_val 。 sliding_val 是常量,表示窗口滑动的数量,类似于 INTERVAL 的 SLIDING 。
|
||||
- COUNT_WINDOW 是计数窗口,按固定的数据行数来划分窗口。count_val 是常量,是正整数,必须大于等于 2,小于 2147483648。count_val 表示每个 COUNT_WINDOW 包含的最大数据行数,总数据行数不能整除 count_val 时,最后一个窗口的行数会小于 count_val。sliding_val 是常量,表示窗口滑动的数量,类似于 INTERVAL 的 SLIDING。
|
||||
|
||||
窗口的定义与时序数据特色查询中的定义完全相同,详见 [TDengine 特色查询](../distinguished)
|
||||
|
||||
|
@ -101,13 +101,13 @@ notification_definition 子句定义了窗口计算过程中,在窗口打开/
|
|||
CREATE STREAM avg_vol_s INTO avg_vol SUBTABLE(CONCAT('new-', tname)) AS SELECT _wstart, count(*), avg(voltage) FROM meters PARTITION BY tbname tname INTERVAL(1m);
|
||||
```
|
||||
|
||||
PARTITION 子句中,为 tbname 定义了一个别名 tname, 在 PARTITION 子句中的别名可以用于 SUBTABLE 子句中的表达式计算,在上述示例中,流新创建的子表将以前缀 'new-' 连接原表名作为表名(从 3.2.3.0 版本开始,为了避免 SUBTABLE 中的表达式无法区分各个子表,即误将多个相同时间线写入一个子表,在指定的子表名后面加上 _stableName_groupId)。
|
||||
PARTITION 子句中,为 tbname 定义了一个别名 tname, 在 PARTITION 子句中的别名可以用于 SUBTABLE 子句中的表达式计算,在上述示例中,流新创建的子表将以前缀 'new-' 连接原表名作为表名(从 v3.2.3.0 开始,为了避免 SUBTABLE 中的表达式无法区分各个子表,即误将多个相同时间线写入一个子表,在指定的子表名后面加上 _stableName_groupId)。
|
||||
|
||||
注意,子表名的长度若超过 TDengine 的限制,将被截断。若要生成的子表名已经存在于另一超级表,由于 TDengine 的子表名是唯一的,因此对应新子表的创建以及数据的写入将会失败。
|
||||
|
||||
## 流式计算读取历史数据
|
||||
|
||||
正常情况下,流式计算不会处理创建前已经写入源表中的数据,若要处理已经写入的数据,可以在创建流时设置 fill_history 1 选项,这样创建的流式计算会自动处理创建前、创建中、创建后写入的数据。流计算处理历史数据的最大窗口数是 2000万,超过限制会报错。例如:
|
||||
正常情况下,流式计算不会处理创建前已经写入源表中的数据,若要处理已经写入的数据,可以在创建流时设置 fill_history 1 选项,这样创建的流式计算会自动处理创建前、创建中、创建后写入的数据。流计算处理历史数据的最大窗口数是 2000 万,超过限制会报错。例如:
|
||||
|
||||
```sql
|
||||
create stream if not exists s1 fill_history 1 into st1 as select count(*) from t1 interval(10s)
|
||||
|
@ -151,7 +151,7 @@ SELECT * from information_schema.`ins_streams`;
|
|||
|
||||
在创建流时,可以通过 TRIGGER 指令指定流式计算的触发模式。
|
||||
|
||||
对于非窗口计算,流式计算的触发是实时的;对于窗口计算,目前提供 4 种触发模式,默认为 WINDOW_CLOSE:
|
||||
对于非窗口计算,流式计算的触发是实时的;对于窗口计算,目前提供 4 种触发模式,默认为 WINDOW_CLOSE。
|
||||
|
||||
1. AT_ONCE:写入立即触发
|
||||
|
||||
|
@ -283,7 +283,7 @@ RESUME STREAM [IF EXISTS] [IGNORE UNTREATED] stream_name;
|
|||
没有指定 IF EXISTS,如果该 stream 不存在,则报错,如果存在,则恢复流计算;指定了 IF EXISTS,如果 stream 不存在,则返回成功;如果存在,则恢复流计算。如果指定 IGNORE UNTREATED,则恢复流计算时,忽略流计算暂停期间写入的数据。
|
||||
|
||||
## 状态数据备份与同步
|
||||
流计算的中间结果成为计算的状态数据,需要在流计算整个生命周期中进行持久化保存。为了确保流计算中间状态能够在集群环境下在不同的节点间可靠地同步和迁移,从 3.3.2.1 版本开始,需要在运行环境中部署 rsync 软件,还需要增加以下的步骤:
|
||||
流计算的中间结果成为计算的状态数据,需要在流计算整个生命周期中进行持久化保存。为了确保流计算中间状态能够在集群环境下在不同的节点间可靠地同步和迁移,从 v3.3.2.1 开始,需要在运行环境中部署 rsync 软件,还需要增加以下的步骤:
|
||||
1. 在配置文件中配置 snode 的地址(IP + 端口)和状态数据备份目录(该目录系 snode 所在的物理节点的目录)。
|
||||
2. 然后创建 snode。
|
||||
完成上述两个步骤以后才能创建流。
|
||||
|
@ -300,7 +300,7 @@ RESUME STREAM [IF EXISTS] [IGNORE UNTREATED] stream_name;
|
|||
CREATE SNODE ON DNODE [id]
|
||||
```
|
||||
其中的 id 是集群中的 dnode 的序号。请注意选择的dnode,流计算的中间状态将自动在其上进行备份。
|
||||
从 3.3.4.0 版本开始,在多副本环境中创建流会进行 snode 的**存在性检查**,要求首先创建 snode。如果 snode 不存在,无法创建流。
|
||||
从 v3.3.4.0 开始,在多副本环境中创建流会进行 snode 的**存在性检查**,要求首先创建 snode。如果 snode 不存在,无法创建流。
|
||||
|
||||
## 流式计算的事件通知
|
||||
|
||||
|
|
|
@ -57,7 +57,7 @@ LIKE 条件使用通配符字符串进行匹配检查,规则如下:
|
|||
MATCH/REGEXP 条件和 NMATCH/NOT REGEXP 条件使用正则表达式进行匹配,规则如下:
|
||||
|
||||
- 支持符合 POSIX 规范的正则表达式,具体规范内容可参见 Regular Expressions。
|
||||
- MATCH 和正则表达式匹配时, 返回 TURE. NMATCH 和正则表达式不匹配时, 返回 TRUE.
|
||||
- MATCH 和正则表达式匹配时,返回 TURE。NMATCH 和正则表达式不匹配时,返回 TRUE.
|
||||
- 只能针对子表名(即 tbname)、字符串类型的标签值进行正则表达式过滤,不支持普通列的过滤。
|
||||
- 正则匹配字符串长度不能超过 128 字节。可以通过参数 maxRegexStringLen 设置和调整最大允许的正则匹配字符串,该参数是客户端配置参数,需要重启客户端才能生效
|
||||
|
||||
|
@ -65,7 +65,7 @@ MATCH/REGEXP 条件和 NMATCH/NOT REGEXP 条件使用正则表达式进行匹配
|
|||
|
||||
| # | **运算符** | **支持的类型** | **说明** |
|
||||
| --- | :--------: | -------------- | --------------------------------------------------------------------------- |
|
||||
| 1 | AND | BOOL | 逻辑与,如果两个条件均为 TRUE, 则返回 TRUE。如果任一为 FALSE,则返回 FALSE |
|
||||
| 2 | OR | BOOL | 逻辑或,如果任一条件为 TRUE, 则返回 TRUE。如果两者都是 FALSE,则返回 FALSE |
|
||||
| 1 | AND | BOOL | 逻辑与,如果两个条件均为 TRUE,则返回 TRUE。如果任一为 FALSE,则返回 FALSE |
|
||||
| 2 | OR | BOOL | 逻辑或,如果任一条件为 TRUE,则返回 TRUE。如果两者都是 FALSE,则返回 FALSE |
|
||||
|
||||
TDengine 在计算逻辑条件时,会进行短路径优化,即对于 AND,第一个条件为 FALSE,则不再计算第二个条件,直接返回 FALSE;对于 OR,第一个条件为 TRUE,则不再计算第二个条件,直接返回 TRUE。
|
||||
|
|
|
@ -33,7 +33,7 @@ description: 对 JSON 类型如何使用的详细说明
|
|||
|
||||
## 支持的操作
|
||||
|
||||
1. 在 where 条件中时,支持函数 match/nmatch/between and/like/and/or/is null/is not null,不支持 in
|
||||
1. 在 where 条件中时,支持函数 `match`、`nmatch`、`between and`、`like`、`and`、`or`、`is null`、`is not null`,不支持 `in`
|
||||
|
||||
```
|
||||
select * from s1 where info->'k1' match 'v*';
|
||||
|
@ -47,7 +47,7 @@ description: 对 JSON 类型如何使用的详细说明
|
|||
|
||||
2. 支持 json tag 放在 group by、order by、join 子句、union all 以及子查询中,比如 group by json->'key'
|
||||
|
||||
3. 支持 distinct 操作.
|
||||
3. 支持 distinct 操作
|
||||
|
||||
```
|
||||
select distinct info->'k1' from s1
|
||||
|
@ -69,8 +69,8 @@ description: 对 JSON 类型如何使用的详细说明
|
|||
|
||||
3. json 格式限制:
|
||||
|
||||
1. json 输入字符串可以为空("","\t"," "或 null)或 object,不能为非空的字符串,布尔型和数组。
|
||||
2. object 可为{},如果 object 为{},则整个 json 串记为空。key 可为"",若 key 为"",则 json 串中忽略该 k-v 对。
|
||||
1. json 输入字符串可以为空(""、"\t"、" " 或 null)或 object,不能为非空的字符串,布尔型和数组。
|
||||
2. object 可为 {},如果 object 为 {},则整个 json 串记为空。key 可为 "",若 key 为 "",则 json 串中忽略该 k-v 对。
|
||||
3. value 可以为数字(int/double)或字符串或 bool 或 null,暂不可以为数组。不允许嵌套。
|
||||
4. 若 json 字符串中出现两个相同的 key,则第一个生效。
|
||||
5. json 字符串里暂不支持转义。
|
||||
|
|
|
@ -21,8 +21,8 @@ description: TDengine 中使用转义字符的详细规则
|
|||
## 转义字符使用规则
|
||||
|
||||
1. 标识符里有转义字符(数据库名、表名、列名、别名)
|
||||
1. 普通标识符: 直接提示错误的标识符,因为标识符规定必须是数字、字母和下划线,并且不能以数字开头。
|
||||
2. 反引号``标识符: 保持原样,不转义
|
||||
1. 普通标识符:直接提示错误的标识符,因为标识符规定必须是数字、字母和下划线,并且不能以数字开头。
|
||||
2. 反引号 `` 标识符:保持原样,不转义
|
||||
2. 数据里有转义字符
|
||||
1. 遇到上面定义的转义字符会转义(`%`和`_`见下面说明),如果没有匹配的转义字符会忽略掉转义符`\ `(`\x`保持原样)。
|
||||
2. 对于`%`和`_`,因为在`like`里这两个字符是通配符,所以在模式匹配`like`里用`\%`和`\_`表示字符里本身的`%`和`_`,如果在`like`模式匹配上下文之外使用`\%`或`\_`,则它们的计算结果为字符串`\%`和`\_`,而不是`%`和`_`。
|
||||
1. 遇到上面定义的转义字符会转义(`%`和`_`见下面说明),如果没有匹配的转义字符会忽略掉转义符 `\ `(`\x`保持原样)。
|
||||
2. 对于 `%` 和 `_`,因为在 `like` 里这两个字符是通配符,所以在模式匹配 `like` 里用 `\%` 和 `\_` 表示字符里本身的 `%` 和 `_`,如果在 `like` 模式匹配上下文之外使用 `\%` 或 `\_`,则它们的计算结果为字符串 `\%` 和 `\_`,而不是 `%` 和 `_`。
|
||||
|
|
|
@ -9,13 +9,13 @@ description: 合法字符集和命名中的限制规则
|
|||
1. 合法字符:英文字符、数字和下划线。
|
||||
1. 允许英文字符或下划线开头,不允许以数字开头。
|
||||
1. 不区分大小写。
|
||||
1. 不能是[保留关键字](./20-keywords.md)。
|
||||
1. 不能是 [保留关键字](./20-keywords.md)。
|
||||
1. 转义后表(列)名规则:
|
||||
为了兼容支持更多形式的表(列)名,TDengine 引入新的转义符 "`"。使用转义字符以后:
|
||||
- 不再对转义字符中的内容进行大小写统一,即可以保留用户指定表名中的大小写属性,例如:\`aBc\` 和 \`abc\` 是不同的表(列)名,但是 abc 和 aBc 是相同的表(列)名。
|
||||
- 不再对转义字符中的内容进行大小写统一,即可以保留用户指定表名中的大小写属性,例如 \`aBc\` 和 \`abc\` 是不同的表(列)名,但是 abc 和 aBc 是相同的表(列)名。
|
||||
- 可以创建包含字母、数字和下划线以外字符的表(列)名,例如:\`abc@TD\`,但是转义后名称中仍然不能包含`.`,否则会提示`The table name cannot contain '.'`。
|
||||
- 可以创建以数字开头的表(列)名,例如\`1970\`。
|
||||
- 可以创建以[保留关键字](./20-keywords.md)命名的表(列)名,例如\`select\`。
|
||||
- 可以创建以数字开头的表(列)名,例如 \`1970\`。
|
||||
- 可以创建以 [保留关键字](./20-keywords.md) 命名的表(列)名,例如 \`select\`。
|
||||
|
||||
## 密码合法字符集
|
||||
|
||||
|
@ -27,7 +27,7 @@ description: 合法字符集和命名中的限制规则
|
|||
|
||||
- 数据库名最大长度为 64 字节
|
||||
- 表名最大长度为 192 字节,不包括数据库名前缀和分隔符
|
||||
- 每行数据最大长度 48KB(从 3.0.5.0 版本开始为 64KB) (注意:数据行内每个 BINARY/NCHAR 类型的列还会额外占用 2 个字节的存储位置)
|
||||
- 每行数据最大长度 48KB(从 v3.0.5.0 开始为 64KB)(注意:数据行内每个 BINARY/NCHAR 类型的列还会额外占用 2 个字节的存储位置)
|
||||
- 列名最大长度为 64 字节
|
||||
- 最多允许 4096 列,最少需要 2 列,第一列必须是时间戳。
|
||||
- 标签名最大长度为 64 字节
|
||||
|
|
|
@ -32,9 +32,9 @@ DROP DNODE dnode_id [force] [unsafe]
|
|||
|
||||
注意删除 dnode 不等于停止相应的进程。实际中推荐先将一个 dnode 删除之后再停止其所对应的进程。
|
||||
|
||||
只有在线节点可以被删除。如果要强制删除离线节点,需要执行强制删除操作, 即指定force选项。
|
||||
只有在线节点可以被删除。如果要强制删除离线节点,需要执行强制删除操作, 即指定 force 选项。
|
||||
|
||||
当节点上存在单副本,并且节点处于离线,如果要强制删除该节点,需要执行非安全删除,即制定unsafe,并且数据不可再恢复。
|
||||
当节点上存在单副本,并且节点处于离线,如果要强制删除该节点,需要执行非安全删除,即制定 unsafe,并且数据不可再恢复。
|
||||
|
||||
## 修改数据节点配置
|
||||
|
||||
|
@ -44,27 +44,27 @@ ALTER DNODE dnode_id dnode_option
|
|||
ALTER ALL DNODES dnode_option
|
||||
```
|
||||
|
||||
对于支持动态修改的配置参数,您可以使用 ALTER DNODE 或 ALTER ALL DNODES 语法修改 dnode 中配置参数的值,自 3.3.4.0 后,修改的配置参数将自动持久化,即便数据库服务重启后仍然生效。
|
||||
对于支持动态修改的配置参数,您可以使用 ALTER DNODE 或 ALTER ALL DNODES 语法修改 dnode 中配置参数的值,自 v3.3.4.0 后,修改的配置参数将自动持久化,即便数据库服务重启后仍然生效。
|
||||
|
||||
对于一个配置参数是否支持动态修改,请您参考以下页面:[taosd 参考手册](../01-components/01-taosd.md)
|
||||
对于一个配置参数是否支持动态修改,请您参考 [taosd 参考手册](../01-components/01-taosd.md)
|
||||
|
||||
value 是参数的值,需要是字符格式。如修改 dnode 1 的日志输出级别为 debug:
|
||||
value 是参数的值,需要是字符格式。如修改 dnode 1 的日志输出级别为 debug。
|
||||
|
||||
```sql
|
||||
ALTER DNODE 1 'debugFlag' '143';
|
||||
```
|
||||
|
||||
### 补充说明:
|
||||
配置参数在 dnode 中被分为全局配置参数与局部配置参数,您可以查看 SHOW VARIABLES 或 SHOW DNODE dnode_id VARIABLE 中的 category 字段来确认配置参数属于全局配置参数还是局部配置参数:
|
||||
配置参数在 dnode 中被分为全局配置参数与局部配置参数,您可以查看 SHOW VARIABLES 或 SHOW DNODE dnode_id VARIABLE 中的 category 字段来确认配置参数属于全局配置参数还是局部配置参数。
|
||||
1. 局部配置参数:您可以使用 ALTER DNODE 或 ALTER ALL DNODES 来更新某一个 dnode 或全部 dnodes 的局部配置参数。
|
||||
2. 全局配置参数:全局配置参数要求各个 dnode 保持一致,所以您只可以使用 ALTER ALL DNODES 来更新全部 dnodes 的全局配置参数。
|
||||
|
||||
配置参数是否可以动态修改,有以下三种情况:
|
||||
1. 支持动态修改 立即生效
|
||||
2. 支持动态修改 重启生效
|
||||
1. 支持动态修改,立即生效
|
||||
2. 支持动态修改,重启生效
|
||||
3. 不支持动态修改
|
||||
|
||||
对于重启后生效的配置参数,您可以通过 SHOW VARIABLES 或 SHOW DNODE dnode_id VARIABLE 看到修改后的值,但是需要重启数据库服务才使其生效。
|
||||
对于重启后生效的配置参数,您可以通过 `SHOW VARIABLES` 或 `SHOW DNODE dnode_id VARIABLE` 看到修改后的值,但是需要重启数据库服务才使其生效。
|
||||
|
||||
## 添加管理节点
|
||||
|
||||
|
@ -96,7 +96,7 @@ DROP MNODE ON DNODE dnode_id;
|
|||
CREATE QNODE ON DNODE dnode_id;
|
||||
```
|
||||
|
||||
系统启动默认没有 QNODE,用户可以创建 QNODE 来实现计算和存储的分离。一个 DNODE 上只能创建一个 QNODE。一个 DNODE 的 `supportVnodes` 参数如果不为 0,同时又在其上创建上 QNODE,则在该 dnode 中既有负责存储管理的 vnode 又有负责查询计算的 qnode,如果还在该 dnode 上创建了 mnode,则一个 dnode 上最多三种逻辑节点都可以存在。但通过配置也可以使其彻底分离。将一个 dnode 的`supportVnodes`配置为 0,可以选择在其上创建 mnode 或者 qnode 中的一种,这样可以实现三种逻辑节点在物理上的彻底分离。
|
||||
系统启动默认没有 QNODE,用户可以创建 QNODE 来实现计算和存储的分离。一个 dnode 上只能创建一个 QNODE。一个 dnode 的 `supportVnodes` 参数如果不为 0,同时又在其上创建上 QNODE,则在该 dnode 中既有负责存储管理的 vnode 又有负责查询计算的 qnode,如果还在该 dnode 上创建了 mnode,则一个 dnode 上最多三种逻辑节点都可以存在。但通过配置也可以使其彻底分离。将一个 dnode 的`supportVnodes`配置为 0,可以选择在其上创建 mnode 或者 qnode 中的一种,这样可以实现三种逻辑节点在物理上的彻底分离。
|
||||
|
||||
## 查看查询节点
|
||||
|
||||
|
@ -104,7 +104,7 @@ CREATE QNODE ON DNODE dnode_id;
|
|||
SHOW QNODES;
|
||||
```
|
||||
|
||||
列出集群中所有查询节点,包括 ID,及所在 DNODE。
|
||||
列出集群中所有查询节点,包括 ID,及所在 dnode
|
||||
|
||||
## 删除查询节点
|
||||
|
||||
|
@ -112,7 +112,7 @@ SHOW QNODES;
|
|||
DROP QNODE ON DNODE dnode_id;
|
||||
```
|
||||
|
||||
删除 ID 为 dnode_id 的 DNODE 上的 QNODE,但并不会影响该 dnode 的状态。
|
||||
删除 ID 为 dnode_id 的 dnode 上的 qnode,但并不会影响该 dnode 的状态。
|
||||
|
||||
## 查询集群状态
|
||||
|
||||
|
@ -120,7 +120,10 @@ DROP QNODE ON DNODE dnode_id;
|
|||
SHOW CLUSTER ALIVE;
|
||||
```
|
||||
|
||||
查询当前集群的状态是否可用,返回值: 0:不可用 1:完全可用 2:部分可用(集群中部分节点下线,但其它节点仍可以正常使用)
|
||||
查询当前集群的状态是否可用,返回值
|
||||
- 0:不可用
|
||||
- 1:完全可用
|
||||
- 2:部分可用(集群中部分节点下线,但其它节点仍可以正常使用)
|
||||
|
||||
## 修改客户端配置
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ title: 元数据
|
|||
description: Information_Schema 数据库中存储了系统中所有的元数据信息
|
||||
---
|
||||
|
||||
TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数据库元数据、数据库系统信息和状态的访问,例如数据库或表的名称,当前执行的 SQL 语句等。该数据库存储有关 TDengine 维护的所有其他数据库的信息。它包含多个只读表。实际上,这些表都是视图,而不是基表,因此没有与它们关联的文件。所以对这些表只能查询,不能进行 INSERT 等写入操作。`INFORMATION_SCHEMA` 数据库旨在以一种更一致的方式来提供对 TDengine 支持的各种 SHOW 语句(如 SHOW TABLES、SHOW DATABASES)所提供的信息的访问。与 SHOW 语句相比,使用 SELECT ... FROM INFORMATION_SCHEMA.tablename 具有以下优点:
|
||||
TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数据库元数据、数据库系统信息和状态的访问,例如数据库或表的名称,当前执行的 SQL 语句等。该数据库存储有关 TDengine 维护的所有其他数据库的信息。它包含多个只读表。实际上,这些表都是视图,而不是基表,因此没有与它们关联的文件。所以对这些表只能查询,不能进行 INSERT 等写入操作。`INFORMATION_SCHEMA` 数据库旨在以一种更一致的方式来提供对 TDengine 支持的各种 SHOW 语句(如 SHOW TABLES、SHOW DATABASES)所提供的信息的访问。与 SHOW 语句相比,使用 `SELECT ... FROM INFORMATION_SCHEMA.tablename` 具有以下优点。
|
||||
|
||||
1. 可以使用 USE 语句将 INFORMATION_SCHEMA 设为默认数据库
|
||||
2. 可以使用 SELECT 语句熟悉的语法,只需要学习一些表名和列名
|
||||
|
@ -15,7 +15,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
:::info
|
||||
|
||||
- 由于 SHOW 语句已经被开发者熟悉和广泛使用,所以它们仍然被保留。
|
||||
- 系统表中的一些列可能是关键字,在查询时需要使用转义符'\`',例如查询数据库 test 有几个 VGROUP:
|
||||
- 系统表中的一些列可能是关键字,在查询时需要使用转义符 '\`',例如查询数据库 test 有几个 VGROUP。
|
||||
```sql
|
||||
select `vgroups` from ins_databases where name = 'test';
|
||||
```
|
||||
|
@ -26,11 +26,11 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
|
||||
## INS_DNODES
|
||||
|
||||
提供 dnode 的相关信息。也可以使用 SHOW DNODES 来查询这些信息。 SYSINFO 为 0 的用户不能查看此表。
|
||||
提供 dnode 的相关信息。也可以使用 SHOW DNODES 来查询这些信息。SYSINFO 为 0 的用户不能查看此表。
|
||||
|
||||
| # | **列名** | **数据类型** | **说明** |
|
||||
| --- | :------------: | ------------ | ----------------------------------------------------------------------------------------------------- |
|
||||
| 1 | vnodes | SMALLINT | dnode 中的实际 vnode 个数。需要注意,`vnodes` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 1 | vnodes | SMALLINT | dnode 中的实际 vnode 个数。需要注意,`vnodes` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 2 | support_vnodes | SMALLINT | 最多支持的 vnode 个数 |
|
||||
| 3 | status | BINARY(10) | 当前状态 |
|
||||
| 4 | note | BINARY(256) | 离线原因等信息 |
|
||||
|
@ -40,7 +40,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
|
||||
## INS_MNODES
|
||||
|
||||
提供 mnode 的相关信息。也可以使用 SHOW MNODES 来查询这些信息。 SYSINFO 为 0 的用户不能查看此表。
|
||||
提供 mnode 的相关信息。也可以使用 SHOW MNODES 来查询这些信息。SYSINFO 为 0 的用户不能查看此表。
|
||||
|
||||
| # | **列名** | **数据类型** | **说明** |
|
||||
| --- | :---------: | ------------ | ------------------ |
|
||||
|
@ -73,7 +73,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
|
||||
## INS_CLUSTER
|
||||
|
||||
存储集群相关信息。 SYSINFO 属性为 0 的用户不能查看此表。
|
||||
存储集群相关信息。SYSINFO 属性为 0 的用户不能查看此表。
|
||||
|
||||
| # | **列名** | **数据类型** | **说明** |
|
||||
| --- | :---------: | ------------ | ---------- |
|
||||
|
@ -90,31 +90,31 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 1 | name | VARCHAR(64) | 数据库名 |
|
||||
| 2 | create_time | TIMESTAMP | 创建时间 |
|
||||
| 3 | ntables | INT | 数据库中表的数量,包含子表和普通表但不包含超级表 |
|
||||
| 4 | vgroups | INT | 数据库中有多少个 vgroup。需要注意,`vgroups` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 6 | replica | INT | 副本数。需要注意,`replica` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 4 | vgroups | INT | 数据库中有多少个 vgroup。需要注意,`vgroups` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 6 | replica | INT | 副本数。需要注意,`replica` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 7 | strict | VARCHAR(4) | 废弃参数 |
|
||||
| 8 | duration | VARCHAR(10) | 单文件存储数据的时间跨度。需要注意,`duration` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。内部存储单位为分钟,查询时有可能转换为天或小时展示 |
|
||||
| 9 | keep | VARCHAR(32) | 数据保留时长。需要注意,`keep` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 内部存储单位为分钟,查询时有可能转换为天或小时展示 |
|
||||
| 10 | buffer | INT | 每个 vnode 写缓存的内存块大小,单位 MB。需要注意,`buffer` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 11 | pagesize | INT | 每个 VNODE 中元数据存储引擎的页大小,单位为 KB。需要注意,`pagesize` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 12 | pages | INT | 每个 vnode 元数据存储引擎的缓存页个数。需要注意,`pages` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 13 | minrows | INT | 文件块中记录的最小条数。需要注意,`minrows` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 14 | maxrows | INT | 文件块中记录的最大条数。需要注意,`maxrows` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 15 | comp | INT | 数据压缩方式。需要注意,`comp` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 16 | precision | VARCHAR(2) | 时间分辨率。需要注意,`precision` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 9 | keep | VARCHAR(32) | 数据保留时长。需要注意,`keep` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 内部存储单位为分钟,查询时有可能转换为天或小时展示 |
|
||||
| 10 | buffer | INT | 每个 vnode 写缓存的内存块大小,单位 MB。需要注意,`buffer` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 11 | pagesize | INT | 每个 VNODE 中元数据存储引擎的页大小,单位为 KB。需要注意,`pagesize` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 12 | pages | INT | 每个 vnode 元数据存储引擎的缓存页个数。需要注意,`pages` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 13 | minrows | INT | 文件块中记录的最小条数。需要注意,`minrows` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 14 | maxrows | INT | 文件块中记录的最大条数。需要注意,`maxrows` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 15 | comp | INT | 数据压缩方式。需要注意,`comp` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 16 | precision | VARCHAR(2) | 时间分辨率。需要注意,`precision` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 17 | status | VARCHAR(10) | 数据库状态 |
|
||||
| 18 | retentions | VARCHAR(60) | 数据的聚合周期和保存时长。需要注意,`retentions` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 19 | single_stable | BOOL | 表示此数据库中是否只可以创建一个超级表。需要注意,`single_stable` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 20 | cachemodel | VARCHAR(60) | 表示是否在内存中缓存子表的最近数据。需要注意,`cachemodel` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 21 | cachesize | INT | 表示每个 vnode 中用于缓存子表最近数据的内存大小。需要注意,`cachesize` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 22 | wal_level | INT | WAL 级别。需要注意,`wal_level` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 23 | wal_fsync_period | INT | 数据落盘周期。需要注意,`wal_fsync_period` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 24 | wal_retention_period | INT | WAL 的保存时长,单位为秒。需要注意,`wal_retention_period` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 25 | wal_retention_size | INT | WAL 的保存上限。需要注意,`wal_retention_size` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 26 | stt_trigger | SMALLINT | 触发文件合并的落盘文件的个数。需要注意,`stt_trigger` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 27 | table_prefix | SMALLINT | 内部存储引擎根据表名分配存储该表数据的 VNODE 时要忽略的前缀的长度。需要注意,`table_prefix` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 28 | table_suffix | SMALLINT | 内部存储引擎根据表名分配存储该表数据的 VNODE 时要忽略的后缀的长度。需要注意,`table_suffix` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 29 | tsdb_pagesize | INT | 时序数据存储引擎中的页大小。需要注意,`tsdb_pagesize` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 18 | retentions | VARCHAR(60) | 数据的聚合周期和保存时长。需要注意,`retentions` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 19 | single_stable | BOOL | 表示此数据库中是否只可以创建一个超级表。需要注意,`single_stable` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 20 | cachemodel | VARCHAR(60) | 表示是否在内存中缓存子表的最近数据。需要注意,`cachemodel` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 21 | cachesize | INT | 表示每个 vnode 中用于缓存子表最近数据的内存大小。需要注意,`cachesize` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 22 | wal_level | INT | WAL 级别。需要注意,`wal_level` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 23 | wal_fsync_period | INT | 数据落盘周期。需要注意,`wal_fsync_period` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 24 | wal_retention_period | INT | WAL 的保存时长,单位为秒。需要注意,`wal_retention_period` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 25 | wal_retention_size | INT | WAL 的保存上限。需要注意,`wal_retention_size` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 26 | stt_trigger | SMALLINT | 触发文件合并的落盘文件的个数。需要注意,`stt_trigger` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 27 | table_prefix | SMALLINT | 内部存储引擎根据表名分配存储该表数据的 VNODE 时要忽略的前缀的长度。需要注意,`table_prefix` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 28 | table_suffix | SMALLINT | 内部存储引擎根据表名分配存储该表数据的 VNODE 时要忽略的后缀的长度。需要注意,`table_suffix` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 29 | tsdb_pagesize | INT | 时序数据存储引擎中的页大小。需要注意,`tsdb_pagesize` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
|
||||
## INS_FUNCTIONS
|
||||
|
||||
|
@ -123,15 +123,15 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| # | **列名** | **数据类型** | **说明** |
|
||||
| --- | :-----------: | ------------- | --------------------------------------------------------------------------------------------- |
|
||||
| 1 | name | VARCHAR(64) | 函数名 |
|
||||
| 2 | comment | VARCHAR(255) | 补充说明。需要注意,`comment` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 3 | aggregate | INT | 是否为聚合函数。需要注意,`aggregate` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 2 | comment | VARCHAR(255) | 补充说明。需要注意,`comment` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 3 | aggregate | INT | 是否为聚合函数。需要注意,`aggregate` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 4 | output_type | VARCHAR(31) | 输出类型 |
|
||||
| 5 | create_time | TIMESTAMP | 创建时间 |
|
||||
| 6 | code_len | INT | 代码长度 |
|
||||
| 7 | bufsize | INT | buffer 大小 |
|
||||
| 8 | func_language | VARCHAR(31) | 自定义函数编程语言 |
|
||||
| 9 | func_body | VARCHAR(16384) | 函数体定义 |
|
||||
| 10 | func_version | INT | 函数版本号。初始版本为0,每次替换更新,版本号加1。 |
|
||||
| 10 | func_version | INT | 函数版本号。初始版本为0,每次替换更新,版本号加1。 |
|
||||
|
||||
|
||||
## INS_INDEXES
|
||||
|
@ -145,7 +145,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 3 | index_name | VARCHAR(192) | 索引名 |
|
||||
| 4 | column_name | VARCHAR(64) | 建索引的列的列名 |
|
||||
| 5 | index_type | VARCHAR(10) | 目前有 SMA 和 tag |
|
||||
| 6 | index_extensions | VARCHAR(256) | 索引的额外信息。对 SMA/tag 类型的索引,是函数名的列表。 |
|
||||
| 6 | index_extensions | VARCHAR(256) | 索引的额外信息。对 SMA/tag 类型的索引,是函数名的列表。|
|
||||
|
||||
## INS_STABLES
|
||||
|
||||
|
@ -157,12 +157,12 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 2 | db_name | VARCHAR(64) | 超级表所在的数据库的名称 |
|
||||
| 3 | create_time | TIMESTAMP | 创建时间 |
|
||||
| 4 | columns | INT | 列数目 |
|
||||
| 5 | tags | INT | 标签数目。需要注意,`tags` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 5 | tags | INT | 标签数目。需要注意,`tags` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 6 | last_update | TIMESTAMP | 最后更新时间 |
|
||||
| 7 | table_comment | VARCHAR(1024) | 表注释 |
|
||||
| 8 | watermark | VARCHAR(64) | 窗口的关闭时间。需要注意,`watermark` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 9 | max_delay | VARCHAR(64) | 推送计算结果的最大延迟。需要注意,`max_delay` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 10 | rollup | VARCHAR(128) | rollup 聚合函数。需要注意,`rollup` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 8 | watermark | VARCHAR(64) | 窗口的关闭时间。需要注意,`watermark` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 9 | max_delay | VARCHAR(64) | 推送计算结果的最大延迟。需要注意,`max_delay` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 10 | rollup | VARCHAR(128) | rollup 聚合函数。需要注意,`rollup` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
|
||||
## INS_TABLES
|
||||
|
||||
|
@ -177,7 +177,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 5 | stable_name | VARCHAR(192) | 所属的超级表表名 |
|
||||
| 6 | uid | BIGINT | 表 id |
|
||||
| 7 | vgroup_id | INT | vgroup id |
|
||||
| 8 | ttl | INT | 表的生命周期。需要注意,`ttl` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 8 | ttl | INT | 表的生命周期。需要注意 `ttl` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 9 | table_comment | VARCHAR(1024) | 表注释 |
|
||||
| 10 | type | VARCHAR(21) | 表类型 |
|
||||
|
||||
|
@ -215,7 +215,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 1 | name | VARCHAR(24) | 用户名 |
|
||||
| 2 | super | TINYINT | 用户是否为超级用户,1:是,0:否 |
|
||||
| 3 | enable | TINYINT | 用户是否启用,1:是,0:否 |
|
||||
| 4 | sysinfo | TINYINT | 用户是否可查看系统信息,1:是, 0:否 |
|
||||
| 4 | sysinfo | TINYINT | 用户是否可查看系统信息,1:是,0:否 |
|
||||
| 5 | create_time | TIMESTAMP | 创建时间 |
|
||||
| 6 | allowed_host | VARCHAR(49152)| IP 白名单 |
|
||||
|
||||
|
@ -227,13 +227,13 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| --- | :---------: | ------------ | --------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | version | VARCHAR(9) | 企业版授权说明:official(官方授权的)/trial(试用的) |
|
||||
| 2 | cpu_cores | VARCHAR(9) | 授权使用的 CPU 核心数量 |
|
||||
| 3 | dnodes | VARCHAR(10) | 授权使用的 dnode 节点数量。需要注意,`dnodes` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 4 | streams | VARCHAR(10) | 授权创建的流数量。需要注意,`streams` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 5 | users | VARCHAR(10) | 授权创建的用户数量。需要注意,`users` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 6 | accounts | VARCHAR(10) | 授权创建的帐户数量。需要注意,`accounts` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 7 | storage | VARCHAR(21) | 授权使用的存储空间大小。需要注意,`storage` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 8 | connections | VARCHAR(21) | 授权使用的客户端连接数量。需要注意,`connections` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 9 | databases | VARCHAR(11) | 授权使用的数据库数量。需要注意,`databases` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 3 | dnodes | VARCHAR(10) | 授权使用的 dnode 节点数量。需要注意,`dnodes` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 4 | streams | VARCHAR(10) | 授权创建的流数量。需要注意,`streams` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 5 | users | VARCHAR(10) | 授权创建的用户数量。需要注意,`users` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 6 | accounts | VARCHAR(10) | 授权创建的帐户数量。需要注意,`accounts` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 7 | storage | VARCHAR(21) | 授权使用的存储空间大小。需要注意,`storage` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 8 | connections | VARCHAR(21) | 授权使用的客户端连接数量。需要注意,`connections` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 9 | databases | VARCHAR(11) | 授权使用的数据库数量。需要注意,`databases` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 10 | speed | VARCHAR(9) | 授权使用的数据点每秒写入数量 |
|
||||
| 11 | querytime | VARCHAR(9) | 授权使用的查询总时长 |
|
||||
| 12 | timeseries | VARCHAR(21) | 授权使用的测点数量 |
|
||||
|
@ -248,7 +248,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| --- | :-------: | ------------ | ------------------------------------------------------------------------------------------------ |
|
||||
| 1 | vgroup_id | INT | vgroup id |
|
||||
| 2 | db_name | VARCHAR(32) | 数据库名 |
|
||||
| 3 | tables | INT | 此 vgroup 内有多少表。需要注意,`tables` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 3 | tables | INT | 此 vgroup 内有多少表。需要注意,`tables` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
| 4 | status | VARCHAR(10) | 此 vgroup 的状态 |
|
||||
| 5 | v1_dnode | INT | 第一个成员所在的 dnode 的 id |
|
||||
| 6 | v1_status | VARCHAR(10) | 第一个成员的状态 |
|
||||
|
@ -258,7 +258,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 10 | v3_status | VARCHAR(10) | 第三个成员的状态 |
|
||||
| 11 | nfiles | INT | 此 vgroup 中数据/元数据文件的数量 |
|
||||
| 12 | file_size | INT | 此 vgroup 中数据/元数据文件的大小 |
|
||||
| 13 | tsma | TINYINT | 此 vgroup 是否专用于 Time-range-wise SMA,1: 是, 0: 否 |
|
||||
| 13 | tsma | TINYINT | 此 vgroup 是否专用于 Time-range-wise SMA,1: 是,0: 否 |
|
||||
|
||||
## INS_CONFIGS
|
||||
|
||||
|
@ -267,7 +267,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| # | **列名** | **数据类型** | **说明** |
|
||||
| --- | :------: | ------------ | --------------------------------------------------------------------------------------- |
|
||||
| 1 | name | VARCHAR(32) | 配置项名称 |
|
||||
| 2 | value | VARCHAR(64) | 该配置项的值。需要注意,`value` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 2 | value | VARCHAR(64) | 该配置项的值。需要注意,`value` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
|
||||
## INS_DNODE_VARIABLES
|
||||
|
||||
|
@ -277,7 +277,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| --- | :------: | ------------ | --------------------------------------------------------------------------------------- |
|
||||
| 1 | dnode_id | INT | dnode 的 ID |
|
||||
| 2 | name | VARCHAR(32) | 配置项名称 |
|
||||
| 3 | value | VARCHAR(64) | 该配置项的值。需要注意,`value` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 3 | value | VARCHAR(64) | 该配置项的值。需要注意,`value` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
|
||||
## INS_TOPICS
|
||||
|
||||
|
@ -312,7 +312,7 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
| 5 | source_db | VARCHAR(64) | 源数据库 |
|
||||
| 6 | target_db | VARCHAR(64) | 目的数据库 |
|
||||
| 7 | target_table | VARCHAR(192) | 流计算写入的目标表 |
|
||||
| 8 | watermark | BIGINT | watermark,详见 SQL 手册流式计算。需要注意,`watermark` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 8 | watermark | BIGINT | watermark,详见 SQL 手册流式计算。需要注意,`watermark` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。 |
|
||||
| 9 | trigger | INT | 计算结果推送模式,详见 SQL 手册流式计算。需要注意,`trigger` 为 TDengine 关键字,作为列名使用时需要使用 ` 进行转义。|
|
||||
|
||||
## INS_USER_PRIVILEGES
|
||||
|
@ -333,14 +333,14 @@ TDengine 内置了一个名为 `INFORMATION_SCHEMA` 的数据库,提供对数
|
|||
|:----|:-----------|:------------|:--------|
|
||||
| 1 | db_name | VARCHAR(32) | 数据库名称 |
|
||||
| 2 | vgroup_id | INT | vgroup 的 ID |
|
||||
| 3 | wal | BIGINT | wal 文件大小, 单位为 K |
|
||||
| 4 | data1 | BIGINT | 一级存储上数据文件的大小,单位为KB |
|
||||
| 5 | data2 | BIGINT | 二级存储上数据文件的大小,单位为 KB |
|
||||
| 6 | data3 | BIGINT | 三级存储上数据文件的大小, 单位为KB |
|
||||
| 7 | cache_rdb | BIGINT | last/last_row 文件的大小,单位为KB |
|
||||
| 8 | table_meta | BIGINT | meta 文件的大小, 单位为KB |
|
||||
| 9 | s3 | BIGINT | s3 上占用的大小, 单位为KB |
|
||||
| 10 | raw_data | BIGINT | 预估的原始数据的大小, 单位为KB |
|
||||
| 3 | wal | BIGINT | wal 文件大小,单位为 KB |
|
||||
| 4 | data1 | BIGINT | 一级存储上数据文件的大小,单位为 KB |
|
||||
| 5 | data2 | BIGINT | 二级存储上数据文件的大小,单位为 KB |
|
||||
| 6 | data3 | BIGINT | 三级存储上数据文件的大小,单位为 KB |
|
||||
| 7 | cache_rdb | BIGINT | last/last_row 文件的大小,单位为 KB |
|
||||
| 8 | table_meta | BIGINT | meta 文件的大小,单位为 KB |
|
||||
| 9 | s3 | BIGINT | s3 上占用的大小,单位为 KB |
|
||||
| 10 | raw_data | BIGINT | 预估的原始数据的大小,单位为 KB |
|
||||
|
||||
|
||||
## INS_FILESETS
|
||||
|
|
|
@ -14,7 +14,7 @@ TDengine 3.0 版本开始提供一个内置数据库 `performance_schema`,其
|
|||
| --- | :----------: | ------------ | ------------------------------- |
|
||||
| 1 | app_id | UBIGINT | 客户端 ID |
|
||||
| 2 | ip | BINARY(16) | 客户端地址 |
|
||||
| 3 | pid | INT | 客户端进程 号 |
|
||||
| 3 | pid | INT | 客户端进程号 |
|
||||
| 4 | name | BINARY(24) | 客户端名称 |
|
||||
| 5 | start_time | TIMESTAMP | 客户端启动时间 |
|
||||
| 6 | insert_req | UBIGINT | insert 请求次数 |
|
||||
|
@ -69,7 +69,7 @@ TDengine 3.0 版本开始提供一个内置数据库 `performance_schema`,其
|
|||
| 1 | consumer_id | BIGINT | 消费者的唯一 ID |
|
||||
| 2 | consumer_group | BINARY(192) | 消费者组 |
|
||||
| 3 | client_id | BINARY(192) | 用户自定义字符串,通过创建 consumer 时指定 client_id 来展示 |
|
||||
| 4 | status | BINARY(20) | 消费者当前状态。消费者状态包括:ready(正常可用)、 lost(连接已丢失)、 rebalancing(消费者所属 vgroup 正在分配中)、unknown(未知状态)|
|
||||
| 4 | status | BINARY(20) | 消费者当前状态。消费者状态包括:ready(正常可用)、lost(连接已丢失)、rebalancing(消费者所属 vgroup 正在分配中)、unknown(未知状态)|
|
||||
| 5 | topics | BINARY(204) | 被订阅的 topic。若订阅多个 topic,则展示为多行 |
|
||||
| 6 | up_time | TIMESTAMP | 第一次连接 taosd 的时间 |
|
||||
| 7 | subscribe_time | TIMESTAMP | 上一次发起订阅的时间 |
|
||||
|
|
|
@ -20,7 +20,7 @@ SHOW APPS;
|
|||
SHOW CLUSTER;
|
||||
```
|
||||
|
||||
显示当前集群的信息
|
||||
显示当前集群的信息。
|
||||
|
||||
## SHOW CLUSTER ALIVE
|
||||
|
||||
|
@ -28,17 +28,22 @@ SHOW CLUSTER;
|
|||
SHOW CLUSTER ALIVE;
|
||||
```
|
||||
|
||||
查询当前集群的状态是否可用,返回值: 0:不可用 1:完全可用 2:部分可用(集群中部分节点下线,但其它节点仍可以正常使用)
|
||||
查询当前集群的状态是否可用,返回值如下
|
||||
- 0:不可用
|
||||
- 1:完全可用
|
||||
- 2:部分可用(集群中部分节点下线,但其它节点仍可以正常使用)
|
||||
|
||||
## SHOW CLUSTER MACHINES
|
||||
|
||||
```sql
|
||||
SHOW CLUSTER MACHINES; // 从 TDengine 3.2.3.0 版本开始支持
|
||||
SHOW CLUSTER MACHINES;
|
||||
```
|
||||
|
||||
显示集群的机器码等信息。
|
||||
|
||||
注:企业版独有
|
||||
备注
|
||||
- 企业版功能
|
||||
- v3.2.3.0 开始支持
|
||||
|
||||
## SHOW CONNECTIONS
|
||||
|
||||
|
@ -70,7 +75,7 @@ SHOW CREATE DATABASE db_name;
|
|||
SHOW CREATE STABLE [db_name.]stb_name;
|
||||
```
|
||||
|
||||
显示 tb_name 指定的超级表的创建语句
|
||||
显示 tb_name 指定的超级表的创建语句。
|
||||
|
||||
## SHOW CREATE TABLE
|
||||
|
||||
|
@ -114,7 +119,8 @@ SHOW GRANTS FULL; // 从 TDengine 3.2.3.0 版本开始支持
|
|||
|
||||
显示企业版许可授权的信息。
|
||||
|
||||
注:企业版独有
|
||||
备注
|
||||
- 企业版功能
|
||||
|
||||
## SHOW INDEXES
|
||||
|
||||
|
@ -147,7 +153,7 @@ SHOW MNODES;
|
|||
SHOW QNODES;
|
||||
```
|
||||
|
||||
显示当前系统中 QNODE (查询节点)的信息。
|
||||
显示当前系统中 QNODE(查询节点)的信息。
|
||||
|
||||
## SHOW QUERIES
|
||||
|
||||
|
@ -155,7 +161,7 @@ SHOW QNODES;
|
|||
SHOW QUERIES;
|
||||
```
|
||||
|
||||
显示当前系统中正在进行的写入(更新)/查询/删除。(由于内部 API 命名原因,所以统称 QUERIES)
|
||||
显示当前系统中正在进行的写入(更新)、查询、删除。(由于内部 API 命名原因,所以统称 QUERIES)
|
||||
|
||||
## SHOW SCORES
|
||||
|
||||
|
@ -165,7 +171,8 @@ SHOW SCORES;
|
|||
|
||||
显示系统被许可授权的容量的信息。
|
||||
|
||||
注:企业版独有。
|
||||
备注
|
||||
- 企业版功能
|
||||
|
||||
## SHOW STABLES
|
||||
|
||||
|
@ -219,11 +226,11 @@ SHOW TABLE DISTRIBUTED table_name;
|
|||
|
||||
_block_dist: Total_Blocks=[5] Total_Size=[93.65 KB] Average_size=[18.73 KB] Compression_Ratio=[23.98 %]
|
||||
|
||||
Total_Blocks: 表 d0 占用的 block 个数为 5 个
|
||||
Total_Blocks:表 d0 占用的 block 个数为 5 个
|
||||
|
||||
Total_Size: 表 d0 所有 block 在文件中占用的大小为 93.65 KB
|
||||
Total_Size: 表 d0 所有 block 在文件中占用的大小为 93.65 KB
|
||||
|
||||
Average_size: 平均每个 block 在文件中占用的空间大小为 18.73 KB
|
||||
Average_size:平均每个 block 在文件中占用的空间大小为 18.73 KB
|
||||
|
||||
Compression_Ratio: 数据压缩率 23.98%
|
||||
|
||||
|
@ -232,7 +239,7 @@ Compression_Ratio: 数据压缩率 23.98%
|
|||
|
||||
_block_dist: Total_Rows=[20000] Inmem_Rows=[0] MinRows=[3616] MaxRows=[4096] Average_Rows=[4000]
|
||||
|
||||
Total_Rows: 统计表 d0 的存储在磁盘上行数 20000 行(该数值仅供参考,不是精确的行数。获得精确的行数需要使用 count 函数)
|
||||
Total_Rows:统计表 d0 的存储在磁盘上行数 20000 行(该数值仅供参考,不是精确的行数。获得精确的行数需要使用 count 函数)
|
||||
|
||||
Inmem_Rows: 存储在写缓存中的数据行数(没有落盘),0 行表示内存缓存中没有数据
|
||||
|
||||
|
@ -247,7 +254,7 @@ Average_Rows: 每个 BLOCK 中的平均行数,此时为 4000 行
|
|||
|
||||
_block_dist: Total_Tables=[1] Total_Files=[2] Total_Vgroups=[1]
|
||||
|
||||
Total_Tables: 子表的个数,这里为 1
|
||||
Total_Tables: 子表的个数,这里为 1
|
||||
|
||||
Total_Files: 表数据被分别保存的数据文件数量,这里是 2 个文件
|
||||
|
||||
|
@ -281,7 +288,7 @@ Query OK, 24 row(s) in set (0.002444s)
|
|||
</code></pre>
|
||||
</details>
|
||||
|
||||
上面是块中包含数据行数的块儿分布情况图,这里的 0100 0299 0498 … 表示的是每个块中包含的数据行数,上面的意思就是这个表的 5 个块,分布在 3483 ~3681 行的块有 1 个,占整个块的 20%,分布在 3881 ~ 4096(最大行数)的块数为 4 个,占整个块的 80%, 其它区域内分布块数为 0。
|
||||
上面是块中包含数据行数的块儿分布情况图,这里的 `0100 0299 0498 …` 表示的是每个块中包含的数据行数,上面的意思就是这个表的 5 个块,分布在 `3483 ~ 3681` 行的块有 1 个,占整个块的 20%,分布在 `3881 ~ 4096`(最大行数)的块数为 4 个,占整个块的 80%, 其它区域内分布块数为 0。
|
||||
|
||||
需要注意,这里只会显示 data 文件中数据块的信息,stt 文件中的数据的信息不会被显示。
|
||||
|
||||
|
@ -309,7 +316,7 @@ SHOW TRANSACTIONS;
|
|||
SHOW TRANSACTION [tranaction_id];
|
||||
```
|
||||
|
||||
显示当前系统中正在执行的所有或者某一个事务的信息(该事务仅针对除普通表以外的元数据级别)
|
||||
显示当前系统中正在执行的所有或者某一个事务的信息(该事务仅针对除普通表以外的元数据级别)。
|
||||
|
||||
## SHOW USERS
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ CREATE USER user_name PASS 'password' [SYSINFO {1|0}] [CREATEDB {1|0}];
|
|||
|
||||
`SYSINFO` 表示该用户是否能够查看系统信息。`1` 表示可以查看,`0` 表示无权查看。系统信息包括服务配置、dnode、vnode、存储等信息。缺省值为 `1`。
|
||||
|
||||
`CREATEDB` 表示该用户是否能够创建数据库。`1` 表示可以创建,`0` 表示无权创建。缺省值为 `0`。// 从 TDengine 企业版 3.3.2.0 开始支持
|
||||
`CREATEDB` 表示该用户是否能够创建数据库。`1` 表示可以创建,`0` 表示无权创建。缺省值为 `0`。从企业版 v3.3.2.0 开始支持。
|
||||
|
||||
在下面的示例中,我们创建一个密码为 `abc123!@#` 且可以查看系统信息的用户。
|
||||
|
||||
|
@ -76,12 +76,12 @@ alter_user_clause: {
|
|||
}
|
||||
```
|
||||
|
||||
- PASS: 修改密码,后跟新密码
|
||||
- ENABLE: 启用或禁用该用户,`1` 表示启用,`0` 表示禁用
|
||||
- SYSINFO: 允许或禁止查看系统信息,`1` 表示允许,`0` 表示禁止
|
||||
- CREATEDB: 允许或禁止创建数据库,`1` 表示允许,`0` 表示禁止。// 从 TDengine 企业版 3.3.2.0 开始支持
|
||||
- PASS:修改密码,后跟新密码
|
||||
- ENABLE:启用或禁用该用户,`1` 表示启用,`0` 表示禁用
|
||||
- SYSINFO:允许或禁止查看系统信息,`1` 表示允许,`0` 表示禁止
|
||||
- CREATEDB:允许或禁止创建数据库,`1` 表示允许,`0` 表示禁止。从企业版 v3.3.2.0 开始支持。
|
||||
|
||||
下面的示例禁用了名为 `test` 的用户:
|
||||
下面的示例禁用了名为 `test` 的用户。
|
||||
|
||||
```sql
|
||||
taos> alter user test enable 0;
|
||||
|
|
|
@ -3,7 +3,7 @@ toc_max_heading_level: 4
|
|||
title: 权限管理
|
||||
---
|
||||
|
||||
TDengine 中的权限管理分为[用户管理](../user)、数据库授权管理以及消息订阅授权管理,本节重点说明数据库授权和订阅授权。
|
||||
TDengine 中的权限管理分为 [用户管理](../user)、数据库授权管理以及消息订阅授权管理,本节重点说明数据库授权和订阅授权。
|
||||
授权管理仅在 TDengine 企业版中可用,请联系 TDengine 销售团队。授权语法在社区版可用,但不起作用。
|
||||
|
||||
## 数据库访问授权
|
||||
|
@ -33,19 +33,18 @@ priv_level : {
|
|||
对数据库的访问权限包含读和写两种权限,它们可以被分别授予,也可以被同时授予。
|
||||
|
||||
说明
|
||||
|
||||
- priv_level 格式中 "." 之前为数据库名称, "." 之后为表名称,意思为表级别的授权控制。如果 "." 之后为 "\*" ,意为 "." 前所指定的数据库中的所有表
|
||||
- "dbname.\*" 意思是名为 "dbname" 的数据库中的所有表
|
||||
- "\*.\*" 意思是所有数据库名中的所有表
|
||||
- priv_level 格式中 "." 之前为数据库名称,"." 之后为表名称,意思为表级别的授权控制。如果 "." 之后为 "\*",意为 "." 前所指定的数据库中的所有表
|
||||
- "dbname.\*" 意思是名为 "dbname" 的数据库中的所有表
|
||||
- "\*.\*" 意思是所有数据库名中的所有表
|
||||
|
||||
### 数据库权限说明
|
||||
|
||||
对 root 用户和普通用户的权限的说明如下表
|
||||
|
||||
| 用户 | 描述 | 权限说明 |
|
||||
| -------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 超级用户 | 只有 root 是超级用户 | DB 外部 所有操作权限,例如user、dnode、udf、qnode等的CRUD DB 权限,包括 创建 删除 更新,例如修改 Option,移动 Vgruop等 读 写 Enable/Disable 用户 |
|
||||
| 普通用户 | 除 root 以外的其它用户均为普通用户 | 在可读的 DB 中,普通用户可以进行读操作 select describe show subscribe 在可写 DB 的内部,用户可以进行写操作: 创建、删除、修改 超级表 创建、删除、修改 子表 创建、删除、修改 topic 写入数据 被限制系统信息时,不可进行如下操作 show dnode、mnode、vgroups、qnode、snode 修改用户包括自身密码 show db时只能看到自己的db,并且不能看到vgroups、副本、cache等信息 无论是否被限制系统信息,都可以 管理 udf 可以创建 DB 自己创建的 DB 具备所有权限 非自己创建的 DB ,参照读、写列表中的权限 |
|
||||
| 用户 | 描述 | 权限说明 |
|
||||
| -------- | --------------------------------- | -- |
|
||||
| 超级用户 | 只有 root 是超级用户 |<br/>DB 外部:所有操作权限,例如 user、dnode、udf、qnode 等的 CRUD <br/>DB 权限:包括创建、删除、修改 Option、移动 Vgruop、读、写、Enable/Disable 用户 |
|
||||
| 普通用户 | 除 root 以外的其它用户均为普通用户 | <br/>在可读的 DB 中:普通用户可以进行读操作 select、describe、show、subscribe <br/>在可写 DB 的内部,用户可以进行写操作,创建、删除、修改超级表,创建、删除、修改子表,创建、删除、修改 topic。写入数据 <br/>被限制系统信息时,不可进行如下操作 show dnode、mnode、vgroups、qnode、snode、修改用户包括自身密码、`show db` 时只能看到自己的 db,并且不能看到 vgroups、副本、cache等信息 <br/>无论是否被限制系统信息,都可以管理 udf,可以创建 DB、自己创建的 DB 具备所有权限、非自己创建的 DB,参照读、写列表中的权限 |
|
||||
|
||||
## 消息订阅授权
|
||||
|
||||
|
@ -61,7 +60,7 @@ REVOKE SUBSCRIBE ON topic_name FROM user_name
|
|||
|
||||
## 基于标签的授权(表级授权)
|
||||
|
||||
从 TDengine 3.0.5.0 开始,我们支持按标签授权某个超级表中部分特定的子表。具体的 SQL 语法如下。
|
||||
从 v3.0.5.0 开始,我们支持按标签授权某个超级表中部分特定的子表。具体的 SQL 语法如下。
|
||||
|
||||
```sql
|
||||
GRANT privileges ON priv_level [WITH tag_condition] TO user_name
|
||||
|
@ -110,11 +109,11 @@ priv_level : {
|
|||
|
||||
下表列出了在不同的数据库授权和表级授权的组合下产生的实际权限。
|
||||
|
||||
| | **表无授权** | **表读授权** | **表读授权有标签条件** | **表写授权** | **表写授权有标签条件** |
|
||||
| ---------------- | ---------------- | ---------------------------------------- | ------------------------------------------------------------ | ---------------------------------------- | ---------------------------------------------------------- |
|
||||
| **数据库无授权** | 无授权 | 对此表有读权限,对数据库下的其他表无权限 | 对此表符合标签权限的子表有读权限,对数据库下的其他表无权限 | 对此表有写权限,对数据库下的其他表无权限 | 对此表符合标签权限的子表有写权限,对数据库下的其他表无权限 |
|
||||
| **数据库读授权** | 对所有表有读权限 | 对所有表有读权限 | 对此表符合标签权限的子表有读权限,对数据库下的其他表有读权限 | 对此表有写权限,对所有表有读权限 | 对此表符合标签权限的子表有写权限,所有表有读权限 |
|
||||
| **数据库写授权** | 对所有表有写权限 | 对此表有读权限,对所有表有写权限 | 对此表符合标签权限的子表有读权限,对所有表有写权限 | 对所有表有写权限 | 对此表符合标签权限的子表有写权限,数据库下的其他表有写权限 |
|
||||
| | **表无授权** | **表读授权** | **表读授权有标签条件** | **表写授权** | **表写授权有标签条件** |
|
||||
| -------------- | ------------- | --------------------------------- | ------------------------------------------------- | ---------------------------------- | -------------------- |
|
||||
| **数据库无授权** | 无授权 | 对此表有读权限,对数据库下的其他表无权限 | 对此表符合标签权限的子表有读权限,对数据库下的其他表无权限 | 对此表有写权限,对数据库下的其他表无权限 | 对此表符合标签权限的子表有写权限,对数据库下的其他表无权限 |
|
||||
| **数据库读授权** | 对所有表有读权限 | 对所有表有读权限 | 对此表符合标签权限的子表有读权限,对数据库下的其他表有读权限 | 对此表有写权限,对所有表有读权限 | 对此表符合标签权限的子表有写权限,所有表有读权限 |
|
||||
| **数据库写授权** | 对所有表有写权限 | 对此表有读权限,对所有表有写权限 | 对此表符合标签权限的子表有读权限,对所有表有写权限 | 对所有表有写权限 | 对此表符合标签权限的子表有写权限,数据库下的其他表有写权限 |
|
||||
|
||||
|
||||
## 查看用户授权
|
||||
|
@ -127,7 +126,7 @@ show user privileges
|
|||
|
||||
## 撤销授权
|
||||
|
||||
1. 撤销数据库访问的授权
|
||||
1. 撤销数据库访问的授权
|
||||
|
||||
```sql
|
||||
REVOKE privileges ON priv_level FROM user_name
|
||||
|
@ -149,7 +148,7 @@ priv_level : {
|
|||
}
|
||||
```
|
||||
|
||||
2. 撤销数据订阅的授权
|
||||
2. 撤销数据订阅的授权
|
||||
|
||||
```sql
|
||||
REVOKE privileges ON priv_level FROM user_name
|
||||
|
|
|
@ -4,10 +4,10 @@ title: 自定义函数
|
|||
description: 使用 UDF 的详细指南
|
||||
---
|
||||
|
||||
除了 TDengine 的内置函数以外,用户还可以编写自己的函数逻辑并加入TDengine系统中。
|
||||
除了 TDengine 的内置函数以外,用户还可以编写自己的函数逻辑并加入 TDengine 系统中。
|
||||
## 创建 UDF
|
||||
|
||||
用户可以通过 SQL 指令在系统中加载客户端所在主机上的 UDF 函数库(不能通过 RESTful 接口或 HTTP 管理界面来进行这一过程)。一旦创建成功,则当前 TDengine 集群的所有用户都可以在 SQL 指令中使用这些函数。UDF 存储在系统的 MNode 节点上,因此即使重启 TDengine 系统,已经创建的 UDF 也仍然可用。
|
||||
用户可以通过 SQL 指令在系统中加载客户端所在主机上的 UDF 函数库(不能通过 RESTful 接口或 HTTP 管理界面来进行这一过程)。一旦创建成功,则当前 TDengine 集群的所有用户都可以在 SQL 指令中使用这些函数。UDF 存储在系统的 mnode 节点上,因此即使重启 TDengine 系统,已经创建的 UDF 也仍然可用。
|
||||
|
||||
在创建 UDF 时,需要区分标量函数和聚合函数。如果创建时声明了错误的函数类别,则可能导致通过 SQL 指令调用函数时出错。此外,用户需要保证输入数据类型与 UDF 程序匹配,UDF 输出数据类型与 OUTPUTTYPE 匹配。
|
||||
|
||||
|
@ -15,11 +15,11 @@ description: 使用 UDF 的详细指南
|
|||
```sql
|
||||
CREATE [OR REPLACE] FUNCTION function_name AS library_path OUTPUTTYPE output_type [LANGUAGE 'C|Python'];
|
||||
```
|
||||
- OR REPLACE: 如果函数已经存在,会修改已有的函数属性。
|
||||
- function_name:标量函数未来在 SQL 中被调用时的函数名;
|
||||
- LANGUAGE 'C|Python':函数编程语言,目前支持C语言和Python语言。 如果这个从句忽略,编程语言是C语言
|
||||
- library_path:如果编程语言是C,路径是包含 UDF 函数实现的动态链接库的库文件绝对路径(指的是库文件在当前客户端所在主机上的保存路径,通常是指向一个 .so 文件)。如果编程语言是Python,路径是包含 UDF 函数实现的Python文件路径。这个路径需要用英文单引号或英文双引号括起来;
|
||||
- output_type:此函数计算结果的数据类型名称;
|
||||
- OR REPLACE:如果函数已经存在,会修改已有的函数属性。
|
||||
- function_name:标量函数未来在 SQL 中被调用时的函数名。
|
||||
- LANGUAGE 'C|Python':函数编程语言,目前支持 C 语言和 Python 语言。如果这个从句忽略,编程语言是 C 语言。
|
||||
- library_path:如果编程语言是C,路径是包含 UDF 函数实现的动态链接库的库文件绝对路径(指的是库文件在当前客户端所在主机上的保存路径,通常是指向一个 .so 文件)。如果编程语言是 Python,路径是包含 UDF 函数实现的 Python 文件路径。这个路径需要用英文单引号或英文双引号括起来;
|
||||
- output_type:此函数计算结果的数据类型名称。
|
||||
|
||||
例如,如下语句可以把 libbitand.so 创建为系统中可用的 UDF:
|
||||
|
||||
|
@ -36,19 +36,19 @@ CREATE [OR REPLACE] FUNCTION function_name AS library_path OUTPUTTYPE output_typ
|
|||
```sql
|
||||
CREATE [OR REPLACE] AGGREGATE FUNCTION function_name AS library_path OUTPUTTYPE output_type [ BUFSIZE buffer_size ] [LANGUAGE 'C|Python'];
|
||||
```
|
||||
- OR REPLACE: 如果函数已经存在,会修改已有的函数属性。
|
||||
- OR REPLACE:如果函数已经存在,会修改已有的函数属性。
|
||||
- function_name:聚合函数未来在 SQL 中被调用时的函数名,必须与函数实现中 udfNormalFunc 的实际名称一致;
|
||||
- LANGUAGE 'C|Python':函数编程语言,目前支持C语言和Python语言(v3.7+)。
|
||||
- library_path:如果编程语言是C,路径是包含 UDF 函数实现的动态链接库的库文件绝对路径(指的是库文件在当前客户端所在主机上的保存路径,通常是指向一个 .so 文件)。如果编程语言是Python,路径是包含 UDF 函数实现的Python文件路径。这个路径需要用英文单引号或英文双引号括起来;;
|
||||
- LANGUAGE 'C|Python':函数编程语言,目前支持 C 语言和 Python 语言(v3.7+)。
|
||||
- library_path:如果编程语言是C,路径是包含 UDF 函数实现的动态链接库的库文件绝对路径(指的是库文件在当前客户端所在主机上的保存路径,通常是指向一个 `.so` 文件)。如果编程语言是 Python,路径是包含 UDF 函数实现的 Python 文件路径。这个路径需要用英文单引号或英文双引号括起来;
|
||||
- output_type:此函数计算结果的数据类型名称;
|
||||
- buffer_size:中间计算结果的缓冲区大小,单位是字节。如果不使用可以不设置。
|
||||
|
||||
例如,如下语句可以把 libl2norm.so 创建为系统中可用的 UDF:
|
||||
例如,如下语句可以把 libl2norm.so 创建为系统中可用的 UDF。
|
||||
|
||||
```sql
|
||||
CREATE AGGREGATE FUNCTION l2norm AS "/home/taos/udf_example/libl2norm.so" OUTPUTTYPE DOUBLE bufsize 8;
|
||||
```
|
||||
例如,使用以下语句可以修改已经定义的 l2norm 函数的缓冲区大小为64。
|
||||
例如,使用以下语句可以修改已经定义的 l2norm 函数的缓冲区大小为 64。
|
||||
```sql
|
||||
CREATE AGGREGATE FUNCTION l2norm AS "/home/taos/udf_example/libl2norm.so" OUTPUTTYPE DOUBLE bufsize 64;
|
||||
```
|
||||
|
@ -57,25 +57,26 @@ CREATE [OR REPLACE] AGGREGATE FUNCTION function_name AS library_path OUTPUTTYPE
|
|||
|
||||
## 管理 UDF
|
||||
|
||||
- 删除指定名称的用户定义函数:
|
||||
- 删除指定名称的用户定义函数。
|
||||
```
|
||||
DROP FUNCTION function_name;
|
||||
```
|
||||
|
||||
- function_name:此参数的含义与 CREATE 指令中的 function_name 参数一致,也即要删除的函数的名字,例如bit_and, l2norm
|
||||
- function_name:此参数的含义与 CREATE 指令中的 function_name 参数一致,也即要删除的函数的名字,例如 bit_and、l2norm
|
||||
```sql
|
||||
DROP FUNCTION bit_and;
|
||||
```
|
||||
- 显示系统中当前可用的所有 UDF:
|
||||
|
||||
- 显示系统中当前可用的所有 UDF。
|
||||
```sql
|
||||
SHOW FUNCTIONS;
|
||||
```
|
||||
|
||||
## 调用 UDF
|
||||
|
||||
在 SQL 指令中,可以直接以在系统中创建 UDF 时赋予的函数名来调用用户定义函数。例如:
|
||||
在 SQL 指令中,可以直接以在系统中创建 UDF 时赋予的函数名来调用用户定义函数。
|
||||
```sql
|
||||
SELECT bit_and(c1,c2) FROM table;
|
||||
```
|
||||
|
||||
表示对表 table 上名为 c1, c2 的数据列调用名为 bit_and 的用户定义函数。SQL 指令中用户定义函数可以配合 WHERE 等查询特性来使用。
|
||||
表示对表 table 上名为 c1、c2 的数据列调用名为 bit_and 的用户定义函数。SQL 指令中用户定义函数可以配合 WHERE 等查询特性来使用。
|
||||
|
|
|
@ -4,36 +4,38 @@ title: 窗口预聚集
|
|||
description: 窗口预聚集使用说明
|
||||
---
|
||||
|
||||
在大数据量场景下, 经常需要查询某段时间内的汇总结果, 当历史数据变多或者时间范围变大时, 查询时间也会相应增加. 通过预聚集的方式可以将计算结果提前存储下来, 后续查询可以直接读取聚集结果, 而不需要扫描原始数据, 如当前Block内的SMA (Small Materialized Aggregates)信息.
|
||||
Block内的SMA信息粒度较小, 若查询时间范围是日,月甚至年时, Block的数量将会很多, 因此TSMA (Time-Range Small Materialized Aggregates)支持用户指定时间窗口进行预聚集. 通过对固定时间窗口内的数据进行预计算, 并将计算结果存储下来, 查询时通过查询预计算结果以提高查询性能。
|
||||
在大数据量场景下,经常需要查询某段时间内的汇总结果,当历史数据变多或者时间范围变大时,查询时间也会相应增加。通过预聚集的方式可以将计算结果提前存储下来,后续查询可以直接读取聚集结果,而不需要扫描原始数据,如当前 Block 内的 SMA (Small Materialized Aggregates)信息。
|
||||
|
||||
Block 内的 SMA 信息粒度较小,若查询时间范围是日,月甚至年时,Block 的数量将会很多,因此 TSMA (Time-Range Small Materialized Aggregates)支持用户指定时间窗口进行预聚集。通过对固定时间窗口内的数据进行预计算,并将计算结果存储下来,查询时通过查询预计算结果以提高查询性能。
|
||||
|
||||

|
||||
|
||||
## 创建TSMA
|
||||
## 创建 TSMA
|
||||
|
||||
```sql
|
||||
-- 创建基于超级表或普通表的tsma
|
||||
-- 创建基于超级表或普通表的 tsma
|
||||
CREATE TSMA tsma_name ON [dbname.]table_name FUNCTION (func_name(func_param) [, ...] ) INTERVAL(time_duration);
|
||||
-- 创建基于小窗口tsma的大窗口tsma
|
||||
|
||||
-- 创建基于小窗口 tsma 的大窗口 tsma
|
||||
CREATE RECURSIVE TSMA tsma_name ON [db_name.]tsma_name1 INTERVAL(time_duration);
|
||||
|
||||
time_duration:
|
||||
number unit
|
||||
```
|
||||
|
||||
创建 TSMA 时需要指定 TSMA 名字, 表名字, 函数列表以及窗口大小. 当基于一个已经存在的 TSMA 创建新的 TSMA 时, 需要使用 `RECURSIVE` 关键字但不能指定 `FUNCTION()`, 新创建的 TSMA 已有 TSMA 拥有相同的函数列表, 且此种情况下所指定的 INTERVAL 必须至少为所基于的 TSMA 窗口长度的整数倍, 并且天不能基于2h或3h建立, 只能基于1h建立, 月也只能基于1d而非2d,3d建立。
|
||||
创建 TSMA 时需要指定 TSMA 名字,表名字,函数列表以及窗口大小。当基于一个已经存在的 TSMA 创建新的 TSMA 时,需要使用 `RECURSIVE` 关键字但不能指定 `FUNCTION()`,新创建的 TSMA 已有 TSMA 拥有相同的函数列表,且此种情况下所指定的 INTERVAL 必须至少为所基于的 TSMA 窗口长度的整数倍,并且天不能基于 2h 或 3h 建立,只能基于 1h 建立,月也只能基于 1d 而非 2d、3d 建立。
|
||||
|
||||
其中 TSMA 命名规则与表名字类似, 长度最大限制为表名长度限制减去输出表后缀长度, 表名长度限制为193, 输出表后缀为`_tsma_res_stb_`, TSMA 名字最大长度为178.
|
||||
其中 TSMA 命名规则与表名字类似,长度最大限制为表名长度限制减去输出表后缀长度,表名长度限制为 193,输出表后缀为`_tsma_res_stb_`,TSMA 名字最大长度为 178。
|
||||
|
||||
TSMA只能基于超级表和普通表创建, 不能基于子表创建.
|
||||
TSMA 只能基于超级表和普通表创建,不能基于子表创建。
|
||||
|
||||
函数列表中只能指定支持的聚集函数(见下文), 并且函数参数必须为1个, 即使当前函数支持多个参数, 函数参数内必须为普通列名, 不能为标签列. 函数列表中完全相同的函数和列会被去重, 如同时创建两个avg(c1), 则只会计算一个输出. TSMA 计算时将会把所有`函数中间结果`都输出到另一张超级表中, 输出超级表还包含了原始表的所有tag列. 函数列表中函数个数最多支持创建表最大列个数(包括tag列)减去 TSMA 计算附加的四列, 分别为`_wstart`, `_wend`, `_wduration`, 以及一个新增tag列 `tbname`, 再减去原始表的tag列数. 若列个数超出限制, 会报`Too many columns`错误.
|
||||
函数列表中只能指定支持的聚集函数(见下文),并且函数参数必须为 1 个,即使当前函数支持多个参数,函数参数内必须为普通列名,不能为标签列。函数列表中完全相同的函数和列会被去重,如同时创建两个 avg(c1),则只会计算一个输出。TSMA 计算时将会把所有 `函数中间结果` 都输出到另一张超级表中,输出超级表还包含了原始表的所有 tag 列。函数列表中函数个数最多支持创建表最大列个数(包括 tag 列)减去 TSMA 计算附加的四列,分别为 `_wstart`、`_wend`、`_wduration`,以及一个新增 tag 列 `tbname`,再减去原始表的 tag 列数。若列个数超出限制,会报 `Too many columns` 错误。
|
||||
|
||||
由于TSMA输出为一张超级表, 因此输出表的行长度受最大行长度限制, 不同函数的`中间结果`大小各异, 一般都大于原始数据大小, 若输出表的行长度大于最大行长度限制, 将会报`Row length exceeds max length`错误. 此时需要减少函数个数或者将常用的函数进行分组拆分到多个TSMA中.
|
||||
由于 TSMA 输出为一张超级表,因此输出表的行长度受最大行长度限制,不同函数的 `中间结果` 大小各异,一般都大于原始数据大小,若输出表的行长度大于最大行长度限制,将会报 `Row length exceeds max length` 错误。此时需要减少函数个数或者将常用的函数进行分组拆分到多个 TSMA 中。
|
||||
|
||||
窗口大小的限制为[1m ~ 1y/12n]. INTERVAL 的单位与查询中INTERVAL子句相同, 如 a (毫秒), b (纳秒), h (小时), m (分钟), s (秒), u (微秒), d (天), w(周), n(月), y(年).
|
||||
窗口大小的限制为 [1m ~ 1y/12n]。INTERVAL 的单位与查询中 INTERVAL 子句相同,如 a(毫秒)、b(纳秒)、h(小时)、m(分钟)、s(秒)、u(微秒)、d(天)、w(周)、n(月)、y(年)。
|
||||
|
||||
TSMA为库内对象, 但名字全局唯一. 集群内一共可创建TSMA个数受参数`maxTsmaNum`限制, 参数默认值为3, 范围: [0-3]. 注意, 由于TSMA后台计算使用流计算, 因此每创建一条TSMA, 将会创建一条流, 因此能够创建的TSMA条数也受当前已经存在的流条数和最大可创建流条数限制.
|
||||
TSMA 为库内对象,但名字全局唯一。集群内一共可创建 TSMA 个数受参数 `maxTsmaNum` 限制,参数默认值为 3,范围:[0-3]。注意,由于 TSMA 后台计算使用流计算,因此每创建一条 TSMA,将会创建一条流,因此能够创建的 TSMA 条数也受当前已经存在的流条数和最大可创建流条数限制。
|
||||
|
||||
## 支持的函数列表
|
||||
| 函数| 备注 |
|
||||
|
@ -44,65 +46,64 @@ TSMA为库内对象, 但名字全局唯一. 集群内一共可创建TSMA个数
|
|||
|first||
|
||||
|last||
|
||||
|avg||
|
||||
|count| 若想使用count(*), 则应创建count(ts)函数|
|
||||
|count| 若想使用 count(*),则应创建 count(ts) 函数|
|
||||
|spread||
|
||||
|stddev||
|
||||
|||
|
||||
|
||||
## 删除TSMA
|
||||
## 删除 TSMA
|
||||
```sql
|
||||
DROP TSMA [db_name.]tsma_name;
|
||||
```
|
||||
若存在其他TSMA基于当前被删除TSMA创建, 则删除操作报`Invalid drop base tsma, drop recursive tsma first`错误. 因此需先删除 所有Recursive TSMA.
|
||||
若存在其他 TSMA 基于当前被删除 TSMA 创建,则删除操作报 `Invalid drop base tsma, drop recursive tsma first` 错误。因此需先删除 所有 Recursive TSMA。
|
||||
|
||||
## TSMA的计算
|
||||
TSMA的计算结果为与原始表相同库下的一张超级表, 此表用户不可见. 不可删除, 在`DROP TSMA`时自动删除. TSMA的计算是通过流计算完成的, 此过程为后台异步过程, TSMA的计算结果不保证实时性, 但可以保证最终正确性.
|
||||
## TSMA 的计算
|
||||
TSMA 的计算结果为与原始表相同库下的一张超级表,此表用户不可见。不可删除,在 `DROP TSMA` 时自动删除。TSMA 的计算是通过流计算完成的,此过程为后台异步过程,TSMA 的计算结果不保证实时性,但可以保证最终正确性。
|
||||
|
||||
TSMA计算时若原始子表内没有数据, 则可能不会创建对应的输出子表, 因此在count查询中, 即使配置了`countAlwaysReturnValue`, 也不会返回该表的结果.
|
||||
TSMA 计算时若原始子表内没有数据,则可能不会创建对应的输出子表,因此在 count 查询中,即使配置了 `countAlwaysReturnValue`,也不会返回该表的结果。
|
||||
|
||||
当存在大量历史数据时, 创建TSMA之后, 流计算将会首先计算历史数据, 此期间新创建的TSMA不会被使用. 数据更新删除或者过期数据到来时自动重新计算影响部分数据。 在重新计算期间 TSMA 查询结果不保证实时性。若希望查询实时数据, 可以通过在 SQL 中添加 hint `/*+ skip_tsma() */` 或者关闭参数`querySmaOptimize`从原始数据查询。
|
||||
当存在大量历史数据时,创建 TSMA 之后,流计算将会首先计算历史数据,此期间新创建的 TSMA 不会被使用。数据更新删除或者过期数据到来时自动重新计算影响部分数据。在重新计算期间 TSMA 查询结果不保证实时性。若希望查询实时数据,可以通过在 SQL 中添加 hint `/*+ skip_tsma() */` 或者关闭参数 `querySmaOptimize` 从原始数据查询。
|
||||
|
||||
## TSMA的使用与限制
|
||||
## TSMA 的使用与限制
|
||||
|
||||
客户端配置参数: `querySmaOptimize`, 用于控制查询时是否使用TSMA, `True`为使用, `False`为不使用即从原始数据查询.
|
||||
- 客户端配置参数:`querySmaOptimize`,用于控制查询时是否使用TSMA,`True`为使用,`False` 为不使用即从原始数据查询。
|
||||
- 客户端配置参数:`maxTsmaCalcDelay`,单位为秒,用于控制用户可以接受的 TSMA 计算延迟,若 TSMA 的计算进度与最新时间差距在此范围内,则该 TSMA 将会被使用,若超出该范围,则不使用,默认值:600(10 分钟),最小值:600(10 分钟),最大值:86400(1 天)。
|
||||
- 客户端配置参数:`tsmaDataDeleteMark`,单位毫秒,与流计算参数 `deleteMark` 一致,用于控制流计算中间结果的保存时间,默认值为 1d,最小值为 1h。因此那些距最后一条数据时间大于配置参数的历史数据将不保存流计算中间结果,因此若修改这些时间窗口内的数据,TSMA 的计算结果中将不包含更新的结果。即与查询原始数据结果将不一致。
|
||||
|
||||
客户端配置参数:`maxTsmaCalcDelay`,单位 s,用于控制用户可以接受的 TSMA 计算延迟,若 TSMA 的计算进度与最新时间差距在此范围内, 则该 TSMA 将会被使用, 若超出该范围, 则不使用, 默认值: 600(10 分钟), 最小值: 600(10 分钟), 最大值: 86400(1 天).
|
||||
### 查询时使用 TSMA
|
||||
|
||||
客户端配置参数: `tsmaDataDeleteMark`, 单位毫秒, 与流计算参数`deleteMark`一致, 用于控制流计算中间结果的保存时间, 默认值为: 1d, 最小值为1h. 因此那些距最后一条数据时间大于配置参数的历史数据将不保存流计算中间结果, 因此若修改这些时间窗口内的数据, TSMA的计算结果中将不包含更新的结果. 即与查询原始数据结果将不一致.
|
||||
已在 TSMA 中定义的 agg 函数在大部分查询场景下都可直接使用,若存在多个可用的 TSMA,优先使用大窗口的 TSMA,未闭合窗口通过查询小窗口 TSMA 或者原始数据计算。同时也有某些场景不能使用 TSMA(见下文)。不可用时整个查询将使用原始数据进行计算。
|
||||
|
||||
### 查询时使用TSMA
|
||||
未指定窗口大小的查询语句默认优先使用包含所有查询聚合函数的最大窗口 TSMA 进行数据的计算。如 `SELECT COUNT(*) FROM stable GROUP BY tbname` 将会使用包含 count(ts) 且窗口最大的 TSMA。因此若使用聚合查询频率高时,应当尽可能创建大窗口的 TSMA。
|
||||
|
||||
已在 TSMA 中定义的 agg 函数在大部分查询场景下都可直接使用, 若存在多个可用的 TSMA, 优先使用大窗口的 TSMA, 未闭合窗口通过查询小窗口TSMA或者原始数据计算。 同时也有某些场景不能使用 TSMA(见下文)。 不可用时整个查询将使用原始数据进行计算。
|
||||
指定窗口大小时即 `INTERVAL` 语句,使用最大的可整除窗口 TSMA。窗口查询中,`INTERVAL` 的窗口大小、`OFFSET` 以及 `SLIDING` 都影响能使用的 TSMA 窗口大小。因此若使用窗口查询较多时,需要考虑经常查询的窗口大小,以及 offset、sliding 大小来创建 TSMA。
|
||||
|
||||
未指定窗口大小的查询语句默认优先使用包含所有查询聚合函数的最大窗口 TSMA 进行数据的计算。 如`SELECT COUNT(*) FROM stable GROUP BY tbname`将会使用包含count(ts)且窗口最大的TSMA。因此若使用聚合查询频率高时, 应当尽可能创建大窗口的TSMA.
|
||||
|
||||
指定窗口大小时即 `INTERVAL` 语句,使用最大的可整除窗口 TSMA。 窗口查询中, `INTERVAL` 的窗口大小, `OFFSET` 以及 `SLIDING` 都影响能使用的 TSMA 窗口大小, 可整 除窗口 TSMA 即 TSMA 窗口大小可被查询语句的 `INTERVAL, OFFSET, SLIDING` 整除的窗口。因此若使用窗口查询较多时, 需要考虑经常查询的窗口大小, 以及 offset, sliding大小来创建TSMA.
|
||||
|
||||
例 1. 如 创建 TSMA 窗口大小 `5m` 一条, `10m` 一条, 查询时 `INTERVAL(30m)`, 那么优先使用 `10m` 的 TSMA, 若查询为 `INTERVAL(30m, 10m) SLIDING(5m)`, 那么仅可使用 `5m` 的 TSMA 查询。
|
||||
例如 创建 TSMA 窗口大小 `5m` 一条,`10m` 一条,查询时 `INTERVAL(30m)`,那么优先使用 `10m` 的 TSMA,若查询为 `INTERVAL(30m, 10m) SLIDING(5m)`,那么仅可使用 `5m` 的 TSMA 查询。
|
||||
|
||||
|
||||
### 查询限制
|
||||
|
||||
在开启了参数`querySmaOptimize`并且无`skip_tsma()` hint时, 以下查询场景无法使用TSMA:
|
||||
在开启了参数 `querySmaOptimize` 并且无 `skip_tsma()` hint 时,以下查询场景无法使用 TSMA。
|
||||
|
||||
- 某个TSMA 中定义的 agg 函数不能覆盖当前查询的函数列表时
|
||||
- 某个 TSMA 中定义的 agg 函数不能覆盖当前查询的函数列表时
|
||||
- 非 `INTERVAL` 的其他窗口,或者 `INTERVAL` 查询窗口大小(包括 `INTERVAL,SLIDING,OFFSET`)不是定义窗口的整数倍,如定义窗口为 2m,查询使用 5 分钟窗口,但若存在 1m 的窗口,则可以使用。
|
||||
- 查询 `WHERE` 条件中包含任意普通列(非主键时间列)的过滤。
|
||||
- `PARTITION` 或者 `GROUY BY` 包含任意普通列或其表达式时
|
||||
- 可以使用其他更快的优化逻辑时, 如last cache优化, 若符合last优化的条件, 则先走last 优化, 无法走last时, 再判断是否可以走tsma优化
|
||||
- 可以使用其他更快的优化逻辑时,如 last cache 优化,若符合 last 优化的条件,则先走 last 优化,无法走 last 时,再判断是否可以走 tsma 优化
|
||||
- 当前 TSMA 计算进度延迟大于配置参数 `maxTsmaCalcDelay`时
|
||||
|
||||
下面是一些例子:
|
||||
下面是一些例子:
|
||||
|
||||
```sql
|
||||
SELECT agg_func_list [, pesudo_col_list] FROM stable WHERE exprs [GROUP/PARTITION BY [tbname] [, tag_list]] [HAVING ...] [INTERVAL(time_duration, offset) SLIDING(duration)]...;
|
||||
|
||||
-- 创建
|
||||
CREATE TSMA tsma1 ON stable FUNCTION(COUNT(ts), SUM(c1), SUM(c3), MIN(c1), MIN(c3), AVG(c1)) INTERVAL(1m);
|
||||
|
||||
-- 查询
|
||||
SELECT COUNT(*), SUM(c1) + SUM(c3) FROM stable; ---- use tsma1
|
||||
SELECT COUNT(*), AVG(c1) FROM stable GROUP/PARTITION BY tbname, tag1, tag2; --- use tsma1
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(1h); ---use tsma1
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(1h); --- use tsma1
|
||||
SELECT COUNT(*), MIN(c1), SPREAD(c1) FROM stable INTERVAL(1h); ----- can't use, spread func not defined, although SPREAD can be calculated by MIN and MAX which are defined.
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(30s); ----- can't use tsma1, time_duration not fit. Normally, query_time_duration should be multple of create_duration.
|
||||
SELECT COUNT(*), MIN(c1) FROM stable where c2 > 0; ---- can't use tsma1, can't do c2 filtering
|
||||
|
@ -113,10 +114,10 @@ SELECT MIN(c3), MIN(c2) FROM stable INTERVAL(1m); ---- can't use tsma1, c2 is no
|
|||
CREATE RECURSIVE TSMA tsma2 on tsma1 INTERVAL(1h);
|
||||
SELECT COUNT(*), SUM(c1) FROM stable; ---- use tsma2
|
||||
SELECT COUNT(*), AVG(c1) FROM stable GROUP/PARTITION BY tbname, tag1, tag2; --- use tsma2
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(2h); ---use tsma2
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(2h); --- use tsma2
|
||||
SELECT COUNT(*), MIN(c1) FROM stable WHERE ts < '2023-01-01 10:10:10' INTERVAL(30m); --use tsma1
|
||||
SELECT COUNT(*), MIN(c1) + MIN(c3) FROM stable INTERVAL(30m); ---use tsma1
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(1h) SLIDING(30m); ---use tsma1
|
||||
SELECT COUNT(*), MIN(c1) + MIN(c3) FROM stable INTERVAL(30m); --- use tsma1
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(1h) SLIDING(30m); --- use tsma1
|
||||
SELECT COUNT(*), MIN(c1), SPREAD(c1) FROM stable INTERVAL(1h); ----- can't use tsma1 or tsma2, spread func not defined
|
||||
SELECT COUNT(*), MIN(c1) FROM stable INTERVAL(30s); ----- can't use tsma1 or tsma2, time_duration not fit. Normally, query_time_duration should be multple of create_duration.
|
||||
SELECT COUNT(*), MIN(c1) FROM stable where c2 > 0; ---- can't use tsma1 or tsam2, can't do c2 filtering
|
||||
|
@ -124,15 +125,15 @@ SELECT COUNT(*), MIN(c1) FROM stable where c2 > 0; ---- can't use tsma1 or tsam2
|
|||
|
||||
### 使用限制
|
||||
|
||||
创建TSMA之后, 对原始超级表的操作有以下限制:
|
||||
创建 TSMA 之后,对原始超级表的操作有以下限制:
|
||||
|
||||
- 必须删除该表上的所有TSMA才能删除该表.
|
||||
- 原始表所有tag列不能删除, 也不能修改tag列名或子表的tag值, 必须先删除TSMA, 才能删除tag列.
|
||||
- 若某些列被TSMA使用了, 则这些列不能被删除, 必须先删除TSMA. 添加列不受影响, 但是新添加的列不在任何TSMA中, 因此若要计算新增列, 需要新创建其他的TSMA.
|
||||
- 必须删除该表上的所有 TSMA 才能删除该表。
|
||||
- 原始表所有 tag 列不能删除,也不能修改 tag 列名或子表的 tag 值,必须先删除 TSMA,才能删除 tag 列。
|
||||
- 若某些列被 TSMA 使用了,则这些列不能被删除,必须先删除 TSMA。添加列不受影响,但是新添加的列不在任何 TSMA 中,因此若要计算新增列,需要新创建其他的 TSMA。
|
||||
|
||||
## 查看TSMA
|
||||
```sql
|
||||
SHOW [db_name.]TSMAS;
|
||||
SELECT * FROM information_schema.ins_tsma;
|
||||
```
|
||||
若创建时指定的较多的函数, 且列名较长, 在显示函数列表时可能会被截断(目前最大支持输出256KB).
|
||||
若创建时指定的较多的函数,且列名较长,在显示函数列表时可能会被截断(目前最大支持输出 256KB)。
|
||||
|
|
|
@ -9,15 +9,15 @@ description: "TDengine 3.0 版本的语法变更说明"
|
|||
| # | **元素** | **<div style={{width: 60}}>差异性</div>** | **说明** |
|
||||
| - | :------- | :-------- | :------- |
|
||||
| 1 | VARCHAR | 新增 | BINARY类型的别名。
|
||||
| 2 | TIMESTAMP字面量 | 新增 | 新增支持 TIMESTAMP 'timestamp format' 语法。
|
||||
| 3 | _ROWTS伪列 | 新增 | 表示时间戳主键。是_C0伪列的别名。
|
||||
| 4 | _IROWTS伪列 | 新增 | 用于返回 interp 函数插值结果对应的时间戳列。
|
||||
| 5 | INFORMATION_SCHEMA | 新增 | 包含各种SCHEMA定义的系统数据库。
|
||||
| 2 | TIMESTAMP 字面量 | 新增 | 新增支持 TIMESTAMP 'timestamp format' 语法。
|
||||
| 3 | _ROWTS 伪列 | 新增 | 表示时间戳主键。是_C0伪列的别名。
|
||||
| 4 | _IROWTS 伪列 | 新增 | 用于返回 interp 函数插值结果对应的时间戳列。
|
||||
| 5 | INFORMATION_SCHEMA | 新增 | 包含各种 SCHEMA 定义的系统数据库。
|
||||
| 6 | PERFORMANCE_SCHEMA | 新增 | 包含运行信息的系统数据库。
|
||||
| 7 | 连续查询 | 废除 | 不再支持连续查询。相关的各种语法和接口废除。
|
||||
| 8 | 混合运算 | 增强 | 查询中的混合运算(标量运算和矢量运算混合)全面增强,SELECT的各个子句均全面支持符合语法语义的混合运算。
|
||||
| 8 | 混合运算 | 增强 | 查询中的混合运算(标量运算和矢量运算混合)全面增强,SELECT 的各个子句均全面支持符合语法语义的混合运算。
|
||||
| 9 | 标签运算 | 新增 |在查询中,标签列可以像普通列一样参与各种运算,用于各种子句。
|
||||
| 10 | 时间线子句和时间函数用于超级表查询 | 增强 |没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 10 | 时间线子句和时间函数用于超级表查询 | 增强 |没有 PARTITION BY 时,超级表的数据会被合并成一条时间线。
|
||||
| 11 | GEOMETRY | 新增 | 几何类型。
|
||||
|
||||
## SQL 语句变更
|
||||
|
@ -26,15 +26,15 @@ description: "TDengine 3.0 版本的语法变更说明"
|
|||
|
||||
| # | **语句** | **<div style={{width: 60}}>差异性</div>** | **说明** |
|
||||
| - | :------- | :-------- | :------- |
|
||||
| 1 | ALTER ACCOUNT | 废除 | 2.x中为企业版功能,3.0不再支持。语法暂时保留了,执行报“This statement is no longer supported”错误。
|
||||
| 2 | ALTER ALL DNODES | 新增 | 修改所有DNODE的参数。
|
||||
| 3 | ALTER DATABASE | 调整 | <p>废除</p><ul><li>QUORUM:写入需要的副本确认数。3.0 版本默认行为是强一致性,且不支持修改为弱一致性。</li><li>BLOCKS:VNODE使用的内存块数。3.0版本使用BUFFER来表示VNODE写入内存池的大小。</li><li>UPDATE:更新操作的支持模式。3.0版本所有数据库都支持部分列更新。</li><li>CACHELAST:缓存最新一行数据的模式。3.0版本用CACHEMODEL代替。</li><li>COMP:3.0版本暂不支持修改。</li></ul><p>新增</p><ul><li>CACHEMODEL:表示是否在内存中缓存子表的最近数据。</li><li>CACHESIZE:表示缓存子表最近数据的内存大小。</li><li>WAL_FSYNC_PERIOD:代替原FSYNC参数。</li><li>WAL_LEVEL:代替原WAL参数。</li><li>WAL_RETENTION_PERIOD:3.0.4.0版本新增,wal文件的额外保留策略,用于数据订阅。</li><li>WAL_RETENTION_SIZE:3.0.4.0版本新增,wal文件的额外保留策略,用于数据订阅。</li></ul><p>调整</p><ul><li>KEEP:3.0版本新增支持带单位的设置方式。</li></ul>
|
||||
| 4 | ALTER STABLE | 调整 | 废除<ul><li>CHANGE TAG:修改标签列的名称。3.0版本使用RENAME TAG代替。<br/>新增</li><li>RENAME TAG:代替原CHANGE TAG子句。</li><li>COMMENT:修改超级表的注释。</li></ul>
|
||||
| 5 | ALTER TABLE | 调整 | 废除<ul><li>CHANGE TAG:修改标签列的名称。3.0版本使用RENAME TAG代替。<br/>新增</li><li>RENAME TAG:代替原CHANGE TAG子句。</li><li>COMMENT:修改表的注释。</li><li>TTL:修改表的生命周期。</li></ul>
|
||||
| 6 | ALTER USER | 调整 | 废除<ul><li>PRIVILEGE:修改用户权限。3.0版本使用GRANT和REVOKE来授予和回收权限。<br/>新增</li><li>ENABLE:启用或停用此用户。</li><li>SYSINFO:修改用户是否可查看系统信息。</li></ul>
|
||||
| 7 | COMPACT VNODES | 暂不支持 | 整理指定VNODE的数据。3.0.0版本暂不支持。
|
||||
| 8 | CREATE ACCOUNT | 废除 | 2.x中为企业版功能,3.0不再支持。语法暂时保留了,执行报“This statement is no longer supported”错误。
|
||||
| 9 | CREATE DATABASE | 调整 | <p>废除</p><ul><li>BLOCKS:VNODE使用的内存块数。3.0版本使用BUFFER来表示VNODE写入内存池的大小。</li><li>CACHE:VNODE使用的内存块的大小。3.0版本使用BUFFER来表示VNODE写入内存池的大小。</li><li>CACHELAST:缓存最新一行数据的模式。3.0版本用CACHEMODEL代替。</li><li>DAYS:数据文件存储数据的时间跨度。3.0版本使用DURATION代替。</li><li>FSYNC:当 WAL 设置为 2 时,执行 fsync 的周期。3.0版本使用WAL_FSYNC_PERIOD代替。</li><li>QUORUM:写入需要的副本确认数。3.0版本使用STRICT来指定强一致还是弱一致。</li><li>UPDATE:更新操作的支持模式。3.0版本所有数据库都支持部分列更新。</li><li>WAL:WAL 级别。3.0版本使用WAL_LEVEL代替。</li></ul><p>新增</p><ul><li>BUFFER:一个 VNODE 写入内存池大小。</li><li>CACHEMODEL:表示是否在内存中缓存子表的最近数据。</li><li>CACHESIZE:表示缓存子表最近数据的内存大小。</li><li>DURATION:代替原DAYS参数。新增支持带单位的设置方式。</li><li>PAGES:一个 VNODE 中元数据存储引擎的缓存页个数。</li><li>PAGESIZE:一个 VNODE 中元数据存储引擎的页大小。</li><li>RETENTIONS:表示数据的聚合周期和保存时长。</li><li>STRICT:表示数据同步的一致性要求。</li><li>SINGLE_STABLE:表示此数据库中是否只可以创建一个超级表。</li><li>VGROUPS:数据库中初始VGROUP的数目。</li><li>WAL_FSYNC_PERIOD:代替原FSYNC参数。</li><li>WAL_LEVEL:代替原WAL参数。</li><li>WAL_RETENTION_PERIOD:wal文件的额外保留策略,用于数据订阅。</li><li>WAL_RETENTION_SIZE:wal文件的额外保留策略,用于数据订阅。</li></ul><p>调整</p><ul><li>KEEP:3.0版本新增支持带单位的设置方式。</li></ul>
|
||||
| 1 | ALTER ACCOUNT | 废除 | 2.x 中为企业版功能,3.0 不再支持。语法暂时保留,执行报 “This statement is no longer supported” 错误。
|
||||
| 2 | ALTER ALL DNODES | 新增 | 修改所有 DNODE 的参数。
|
||||
| 3 | ALTER DATABASE | 调整 | <p>废除</p><ul><li>QUORUM:写入需要的副本确认数。3.0 版本默认行为是强一致性,且不支持修改为弱一致性。</li><li>BLOCKS:VNODE使用的内存块数。3.0 版本使用 BUFFER 来表示 VNODE 写入内存池的大小。</li><li>UPDATE:更新操作的支持模式。3.0 版本所有数据库都支持部分列更新。</li><li>CACHELAST:缓存最新一行数据的模式。3.0 版本用 CACHEMODEL 代替。</li><li>COMP:3.0 版本暂不支持修改。</li></ul><p>新增</p><ul><li>CACHEMODEL:表示是否在内存中缓存子表的最近数据。</li><li>CACHESIZE:表示缓存子表最近数据的内存大小。</li><li>WAL_FSYNC_PERIOD:代替原 FSYNC 参数。</li><li>WAL_LEVEL:代替原 WAL 参数。</li><li>WAL_RETENTION_PERIOD:v3.0.4.0 新增,WAL 文件的额外保留策略,用于数据订阅。</li><li>WAL_RETENTION_SIZE:v3.0.4.0 新增,WAL 文件的额外保留策略,用于数据订阅。</li></ul><p>调整</p><ul><li>KEEP:3.0 版本新增支持带单位的设置方式。</li></ul>
|
||||
| 4 | ALTER STABLE | 调整 | 废除<ul><li>CHANGE TAG:修改标签列的名称。3.0 版本使用 RENAME TAG 代替。<br/>新增</li><li>RENAME TAG:代替原 CHANGE TAG 子句。</li><li>COMMENT:修改超级表的注释。</li></ul>
|
||||
| 5 | ALTER TABLE | 调整 | 废除<ul><li>CHANGE TAG:修改标签列的名称。3.0 版本使用 RENAME TAG 代替。<br/>新增</li><li>RENAME TAG:代替原 CHANGE TAG 子句。</li><li>COMMENT:修改表的注释。</li><li>TTL:修改表的生命周期。</li></ul>
|
||||
| 6 | ALTER USER | 调整 | 废除<ul><li>PRIVILEGE:修改用户权限。3.0 版本使用 GRANT 和 REVOKE 来授予和回收权限。<br/>新增</li><li>ENABLE:启用或停用此用户。</li><li>SYSINFO:修改用户是否可查看系统信息。</li></ul>
|
||||
| 7 | COMPACT VNODES | 暂不支持 | 整理指定 VNODE 的数据。
|
||||
| 8 | CREATE ACCOUNT | 废除 | 2.x 中为企业版功能,3.0 不再支持。语法暂时保留,执行报 “This statement is no longer supported” 错误。
|
||||
| 9 | CREATE DATABASE | 调整 | <p>废除</p><ul><li>BLOCKS:VNODE 使用的内存块数。3.0 版本使用 BUFFER 来表示 VNODE 写入内存池的大小。</li><li>CACHE:VNODE 使用的内存块的大小。3.0 版本使用 BUFFER 来表示 VNODE 写入内存池的大小。</li><li>CACHELAST:缓存最新一行数据的模式。3.0 版本用 CACHEMODEL 代替。</li><li>DAYS:数据文件存储数据的时间跨度。3.0 版本使用 DURATION 代替。</li><li>FSYNC:当 WAL 设置为 2 时,执行 fsync 的周期。3.0 版本使用 WAL_FSYNC_PERIOD 代替。</li><li>QUORUM:写入需要的副本确认数。3.0 版本使用 STRICT 来指定强一致还是弱一致。</li><li>UPDATE:更新操作的支持模式。3.0 版本所有数据库都支持部分列更新。</li><li>WAL:WAL 级别。3.0 版本使用 WAL_LEVEL 代替。</li></ul><p>新增</p><ul><li>BUFFER:一个 VNODE 写入内存池大小。</li><li>CACHEMODEL:表示是否在内存中缓存子表的最近数据。</li><li>CACHESIZE:表示缓存子表最近数据的内存大小。</li><li>DURATION:代替原 DAYS 参数。新增支持带单位的设置方式。</li><li>PAGES:一个 VNODE 中元数据存储引擎的缓存页个数。</li><li>PAGESIZE:一个 VNODE 中元数据存储引擎的页大小。</li><li>RETENTIONS:表示数据的聚合周期和保存时长。</li><li>STRICT:表示数据同步的一致性要求。</li><li>SINGLE_STABLE:表示此数据库中是否只可以创建一个超级表。</li><li>VGROUPS:数据库中初始 VGROUP 的数目。</li><li>WAL_FSYNC_PERIOD:代替原 FSYNC 参数。</li><li>WAL_LEVEL:代替原 WAL 参数。</li><li>WAL_RETENTION_PERIOD:WAL 文件的额外保留策略,用于数据订阅。</li><li>WAL_RETENTION_SIZE:WAL 文件的额外保留策略,用于数据订阅。</li></ul><p>调整</p><ul><li>KEEP:3.0 版本新增支持带单位的设置方式。</li></ul>
|
||||
| 10 | CREATE DNODE | 调整 | 新增主机名和端口号分开指定语法<ul><li>CREATE DNODE dnode_host_name PORT port_val</li></ul>
|
||||
| 11 | CREATE INDEX | 新增 | 创建SMA索引。
|
||||
| 12 | CREATE MNODE | 新增 | 创建管理节点。
|
||||
|
@ -43,7 +43,7 @@ description: "TDengine 3.0 版本的语法变更说明"
|
|||
| 15 | CREATE STREAM | 新增 | 创建流。
|
||||
| 16 | CREATE TABLE | 调整 | 新增表参数语法<ul><li>COMMENT:表注释。</li><li>WATERMARK:指定窗口的关闭时间。</li><li>MAX_DELAY:用于控制推送计算结果的最大延迟。</li><li>ROLLUP:指定的聚合函数,提供基于多层级的降采样聚合结果。</li><li>SMA:提供基于数据块的自定义预计算功能。</li><li>TTL:用来指定表的生命周期的参数。</li></ul>
|
||||
| 17 | CREATE TOPIC | 新增 | 创建订阅主题。
|
||||
| 18 | DROP ACCOUNT | 废除 | 2.x中为企业版功能,3.0不再支持。语法暂时保留了,执行报“This statement is no longer supported”错误。
|
||||
| 18 | DROP ACCOUNT | 废除 | 2.x 中为企业版功能,3.0 不再支持。语法暂时保留,执行报 “This statement is no longer supported” 错误。
|
||||
| 19 | DROP CONSUMER GROUP | 新增 | 删除消费组。
|
||||
| 20 | DROP INDEX | 新增 | 删除索引。
|
||||
| 21 | DROP MNODE | 新增 | 创建管理节点。
|
||||
|
@ -54,52 +54,52 @@ description: "TDengine 3.0 版本的语法变更说明"
|
|||
| 26 | EXPLAIN | 新增 | 查看查询语句的执行计划。
|
||||
| 27 | GRANT | 新增 | 授予用户权限。
|
||||
| 28 | KILL TRANSACTION | 新增 | 终止管理节点的事务。
|
||||
| 29 | KILL STREAM | 废除 | 终止连续查询。3.0版本不再支持连续查询,而是用更通用的流计算来代替。
|
||||
| 29 | KILL STREAM | 废除 | 终止连续查询。3.0 版本不再支持连续查询,而是用更通用的流计算来代替。
|
||||
| 31 | REVOKE | 新增 | 回收用户权限。
|
||||
| 32 | SELECT | 调整 | <ul><li>SELECT关闭隐式结果列,输出列均需要由SELECT子句来指定。</li><li>DISTINCT功能全面支持。2.x版本只支持对标签列去重,并且不可以和JOIN、GROUP BY等子句混用。</li><li>JOIN功能增强。增加支持:JOIN后WHERE条件中有OR条件;JOIN后的多表运算;JOIN后的多表GROUP BY。</li><li>FROM后子查询功能大幅增强。不限制子查询嵌套层数;支持子查询和UNION ALL混合使用;移除其他一些之前版本的语法限制。</li><li>WHERE后可以使用任意的标量表达式。</li><li>GROUP BY功能增强。支持任意标量表达式及其组合的分组。</li><li>SESSION可以用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。</li><li>STATE_WINDOW可以用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。</li><li>ORDER BY功能大幅增强。不再必须和GROUP BY子句一起使用;不再有排序表达式个数的限制;增加支持NULLS FIRST/LAST语法功能;支持符合语法语义的任意表达式。</li><li>新增PARTITION BY语法。替代原来的GROUP BY tags。</li></ul>
|
||||
| 33 | SHOW ACCOUNTS | 废除 | 2.x中为企业版功能,3.0不再支持。语法暂时保留了,执行报“This statement is no longer supported”错误。
|
||||
| 32 | SELECT | 调整 | <ul><li>SELECT 关闭隐式结果列,输出列均需要由 SELECT 子句来指定。</li><li>DISTINCT 功能全面支持。2.x 版本只支持对标签列去重,并且不可以和 JOIN、GROUP BY 等子句混用。</li><li>JOIN 功能增强。增加支持:JOIN 后 WHERE 条件中有 OR 条件;JOIN 后的多表运算;JOIN 后的多表 GROUP BY。</li><li>FROM 后子查询功能大幅增强。不限制子查询嵌套层数;支持子查询和 UNION ALL 混合使用;移除其他一些之前版本的语法限制。</li><li>WHERE 后可以使用任意的标量表达式。</li><li>GROUP BY 功能增强。支持任意标量表达式及其组合的分组。</li><li>SESSION 可以用于超级表。之前版本,超级表的数据会被合并成一条时间线。</li><li>STATE_WINDOW 可以用于超级表。之前版本,超级表的数据会被合并成一条时间线。</li><li>ORDER BY 功能大幅增强。不再必须和 GROUP BY 子句一起使用;不再有排序表达式个数的限制;增加支持 NULLS FIRST/LAST 语法功能;支持符合语法语义的任意表达式。</li><li>新增 PARTITION BY 语法。替代原来的 GROUP BY tags。</li></ul>
|
||||
| 33 | SHOW ACCOUNTS | 废除 | 2.x 中为企业版功能,3.0 不再支持。语法暂时保留,执行报 “This statement is no longer supported” 错误。
|
||||
| 34 | SHOW APPS |新增 | 显示接入集群的应用(客户端)信息。
|
||||
| 35 | SHOW CONSUMERS | 新增 | 显示当前数据库下所有活跃的消费者的信息。
|
||||
| 36 | SHOW DATABASES | 调整 | 3.0版本只显示数据库名。
|
||||
| 37 | SHOW FUNCTIONS | 调整 | 3.0版本只显示自定义函数名。
|
||||
| 38 | SHOW LICENCE | 新增 | 和SHOW GRANTS 命令等效。
|
||||
| 36 | SHOW DATABASES | 调整 | 3.0 版本只显示数据库名。
|
||||
| 37 | SHOW FUNCTIONS | 调整 | 3.0 版本只显示自定义函数名。
|
||||
| 38 | SHOW LICENCE | 新增 | 和 SHOW GRANTS 命令等效。
|
||||
| 39 | SHOW INDEXES | 新增 | 显示已创建的索引。
|
||||
| 40 | SHOW LOCAL VARIABLES | 新增 | 显示当前客户端配置参数的运行值。
|
||||
| 41 | SHOW MODULES | 废除 | 显示当前系统中所安装的组件的信息。
|
||||
| 42 | SHOW QNODES | 新增 | 显示当前系统中QNODE的信息。
|
||||
| 43 | SHOW STABLES | 调整 | 3.0版本只显示超级表名。
|
||||
| 44 | SHOW STREAMS | 调整 | 2.x版本此命令显示系统中已创建的连续查询的信息。3.0版本废除了连续查询,用流代替。此命令显示已创建的流。
|
||||
| 43 | SHOW STABLES | 调整 | 3.0 版本只显示超级表名。
|
||||
| 44 | SHOW STREAMS | 调整 | 2.x 版本此命令显示系统中已创建的连续查询的信息。3.0 版本废除了连续查询,用流代替。此命令显示已创建的流。
|
||||
| 45 | SHOW SUBSCRIPTIONS | 新增 | 显示当前数据库下的所有的订阅关系
|
||||
| 46 | SHOW TABLES | 调整 | 3.0版本只显示表名。
|
||||
| 47 | SHOW TABLE DISTRIBUTED | 新增 | 显示表的数据分布信息。代替2.x版本中的SELECT _block_dist() FROM \{ tb_name | stb_name }方式。
|
||||
| 46 | SHOW TABLES | 调整 | 3.0 版本只显示表名。
|
||||
| 47 | SHOW TABLE DISTRIBUTED | 新增 | 显示表的数据分布信息。代替 2.x 版本中的 `SELECT _block_dist() FROM tb_name` 方式。
|
||||
| 48 | SHOW TOPICS | 新增 | 显示当前数据库下的所有订阅主题。
|
||||
| 49 | SHOW TRANSACTIONS | 新增 | 显示当前系统中正在执行的事务的信息。
|
||||
| 50 | SHOW DNODE VARIABLES | 新增 |显示指定DNODE的配置参数。
|
||||
| 51 | SHOW VNODES | 暂不支持 | 显示当前系统中VNODE的信息。3.0.0版本暂不支持。
|
||||
| 50 | SHOW DNODE VARIABLES | 新增 |显示指定 DNODE 的配置参数。
|
||||
| 51 | SHOW VNODES | 暂不支持 | 显示当前系统中 VNODE 的信息。
|
||||
| 52 | TRIM DATABASE | 新增 | 删除过期数据,并根据多级存储的配置归整数据。
|
||||
| 53 | REDISTRIBUTE VGROUP | 新增 | 调整VGROUP中VNODE的分布。
|
||||
| 54 | BALANCE VGROUP | 新增 | 自动调整VGROUP中VNODE的分布。
|
||||
| 53 | REDISTRIBUTE VGROUP | 新增 | 调整 VGROUP 中 VNODE 的分布。
|
||||
| 54 | BALANCE VGROUP | 新增 | 自动调整 VGROUP中 VNODE 的分布。
|
||||
|
||||
## SQL 函数变更
|
||||
|
||||
| # | **函数** | ** <div style={{width: 60}}>差异性</div> ** | **说明** |
|
||||
| - | :------- | :-------- | :------- |
|
||||
| 1 | TWA | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 2 | IRATE | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 3 | LEASTSQUARES | 增强 | 可以用于超级表了。
|
||||
| 4 | ELAPSED | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 5 | DIFF | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 6 | DERIVATIVE | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 7 | CSUM | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 8 | MAVG | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 9 | SAMPLE | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 10 | STATECOUNT | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 11 | STATEDURATION | 增强 | 可以直接用于超级表了。没有PARTITION BY时,超级表的数据会被合并成一条时间线。
|
||||
| 12 | TIMETRUNCATE | 增强 | 增加ignore_timezone参数,可选是否使用,默认值为1.
|
||||
| 1 | TWA | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 2 | IRATE | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 3 | LEASTSQUARES | 增强 | 可以用于超级表。
|
||||
| 4 | ELAPSED | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 5 | DIFF | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 6 | DERIVATIVE | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 7 | CSUM | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 8 | MAVG | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 9 | SAMPLE | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 10 | STATECOUNT | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 11 | STATEDURATION | 增强 | 可以直接用于超级表。之前版本,超级表的数据会被合并成一条时间线。
|
||||
| 12 | TIMETRUNCATE | 增强 | 增加 ignore_timezone 参数,可选是否使用,默认值为 1。
|
||||
|
||||
|
||||
## SCHEMALESS 变更
|
||||
|
||||
| # | **元素** | **<div style={{width: 60}}>差异性</div>** | **说明** |
|
||||
| - | :------- | :-------- | :------- |
|
||||
| 1 | 主键ts 变更为 _ts | 变更 | schemaless自动建的列名用 _ 开头,不同于2.x。
|
||||
| 1 | 主键 ts 变更为 _ts | 变更 | schemaless 自动建的列名用 `_` 开头,不同于2.x。
|
||||
|
|
|
@ -14,9 +14,9 @@ description: 关联查询详细描述
|
|||
|
||||
连接条件是指进行表关联所指定的条件,TDengine 支持的所有关联查询都需要指定连接条件,连接条件通常(Inner Join 和 Window Join 例外)只出现在 `ON` 之后。根据语义,Inner Join 中出现在 `WHERE` 之后的条件也可以视作连接条件,而 Window Join 是通过 `WINDOW_OFFSET` 来指定连接条件。
|
||||
|
||||
除 ASOF Join 外,TDengine 支持的所有 Join 类型都必须显式指定连接条件,ASOF Join 因为默认定义有隐式的连接条件,所以(在默认条件可以满足需求的情况下)可以不必显式指定连接条件。
|
||||
除 ASOF Join 外,TDengine 支持的所有 Join 类型都必须显式指定连接条件,ASOF Join 因为默认定义有隐式的连接条件,所以(在默认条件可以满足需求的情况下)可以不必显式指定连接条件。
|
||||
|
||||
除 ASOF/Window Join 外,连接条件中除了包含主连接条件外,还可以包含任意多条其他连接条件,主连接条件与其他连接条件间必须是 `AND` 关系,而其他连接条件之间则没有这个限制。其他连接条件中可以包含主键列、Tag 、普通列、常量及其标量函数或运算的任意逻辑运算组合。
|
||||
除 ASOF/Window Join 外,连接条件中除了包含主连接条件外,还可以包含任意多条其他连接条件,主连接条件与其他连接条件间必须是 `AND` 关系,而其他连接条件之间则没有这个限制。其他连接条件中可以包含主键列、Tag、普通列、常量及其标量函数或运算的任意逻辑运算组合。
|
||||
|
||||
以智能电表为例,下面这几条 SQL 都包含合法的连接条件:
|
||||
|
||||
|
@ -196,7 +196,7 @@ SELECT ... FROM table_name1 LEFT|RIGHT ASOF JOIN table_name2 [ON ...] [JLIMIT jl
|
|||
- 如果不含 `ON` 子句或 `ON` 子句中未指定主键列的匹配规则,则默认主键匹配规则运算符是 “>=”, 即(对 Left ASOF Join 来说)右表中主键时戳小于等于左表主键时戳的行数据。不支持多个主连接条件。
|
||||
- `ON` 子句中还可以指定除主键列外的 Tag、普通列(不支持标量函数及运算)之间的等值条件用于分组计算,除此之外不支持其他类型的条件。
|
||||
- 所有 ON 条件间只支持 `AND` 运算。
|
||||
- `JLIMIT` 用于指定单行匹配结果的最大行数,可选,未指定时默认值为1,即左/右表每行数据最多从右/左表中获得一行匹配结果。`JLIMIT` 取值范围为 [0, 1024]。符合匹配条件的 `jlimit_num` 条数据不要求时间戳相同,当右/左表中不存在满足条件的 `jlimit_num` 条数据时,返回的结果行数可能小于 `jlimit_num`;当右/左表中存在符合条件的多于 `jlimit_num` 条数据时,如果时间戳相同将随机返回 `jlimit_num` 条数据。
|
||||
- `JLIMIT` 用于指定单行匹配结果的最大行数,可选,未指定时默认值为 1,即左/右表每行数据最多从右/左表中获得一行匹配结果。`JLIMIT` 取值范围为 [0, 1024]。符合匹配条件的 `jlimit_num` 条数据不要求时间戳相同,当右/左表中不存在满足条件的 `jlimit_num` 条数据时,返回的结果行数可能小于 `jlimit_num`;当右/左表中存在符合条件的多于 `jlimit_num` 条数据时,如果时间戳相同将随机返回 `jlimit_num` 条数据。
|
||||
|
||||
#### 示例
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ sidebar_label: 可配置压缩
|
|||
description: 可配置压缩算法
|
||||
---
|
||||
|
||||
从 TDengine 3.3.0.0 版本开始,TDengine 提供了更高级的压缩功能,用户可以在建表时针对每一列配置是否进行压缩、以及使用的压缩算法和压缩级别。
|
||||
从 v3.3.0.0 开始,TDengine 提供了更高级的压缩功能,用户可以在建表时针对每一列配置是否进行压缩、以及使用的压缩算法和压缩级别。
|
||||
|
||||
## 压缩术语定义
|
||||
|
||||
|
@ -15,7 +15,7 @@ description: 可配置压缩算法
|
|||
|
||||
### 压缩级别
|
||||
|
||||
在本文中特指二级压缩算法内部的级别,比如zstd,至少8个level可选,每个level 下都有不同表现,本质是压缩率、压缩速度、解压速度之间的 tradeoff,为了避免选择困难,特简化定义为如下三种级别:
|
||||
在本文中特指二级压缩算法内部的级别,比如 zstd,至少 8 个 level 可选,每个 level 下都有不同表现,本质是压缩率、压缩速度、解压速度之间的 tradeoff,为了避免选择困难,特简化定义为如下三种级别:
|
||||
|
||||
- high:压缩率最高,压缩速度和解压速度相对最差。
|
||||
- low:压缩速度和解压速度最好,压缩率相对最低。
|
||||
|
@ -23,9 +23,9 @@ description: 可配置压缩算法
|
|||
|
||||
### 压缩算法列表
|
||||
|
||||
- 编码算法列表(一级压缩):simple8b, bit-packing,delta-i, delta-d, disabled
|
||||
- 编码算法列表(一级压缩):simple8b、bit-packing、delta-i、delta-d、disabled
|
||||
|
||||
- 压缩算法列表(二级压缩): lz4、zlib、zstd、tsz、xz、disabled
|
||||
- 压缩算法列表(二级压缩):lz4、zlib、zstd、tsz、xz、disabled
|
||||
|
||||
- 各个数据类型的默认压缩算法列表和适用范围
|
||||
|
||||
|
@ -50,9 +50,9 @@ CREATE [dbname.]tabname (colName colType [ENCODE 'encode_type'] [COMPRESS 'compr
|
|||
**参数说明**
|
||||
|
||||
- tabname:超级表或者普通表名称
|
||||
- encode_type: 一级压缩,具体参数见上面列表
|
||||
- compress_type: 二级压缩,具体参数见上面列表
|
||||
- level: 特指二级压缩的级别,默认值为medium, 支持简写为 'h'/'l'/'m'
|
||||
- encode_type:一级压缩,具体参数见上面列表
|
||||
- compress_type:二级压缩,具体参数见上面列表
|
||||
- level:特指二级压缩的级别,默认值为 medium,支持简写为 'h'、'l'、'm'
|
||||
|
||||
**功能说明**
|
||||
|
||||
|
@ -67,8 +67,8 @@ ALTER TABLE [db_name.]tabName MODIFY COLUMN colName [ENCODE 'ecode_type'] [COMPR
|
|||
|
||||
**参数说明**
|
||||
|
||||
- tabName: 表名,可以为超级表、普通表
|
||||
- colName: 待更改压缩算法的列, 只能为普通列
|
||||
- tabName:表名,可以为超级表、普通表
|
||||
- colName:待更改压缩算法的列,只能为普通列
|
||||
|
||||
**功能说明**
|
||||
|
||||
|
@ -87,4 +87,4 @@ DESCRIBE [dbname.]tabName
|
|||
## 兼容性
|
||||
|
||||
- 完全兼容已经存在的数据
|
||||
- 从更低版本升级到 3.3.0.0 后不能回退
|
||||
- 从更低版本升级到 v3.3.0.0 后不能回退
|
||||
|
|
|
@ -4,14 +4,13 @@ title: "视图"
|
|||
sidebar_label: "视图"
|
||||
---
|
||||
|
||||
从 TDengine 3.2.1.0 开始,TDengine 企业版提供视图功能,便于用户简化操作,提升用户间的分享能力。
|
||||
从 v3.2.1.0 开始,TDengine 企业版提供视图功能,便于用户简化操作,提升用户间的分享能力。
|
||||
|
||||
视图(View)本质上是一个存储在数据库中的查询语句。视图(非物化视图)本身不包含数据,只有在从视图读取数据时才动态执行视图所指定的查询语句。我们在创建视图时指定一个名称,然后可以像使用普通表一样对其进行查询等操作。视图的使用需遵循以下规则:
|
||||
- 视图可以嵌套定义和使用,视图与创建时指定的或当前数据库绑定使用。
|
||||
- 在同一个数据库内,视图名称不允许重名,视图名跟表名也推荐不重名(不强制)。当出现视图与表名重名时,写入、查询、授权、回收权限等操作优先使用同名表。
|
||||
|
||||
|
||||
|
||||
## 语法
|
||||
|
||||
### 创建(更新)视图
|
||||
|
@ -58,7 +57,7 @@ DROP VIEW [IF EXISTS] [db_name.]view_name;
|
|||
### 规则
|
||||
- 视图的创建者和 root 用户默认具备所有权限。
|
||||
- 对其他用户进行授权与回收权限可以通过 GRANT 和 REVOKE 语句进行,该操作只能由 root 用户进行。
|
||||
- 视图权限需单独授权与回收,通过db.*进行的授权与回收不含视图权限。
|
||||
- 视图权限需单独授权与回收,通过 db.* 进行的授权与回收不含视图权限。
|
||||
- 视图可以嵌套定义与使用,同理对视图权限的校验也是递归进行的。
|
||||
- 为了方便视图的分享与使用,引入视图有效用户(即视图的创建用户)的概念,被授权用户可以使用视图有效用户的库、表及嵌套视图的读写权限。注:视图被 REPLACE 后有效用户也会被更新。
|
||||
|
||||
|
@ -67,7 +66,7 @@ DROP VIEW [IF EXISTS] [db_name.]view_name;
|
|||
| 序号 | 操作 | 权限要求 |
|
||||
| ---- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | CREATE VIEW <br/>(创建新用户) | 用户对视图所属数据库有 WRITE 权限<br/>且<br/> 用户对视图的目标库、表、视图有查询权限,若查询中的对象是视图需满足当前表中第8条规则 |
|
||||
| 2 | CREATE OR REPLACE VIEW <br/>(覆盖旧视图) | 用户对视图所属数据库有 WRITE 权限 且 对旧有视图有 ALTER 权限 <br/>且<br/> 用户对视图的目标库、表、视图有查询权限,若查询中的对象是视图需满足当前表中第8条规则 |
|
||||
| 2 | CREATE OR REPLACE VIEW <br/>(覆盖旧视图) | 用户对视图所属数据库有 WRITE 权限 且 对旧有视图有 ALTER 权限 <br/>且<br/> 用户对视图的目标库、表、视图有查询权限,若查询中的对象是视图需满足当前表中第 8 条规则 |
|
||||
| 3 | DROP VIEW | 用户对视图有 ALTER 权限 |
|
||||
| 4 | SHOW VIEWS | 无 |
|
||||
| 5 | SHOW CREATE VIEW | 无 |
|
||||
|
|
|
@ -16,7 +16,7 @@ TDengine SQL 是用户对 TDengine 进行数据写入和查询的主要工具。
|
|||
- | 表示多选一,选择其中一个即可,但不能输入 | 本身
|
||||
- … 表示前面的项可重复多个
|
||||
|
||||
为更好地说明 SQL 语法的规则及其特点,本文假设存在一个数据集。以智能电表(meters)为例,假设每个智能电表采集电流、电压、相位三个量。其建模如下:
|
||||
为更好地说明 SQL 语法的规则及其特点,本文假设存在一个数据集。以智能电表(meters)为例,假设每个智能电表采集电流、电压、相位三个量。其建模如下:
|
||||
|
||||
```
|
||||
taos> DESCRIBE meters;
|
||||
|
@ -30,7 +30,7 @@ taos> DESCRIBE meters;
|
|||
groupid | INT | 4 | TAG |
|
||||
```
|
||||
|
||||
数据集包含 4 个智能电表的数据,按照 TDengine 的建模规则,对应 4 个子表,其名称分别是 d1001, d1002, d1003, d1004。
|
||||
数据集包含 4 个智能电表的数据,按照 TDengine 的建模规则,对应 4 个子表,其名称分别是 d1001、d1002、d1003、d1004。
|
||||
|
||||
```mdx-code-block
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
|
|
@ -32,13 +32,13 @@ TDengine 客户端驱动的动态库位于:
|
|||
|
||||
### 支持的平台
|
||||
|
||||
请参考[支持的平台列表](../#支持的平台)
|
||||
请参考 [支持的平台列表](../#支持的平台)
|
||||
|
||||
### 版本历史
|
||||
|
||||
| TDengine 客户端版本 | 主要变化 | TDengine 版本 |
|
||||
| ------------------ | --------------------------- | ---------------- |
|
||||
| 3.3.3.0 | 首次发布,提供了 SQL执行,参数绑定,无模式写入和数据订阅等全面功能支持。 | 3.3.2.0 及更高版本 |
|
||||
| 3.3.3.0 | 首次发布,提供了 SQL 执行,参数绑定,无模式写入和数据订阅等全面功能支持。 | 3.3.2.0 及更高版本 |
|
||||
|
||||
|
||||
### 错误码
|
||||
|
@ -50,7 +50,7 @@ WebSocket 连接方式单独的错误码在 `taosws.h` 中,
|
|||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ------- | -------- | ---------------------------- | ------------------ |
|
||||
| 0xE000 | DSN 错误 | DSN 不符合规范 | 检查 dsn 字符串是否符合规范 |
|
||||
| 0xE001 | 内部错误 | 不确定 | 保留现场和日志,github上报issue |
|
||||
| 0xE001 | 内部错误 | 不确定 | 保留现场和日志,github 上报 issue |
|
||||
| 0xE002 | 连接关闭 | 网络断开 | 请检查网络状况,查看 `taosadapter` 日志。 |
|
||||
| 0xE003 | 发送超时 | 网络断开 | 请检查网络状况 |
|
||||
| 0xE004 | 接收超时 | 慢查询,或者网络断开 | 排查 `taosadapter` 日志 |
|
||||
|
@ -93,16 +93,16 @@ DSN 描述字符串基本结构如下:
|
|||
|
||||
各部分意义见下表:
|
||||
|
||||
- **driver**: 必须指定驱动名以便连接器选择何种方式创建连接,支持如下驱动名:
|
||||
- **taos**: 默认驱动,支持 SQL 执行,参数绑定,无模式写入。
|
||||
- **tmq**: 使用 TMQ 订阅数据。
|
||||
- **protocol**: 显示指定以何种方式建立连接,例如:`taos+ws://localhost:6041` 指定以 WebSocket 方式建立连接。
|
||||
- **http/ws**: 使用 WebSocket 协议。
|
||||
- **https/wss**: 在 WebSocket 连接方式下显示启用 SSL/TLS 协议。
|
||||
- **driver**:必须指定驱动名以便连接器选择何种方式创建连接,支持如下驱动名:
|
||||
- **taos**:默认驱动,支持 SQL 执行,参数绑定,无模式写入。
|
||||
- **tmq**:使用 TMQ 订阅数据。
|
||||
- **protocol**:显示指定以何种方式建立连接,例如:`taos+ws://localhost:6041` 指定以 WebSocket 方式建立连接。
|
||||
- **http/ws**:使用 WebSocket 协议。
|
||||
- **https/wss**:在 WebSocket 连接方式下显示启用 SSL/TLS 协议。
|
||||
|
||||
- **username/password**: 用于创建连接的用户名及密码。
|
||||
- **host/port**: 指定创建连接的服务器及端口,当不指定服务器地址及端口时 WebSocket 连接默认为 `localhost:6041` 。
|
||||
- **database**: 指定默认连接的数据库名,可选参数。
|
||||
- **username/password**:用于创建连接的用户名及密码。
|
||||
- **host/port**:指定创建连接的服务器及端口,当不指定服务器地址及端口时 WebSocket 连接默认为 `localhost:6041` 。
|
||||
- **database**:指定默认连接的数据库名,可选参数。
|
||||
- **params**:其他可选参数。
|
||||
|
||||
一个完整的 DSN 描述字符串示例如下:`taos+ws://localhost:6041/test`, 表示使用 WebSocket(`ws`)方式通过 `6041` 端口连接服务器 `localhost`,并指定默认数据库为 `test`。
|
||||
|
@ -280,7 +280,7 @@ TDengine 推荐数据库应用的每个线程都建立一个独立的连接,
|
|||
- **参数说明**:
|
||||
- stmt:[入参] 指向一个有效的预编译的 SQL 语句对象指针。
|
||||
- bind:[入参] 指向一个有效的 WS_MULTI_BIND 结构体指针,该结构体包含了要批量绑定到 SQL 语句中的参数列表。
|
||||
- len: [入参] bind 数组的元素个数。
|
||||
- len:[入参] bind 数组的元素个数。
|
||||
- **返回值**:`0`:成功。非 `0`:失败,详情请参考错误码页面。
|
||||
|
||||
- `int ws_stmt_set_tbname(WS_STMT *stmt, const char *name)`
|
||||
|
@ -356,8 +356,8 @@ TDengine 推荐数据库应用的每个线程都建立一个独立的连接,
|
|||
协议类型是枚举类型,包含以下三种格式:
|
||||
|
||||
- WS_TSDB_SML_LINE_PROTOCOL:InfluxDB 行协议(Line Protocol)
|
||||
- WS_TSDB_SML_TELNET_PROTOCOL: OpenTSDB Telnet 文本行协议
|
||||
- WS_TSDB_SML_JSON_PROTOCOL: OpenTSDB Json 协议格式
|
||||
- WS_TSDB_SML_TELNET_PROTOCOL:OpenTSDB Telnet 文本行协议
|
||||
- WS_TSDB_SML_JSON_PROTOCOL:OpenTSDB Json 协议格式
|
||||
|
||||
时间戳分辨率的定义,定义在 `taosws.h` 文件中,具体内容如下:
|
||||
|
||||
|
@ -625,9 +625,9 @@ TDengine 服务端或客户端安装后,`taos.h` 位于:
|
|||
|
||||
TDengine 客户端驱动的动态库位于:
|
||||
|
||||
- Linux: `/usr/local/taos/driver/libtaos.so`
|
||||
- Windows: `C:\TDengine\driver\taos.dll`
|
||||
- macOS: `/usr/local/lib/libtaos.dylib`
|
||||
- Linux:`/usr/local/taos/driver/libtaos.so`
|
||||
- Windows:`C:\TDengine\driver\taos.dll`
|
||||
- macOS:`/usr/local/lib/libtaos.dylib`
|
||||
|
||||
### 支持的平台
|
||||
|
||||
|
@ -689,7 +689,7 @@ TDengine 客户端驱动的版本号与 TDengine 服务端的版本号是一一
|
|||
- `int taos_options_connection(TAOS *taos, TSDB_OPTION_CONNECTION option, const void *arg, ...)`
|
||||
- **接口说明**:设置客户端连接选项,目前支持字符集设置(`TSDB_OPTION_CONNECTION_CHARSET`)、时区设置(`TSDB_OPTION_CONNECTION_TIMEZONE`)、用户 IP 设置(`TSDB_OPTION_CONNECTION_USER_IP`)、用户 APP 设置(`TSDB_OPTION_CONNECTION_USER_APP`)。
|
||||
- **参数说明**:
|
||||
- `taos`: [入参] taos_connect 返回的连接句柄。
|
||||
- `taos`:[入参] taos_connect 返回的连接句柄。
|
||||
- `option`:[入参] 设置项类型。
|
||||
- `arg`:[入参] 设置项值。
|
||||
- **返回值**:`0`:成功,`非0`:失败。
|
||||
|
@ -727,7 +727,7 @@ TDengine 客户端驱动的版本号与 TDengine 服务端的版本号是一一
|
|||
- **参数说明**:
|
||||
- ip:[入参] TDengine 集群中任一节点的 FQDN。
|
||||
- user:[入参] 用户名。
|
||||
- auth: [入参] 原始密码取 32 位小写 md5。
|
||||
- auth:[入参] 原始密码取 32 位小写 md5。
|
||||
- db:[入参] 数据库名称,如果用户没有提供,也可以正常连接,用户可以通过该连接创建新的数据库,如果用户提供了数据库名字,则说明该数据库用户已经创建好,缺省使用该数据库。
|
||||
- port:[入参] taosd 程序监听的端口。
|
||||
- **返回值**:返回数据库连接,返回值为空表示失败。应用程序需要保存返回的参数,以便后续使用。
|
||||
|
@ -763,7 +763,7 @@ TDengine 客户端驱动的版本号与 TDengine 服务端的版本号是一一
|
|||
- taos:[入参] 指向数据库连接的指针,数据库连接是通过 `taos_connect()` 函数建立。
|
||||
- fp:[入参] 事件回调函数指针。函数声明:typedef void (*__taos_notify_fn_t)(void *param, void *ext, int type);其中, param 为用户自定义参数,ext 为扩展参数(依赖事件类型,针对 TAOS_NOTIFY_PASSVER 返回用户密码版本),type 为事件类型。
|
||||
- param:[入参] 用户自定义参数。
|
||||
- type:[入参] 事件类型。取值范围:1)TAOS_NOTIFY_PASSVER: 用户密码改变。
|
||||
- type:[入参] 事件类型。取值范围:1)TAOS_NOTIFY_PASSVER:用户密码改变。
|
||||
- **返回值**:`0`:成功,`-1`:失败,可调用函数 taos_errstr(NULL) 获取更详细的错误信息。
|
||||
|
||||
- `void taos_close(TAOS *taos)`
|
||||
|
@ -866,12 +866,12 @@ TDengine 还提供性能更高的异步 API 处理数据插入、查询操作。
|
|||
- **接口说明**:异步执行 SQL 语句。
|
||||
- **参数说明**:
|
||||
- taos:[入参] 指向数据库连接的指针,数据库连接是通过 `taos_connect()` 函数建立。
|
||||
- sql: [入参] 需要执行的 SQL 语句。
|
||||
- sql:[入参] 需要执行的 SQL 语句。
|
||||
- fp:用户定义的回调函数,其第三个参数 `code` 用于指示操作是否成功,`0` 表示成功,负数表示失败(调用 `taos_errstr()` 可获取失败原因)。应用在定义回调函数的时候,主要处理第二个参数 `TAOS_RES *`,该参数是查询返回的结果集。
|
||||
- param:应用提供的用于回调的参数。
|
||||
|
||||
- `void taos_fetch_rows_a(TAOS_RES *res, void (*fp)(void *param, TAOS_RES *, int numOfRows), void *param);`
|
||||
- **接口说明**: 批量获取异步查询的结果集,只能与 `taos_query_a()` 配合使用。
|
||||
- **接口说明**:批量获取异步查询的结果集,只能与 `taos_query_a()` 配合使用。
|
||||
- **参数说明**:
|
||||
- res:`taos_query_a()` 回调时返回的结果集。
|
||||
- fp:回调函数。其参数 `param` 是用户可定义的传递给回调函数的参数结构体;`numOfRows` 是获取到的数据的行数(不是整个查询结果集的函数)。 在回调函数中,应用可以通过调用 `taos_fetch_row()` 前向迭代获取批量记录中每一行记录。读完一块内的所有记录后,应用需要在回调函数中继续调用 `taos_fetch_rows_a()` 获取下一批记录进行处理,直到返回的记录数 `numOfRows` 为零(结果返回完成)或记录数为负值(查询出错)。
|
||||
|
@ -995,8 +995,8 @@ TDengine 的异步 API 均采用非阻塞调用模式。应用程序可以用多
|
|||
协议类型是枚举类型,包含以下三种格式:
|
||||
|
||||
- TSDB_SML_LINE_PROTOCOL:InfluxDB 行协议(Line Protocol)
|
||||
- TSDB_SML_TELNET_PROTOCOL: OpenTSDB Telnet 文本行协议
|
||||
- TSDB_SML_JSON_PROTOCOL: OpenTSDB Json 协议格式
|
||||
- TSDB_SML_TELNET_PROTOCOL:OpenTSDB Telnet 文本行协议
|
||||
- TSDB_SML_JSON_PROTOCOL:OpenTSDB Json 协议格式
|
||||
|
||||
时间戳分辨率的定义,定义在 `taos.h` 文件中,具体内容如下:
|
||||
|
||||
|
|
|
@ -21,8 +21,8 @@ TDengine 的 JDBC 驱动实现尽可能与关系型数据库驱动保持一致
|
|||
|
||||
## JDBC 和 JRE 版本兼容性
|
||||
|
||||
- JDBC: 支持 JDBC 4.2 及以上版本。
|
||||
- JRE: 支持 JRE 8 及以上版本。
|
||||
- JDBC:支持 JDBC 4.2 及以上版本。
|
||||
- JRE:支持 JRE 8 及以上版本。
|
||||
|
||||
## 支持的平台
|
||||
|
||||
|
@ -101,7 +101,7 @@ JDBC 连接器可能报错的错误码包括 4 种:
|
|||
| 0x2318 | | REST 连接中出现了数据传输异常,请检查网络情况并重试。 |
|
||||
| 0x2319 | user is required | 创建连接时缺少用户名信息 |
|
||||
| 0x231a | password is required | 创建连接时缺少密码信息 |
|
||||
| 0x231c | httpEntity is null, sql: | REST 连接中执行出现异常 |
|
||||
| 0x231c | httpEntity is null, sql | REST 连接中执行出现异常 |
|
||||
| 0x231d | can't create connection with server within | 通过增加参数 httpConnectTimeout 增加连接耗时,或是请检查与 taosAdapter 之间的连接情况。 |
|
||||
| 0x231e | failed to complete the task within the specified time | 通过增加参数 messageWaitTimeout 增加执行耗时,或是请检查与 taosAdapter 之间的连接情况。 |
|
||||
| 0x2350 | unknown error | 未知异常,请在 github 反馈给开发人员。 |
|
||||
|
@ -162,7 +162,7 @@ WKB规范请参考[Well-Known Binary (WKB)](https://libgeos.org/specifications/w
|
|||
- connectionPools:HikariCP, Druid, dbcp, c3p0 等连接池中使用 taos-jdbcdriver。
|
||||
- SpringJdbcTemplate:Spring JdbcTemplate 中使用 taos-jdbcdriver。
|
||||
- mybatisplus-demo:Springboot + Mybatis 中使用 taos-jdbcdriver。
|
||||
- springbootdemo: Springboot 中使用 taos-jdbcdriver。
|
||||
- springbootdemo:Springboot 中使用 taos-jdbcdriver。
|
||||
- consumer-demo:Consumer 消费 TDengine 数据示例,可通过参数控制消费速度。
|
||||
|
||||
请参考:[JDBC example](https://github.com/taosdata/TDengine/tree/main/docs/examples/JDBC)
|
||||
|
@ -191,13 +191,13 @@ WKB规范请参考[Well-Known Binary (WKB)](https://libgeos.org/specifications/w
|
|||
|
||||
**原因**:taos-jdbcdriver 3.\* 版本仅支持 TDengine 3.0 及以上版本。
|
||||
|
||||
**解决方法**: 使用 taos-jdbcdriver 2.\* 版本连接 TDengine 2.\* 版本。
|
||||
**解决方法**:使用 taos-jdbcdriver 2.\* 版本连接 TDengine 2.\* 版本。
|
||||
|
||||
5. java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; ... taos-jdbcdriver-3.0.1.jar
|
||||
|
||||
**原因**:taos-jdbcdriver 3.0.1 版本需要在 JDK 11+ 环境使用。
|
||||
|
||||
**解决方法**: 更换 taos-jdbcdriver 3.0.2+ 版本。
|
||||
**解决方法**:更换 taos-jdbcdriver 3.0.2+ 版本。
|
||||
|
||||
其它问题请参考 [FAQ](../../../train-faq/faq)
|
||||
|
||||
|
@ -226,7 +226,7 @@ TDengine 的 JDBC URL 规范格式为:
|
|||
- charset:客户端使用的字符集,默认值为系统字符集。
|
||||
- locale:客户端语言环境,默认值系统当前 locale。
|
||||
- timezone:客户端使用的时区,默认值为系统当前时区。
|
||||
- batchfetch: true:在执行查询时批量拉取结果集;false:逐行拉取结果集。默认值为:true。开启批量拉取同时获取一批数据在查询数据量较大时批量拉取可以有效的提升查询性能。
|
||||
- batchfetch:true:在执行查询时批量拉取结果集;false:逐行拉取结果集。默认值为:true。开启批量拉取同时获取一批数据在查询数据量较大时批量拉取可以有效的提升查询性能。
|
||||
- batchErrorIgnore:true:在执行 Statement 的 executeBatch 时,如果中间有一条 SQL 执行失败将继续执行下面的 SQL。false:不再执行失败 SQL 后的任何语句。默认值为:false。
|
||||
|
||||
JDBC 原生连接的使用请参见[视频教程](https://www.taosdata.com/blog/2020/11/11/1955.html)。
|
||||
|
@ -251,9 +251,9 @@ TDengine 中,只要保证 firstEp 和 secondEp 中一个节点有效,就可
|
|||
- user:登录 TDengine 用户名,默认值 'root'。
|
||||
- password:用户登录密码,默认值 'taosdata'。
|
||||
- batchErrorIgnore:true:在执行 Statement 的 executeBatch 时,如果中间有一条 SQL 执行失败,继续执行下面的 SQL 了。false:不再执行失败 SQL 后的任何语句。默认值为:false。
|
||||
- httpConnectTimeout: 连接超时时间,单位 ms, 默认值为 60000。
|
||||
- messageWaitTimeout: 消息超时时间, 单位 ms, 默认值为 60000。
|
||||
- useSSL: 连接中是否使用 SSL。
|
||||
- httpConnectTimeout:连接超时时间,单位 ms, 默认值为 60000。
|
||||
- messageWaitTimeout:消息超时时间, 单位 ms, 默认值为 60000。
|
||||
- useSSL:连接中是否使用 SSL。
|
||||
- timezone:客户端使用的时区,连接上生效,默认值为系统时区。推荐不设置,使用系统时区性能更好。
|
||||
|
||||
**注意**:部分配置项(比如:locale、charset)在 WebSocket 连接中不生效。
|
||||
|
@ -269,10 +269,10 @@ TDengine 中,只要保证 firstEp 和 secondEp 中一个节点有效,就可
|
|||
- user:登录 TDengine 用户名,默认值 'root'。
|
||||
- password:用户登录密码,默认值 'taosdata'。
|
||||
- batchErrorIgnore:true:在执行 Statement 的 executeBatch 时,如果中间有一条 SQL 执行失败,继续执行下面的 SQL 了。false:不再执行失败 SQL 后的任何语句。默认值为:false。
|
||||
- httpConnectTimeout: 连接超时时间,单位 ms, 默认值为 60000。
|
||||
- httpSocketTimeout: socket 超时时间,单位 ms,默认值为 60000。
|
||||
- useSSL: 连接中是否使用 SSL。
|
||||
- httpPoolSize: REST 并发请求大小,默认 20。
|
||||
- httpConnectTimeout:连接超时时间,单位 ms, 默认值为 60000。
|
||||
- httpSocketTimeout:socket 超时时间,单位 ms,默认值为 60000。
|
||||
- useSSL:连接中是否使用 SSL。
|
||||
- httpPoolSize:REST 并发请求大小,默认 20。
|
||||
|
||||
**注意**:部分配置项(比如:locale、charset 和 timezone)在 REST 连接中不生效。
|
||||
|
||||
|
@ -292,7 +292,7 @@ TDengine 中,只要保证 firstEp 和 secondEp 中一个节点有效,就可
|
|||
properties 中的配置参数如下:
|
||||
- TSDBDriver.PROPERTY_KEY_USER:登录 TDengine 用户名,默认值 'root'。
|
||||
- TSDBDriver.PROPERTY_KEY_PASSWORD:用户登录密码,默认值 'taosdata'。
|
||||
- TSDBDriver.PROPERTY_KEY_BATCH_LOAD: true:在执行查询时批量拉取结果集;false:逐行拉取结果集。默认值为:false。因历史原因使用 REST 连接时,若设置此参数为 true 会变成 WebSocket 连接。
|
||||
- TSDBDriver.PROPERTY_KEY_BATCH_LOAD:true:在执行查询时批量拉取结果集;false:逐行拉取结果集。默认值为:false。因历史原因使用 REST 连接时,若设置此参数为 true 会变成 WebSocket 连接。
|
||||
- TSDBDriver.PROPERTY_KEY_BATCH_ERROR_IGNORE:true:在执行 Statement 的 executeBatch 时,如果中间有一条 SQL 执行失败,继续执行下面的 sq 了。false:不再执行失败 SQL 后的任何语句。默认值为:false。
|
||||
- TSDBDriver.PROPERTY_KEY_CONFIG_DIR:仅在使用 JDBC 原生连接时生效。客户端配置文件目录路径,Linux OS 上默认值 `/etc/taos`,Windows OS 上默认值 `C:/TDengine/cfg`。
|
||||
- TSDBDriver.PROPERTY_KEY_CHARSET:客户端使用的字符集,默认值为系统字符集。
|
||||
|
@ -300,21 +300,21 @@ properties 中的配置参数如下:
|
|||
- TSDBDriver.PROPERTY_KEY_TIME_ZONE:
|
||||
- 原生连接:客户端使用的时区,默认值为系统当前时区,全局生效。因为历史的原因,我们只支持POSIX标准的部分规范,如UTC-8(代表中国上上海), GMT-8,Asia/Shanghai 这几种形式。
|
||||
- WebSocket 连接:客户端使用的时区,连接上生效,默认值为系统时区。仅支持 IANA 时区,即 Asia/Shanghai 这种形式。推荐不设置,使用系统时区性能更好。
|
||||
- TSDBDriver.HTTP_CONNECT_TIMEOUT: 连接超时时间,单位 ms, 默认值为 60000。仅在 REST 连接时生效。
|
||||
- TSDBDriver.HTTP_SOCKET_TIMEOUT: socket 超时时间,单位 ms,默认值为 60000。仅在 REST 连接且 batchfetch 设置为 false 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_MESSAGE_WAIT_TIMEOUT: 消息超时时间, 单位 ms, 默认值为 60000。 仅 WebSocket 连接下有效。
|
||||
- TSDBDriver.PROPERTY_KEY_USE_SSL: 连接中是否使用 SSL。仅在 WebSocket/REST 连接时生效。
|
||||
- TSDBDriver.HTTP_POOL_SIZE: REST 并发请求大小,默认 20。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_COMPRESSION: 传输过程是否启用压缩。仅在使用 REST/WebSocket 连接时生效。true: 启用,false: 不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_AUTO_RECONNECT: 是否启用自动重连。仅在使用 WebSocket 连接时生效。true: 启用,false: 不启用。默认为 false。
|
||||
- TSDBDriver.HTTP_CONNECT_TIMEOUT:连接超时时间,单位 ms, 默认值为 60000。仅在 REST 连接时生效。
|
||||
- TSDBDriver.HTTP_SOCKET_TIMEOUT:socket 超时时间,单位 ms,默认值为 60000。仅在 REST 连接且 batchfetch 设置为 false 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_MESSAGE_WAIT_TIMEOUT:消息超时时间, 单位 ms, 默认值为 60000。 仅 WebSocket 连接下有效。
|
||||
- TSDBDriver.PROPERTY_KEY_USE_SSL:连接中是否使用 SSL。仅在 WebSocket/REST 连接时生效。
|
||||
- TSDBDriver.HTTP_POOL_SIZE:REST 并发请求大小,默认 20。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_COMPRESSION:传输过程是否启用压缩。仅在使用 REST/WebSocket 连接时生效。true:启用,false:不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_AUTO_RECONNECT:是否启用自动重连。仅在使用 WebSocket 连接时生效。true:启用,false:不启用。默认为 false。
|
||||
> **注意**:启用自动重连仅对简单执行 SQL 语句以及 无模式写入、数据订阅有效。对于参数绑定无效。自动重连仅对连接建立时通过参数指定数据库有效,对后面的 `use db` 语句切换数据库无效。
|
||||
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_INTERVAL_MS: 自动重连重试间隔,单位毫秒,默认值 2000。仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_RETRY_COUNT: 自动重连重试次数,默认值 3,仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_DISABLE_SSL_CERT_VALIDATION: 关闭 SSL 证书验证 。仅在使用 WebSocket 连接时生效。true: 启用,false: 不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_INTERVAL_MS:自动重连重试间隔,单位毫秒,默认值 2000。仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_RETRY_COUNT:自动重连重试次数,默认值 3,仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_DISABLE_SSL_CERT_VALIDATION:关闭 SSL 证书验证 。仅在使用 WebSocket 连接时生效。true:启用,false:不启用。默认为 false。
|
||||
|
||||
- TSDBDriver.PROPERTY_KEY_APP_NAME: App 名称,可用于 `show connections` 查询结果显示。仅在使用 WebSocket 连接时生效。默认值为 java。
|
||||
- TSDBDriver.PROPERTY_KEY_APP_IP: App IP,可用于 `show connections` 查询结果显示。仅在使用 WebSocket 连接时生效。默认值为空。
|
||||
- TSDBDriver.PROPERTY_KEY_APP_NAME:App 名称,可用于 `show connections` 查询结果显示。仅在使用 WebSocket 连接时生效。默认值为 java。
|
||||
- TSDBDriver.PROPERTY_KEY_APP_IP:App IP,可用于 `show connections` 查询结果显示。仅在使用 WebSocket 连接时生效。默认值为空。
|
||||
|
||||
此外对 JDBC 原生连接,通过指定 URL 和 Properties 还可以指定其他参数,比如日志级别、SQL 长度等。
|
||||
|
||||
|
@ -1177,7 +1177,7 @@ JDBC 驱动支持标准的 ResultSet 接口,提供了用于读取结果集中
|
|||
|
||||
### 参数绑定
|
||||
PreparedStatement 允许使用预编译的 SQL 语句,这可以提高性能并提供参数化查询的能力,从而增加安全性。
|
||||
JDBC 驱动提供了实现 PreparedStatement 接口的两个类:
|
||||
JDBC 驱动提供了实现 PreparedStatement 接口的两个类:
|
||||
1. 对应原生连接的 TSDBPreparedStatement
|
||||
2. 对应 WebSocket 连接的 TSWSPreparedStatement
|
||||
|
||||
|
@ -1337,7 +1337,7 @@ ParameterMetaData 提供了参数元数据接口:
|
|||
- `size`:所有字符串的最大长度,一般为建表语句的限制值。
|
||||
- **异常**:
|
||||
- 如果操作过程中发生错误,将抛出 SQLException 异常。
|
||||
- 下面接口除了要设置的值类型不同外,其余同 setString:
|
||||
- 下面接口除了要设置的值类型不同外,其余同 setString:
|
||||
- `void setVarbinary(int columnIndex, ArrayList<byte[]> list, int size) throws SQLException`
|
||||
- `void setGeometry(int columnIndex, ArrayList<byte[]> list, int size) throws SQLException`
|
||||
- `void setNString(int columnIndex, ArrayList<String> list, int size) throws SQLException`
|
||||
|
@ -1363,19 +1363,19 @@ JDBC 标准不支持数据订阅,因此本章所有接口都是扩展接口。
|
|||
- **返回值**:消费者对象
|
||||
- **异常**:如果创建失败,抛出 SQLException 异常。
|
||||
|
||||
创建消费者支持属性列表:
|
||||
- td.connect.type: 连接方式。jni:表示使用动态库连接的方式,ws/WebSocket:表示使用 WebSocket 进行数据通信。默认为 jni 方式。
|
||||
- bootstrap.servers: TDengine 服务端所在的`ip:port`,如果使用 WebSocket 连接,则为 taosAdapter 所在的`ip:port`。
|
||||
- enable.auto.commit: 是否允许自动提交。
|
||||
- group.id: consumer: 所在的 group。
|
||||
- value.deserializer: 结果集反序列化方法,可以继承 `com.taosdata.jdbc.tmq.ReferenceDeserializer`,并指定结果集 bean,实现反序列化。也可以继承 `com.taosdata.jdbc.tmq.Deserializer`,根据 SQL 的 resultSet 自定义反序列化方式。
|
||||
- httpConnectTimeout: 创建连接超时参数,单位 ms,默认为 5000 ms。仅在 WebSocket 连接下有效。
|
||||
- messageWaitTimeout: 数据传输超时参数,单位 ms,默认为 10000 ms。仅在 WebSocket 连接下有效。
|
||||
- httpPoolSize: 同一个连接下最大并行请求数。仅在 WebSocket 连接下有效。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_COMPRESSION: 传输过程是否启用压缩。仅在使用 WebSocket 连接时生效。true: 启用,false: 不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_AUTO_RECONNECT: 是否启用自动重连。仅在使用 WebSocket 连接时生效。true: 启用,false: 不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_INTERVAL_MS: 自动重连重试间隔,单位毫秒,默认值 2000。仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_RETRY_COUNT: 自动重连重试次数,默认值 3,仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
创建消费者支持属性列表:
|
||||
- td.connect.type:连接方式。jni:表示使用动态库连接的方式,ws/WebSocket:表示使用 WebSocket 进行数据通信。默认为 jni 方式。
|
||||
- bootstrap.servers:TDengine 服务端所在的`ip:port`,如果使用 WebSocket 连接,则为 taosAdapter 所在的`ip:port`。
|
||||
- enable.auto.commit:是否允许自动提交。
|
||||
- group.id:consumer:所在的 group。
|
||||
- value.deserializer:结果集反序列化方法,可以继承 `com.taosdata.jdbc.tmq.ReferenceDeserializer`,并指定结果集 bean,实现反序列化。也可以继承 `com.taosdata.jdbc.tmq.Deserializer`,根据 SQL 的 resultSet 自定义反序列化方式。
|
||||
- httpConnectTimeout:创建连接超时参数,单位 ms,默认为 5000 ms。仅在 WebSocket 连接下有效。
|
||||
- messageWaitTimeout:数据传输超时参数,单位 ms,默认为 10000 ms。仅在 WebSocket 连接下有效。
|
||||
- httpPoolSize:同一个连接下最大并行请求数。仅在 WebSocket 连接下有效。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_COMPRESSION:传输过程是否启用压缩。仅在使用 WebSocket 连接时生效。true:启用,false:不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_ENABLE_AUTO_RECONNECT:是否启用自动重连。仅在使用 WebSocket 连接时生效。true:启用,false:不启用。默认为 false。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_INTERVAL_MS:自动重连重试间隔,单位毫秒,默认值 2000。仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
- TSDBDriver.PROPERTY_KEY_RECONNECT_RETRY_COUNT:自动重连重试次数,默认值 3,仅在 PROPERTY_KEY_ENABLE_AUTO_RECONNECT 为 true 时生效。
|
||||
|
||||
其他参数请参考:[Consumer 参数列表](../../../develop/tmq/#创建参数), 注意TDengine服务端自 3.2.0.0 版本开始消息订阅中的 auto.offset.reset 默认值发生变化。
|
||||
|
||||
|
|
|
@ -109,15 +109,15 @@ DSN 描述字符串基本结构如下:
|
|||
|
||||
各部分意义见下表:
|
||||
|
||||
- **driver**: 必须指定驱动名以便连接器选择何种方式创建连接,支持如下驱动名:
|
||||
- **taos**: 使用 TDengine 连接器驱动,默认是使用 taos 驱动。
|
||||
- **tmq**: 使用 TMQ 订阅数据。
|
||||
- **protocol**: 显示指定以何种方式建立连接,例如:`taos+ws://localhost:6041` 指定以 WebSocket 方式建立连接。
|
||||
- **http/ws**: 使用 WebSocket 创建连接。
|
||||
- **https/wss**: 在 WebSocket 连接方式下显示启用 SSL/TLS 连接。
|
||||
- **username/password**: 用于创建连接的用户名及密码。
|
||||
- **host/port**: 指定创建连接的服务器及端口,当不指定服务器地址及端口时(`taos://`),原生连接默认为 `localhost:6030`,WebSocket 连接默认为 `localhost:6041` 。
|
||||
- **database**: 指定默认连接的数据库名,可选参数。
|
||||
- **driver**:必须指定驱动名以便连接器选择何种方式创建连接,支持如下驱动名:
|
||||
- **taos**:使用 TDengine 连接器驱动,默认是使用 taos 驱动。
|
||||
- **tmq**:使用 TMQ 订阅数据。
|
||||
- **protocol**:显示指定以何种方式建立连接,例如:`taos+ws://localhost:6041` 指定以 WebSocket 方式建立连接。
|
||||
- **http/ws**:使用 WebSocket 创建连接。
|
||||
- **https/wss**:在 WebSocket 连接方式下显示启用 SSL/TLS 连接。
|
||||
- **username/password**:用于创建连接的用户名及密码。
|
||||
- **host/port**:指定创建连接的服务器及端口,当不指定服务器地址及端口时(`taos://`),原生连接默认为 `localhost:6030`,WebSocket 连接默认为 `localhost:6041` 。
|
||||
- **database**:指定默认连接的数据库名,可选参数。
|
||||
- **params**:其他可选参数。
|
||||
|
||||
一个完整的 DSN 描述字符串示例如下:`taos+ws://localhost:6041/test`, 表示使用 WebSocket(`ws`)方式通过 `6041` 端口连接服务器 `localhost`,并指定默认数据库为 `test`。
|
||||
|
@ -596,6 +596,6 @@ Offset 结构体提供了获取当前消息所属的数据库,主题和分区
|
|||
## 附录
|
||||
|
||||
- Rust 连接器文档:https://docs.rs/taos
|
||||
- Rust 连接器项目地址: https://github.com/taosdata/taos-connector-rust
|
||||
- deadpool 连接池: https://crates.io/crates/deadpool
|
||||
- r2d2 连接池: https://crates.io/crates/r2d2
|
||||
- Rust 连接器项目地址:https://github.com/taosdata/taos-connector-rust
|
||||
- deadpool 连接池:https://crates.io/crates/deadpool
|
||||
- r2d2 连接池:https://crates.io/crates/r2d2
|
||||
|
|
|
@ -63,7 +63,7 @@ Python Connector 历史版本(建议使用最新版本的 `taospy`):
|
|||
| 2.7.9 | 数据订阅支持获取消费进度和重置消费进度 | 3.0.2.6 及更高版本 |
|
||||
| 2.7.8 | 新增 `execute_many` | 3.0.0.0 及更高版本 |
|
||||
|
||||
WebSocket Connector 历史版本:
|
||||
WebSocket Connector 历史版本:
|
||||
|
||||
|
||||
| WebSocket Connector 版本 | 主要变化 | TDengine 版本 |
|
||||
|
@ -168,24 +168,24 @@ TDengine 目前支持时间戳、数字、字符、布尔类型,与 Python 对
|
|||
| protocol | | username | password | host | port | database | params |
|
||||
```
|
||||
|
||||
- **protocol**: 使用 websocket 协议建立连接。例如`ws://localhost:6041`
|
||||
- **username/password**: 数据库的用户名和密码。
|
||||
- **host/port**: 主机地址和端口号。例如`localhost:6041`
|
||||
- **database**: 数据库名称。
|
||||
- **params**: 其他参数。 例如token。
|
||||
- **protocol**:使用 websocket 协议建立连接。例如`ws://localhost:6041`
|
||||
- **username/password**:数据库的用户名和密码。
|
||||
- **host/port**:主机地址和端口号。例如`localhost:6041`
|
||||
- **database**:数据库名称。
|
||||
- **params**:其他参数。 例如token。
|
||||
|
||||
#### 建立连接
|
||||
|
||||
- `fn connect(dsn: Option<&str>, args: Option<&PyDict>) -> PyResult<Connection>`
|
||||
- **接口说明**:建立 taosAdapter 连接。
|
||||
- **参数说明**:
|
||||
- `dsn`: 类型 `Option<&str>` 可选,数据源名称(DSN),用于指定要连接的数据库的位置和认证信息。
|
||||
- `args`: 类型 `Option<&PyDict>` 可选,以 Python 字典的形式提供, 可用于设置
|
||||
- `user`: 数据库的用户名
|
||||
- `password`: 数据库的密码。
|
||||
- `host`: 主机地址
|
||||
- `port`: 端口号
|
||||
- `database`: 数据库名称
|
||||
- `dsn`:类型 `Option<&str>` 可选,数据源名称(DSN),用于指定要连接的数据库的位置和认证信息。
|
||||
- `args`:类型 `Option<&PyDict>` 可选,以 Python 字典的形式提供, 可用于设置
|
||||
- `user`:数据库的用户名
|
||||
- `password`:数据库的密码。
|
||||
- `host`:主机地址
|
||||
- `port`:端口号
|
||||
- `database`:数据库名称
|
||||
- **返回值**:连接对象。
|
||||
- **异常**:操作失败抛出 `ConnectionError` 异常。
|
||||
- `fn cursor(&self) -> PyResult<Cursor>`
|
||||
|
@ -205,7 +205,7 @@ TDengine 目前支持时间戳、数字、字符、布尔类型,与 Python 对
|
|||
- **接口说明**:执行带有 req_id 的 sql 语句。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的 sql 语句。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:影响的条数。
|
||||
- **异常**:操作失败抛出 `QueryError` 异常。
|
||||
- `fn query(&self, sql: &str) -> PyResult<TaosResult>`
|
||||
|
@ -218,7 +218,7 @@ TDengine 目前支持时间戳、数字、字符、布尔类型,与 Python 对
|
|||
- **接口说明**:查询带有 req_id 的 sql 语句。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的 sql 语句。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:`TaosResult` 数据集对象。
|
||||
- **异常**:操作失败抛出 `QueryError` 异常。
|
||||
|
||||
|
@ -238,19 +238,19 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- **接口说明**:无模式写入。
|
||||
- **参数说明**:
|
||||
- `lines`:待写入的数据数组,无模式具体的数据格式可参考 `Schemaless 写入`。
|
||||
- `protocol`: 协议类型
|
||||
- `PySchemalessProtocol::Line`: InfluxDB 行协议(Line Protocol)。
|
||||
- `protocol`:协议类型
|
||||
- `PySchemalessProtocol::Line`:InfluxDB 行协议(Line Protocol)。
|
||||
- `PySchemalessProtocol::Telnet`:OpenTSDB 文本行协议。
|
||||
- `PySchemalessProtocol::Json`: JSON 协议格式
|
||||
- `precision`: 时间精度
|
||||
- `PySchemalessPrecision::Hour`: 小时
|
||||
- `PySchemalessProtocol::Json`:JSON 协议格式
|
||||
- `precision`:时间精度
|
||||
- `PySchemalessPrecision::Hour`:小时
|
||||
- `PySchemalessPrecision::Minute`:分钟
|
||||
- `PySchemalessPrecision::Second` 秒
|
||||
- `PySchemalessPrecision::Millisecond`:毫秒
|
||||
- `PySchemalessPrecision::Microsecond`:微秒
|
||||
- `PySchemalessPrecision::Nanosecond`: 纳秒
|
||||
- `PySchemalessPrecision::Nanosecond`:纳秒
|
||||
- `ttl`:表过期时间,单位天。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **异常**:操作失败抛出 `DataError` 或 `OperationalError` 异常。
|
||||
|
||||
#### 参数绑定
|
||||
|
@ -261,22 +261,22 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `fn prepare(&mut self, sql: &str) -> PyResult<()>`
|
||||
- **接口说明**:绑定预编译 sql 语句。
|
||||
- **参数说明**:
|
||||
- `sql`: 预编译的 SQL 语句。
|
||||
- `sql`:预编译的 SQL 语句。
|
||||
- **异常**:操作失败抛出 `ProgrammingError` 异常。
|
||||
- `fn set_tbname(&mut self, table_name: &str) -> PyResult<()>`
|
||||
- **接口说明**:设置将要写入数据的表名。
|
||||
- **参数说明**:
|
||||
- `tableName`: 表名,如果需要指定数据库, 例如: `db_name.table_name` 即可。
|
||||
- `tableName`:表名,如果需要指定数据库, 例如:`db_name.table_name` 即可。
|
||||
- **异常**:操作失败抛出 `ProgrammingError` 异常。
|
||||
- `fn set_tags(&mut self, tags: Vec<PyTagView>) -> PyResult<()>`
|
||||
- **接口说明**:设置表 Tags 数据, 用于自动建表。
|
||||
- **参数说明**:
|
||||
- `paramsArray`: Tags 数据。
|
||||
- `paramsArray`:Tags 数据。
|
||||
- **异常**:操作失败抛出 `ProgrammingError` 异常。
|
||||
- `fn bind_param(&mut self, params: Vec<PyColumnView>) -> PyResult<()>`
|
||||
- **接口说明**:绑定数据。
|
||||
- **参数说明**:
|
||||
- `paramsArray`: 绑定数据。
|
||||
- `paramsArray`:绑定数据。
|
||||
- **异常**:操作失败抛出 `ProgrammingError` 异常。
|
||||
- `fn add_batch(&mut self) -> PyResult<()>`
|
||||
- **接口说明**:提交绑定数据。
|
||||
|
@ -286,10 +286,10 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- **返回值**:写入条数。
|
||||
- **异常**:操作失败抛出 `QueryError` 异常。
|
||||
- `fn affect_rows(&mut self) -> PyResult<usize>`
|
||||
- **接口说明**: 获取写入条数。
|
||||
- **接口说明**:获取写入条数。
|
||||
- **返回值**:写入条数。
|
||||
- `fn close(&self) -> PyResult<()>`
|
||||
- **接口说明**: 关闭 stmt 对象。
|
||||
- **接口说明**:关闭 stmt 对象。
|
||||
|
||||
|
||||
#### 数据订阅
|
||||
|
@ -298,8 +298,8 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- port:端口号。
|
||||
- group.id:所在的 group。
|
||||
- client.id:客户端id。
|
||||
- td.connect.user: 数据库用户名。
|
||||
- td.connect.pass: 数据库密码。
|
||||
- td.connect.user:数据库用户名。
|
||||
- td.connect.pass:数据库密码。
|
||||
- td.connect.token:数据库的连接token。
|
||||
- auto.offset.reset:来确定消费位置为最新数据(latest)还是包含旧数据(earliest)。
|
||||
- enable.auto.commit:是否允许自动提交。
|
||||
|
@ -307,14 +307,14 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
|
||||
- `fn Consumer(conf: Option<&PyDict>, dsn: Option<&str>) -> PyResult<Self>`
|
||||
- **接口说明** 消费者构造函数。
|
||||
- `conf`: 类型 `Option<&PyDict>` 可选,以 Python 字典的形式提供, 具体配置参见属性列表。
|
||||
- `dsn`: 类型 `Option<&str>` 可选,数据源名称(DSN),用于指定要连接的数据库的位置和认证信息。
|
||||
- `conf`:类型 `Option<&PyDict>` 可选,以 Python 字典的形式提供, 具体配置参见属性列表。
|
||||
- `dsn`:类型 `Option<&str>` 可选,数据源名称(DSN),用于指定要连接的数据库的位置和认证信息。
|
||||
- **返回值**:Consumer 消费者对象。
|
||||
- **异常**:操作失败抛出 `ConsumerException` 异常。
|
||||
- `fn subscribe(&mut self, topics: &PyList) -> PyResult<()>`
|
||||
- **接口说明** 订阅一组主题。
|
||||
- **参数说明**:
|
||||
- `topics`: 订阅的主题列表。
|
||||
- `topics`:订阅的主题列表。
|
||||
- **异常**:操作失败抛出 `ConsumerException` 异常。
|
||||
- `fn unsubscribe(&mut self)`
|
||||
- **接口说明** 取消订阅。
|
||||
|
@ -322,13 +322,13 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `fn poll(&mut self, timeout: Option<f64>) -> PyResult<Option<Message>>`
|
||||
- **接口说明** 轮询消息。
|
||||
- **参数说明**:
|
||||
- `timeoutMs`: 表示轮询的超时时间,单位毫秒。
|
||||
- `timeoutMs`:表示轮询的超时时间,单位毫秒。
|
||||
- **返回值**:`Message` 每个主题对应的数据。
|
||||
- **异常**:操作失败抛出 `ConsumerException` 异常。
|
||||
- `fn commit(&mut self, message: &mut Message) -> PyResult<()>`
|
||||
- **接口说明** 提交当前处理的消息的偏移量。
|
||||
- **参数说明**:
|
||||
- `message`: 类型 `Message`, 当前处理的消息的偏移量。
|
||||
- `message`:类型 `Message`, 当前处理的消息的偏移量。
|
||||
- **异常**:操作失败抛出 `ConsumerException` 异常。
|
||||
- `fn assignment(&mut self) -> PyResult<Option<Vec<TopicAssignment>>>`
|
||||
- **接口说明**:获取消费者当前分配的指定的分区或所有分区。
|
||||
|
@ -337,22 +337,22 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `fn seek(&mut self, topic: &str, vg_id: i32, offset: i64) -> PyResult<()>`
|
||||
- **接口说明**:将给定分区的偏移量设置到指定的位置。
|
||||
- **参数说明**:
|
||||
- `topic`: 订阅的主题。
|
||||
- `vg_id`: vgroupid。
|
||||
- `topic`:订阅的主题。
|
||||
- `vg_id`:vgroupid。
|
||||
- `offset`:需要设置的偏移量。
|
||||
- **异常**:操作失败抛出 ConsumerException 异常。
|
||||
- `fn committed(&mut self, topic: &str, vg_id: i32) -> PyResult<i64>`
|
||||
- **接口说明**:获取订阅主题的vgroupid分区最后提交的偏移量。
|
||||
- **参数说明**:
|
||||
- `topic`: 订阅的主题。
|
||||
- `vg_id`: vgroupid。
|
||||
- `topic`:订阅的主题。
|
||||
- `vg_id`:vgroupid。
|
||||
- **返回值**:`i64`,分区最后提交的偏移量。
|
||||
- **异常**:操作失败抛出 ConsumerException 异常。
|
||||
- `fn position(&mut self, topic: &str, vg_id: i32) -> PyResult<i64>`
|
||||
- **接口说明**:获取给定分区当前的偏移量。
|
||||
- **参数说明**:
|
||||
- `topic`: 订阅的主题。
|
||||
- `vg_id`: vgroupid。
|
||||
- `topic`:订阅的主题。
|
||||
- `vg_id`:vgroupid。
|
||||
- **返回值**:`i64`,分区最后提交的偏移量。
|
||||
- **异常**:操作失败抛出 ConsumerException 异常。
|
||||
- `fn close(&mut self)`
|
||||
|
@ -365,14 +365,14 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
|
||||
- `def connect(*args, **kwargs):`
|
||||
- **接口说明**:建立 taosAdapter 连接。
|
||||
- **参数说明**:
|
||||
- `kwargs`: 以 Python 字典的形式提供, 可用于设置
|
||||
- `user`: 数据库的用户名
|
||||
- `password`: 数据库的密码。
|
||||
- `host`: 主机地址
|
||||
- `port`: 端口号
|
||||
- `database`: 数据库名称
|
||||
- `timezone`: 时区
|
||||
- **参数说明**:
|
||||
- `kwargs`:以 Python 字典的形式提供, 可用于设置
|
||||
- `user`:数据库的用户名
|
||||
- `password`:数据库的密码。
|
||||
- `host`:主机地址
|
||||
- `port`:端口号
|
||||
- `database`:数据库名称
|
||||
- `timezone`:时区
|
||||
- **返回值**:`TaosConnection` 连接对象。
|
||||
- **异常**:操作失败抛出 `AttributeError` 或 `ConnectionError` 异常。
|
||||
- `def cursor(self)`
|
||||
|
@ -385,14 +385,14 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- **接口说明**:执行 sql 语句。
|
||||
- **参数说明**:
|
||||
- `operation`:待执行的 sql 语句。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:影响的条数。
|
||||
- **异常**:操作失败抛出 `ProgrammingError` 异常。
|
||||
- `def query(self, sql: str, req_id: Optional[int] = None) -> TaosResult`
|
||||
- **接口说明**:查询数据。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的 sql 语句。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:`TaosResult` 数据集对象。
|
||||
- **异常**:操作失败抛出 `ProgrammingError` 异常。
|
||||
|
||||
|
@ -415,19 +415,19 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- **接口说明**:无模式写入。
|
||||
- **参数说明**:
|
||||
- `lines`:待写入的数据数组,无模式具体的数据格式可参考 `Schemaless 写入`。
|
||||
- `protocol`: 协议类型
|
||||
- `SmlProtocol.LINE_PROTOCOL`: InfluxDB 行协议(Line Protocol)。
|
||||
- `protocol`:协议类型
|
||||
- `SmlProtocol.LINE_PROTOCOL`:InfluxDB 行协议(Line Protocol)。
|
||||
- `SmlProtocol.TELNET_PROTOCOL`:OpenTSDB 文本行协议。
|
||||
- `SmlProtocol.JSON_PROTOCOL`: JSON 协议格式
|
||||
- `precision`: 时间精度
|
||||
- `SmlPrecision.Hour`: 小时
|
||||
- `SmlProtocol.JSON_PROTOCOL`:JSON 协议格式
|
||||
- `precision`:时间精度
|
||||
- `SmlPrecision.Hour`:小时
|
||||
- `SmlPrecision.Minute`:分钟
|
||||
- `SmlPrecision.Second` 秒
|
||||
- `SmlPrecision.Millisecond`:毫秒
|
||||
- `SmlPrecision.Microsecond`:微秒
|
||||
- `SmlPrecision.Nanosecond`: 纳秒
|
||||
- `SmlPrecision.Nanosecond`:纳秒
|
||||
- `ttl`:表过期时间,单位天。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:影响的条数。
|
||||
- **异常**:操作失败抛出 `SchemalessError` 异常。
|
||||
|
||||
|
@ -435,36 +435,36 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `def statement2(self, sql=None, option=None)`
|
||||
- **接口说明**:使用连接对象创建 stmt2 对象
|
||||
- **参数说明**
|
||||
- `sql`: 绑定的 SQL 语句,如果不为空会调用`prepare`函数
|
||||
- `sql`:绑定的 SQL 语句,如果不为空会调用`prepare`函数
|
||||
- `option` 传入 TaosStmt2Option 类实例选项
|
||||
- **返回值**:stmt2 对象。
|
||||
- **异常**:操作失败抛出 `ConnectionError` 异常。
|
||||
- `def prepare(self, sql)`
|
||||
- **接口说明**:绑定预编译 sql 语句
|
||||
- **参数说明**:
|
||||
- `sql`: 绑定的 SQL 语句
|
||||
- `sql`:绑定的 SQL 语句
|
||||
- **异常**:操作失败抛出 `StatementError` 异常。
|
||||
- `def bind_param(self, tbnames, tags, datas)`
|
||||
- **接口说明**:以独立数组方式绑定数据
|
||||
- **参数说明**:
|
||||
- `tbnames`: 绑定表名数组,数据类型为 list
|
||||
- `tags`: 绑定 tag 列值数组,数据类型为 list
|
||||
- `tags`: 绑定普通列值数组,数据类型为 list
|
||||
- `tbnames`:绑定表名数组,数据类型为 list
|
||||
- `tags`:绑定 tag 列值数组,数据类型为 list
|
||||
- `tags`:绑定普通列值数组,数据类型为 list
|
||||
- **异常**:操作失败抛出 `StatementError` 异常
|
||||
- `def bind_param_with_tables(self, tables)`
|
||||
- **接口说明**:以独立表方式绑定数据,独立表是以表为组织单位,每张表中有表名,TAG 值及普通列数值属性
|
||||
- **参数说明**:
|
||||
- `tables`: `BindTable` 独立表对象数组
|
||||
- `tables`:`BindTable` 独立表对象数组
|
||||
- **异常**:操作失败抛出 `StatementError` 异常。
|
||||
- `def execute(self) -> int:`
|
||||
- **接口说明**:执行将绑定数据全部写入
|
||||
- **返回值**:影响行数
|
||||
- **异常**:操作失败抛出 `QueryError` 异常。
|
||||
- `def result(self)`
|
||||
- **接口说明**: 获取参数绑定查询结果集
|
||||
- **接口说明**:获取参数绑定查询结果集
|
||||
- **返回值**:返回 TaosResult 对象
|
||||
- `def close(self)`
|
||||
- **接口说明**: 关闭 stmt2 对象
|
||||
- **接口说明**:关闭 stmt2 对象
|
||||
|
||||
|
||||
#### 数据订阅
|
||||
|
@ -473,21 +473,21 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- td.connect.port:端口号。
|
||||
- group.id:所在的 group。
|
||||
- client.id:客户端id。
|
||||
- td.connect.user: 数据库用户名。
|
||||
- td.connect.pass: 数据库密码。
|
||||
- td.connect.user:数据库用户名。
|
||||
- td.connect.pass:数据库密码。
|
||||
- td.connect.token:数据库的连接token。
|
||||
- auto.offset.reset:来确定消费位置为最新数据(latest)还是包含旧数据(earliest)。
|
||||
- enable.auto.commit:是否允许自动提交。
|
||||
- auto.commit.interval.ms:自动提交间隔
|
||||
- `def Consumer(configs)`
|
||||
- **接口说明** 消费者构造函数。
|
||||
- `configs`: Python 字典的形式提供, 具体配置参见属性列表。
|
||||
- `configs`:Python 字典的形式提供, 具体配置参见属性列表。
|
||||
- **返回值**:Consumer 消费者对象。
|
||||
- **异常**:操作失败抛出 `TmqError` 异常。
|
||||
- `def subscribe(self, topics)`
|
||||
- **接口说明** 订阅一组主题。
|
||||
- **参数说明**:
|
||||
- `topics`: 订阅的主题列表。
|
||||
- `topics`:订阅的主题列表。
|
||||
- **异常**:操作失败抛出 `TmqError` 异常。
|
||||
- `def unsubscribe(self)`
|
||||
- **接口说明** 取消订阅。
|
||||
|
@ -495,14 +495,14 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `def poll(self, timeout: float = 1.0)`
|
||||
- **接口说明** 轮询消息。
|
||||
- **参数说明**:
|
||||
- `timeout`: 表示轮询的超时时间,单位毫秒。
|
||||
- `timeout`:表示轮询的超时时间,单位毫秒。
|
||||
- **返回值**:`Message` 每个主题对应的数据。
|
||||
- **异常**:操作失败抛出 `TmqError` 异常。
|
||||
- `def commit(self, message: Message = None, offsets: [TopicPartition] = None)`
|
||||
- **接口说明** 提交当前处理的消息的偏移量。
|
||||
- **参数说明**:
|
||||
- `message`: 类型 `Message`, 当前处理的消息的偏移量。
|
||||
- `offsets`: 类型 `[TopicPartition]`, 提交一批消息的偏移量。
|
||||
- `message`:类型 `Message`, 当前处理的消息的偏移量。
|
||||
- `offsets`:类型 `[TopicPartition]`, 提交一批消息的偏移量。
|
||||
- **异常**:操作失败抛出 `TmqError` 异常。
|
||||
- `def assignment(self)`
|
||||
- **接口说明**:获取消费者当前分配的指定的分区或所有分区。
|
||||
|
@ -511,25 +511,25 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `def seek(self, partition)`
|
||||
- **接口说明**:将给定分区的偏移量设置到指定的位置。
|
||||
- **参数说明**:
|
||||
- `partition`: 需要设置的偏移量。
|
||||
- `topic`: 订阅的主题
|
||||
- `partition`: 分区
|
||||
- `offset`: 偏移量
|
||||
- `partition`:需要设置的偏移量。
|
||||
- `topic`:订阅的主题
|
||||
- `partition`:分区
|
||||
- `offset`:偏移量
|
||||
- **异常**:操作失败抛出 `TmqError` 异常。
|
||||
- `def committed(self, partitions)`
|
||||
- **接口说明**:获取订阅主题的分区最后提交的偏移量。
|
||||
- **参数说明**:
|
||||
- `partition`: 需要设置的偏移量。
|
||||
- `topic`: 订阅的主题
|
||||
- `partition`: 分区
|
||||
- `partition`:需要设置的偏移量。
|
||||
- `topic`:订阅的主题
|
||||
- `partition`:分区
|
||||
- **返回值**:`partition`,分区最后提交的偏移量。
|
||||
- **异常**:操作失败抛出 `TmqError` 异常。
|
||||
- `def position(self, partitions)`
|
||||
- **接口说明**:获取给定分区当前的偏移量。
|
||||
- **参数说明**:
|
||||
- `partition`: 需要设置的偏移量。
|
||||
- `topic`: 订阅的主题
|
||||
- `partition`: 分区
|
||||
- `partition`:需要设置的偏移量。
|
||||
- `topic`:订阅的主题
|
||||
- `partition`:分区
|
||||
- **返回值**:`partition`,分区最后提交的偏移量。
|
||||
- **异常**:操作失败抛出 TmqError 异常。
|
||||
- `def close(self)`
|
||||
|
@ -541,39 +541,39 @@ TaosResult 对象可以通过循环遍历获取查询到的数据。
|
|||
- `def connect(**kwargs) -> TaosRestConnection`
|
||||
- **接口说明**:建立 taosAdapter 连接。
|
||||
- **参数说明**:
|
||||
- `kwargs`: 以 Python 字典的形式提供, 可用于设置
|
||||
- `user`: 数据库的用户名
|
||||
- `password`: 数据库的密码。
|
||||
- `host`: 主机地址
|
||||
- `port`: 端口号
|
||||
- `database`: 数据库名称
|
||||
- `kwargs`:以 Python 字典的形式提供, 可用于设置
|
||||
- `user`:数据库的用户名
|
||||
- `password`:数据库的密码。
|
||||
- `host`:主机地址
|
||||
- `port`:端口号
|
||||
- `database`:数据库名称
|
||||
- **返回值**:连接对象。
|
||||
- **异常**:操作失败抛出 `ConnectError` 异常。
|
||||
- `def execute(self, sql: str, req_id: Optional[int] = None) -> Optional[int]`
|
||||
- **接口说明**:执行 sql 语句。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的 sql 语句。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:影响的条数。
|
||||
- **异常**:操作失败抛出 `ConnectError` 或 `HTTPError` 异常。
|
||||
- `def query(self, sql: str, req_id: Optional[int] = None) -> Result`
|
||||
- **接口说明**:查询数据。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的 sql 语句。
|
||||
- `reqId`: 用于问题追踪。
|
||||
- `reqId`:用于问题追踪。
|
||||
- **返回值**:`Result` 数据集对象。
|
||||
- **异常**:操作失败抛出 `ConnectError` 或 `HTTPError` 异常。
|
||||
- `RestClient(self, url: str, token: str = None, database: str = None, user: str = "root", password: str = "taosdata", timeout: int = None, convert_timestamp: bool = True, timezone: Union[str, datetime.tzinfo] = None)`
|
||||
- **接口说明**:建立 taosAdapter 连接 client。
|
||||
- **参数说明**:
|
||||
- `url`: taosAdapter REST 服务的 URL。
|
||||
- `user`: 数据库的用户名。
|
||||
- `password`: 数据库的密码。
|
||||
- `database`: 数据库名称。
|
||||
- `timezone`: 时区。
|
||||
- `timeout`: HTTP 请求超时时间。单位为秒。
|
||||
- `convert_timestamp`: 是否将时间戳从STR类型转换为datetime类型。
|
||||
- `timezone`: 时区.
|
||||
- `url`:taosAdapter REST 服务的 URL。
|
||||
- `user`:数据库的用户名。
|
||||
- `password`:数据库的密码。
|
||||
- `database`:数据库名称。
|
||||
- `timezone`:时区。
|
||||
- `timeout`:HTTP 请求超时时间。单位为秒。
|
||||
- `convert_timestamp`:是否将时间戳从STR类型转换为datetime类型。
|
||||
- `timezone`:时区.
|
||||
- **返回值**:连接对象。
|
||||
- **异常**:操作失败抛出 `ConnectError` 异常。
|
||||
- `def sql(self, q: str, req_id: Optional[int] = None) -> dict`
|
||||
|
|
|
@ -116,11 +116,11 @@ Node.js 连接器(`@tdengine/websocket`), 其通过 taosAdapter 提供的 We
|
|||
| protocol | | username | password | host | port | database | params |
|
||||
```
|
||||
|
||||
- **protocol**: 使用 websocket 协议建立连接。例如`ws://localhost:6041`
|
||||
- **username/password**: 数据库的用户名和密码。
|
||||
- **host/port**: 主机地址和端口号。例如`localhost:6041`
|
||||
- **database**: 数据库名称。
|
||||
- **params**: 其他参数。 例如token。
|
||||
- **protocol**:使用 websocket 协议建立连接。例如`ws://localhost:6041`
|
||||
- **username/password**:数据库的用户名和密码。
|
||||
- **host/port**:主机地址和端口号。例如`localhost:6041`
|
||||
- **database**:数据库名称。
|
||||
- **params**:其他参数。 例如token。
|
||||
|
||||
- 完整 URL 示例:
|
||||
|
||||
|
@ -180,7 +180,7 @@ WSConfig 中的配置如下:
|
|||
- **接口说明**:执行 sql 语句。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的 sql 语句。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:执行结果
|
||||
```js
|
||||
TaosResult {
|
||||
|
@ -194,7 +194,7 @@ WSConfig 中的配置如下:
|
|||
- **接口说明**:查询数据。
|
||||
- **参数说明**:
|
||||
- `sql`:待执行的查询 sql 语句。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:WSRows 数据集对象。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
|
||||
|
@ -225,43 +225,43 @@ WSConfig 中的配置如下:
|
|||
- **接口说明**:无模式写入。
|
||||
- **参数说明**:
|
||||
- `lines`:待写入的数据数组,无模式具体的数据格式可参考 `Schemaless 写入`。
|
||||
- `protocol`: 协议类型
|
||||
- `protocol`:协议类型
|
||||
- `SchemalessProto.InfluxDBLineProtocol`:InfluxDB 行协议(Line Protocol)。
|
||||
- `SchemalessProto.OpenTSDBTelnetLineProtocol`:OpenTSDB 文本行协议。
|
||||
- `SchemalessProto.OpenTSDBJsonFormatProtocol`:JSON 协议格式。
|
||||
- `precision`: 时间精度
|
||||
- `Precision.HOURS`: 小时
|
||||
- `precision`:时间精度
|
||||
- `Precision.HOURS`:小时
|
||||
- `Precision.MINUTES`:分钟
|
||||
- `Precision.SECONDS`:秒
|
||||
- `Precision.MILLI_SECONDS`:毫秒
|
||||
- `Precision.MICRO_SECONDS`:微秒
|
||||
- `Precision.NANO_SECONDS`: 纳秒
|
||||
- `Precision.NANO_SECONDS`:纳秒
|
||||
- `ttl`:表过期时间,单位天。
|
||||
- `reqId`: 用于问题追踪,可选。
|
||||
- `reqId`:用于问题追踪,可选。
|
||||
- **异常**:连接失败抛出 `TaosResultError` 异常。
|
||||
|
||||
### 参数绑定
|
||||
- `async stmtInit(reqId?:number): Promise<WsStmt>`
|
||||
- **接口说明** 使用 WsSql 对象创建 stmt 对象。
|
||||
- **参数说明**:
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:stmt 对象。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async prepare(sql: string): Promise<void>`
|
||||
- **接口说明** 绑定预编译 sql 语句。
|
||||
- **参数说明**:
|
||||
- `sql`: 预编译的 SQL 语句。
|
||||
- `sql`:预编译的 SQL 语句。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async setTableName(tableName: string): Promise<void>`
|
||||
- **接口说明** 设置将要写入数据的表名。
|
||||
- **参数说明**:
|
||||
- `tableName`: 表名,如果需要指定数据库, 例如: `db_name.table_name` 即可。
|
||||
- `tableName`:表名,如果需要指定数据库, 例如:`db_name.table_name` 即可。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
通过 StmtBindParams 对象设置绑定数据。
|
||||
- `setBoolean(params :any[])`
|
||||
- **接口说明** 设置布尔值。
|
||||
- **参数说明**:
|
||||
- `params`: 布尔类型列表。
|
||||
- `params`:布尔类型列表。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
- 下面接口除了要设置的值类型不同外,其余同 setBoolean:
|
||||
- `setTinyInt(params :any[])`
|
||||
|
@ -284,12 +284,12 @@ WSConfig 中的配置如下:
|
|||
- `async setTags(paramsArray:StmtBindParams): Promise<void>`
|
||||
- **接口说明** 设置表 Tags 数据,用于自动建表。
|
||||
- **参数说明**:
|
||||
- `paramsArray`: Tags 数据。
|
||||
- `paramsArray`:Tags 数据。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async bind(paramsArray:StmtBindParams): Promise<void>`
|
||||
- **接口说明** 绑定数据。
|
||||
- **参数说明**:
|
||||
- `paramsArray`: 绑定数据。
|
||||
- `paramsArray`:绑定数据。
|
||||
- **异常**:连接失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async batch(): Promise<void>`
|
||||
- **接口说明** 提交绑定数据。
|
||||
|
@ -307,69 +307,69 @@ WSConfig 中的配置如下:
|
|||
### 数据订阅
|
||||
|
||||
- **创建消费者支持属性列表**:
|
||||
- taos.TMQConstants.CONNECT_USER: 用户名。
|
||||
- taos.TMQConstants.CONNECT_PASS: 密码。
|
||||
- taos.TMQConstants.GROUP_ID: 所在的 group。
|
||||
- taos.TMQConstants.CLIENT_ID: 客户端id。
|
||||
- taos.TMQConstants.WS_URL: taosAdapter 的url地址。
|
||||
- taos.TMQConstants.AUTO_OFFSET_RESET: 来确定消费位置为最新数据(latest)还是包含旧数据(earliest)。
|
||||
- taos.TMQConstants.ENABLE_AUTO_COMMIT: 是否允许自动提交。
|
||||
- taos.TMQConstants.AUTO_COMMIT_INTERVAL_MS: 自动提交间隔。
|
||||
- taos.TMQConstants.CONNECT_MESSAGE_TIMEOUT: 数据传输超时参数,单位 ms,默认为 10000 ms。
|
||||
- taos.TMQConstants.CONNECT_USER:用户名。
|
||||
- taos.TMQConstants.CONNECT_PASS:密码。
|
||||
- taos.TMQConstants.GROUP_ID:所在的 group。
|
||||
- taos.TMQConstants.CLIENT_ID:客户端id。
|
||||
- taos.TMQConstants.WS_URL:taosAdapter 的url地址。
|
||||
- taos.TMQConstants.AUTO_OFFSET_RESET:来确定消费位置为最新数据(latest)还是包含旧数据(earliest)。
|
||||
- taos.TMQConstants.ENABLE_AUTO_COMMIT:是否允许自动提交。
|
||||
- taos.TMQConstants.AUTO_COMMIT_INTERVAL_MS:自动提交间隔。
|
||||
- taos.TMQConstants.CONNECT_MESSAGE_TIMEOUT:数据传输超时参数,单位 ms,默认为 10000 ms。
|
||||
- `static async newConsumer(wsConfig:Map<string, any>):Promise<WsConsumer>`
|
||||
- **接口说明** 消费者构造函数。
|
||||
- **参数说明**:
|
||||
- `wsConfig`: 创建消费者属性配置。
|
||||
- `wsConfig`:创建消费者属性配置。
|
||||
- **返回值**:WsConsumer 消费者对象。
|
||||
- **异常**:如果在执行过程中出现异常,抛出 `TDWebSocketClientError` 错误。
|
||||
- `async subscribe(topics: Array<string>, reqId?:number): Promise<void>`
|
||||
- **接口说明** 订阅一组主题。
|
||||
- **参数说明**:
|
||||
- `topics`: 订阅的主题列表。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `topics`:订阅的主题列表。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **异常**:失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async unsubscribe(reqId?:number): Promise<void>`
|
||||
- **接口说明** 取消订阅。
|
||||
- **参数说明**:
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **异常**:失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async poll(timeoutMs: number, reqId?:number):Promise<Map<string, TaosResult>>`
|
||||
- **接口说明** 轮询消息。
|
||||
- **参数说明**:
|
||||
- `timeoutMs`: 表示轮询的超时时间,单位毫秒。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `timeoutMs`:表示轮询的超时时间,单位毫秒。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:`Map<string, TaosResult>` 每个主题对应的数据。
|
||||
- **异常**:失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async subscription(reqId?:number):Promise<Array<string>>`
|
||||
- **接口说明** 获取当前订阅的所有主题。
|
||||
- **参数说明**:
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:`Array<string>` 主题列表。
|
||||
- **异常**:失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async commit(reqId?:number):Promise<Array<TopicPartition>>`
|
||||
- **接口说明** 提交当前处理的消息的偏移量。
|
||||
- **参数说明**:
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:`Array<TopicPartition>` 每个主题的消费进度。
|
||||
- **异常**:失败抛出 `TDWebSocketClientError` 异常。
|
||||
- `async committed(partitions:Array<TopicPartition>, reqId?:number):Promise<Array<TopicPartition>>`
|
||||
- **接口说明**:获取一组分区最后提交的偏移量。
|
||||
- **参数说明**:
|
||||
- `partitions`:一个 `Array<TopicPartition>` 类型的参数,表示要查询的分区集合。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:`Array<TopicPartition>`,即一组分区最后提交的偏移量。
|
||||
- **异常**:如果在获取提交的偏移量过程中发生错误,将抛出 `TDWebSocketClientError` 异常。
|
||||
- `async seek(partition:TopicPartition, reqId?:number):Promise<void>`
|
||||
- **接口说明**:将给定分区的偏移量设置到指定的位置。
|
||||
- **参数说明**:
|
||||
- `partition`:一个 `TopicPartition` 类型的参数,表示要操作的分区和要设置的偏移量。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **异常**:如果在设置偏移量过程中发生错误,将抛出 `TDWebSocketClientError` 异常。
|
||||
- `async positions(partitions:Array<TopicPartition>, reqId?:number):Promise<Array<TopicPartition>>`
|
||||
- **接口说明**:获取给定分区当前的偏移量。
|
||||
- **参数说明**:
|
||||
- `partitions`:一个 `TopicPartition` 类型的参数,表示要查询的分区。
|
||||
- `reqId`: 请求 id 非必填,用于问题追踪。
|
||||
- `reqId`:请求 id 非必填,用于问题追踪。
|
||||
- **返回值**:`Array<TopicPartition>`,即一组分区最后提交的偏移量。
|
||||
- **异常**:如果在获取偏移量过程中发生错误,将抛出 `TDWebSocketClientError` 异常。
|
||||
- `async seekToBeginning(partitions:Array<TopicPartition>):Promise<void>`
|
||||
|
|
|
@ -365,7 +365,7 @@ C# 驱动提供了符合 ADO.NET 标准的 `DbDataReader` 接口,提供了用
|
|||
- **接口说明**:获取指定列的值。
|
||||
- **参数说明**:
|
||||
- `ordinal`:列索引。
|
||||
- **返回值**: 结果对象。
|
||||
- **返回值**:结果对象。
|
||||
|
||||
|
||||
- `public int GetValues(object[] values)`
|
||||
|
|
|
@ -13,11 +13,11 @@ import Rdemo from "../../07-develop/01-connect/_connect_r.mdx"
|
|||
|
||||
## 安装过程
|
||||
|
||||
在开始之前,请确保已经安装了R语言环境。然后按照以下步骤安装和配置RJDBC库:
|
||||
在开始之前,请确保已经安装了 R 语言环境。然后按照以下步骤安装和配置 RJDBC 库:
|
||||
|
||||
1. 安装Java Development Kit (JDK):RJDBC库需要依赖Java环境。请从Oracle官方网站下载适合您操作系统的JDK,并按照安装指南进行安装。
|
||||
1. 安装 Java Development Kit (JDK):RJDBC库需要依赖 Java 环境。请从 Oracle 官方网站下载适合您操作系统的 JDK,并按照安装指南进行安装。
|
||||
|
||||
2. 安装RJDBC库:在R控制台中执行以下命令来安装RJDBC库。
|
||||
2. 安装 RJDBC 库:在R控制台中执行以下命令来安装 RJDBC 库。
|
||||
|
||||
```r
|
||||
install.packages("RJDBC", repos='http://cran.us.r-project.org')
|
||||
|
@ -35,7 +35,7 @@ install.packages("RJDBC", repos='http://cran.us.r-project.org')
|
|||
|
||||
## 配置过程
|
||||
|
||||
完成了安装步骤后,您需要进行一些配置,以便RJDBC库能够正确连接和访问TDengine时序数据库。
|
||||
完成了安装步骤后,您需要进行一些配置,以便RJDBC库能够正确连接和访问 TDengine 时序数据库。
|
||||
|
||||
1. 在 R 脚本中加载 RJDBC 和其他必要的库:
|
||||
|
||||
|
@ -48,10 +48,10 @@ library(RJDBC)
|
|||
2. 设置 JDBC 驱动程序和 JDBC URL:
|
||||
|
||||
```r
|
||||
# 设置JDBC驱动程序路径(根据您实际保存的位置进行修改)
|
||||
# 设置 JDBC 驱动程序路径(根据您实际保存的位置进行修改)
|
||||
driverPath <- "/path/to/taos-jdbcdriver-X.X.X-dist.jar"
|
||||
|
||||
# 设置JDBC URL(根据您的具体环境进行修改)
|
||||
# 设置 JDBC URL(根据您的具体环境进行修改)
|
||||
url <- "jdbc:TAOS://localhost:6030/?user=root&password=taosdata"
|
||||
```
|
||||
|
||||
|
|
|
@ -18,8 +18,8 @@ TDengine 服务端或客户端安装后,`taos.h` 位于:
|
|||
|
||||
TDengine 客户端驱动的动态库位于:
|
||||
|
||||
- Linux: `/usr/local/taos/driver/libtaos.so`
|
||||
- Windows: `C:\TDengine\taos.dll`
|
||||
- Linux:`/usr/local/taos/driver/libtaos.so`
|
||||
- Windows:`C:\TDengine\taos.dll`
|
||||
- macOS:`/usr/local/lib/libtaos.dylib`
|
||||
|
||||
## 支持的平台
|
||||
|
@ -85,7 +85,7 @@ phpize && ./configure --enable-swoole && make -j && make install
|
|||
|
||||
本节展示了使用客户端驱动访问 TDengine 集群的常见访问方式的示例代码。
|
||||
|
||||
> 所有错误都会抛出异常: `TDengine\Exception\TDengineException`
|
||||
> 所有错误都会抛出异常:`TDengine\Exception\TDengineException`
|
||||
|
||||
### 建立连接
|
||||
|
||||
|
|
|
@ -52,11 +52,11 @@ TDengine ODBC 支持两种连接 TDengine 数据库方式:WebSocket 连接与
|
|||
|
||||

|
||||
|
||||
4.1 【DSN】:Data Source Name 必填,为新添加的 ODBC 数据源命名
|
||||
4.1 【DSN】:Data Source Name 必填,为新添加的 ODBC 数据源命名
|
||||
|
||||
4.2【连接类型】 : 必选,选择连接类型,这里选择 【WebSocket】
|
||||
4.2【连接类型】:必选,选择连接类型,这里选择 【WebSocket】
|
||||
|
||||
4.3【URL】必填,ODBC 数据源 URL,示例: `http://localhost:6041`, 云服务的 url 示例: `https://gw.cloud.taosdata.com?token=your_token`
|
||||
4.3【URL】必填,ODBC 数据源 URL,示例:`http://localhost:6041`, 云服务的 url 示例:`https://gw.cloud.taosdata.com?token=your_token`
|
||||
|
||||
4.4【数据库】选填,需要连接的默认数据库
|
||||
|
||||
|
@ -84,11 +84,11 @@ TDengine ODBC 支持两种连接 TDengine 数据库方式:WebSocket 连接与
|
|||
|
||||

|
||||
|
||||
4.1 【DSN】:Data Source Name 必填,为新添加的 ODBC 数据源命名
|
||||
4.1 【DSN】:Data Source Name 必填,为新添加的 ODBC 数据源命名
|
||||
|
||||
4.2 【连接类型】 : 必选,选择连接类型,这里选择 【Native】 原生连接;
|
||||
4.2 【连接类型】:必选,选择连接类型,这里选择 【Native】 原生连接;
|
||||
|
||||
4.3 【服务器】必填,ODBC 数据源 服务器 地址,示例: `localhost:6030`
|
||||
4.3 【服务器】必填,ODBC 数据源 服务器 地址,示例:`localhost:6030`
|
||||
|
||||
4.4 【数据库】选填,需要连接的默认数据库
|
||||
|
||||
|
@ -267,388 +267,388 @@ TDengine ODBC 支持两种连接 TDengine 数据库方式:WebSocket 连接与
|
|||
|
||||
#### 数据源和驱动程序管理
|
||||
|
||||
- API: ConfigDSN
|
||||
- **是否支持**: 支持(仅 Windows)
|
||||
- **标准**: ODBC
|
||||
- **作用**: 配置数据源
|
||||
- API:ConfigDSN
|
||||
- **是否支持**:支持(仅 Windows)
|
||||
- **标准**:ODBC
|
||||
- **作用**:配置数据源
|
||||
|
||||
- API: ConfigDriver
|
||||
- **是否支持**: 支持(仅 Windows)
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于执行与特定驱动程序相关的安装和配置任务
|
||||
- API:ConfigDriver
|
||||
- **是否支持**:支持(仅 Windows)
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于执行与特定驱动程序相关的安装和配置任务
|
||||
|
||||
- API: ConfigTranslator
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于解析DSN的配置,在DSN配置和实际数据库驱动程序配置之间进行翻译或转换
|
||||
- API:ConfigTranslator
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于解析DSN的配置,在DSN配置和实际数据库驱动程序配置之间进行翻译或转换
|
||||
|
||||
|
||||
#### 连接到数据源
|
||||
|
||||
- API: SQLAllocHandle
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 分配环境、连接、语句或描述符句柄
|
||||
- API:SQLAllocHandle
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:分配环境、连接、语句或描述符句柄
|
||||
|
||||
- API: SQLConnect
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 通过数据源名称、用户 ID 和密码连接到特定驱动程序
|
||||
- API:SQLConnect
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:通过数据源名称、用户 ID 和密码连接到特定驱动程序
|
||||
|
||||
- API: SQLDriverConnect
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 通过连接字符串连接到特定驱动程序,支持更多连接信息
|
||||
- API:SQLDriverConnect
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:通过连接字符串连接到特定驱动程序,支持更多连接信息
|
||||
|
||||
- API: SQLBrowseConnect
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于发现和枚举连接到数据源所需的特性和属性值。每次调用 SQLBrowseConnect 都会返回属性和属性值的连续级别
|
||||
- API:SQLBrowseConnect
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于发现和枚举连接到数据源所需的特性和属性值。每次调用 SQLBrowseConnect 都会返回属性和属性值的连续级别
|
||||
|
||||
- API: SQLAllocEnv
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.x 函数 SQLAllocEnv 已替换为 SQLAllocHandle
|
||||
- API:SQLAllocEnv
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.x 函数 SQLAllocEnv 已替换为 SQLAllocHandle
|
||||
|
||||
- API: SQLAllocConnect
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.x 函数 SQLAllocConnect 已替换为 SQLAllocHandle
|
||||
- API:SQLAllocConnect
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.x 函数 SQLAllocConnect 已替换为 SQLAllocHandle
|
||||
|
||||
|
||||
#### 获取有关驱动程序和数据源的信息
|
||||
|
||||
- API: SQLDataSources
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回可用数据源的列表,由驱动程序管理器处理
|
||||
- API:SQLDataSources
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回可用数据源的列表,由驱动程序管理器处理
|
||||
|
||||
- API: SQLDrivers
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回由驱动程序管理器处理的已安装驱动程序及其属性的列表
|
||||
- API:SQLDrivers
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回由驱动程序管理器处理的已安装驱动程序及其属性的列表
|
||||
|
||||
- API: SQLGetInfo
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回有关数据库环境的详细信息,如数据库产品名称、驱动程序名、数据库的SQL语法特性、连接能力等等
|
||||
- API:SQLGetInfo
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回有关数据库环境的详细信息,如数据库产品名称、驱动程序名、数据库的SQL语法特性、连接能力等等
|
||||
|
||||
- API: SQLGetFunctions
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于查询驱动程序支持的函数
|
||||
- API:SQLGetFunctions
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于查询驱动程序支持的函数
|
||||
|
||||
- API: SQLGetTypeInfo
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回有关支持的数据类型的信息
|
||||
- API:SQLGetTypeInfo
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回有关支持的数据类型的信息
|
||||
|
||||
|
||||
#### 设置和检索驱动程序属性
|
||||
|
||||
- API: SQLSetConnectAttr
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 设置连接属性,当设置SQL_ATTR_AUTOCOMMIT属性时,用于控制自动提交模式
|
||||
- API:SQLSetConnectAttr
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:设置连接属性,当设置SQL_ATTR_AUTOCOMMIT属性时,用于控制自动提交模式
|
||||
|
||||
- API: SQLGetConnectAttr
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回连接属性的值
|
||||
- API:SQLGetConnectAttr
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回连接属性的值
|
||||
|
||||
- API: SQLSetConnectOption
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetConnectOption 已替换为 SQLSetConnectAttr
|
||||
- API:SQLSetConnectOption
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetConnectOption 已替换为 SQLSetConnectAttr
|
||||
|
||||
- API: SQLGetConnectOption
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetConnectOption 已替换为 SQLGetConnectAttr
|
||||
- API:SQLGetConnectOption
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetConnectOption 已替换为 SQLGetConnectAttr
|
||||
|
||||
- API: SQLSetEnvAttr
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 设置控制环境的属性
|
||||
- API:SQLSetEnvAttr
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:设置控制环境的属性
|
||||
|
||||
- API: SQLGetEnvAttr
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回环境属性的当前设置
|
||||
- API:SQLGetEnvAttr
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回环境属性的当前设置
|
||||
|
||||
- API: SQLSetStmtAttr
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 设置与语句相关的属性
|
||||
- API:SQLSetStmtAttr
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:设置与语句相关的属性
|
||||
|
||||
- API: SQLGetStmtAttr
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回语句属性的当前设置
|
||||
- API:SQLGetStmtAttr
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回语句属性的当前设置
|
||||
|
||||
- API: SQLSetStmtOption
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetStmtOption 已替换为 SQLSetStmtAttr
|
||||
- API:SQLSetStmtOption
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetStmtOption 已替换为 SQLSetStmtAttr
|
||||
|
||||
- API: SQLGetStmtOption
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetStmtOption 已替换为 SQLGetStmtAttr
|
||||
- API:SQLGetStmtOption
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLSetStmtOption 已替换为 SQLGetStmtAttr
|
||||
|
||||
|
||||
#### 准备SQL请求
|
||||
#### 准备 SQL 请求
|
||||
|
||||
- API: SQLAllocStmt
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.x 函数 SQLAllocStmt 已替换为 SQLAllocHandle
|
||||
- API:SQLAllocStmt
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.x 函数 SQLAllocStmt 已替换为 SQLAllocHandle
|
||||
|
||||
- API: SQLPrepare
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于预处理SQL语句,这通常是SQLExecute之前的一个步骤
|
||||
- API:SQLPrepare
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于预处理SQL语句,这通常是SQLExecute之前的一个步骤
|
||||
|
||||
- API: SQLBindCol
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于将结果集中的列绑定到应用程序缓冲区
|
||||
- API:SQLBindCol
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于将结果集中的列绑定到应用程序缓冲区
|
||||
|
||||
- API: SQLBindParameter
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于将SQL语句的参数绑定到应用程序缓冲区
|
||||
- API:SQLBindParameter
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于将SQL语句的参数绑定到应用程序缓冲区
|
||||
|
||||
- API: SQLGetCursorName
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回与指定语句关联的游标名称
|
||||
- API:SQLGetCursorName
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回与指定语句关联的游标名称
|
||||
|
||||
- API: SQLSetCursorName
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 设置游标名称,允许在查询中使用命名游标
|
||||
- API:SQLSetCursorName
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:设置游标名称,允许在查询中使用命名游标
|
||||
|
||||
- API: SQLSetScrollOptions
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 设置控制光标行为的选项
|
||||
- API:SQLSetScrollOptions
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:设置控制光标行为的选项
|
||||
|
||||
|
||||
#### 提交请求
|
||||
|
||||
- API: SQLExecute
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于执行之前通过 SQLPrepare 准备好的SQL语句
|
||||
- API:SQLExecute
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于执行之前通过 SQLPrepare 准备好的SQL语句
|
||||
|
||||
- API: SQLExecDirect
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于执行包含SQL语句的字符串
|
||||
- API:SQLExecDirect
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于执行包含SQL语句的字符串
|
||||
|
||||
- API: SQLNativeSql
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于将应用程序提供的SQL语句转换为数据库驱动程序的本机SQL语法
|
||||
- API:SQLNativeSql
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于将应用程序提供的SQL语句转换为数据库驱动程序的本机SQL语法
|
||||
|
||||
- API: SQLDescribeParam
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 返回语句中特定参数的描述
|
||||
- API:SQLDescribeParam
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:返回语句中特定参数的描述
|
||||
|
||||
- API: SQLNumParams
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于查询预编译SQL语句中的参数数量
|
||||
- API:SQLNumParams
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于查询预编译SQL语句中的参数数量
|
||||
|
||||
- API: SQLParamData
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于从参数数据流中获取下一个参数值
|
||||
- API:SQLParamData
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于从参数数据流中获取下一个参数值
|
||||
|
||||
- API: SQLPutData
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 当使用流输入方式时,可以用于向输出参数发送数据块
|
||||
- API:SQLPutData
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:当使用流输入方式时,可以用于向输出参数发送数据块
|
||||
|
||||
|
||||
#### 检索结果和关于结果的信息
|
||||
|
||||
- API: SQLRowCount
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回受插入或删除请求影响的行数
|
||||
- API:SQLRowCount
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回受插入或删除请求影响的行数
|
||||
|
||||
- API: SQLNumResultCols
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回结果集中的列数
|
||||
- API:SQLNumResultCols
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回结果集中的列数
|
||||
|
||||
- API: SQLDescribeCol
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于描述结果集中列的属性。它提供了关于列的数据类型、列名、列的最大宽度、小数位数和是否可为空等信息
|
||||
- API:SQLDescribeCol
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于描述结果集中列的属性。它提供了关于列的数据类型、列名、列的最大宽度、小数位数和是否可为空等信息
|
||||
|
||||
- API: SQLColAttribute
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回结果集中列的描述符信息,如标题、排序规则等
|
||||
- API:SQLColAttribute
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回结果集中列的描述符信息,如标题、排序规则等
|
||||
|
||||
- API: SQLColAttributes
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLColAttributes 已替换为 SQLColAttribute
|
||||
- API:SQLColAttributes
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLColAttributes 已替换为 SQLColAttribute
|
||||
|
||||
- API: SQLGetData
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于从结果集中的当前行获取特定列的数据
|
||||
- API:SQLGetData
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于从结果集中的当前行获取特定列的数据
|
||||
|
||||
- API: SQLMoreResults
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 多个结果集的 SQL 语句执行后(例如:一个批处理或存储过程),移动到下一个结果集
|
||||
- API:SQLMoreResults
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:多个结果集的 SQL 语句执行后(例如:一个批处理或存储过程),移动到下一个结果集
|
||||
|
||||
- API: SQLFetch
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于从结果集中提取下一行数据,并返回所有绑定列的数据
|
||||
- API:SQLFetch
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于从结果集中提取下一行数据,并返回所有绑定列的数据
|
||||
|
||||
- API: SQLFetchScroll
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于从结果集中提取指定的数据行集,并返回所有绑定列的数据
|
||||
- API:SQLFetchScroll
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于从结果集中提取指定的数据行集,并返回所有绑定列的数据
|
||||
|
||||
- API: SQLExtendedFetch
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,SQLExtendedFetch 已替换为 SQLFetchScroll
|
||||
- API:SQLExtendedFetch
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,SQLExtendedFetch 已替换为 SQLFetchScroll
|
||||
|
||||
- API: SQLSetPos
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 设置行集中的游标位置,并允许应用程序更新数据集中的行
|
||||
- API:SQLSetPos
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:设置行集中的游标位置,并允许应用程序更新数据集中的行
|
||||
|
||||
- API: SQLBulkOperations
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 执行批量插入和批量书签操作,包括更新、删除和按书签提取
|
||||
- API:SQLBulkOperations
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:执行批量插入和批量书签操作,包括更新、删除和按书签提取
|
||||
|
||||
|
||||
#### 检索错误或诊断信息
|
||||
|
||||
- API: SQLError
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.x 函数 SQLError 已替换为 SQLGetDiagRec
|
||||
- API:SQLError
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.x 函数 SQLError 已替换为 SQLGetDiagRec
|
||||
|
||||
- API: SQLGetDiagField
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回附加诊断信息(单条诊断结果)
|
||||
- API:SQLGetDiagField
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回附加诊断信息(单条诊断结果)
|
||||
|
||||
- API: SQLGetDiagRec
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回附加诊断信息(多条诊断结果)
|
||||
- API:SQLGetDiagRec
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回附加诊断信息(多条诊断结果)
|
||||
|
||||
|
||||
#### 获取有关数据源的系统表项的信息
|
||||
|
||||
- API: SQLColumnPrivileges
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 用于检索指定表中列的权限信息,如哪些用户或角色拥有对特定列的读取、插入、更新或删除权限
|
||||
- API:SQLColumnPrivileges
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:用于检索指定表中列的权限信息,如哪些用户或角色拥有对特定列的读取、插入、更新或删除权限
|
||||
|
||||
- API: SQLColumns
|
||||
- **是否支持**: 支持
|
||||
- **标准**: X/Open
|
||||
- **作用**: 返回指定表中的列名列表
|
||||
- API:SQLColumns
|
||||
- **是否支持**:支持
|
||||
- **标准**:X/Open
|
||||
- **作用**:返回指定表中的列名列表
|
||||
|
||||
- API: SQLForeignKeys
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 检索外键关系的详细信息
|
||||
- API:SQLForeignKeys
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:检索外键关系的详细信息
|
||||
|
||||
- API: SQLPrimaryKeys
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 返回构成表主键的列名列表
|
||||
- API:SQLPrimaryKeys
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:返回构成表主键的列名列表
|
||||
|
||||
- API: SQLSpecialColumns
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: X/Open
|
||||
- **作用**: 返回数据库中特殊列的信息,如唯一键或索引列
|
||||
- API:SQLSpecialColumns
|
||||
- **是否支持**:不支持
|
||||
- **标准**:X/Open
|
||||
- **作用**:返回数据库中特殊列的信息,如唯一键或索引列
|
||||
|
||||
- API: SQLStatistics
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 返回关于表的统计信息,如行数、列数、平均行宽等
|
||||
- API:SQLStatistics
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:返回关于表的统计信息,如行数、列数、平均行宽等
|
||||
|
||||
- API: SQLTablePrivileges
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 返回用户在特定表上的权限,如SELECT、INSERT、UPDATE等
|
||||
- API:SQLTablePrivileges
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:返回用户在特定表上的权限,如SELECT、INSERT、UPDATE等
|
||||
|
||||
- API: SQLTables
|
||||
- **是否支持**: 支持
|
||||
- **标准**: X/Open
|
||||
- **作用**: 返回存储在数据源的当前数据库中的表信息
|
||||
- API:SQLTables
|
||||
- **是否支持**:支持
|
||||
- **标准**:X/Open
|
||||
- **作用**:返回存储在数据源的当前数据库中的表信息
|
||||
|
||||
- API: SQLProcedures
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 返回数据库中可用的存储过程信息,包括名称和类型
|
||||
- API:SQLProcedures
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:返回数据库中可用的存储过程信息,包括名称和类型
|
||||
|
||||
- API: SQLProcedureColumns
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 返回存储过程的列信息,包括输入输出参数的详细信息
|
||||
- API:SQLProcedureColumns
|
||||
- **是否支持**:不支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:返回存储过程的列信息,包括输入输出参数的详细信息
|
||||
|
||||
|
||||
#### 执行事务
|
||||
|
||||
- API: SQLTransact
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.x 函数 SQLTransact 已替换为 SQLEndTran
|
||||
- API:SQLTransact
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.x 函数 SQLTransact 已替换为 SQLEndTran
|
||||
|
||||
- API: SQLEndTran
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 用于提交或回滚事务。TDengine 是非事务性的,因此 SQLEndTran 函数最多只能模拟提交或回滚操作。如果有任何未完成的连接或语句,无论是提交(commit)还是回滚(rollback)都不会成功
|
||||
- API:SQLEndTran
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:用于提交或回滚事务。TDengine 是非事务性的,因此 SQLEndTran 函数最多只能模拟提交或回滚操作。如果有任何未完成的连接或语句,无论是提交(commit)还是回滚(rollback)都不会成功
|
||||
|
||||
|
||||
#### 终止连接
|
||||
|
||||
- API: SQLDisconnect
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 断开数据库连接
|
||||
- API:SQLDisconnect
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:断开数据库连接
|
||||
|
||||
- API: SQLFreeHandle
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ISO 92
|
||||
- **作用**: 释放与特定环境、连接、语句或描述符句柄关联的资源
|
||||
- API:SQLFreeHandle
|
||||
- **是否支持**:支持
|
||||
- **标准**:ISO 92
|
||||
- **作用**:释放与特定环境、连接、语句或描述符句柄关联的资源
|
||||
|
||||
- API: SQLFreeConnect
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLFreeConnect 已替换为 SQLFreeHandle
|
||||
- API:SQLFreeConnect
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLFreeConnect 已替换为 SQLFreeHandle
|
||||
|
||||
- API: SQLFreeEnv
|
||||
- **是否支持**: 不支持
|
||||
- **标准**: 弃用
|
||||
- **作用**: 在 ODBC 3.x 中,ODBC 2.0 函数 SQLFreeEnv 已替换为 SQLFreeHandle
|
||||
- API:SQLFreeEnv
|
||||
- **是否支持**:不支持
|
||||
- **标准**:弃用
|
||||
- **作用**:在 ODBC 3.x 中,ODBC 2.0 函数 SQLFreeEnv 已替换为 SQLFreeHandle
|
||||
|
||||
- API: SQLFreeStmt
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 结束语句处理,丢弃挂起的结果,并且可以选择释放与语句句柄关联的所有资源
|
||||
- API:SQLFreeStmt
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:结束语句处理,丢弃挂起的结果,并且可以选择释放与语句句柄关联的所有资源
|
||||
|
||||
- API: SQLCloseCursor
|
||||
- **是否支持**: 支持
|
||||
- **标准**: ODBC
|
||||
- **作用**: 关闭与当前语句句柄关联的游标,并释放游标所使用的所有资源
|
||||
- API:SQLCloseCursor
|
||||
- **是否支持**:支持
|
||||
- **标准**:ODBC
|
||||
- **作用**:关闭与当前语句句柄关联的游标,并释放游标所使用的所有资源
|
||||
|
||||
|
|
|
@ -75,12 +75,12 @@ http://<fqdn>:<port>/rest/sql/[db_name][?tz=timezone[&req_id=req_id][&row_with_m
|
|||
|
||||
参数说明:
|
||||
|
||||
- fqdn: 集群中的任一台主机 FQDN 或 IP 地址。
|
||||
- port: 配置文件中 httpPort 配置项,缺省为 6041。
|
||||
- db_name: 可选参数,指定本次所执行的 SQL 语句的默认数据库库名。
|
||||
- tz: 可选参数,指定返回时间的时区,遵照 IANA Time Zone 规则,如 `America/New_York`。
|
||||
- req_id: 可选参数,指定请求 id,可以用于 tracing。
|
||||
- row_with_meta: 可选参数,指定是否每行数据都携带列名,缺省为 false。(3.3.2.0 版本开始支持)
|
||||
- fqdn:集群中的任一台主机 FQDN 或 IP 地址。
|
||||
- port:配置文件中 httpPort 配置项,缺省为 6041。
|
||||
- db_name:可选参数,指定本次所执行的 SQL 语句的默认数据库库名。
|
||||
- tz:可选参数,指定返回时间的时区,遵照 IANA Time Zone 规则,如 `America/New_York`。
|
||||
- req_id:可选参数,指定请求 id,可以用于 tracing。
|
||||
- row_with_meta:可选参数,指定是否每行数据都携带列名,缺省为 false。(3.3.2.0 版本开始支持)
|
||||
|
||||
例如:`http://h1.taos.com:6041/rest/sql/test` 是指向地址为 `h1.taos.com:6041` 的 URL,并将默认使用的数据库库名设置为 `test`。
|
||||
|
||||
|
|
|
@ -18,19 +18,19 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 0x80000015 | Unable to resolve FQDN | 设置了无效的 fqdn | 检查fqdn 的设置 |
|
||||
| 0x80000017 | Port already in use | 端口已经被某个服务占用的情况下,新启的服务依然尝试绑定该端口 | 1.改动新服务的服务端口 2.杀死之前占用端口的服务 |
|
||||
| 0x80000018 | Conn is broken | 由于网络抖动或者请求时间过长(超过 900 秒),导致系统主动摘掉连接 | 1.设置系统的最大超时时长 2.检查请求时长 |
|
||||
| 0x80000019 | Conn read timeout | 1.请求是否处理时间过长 2. 服务端处理不过来 3. 服务端已经死锁| 1. 显式配置readTimeout参数,2. 分析taosd上堆栈 |
|
||||
| 0x80000019 | Conn read timeout | 1.请求是否处理时间过长 2.服务端处理不过来 3.服务端已经死锁| 1.显式配置readTimeout参数,2.分析taosd上堆栈 |
|
||||
| 0x80000020 | some vnode/qnode/mnode(s) out of service | 多次重试之后,仍然无法连接到集群,可能是所有的节点都宕机了,或者存活的节点不是 Leader 节点 | 1.查看 taosd 的状态、分析 taosd 宕机的原因 2.分析存活的 taosd 为什么无法选取 Leader |
|
||||
| 0x80000021 | some vnode/qnode/mnode(s) conn is broken | 多次重试之后,仍然无法连接到集群,可能是网络异常、请求时间太长、服务端死锁等问题 | 1.检查网络 2.请求的执行时间 |
|
||||
| 0x80000022 | rpc open too many session | 1.并发太高导致占用链接已经到达上限 2.服务端的 BUG,导致连接一直不释放 | 1.调整配置参数 numOfRpcSessions 2.调整配置参数 timeToGetAvailableConn 3.分析服务端不释放的连接的原因 |
|
||||
| 0x80000023 | rpc network error | 1. 网络问题,可能是闪断,2. 服务端crash | 1. 检查网络 2. 检查服务端是否重启|
|
||||
| 0x80000024 |rpc network bus | 1.集群间互相拉数据的时候,没有拿到可用链接,或者链接数目已经到上限 | 1.是否并发太高 2. 检查集群各个节点是否有异常,是否出现了死锁等情况|
|
||||
| 0x80000025 | http-report already quit | 1. http上报出现的问题| 内部问题,可以忽略|
|
||||
| 0x80000023 | rpc network error | 1.网络问题,可能是闪断,2.服务端 crash | 1.检查网络 2.检查服务端是否重启|
|
||||
| 0x80000024 |rpc network bus | 1.集群间互相拉数据的时候,没有拿到可用链接,或者链接数目已经到上限 | 1.是否并发太高 2.检查集群各个节点是否有异常,是否出现了死锁等情况|
|
||||
| 0x80000025 | http-report already quit | 1.http上报出现的问题| 内部问题,可以忽略|
|
||||
| 0x80000026 | rpc module already quit | 1.客户端实例已经退出,依然用该实例做查询 | 检查业务代码,是否用错|
|
||||
| 0x80000027 | rpc async module already quit | 1. 引擎错误, 可以忽略, 该错误码不会返回到用户侧| 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x80000028 | rpc async in proces | 1. 引擎错误, 可以忽略, 该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x80000029 | rpc no state | 1. 引擎错误, 可以忽略, 该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题 |
|
||||
| 0x8000002A | rpc state already dropped | 1. 引擎错误, 可以忽略, 该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x8000002B | rpc msg exceed limit | 1. 单个rpc 消息超过上限,该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x80000027 | rpc async module already quit | 1.引擎错误, 可以忽略, 该错误码不会返回到用户侧| 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x80000028 | rpc async in proces | 1.引擎错误, 可以忽略, 该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x80000029 | rpc no state | 1.引擎错误, 可以忽略, 该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题 |
|
||||
| 0x8000002A | rpc state already dropped | 1.引擎错误, 可以忽略, 该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
| 0x8000002B | rpc msg exceed limit | 1.单个rpc 消息超过上限,该错误码不会返回到用户侧 | 如果返回到用户侧, 需要引擎侧追查问题|
|
||||
|
||||
|
||||
## common
|
||||
|
@ -40,42 +40,42 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 0x80000100 | Operation not supported | 操作不被支持、不允许的场景 | 检查操作是否有误,确认该功能是否被支持 |
|
||||
| 0x80000102 | Out of Memory | 客户端或服务端内存分配失败的场景 | 检查客户端、服务端内存是否充足 |
|
||||
| 0x80000104 | Data file corrupted | 1.存储数据文件损坏 2.udf 文件无法创建 | 1.联系涛思客户支持 2.确认服务端对临时目录有读写创建文件权限 |
|
||||
| 0x80000106 | too many Ref Objs | 无可用ref资源 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000107 | Ref ID is removed | 引用的ref资源已经释放 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000108 | Invalid Ref ID | 无效ref ID | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000106 | too many Ref Objs | 无可用 ref 资源 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000107 | Ref ID is removed | 引用的 ref 资源已经释放 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000108 | Invalid Ref ID | 无效 ref ID | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000010A | Ref is not there | ref 信息不存在 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000110 | Unexpected generic error | 系统内部错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000111 | Action in progress | 操作进行中 | 1.等待操作完成 2.根据需要取消操作 3.当超出合理时间仍然未完成可保留现场和日志,或联系客户支持 |
|
||||
| 0x80000112 | Out of range | 配置参数超出允许值范围 | 更改参数 |
|
||||
| 0x80000115 | Invalid message | 消息错误 | 1. 检查是否存在节点间版本不一致 2. 保留现场和日志,github上报issue |
|
||||
| 0x80000116 | Invalid message len | 消息长度错误 | 1. 检查是否存在节点间版本不一致 2. 保留现场和日志,github上报issue |
|
||||
| 0x80000117 | Invalid pointer | 无效指针 | 保留现场和日志,github上报issue |
|
||||
| 0x80000118 | Invalid parameters | 无效参数 | 保留现场和日志,github上报issue |
|
||||
| 0x80000119 | Invalid config option | 无效配置 | 保留现场和日志,github上报issue |
|
||||
| 0x8000011A | Invalid option | 无效选项 | 保留现场和日志,github上报issue |
|
||||
| 0x8000011B | Invalid json format | JSON格式错误 | 保留现场和日志,github上报issue |
|
||||
| 0x8000011C | Invalid version number | 无效版本格式 | 保留现场和日志,github上报issue |
|
||||
| 0x8000011D | Invalid version string | 无效版本格式 | 保留现场和日志,github上报issue |
|
||||
| 0x80000115 | Invalid message | 消息错误 | 1.检查是否存在节点间版本不一致 2.保留现场和日志,github 上报 issue |
|
||||
| 0x80000116 | Invalid message len | 消息长度错误 | 1.检查是否存在节点间版本不一致 2.保留现场和日志,github 上报 issue |
|
||||
| 0x80000117 | Invalid pointer | 无效指针 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000118 | Invalid parameters | 无效参数 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000119 | Invalid config option | 无效配置 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000011A | Invalid option | 无效选项 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000011B | Invalid json format | JSON格式错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000011C | Invalid version number | 无效版本格式 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000011D | Invalid version string | 无效版本格式 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000011E | Version not compatible | 节点间版本不兼容 | 检查各节点版本(包括服务端与客户端),确保节点间版本一致或兼容 |
|
||||
| 0x8000011F | Checksum error | 文件checksum校验失败 | 保留现场和日志,github上报issue |
|
||||
| 0x80000120 | Failed to compress msg | 压缩失败 | 保留现场和日志,github上报issue |
|
||||
| 0x80000121 | Message not processed | 消息未被正确处理 | 保留现场和日志,github上报issue |
|
||||
| 0x80000122 | Config not found | 未找到配置项 | 保留现场和日志,github上报issue |
|
||||
| 0x80000123 | Repeat initialization | 重复初始化 | 保留现场和日志,github上报issue |
|
||||
| 0x80000124 | Cannot add duplicate keys to hash | 添加重复key数据到哈希表中 | 保留现场和日志,github上报issue |
|
||||
| 0x8000011F | Checksum error | 文件 checksum 校验失败 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000120 | Failed to compress msg | 压缩失败 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000121 | Message not processed | 消息未被正确处理 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000122 | Config not found | 未找到配置项 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000123 | Repeat initialization | 重复初始化 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000124 | Cannot add duplicate keys to hash | 添加重复 key 数据到哈希表中 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000125 | Retry needed | 需要应用进行重试 | 应用按照API使用规范进行重试 |
|
||||
| 0x80000126 | Out of memory in rpc queue | rpc消息队列内存使用达到上限 | 1. 检查确认系统负载是否过大 2. (如必要)通过配置rpcQueueMemoryAllowed增大rpc消息队列内存上限 3. 如果问题还未解决,保留现场和日志,github上报issue |
|
||||
| 0x80000126 | Out of memory in rpc queue | rpc 消息队列内存使用达到上限 | 1.检查确认系统负载是否过大 2.(如必要)通过配置 rpcQueueMemoryAllowed 增大 rpc 消息队列内存上限 3.如果问题还未解决,保留现场和日志,github 上报 issue |
|
||||
| 0x80000127 | Invalid timestamp format | 时间戳格式错误 | 检查并确认输入的时间戳格式正确 |
|
||||
| 0x80000128 | Msg decode error | 消息解码错误 | 保留现场和日志,github上报issue |
|
||||
| 0x8000012A | Not found | 未找到内部缓存信息 | 保留现场和日志,github上报issue |
|
||||
| 0x8000012B | Out of disk space | 磁盘空间不足 | 1. 检查并确保数据目录、临时文件夹目录有足够磁盘空间 2. 定期检查维护上述目录,确保空间足够 |
|
||||
| 0x80000128 | Msg decode error | 消息解码错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000012A | Not found | 未找到内部缓存信息 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000012B | Out of disk space | 磁盘空间不足 | 1.检查并确保数据目录、临时文件夹目录有足够磁盘空间 2.定期检查维护上述目录,确保空间足够 |
|
||||
| 0x80000130 | Database is starting up | 数据库启动中,暂无法提供服务 | 检查数据库状态,待系统完成启动后继续或重试 |
|
||||
| 0x80000131 | Database is closing down | 数据库正在或已经关闭,无法提供服务 | 检查数据库状态,确保系统工作在正常状态 |
|
||||
| 0x80000132 | Invalid data format | 数据格式错误 | 1. 保留现场和日志,github上报issue 2. 联系涛思客户支持 |
|
||||
| 0x80000133 | Invalid operation | 无效的或不支持的操作 | 1. 修改确认当前操作为合法有效支持的操作,检查参数有效性 2. 如果问题还未解决,保留现场和日志,github上报issue |
|
||||
| 0x80000134 | Invalid value | 无效值 | 保留现场和日志,github上报issue |
|
||||
| 0x80000135 | Invalid fqdn | 无效FQDN | 检查配置或输入的FQDN值是否正确 |
|
||||
| 0x8000013C | Invalid disk id | 不合法的disk id | 建议用户检查挂载磁盘是否失效或者使用参数 diskIDCheckEnabled 来跳过磁盘检查 |
|
||||
| 0x80000132 | Invalid data format | 数据格式错误 | 1.保留现场和日志,github 上报 issue 2.联系涛思客户支持 |
|
||||
| 0x80000133 | Invalid operation | 无效的或不支持的操作 | 1.修改确认当前操作为合法有效支持的操作,检查参数有效性 2.如果问题还未解决,保留现场和日志,github 上报 issue |
|
||||
| 0x80000134 | Invalid value | 无效值 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000135 | Invalid fqdn | 无效 FQDN | 检查配置或输入的 FQDN 值是否正确 |
|
||||
| 0x8000013C | Invalid disk id | 不合法的 disk id | 建议用户检查挂载磁盘是否失效或者使用参数 diskIDCheckEnabled 来跳过磁盘检查 |
|
||||
|
||||
|
||||
|
||||
|
@ -89,20 +89,20 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 0x8000020A | Table name too long | 表名不合法 | 检查表名是否正确 |
|
||||
| 0x8000020F | Query terminated | 查询被中止 | 检查是否有用户中止了查询 |
|
||||
| 0x80000213 | Disconnected from server | 连接已中断 | 检查连接是否被人为中断或客户端正在退出 |
|
||||
| 0x80000216 | Syntax error in SQL | SQL语法错误 | 检查SQL语句并修正错误 |
|
||||
| 0x80000219 | SQL statement too long | SQL长度超出限制 | 检查SQL语句并修正错误 |
|
||||
| 0x80000216 | Syntax error in SQL | SQL 语法错误 | 检查 SQL 语句并修正错误 |
|
||||
| 0x80000219 | SQL statement too long | SQL 长度超出限制 | 检查 SQL 语句并修正错误 |
|
||||
| 0x8000021A | File is empty | 文件内容为空 | 检查输入文件内容 |
|
||||
| 0x8000021F | Invalid column length | 列长度错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80000222 | Invalid JSON data type | JSON数据类型错误 | 检查输入JSON内容 |
|
||||
| 0x8000021F | Invalid column length | 列长度错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000222 | Invalid JSON data type | JSON 数据类型错误 | 检查输入 JSON 内容 |
|
||||
| 0x80000224 | Value out of range | 数据大小超过类型范围 | 检查输入的数据值 |
|
||||
| 0x80000229 | Invalid tsc input | API输入错误 | 检查应用调用API时传递的参数 |
|
||||
| 0x8000022A | Stmt API usage error | STMT API使用错误 | 检查STMT API调用的顺序、适用场景、错误处理 |
|
||||
| 0x8000022B | Stmt table name not set | STMT未正确设置table name | 检查是否调用了设置table name接口 |
|
||||
| 0x80000229 | Invalid tsc input | API 输入错误 | 检查应用调用 API 时传递的参数 |
|
||||
| 0x8000022A | Stmt API usage error | STMT API 使用错误 | 检查 STMT API 调用的顺序、适用场景、错误处理 |
|
||||
| 0x8000022B | Stmt table name not set | STMT 未正确设置 table name | 检查是否调用了设置 table name 接口 |
|
||||
| 0x8000022D | Query killed | 查询被中止 | 检查是否有用户中止了查询 |
|
||||
| 0x8000022E | No available execution node | 没有可用的查询执行节点 | 检查当前query policy配置,如果需要有Qnode参与确保系统中存在可用的Qnode节点 |
|
||||
| 0x8000022E | No available execution node | 没有可用的查询执行节点 | 检查当前 query policy 配置,如果需要有 Qnode 参与确保系统中存在可用的 Qnode 节点 |
|
||||
| 0x8000022F | Table is not a super table | 当前语句中的表名不是超级表 | 检查当前语句中所用表名是否是超级表 |
|
||||
| 0x80000230 | Stmt cache error | STMT内部缓存出错 | 保留现场和日志,github上报issue |
|
||||
| 0x80000231 | Tsc internal error | TSC内部错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80000230 | Stmt cache error | STMT 内部缓存出错 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000231 | Tsc internal error | TSC 内部错误 | 保留现场和日志,github 上报 issue |
|
||||
|
||||
|
||||
|
||||
|
@ -111,105 +111,105 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | -------------------------------------------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| 0x80000303 | Insufficient privilege for operation | 无权限 | 赋权 |
|
||||
| 0x8000030B | Data expired | 内部错误 | 上报issue |
|
||||
| 0x8000030C | Invalid query id | 内部错误 | 上报issue |
|
||||
| 0x8000030E | Invalid connection id | 内部错误 | 上报issue |
|
||||
| 0x8000030B | Data expired | 内部错误 | 上报 issue |
|
||||
| 0x8000030C | Invalid query id | 内部错误 | 上报 issue |
|
||||
| 0x8000030E | Invalid connection id | 内部错误 | 上报 issue |
|
||||
| 0x80000315 | User is disabled | 该用户不可用 | 赋权 |
|
||||
| 0x80000320 | Object already there | 内部错误 | 上报issue |
|
||||
| 0x80000322 | Invalid table type | 内部错误 | 上报issue |
|
||||
| 0x80000323 | Object not there | 内部错误 | 上报issue |
|
||||
| 0x80000326 | Invalid action type | 内部错误 | 上报issue |
|
||||
| 0x80000328 | Invalid raw data version | 内部错误 | 上报issue |
|
||||
| 0x80000329 | Invalid raw data len | 内部错误 | 上报issue |
|
||||
| 0x8000032A | Invalid raw data content | 内部错误 | 上报issue |
|
||||
| 0x8000032C | Object is creating | 内部错误 | 上报issue |
|
||||
| 0x8000032D | Object is dropping | 内部错误 | 上报issue |
|
||||
| 0x80000330 | Dnode already exists | 内部错误 | 上报issue |
|
||||
| 0x80000331 | Dnode does not exist | 内部错误 | 上报issue |
|
||||
| 0x80000332 | Vgroup does not exist | 内部错误 | 上报issue |
|
||||
| 0x80000333 | Cannot drop mnode which is leader | 操作节点为leader | 确认操作是否正确 |
|
||||
| 0x80000334 | Out of dnodes | dnode节点数量不够 | 增加dnode节点 |
|
||||
| 0x80000335 | Cluster cfg inconsistent | 配置不一致 | 检查dnode节点与mnode节点配置是否一致。检查方式:1.节点启动时,在日志中输出 2.使用show variables |
|
||||
| 0x8000033B | Cluster id not match | 节点配置数据不一致 | 检查各节点data/dnode/dnodes.json文件中的clusterid |
|
||||
| 0x80000340 | Account already exists | (仅企业版)内部错误 | 上报issue |
|
||||
| 0x80000320 | Object already there | 内部错误 | 上报 issue |
|
||||
| 0x80000322 | Invalid table type | 内部错误 | 上报 issue |
|
||||
| 0x80000323 | Object not there | 内部错误 | 上报 issue |
|
||||
| 0x80000326 | Invalid action type | 内部错误 | 上报 issue |
|
||||
| 0x80000328 | Invalid raw data version | 内部错误 | 上报 issue |
|
||||
| 0x80000329 | Invalid raw data len | 内部错误 | 上报 issue |
|
||||
| 0x8000032A | Invalid raw data content | 内部错误 | 上报 issue |
|
||||
| 0x8000032C | Object is creating | 内部错误 | 上报 issue |
|
||||
| 0x8000032D | Object is dropping | 内部错误 | 上报 issue |
|
||||
| 0x80000330 | Dnode already exists | 内部错误 | 上报 issue |
|
||||
| 0x80000331 | Dnode does not exist | 内部错误 | 上报 issue |
|
||||
| 0x80000332 | Vgroup does not exist | 内部错误 | 上报 issue |
|
||||
| 0x80000333 | Cannot drop mnode which is leader | 操作节点为 leader | 确认操作是否正确 |
|
||||
| 0x80000334 | Out of dnodes | dnode 节点数量不够 | 增加dnode 节点 |
|
||||
| 0x80000335 | Cluster cfg inconsistent | 配置不一致 | 检查dnode 节点与 mnode 节点配置是否一致。检查方式:1.节点启动时,在日志中输出 2.使用 show variables |
|
||||
| 0x8000033B | Cluster id not match | 节点配置数据不一致 | 检查各节点 data/dnode/dnodes.json 文件中的 clusterid |
|
||||
| 0x80000340 | Account already exists | (仅企业版)内部错误 | 上报 issue |
|
||||
| 0x80000342 | Invalid account options | (仅企业版)该操作不支持 | 确认操作是否正确 |
|
||||
| 0x80000344 | Invalid account | 账户不存在 | 确认账户是否正确 |
|
||||
| 0x80000350 | User already exists | Create user, 重复创建 | 确认操作是否正确 |
|
||||
| 0x80000351 | Invalid user | 用户不存在 | 确认操作是否正确 |
|
||||
| 0x80000352 | Invalid user format | 格式不正确 | 确认操作是否正确 |
|
||||
| 0x80000353 | Invalid password format | 密码长度必须为 8 到 16 位,并且至少包含大写字母、小写字母、数字、特殊字符中的三类 | 确认密码字符串的格式 |
|
||||
| 0x80000354 | Can not get user from conn | 内部错误 | 上报issue |
|
||||
| 0x80000354 | Can not get user from conn | 内部错误 | 上报 issue |
|
||||
| 0x80000355 | Too many users | (仅企业版)用户数量超限 | 调整配置 |
|
||||
| 0x80000357 | Authentication failure | 密码不正确 | 确认操作是否正确 |
|
||||
| 0x80000358 | User not available | 用户不存在 | 确认操作是否正确 |
|
||||
| 0x80000360 | STable already exists | 内部错误 | 上报issue |
|
||||
| 0x80000361 | STable not exist | 内部错误 | 上报issue |
|
||||
| 0x80000364 | Too many tags | tag数量太多 | 不能修改,代码级别限制 |
|
||||
| 0x80000365 | Too many columns | columns数量太多 | 不能修改,代码级别限制 |
|
||||
| 0x80000369 | Tag already exists | tag已存在 | 确认操作是否正确 |
|
||||
| 0x8000036A | Tag does not exist | tag不存在 | 确认操作是否正确 |
|
||||
| 0x80000360 | STable already exists | 内部错误 | 上报 issue |
|
||||
| 0x80000361 | STable not exist | 内部错误 | 上报 issue |
|
||||
| 0x80000364 | Too many tags | tag 数量太多 | 不能修改,代码级别限制 |
|
||||
| 0x80000365 | Too many columns | columns 数量太多 | 不能修改,代码级别限制 |
|
||||
| 0x80000369 | Tag already exists | tag 已存在 | 确认操作是否正确 |
|
||||
| 0x8000036A | Tag does not exist | tag 不存在 | 确认操作是否正确 |
|
||||
| 0x8000036B | Column already exists | Column 已存在 | 确认操作是否正确 |
|
||||
| 0x8000036C | Column does not exist | Column 不存在 | 确认操作是否正确 |
|
||||
| 0x8000036E | Invalid stable options | 内部错误 | 上报issue |
|
||||
| 0x8000036F | Invalid row bytes | 内部错误 | 上报issue |
|
||||
| 0x80000370 | Invalid func name | name长度错误 | 确认操作是否正确 |
|
||||
| 0x80000372 | Invalid func code | code长度错误 | 确认操作是否正确 |
|
||||
| 0x80000373 | Func already exists | Func已存在 | 确认操作是否正确 |
|
||||
| 0x80000374 | Func not exists | Func不存在 | 确认操作是否正确 |
|
||||
| 0x80000375 | Invalid func bufSize | bufSize长度错误,或者超过限制 | 确认操作是否正确 |
|
||||
| 0x8000036E | Invalid stable options | 内部错误 | 上报 issue |
|
||||
| 0x8000036F | Invalid row bytes | 内部错误 | 上报 issue |
|
||||
| 0x80000370 | Invalid func name | name 长度错误 | 确认操作是否正确 |
|
||||
| 0x80000372 | Invalid func code | code 长度错误 | 确认操作是否正确 |
|
||||
| 0x80000373 | Func already exists | Func 已存在 | 确认操作是否正确 |
|
||||
| 0x80000374 | Func not exists | Func 不存在 | 确认操作是否正确 |
|
||||
| 0x80000375 | Invalid func bufSize | bufSize 长度错误,或者超过限制 | 确认操作是否正确 |
|
||||
| 0x80000378 | Invalid func comment | 长度错误,或者超过限制 | 确认操作是否正确 |
|
||||
| 0x80000379 | Invalid func retrieve msg | 长度错误,或者超过限制 | 确认操作是否正确 |
|
||||
| 0x80000380 | Database not specified or available | 未指定database | 使用 use database; |
|
||||
| 0x80000381 | Database already exists | Database已存在 | 确认操作是否正确 |
|
||||
| 0x80000382 | Invalid database options | 内部错误 | 上报issue |
|
||||
| 0x80000380 | Database not specified or available | 未指定 database | 使用 use database; |
|
||||
| 0x80000381 | Database already exists | Database 已存在 | 确认操作是否正确 |
|
||||
| 0x80000382 | Invalid database options | 内部错误 | 上报 issue |
|
||||
| 0x80000383 | Invalid database name | 长度错误 | 确认操作是否正确 |
|
||||
| 0x80000385 | Too many databases for account | 数量超限 | 调整配置 |
|
||||
| 0x80000386 | Database in dropping status | 数据库正在被删除 | 重试,长时间保持该状态上报issue |
|
||||
| 0x80000386 | Database in dropping status | 数据库正在被删除 | 重试,长时间保持该状态上报 issue |
|
||||
| 0x80000388 | Database not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x80000389 | Invalid database account | 内部错误 | 上报issue |
|
||||
| 0x80000389 | Invalid database account | 内部错误 | 上报 issue |
|
||||
| 0x8000038A | Database options not changed | 操作无变化 | 确认操作是否正确 |
|
||||
| 0x8000038B | Index not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x80000396 | Database in creating status | 数据库正在被创建 | 重试 |
|
||||
| 0x8000039A | Invalid system table name | 内部错误 | 上报issue |
|
||||
| 0x8000039A | Invalid system table name | 内部错误 | 上报 issue |
|
||||
| 0x800003A0 | Mnode already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x800003A1 | Mnode not there | 已存在 | 确认操作是否正确 |
|
||||
| 0x800003A2 | Qnode already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x800003A3 | Qnode not there | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003A4 | Snode already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x800003A5 | Snode not there | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003A8 | The replica of mnode cannot less than 1 | mnode少于1 | 操作不允许 |
|
||||
| 0x800003A9 | The replica of mnode cannot exceed 3 | mnode多于1 | 操作不允许 |
|
||||
| 0x800003A8 | The replica of mnode cannot less than 1 | mnode 少于 1 | 操作不允许 |
|
||||
| 0x800003A9 | The replica of mnode cannot exceed 3 | mnode 多于 1 | 操作不允许 |
|
||||
| 0x800003B1 | No enough memory in dnode | 内存不足 | 调整配置 |
|
||||
| 0x800003B3 | Invalid dnode end point | ep配置不正确 | 确认操作是否正确 |
|
||||
| 0x800003B3 | Invalid dnode end point | ep 配置不正确 | 确认操作是否正确 |
|
||||
| 0x800003B6 | Offline dnode exists | Dnode offline | 检查节点状态 |
|
||||
| 0x800003B7 | Invalid vgroup replica | 内部错误 | 上报issue |
|
||||
| 0x800003B7 | Invalid vgroup replica | 内部错误 | 上报 issue |
|
||||
| 0x800003B8 | Dnode in creating status | 正在创建 | 重试 |
|
||||
| 0x800003B9 | Dnode in dropping status | 正在删除 | 重试 |
|
||||
| 0x800003C2 | Invalid stable alter options | 内部错误 | 上报issue |
|
||||
| 0x800003C2 | Invalid stable alter options | 内部错误 | 上报 issue |
|
||||
| 0x800003C3 | STable option unchanged | 操作无变化 | 确认操作是否正确 |
|
||||
| 0x800003C4 | Field used by topic | 被使用 | 确认操作是否正确 |
|
||||
| 0x800003C5 | Database is single stable mode | 内部错误 | 上报issue |
|
||||
| 0x800003C6 | Invalid schema version while alter stb | 内部错误 | 上报issue |
|
||||
| 0x800003C7 | Invalid stable uid while alter stb | 内部错误 | 上报issue |
|
||||
| 0x800003C5 | Database is single stable mode | 内部错误 | 上报 issue |
|
||||
| 0x800003C6 | Invalid schema version while alter stb | 内部错误 | 上报 issue |
|
||||
| 0x800003C7 | Invalid stable uid while alter stb | 内部错误 | 上报 issue |
|
||||
| 0x800003C8 | Field used by tsma | 被使用 | 确认操作是否正确 |
|
||||
| 0x800003D1 | Transaction not exists | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003D2 | Invalid stage to kill | 事务处在不能被kill的节点(比如 在commit阶段) | 等待事务结束,如长时间不结束,上报issue |
|
||||
| 0x800003D3 | Conflict transaction not completed | 事务冲突,不能执行该操作 | 使用show transactions命令查看冲突的事务,等待冲突事务结束,如长时间不结束,上报issue |
|
||||
| 0x800003D4 | Transaction commitlog is null | 内部错误 | 上报issue |
|
||||
| 0x800003D2 | Invalid stage to kill | 事务处在不能被 kill 的节点(比如 在 commit 阶段) | 等待事务结束,如长时间不结束,上报 issue |
|
||||
| 0x800003D3 | Conflict transaction not completed | 事务冲突,不能执行该操作 | 使用 show transactions 命令查看冲突的事务,等待冲突事务结束,如长时间不结束,上报 issue |
|
||||
| 0x800003D4 | Transaction commitlog is null | 内部错误 | 上报 issue |
|
||||
| 0x800003D5 | Unable to establish connection While execute transaction and will continue in the background | 网络错误 | 检查网络是否正常 |
|
||||
| 0x800003D6 | Last Transaction not finished | 内部错误 | 上报issue |
|
||||
| 0x800003D7 | Sync timeout While execute transaction and will continue in the background | 内部错误 | 上报issue |
|
||||
| 0x800003DF | Unknown transaction error | 内部错误 | 上报issue |
|
||||
| 0x800003D6 | Last Transaction not finished | 内部错误 | 上报 issue |
|
||||
| 0x800003D7 | Sync timeout While execute transaction and will continue in the background | 内部错误 | 上报 issue |
|
||||
| 0x800003DF | Unknown transaction error | 内部错误 | 上报 issue |
|
||||
| 0x800003E0 | Topic already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x800003E1 | Topic not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003E3 | Invalid topic | 内部错误 | 上报issue |
|
||||
| 0x800003E4 | Topic with invalid query | 内部错误 | 上报issue |
|
||||
| 0x800003E5 | Topic with invalid option | 内部错误 | 上报issue |
|
||||
| 0x800003E3 | Invalid topic | 内部错误 | 上报 issue |
|
||||
| 0x800003E4 | Topic with invalid query | 内部错误 | 上报 issue |
|
||||
| 0x800003E5 | Topic with invalid option | 内部错误 | 上报 issue |
|
||||
| 0x800003E6 | Consumer not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003E7 | Topic unchanged | 无变化 | 确认操作是否正确 |
|
||||
| 0x800003E8 | Subcribe not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003E9 | Offset not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003EA | Consumer not ready | 内部错误 | 上报issue |
|
||||
| 0x800003EA | Consumer not ready | 内部错误 | 上报 issue |
|
||||
| 0x800003EB | Topic subscribed cannot be dropped | 被使用 | 确认操作是否正确 |
|
||||
| 0x800003EC | Consumer group being used by some consumer | 被使用 | 确认操作是否正确 |
|
||||
| 0x800003ED | Topic must be dropped first | 被使用 | 确认操作是否正确 |
|
||||
|
@ -217,14 +217,14 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 0x800003EF | Topic being rebalanced | 操作中 | 重试 |
|
||||
| 0x800003F0 | Stream already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x800003F1 | Stream not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x800003F2 | Invalid stream option | 内部错误 | 上报issue |
|
||||
| 0x800003F2 | Invalid stream option | 内部错误 | 上报 issue |
|
||||
| 0x800003F3 | Stream must be dropped first | 被使用 | 确认操作是否正确 |
|
||||
| 0x800003F5 | Stream temporarily does not support source db having replica > 1 | 超过限制 | 操作不被允许 |
|
||||
| 0x800003F6 | Too many streams | 超过限制 | 不能修改,代码级别限制 |
|
||||
| 0x800003F7 | Cannot write the same stable as other stream | 内部错误 | 上报issue |
|
||||
| 0x800003F7 | Cannot write the same stable as other stream | 内部错误 | 上报 issue |
|
||||
| 0x80000480 | index already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x80000481 | index not exist | 不存在 | 确认操作是否正确 |
|
||||
| 0x80000482 | Invalid sma index option | 内部错误 | 上报issue |
|
||||
| 0x80000482 | Invalid sma index option | 内部错误 | 上报 issue |
|
||||
| 0x80000483 | index already exists | 已存在 | 确认操作是否正确 |
|
||||
| 0x80000484 | index not exist | 不存在 | 确认操作是否正确 |
|
||||
|
||||
|
@ -235,13 +235,13 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| ---------- | ---------------------- | ---------------------------- | ------------------ |
|
||||
| 0x80000408 | Dnode is offline | 不在线 | 检查节点状态 |
|
||||
| 0x80000409 | Mnode already deployed | 已部署 | 确认操作是否正确 |
|
||||
| 0x8000040A | Mnode not found | 内部错误 | 上报issue |
|
||||
| 0x8000040B | Mnode not deployed | 内部错误 | 上报issue |
|
||||
| 0x8000040A | Mnode not found | 内部错误 | 上报 issue |
|
||||
| 0x8000040B | Mnode not deployed | 内部错误 | 上报 issue |
|
||||
| 0x8000040C | Qnode already deployed | 已部署 | 确认操作是否正确 |
|
||||
| 0x8000040D | Qnode not found | 内部错误 | 上报issue |
|
||||
| 0x8000040E | Qnode not deployed | 内部错误 | 上报issue |
|
||||
| 0x8000040D | Qnode not found | 内部错误 | 上报 issue |
|
||||
| 0x8000040E | Qnode not deployed | 内部错误 | 上报 issue |
|
||||
| 0x8000040F | Snode already deployed | 已部署 | 确认操作是否正确 |
|
||||
| 0x80000410 | Snode not found | 内部错误 | 上报issue |
|
||||
| 0x80000410 | Snode not found | 内部错误 | 上报 issue |
|
||||
| 0x80000411 | Snode not deployed | 已部署 | 确认操作是否正确 |
|
||||
|
||||
|
||||
|
@ -286,18 +286,18 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | ------------------------------------ | ------------------------------------------ | ------------------------------------------------------ |
|
||||
| 0x80000700 | Invalid query handle | 当前查询句柄不存在 | 保留现场和日志,github上报issue |
|
||||
| 0x80000709 | Multiple retrieval of this query | 当前子查询已经正在进行中 | 保留现场和日志,github上报issue |
|
||||
| 0x80000700 | Invalid query handle | 当前查询句柄不存在 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000709 | Multiple retrieval of this query | 当前子查询已经正在进行中 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000070A | Too many groups/time window in query | 当前查询结果中的分组或窗口个数超过限制个数 | 调整查询语句,确保查询条件中的分组和窗口个数不超过上限 |
|
||||
| 0x8000070D | System error | 底层系统API返回错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80000720 | Scheduler not exist | 当前子查询对应的客户端信息不存在 | 保留现场和日志,github上报issue |
|
||||
| 0x80000721 | Task not exist | 子查询不存在 | 保留现场和日志,github上报issue |
|
||||
| 0x80000722 | Task already exist | 子查询已经存在 | 保留现场和日志,github上报issue |
|
||||
| 0x80000729 | Task message error | 查询消息错误 | 保留现场和日志,github上报issue |
|
||||
| 0x8000072B | Task status error | 子查询状态错误 | 保留现场和日志,github上报issue |
|
||||
| 0x8000072F | Job not exist | 查询JOB已经不存在 | 保留现场和日志,github上报issue |
|
||||
| 0x8000070D | System error | 底层系统 API 返回错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000720 | Scheduler not exist | 当前子查询对应的客户端信息不存在 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000721 | Task not exist | 子查询不存在 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000722 | Task already exist | 子查询已经存在 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000729 | Task message error | 查询消息错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000072B | Task status error | 子查询状态错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x8000072F | Job not exist | 查询 JOB 已经不存在 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80000739 | Query memory upper limit is reached | 单个查询达到内存使用上限 | 设置合理的内存上限或调整 SQL 语句 |
|
||||
| 0x8000073A | Query memory exhausted | dnode查询内存到达使用上限 | 设置合理的内存上限或调整并发查询量或增大系统内存 |
|
||||
| 0x8000073A | Query memory exhausted | dnode 查询内存到达使用上限 | 设置合理的内存上限或调整并发查询量或增大系统内存 |
|
||||
| 0x8000073B | Timeout for long time no fetch | 查询被长时间中断未恢复 | 调整应用实现尽快 fetch 数据 |
|
||||
|
||||
## grant
|
||||
|
@ -329,9 +329,9 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 0x80000911 | Sync not ready to propose | 场景1:恢复未完成 | 检查集群状态,例如:show vgroups。查看服务端日志,以及服务端节点之间的网络状况。 |
|
||||
| 0x80000914 | Sync leader is restoring | 场景1:发生了切主 选主后,日志重演中 | 检查集群状态,例如:show vgroups。查看服务端日志,观察恢复进度。 |
|
||||
| 0x80000915 | Sync invalid snapshot msg | 快照复制消息错误 | 服务端内部错误 |
|
||||
| 0x80000916 | Sync buffer is full | 场景1:客户端请求并发数特别大,超过了服务端处理能力,或者因为网络和CPU资源严重不足,或者网络连接问题等。 | 检查集群状态,系统资源使用率(例如磁盘IO、CPU、网络通信等),以及节点之间网络连接状况。 |
|
||||
| 0x80000917 | Sync write stall | 场景1:状态机执行被阻塞,例如因系统繁忙,磁盘IO资源严重不足,或落盘失败等 | 检查集群状态,系统资源使用率(例如磁盘IO和CPU等),以及是否发生了落盘失败等。 |
|
||||
| 0x80000918 | Sync negotiation win is full | 场景1:客户端请求并发数特别大,超过了服务端处理能力,或者因为网络和CPU资源严重不足,或者网络连接问题等。 | 检查集群状态,系统资源使用率(例如磁盘IO、CPU、网络通信等),以及节点之间网络连接状况。 |
|
||||
| 0x80000916 | Sync buffer is full | 场景1:客户端请求并发数特别大,超过了服务端处理能力,或者因为网络和CPU资源严重不足,或者网络连接问题等。 | 检查集群状态,系统资源使用率(例如磁盘 IO、CPU、网络通信等),以及节点之间网络连接状况。 |
|
||||
| 0x80000917 | Sync write stall | 场景1:状态机执行被阻塞,例如因系统繁忙,磁盘IO资源严重不足,或落盘失败等 | 检查集群状态,系统资源使用率(例如磁盘 IO 和 CPU 等),以及是否发生了落盘失败等。 |
|
||||
| 0x80000918 | Sync negotiation win is full | 场景1:客户端请求并发数特别大,超过了服务端处理能力,或者因为网络和CPU资源严重不足,或者网络连接问题等。 | 检查集群状态,系统资源使用率(例如磁盘 IO、CPU、网络通信等),以及节点之间网络连接状况。 |
|
||||
| 0x800009FF | Sync internal error | 其它内部错误 | 检查集群状态,例如:show vgroups |
|
||||
|
||||
|
||||
|
@ -341,17 +341,17 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | ------------------------- | --------------------------------------------------------------- | -------------------------------------- |
|
||||
| 0x80000A0C | TQ table schema not found | 消费数据时表不存在 | 内部错误,不透传给用户 |
|
||||
| 0x80000A0D | TQ no committed offset | 消费时设置offset reset = none,并且server端没有之前消费的offset | 设置offset reset为earliest 或者 latest |
|
||||
| 0x80000A0D | TQ no committed offset | 消费时设置 offset reset = none,并且 server 端没有之前消费的 offset | 设置 offset reset 为 earliest 或者 latest |
|
||||
|
||||
|
||||
## wal
|
||||
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | --------------------- | -------------------------------- | ------------------ |
|
||||
| 0x80001001 | WAL file is corrupted | WAL文件损坏 | 服务端内部错误 |
|
||||
| 0x80001001 | WAL file is corrupted | WAL 文件损坏 | 服务端内部错误 |
|
||||
| 0x80001003 | WAL invalid version | 请求日志版本,超过了当前日志范围 | 服务端内部错误 |
|
||||
| 0x80001005 | WAL log not exist | 请求日志记录,不存在 | 服务端内部错误 |
|
||||
| 0x80001006 | WAL checksum mismatch | 场景:发生了WAL文件损坏 | 服务端内部错误 |
|
||||
| 0x80001006 | WAL checksum mismatch | 场景:发生了 WAL 文件损坏 | 服务端内部错误 |
|
||||
| 0x80001007 | WAL log incomplete | 日志文件发生了丢失或损坏 | 服务端内部错误 |
|
||||
|
||||
## tfs
|
||||
|
@ -371,16 +371,16 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | -------------------------------- | ---------------------------- | -------------------------------- |
|
||||
| 0x80002400 | catalog internal error | catalog内部错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002401 | catalog invalid input parameters | catalog输入参数错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002402 | catalog is not ready | catalog未初始化完成 | 保留现场和日志,github上报issue |
|
||||
| 0x80002403 | catalog system error | catalog系统错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002404 | Database is dropped | db缓存被删除 | 保留现场和日志,github上报issue |
|
||||
| 0x80002405 | catalog is out of service | catalog模块已经退出 | 保留现场和日志,github上报issue |
|
||||
| 0x80002550 | Invalid msg order | 消息顺序错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002501 | Job status error | 任务状态错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002502 | scheduler internal error | scheduler内部错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002504 | Task timeout | 子任务超时 | 保留现场和日志,github上报issue |
|
||||
| 0x80002400 | catalog internal error | catalog 内部错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002401 | catalog invalid input parameters | catalog 输入参数错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002402 | catalog is not ready | catalog 未初始化完成 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002403 | catalog system error | catalog 系统错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002404 | Database is dropped | db 缓存被删除 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002405 | catalog is out of service | catalog 模块已经退出 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002550 | Invalid msg order | 消息顺序错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002501 | Job status error | 任务状态错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002502 | scheduler internal error | scheduler 内部错误 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002504 | Task timeout | 子任务超时 | 保留现场和日志,github 上报 issue |
|
||||
| 0x80002505 | Job is dropping | 任务正在或已经被取消 | 检查是否有手动或应用中断当前任务 |
|
||||
|
||||
|
||||
|
@ -389,139 +389,139 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------- | ------------------------------------- |
|
||||
| 0x80002600 | syntax error near | SQL语法错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002601 | Incomplete SQL statement | 不完整的SQL语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002600 | syntax error near | SQL 语法错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002601 | Incomplete SQL statement | 不完整的 SQL 语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002602 | Invalid column name | 不合法或不存在的列名 | 检查并修正 SQL 语句 |
|
||||
| 0x80002603 | Table does not exist | 表不存在 | 检查并确认SQL语句中的表是否存在 |
|
||||
| 0x80002604 | Column ambiguously defined | 列名(别名)重复定义 | 检查并修正 SQL 语句 |
|
||||
| 0x80002605 | Invalid value type | 常量值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002608 | There mustn't be aggregation | 聚合函数出现在非法子句中 | 检查并修正 SQL 语句 |
|
||||
| 0x80002609 | ORDER BY item must be the number of a SELECT-list expression | Order by指定的位置不合法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260A | Not a GROUP BY expression | 非法group by语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002609 | ORDER BY item must be the number of a SELECT-list expression | Order by 指定的位置不合法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260A | Not a GROUP BY expression | 非法 group by 语句 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260B | Not SELECTed expression | 非法表达式 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260C | Not a single-group group function | 非法使用列与函数 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260D | Tags number not matched | tag列个数不匹配 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260E | Invalid tag name | 无效或不存在的tag名 | 检查并修正 SQL 语句 |
|
||||
| 0x80002610 | Value is too long | 值长度超出限制 | 检查并修正 SQL 语句或API参数 |
|
||||
| 0x8000260D | Tags number not matched | tag 列个数不匹配 | 检查并修正 SQL 语句 |
|
||||
| 0x8000260E | Invalid tag name | 无效或不存在的 tag 名 | 检查并修正 SQL 语句 |
|
||||
| 0x80002610 | Value is too long | 值长度超出限制 | 检查并修正 SQL 语句或 API 参数 |
|
||||
| 0x80002611 | Password too short or empty | 密码为空或少于 8 个字符 | 使用合法的密码 |
|
||||
| 0x80002612 | Port should be an integer that is less than 65535 and greater than 0 | 端口号非法 | 检查并修正端口号 |
|
||||
| 0x80002613 | Endpoint should be in the format of 'fqdn:port' | 地址格式错误 | 检查并修正地址信息 |
|
||||
| 0x80002614 | This statement is no longer supported | 功能已经废弃 | 参考功能文档说明 |
|
||||
| 0x80002615 | Interval too small | interval值超过允许的最小值 | 更改INTERVAL值 |
|
||||
| 0x80002615 | Interval too small | interval 值超过允许的最小值 | 更改 INTERVAL 值 |
|
||||
| 0x80002616 | Database not specified | 未指定数据库 | 指定当前操作的数据库 |
|
||||
| 0x80002617 | Invalid identifier name | ID非法或长度不合法 | 检查语句中相关的库、表、列、TAG等名称 |
|
||||
| 0x80002617 | Invalid identifier name | ID 非法或长度不合法 | 检查语句中相关的库、表、列、TAG 等名称 |
|
||||
| 0x80002618 | Corresponding super table not in this db | 超级表不存在 | 检查库中是否存在对应的超级表 |
|
||||
| 0x80002619 | Invalid database option | 数据库选项值非法 | 检查并修正数据库选项值 |
|
||||
| 0x8000261A | Invalid table option | 表选项值非法 | 检查并修正数据表选项值 |
|
||||
| 0x80002624 | GROUP BY and WINDOW-clause can't be used together | Group by和窗口不能同时使用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002624 | GROUP BY and WINDOW-clause can't be used together | Group by 和窗口不能同时使用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002627 | Aggregate functions do not support nesting | 函数不支持嵌套使用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002628 | Only support STATE_WINDOW on integer/bool/varchar column | 不支持的STATE_WINDOW数据类型 | 检查并修正 SQL 语句 |
|
||||
| 0x80002629 | Not support STATE_WINDOW on tag column | 不支持TAG列的STATE_WINDOW | 检查并修正 SQL 语句 |
|
||||
| 0x8000262A | STATE_WINDOW not support for super table query | 不支持超级表的STATE_WINDOW | 检查并修正 SQL 语句 |
|
||||
| 0x8000262B | SESSION gap should be fixed time window, and greater than 0 | SESSION窗口值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000262C | Only support SESSION on primary timestamp column | SESSION窗口列非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002628 | Only support STATE_WINDOW on integer/bool/varchar column | 不支持的 STATE_WINDOW 数据类型 | 检查并修正 SQL 语句 |
|
||||
| 0x80002629 | Not support STATE_WINDOW on tag column | 不支持 TAG 列的 STATE_WINDOW | 检查并修正 SQL 语句 |
|
||||
| 0x8000262A | STATE_WINDOW not support for super table query | 不支持超级表的 STATE_WINDOW | 检查并修正 SQL 语句 |
|
||||
| 0x8000262B | SESSION gap should be fixed time window, and greater than 0 | SESSION 窗口值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000262C | Only support SESSION on primary timestamp column | SESSION 窗口列非法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000262D | Interval offset cannot be negative | INTERVAL offset值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000262E | Cannot use 'year' as offset when interval is 'month' | INTERVAL offset单位非法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000262F | Interval offset should be shorter than interval | INTERVAL offset值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002630 | Does not support sliding when interval is natural month/year | sliding单位非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002631 | sliding value no larger than the interval value | sliding值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002632 | sliding value can not less than 1%% of interval value | sliding值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002633 | Only one tag if there is a json tag | 只支持单个JSON TAG列 | 检查并修正 SQL 语句 |
|
||||
| 0x80002630 | Does not support sliding when interval is natural month/year | sliding 单位非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002631 | sliding value no larger than the interval value | sliding 值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002632 | sliding value can not less than 1%% of interval value | sliding 值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002633 | Only one tag if there is a json tag | 只支持单个 JSON TAG 列 | 检查并修正 SQL 语句 |
|
||||
| 0x80002634 | Query block has incorrect number of result columns | 列个数不匹配 | 检查并修正 SQL 语句 |
|
||||
| 0x80002635 | Incorrect TIMESTAMP value | 主键时间戳列值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002637 | soffset/offset can not be less than 0 | soffset/offset值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002638 | slimit/soffset only available for PARTITION/GROUP BY query | slimit/soffset只支持PARTITION BY/GROUP BY语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002639 | Invalid topic query | 不支持的TOPIC查询语 |
|
||||
| 0x80002637 | soffset/offset can not be less than 0 | soffset/offset 值非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002638 | slimit/soffset only available for PARTITION/GROUP BY query | slimit/soffset 只支持 PARTITION BY/GROUP BY 语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002639 | Invalid topic query | 不支持的 TOPIC 查询语法 |
|
||||
| 0x8000263A | Cannot drop super table in batch | 不支持批量删除超级表 | 检查并修正 SQL 语句 |
|
||||
| 0x8000263B | Start(end) time of query range required or time range too large | 窗口个数超出限制 | 检查并修正 SQL 语句 |
|
||||
| 0x8000263C | Duplicated column names | 列名称重复 | 检查并修正 SQL 语句 |
|
||||
| 0x8000263D | Tags length exceeds max length | TAG值长度超出最大支持范围 | 检查并修正 SQL 语句 |
|
||||
| 0x8000263D | Tags length exceeds max length | TAG 值长度超出最大支持范围 | 检查并修正 SQL 语句 |
|
||||
| 0x8000263E | Row length exceeds max length | 行长度检查并修正 SQL 语句 | 检查并修正 SQL 语句 |
|
||||
| 0x8000263F | Illegal number of columns | 列个数错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002640 | Too many columns | 列个数超出上限 | 检查并修正 SQL 语句 |
|
||||
| 0x80002641 | First column must be timestamp | 第一列必须是主键时间戳列 | 检查并修正 SQL 语句 |
|
||||
| 0x80002642 | Invalid binary/nchar column/tag length | binary/nchar长度错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002643 | Invalid number of tag columns | TAG列个数错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002642 | Invalid binary/nchar column/tag length | binary/nchar 长度错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002643 | Invalid number of tag columns | TAG 列个数错误 | 检查并修正 SQL 语句 |
|
||||
| 0x80002644 | Permission denied | 权限错误 | 检查确认用户是否有相应操作权限 |
|
||||
| 0x80002645 | Invalid stream query | 非法流语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002646 | Invalid _c0 or _rowts expression | _c0或_rowts非法使用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002646 | Invalid _c0 or _rowts expression | _c0 或 _rowts 非法使用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002647 | Invalid timeline function | 函数依赖的主键时间戳不存在 | 检查并修正 SQL 语句 |
|
||||
| 0x80002648 | Invalid password | 密码不符合规范 | 检查并修改密码 |
|
||||
| 0x80002649 | Invalid alter table statement | 修改表语句不合法 | 检查并修正 SQL 语句 |
|
||||
| 0x8000264A | Primary timestamp column cannot be dropped | 主键时间戳列不允许删除 | 检查并修正 SQL 语句 |
|
||||
| 0x8000264B | Only binary/nchar column length could be modified, and the length can only be increased, not decreased | 非法列修改 | 检查并修正 SQL 语句 |
|
||||
| 0x8000264C | Invalid tbname pseudo column | 非法使用tbname列 | 检查并修正 SQL 语句 |
|
||||
| 0x8000264C | Invalid tbname pseudo column | 非法使用 tbname 列 | 检查并修正 SQL 语句 |
|
||||
| 0x8000264D | Invalid function name | 非法函数名 | 检查并修正函数名 |
|
||||
| 0x8000264E | Comment too long | 注释长度超限 | 检查并修正 SQL 语句 |
|
||||
| 0x8000264F | Function(s) only allowed in SELECT list, cannot mixed with non scalar functions or columns | 非法的函数混用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002650 | Window query not supported, since no valid timestamp column included in the result of subquery | 窗口查询依赖的主键时间戳列不存在 | 检查并修正 SQL 语句 |
|
||||
| 0x80002651 | No columns can be dropped | 必须的列不能被删除 | 检查并修正 SQL 语句 |
|
||||
| 0x80002652 | Only tag can be json type | 普通列不支持JSON类型 | 检查并修正 SQL 语句 |
|
||||
| 0x80002655 | The DELETE statement must have a definite time window range | DELETE语句中存在非法WHERE条件 | 检查并修正 SQL 语句 |
|
||||
| 0x80002656 | The REDISTRIBUTE VGROUP statement only support 1 to 3 dnodes | REDISTRIBUTE VGROUP指定的DNODE个数非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002657 | Fill now allowed | 函数不允许FILL功能 | 检查并修正 SQL 语句 |
|
||||
| 0x80002652 | Only tag can be json type | 普通列不支持 JSON 类型 | 检查并修正 SQL 语句 |
|
||||
| 0x80002655 | The DELETE statement must have a definite time window range | DELETE 语句中存在非法 WHERE 条件 | 检查并修正 SQL 语句 |
|
||||
| 0x80002656 | The REDISTRIBUTE VGROUP statement only support 1 to 3 dnodes | REDISTRIBUTE VGROUP 指定的 DNODE 个数非法 | 检查并修正 SQL 语句 |
|
||||
| 0x80002657 | Fill now allowed | 函数不允许 FILL 功能 | 检查并修正 SQL 语句 |
|
||||
| 0x80002658 | Invalid windows pc | 非法使用窗口伪列 | 检查并修正 SQL 语句 |
|
||||
| 0x80002659 | Window not allowed | 函数不能在窗口中使用 | 检查并修正 SQL 语句 |
|
||||
| 0x8000265A | Stream not allowed | 函数不能在流计算中使用 | 检查并修正 SQL 语句 |
|
||||
| 0x8000265B | Group by not allowd | 函数不能在分组中使用 | 检查并修正 SQL 语句 |
|
||||
| 0x8000265D | Invalid interp clause | 非法INTERP或相关语句 | 检查并修正 SQL 语句 |
|
||||
| 0x8000265D | Invalid interp clause | 非法 INTERP 或相关语句 | 检查并修正 SQL 语句 |
|
||||
| 0x8000265E | Not valid function ion window | 非法窗口语句 | 检查并修正 SQL 语句 |
|
||||
| 0x8000265F | Only support single table | 函数只支持在单表查询中使用 | 检查并修正 SQL 语句 |
|
||||
| 0x80002660 | Invalid sma index | 非法创建SMA语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002660 | Invalid sma index | 非法创建 SMA 语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002661 | Invalid SELECTed expression | 无效查询语句 | 检查并修正 SQL 语句 |
|
||||
| 0x80002662 | Fail to get table info | 获取表元数据信息失败 | 保留现场和日志,github上报issue |
|
||||
| 0x80002663 | Not unique table/alias | 表名(别名)冲突 | 检查并修正 SQL 语句 |
|
||||
| 0x80002664 | Join requires valid time series input | 不支持子查询不含主键时间戳列输出的JOIN查询 | 检查并修正 SQL 语句 |
|
||||
| 0x80002665 | The _TAGS pseudo column can only be used for subtable and supertable queries | 非法TAG列查询 | 检查并修正 SQL 语句 |
|
||||
| 0x80002664 | Join requires valid time series input | 不支持子查询不含主键时间戳列输出的 JOIN 查询 | 检查并修正 SQL 语句 |
|
||||
| 0x80002665 | The _TAGS pseudo column can only be used for subtable and supertable queries | 非法 TAG 列查询 | 检查并修正 SQL 语句 |
|
||||
| 0x80002666 | 子查询不含主键时间戳列输出 | 检查并修正 SQL 语句 |
|
||||
| 0x80002667 | Invalid usage of expr: %s | 非法表达式 | 检查并修正 SQL 语句 |
|
||||
| 0x80002687 | True_for duration cannot be negative | true_for 的值不能是负数 | 检查并修正 SQL 语句 |
|
||||
| 0x80002688 | Cannot use 'year' or 'month' as true_for duration | 不能使用 n(月), y(年) 作为 true_for 的时间单位 | 检查并修正 SQL 语句 |
|
||||
| 0x80002689 | Invalid using cols function | cols函数使用错误 | 检查并修正 SQL 语句 |
|
||||
| 0x8000268A | Cols function's first param must be a select function that output a single row | cols函数第一个参数应该为选择函数 | 检查并修正 SQL 语句 |
|
||||
| 0x80002689 | Invalid using cols function | cols 函数使用错误 | 检查并修正 SQL 语句 |
|
||||
| 0x8000268A | Cols function's first param must be a select function that output a single row | cols 函数第一个参数应该为选择函数 | 检查并修正 SQL 语句 |
|
||||
| 0x8000268B | Invalid using cols function with multiple output columns | 多列输出的 cols 函数使用错误 | 检查并修正 SQL 语句 |
|
||||
| 0x8000268C | Invalid using alias for cols function | cols 函数输出列重命名错误 | 检查并修正 SQL 语句 |
|
||||
| 0x800026FF | Parser internal error | 解析器内部错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002700 | Planner internal error | 计划期内部错误 | 保留现场和日志,github上报issue |
|
||||
| 0x80002701 | Expect ts equal | JOIN条件校验失败 | 保留现场和日志,github上报issue |
|
||||
| 0x80002702 | Cross join not support | 不支持CROSS JOIN | 检查并修正 SQL 语句 |
|
||||
| 0x80002701 | Expect ts equal | JOIN 条件校验失败 | 保留现场和日志,github上报issue |
|
||||
| 0x80002702 | Cross join not support | 不支持 CROSS JOIN | 检查并修正 SQL 语句 |
|
||||
|
||||
|
||||
## function
|
||||
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
|
||||
| 0x80002800 | Function internal error | 函数参数输入不合理造成的错误,随错误码会返回具体错误描述信息。比如APERCENTILE函数第三个参数指定算法时只能使用字符串"default" | "t-digest", 使用其他输入会报此类错误。或者TO_ISO8601函数第二个参数指定时区时,字符串不符合时区格式规范等。 | 根据具体错误描述信息,调整函数输入。 |
|
||||
| 0x80002801 | Invalid function para number | 函数输入参数个数不正确。函数规定必须要使用n个参数,而用户给定参数个数不为n。比如COUNT(col1, col2)。 | 调整函数输入参数为正确个数。 |
|
||||
| 0x80002802 | Invalid function para type | 函数输入参数类型不正确。函数输入参数要求为数值类型,但是用户所给参数为字符串。比如SUM("abc")。 | 调整函数参数输入为正确类型 |
|
||||
| 0x80002803 | Invalid function para value | 函数输入参数取值不正确。函数输入参数范围不正确。比如SAMPLE函数第二个参数指定采样个数范围为[1, 1000], 如果不在这个范围内会会报错。 | 调整函数参数输入为正确取值。 |
|
||||
| 0x80002804 | Not builtin function | 函数非内置函数。内置函数不在的哈希表中会报错,用户应该很少遇见这个问题,否则是内部内置函数哈希初始化的时候出错或者写坏。 | 客户应该不会遇到,如果遇到,说明程序有bug,咨询开发人员。 |
|
||||
| 0x80002805 | Duplicate timestamps not allowed in function | 函数输入主键列有重复时间戳。对某些依赖时间线顺序函数做超级表查询时,所有子表数据会按照时间戳进行排序后合并为一条时间线进行计算,因此子表合并后的时间戳可能会出现重复,导致某些计算没有意义而报错。涉及到的函数有:CSUM,DERIVATIVE,DIFF,IRATE,MAVG,STATECOUNT,STATEDURATION,TWA | 如果需要对超级表查询并且使用这些依赖时间线顺序函数时,确保子表中不存在重复时间戳数据。 |
|
||||
| 0x80002800 | Function internal error | 函数参数输入不合理造成的错误,随错误码会返回具体错误描述信息。比如 APERCENTILE 函数第三个参数指定算法时只能使用字符串"default" | "t-digest", 使用其他输入会报此类错误。或者 TO_ISO8601 函数第二个参数指定时区时,字符串不符合时区格式规范等。 | 根据具体错误描述信息,调整函数输入。 |
|
||||
| 0x80002801 | Invalid function para number | 函数输入参数个数不正确。函数规定必须要使用n个参数,而用户给定参数个数不为 n。比如 COUNT(col1, col2)。 | 调整函数输入参数为正确个数。 |
|
||||
| 0x80002802 | Invalid function para type | 函数输入参数类型不正确。函数输入参数要求为数值类型,但是用户所给参数为字符串。比如 SUM("abc")。 | 调整函数参数输入为正确类型 |
|
||||
| 0x80002803 | Invalid function para value | 函数输入参数取值不正确。函数输入参数范围不正确。比如 SAMPLE 函数第二个参数指定采样个数范围为 [1, 1000], 如果不在这个范围内会会报错。 | 调整函数参数输入为正确取值。 |
|
||||
| 0x80002804 | Not builtin function | 函数非内置函数。内置函数不在的哈希表中会报错,用户应该很少遇见这个问题,否则是内部内置函数哈希初始化的时候出错或者写坏。 | 客户应该不会遇到,如果遇到,说明程序有 bug,咨询开发人员。 |
|
||||
| 0x80002805 | Duplicate timestamps not allowed in function | 函数输入主键列有重复时间戳。对某些依赖时间线顺序函数做超级表查询时,所有子表数据会按照时间戳进行排序后合并为一条时间线进行计算,因此子表合并后的时间戳可能会出现重复,导致某些计算没有意义而报错。涉及到的函数有:CSUM、DERIVATIVE、DIFF、IRATE、MAVG、STATECOUNT、STATEDURATION、TWA | 如果需要对超级表查询并且使用这些依赖时间线顺序函数时,确保子表中不存在重复时间戳数据。 |
|
||||
|
||||
|
||||
## udf
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | ---------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------- |
|
||||
| 0x80002901 | udf is stopping | dnode退出时,收到udf调用 | 停止执行udf查询 |
|
||||
| 0x80002902 | udf pipe read error | taosd读取udfd pipe,发生错误 | udfd异常退出,1)c udf崩溃 2)udfd崩溃 |
|
||||
| 0x80002903 | udf pipe connect error | taosd建立到udfd的管道连接时,发生错误 | 1)taosd对应的udfd未启动。重启taosd |
|
||||
| 0x80002904 | udf pip not exist | udf建立,调用,拆除三个阶段,两个阶段中间发生连接错误,导致连接消失,后续阶段继续执行 | udfd异常退出,1)c udf崩溃 2)udfd崩溃 |
|
||||
| 0x80002905 | udf load failure | udfd加载udf时错误 | 1)mnode中udf不存在 2)udf 加载出错。查看日志 |
|
||||
| 0x80002906 | udf invalid function input | udf检查输入 | udf函数不接受输入,如输入列类型错误 |
|
||||
| 0x80002907 | udf invalid bufsize | udf聚合函数中间结果大于创建udf中指定的bufsize | 增大bufSize,或者降低中间结果大小 |
|
||||
| 0x80002908 | udf invalid output type | udf输出的类型和创建udf中指定的类型 | 修改udf,或者创建udf的类型,使得结果相同 |
|
||||
| 0x80002909 | udf program language not supported | udf编程语言不支持 | 使用支持的语言,当前支持c,python |
|
||||
| 0x8000290A | udf function execution failure | udf函数执行错误,如返回错误的行数 | 具体查看错误日志 |
|
||||
| 0x80002901 | udf is stopping | dnode 退出时,收到 udf 调用 | 停止执行 udf 查询 |
|
||||
| 0x80002902 | udf pipe read error | taosd 读取 udfd pipe,发生错误 | udfd 异常退出,1. c udf 崩溃 2. udfd 崩溃 |
|
||||
| 0x80002903 | udf pipe connect error | taosd 建立到 udfd 的管道连接时,发生错误 | 1. taosd 对应的 udfd 未启动。重启 taosd |
|
||||
| 0x80002904 | udf pip not exist | udf 建立,调用,拆除三个阶段,两个阶段中间发生连接错误,导致连接消失,后续阶段继续执行 | udfd 异常退出,1. c udf 崩溃 2. udfd 崩溃 |
|
||||
| 0x80002905 | udf load failure | udfd 加载 udf 时错误 | 1.mnode 中 udf 不存在 2. udf 加载出错。查看日志 |
|
||||
| 0x80002906 | udf invalid function input | udf 检查输入 | udf 函数不接受输入,如输入列类型错误 |
|
||||
| 0x80002907 | udf invalid bufsize | udf 聚合函数中间结果大于创建udf中指定的 bufsize | 增大 bufSize,或者降低中间结果大小 |
|
||||
| 0x80002908 | udf invalid output type | udf 输出的类型和创建 udf 中指定的类型 | 修改 udf,或者创建 udf 的类型,使得结果相同 |
|
||||
| 0x80002909 | udf program language not supported | udf 编程语言不支持 | 使用支持的语言,当前支持 c、python |
|
||||
| 0x8000290A | udf function execution failure | udf 函数执行错误,如返回错误的行数 | 具体查看错误日志 |
|
||||
|
||||
|
||||
## sml
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | -------------------------------- | ----------------------------------------------- | --------------------------------------------------------------- |
|
||||
| 0x80003000 | Invalid line protocol type | schemaless接口传入的协议非法 | 检查传入的协议是否为taos.h 中定位的三种 TSDB_SML_PROTOCOL_TYPE |
|
||||
| 0x80003001 | Invalid timestamp precision type | schemaless接口传入的时间精度非法 | 检查传入的协议是否为taos.h 中定位的七种 TSDB_SML_TIMESTAMP_TYPE |
|
||||
| 0x80003002 | Invalid data format | schemaless接口传入的数据格式非法 | 具体查看client端的错误日志提示 |
|
||||
| 0x80003000 | Invalid line protocol type | schemaless 接口传入的协议非法 | 检查传入的协议是否为 taos.h 中定位的三种 TSDB_SML_PROTOCOL_TYPE |
|
||||
| 0x80003001 | Invalid timestamp precision type | schemaless 接口传入的时间精度非法 | 检查传入的协议是否为 taos.h 中定位的七种 TSDB_SML_TIMESTAMP_TYPE |
|
||||
| 0x80003002 | Invalid data format | schemaless 接口传入的数据格式非法 | 具体查看 client 端的错误日志提示 |
|
||||
| 0x80003004 | Not the same type as before | schemaless 数据一批的多行数据里相同列类型不一致 | 检测数据里每行相同列的数据类型是否一致 |
|
||||
| 0x80003005 | Internal error | schemaless 内部逻辑错误,一般不会出现 | 具体查看client端的错误日志提示 |
|
||||
| 0x80003005 | Internal error | schemaless 内部逻辑错误,一般不会出现 | 具体查看 client 端的错误日志提示 |
|
||||
|
||||
|
||||
## sma
|
||||
|
@ -533,7 +533,7 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
| 0x80003102 | Invalid tsma env | TSMA 运行环境异常 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003103 | Invalid tsma state | 流计算下发结果的 vgroup 与创建 TSMA index 的 vgroup 不一致 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003104 | Invalid tsma pointer | 在处理写入流计算下发的结果,消息体为空指针。 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003105 | Invalid tsma parameters | 在处理写入流计算下发的结果,结果数量为0。 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003105 | Invalid tsma parameters | 在处理写入流计算下发的结果,结果数量为 0。 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003113 | Tsma optimization cannot be applied with INTERVAL AUTO offset. | 当前查询条件下使用 INTERVAL AUTO OFFSET 无法启用 tsma 优化。 | 使用 SKIP_TSMA Hint 或者手动指定 INTERVAL OFFSET。 |
|
||||
| 0x80003150 | Invalid rsma env | Rsma 执行环境异常。 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003151 | Invalid rsma state | Rsma 执行状态异常。 | 检查错误日志,联系开发处理 |
|
||||
|
@ -549,7 +549,7 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
## index
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | ---------------- | --------------------------------------------------------------------- | -------------------------- |
|
||||
| 0x80003200 | INDEX 正在重建中 | 1. 写入过快,导致index 的合并线程处理不过来 2. 索引文件损坏,正在重建 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003200 | INDEX 正在重建中 | 1.写入过快,导致 index 的合并线程处理不过来 2.索引文件损坏,正在重建 | 检查错误日志,联系开发处理 |
|
||||
| 0x80003201 | 索引文件损坏 | 文件损坏 | 检查错误日志,联系开发处理 |
|
||||
|
||||
|
||||
|
@ -557,9 +557,11 @@ description: TDengine 服务端的错误码列表和详细说明
|
|||
|
||||
| 错误码 | 错误描述 | 可能的出错场景或者可能的原因 | 建议用户采取的措施 |
|
||||
| ---------- | --------------------- | -------------------------------------------------------------------------------- | ------------------------------ |
|
||||
| 0x80004000 | Invalid message | 订阅到的数据非法,一般不会出现 | 具体查看client端的错误日志提示 |
|
||||
| 0x80004001 | Consumer mismatch | 订阅请求的vnode和重新分配的vnode不一致,一般存在于有新消费者加入相同消费者组里时 | 内部错误,不暴露给用户 |
|
||||
| 0x80004002 | Consumer closed | 消费者已经不存在了 | 查看是否已经close掉了 |
|
||||
| 0x800003E6 | Consumer not exist | Consumer 超时下线 | 重新建 consumer 订阅数据 |
|
||||
| 0x800003EA | Consumer not ready | Consumer 正在平衡中 | 等待 2 秒后重试 |
|
||||
| 0x80004000 | Invalid message | 订阅到的数据非法,一般不会出现 | 具体查看 client 端的错误日志提示 |
|
||||
| 0x80004001 | Consumer mismatch | 订阅请求的 vnode 和重新分配的 vnode 不一致,一般存在于有新消费者加入相同消费者组里时 | 内部错误 |
|
||||
| 0x80004002 | Consumer closed | 消费者已经不存在了 | 查看是否已经 close 掉了 |
|
||||
| 0x80004017 | Invalid status, please subscribe topic first | 数据订阅状态不对 | 没有调用 subscribe,直接 poll 数据 |
|
||||
| 0x80004100 | Stream task not exist | 流计算任务不存在 | 具体查看server端的错误日志 |
|
||||
| 0x80004100 | Stream task not exist | 流计算任务不存在 | 具体查看 server 端的错误日志 |
|
||||
|
||||
|
|
|
@ -8,57 +8,51 @@ toc_max_heading_level: 4
|
|||
|
||||
## 车联网面临的挑战
|
||||
|
||||
在国家政策的有力引导下,车联网行业正迎来前所未有的发展机遇。早在2016年,我国便推出了GB/T 32960标准规范,以推动车联网应用的快速发展。自2017年起,一系列车联网相关政策相继出台,旨在促进网联化、智能化、共享化和电动化的实现。在这一进程中,车联网车与一切技术扮演着举足轻重的角色,其收集的信息中时序数据占据了绝大多数。随着联网汽车数量的持续增长,如何高效地上传、存储和处理海量数据,以及如何有效应对乱序数据的挑战,进行高效的查询和分析,已成为业界亟须解决的关键问题。
|
||||
在国家政策的有力引导下,车联网行业正迎来前所未有的发展机遇。早在 2016 年,我国便推出了 GB/T 32960 标准规范,以推动车联网应用的快速发展。自 2017 年起,一系列车联网相关政策相继出台,旨在促进网联化、智能化、共享化和电动化的实现。在这一进程中,车联网车与一切技术扮演着举足轻重的角色,其收集的信息中时序数据占据了绝大多数。随着联网汽车数量的持续增长,如何高效地上传、存储和处理海量数据,以及如何有效应对乱序数据的挑战,进行高效的查询和分析,已成为业界亟须解决的关键问题。
|
||||
|
||||
- 海量数据采集:如今,无论是小型客车还是受监管的货车,普遍配备了T-Box或其他OBD(On-Board Diagnostics,车载自动诊断系统)车载终端设备,用于实时采集车辆的运行参数,并将这些数据及时传输至云端数据中心。以某品牌汽车为例,每辆车每秒可采集140个高频测点数据,每30s采集280个低频测点数据。在日常运营中,80万辆在线车辆每天产生的数据量高达4.5TB,这些数据最终汇入时序数据库,形成了庞大的数据采集点网络。
|
||||
- 海量数据采集:如今,无论是小型客车还是受监管的货车,普遍配备了 T-Box 或其他 OBD(On-Board Diagnostics,车载自动诊断系统)车载终端设备,用于实时采集车辆的运行参数,并将这些数据及时传输至云端数据中心。以某品牌汽车为例,每辆车每秒可采集 140 个高频测点数据,每 30s 采集 280 个低频测点数据。在日常运营中,80 万辆在线车辆每天产生的数据量高达 4.5TB,这些数据最终汇入时序数据库,形成了庞大的数据采集点网络。
|
||||
- 海量数据存储:鉴于数据采集的规模之大,相应的硬件资源需求自然引起了汽车制造商的高度关注。因此,在选择数据存储方案时,必须考虑高压缩率,最大限度地减少存储空间的占用。同时,应实现冷热数据的自动分离,确保热数据被自动存储到高性能的硬盘上,而冷数据则被转移到较低性能的硬盘上。这样既能保障查询性能不受影响,又能有效降低存储成本,实现资源的合理利用。
|
||||
- 支持乱序写入整理:在信号不佳或无信号的区域,数据通常会在本地缓存。一旦网络通信恢复正常,依照GB/T 32960的规定,数据将以交替发送的方式上传至数据中心,确保实时与离线数据的同步传输。在消息分发至不同区域后,消费组的消费顺序也会导致数据的乱序写入。这种乱序写入若频繁发生,将导致大量存储碎片的产生,进而降低时序数据库的存储效率和查询速度。
|
||||
- 强大的查询和分析能力:系统应能支持使用标准SQL进行状态、时长、位置等关键指标的统计分析。此外,还应具备轨迹历史回放、双轨合验、预警报警等实用功能,以降低学习和分析的难度。对于更复杂的分析需求,系统须支持UDF,通过编写高级编程语言生成的库文件并加载至集群中,以弥补时序数据库内置函数的局限性。系统应查询操作简便且结果实时性强,以便为业务决策提供有力且及时的数据支持。
|
||||
- 支持乱序写入整理:在信号不佳或无信号的区域,数据通常会在本地缓存。一旦网络通信恢复正常,依照 GB/T 32960 的规定,数据将以交替发送的方式上传至数据中心,确保实时与离线数据的同步传输。在消息分发至不同区域后,消费组的消费顺序也会导致数据的乱序写入。这种乱序写入若频繁发生,将导致大量存储碎片的产生,进而降低时序数据库的存储效率和查询速度。
|
||||
- 强大的查询和分析能力:系统应能支持使用标准 SQL 进行状态、时长、位置等关键指标的统计分析。此外,还应具备轨迹历史回放、双轨合验、预警报警等实用功能,以降低学习和分析的难度。对于更复杂的分析需求,系统须支持 UDF,通过编写高级编程语言生成的库文件并加载至集群中,以弥补时序数据库内置函数的局限性。系统应查询操作简便且结果实时性强,以便为业务决策提供有力且及时的数据支持。
|
||||
|
||||
## TDengine在车联网中的核心价值
|
||||
|
||||
在面对亿万级别的点位信息时,任何微小的数据处理逻辑错误或冗余都可能导致性能瓶颈。得益于全球社区爱好者的共同努力、超过53万个的装机实例部署,以及在极端条件下的严格验证,TDengine在功能和性能方面均达到顶尖水平。在车联网领域,TDengine的核心价值体现在以下几个方面。
|
||||
在面对亿万级别的点位信息时,任何微小的数据处理逻辑错误或冗余都可能导致性能瓶颈。得益于全球社区爱好者的共同努力、超过 53 万个的装机实例部署,以及在极端条件下的严格验证,TDengine 在功能和性能方面均达到顶尖水平。在车联网领域,TDengine 的核心价值体现在以下几个方面。
|
||||
|
||||
- 便于采集:作为物联网的一个分支,车联网的技术特点与之一致。TDengine配备了可视化采集界面,用户无须编写代码即可轻松将Kafka、MQTT等通用消息中间件中
|
||||
的数据导入数据库。此外,提供的可视化性能指标看板大大简化了数据接入和管理
|
||||
的工作流程。
|
||||
- 数据存储:车联网数据具有高度的相关性,例如特定车型的配置信息或同一车辆上不同点位的状态数据。TDengine的设计理念完美契合车联网的需求,采用“一车一表”的模式,简化了数据存储管理的复杂性。结合云原生架构、冷热数据分离、列式存储以及动态扩容(包括横向、纵向扩容和动态添加存储空间)等技术,TDengine在数据存储的性能和成本控制方面表现出色。
|
||||
- 查询分析:TDengine作为一个开放且简洁的时序大数据平台,提供了丰富的API,兼容各种分析工具、编程语言和BI系统,如Matlab、R、永洪BI等。TDengine 主要采用SQL,易于学习和使用,支持状态、计数、时间、事件及会话窗口等多种分析模式,并内置了70多个基础算子,足以应对日常的分析需求。对于更专业的算法分析,用户可通过C或Python语言开发UDF,并将其集成到TDengine中。
|
||||
- 便于采集:作为物联网的一个分支,车联网的技术特点与之一致。TDengine 配备了可视化采集界面,用户无须编写代码即可轻松将 Kafka、MQTT 等通用消息中间件中的数据导入数据库。此外,提供的可视化性能指标看板大大简化了数据接入和管理的工作流程。
|
||||
- 数据存储:车联网数据具有高度的相关性,例如特定车型的配置信息或同一车辆上不同点位的状态数据。TDengine 的设计理念完美契合车联网的需求,采用“一车一表”的模式,简化了数据存储管理的复杂性。结合云原生架构、冷热数据分离、列式存储以及动态扩容(包括横向、纵向扩容和动态添加存储空间)等技术,TDengine 在数据存储的性能和成本控制方面表现出色。
|
||||
- 查询分析:TDengine 作为一个开放且简洁的时序大数据平台,提供了丰富的 API,兼容各种分析工具、编程语言和 BI 系统,如 Matlab、R、永洪 BI 等。TDengine 主要采用 SQL,易于学习和使用,支持状态、计数、时间、事件及会话窗口等多种分析模式,并内置了 70 多个基础算子,足以应对日常的分析需求。对于更专业的算法分析,用户可通过 C 或 Python 语言开发 UDF,并将其集成到 TDengine 中。
|
||||
|
||||
## TDengine在车联网中的应用
|
||||
|
||||
车联网场景是时序数据应用的典型代表,而TDengine正是处理这类海量时序数据的理想选择。通过整合车载数据,车联网系统能够实现对汽车各个零部件健康状况的监控、用户驾驶行为的追踪、车载系统的安全分析、合规性检查以及车载网络质量的监测。此外,利用TDengine提供的geometry数据类型及其相关函数,车联网系统能够轻松且高效地执行车辆轨迹监管、历史轨迹回放、最新位置定位等关键功能。
|
||||
车联网场景是时序数据应用的典型代表,而 TDengine 正是处理这类海量时序数据的理想选择。通过整合车载数据,车联网系统能够实现对汽车各个零部件健康状况的监控、用户驾驶行为的追踪、车载系统的安全分析、合规性检查以及车载网络质量的监测。此外,利用 TDengine 提供的 geometry 数据类型及其相关函数,车联网系统能够轻松且高效地执行车辆轨迹监管、历史轨迹回放、最新位置定位等关键功能。
|
||||
|
||||
### TSP 车联网
|
||||
|
||||
汽车制造商通过车载T-Box终端收集车辆的关键行驶数据,包括行驶速度、行驶方向、电门开度、制动踏板开度、挡位、电机转速以及电池包信息等。这些数据通过MQTT协议汇聚至TDengine进行存储,从而满足车辆历史轨迹的回放需求以及对车辆实时状态的监控。TSP车联网架构如下图所示。
|
||||
汽车制造商通过车载 T-Box 终端收集车辆的关键行驶数据,包括行驶速度、行驶方向、电门开度、制动踏板开度、挡位、电机转速以及电池包信息等。这些数据通过 MQTT 协议汇聚至 TDengine 进行存储,从而满足车辆历史轨迹的回放需求以及对车辆实时状态的监控。TSP 车联网架构如下图所示。
|
||||
|
||||
|
||||

|
||||
|
||||
TDengine能够无缝地从外部消息队列(如MQTT、Kafka)中采集并过滤数据,用户可通过直观的可视化界面来管理和配置采集任务,实现无须编写代码即可接入外部数据源。此外,TDengine还支持对接入消息的解析、过滤和映射操作,并提供数据采集任务状态的实时监控功能,从而极大地提高数据接入的工作效率。
|
||||
TDengine 能够无缝地从外部消息队列(如 MQTT、Kafka)中采集并过滤数据,用户可通过直观的可视化界面来管理和配置采集任务,实现无须编写代码即可接入外部数据源。此外,TDengine 还支持对接入消息的解析、过滤和映射操作,并提供数据采集任务状态的实时监控功能,从而极大地提高数据接入的工作效率。
|
||||
|
||||
在本案例中,系统采用了“一车一表”的建模策略,确保每张子表中的数据都能按照时间顺序进行追加操作。设备表与表之间保持相对独立,并且数据是连续写入的,这一设计显著提高了数据的写入效率。
|
||||
- 海量高频数据采集上报存储:为了应对海量且高频的数据采集与上报需求,系统采用多节点的三副本或双副本集群架构。每个核心节点能够高效管理并存储高达100万张子表。通过分布式部署、构建高可用集群以及实施负载均衡技术,系统确保了数据采集存储在性能、可用性和可靠性方面的卓越表现。
|
||||
- 采用多级存储方式:系统支持冷热数据分离的策略,将热数据存储于高性能的硬盘上,而冷数据则可根据配置迁移至S3对象存储服务中,实现存储方式的灵活性。鉴于数据量的庞大,多级存储不仅满足了日常业务需求,还有效降低了存储成本。通过独特的数据存储结构设计,实现了行转列和连续存储,无损压缩率轻松达到10%以内,极大地节约了数据存储空间。
|
||||
- 预统计和缓存:在数据写入存储空间的过程中,系统已经计算并附带了max、min、avg、count等预统计结果。这些预计算结果为大多数统计分析提供了基础,使得在数据量庞大时,能够通过统计函数迅速筛选出所需信息。在处理海量数据的并发写入场景时,系统展现出高效的统计报表生成能力和卓越的SQL查询效率。此外,系统内置的实时缓存功能能够实现毫秒级的实时数据反馈。
|
||||
- 海量高频数据采集上报存储:为了应对海量且高频的数据采集与上报需求,系统采用多节点的三副本或双副本集群架构。每个核心节点能够高效管理并存储高达 100 万张子表。通过分布式部署、构建高可用集群以及实施负载均衡技术,系统确保了数据采集存储在性能、可用性和可靠性方面的卓越表现。
|
||||
- 采用多级存储方式:系统支持冷热数据分离的策略,将热数据存储于高性能的硬盘上,而冷数据则可根据配置迁移至 S3 对象存储服务中,实现存储方式的灵活性。鉴于数据量的庞大,多级存储不仅满足了日常业务需求,还有效降低了存储成本。通过独特的数据存储结构设计,实现了行转列和连续存储,无损压缩率轻松达到 10% 以内,极大地节约了数据存储空间。
|
||||
- 预统计和缓存:在数据写入存储空间的过程中,系统已经计算并附带了 max、min、avg、count 等预统计结果。这些预计算结果为大多数统计分析提供了基础,使得在数据量庞大时,能够通过统计函数迅速筛选出所需信息。在处理海量数据的并发写入场景时,系统展现出高效的统计报表生成能力和卓越的 SQL 查询效率。此外,系统内置的实时缓存功能能够实现毫秒级的实时数据反馈。
|
||||
- 在线异步方式数据整理:此过程不会干扰正常的存储和查询服务,而是对乱序数据和因数据删除产生的存储碎片进行整理,有效释放存储空间。
|
||||
- 系统部署满足分布式、高可用以及负载均衡的需求,其性能、可靠性和稳定性已经过充分验证。
|
||||
- 极简大数据平台:与传统大数据平台相比,系统将消息队列、流计算、实时缓存、ETL工具以及数据库本体集成于一体,构建了极为简洁的架构,同时增强了实时性,大幅减少了验证和维护过程中的工作量。
|
||||
- 极简大数据平台:与传统大数据平台相比,系统将消息队列、流计算、实时缓存、ETL 工具以及数据库本体集成于一体,构建了极为简洁的架构,同时增强了实时性,大幅减少了验证和维护过程中的工作量。
|
||||
|
||||
### 物流车联网
|
||||
|
||||
物流车辆运营商借助车辆的轨迹监管、异常预警以及历史轨迹回放功能,实现对运营车辆的在线监控、精准轨迹追踪、深入大数据分析及可视化应用等多方面目标。
|
||||
|
||||
在这一业务场景中,系统数据建模遵循“一车一表”的原则进行设计。GIS (Geographic Information System,地理信息系统)网关负责收集并汇聚数万台车辆上报的车辆定位和行驶数据。随后,下游服务解析这些报文并将数据推送至消息队列。通过TDengine的数据接入组件,数据经过加载、过滤和转换等一系列处理步骤后,最终存储于TDengine中。这为下游应用程序提供了实时的车辆位置监控和历史轨迹回放等查询分析服务。物流车联网系统的架构如下图所示:
|
||||
在这一业务场景中,系统数据建模遵循“一车一表”的原则进行设计。GIS(Geographic Information System,地理信息系统)网关负责收集并汇聚数万台车辆上报的车辆定位和行驶数据。随后,下游服务解析这些报文并将数据推送至消息队列。通过TDengine的数据接入组件,数据经过加载、过滤和转换等一系列处理步骤后,最终存储于 TDengine 中。这为下游应用程序提供了实时的车辆位置监控和历史轨迹回放等查询分析服务。物流车联网系统的架构如下图所示:
|
||||
|
||||

|
||||
|
||||
方案特点如下。
|
||||
- 高性能:该项目服务于一万辆车,数据量呈现快速增长态势,日均写入记录高达约10亿条。项目对聚合查询的高效性和存储压缩性能进行了严格的验证,无损压缩率可达4%。这证明了TDengine在处理大规模数据时的卓越性能。
|
||||
- 乱序治理:尽管消息队列的使用难以避免乱序问题的出现,尤其是在离线数据补传的场景中,乱序数据往往表现为时间戳早于当前车辆存储记录的时间戳。这种乱序写入会导致大量存储碎片的产生,严重时会影响数据库的性能。TDengine巧妙地解决了这一行业难题,支持在线整理乱序写入,确保数据库性能不受影响。同时,对于异常数据段的删除,也可以通过在线整理实现真正的数据存储空间释放,而不仅仅是索引屏蔽。
|
||||
- 数据应用:鉴于车辆运营涉及食品安全的特殊性,实时监控当前车辆位置信息显
|
||||
得尤为重要。TDengine 具备缓存实时数据的功能,无论数据库中已存储多少数据,
|
||||
仍能保持稳定的性能,毫秒级响应最新数据请求,充分发挥时序数据库的实时特
|
||||
性。业务中还需要进行历史轨迹回放、行驶里程分析、时间分段分析等多项操作,
|
||||
TDengine 的强大性能和多功能性为业务分析提供了无限可能。
|
||||
- 高性能:该项目服务于一万辆车,数据量呈现快速增长态势,日均写入记录高达约 10 亿条。项目对聚合查询的高效性和存储压缩性能进行了严格的验证,无损压缩率可达 4%。这证明了 TDengine 在处理大规模数据时的卓越性能。
|
||||
- 乱序治理:尽管消息队列的使用难以避免乱序问题的出现,尤其是在离线数据补传的场景中,乱序数据往往表现为时间戳早于当前车辆存储记录的时间戳。这种乱序写入会导致大量存储碎片的产生,严重时会影响数据库的性能。TDengine 巧妙地解决了这一行业难题,支持在线整理乱序写入,确保数据库性能不受影响。同时,对于异常数据段的删除,也可以通过在线整理实现真正的数据存储空间释放,而不仅仅是索引屏蔽。
|
||||
- 数据应用:鉴于车辆运营涉及食品安全的特殊性,实时监控当前车辆位置信息显得尤为重要。TDengine 具备缓存实时数据的功能,无论数据库中已存储多少数据,仍能保持稳定的性能,毫秒级响应最新数据请求,充分发挥时序数据库的实时特性。业务中还需要进行历史轨迹回放、行驶里程分析、时间分段分析等多项操作,TDengine 的强大性能和多功能性为业务分析提供了无限可能。
|
|
@ -6,11 +6,11 @@ toc_max_heading_level: 4
|
|||
|
||||
在当前可再生能源迅速发展的浪潮中,分布式光伏和可再生能源的装机容量已经达到相当可观的规模。尽管新能源的发展得到政策的鼎力扶持,但其并网后对电网的运行调度、供电可靠性以及系统的安全稳定带来诸多新挑战。
|
||||
|
||||
分布式光伏,即分布式光伏发电系统,是指将光伏电池板安装在城市的建筑物屋顶或墙壁上,甚至农田、山坡等非建筑用地上,利用采集到的太阳能为城市供电的一种绿色能源解决方案。其显著特点是电力产生地与用电地重合,可以直接向用户提供电力,或者通过配电变压器并入电网。这种能源系统不仅环保,而且高效,能有效降低长距离输电的损耗,减少能源使用成本。分布式光伏电站主要由光伏电池板、组串式逆变器、配电设备和监控系统4部分组成。光伏电池板负责将太阳能转换为直流电,组串式逆变器进一步将直流电转换为交流电,供用户使用或并入电网。电力公司普遍采用HPLC (High-speed Power Line Communication,高速电力线通信)方案对分布式光伏接入的电能表进行数据采集,以实现1分钟、15分钟级别的运行数据采集能力。
|
||||
分布式光伏,即分布式光伏发电系统,是指将光伏电池板安装在城市的建筑物屋顶或墙壁上,甚至农田、山坡等非建筑用地上,利用采集到的太阳能为城市供电的一种绿色能源解决方案。其显著特点是电力产生地与用电地重合,可以直接向用户提供电力,或者通过配电变压器并入电网。这种能源系统不仅环保,而且高效,能有效降低长距离输电的损耗,减少能源使用成本。分布式光伏电站主要由光伏电池板、组串式逆变器、配电设备和监控系统 4 部分组成。光伏电池板负责将太阳能转换为直流电,组串式逆变器进一步将直流电转换为交流电,供用户使用或并入电网。电力公司普遍采用HPLC (High-speed Power Line Communication,高速电力线通信)方案对分布式光伏接入的电能表进行数据采集,以实现 1 分钟、15 分钟级别的运行数据采集能力。
|
||||
|
||||
储能系统以其独特的能力,能够平滑新能源输出的不稳定性,实现削峰填谷,从而有望显著降低微电网的运行成本。更为重要的是,从长远角度考虑,引入储能系统有助于减轻对主电网的依赖,进一步优化整体的能源结构。
|
||||
|
||||
新能源的波动性无疑加剧了电网供电的不确定性,这使得储能系统成为确保电网稳定性和可靠性的关键。针对这方面,《2030年前碳达峰行动方案》明确强调了储能系统的重要性,并支持分布式新能源与储能系统的融合发展,旨在加速储能技术的示范应用和推广普及。
|
||||
新能源的波动性无疑加剧了电网供电的不确定性,这使得储能系统成为确保电网稳定性和可靠性的关键。针对这方面,《2030 年前碳达峰行动方案》明确强调了储能系统的重要性,并支持分布式新能源与储能系统的融合发展,旨在加速储能技术的示范应用和推广普及。
|
||||
|
||||
## 新能源面临的挑战
|
||||
|
||||
|
@ -18,70 +18,67 @@ toc_max_heading_level: 4
|
|||
|
||||
储能系统的核心组件是电芯,对其实时工作参数(如电流、电压、温度、内阻)的监控对于保障储能系统的安全和可靠运行至关重要。如何有效地存储和分析这些海量的测点和数据,已成为储能领域不得不正视的技术难题。这些难题主要体现在如下几个方面。
|
||||
- 测点量大:分布式光伏组件众多,大型储能系统中电芯数量庞大,需要监测的测点数从数十万到数千万不等。加之较高的采集频率,每天产生的海量监测数据需要进行长期持久化存储。
|
||||
- 数据接入难:电网调度中心须实时监控分布式光伏电站和储能系统的运行状况,但由于分布式光伏电站目前主要通过配网侧接入电网,数据接入过程面临挑战。
|
||||
另外,由于营销系统与调度中心的信息化水平存在差异,数据接入过程中存在客观难题:数据提取规则复杂,测点数量庞大,传统的数据采集方案资源消耗大。
|
||||
- 数据分发难:分布式光伏电站的运行数据一旦接入省级调度中心,就需要迅速分发至各地市的生产区以驱动后续业务。如何实现快速且高效的数据分发,是客户
|
||||
需要解决的一个棘手问题。
|
||||
- 数据接入难:电网调度中心须实时监控分布式光伏电站和储能系统的运行状况,但由于分布式光伏电站目前主要通过配网侧接入电网,数据接入过程面临挑战。另外,由于营销系统与调度中心的信息化水平存在差异,数据接入过程中存在客观难题:数据提取规则复杂,测点数量庞大,传统的数据采集方案资源消耗大。
|
||||
- 数据分发难:分布式光伏电站的运行数据一旦接入省级调度中心,就需要迅速分发至各地市的生产区以驱动后续业务。如何实现快速且高效的数据分发,是客户需要解决的一个棘手问题。
|
||||
- 聚合分析难:分布式光伏电站的运行数据须根据电站在电网拓扑中的具体隶属关系(如电站隶属于某台配电变压器、馈线、主网变压器)进行多维度的聚合分析。现有技术方案在提供高效聚合分析手段方面存在不足,如性能低下、耗时过长等问题尤为突出。
|
||||
|
||||
## TDengine在新能源中的核心价值
|
||||
|
||||
在新能源领域,特别是分布式光伏电站和储能系统的复杂任务与数据处理需求面前,TDengine的时序数据库技术扮演了不可或缺的角色。TDengine的核心优势体现在以下几个方面。
|
||||
在新能源领域,特别是分布式光伏电站和储能系统的复杂任务与数据处理需求面前,TDengine 的时序数据库技术扮演了不可或缺的角色。TDengine 的核心优势体现在以下几个方面。
|
||||
|
||||
- 支持海量测点:TDengine能够支持高达10亿个时间线,充分满足分布式光伏电站和储能系统的数据处理需求。
|
||||
- 高性能:面对千万级测点的分钟级数据采集场景,调度业务对时序数据库的写入性能和低延迟有着严苛的要求。TDengine凭借“一个数据采集点一张表”的创新设计理念,实现了卓越的写入性能,完全契合业务需求。
|
||||
- 最新状态数据快速查询:在千万级测点数据写入后,调度业务需要时序数据库能够迅速查询各设备的最新状态数据,以驱动后续业务逻辑。TDengine通过超级表和内置的高速读缓存设计,使用户能够高效查询光伏设备和储能电芯的最新运行数据,使运维人员能够实时获取并监控设备状态,从而提高运维效率。
|
||||
- 数据订阅与分发:针对需要实时数据分发的业务场景,TDengine内置的消息队列功能从机制上解决了大量数据即时分发的难题,简化了整个系统架构的复
|
||||
杂性。
|
||||
- 开放的生态:TDengine易于与其他系统集成,兼容多种大数据框架,支持数据的整合与分析,为开发者提供了一个灵活的生态平台。
|
||||
- 支持海量测点:TDengine 能够支持高达 10 亿个时间线,充分满足分布式光伏电站和储能系统的数据处理需求。
|
||||
- 高性能:面对千万级测点的分钟级数据采集场景,调度业务对时序数据库的写入性能和低延迟有着严苛的要求。TDengine 凭借“一个数据采集点一张表”的创新设计理念,实现了卓越的写入性能,完全契合业务需求。
|
||||
- 最新状态数据快速查询:在千万级测点数据写入后,调度业务需要时序数据库能够迅速查询各设备的最新状态数据,以驱动后续业务逻辑。TDengine 通过超级表和内置的高速读缓存设计,使用户能够高效查询光伏设备和储能电芯的最新运行数据,使运维人员能够实时获取并监控设备状态,从而提高运维效率。
|
||||
- 数据订阅与分发:针对需要实时数据分发的业务场景,TDengine 内置的消息队列功能从机制上解决了大量数据即时分发的难题,简化了整个系统架构的复杂性。
|
||||
- 开放的生态:TDengine 易于与其他系统集成,兼容多种大数据框架,支持数据的整合与分析,为开发者提供了一个灵活的生态平台。
|
||||
|
||||
## TDengine 在新能源中的应用
|
||||
|
||||
### 营销侧分布式光伏电站运行数据接入
|
||||
|
||||
分布式光伏电站的运行数据通常须从外部营销系统接入,而该营销系统所提供的数据接口采用的是Kafka,如下图所示:
|
||||
分布式光伏电站的运行数据通常须从外部营销系统接入,而该营销系统所提供的数据接口采用的是 Kafka,如下图所示:
|
||||
|
||||

|
||||
|
||||
针对外部数据源的接入场景,TDengine Enterprise提供了专业的taosX数据接入组件。用户无须编写任何代码,只须通过配置参数即可迅速接入营销侧Kafka消息队列中的分布式光伏电站采集数据,实现提取解析、过滤、数据映射等操作,并将处理后的数据写入TDengine。这种方法不再依赖第三方ETL工具,如下图所示:
|
||||
针对外部数据源的接入场景,TDengine Enterprise 提供了专业的 taosX 数据接入组件。用户无须编写任何代码,只须通过配置参数即可迅速接入营销侧 Kafka 消息队列中的分布式光伏电站采集数据,实现提取解析、过滤、数据映射等操作,并将处理后的数据写入 TDengine。这种方法不再依赖第三方 ETL 工具,如下图所示:
|
||||
|
||||

|
||||
|
||||
taosX是一个高度灵活的数据接入工具,能够适应多样化的数据源格式。它配备了全面的过滤选项和丰富的数据映射功能,这些特性大幅缩短了从外部系统收集并整合数据的开发周期。在维持低资源消耗的同时,taosX保证了高效的数据接入能力。
|
||||
taosX 是一个高度灵活的数据接入工具,能够适应多样化的数据源格式。它配备了全面的过滤选项和丰富的数据映射功能,这些特性大幅缩短了从外部系统收集并整合数据的开发周期。在维持低资源消耗的同时,taosX 保证了高效的数据接入能力。
|
||||
|
||||
与市面上常见的开源ETL工具相比,taosX在接入Kafka数据时能够显著减少服务器CPU资源的占用。这不仅意味着企业能够在更短的时间内完成数据接入任务,还能有效降低硬件成本,为企业的发展提供强有力的支持。
|
||||
与市面上常见的开源 ETL 工具相比,taosX 在接入 Kafka 数据时能够显著减少服务器 CPU 资源的占用。这不仅意味着企业能够在更短的时间内完成数据接入任务,还能有效降低硬件成本,为企业的发展提供强有力的支持。
|
||||
|
||||
### 数据即时分发至各地市
|
||||
|
||||
针对汇总至省级调度中心的分布式光伏电站运行数据,用户须将这些数据及时分发至各地市的调度中心,以便推动下游业务的顺利进行。
|
||||
|
||||
利用TDengine内置的结构化消息队列功能,用户可以迅速构建数据分发子系统。通过订阅省级调度中心TDengine集群中的分布式光伏电站瞬时功率数据,并根据各地市进行分类,实时将数据分发至对应地市的TDengine。各地市调度中心根据收到的数据,进一步驱动后续业务,如本地电网负载调控等。分布式光伏电站运行数据的分发架构如下图所示:
|
||||
利用 TDengine 内置的结构化消息队列功能,用户可以迅速构建数据分发子系统。通过订阅省级调度中心 TDengine 集群中的分布式光伏电站瞬时功率数据,并根据各地市进行分类,实时将数据分发至对应地市的 TDengine。各地市调度中心根据收到的数据,进一步驱动后续业务,如本地电网负载调控等。分布式光伏电站运行数据的分发架构如下图所示:
|
||||
|
||||

|
||||
|
||||
### 分类聚合计算瞬时发电功率
|
||||
|
||||
分布式光伏电站通过配电变压器并入配电网,并逐级向上汇聚至配网的10kV线端和110kV主网变压器。各级配电变压器、10kV线端、馈线以及110kV主网变压器所汇集的分布式光伏电站瞬时发电功率,对电网的安全稳定运行具有决定性的影响。
|
||||
分布式光伏电站通过配电变压器并入配电网,并逐级向上汇聚至配网的 10kV 线端和 110kV 主网变压器。各级配电变压器、10kV 线端、馈线以及 110kV 主网变压器所汇集的分布式光伏电站瞬时发电功率,对电网的安全稳定运行具有决定性的影响。
|
||||
|
||||
在一个省份中,分布式光伏电站和配电变压器的数量庞大,可达百万级别。每个分布式光伏电站和配电变压器通常设有8至10个测点,涵盖三相电流电压、功率、功率因数、示值等指标,总测点数往往超过千万个。在这种大规模的测点环境下,实现快速聚合计算成为一个关键挑战。
|
||||
在一个省份中,分布式光伏电站和配电变压器的数量庞大,可达百万级别。每个分布式光伏电站和配电变压器通常设有 8 至 10 个测点,涵盖三相电流电压、功率、功率因数、示值等指标,总测点数往往超过千万个。在这种大规模的测点环境下,实现快速聚合计算成为一个关键挑战。
|
||||
|
||||
TDengine的标签设计允许用户从超级表中迅速分类和检索数据,这一点对于基于分布式光伏电站产生的大量时序数据进行快速聚合计算尤为重要。在TDengine中,通常会分别为分布式光伏电站发电功率和配电变压器的瞬时功率创建超级表,每个分布式光伏电站和配电变压器分别对应一张子表。通过TDengine的静态标签,可以存储分布式光伏电站发电功率的相关分类信息,如地区、所属配电变压器、所属馈线、所属10kV单端线端、所属110kV主网变压器等。
|
||||
TDengine 的标签设计允许用户从超级表中迅速分类和检索数据,这一点对于基于分布式光伏电站产生的大量时序数据进行快速聚合计算尤为重要。在 TDengine中,通常会分别为分布式光伏电站发电功率和配电变压器的瞬时功率创建超级表,每个分布式光伏电站和配电变压器分别对应一张子表。通过 TDengine 的静态标签,可以存储分布式光伏电站发电功率的相关分类信息,如地区、所属配电变压器、所属馈线、所属 10kV 单端线端、所属 110kV 主网变压器等。
|
||||
|
||||
用户可根据多样化的标签,如地区、所属配电变压器、所属馈线、所属主网变压器等,对分布式光伏电站执行指定条件的聚合查询,实现快速求解。例如,用户可以迅速查询特定地区内所有配电变压器的下辖分布式光伏电站瞬时发电功率,或根据业务需求,针对不同级别的电网变电站(220kV、110kV、35kV、10kV)进行下辖分布式光伏电站瞬时功率的条件聚合查询。这为电网调度和设备故障判断提供了高效的数据支持手段。此类条件聚合查询的结果集可能包含数百至数十万条记录。
|
||||
|
||||
在TDengine中,用户可以基于标签进行聚合分析,无须编写代码进行表关联和数据处理,仅须通过SQL查询超级表即可直接获得结果,性能表现卓越,通常能在几秒内返回查询结果。示例SQL如下。
|
||||
在TDengine中,用户可以基于标签进行聚合分析,无须编写代码进行表关联和数据处理,仅须通过 SQL 查询超级表即可直接获得结果,性能表现卓越,通常能在几秒内返回查询结果。示例 SQL 如下。
|
||||
```sql
|
||||
select sum(val) from dpv_power_1m where ts > now-1m group by dtr;
|
||||
```
|
||||
|
||||
借助TDengine的高效聚合特性,用户可以高效、及时地获得分布式光伏电站实时运行状态,为运行决策提供可靠的数据支持。
|
||||
借助 TDengine 的高效聚合特性,用户可以高效、及时地获得分布式光伏电站实时运行状态,为运行决策提供可靠的数据支持。
|
||||
|
||||
### 实时数据监测
|
||||
|
||||
在某储能项目中,TDengine被应用于实时监控电池的充放电过程,以保障电池的安全运行。所有电芯的充放电数据都被精确记录,得益于TDengine的强大分析能力,用户显著提高了数据处理和分析的效率。
|
||||
在某储能项目中,TDengine 被应用于实时监控电池的充放电过程,以保障电池的安全运行。所有电芯的充放电数据都被精确记录,得益于 TDengine 的强大分析能力,用户显著提高了数据处理和分析的效率。
|
||||
|
||||
### 智慧运维系统
|
||||
|
||||
在某储能智慧运维系统中,用户原有的解决方案受到站端系统在内存、CPU以及读写性能等硬件资源上的限制,这导致项目进度一再推迟。TDengine凭借卓越的架构设计和工程实现,以较低的资源消耗完美满足了项目需求,解决了客户的痛点问题,并迅速支持业务系统的顺利部署。
|
||||
在某储能智慧运维系统中,用户原有的解决方案受到站端系统在内存、CPU 以及读写性能等硬件资源上的限制,这导致项目进度一再推迟。TDengine 凭借卓越的架构设计和工程实现,以较低的资源消耗完美满足了项目需求,解决了客户的痛点问题,并迅速支持业务系统的顺利部署。
|
||||
|
||||
TDengine的加入为储能设备注入了信息感知、控制协调以及远程运维的能力,确保了电站和设备运行的安全性与可靠性。
|
||||
TDengine 的加入为储能设备注入了信息感知、控制协调以及远程运维的能力,确保了电站和设备运行的安全性与可靠性。
|
|
@ -28,7 +28,7 @@ toc_max_heading_level: 4
|
|||
|
||||
## TDengine在智慧油田中的应用
|
||||
|
||||
在一项致力于提升大型油田生产管理水平的技术方案中,客户设定了实现多个关键领域技术集成的目标。这些领域包括但不限于如下这些
|
||||
在一项致力于提升大型油田生产管理水平的技术方案中,客户设定了实现多个关键领域技术集成的目标。这些领域包括但不限于如下这些。
|
||||
- 自动化采集与控制:在生产现场构建先进的自动化系统,以实现数据的实时采集和精确控制,提升生产过程的自动化水平。
|
||||
- 生产视频系统:整合高效的视频监控系统,对生产过程进行全面监控,确保作业安全,并为管理层提供实时、直观的决策支持。
|
||||
- 工业物联网:运用物联网技术,将各种传感器和设备无缝连接,实现数据的远程采集与分析,提高油田运营的透明度和智能化程度。
|
||||
|
@ -36,7 +36,7 @@ toc_max_heading_level: 4
|
|||
- 智能化生产管控应用:研发智能化的生产管控应用,利用大数据分析和人工智能技术,提高生产效率,优化资源配置,加强生产管理。
|
||||
- 信息化采集标准建设:制定统一的信息化采集标准和规范,确保数据的一致性、准确性和可管理性,为油田的数字化和智能化转型奠定坚实基础。
|
||||
|
||||
以往的技术解决方案中,客户普遍采用常规的实时数据库来搜集现场数据。然而,这些传统软件在数据分析功能上显得力不从心。鉴于此,用户不得不将数据迁移到以Oracle为代表的关系型数据库中,以期利用这些数据库作为数据汇聚与分析的核心平台。
|
||||
以往的技术解决方案中,客户普遍采用常规的实时数据库来搜集现场数据。然而,这些传统软件在数据分析功能上显得力不从心。鉴于此,用户不得不将数据迁移到以 Oracle 为代表的关系型数据库中,以期利用这些数据库作为数据汇聚与分析的核心平台。
|
||||
|
||||
但随着油田数据量的激增,客户遭遇了两大核心挑战:一是数据采集量的快速增长,二是数据采集频率的显著提高。在这种背景下,传统关系型数据库在数据处理上开始显现出一系列问题和瓶颈。
|
||||
|
||||
|
@ -46,35 +46,35 @@ toc_max_heading_level: 4
|
|||
- 数据的分区和归档操作变得异常复杂,一旦系统出现故障,恢复数据所需的时间极为漫长,这对业务连续性构成了严重威胁。
|
||||
- 数据协同效率低下,难以实现秒级的数据同步,这对于需要快速响应的业务场景来说是一个巨大的限制。
|
||||
|
||||
在这样的项目背景下,TDengine凭借作为时序数据库的独特优势,展现出强大的竞争力。TDengine以高效的数据处理速度、卓越的数据压缩率、直观的系统易用性以及出色的可扩展性,有效地支持了智慧油田项目在数据管理和分析方面的需求。此外,TDengine还覆盖了数据生命周期的全管理流程,并积极应对日益严峻的数据安全挑战,确保了大型项目在技术上的顺利优化和升级。
|
||||
在这样的项目背景下,TDengine 凭借作为时序数据库的独特优势,展现出强大的竞争力。TDengine 以高效的数据处理速度、卓越的数据压缩率、直观的系统易用性以及出色的可扩展性,有效地支持了智慧油田项目在数据管理和分析方面的需求。此外,TDengine 还覆盖了数据生命周期的全管理流程,并积极应对日益严峻的数据安全挑战,确保了大型项目在技术上的顺利优化和升级。
|
||||
|
||||
TDengine的“一个数据采集点一张表”与“超级表”的创新设计理念,极大地提高了时序数据的写入、查询和存储效率。如下图所示,当客户采用TDengine后,他们可以根据不同专业领域的多样化数据需求,创建相应的超级表。以油井为例,客户首先须细致梳理业务所需的数据项及其采集频率,随后为每一口油井建立一张独立的表,并为这些表附加相应的静态标签,如采油厂名称、所属业务部门等。这样的设计不仅确保了数据的精细化管理和高效检索,还极大地简化了数据的组织和维护工作。
|
||||
TDengine 的“一个数据采集点一张表”与“超级表”的创新设计理念,极大地提高了时序数据的写入、查询和存储效率。如下图所示,当客户采用 TDengine 后,他们可以根据不同专业领域的多样化数据需求,创建相应的超级表。以油井为例,客户首先须细致梳理业务所需的数据项及其采集频率,随后为每一口油井建立一张独立的表,并为这些表附加相应的静态标签,如采油厂名称、所属业务部门等。这样的设计不仅确保了数据的精细化管理和高效检索,还极大地简化了数据的组织和维护工作。
|
||||
|
||||

|
||||
|
||||
在将Oracle全面迁移至TDengine之后,该项目的优化效果显著,具体体现在以下几个方面。
|
||||
在将 Oracle 全面迁移至 TDengine 之后,该项目的优化效果显著,具体体现在以下几个方面。
|
||||
- 数据写入性能显著提升,同时硬件资源消耗得以降低,实现了更高的资源利用率。
|
||||
- 集群支持在线水平扩展,使得未来面对扩容需求时能够轻松应对,保证了系统的可扩展性和前瞻性。
|
||||
- 灵活定义数据的生命周期,简化了过期数据的管理流程,提高了数据管理的效率和便捷性。
|
||||
- 达到每秒500万测点的同步速率,这一性能指标满足了用户在边云协同场景下的高实时性需求,为数据的高效流动和利用提供了有力保障。
|
||||
- 达到每秒 500 万测点的同步速率,这一性能指标满足了用户在边云协同场景下的高实时性需求,为数据的高效流动和利用提供了有力保障。
|
||||
|
||||
如果说前3点是TDengine固有特性的体现,那么第4点无疑是其核心价值所在。为了满足人工智能研究、数据挖掘、设备预测性维护等多方面的数据需求,客户经常需要将各个厂级的油田实时数据集中汇聚至公司层面,然后再进一步将公司数据整合至集团或相应的业务板块。如下图所示,这一过程对数据的实时性和同步性提出了极高要求,TDengine的出色表现确保了这一关键环节的顺畅运行。
|
||||
如果说前 3 点是 TDengine 固有特性的体现,那么第 4 点无疑是其核心价值所在。为了满足人工智能研究、数据挖掘、设备预测性维护等多方面的数据需求,客户经常需要将各个厂级的油田实时数据集中汇聚至公司层面,然后再进一步将公司数据整合至集团或相应的业务板块。如下图所示,这一过程对数据的实时性和同步性提出了极高要求,TDengine 的出色表现确保了这一关键环节的顺畅运行。
|
||||
|
||||

|
||||
|
||||
在传统业务模式中,由于需要定义众多复杂的数据接口,导致业务开发效率低下,且数据传输频率受限,难以满足对原始数据和原始频率进行同步的需求。在这一关键节点上,客户可以充分利用TDengine的边云协同功能,实现数据的实时高效同步。
|
||||
在传统业务模式中,由于需要定义众多复杂的数据接口,导致业务开发效率低下,且数据传输频率受限,难以满足对原始数据和原始频率进行同步的需求。在这一关键节点上,客户可以充分利用 TDengine 的边云协同功能,实现数据的实时高效同步。
|
||||
|
||||
边云协同允许将多个分散在不同地点的TDengine服务中的全量历史数据以及新产生的数据实时同步至云端TDengine。作为TDengine套件的重要组成部分,taosX工具简化了这一过程。用户只须在数据接收端部署taosX,并通过一行简单的命令,即可轻松实现实时数据同步、历史数据迁移,或是两者的混合处理方案。例如,同步某台服务器的db1 的历史数据以及实时数据到本地的db2数据库仅需要执行如下一条命令。
|
||||
边云协同允许将多个分散在不同地点的 TDengine 服务中的全量历史数据以及新产生的数据实时同步至云端 TDengine。作为 TDengine 套件的重要组成部分,taosX 工具简化了这一过程。用户只须在数据接收端部署 taosX,并通过一行简单的命令,即可轻松实现实时数据同步、历史数据迁移,或是两者的混合处理方案。例如,同步某台服务器的 db1 的历史数据以及实时数据到本地的 db2 数据库仅需要执行如下一条命令。
|
||||
```shell
|
||||
taosxrun-f'taos://192.168.1.101:6030/db1?mode=all'-t'taos://localhost:6030/db2'-v
|
||||
```
|
||||
|
||||
此外,taosX提供了一种基于数据订阅的实时数据同步方法,它按照事件到达的顺序来处理数据。这种方法确保了无论是实时数据还是历史数据的写入,都能够实时同步到目标集群,并且不会遗漏任何补录的历史数据。
|
||||
|
||||
通过实施这一方案,多个TDengine服务得以通过taosX跨省份实时同步数据至云端总部集群。迄今为止,在该项目中,TDengine总部集群存储的数据量已达到36TB,总数据条目超过1034亿条,压缩率降至10%以内,这一成就令人瞩目。
|
||||
通过实施这一方案,多个 TDengine 服务得以通过 taosX 跨省份实时同步数据至云端总部集群。迄今为止,在该项目中,TDengine 总部集群存储的数据量已达到 36TB,总数据条目超过 1034 亿条,压缩率降至 10% 以内,这一成就令人瞩目。
|
||||
|
||||
边云协同功能的广泛采用充分验证了TDengine在处理大规模、高频工业数据方面的卓越实力。其灵活的架构设计和优化的存储机制不仅满足了工业物联网环境对实时数据处理的高要求,而且有效降低了存储成本。同时,TDengine的水平扩展性、实时分析支持、边缘计算集成以及强大的数据安全保护功能,为工业物联网的智能化发展奠定了坚实的技术基础。这不仅确保了数据处理的高效性和安全性,还简化了维护流程,相较于传统关系型数据库,展现了更高的成本效益。TDengine的这些优势为工业物联网的持续进步和发展提供了强有力的支持和保障。
|
||||
边云协同功能的广泛采用充分验证了 TDengine 在处理大规模、高频工业数据方面的卓越实力。其灵活的架构设计和优化的存储机制不仅满足了工业物联网环境对实时数据处理的高要求,而且有效降低了存储成本。同时,TDengine 的水平扩展性、实时分析支持、边缘计算集成以及强大的数据安全保护功能,为工业物联网的智能化发展奠定了坚实的技术基础。这不仅确保了数据处理的高效性和安全性,还简化了维护流程,相较于传统关系型数据库,展现了更高的成本效益。TDengine 的这些优势为工业物联网的持续进步和发展提供了强有力的支持和保障。
|
||||
|
||||
随着项目的深入推进,TDengine的数据抽稀功能,作为处理和管理时序数据的一种高效策略,在与Kudu为核心的数据中台相结合时,展现出非凡的能力。数据抽稀通过精心挑选具有代表性的数据点,有效减少了数据的存储量,同时确保了数据的关键特征和趋势得以完整保留。这种方法特别适合于那些需要长期保存数据但又不必要保留所有细节的应用场景。例如,在监控系统中,随着时间的积累,只须保存关键时间节点的数据,而不是每个瞬间的数据。
|
||||
随着项目的深入推进,TDengine 的数据抽稀功能,作为处理和管理时序数据的一种高效策略,在与 Kudu 为核心的数据中台相结合时,展现出非凡的能力。数据抽稀通过精心挑选具有代表性的数据点,有效减少了数据的存储量,同时确保了数据的关键特征和趋势得以完整保留。这种方法特别适合于那些需要长期保存数据但又不必要保留所有细节的应用场景。例如,在监控系统中,随着时间的积累,只须保存关键时间节点的数据,而不是每个瞬间的数据。
|
||||
|
||||
因此,TDengine成为构建数据中台的理想选择,尤其是对于那些需要高效处理大量时序数据的中台环境。通过将TDengine集成到数据中台中,企业能够进一步优化其数据存储、查询和管理流程,从而提高数据平台的功能性和效率。TDengine的这一特性不仅提高了数据处理的速度和效率,还为企业提供了更加灵活和经济的数据管理解决方案。
|
||||
因此,TDengine 成为构建数据中台的理想选择,尤其是对于那些需要高效处理大量时序数据的中台环境。通过将 TDengine 集成到数据中台中,企业能够进一步优化其数据存储、查询和管理流程,从而提高数据平台的功能性和效率。TDengine 的这一特性不仅提高了数据处理的速度和效率,还为企业提供了更加灵活和经济的数据管理解决方案。
|
|
@ -6,59 +6,56 @@ toc_max_heading_level: 4
|
|||
|
||||
智能制造与数据库技术的深度融合,已成为现代工业技术进步的一个重要里程碑。随着信息技术的飞速发展,智能制造已经成为推动工业转型升级的关键动力。在这一进程中,数据库技术扮演着不可或缺的角色,它不仅承载着海量的生产数据,还为智能制造提供了强大的数据支持和服务。
|
||||
|
||||
特别是随着大数据、云计算等前沿技术的崛起,TDengine凭借灵活多变的数据模型和卓越的数据处理能力,在智能制造领域大放异彩。TDengine能够高效地管理和分析制造过程中的各类数据,从生产线的实时监控到产品质量的精细管理,再到供应链的优化协调,它都能提供精准可靠的数据支持。
|
||||
特别是随着大数据、云计算等前沿技术的崛起,TDengine 凭借灵活多变的数据模型和卓越的数据处理能力,在智能制造领域大放异彩。TDengine 能够高效地管理和分析制造过程中的各类数据,从生产线的实时监控到产品质量的精细管理,再到供应链的优化协调,它都能提供精准可靠的数据支持。
|
||||
|
||||
## 智能制造面临的挑战
|
||||
|
||||
依照传统的IEC 62264-1层次模型,工业制造领域被划分为5个层级—现场设备层、现场控制层、过程监控层、生产管理层及企业资源层。这一模型清晰地描绘了从生产现场的实时操作到企业管理层面的战略规划,每一层级的跃迁都伴随着数据量的急剧增长和需求的变化,如下图所示。这种层级划分不仅反映了工业制造过程中信息流动的复杂性,也揭示了随着生产规模的扩大和自动程度的提高,对数据处理能力和效率的要求也在不断提升。
|
||||
依照传统的 IEC 62264-1 层次模型,工业制造领域被划分为 5 个层级—现场设备层、现场控制层、过程监控层、生产管理层及企业资源层。这一模型清晰地描绘了从生产现场的实时操作到企业管理层面的战略规划,每一层级的跃迁都伴随着数据量的急剧增长和需求的变化,如下图所示。这种层级划分不仅反映了工业制造过程中信息流动的复杂性,也揭示了随着生产规模的扩大和自动程度的提高,对数据处理能力和效率的要求也在不断提升。
|
||||
|
||||

|
||||
|
||||
随着工业数字化的巨浪席卷而来,我们见证了数据采集量的爆炸式增长和分析需求的日益复杂化,随之而来的问题和挑战也愈发凸显。
|
||||
- 海量设备数据采集:在过去的十余年里,制造业的数字化进程取得了显著进展。工厂的数据采集点从传统的数千个激增至数十万甚至数百万个。面对如此庞大的
|
||||
数据采集需求,传统的实时数据库已显得力不从心。
|
||||
- 海量设备数据采集:在过去的十余年里,制造业的数字化进程取得了显著进展。工厂的数据采集点从传统的数千个激增至数十万甚至数百万个。面对如此庞大的数据采集需求,传统的实时数据库已显得力不从心。
|
||||
- 动态扩容:随着数据的逐步接入,初期的硬件配置往往较为有限。随着业务量的增加和数据量的上升,硬件资源必须迅速扩展以满足业务的正常运行。然而,一旦系统上线运行,通常不允许进行停机扩容,这就要求系统在设计时就要考虑到未来的扩展性。
|
||||
- 数据关联与多维分析:传统工业实时数据库通常只包含几个固定的字段,如变量名、变量值、质量戳和时间戳,缺乏信息间的关联性,这使得复杂的多维分析变
|
||||
得难以执行。
|
||||
- 数据关联与多维分析:传统工业实时数据库通常只包含几个固定的字段,如变量名、变量值、质量戳和时间戳,缺乏信息间的关联性,这使得复杂的多维分析变得难以执行。
|
||||
- 截面查询与插值查询:为了满足报表和其他统计需求,系统需要支持历史截面查询以及按指定时间间隔进行的线性插值查询。
|
||||
- 第三方系统数据库对接:除了设备数据以外,还须采集来自各个生产系统的数据,这些系统通常位于过程监控层或生产管理层。这就要求系统能够实时采集数据、迁移历史数据,并在网络断开时能够断线续传。除了API以外,常见的对接方式还包括数据库对接,例如,与LIMIS对接,采集其关系型数据库中存储的时序数据,或与第三方生产数据库(如AVEVA PI System或Wonderware系统)对接,获取实时、历史和报警数据。
|
||||
- 与SCADA(Supervisory Control and Data Acquisition,监控控制与数据采集)系统对接:SCADA系统作为过程监控层的核心,汇集了站内和厂区的所有生产数据,并提供了直观易用的开发、运行和管理界面。然而,其自带的传统实时数据库在分析能力和高密度点位容量上存在限制,通常仅支持约1万个点位。因此,将SCADA系统与性能更优越的数据库相结合,充分发挥双方的优势,通过面向操作技术层的模块化组态开发,为工业控制系统注入新的活力,已成为工业数字化发展的重要方向。
|
||||
- 第三方系统数据库对接:除了设备数据以外,还须采集来自各个生产系统的数据,这些系统通常位于过程监控层或生产管理层。这就要求系统能够实时采集数据、迁移历史数据,并在网络断开时能够断线续传。除了 API 以外,常见的对接方式还包括数据库对接,例如,与LIMIS对接,采集其关系型数据库中存储的时序数据,或与第三方生产数据库(如AVEVA PI System或Wonderware系统)对接,获取实时、历史和报警数据。
|
||||
- 与SCADA(Supervisory Control and Data Acquisition,监控控制与数据采集)系统对接:SCADA 系统作为过程监控层的核心,汇集了站内和厂区的所有生产数据,并提供了直观易用的开发、运行和管理界面。然而,其自带的传统实时数据库在分析能力和高密度点位容量上存在限制,通常仅支持约 1 万个点位。因此,将 SCADA 系统与性能更优越的数据库相结合,充分发挥双方的优势,通过面向操作技术层的模块化组态开发,为工业控制系统注入新的活力,已成为工业数字化发展的重要方向。
|
||||
|
||||
## TDengine在智能制造中的核心价值
|
||||
|
||||
智能制造领域涵盖众多类型的数据设备、系统以及复杂的数据分析方法。TDengine 不仅巧妙解决了数据接入和存储的挑战,更通过强大的数据分析功能,为黄金批次、设备综合效率(Overall Equipment Effectiveness,OEE)、设备预防性维护、统计过程控制(Statistical Process Control,SPC)等关键分析系统提供了卓越的数据统计服务。这不仅显著提高了生产效率和产品品质,还有效降低了生产成本。
|
||||
|
||||
- 广泛兼容各种设备和系统:TDengine配备了可视化配置的采集器,能够轻松对接SQL Server、MySQL、Oracle、AVEVA PI System、AVEVA Historian、InfluxDB、OpenTSDB、ClickHouse等多种系统,支持实时数据采集、历史数据迁移以及断线续传等功能。通过与诸如Kepware或KingIOServer这样的强大第三方采集平台对接,TDengine能够应对各种工业互联网协议,实现海量生产设备数据的接入。
|
||||
- 高效的集群管理:与传统实时数据库相比,TDengine采用了基于云原生技术的先进架构,能够轻松实现动态扩容。TDengine集群采用Raft强一致性协议,确保生产数据对外查询结果的一致性。集群的运维管理简便,内部自动完成数据分区和数据分片,实现了分布式、高可用性和负载均衡的集群环境。
|
||||
- 设备物模型:TDengine秉承“一台设备一张表”的设计策略,构建了以设备对象为核心的变量关系模型,为相关分析提供了坚实的基础。
|
||||
- 先进的时序分析:TDengine支持时序领域的截面查询、步进查询、线性插值查询等多种查询方式,并提供了窗口查询功能,使得设备状态时长统计、连续过载报警等时序分析变得简单易行。
|
||||
- 广泛兼容各种设备和系统:TDengine配备了可视化配置的采集器,能够轻松对接 SQL Server、MySQL、Oracle、AVEVA PI System、AVEVA Historian、InfluxDB、OpenTSDB、ClickHouse 等多种系统,支持实时数据采集、历史数据迁移以及断线续传等功能。通过与诸如 Kepware 或 KingIOServer 这样的强大第三方采集平台对接,TDengine 能够应对各种工业互联网协议,实现海量生产设备数据的接入。
|
||||
- 高效的集群管理:与传统实时数据库相比,TDengine 采用了基于云原生技术的先进架构,能够轻松实现动态扩容。TDengine 集群采用 Raft 强一致性协议,确保生产数据对外查询结果的一致性。集群的运维管理简便,内部自动完成数据分区和数据分片,实现了分布式、高可用性和负载均衡的集群环境。
|
||||
- 设备物模型:TDengine 秉承“一台设备一张表”的设计策略,构建了以设备对象为核心的变量关系模型,为相关分析提供了坚实的基础。
|
||||
- 先进的时序分析:TDengine 支持时序领域的截面查询、步进查询、线性插值查询等多种查询方式,并提供了窗口查询功能,使得设备状态时长统计、连续过载报警等时序分析变得简单易行。
|
||||
|
||||
## TDengine在智能制造中的应用
|
||||
|
||||
作为新一代时序大数据平台的杰出代表,TDengine针对工业场景中的种种挑战,凭借独特的设计理念和卓越的性能,为智能制造领域注入了强大的动力。接下来以某烟厂的实际应用案例为例进行阐述。
|
||||
作为新一代时序大数据平台的杰出代表,TDengine 针对工业场景中的种种挑战,凭借独特的设计理念和卓越的性能,为智能制造领域注入了强大的动力。接下来以某烟厂的实际应用案例为例进行阐述。
|
||||
|
||||
在该项目中,TDengine集群为工厂内的各类业务提供了坚实的时序数据服务。无论是看板展示还是预警系统等对实时数据要求极高的业务场景,TDengine都能够提供低延迟、高质量的数据响应。自系统上线以来,已稳定运行超过两年,成功存储超过2万亿条数据,且查询最新数据的延迟控制在毫秒级,完全达到项目立项的预期要求。该项目的亮点设计如下
|
||||
在该项目中,TDengine 集群为工厂内的各类业务提供了坚实的时序数据服务。无论是看板展示还是预警系统等对实时数据要求极高的业务场景,TDengine 都能够提供低延迟、高质量的数据响应。自系统上线以来,已稳定运行超过两年,成功存储超过 2 万亿条数据,且查询最新数据的延迟控制在毫秒级,完全达到项目立项的预期要求。该项目的亮点设计如下
|
||||
|
||||
- 高效采集:烟草项目初期规模有限,全厂测点数不足10万。数据采集网关将部分测点数据写入OPC(OLE for Process Control,用于过程控制的OLE)服务器,并通过OPC协议接入TDengine;另一部分测点数据则写入Kafka,进而接入TDengine。客户无须开发OPC或Kafka接口应用程序,即可实现数据的高效接入。对于采用关系型数据库如LIMIS的场景,TDengine通过可视化配置SQL Server采集器,实现了数据的同步更新、历史数据迁移、断线续传以及故障诊断等功能,无须编写代码,大幅降低了开发和运维成本。在其兄弟单位中,部分生产系统使用Wonderware数据库(现AVEVA Historian),TDengine通过建立AVEVA Historian采集器,同样实现了零代码可视化配置,轻松完成实时数据接入、历史数据迁移及断线续传等功能。相较于初次定制化开发长达3个月的交付周期,TDengine采集器的部署仅需要十几分钟,且具有更强的可靠性和灵活性。
|
||||
- 动态扩容和负载再均衡:为应对未来业务的增长,TDengine支持在不停止服务的前提下进行动态的纵向和水平扩容。在单台计算机资源充足的场景下,TDengine 可通过拆分虚拟节点服务,充分利用计算机的额外CPU资源来提高数据库性能。而在资源不足的情况下,只须增加物理节点,TDengine集群便能根据需求进行自动负载均衡。
|
||||
- 支持建立大宽表:TDengine的这一设计满足了数据关联和多维分析的需求,解决了传统工业实时数据库固定格式数据存储的限制。通过超级表的静态标签设计,
|
||||
- 高效采集:烟草项目初期规模有限,全厂测点数不足 10 万。数据采集网关将部分测点数据写入OPC(OLE for Process Control,用于过程控制的 OLE)服务器,并通过 OPC 协议接入 TDengine;另一部分测点数据则写入 Kafka,进而接入 TDengine。客户无须开发 OP C或 Kafka 接口应用程序,即可实现数据的高效接入。对于采用关系型数据库如 LIMIS 的场景,TDengine 通过可视化配置 SQL Server 采集器,实现了数据的同步更新、历史数据迁移、断线续传以及故障诊断等功能,无须编写代码,大幅降低了开发和运维成本。在其兄弟单位中,部分生产系统使用 Wonderware 数据库(现 AVEVA Historian),TDengine 通过建立 AVEVA Historian 采集器,同样实现了零代码可视化配置,轻松完成实时数据接入、历史数据迁移及断线续传等功能。相较于初次定制化开发长达 3 个月的交付周期,TDengine 采集器的部署仅需要十几分钟,且具有更强的可靠性和灵活性。
|
||||
- 动态扩容和负载再均衡:为应对未来业务的增长,TDengine 支持在不停止服务的前提下进行动态的纵向和水平扩容。在单台计算机资源充足的场景下,TDengine 可通过拆分虚拟节点服务,充分利用计算机的额外 CPU 资源来提高数据库性能。而在资源不足的情况下,只须增加物理节点,TDengine 集群便能根据需求进行自动负载均衡。
|
||||
- 支持建立大宽表:TDengine 的这一设计满足了数据关联和多维分析的需求,解决了传统工业实时数据库固定格式数据存储的限制。通过超级表的静态标签设计,
|
||||
用户可以便捷地进行多维度数据分析。
|
||||
- 支持丰富的对外接口:作为数据中心,TDengine可对接第三方可视化界面(如看板)、MES、预警报警、水分预测、零配件需求预测、SPC、故障分析、产能分析、能耗分析、预防性维护等系统,如下图所示:
|
||||
- 支持丰富的对外接口:作为数据中心,TDengine 可对接第三方可视化界面(如看板)、MES、预警报警、水分预测、零配件需求预测、SPC、故障分析、产能分析、能耗分析、预防性维护等系统,如下图所示:
|
||||
|
||||

|
||||
|
||||
- TDengine与SCADA系统的融合:生产调度中心常采用SCADA系统进行数据采集、监视和控制。SCADA系统通过TDengine的ODBC接口,将实时和历史数据、设备报警、操作记录、登录信息以及系统事件等数据存储到TDengine中。与SCADA系统自带的历史库相比,客户在查询曲线、报表等历史数据时耗时更短、响应更快、灵活性更强,这不仅降低了对SCADA系统的压力,还提高了整个系统的效率和稳定性。
|
||||
- TDengine 与 SCADA 系统的融合:生产调度中心常采用 SCADA 系统进行数据采集、监视和控制。SCADA 系统通过 TDengine 的 ODBC 接口,将实时和历史数据、设备报警、操作记录、登录信息以及系统事件等数据存储到 TDengine 中。与 SCADA 系统自带的历史库相比,客户在查询曲线、报表等历史数据时耗时更短、响应更快、灵活性更强,这不仅降低了对 SCADA 系统的压力,还提高了整个系统的效率和稳定性。
|
||||
|
||||
此外,TDengine还支持云边系统部署,如下图所示:
|
||||
此外,TDengine 还支持云边系统部署,如下图所示:
|
||||
|
||||

|
||||
|
||||
在工厂侧部署TDengine,不仅为该烟厂提供数据存储、查询和分析服务,还能通过高效的数据同步工具,实现工厂数据实时同步至上一级或集团中心。TDengine的量化裁剪功能使其能够适应资源有限的计算机或边缘盒子环境,满足不同规模部署的需求。TDengine的同步特性如下。
|
||||
在工厂侧部署 TDengine,不仅为该烟厂提供数据存储、查询和分析服务,还能通过高效的数据同步工具,实现工厂数据实时同步至上一级或集团中心。TDengine 的量化裁剪功能使其能够适应资源有限的计算机或边缘盒子环境,满足不同规模部署的需求。TDengine 的同步特性如下。
|
||||
|
||||
- 统计意义的降采样同步:TDengine利用流计算技术,实现了具有统计意义的降采样数据同步。通过这种方式,可以在不损失数据精度的前提下,对数据进行降采样处理,确保即使在数据时间颗粒度增大的情况下,也能保持数据的准确性。流计算的使用方式简便,无须复杂配置,客户只须根据自己的需求编写SQL即可实现。
|
||||
- 订阅式传输:TDengine采用了类似Kafka的消息订阅方式进行数据同步,相较于传统的周期性同步和普通订阅访问,这种方式实现了负载隔离和流量削峰,提高了同步的稳定性和效率。消息订阅机制遵循至少一次消费原则,确保在网络断线故障恢复后,能够从断点处继续消费数据,或者从头开始消费,以保证消费者能够接收到完整的生产数据。
|
||||
- 操作行为同步:TDengine能够将操作行为同步到中心端,确保设备故障或人为对边缘侧数据的修改和删除操作能够实时反映到中心侧,维护了数据的一致性。
|
||||
- 数据传输压缩:在数据传输过程中,TDengine实现了高达20%的数据压缩率,结合流计算的降采样同步,显著降低了同步过程对带宽的占用,提高了数据传输
|
||||
效率。
|
||||
- 多种同步方式:TDengine支持多对一、一对多以及多对多的数据同步模式,满足不同场景下的数据同步需求。
|
||||
- 支持双活:数据中心侧可实现异地灾备。边缘侧的TDengine或第三方客户端能够根据集团中心侧的TDengine状态进行智能连接。若主TDengine集群发生故障,无法对外提供服务,异地备用的TDengine集群将立即激活,接管所有客户端的访问连接,包括写入和查询功能。一旦主TDengine集群恢复正常,备用集群会将历史缓存和实时数据同步回主集群,整个过程对客户端透明,无须人工干预。
|
||||
- 统计意义的降采样同步:TDengine 利用流计算技术,实现了具有统计意义的降采样数据同步。通过这种方式,可以在不损失数据精度的前提下,对数据进行降采样处理,确保即使在数据时间颗粒度增大的情况下,也能保持数据的准确性。流计算的使用方式简便,无须复杂配置,客户只须根据自己的需求编写SQL即可实现。
|
||||
- 订阅式传输:TDengine 采用了类似 Kafka 的消息订阅方式进行数据同步,相较于传统的周期性同步和普通订阅访问,这种方式实现了负载隔离和流量削峰,提高了同步的稳定性和效率。消息订阅机制遵循至少一次消费原则,确保在网络断线故障恢复后,能够从断点处继续消费数据,或者从头开始消费,以保证消费者能够接收到完整的生产数据。
|
||||
- 操作行为同步:TDengine 能够将操作行为同步到中心端,确保设备故障或人为对边缘侧数据的修改和删除操作能够实时反映到中心侧,维护了数据的一致性。
|
||||
- 数据传输压缩:在数据传输过程中,TDengine 实现了高达 20% 的数据压缩率,结合流计算的降采样同步,显著降低了同步过程对带宽的占用,提高了数据传输效率。
|
||||
- 多种同步方式:TDengine 支持多对一、一对多以及多对多的数据同步模式,满足不同场景下的数据同步需求。
|
||||
- 支持双活:数据中心侧可实现异地灾备。边缘侧的 TDengine 或第三方客户端能够根据集团中心侧的 TDengine 状态进行智能连接。若主 TDengine 集群发生故障,无法对外提供服务,异地备用的 TDengine 集群将立即激活,接管所有客户端的访问连接,包括写入和查询功能。一旦主 TDengine 集群恢复正常,备用集群会将历史缓存和实时数据同步回主集群,整个过程对客户端透明,无须人工干预。
|
|
@ -8,16 +8,15 @@ toc_max_heading_level: 4
|
|||
|
||||
在金融领域,行情数据的处理尤为复杂,不仅数据量大,而且具有标准化的数据格式、长期的存储需求以及高度分散的子表管理要求,这些特点共同构成了数据处理领域的一大难题。具体挑战如下。
|
||||
|
||||
- 数据量庞大:金融市场的数据量达到TB级别,这为数据的存储和管理带来巨大的挑战。金融机构需要确保有足够的能力来处理和存储这些数据,同时保证系统的稳定性和可扩展性。
|
||||
- 数据量庞大:金融市场的数据量达到 TB 级别,这为数据的存储和管理带来巨大的挑战。金融机构需要确保有足够的能力来处理和存储这些数据,同时保证系统的稳定性和可扩展性。
|
||||
- 标的数量众多:金融市场中资产和衍生品的种类繁多,这意味着行情中心需要管理数十万至数千万个不同的标的。这种多样性和数量级的增长要求系统必须具备高度的灵活性和高效的管理能力。
|
||||
- 存储期限长:金融数据的敏感性要求这些数据必须被长期保存,通常存储期限为5至10年,有些关键数据甚至需要保存超过30年。这要求金融机构必须投资于可靠的存储解决方案,以确保长期数据的完整性和可访问性。
|
||||
- 存储期限长:金融数据的敏感性要求这些数据必须被长期保存,通常存储期限为 5 至 10 年,有些关键数据甚至需要保存超过 30 年。这要求金融机构必须投资于可靠的存储解决方案,以确保长期数据的完整性和可访问性。
|
||||
|
||||
## 处理金融时序数据时面临的挑战
|
||||
|
||||
在时序数据处理领域,金融机构面临着一系列核心需求与挑战,这些需求与挑战不仅关系到日常运营的效率,还直接影响到决策的准确性和业务的创新能力。
|
||||
|
||||
- 高性能写入:金融机构需要的是一个能够实时处理巨量数据流的平台。随着交易活动的频繁和市场数据的不断更新,平台必须能够每秒处理数以亿计的数据点,
|
||||
确保数据的即时性和完整性,以支持实时的交易决策和风险管理。
|
||||
- 高性能写入:金融机构需要的是一个能够实时处理巨量数据流的平台。随着交易活动的频繁和市场数据的不断更新,平台必须能够每秒处理数以亿计的数据点,确保数据的即时性和完整性,以支持实时的交易决策和风险管理。
|
||||
- 强大的读取及数据消费性能:金融市场的特点是业务场景多变,这要求平台必须具备高度的数据读取和计算能力。例如,量化投资策略的研发依赖于实时行情数据和衍生数据的深度分析。平台需要支持高效的数据查询和计算,以便量化分析师能够快速回测模型、优化策略,并进行实时学习和调整。
|
||||
- 计算性能:资产和衍生品的监控对平台的计算性能提出了更高的要求。金融机构需要能够执行复杂的统计分析、风险预测和价格发现等计算任务,以监控市场动态和评估投资组合的风险。这要求平台不仅要有强大的计算能力,还要能够提供快速响应,以支持实时决策和快速反应市场变化。
|
||||
|
||||
|
@ -40,7 +39,7 @@ TDengine,作为一个高性能、云原生的时序大数据平台,在金融
|
|||
|
||||
特别是在金融科技取得突破性进展的今天,量化交易已成为资本市场中一股不可逆转的趋势。基于行情数据的量化交易平台,凭借其全面的应用模块和深入的数据应用能力,为金融市场提供了精准的分析和智能化的决策支持。这些平台不仅能够处理海量的市场数据,还能够运用先进的算法和模型,为交易者提供个性化的投资策略和风险管理方案。
|
||||
|
||||
在此背景下,TDengine作为一个专为时序数据设计的高性能数据库,其在量化交易平台中的应用,进一步提高了平台的性能和效率。TDengine的主要模块或功能如下。
|
||||
在此背景下,TDengine 作为一个专为时序数据设计的高性能数据库,其在量化交易平台中的应用,进一步提高了平台的性能和效率。TDengine 的主要模块或功能如下。
|
||||
|
||||
1. 多路校验
|
||||
|
||||
|
@ -64,7 +63,7 @@ TDengine 中的智能监控和分析是一系列高级特性,它们共同构
|
|||
- 自动调整交易策略:TDengine 的函数、UDF 和流计算功能,结合其他计算框架,使得交易策略能够根据市场实时数据自动调整。这种自适应的策略调整机制优化了资产配置,提高了交易的灵活性和效率。
|
||||
- 清晰的交易执行计划:通过对数据进行全面的计算分析,TDengine 能够输出清晰、明确的交易执行计划,为投资团队提供决策支持。这些计划结合了市场分析和风险评估,有助于团队制定出更加精准和有效的投资策略。
|
||||
|
||||
行情数据文件和实时数据流统一汇入TDengine集群后,客户可以通过HTTP接口轻松访问所有时序数据,构建各种金融服务应用。行情数据系统架构(见下图)不仅提供了数据的集中管理,还为开发者提供了开放的接口,使得构建复杂的数据分析工具和金融服务应用变得更加便捷和高效。通过这种架构,金融机构能够加快创新速度,提升服务质量,并在竞争激烈的金融市场中获得优势。
|
||||
行情数据文件和实时数据流统一汇入 TDengine 集群后,客户可以通过 HTTP 接口轻松访问所有时序数据,构建各种金融服务应用。行情数据系统架构(见下图)不仅提供了数据的集中管理,还为开发者提供了开放的接口,使得构建复杂的数据分析工具和金融服务应用变得更加便捷和高效。通过这种架构,金融机构能够加快创新速度,提升服务质量,并在竞争激烈的金融市场中获得优势。
|
||||
|
||||

|
||||
|
||||
|
@ -77,8 +76,8 @@ TDengine 中的智能监控和分析是一系列高级特性,它们共同构
|
|||
- 高并发:行情中心需要同时为众多应用提供高效的服务,必须具备强大的高并发处理能力。除了支持实时交易的核心业务以外,行情中心还须为量化回测、因子计算、风险管理等提供高效的时序数据服务。
|
||||
- 稳定性:作为金融市场的心脏,行情中心的稳定运行至关重要。任何形式的停机或故障都可能导致不可估量的经济损失。系统的高稳定性和可靠性是不可或缺的。众多券商在经过全面评估后,纷纷选择 TDengine 作为构建行情中心的核心组件,并且已经稳定运行多年。这一选择充分验证了 TDengine 在以下几个关键方面的卓越价值。
|
||||
- 实时性:TDengine 的高效写入能力能够处理大量的实时数据流,支持毫秒级甚至亚毫秒级的数据查询响应,完美契合行情中心对实时性的高标准要求。
|
||||
- 高并发处理:TDengine 设计了卓越的并发处理机制,能够支持从千万到亿级别的QPS(Queries Per Second,每秒查询率)的时序数据读写操作,确保了各类业务对实时和历史行情数据的写入和查询需求得到满足。
|
||||
- 高并发处理:TDengine 设计了卓越的并发处理机制,能够支持从千万到亿级别的 QPS(Queries Per Second,每秒查询率)的时序数据读写操作,确保了各类业务对实时和历史行情数据的写入和查询需求得到满足。
|
||||
- 海量数据处理能力:TDengine 的“一个数据采集点一张表”创新设计,结合先进的数据压缩技术和高效的存储格式,使得即使在存储超过 10 年历史数据的情况下,依然能够保持良好的读写性能,并且显著降低了存储空间的占用。
|
||||
- 稳定性:TDengine 提供了服务的高可用性和数据的强一致性保障,即使在单个节点发生故障的情况下,也能确保系统连续稳定运行,满足了行情中心对系统稳定性的严格要求。
|
||||
|
||||
这些券商的选择不仅体现了TDengine在技术性能上的领先地位,也彰显了对TDengine在金融行业中可靠性和适用性的广泛认可。通过采用TDengine,券商能够进一步提升行情中心的服务质量,增强核心竞争力,并在激烈的市场竞争中占据有利地位。
|
||||
这些券商的选择不仅体现了 TDengine 在技术性能上的领先地位,也彰显了对 TDengine 在金融行业中可靠性和适用性的广泛认可。通过采用 TDengine,券商能够进一步提升行情中心的服务质量,增强核心竞争力,并在激烈的市场竞争中占据有利地位。
|
|
@ -33,14 +33,14 @@ dnode 在 TDengine 集群中的唯一标识由其实例的 endpoint(EP)决
|
|||
每个 vnode 都拥有独立的运行线程、内存空间和持久化存储路径,确保数据的隔离性和高效访问。一个 vnode 可以包含多张表(即数据采集点),这些表在物理上分布在不
|
||||
同的 vnode 上,以实现数据的均匀分布和负载均衡。
|
||||
|
||||
当在集群中创建一个新的数据库时,系统会自动为该数据库创建相应的 vnode。一个dnode 上能够创建的 vnode 数量取决于该 dnode 所在物理节点的硬件资源,如 CPU、内存和存储容量等。需要注意的是,一个 vnode 只能属于一个数据库,但一个数据库可以包含多个 vnode。
|
||||
当在集群中创建一个新的数据库时,系统会自动为该数据库创建相应的 vnode。一个 dnode 上能够创建的 vnode 数量取决于该 dnode 所在物理节点的硬件资源,如 CPU、内存和存储容量等。需要注意的是,一个 vnode 只能属于一个数据库,但一个数据库可以包含多个 vnode。
|
||||
|
||||
除了存储时序数据以外,每个 vnode 还保存了其包含的表的 schema 信息和标签值等元数据。这些信息对于数据的查询和管理至关重要。
|
||||
|
||||
在集群内部,一个 vnode 由其所归属的 dnode 的 endpoint 和所属的 vgroup ID 唯一标识。管理节点负责创建和管理这些 vnode,确保它们能够正常运行并协同工作。
|
||||
|
||||
**管理节点(mnode):**
|
||||
mnode(管理节点)是 TDengine 集群中的核心逻辑单元,负责监控和维护所有 dnode的运行状态,并在节点之间实现负载均衡(如图 15-1 中的 M1、M2、M3 所示)。作为元数据(包括用户、数据库、超级表等)的存储和管理中心,mnode 也被称为 MetaNode。
|
||||
mnode(管理节点)是 TDengine 集群中的核心逻辑单元,负责监控和维护所有 dnode的运行状态,并在节点之间实现负载均衡(如图 1 中的 M1、M2、M3 所示)。作为元数据(包括用户、数据库、超级表等)的存储和管理中心,mnode 也被称为 MetaNode。
|
||||
|
||||
为了提高集群的高可用性和可靠性,TDengine 集群允许有多个(最多不超过 3 个)mnode。这些 mnode 自动组成一个虚拟的 mnode 组,共同承担管理职责。mnode 支持多副本,并采用 Raft 一致性协议来确保数据的一致性和操作的可靠性。在 mnode 集群中,任何数据更新操作都必须在 leader 节点上执行。
|
||||
|
||||
|
@ -49,7 +49,7 @@ mnode 集群的第 1 个节点在集群部署时自动创建,而其他节点
|
|||
为了实现集群内部的信息共享和通信,每个 dnode 通过内部消息交互机制自动获取整个集群中所有 mnode 所在的 dnode 的 endpoint。
|
||||
|
||||
**计算节点(qnode):**
|
||||
qnode(计算节点)是 TDengine 集群中负责执行查询计算任务的虚拟逻辑单元,同时也处理基于系统表的 show 命令。为了提高查询性能和并行处理能力,集群中可以配置多个 qnode,这些 qnode 在整个集群范围内共享使用(如图 15-1 中的 Q1、Q2、Q3 所示)。
|
||||
qnode(计算节点)是 TDengine 集群中负责执行查询计算任务的虚拟逻辑单元,同时也处理基于系统表的 show 命令。为了提高查询性能和并行处理能力,集群中可以配置多个 qnode,这些 qnode 在整个集群范围内共享使用(如图 1 中的 Q1、Q2、Q3 所示)。
|
||||
|
||||
与 dnode 不同,qnode 并不与特定的数据库绑定,这意味着一个 qnode 可以同时处理来自多个数据库的查询任务。每个 dnode 上最多有一个 qnode,并由其所归属的 dnode 的endpoint 唯一标识。
|
||||
|
||||
|
@ -155,14 +155,14 @@ TDengine 集群可以容纳单个、多个甚至几千个数据节点。应用
|
|||
|
||||
<center> 图 2 TDengine 典型的操作流程 </center>
|
||||
|
||||
1. 应用通过 JDBC 或其他 API 接口发起插入数据的请求。
|
||||
2. taosc 会检查缓存,看是否保存有该表所在数据库的 vgroup-info 信息。如果有,直接到第 4 步。如果没有,taosc 将向 mnode 发出 get vgroup-info 请求。
|
||||
3. mnode 将该表所在数据库的 vgroup-info 返回给 taosc。Vgroup-info 包含数据库的 vgroup 分布信息(vnode ID 以及所在的 dnode 的 End Point,如果副本数为 N,就有 N 组 End Point),还包含每个 vgroup 中存储数据表的 hash 范围。如果 taosc 迟迟得不到 mnode 回应,而且存在多个 mnode,taosc 将向下一个 mnode 发出请求。
|
||||
4. taosc 会继续检查缓存,看是否保存有该表的 meta-data。如果有,直接到第 6 步。如果没有,taosc 将向 vnode 发出 get meta-data 请求。
|
||||
5. vnode 将该表的 meta-data 返回给 taosc。Meta-data 包含有该表的 schema。
|
||||
6. taosc 向 leader vnode 发起插入请求。
|
||||
7. vnode 插入数据后,给 taosc 一个应答,表示插入成功。如果 taosc 迟迟得不到 vnode 的回应,taosc 会认为该节点已经离线。这种情况下,如果被插入的数据库有多个副本,taosc 将向 vgroup 里下一个 vnode 发出插入请求。
|
||||
8. taosc 通知 APP,写入成功。
|
||||
- 第 1 步:应用通过 JDBC 或其他 API 接口发起插入数据的请求。
|
||||
- 第 2 步:taosc 会检查缓存,看是否保存有该表所在数据库的 vgroup-info 信息。如果有,直接到第 4 步。如果没有,taosc 将向 mnode 发出 get vgroup-info 请求。
|
||||
- 第 4 步:mnode 将该表所在数据库的 vgroup-info 返回给 taosc。Vgroup-info 包含数据库的 vgroup 分布信息(vnode ID 以及所在的 dnode 的 End Point,如果副本数为 N,就有 N 组 End Point),还包含每个 vgroup 中存储数据表的 hash 范围。如果 taosc 迟迟得不到 mnode 回应,而且存在多个 mnode,taosc 将向下一个 mnode 发出请求。
|
||||
- 第 4 步:taosc 会继续检查缓存,看是否保存有该表的 meta-data。如果有,直接到第 6 步。如果没有,taosc 将向 vnode 发出 get meta-data 请求。
|
||||
- 第 5 步:vnode 将该表的 meta-data 返回给 taosc。Meta-data 包含有该表的 schema。
|
||||
- 第 6 步:taosc 向 leader vnode 发起插入请求。
|
||||
- 第 7 步:vnode 插入数据后,给 taosc 一个应答,表示插入成功。如果 taosc 迟迟得不到 vnode 的回应,taosc 会认为该节点已经离线。这种情况下,如果被插入的数据库有多个副本,taosc 将向 vgroup 里下一个 vnode 发出插入请求。
|
||||
- 第 8 步:taosc 通知 APP,写入成功。
|
||||
|
||||
对于第二步,taosc 启动时,并不知道 mnode 的 End Point,因此会直接向配置的集群对外服务的 End Point 发起请求。如果接收到该请求的 dnode 并没有配置 mnode,该 dnode 会在回复的消息中告知 mnode EP 列表,这样 taosc 会重新向新的 mnode 的 EP 发出获取 meta-data 的请求。
|
||||
|
||||
|
@ -231,7 +231,7 @@ Leader Vnode 遵循下面的写入流程:
|
|||
|
||||
<center> 图 3 TDengine Leader 写入流程 </center>
|
||||
|
||||
- 第 1 步: leader vnode 收到应用的写入数据请求,验证 OK,验证有效性后进入第 2 步;
|
||||
- 第 1 步:leader vnode 收到应用的写入数据请求,验证 OK,验证有效性后进入第 2 步;
|
||||
- 第 2 步:vnode 将该请求的原始数据包写入数据库日志文件 WAL。如果 `wal_level` 设置为 2,而且 `wal_fsync_period` 设置为 0,TDengine 还将 WAL 数据立即落盘,以保证即使宕机,也能从数据库日志文件中恢复数据,避免数据的丢失;
|
||||
- 第 3 步:如果有多个副本,vnode 将把数据包转发给同一虚拟节点组内的 follower vnodes,该转发包带有数据的版本号(version);
|
||||
- 第 4 步:写入内存,并将记录加入到 skip list。但如果未达成一致,会触发回滚操作;
|
||||
|
@ -315,17 +315,17 @@ TDengine 采用了一种数据驱动的策略来实现缓存数据的持久化
|
|||
|
||||
每个数据文件块(以 .data 结尾)都配有一个索引文件(以 .head 结尾),该索引文件包含每张表的各个数据文件块的摘要信息,记录了每个数据文件块在数据文件中的偏移量、数据的起始时间和结束时间等信息,以便于快速定位所需数据。此外,每个数据文件块还有一个与之关联的 last 文件(以 .last 结尾),该文件旨在防止数据文件块在落盘时发生碎片化。如果某张表落盘的记录条数未达到数据库参数 minRows(每块最小记录条数)的要求,这些记录将首先存储在 last 文件中,待下次落盘时,新落盘的记录将与 last文件中的记录合并,然后再写入数据文件块。
|
||||
|
||||
在数据写入硬盘的过程中,是否对数据进行压缩取决于数据库参数 comp 的设置。TDengine 提供了 3 种压缩选项—无压缩、一级压缩和二级压缩,对应的 comp 值分别为 0、1 和 2。一级压缩会根据数据类型采用相应的压缩算法,如 delta-delta 编码、simple8B 方法、zig-zag 编码、LZ4 等。二级压缩则在一级压缩的基础上进一步使用通用压缩算法,以实现更高的压缩率。
|
||||
在数据写入硬盘的过程中,是否对数据进行压缩取决于数据库参数 comp 的设置。TDengine 提供了 3 种压缩选项—无压缩、一级压缩和二级压缩,对应的 comp 值分别为 0、1 和 2。一级压缩会根据数据类型采用相应的压缩算法,如 delta-delta 编码、simple8B 编码、zig-zag 编码、LZ4 等。二级压缩则在一级压缩的基础上进一步使用通用压缩算法,以实现更高的压缩率。
|
||||
|
||||
### 预计算
|
||||
|
||||
为了显著提高查询处理的效率,TDengine 在数据文件块的头部存储了该数据文件块的统计信息,包括最大值、最小值和数据总和,这些被称为预计算单元。当查询处理涉及这些计算结果时,可以直接利用这些预计算值,而无须访问数据文件块的具体内容。对于那些硬盘 I/O 成为瓶颈的查询场景,利用预计算结果可以有效减轻读取硬盘 I/O 的压力,从而提高查询速度。
|
||||
|
||||
除了预计算功能以外,TDengine 还支持对原始数据进行多种降采样存储。一种降采样存储方式是 Rollup SMA,它能够自动对原始数据进行降采样存储,并支持 3 个不同的数据保存层级,用户可以指定每层数据的聚合周期和保存时长。这对于那些关注数据趋势的场景尤为适用,其核心目的是减少存储开销并提高查询速度。另一种降采样存储方式是 Time-Range-Wise SMA,它可以根据聚合结果进行降采样存储,非常适合于高频的 interval 查询场景。该功能采用与普通流计算相同的逻辑,并允许用户通过设置watermark 来处理延时数据,相应地,实际的查询结果也会有一定的时间延迟。
|
||||
除了预计算功能以外,TDengine 还支持对原始数据进行多种降采样存储。一种降采样存储方式是 Rollup SMA,它能够自动对原始数据进行降采样存储,并支持 3 个不同的数据保存层级,用户可以指定每层数据的聚合周期和保存时长。这对于那些关注数据趋势的场景尤为适用,其核心目的是减少存储开销并提高查询速度。另一种降采样存储方式是 Time-Range-Wise SMA,它可以根据聚合结果进行降采样存储,非常适合于高频的 interval 查询场景。该功能采用与普通流计算相同的逻辑,并允许用户通过设置 watermark 来处理延时数据,相应地,实际的查询结果也会有一定的时间延迟。
|
||||
|
||||
### 多级存储与对象存储
|
||||
|
||||
说明:多级存储功能仅企业版支持,从 2.0.16.0 版本开始提供。
|
||||
说明:多级存储功能仅企业版支持。
|
||||
|
||||
在默认配置下,TDengine 会将所有数据保存在 /var/lib/taos 目录下,而且每个 vnode 的数据文件保存在该目录下的不同目录。为扩大存储空间,尽量减少文件读取的瓶颈,提高数据吞吐率 TDengine 可通过配置系统参数 dataDir 让多个挂载的硬盘被系统同时使用。
|
||||
|
||||
|
|
|
@ -30,13 +30,13 @@ Tuple 编码格式主要用于非稀疏数据的场景,如所有列数据全
|
|||
|
||||
Key-Value 编码格式特别适合于稀疏数据的场景,即在表的 schema 中定义了大量列(例如数千列),但实际有值的列却非常少的情况。在这种情形下,如果采用传统的 Tuple 编码格式,会造成极大的空间浪费。相比之下,采用 Key-Value 编码格式可以显著减少行数据所占用的存储空间。如下图所示。
|
||||
|
||||
Key-Value 编码的行数据通过一个 offset 数组来索引各列的值,虽然这种方式的访问速度相对于直接访问列数据较慢,但它能显著减少存储空间的占用。在实际编码实现中,通过引入 flag 选项,进一步优化了空间占用。具体来说,当所有 offset 值均小于 256 时,Key-Value 编码行的 offset 数组采用 uint8_t 类型;若所有 offset 值均小于 65 536 时,则使用 uint16_t 类型;在其他情况下,则使用 uint32_t 类型。这样的设计使得空间利用率得到进一步提升。
|
||||
Key-Value 编码的行数据通过一个 offset 数组来索引各列的值,虽然这种方式的访问速度相对于直接访问列数据较慢,但它能显著减少存储空间的占用。在实际编码实现中,通过引入 flag 选项,进一步优化了空间占用。具体来说,当所有 offset 值均小于 256 时,Key-Value 编码行的 offset 数组采用 uint8_t 类型;若所有 offset 值均小于 65536 时,则使用 uint16_t 类型;在其他情况下,则使用 uint32_t 类型。这样的设计使得空间利用率得到进一步提升。
|
||||
|
||||

|
||||
|
||||
### 列格式
|
||||
|
||||
在 TDengine 中,列格式的定长数据可以被视为数组,但由于存在 NONE、NULL和有值的并存情况,列格式中还需要一个 bitmap 来标识各个索引位置的值是 NONE、NULL 还是有值。而对于变长类型的数据,列格式则有所不同。除了数据数组以外,变长类型的数据列格式还包含一个 offset 数组,用于索引变长数据的起始位置。变长数据的长度可以通过两个相邻 offset 值之差来获得。这种设计使得数据的存储和访问更加高效,如下图所示:
|
||||
在 TDengine 中,列格式的定长数据可以被视为数组,但由于存在 NONE、NULL 和有值的并存情况,列格式中还需要一个 bitmap 来标识各个索引位置的值是 NONE、NULL 还是有值。而对于变长类型的数据,列格式则有所不同。除了数据数组以外,变长类型的数据列格式还包含一个 offset 数组,用于索引变长数据的起始位置。变长数据的长度可以通过两个相邻 offset 值之差来获得。这种设计使得数据的存储和访问更加高效,如下图所示:
|
||||
|
||||

|
||||
|
||||
|
@ -51,7 +51,7 @@ vnode 是 TDengine 中数据存储、查询以及备份的基本单元。每个
|
|||
|
||||

|
||||
|
||||
当 vnode 收到写入数据请求时,首先会对请求进行预处理,以确保多副本上的数据保持一致。预处理的目的在于确保数据的安全性和一致性。在预处理完成后,数据会被写入到 WAL 文件中,以确保数据的持久性。接着,数据会被写入 vnode 的内存池中。当内存池的空间占用达到一定阈值时,后台线程会将写入的数据刷新到硬盘上(META 和TSDB),以便持久化。同时,标记内存中对应的 WAL 编号为已落盘。此外,TSDB 采用了 LSM(Log-Structured Merge-Tree,日志结构合并树)存储结构,这种结构在打开数据库的多表低频参数时,后台还会对 TSDB 的数据文件进行合并,以减少文件数量并提高查询性能。这种设计使得数据的存储和访问更加高效。
|
||||
当 vnode 收到写入数据请求时,首先会对请求进行预处理,以确保多副本上的数据保持一致。预处理的目的在于确保数据的安全性和一致性。在预处理完成后,数据会被写入到 WAL 文件中,以确保数据的持久性。接着,数据会被写入 vnode 的内存池中。当内存池的空间占用达到一定阈值时,后台线程会将写入的数据刷新到硬盘上(META 和 TSDB),以便持久化。同时,标记内存中对应的 WAL 编号为已落盘。此外,TSDB 采用了 LSM(Log-Structured Merge-Tree,日志结构合并树)存储结构,这种结构在打开数据库的多表低频参数时,后台还会对 TSDB 的数据文件进行合并,以减少文件数量并提高查询性能。这种设计使得数据的存储和访问更加高效。
|
||||
|
||||
### 元数据的存储
|
||||
|
||||
|
@ -60,7 +60,7 @@ vnode 中存储的元数据主要涉及表的元数据信息,包括超级表
|
|||
|
||||

|
||||
|
||||
当 META 模块接收到元数据写入请求时,它会生成多个 Key-Value 数据对,并将这些数据对存储在底层的 TDB 存储引擎中。TDB 是 TDengine 根据自身需求研发的 B+Tree存储引擎,它由 3 个主要部分组成——内置 Cache、TDB 存储主文件和 TDB 的日志文件。数据在写入 TDB 时,首先被写入内置 Cache,如果 Cache 内存不足,系统会向 vnode的内存池请求额外的内存分配。如果写入操作涉及已有数据页的更改,系统会在修改数据页之前,先将未更改的数据页写入 TDB 的日志文件,作为备份。这样做可以在断电或其他故障发生时,通过日志文件回滚到原始数据,确保数据更新的原子性和数据完整性。
|
||||
当 META 模块接收到元数据写入请求时,它会生成多个 Key-Value 数据对,并将这些数据对存储在底层的 TDB 存储引擎中。TDB 是 TDengine 根据自身需求研发的 B+Tree 存储引擎,它由 3 个主要部分组成——内置 Cache、TDB 存储主文件和 TDB 的日志文件。数据在写入 TDB 时,首先被写入内置 Cache,如果 Cache 内存不足,系统会向 vnode 的内存池请求额外的内存分配。如果写入操作涉及已有数据页的更改,系统会在修改数据页之前,先将未更改的数据页写入 TDB 的日志文件,作为备份。这样做可以在断电或其他故障发生时,通过日志文件回滚到原始数据,确保数据更新的原子性和数据完整性。
|
||||
|
||||
由于 vnode 存储了各种元数据信息,并且元数据的查询需求多样化,vnode 内部会创建多个 B+Tree,用于存储不同维度的索引信息。这些 B+Tree 都存储在一个共享的存储文件中,并通过一个根页编号为 1 的索引 B+Tree 来索引各个 B+Tree 的根页编号,如下图所示:
|
||||
|
||||
|
@ -80,9 +80,9 @@ B+ Tree 的页结构如下图所示:
|
|||
|
||||
在 MemTable 中,数据采用了 Red-Black Tree(红黑树)和 SkipList 相结合的索引方式。不同表的数据索引存储在 Red-Black Tree 中,而同一张表的数据索引则存储在SkipList 中。这种设计方式充分利用了时序数据的特点,提高了数据的存储和访问效率。
|
||||
|
||||
Red-Black Tree 是一种自平衡的二叉树,它通过对节点进行着色和旋转操作来保持树的平衡,从而确保了查询、插入和删除操作的时间复杂度为 O(log n)。在 MemTable 中,Red-Black Tree 用于存储不同表
|
||||
Red-Black Tree 是一种自平衡的二叉树,它通过对节点进行着色和旋转操作来保持树的平衡,从而确保了查询、插入和删除操作的时间复杂度为 O(logn)。在 MemTable 中,Red-Black Tree 用于存储不同表
|
||||
|
||||
SkipList 是一种基于有序链表的数据结构,它通过在链表的基础上添加多级索引来实现快速查找。SkipList 的查询、插入和删除操作的时间复杂度为 O(log n),与 Red-Black Tree 相当。在 MemTable 中,SkipList 用于存储同一张表的数据索引,这样可以快速定位到特定时间范围内的数据,为时序数据的查询和写入提供高效支持。
|
||||
SkipList 是一种基于有序链表的数据结构,它通过在链表的基础上添加多级索引来实现快速查找。SkipList 的查询、插入和删除操作的时间复杂度为 O(logn),与 Red-Black Tree 相当。在 MemTable 中,SkipList 用于存储同一张表的数据索引,这样可以快速定位到特定时间范围内的数据,为时序数据的查询和写入提供高效支持。
|
||||
|
||||
通过将 Red-Black Tree 和 SkipList 相结合,TDengine 在 MemTable 中实现了一种高效的数据索引方式,既能够快速定位到不同表的数据,又能够快速定位到同一张表中特定时间范围内的数据。SkipList 索引如下图所示:
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ title: 查询引擎
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
TDengine 作为一个高性能的时序大数据平台,其查询与计算功能是核心组件之一。该平台提供了丰富的查询处理功能,不仅包括常规的聚合查询,还涵盖了时序数据的窗口查询、统计聚合等高级功能。这些查询计算任务需要 taosc、vnode、qnode 和 mnode 之间的紧密协作。在一个复杂的超级表聚合查询场景中,可能需要多个 vnode 和 qnode 共同承担查询和计算的职责。关于 vnode、qnode、mnode 的定义和介绍,请参考[系统架构](../arch)
|
||||
TDengine 作为一个高性能的时序大数据平台,其查询与计算功能是核心组件之一。该平台提供了丰富的查询处理功能,不仅包括常规的聚合查询,还涵盖了时序数据的窗口查询、统计聚合等高级功能。这些查询计算任务需要 taosc、vnode、qnode 和 mnode 之间的紧密协作。在一个复杂的超级表聚合查询场景中,可能需要多个 vnode 和 qnode 共同承担查询和计算的职责。关于 vnode、qnode、mnode 的定义和介绍,请参考 [系统架构](../arch)
|
||||
|
||||
## 各模块在查询计算中的职责
|
||||
|
||||
|
@ -87,14 +87,14 @@ TDengine 为了解决实际应用中对不同数据采集点数据进行高效
|
|||

|
||||
|
||||
具体步骤说明如下。
|
||||
第 1 步,taosc 从 mnode 获取库和表的元数据信息。
|
||||
第 2 步,mnode 返回请求的元数据信息。
|
||||
第 3 步,taosc 向超级表所属的每个 vnode 发送查询请求。
|
||||
第 4 步,vnode 启动本地查询,在获得查询结果后返回查询响应。
|
||||
第 5 步,taosc 向聚合节点(在本例中为 qnode)发送查询请求。
|
||||
第 6 步,qnode 向每个 vnode 节点发送数据请求消息来拉取数据。
|
||||
第 7 步,vnode 返回本节点的查询计算结果。
|
||||
第 8 步,qnode 完成多节点数据聚合后将最终查询结果返回给客户端。
|
||||
- 第 1 步,taosc 从 mnode 获取库和表的元数据信息。
|
||||
- 第 2 步,mnode 返回请求的元数据信息。
|
||||
- 第 3 步,taosc 向超级表所属的每个 vnode 发送查询请求。
|
||||
- 第 4 步,vnode 启动本地查询,在获得查询结果后返回查询响应。
|
||||
- 第 5 步,taosc 向聚合节点(在本例中为 qnode)发送查询请求。
|
||||
- 第 6 步,qnode 向每个 vnode 节点发送数据请求消息来拉取数据。
|
||||
- 第 7 步,vnode 返回本节点的查询计算结果。
|
||||
- 第 8 步,qnode 完成多节点数据聚合后将最终查询结果返回给客户端。
|
||||
|
||||
TDengine 为了提升聚合计算速度,在 vnode 内实现了标签数据与时序数据的分离存储。首先,系统会在内存中过滤标签数据,以确定需要参与聚合操作的表的集合。这样做可以显著减少需要扫描的数据集,从而大幅提高聚合计算的速度。
|
||||
|
||||
|
@ -127,6 +127,6 @@ TDengine 针对不同类型的缓存对象采用了相应的缓存管理策略
|
|||

|
||||
|
||||
- 元数据缓存(meta data):包括数据库、超级表、用户、节点、视图、虚拟节点等信息,以及表的 schema 和其所在虚拟节点的映射关系。通过在 taosc 缓存元数据可以避免频繁地向 mnode/vnode 请求元数据。taosc 对元数据的缓存采用固定大小的缓存空间,先到先得,直到缓存空间用完。当缓存空间用完时,缓存会被进行部分淘汰处理,用来缓存新进请求所需要的元数据。
|
||||
- 时序数据缓存(time series data):时序数据首先被缓存在 vnode 的内存中,以SkipList 形式组织,当达到落盘条件后,将时序数据进行压缩,写入数据存储文件
|
||||
- 时序数据缓存(time series data):时序数据首先被缓存在 vnode 的内存中,以 skipList 形式组织,当达到落盘条件后,将时序数据进行压缩,写入数据存储文件
|
||||
中,并从缓存中清除。
|
||||
- 最新数据缓存(last/last_row):对时序数据中的最新数据进行缓存,可以提高最新数据的查询效率。最新数据以子表为单元组织成 KV 形式,其中,K 是子表 ID,V 是该子表中每列的最后一个非 NULL 以及最新的一行数据。
|
|
@ -34,7 +34,7 @@ TDengine 会为 WAL 文件自动创建索引以支持快速随机访问。通过
|
|||
|
||||
### 消费组
|
||||
|
||||
在创建消费者时,需要为其指定一个消费组。同一消费组内的消费者将共享消费进度,确保数据在消费者之间均匀分配。正如前面所述,一个主题的数据会被分布在多个vnode 中。为了提高消费速度和实现多线程、分布式地消费数据,可以在同一消费组中添加多个消费者。这些消费者首先会均分 vnode,然后分别对分配给自己的 vnode 进行消费。例如,假设数据分布在 4 个 vnode 上:
|
||||
在创建消费者时,需要为其指定一个消费组。同一消费组内的消费者将共享消费进度,确保数据在消费者之间均匀分配。正如前面所述,一个主题的数据会被分布在多个 vnode 中。为了提高消费速度和实现多线程、分布式地消费数据,可以在同一消费组中添加多个消费者。这些消费者首先会均分 vnode,然后分别对分配给自己的 vnode 进行消费。例如,假设数据分布在 4 个 vnode 上:
|
||||
- 当有 2 个消费者时,每个消费者将消费 2 个 vnode;
|
||||
- 当有 3 个消费者时,其中 2 个消费者各消费 1 个 vnode,而剩下的 1 个消费者将消费剩余的 2 个 vnode;
|
||||
- 当有 5 个消费者时,其中 4 个消费者各分配 1 个 vnode,而剩下的 1 个消费者则不参与消费。
|
||||
|
@ -81,7 +81,7 @@ mnode 主要负责处理订阅过程中的控制消息,包括创建和删除
|
|||
|
||||

|
||||
|
||||
再平衡计时器每 2s 检测一次是否需要再平衡。在再平衡过程中,如果消费者获取的状态是 not ready,则不能进行消费。只有再平衡正常结束后,消费者获取分配 vnode 的offset 后才可正常消费,否则消费者会重试指定次数后报错。
|
||||
再平衡计时器每 2s 检测一次是否需要再平衡。在再平衡过程中,如果消费者获取的状态是 not ready,则不能进行消费。只有再平衡正常结束后,消费者获取分配 vnode 的 offset 后才可正常消费,否则消费者会重试指定次数后报错。
|
||||
|
||||
## 消费者状态处理
|
||||
|
||||
|
|
|
@ -13,8 +13,7 @@ TDengine 流计算的架构如下图所示。当用户输入用于创建流的 S
|
|||
mnode 包含与流计算相关的如下 4 个逻辑模块。
|
||||
- 任务调度,负责将逻辑执行计划转化为物理执行计划,并下发到每个 vnode。
|
||||
- meta store,负责存储流计算任务的元数据信息以及流任务相应的 DAG 信息。
|
||||
- 检查点调度,负责定期生成检查点(checkpoint)事务,并下发到各 source task(源
|
||||
任务)。
|
||||
- 检查点调度,负责定期生成检查点(checkpoint)事务,并下发到各 source task(源任务)。
|
||||
- exec 监控,负责接收上报的心跳、更新 mnode 中各任务的执行状态,以及定期监控检查点执行状态和 DAG 变动信息。
|
||||
|
||||
此外,mnode 还承担着向流计算任务下发控制命令的重要角色,这些命令包括但不限于暂停、恢复执行、删除流任务及更新流任务的上下游信息等。
|
||||
|
@ -67,7 +66,7 @@ TDengine 的流计算功能允许根据记录的事件时间将数据划分到
|
|||
|
||||

|
||||
|
||||
按照流任务承担任务的不同,可将其划分为 3 个类别—source task(源任务)、agg task(聚合任务)和 sink task(写回任务)。
|
||||
按照流任务承担任务的不同,可将其划分为 3 个类别:source task(源任务)、agg task(聚合任务)和 sink task(写回任务)。
|
||||
|
||||
### source task
|
||||
|
||||
|
@ -75,7 +74,7 @@ TDengine 的流计算功能允许根据记录的事件时间将数据划分到
|
|||
|
||||
### agg task
|
||||
|
||||
source task 的下游任务是接收源任务聚合后的结果,并对这些结果进行进一步的汇总以生成最终输出。在集群中配置 snode 的情况下,agg task 会被优先安排在 snode 上执行,以利用其存储和处理能力。如果集群中没有 snode,mnode 则会随机选择一个vnode,在该 vnode 上调度执行 agg task。值得注意的是,agg task 并非在所有情况下都是必需的。对于那些不涉及窗口聚合的流计算场景(例如,仅包含标量运算的流计算,或者在数据库只有一个 vnode 时的聚合流计算),就不会出现 agg task。在这种情况下,流计算的拓扑结构将简化为仅包含两级流计算任务,即 source task 和直接输出结果的下游任务。
|
||||
source task 的下游任务是接收源任务聚合后的结果,并对这些结果进行进一步的汇总以生成最终输出。在集群中配置 snode 的情况下,agg task 会被优先安排在 snode 上执行,以利用其存储和处理能力。如果集群中没有 snode,mnode 则会随机选择一个 vnode,在该 vnode 上调度执行 agg task。值得注意的是,agg task 并非在所有情况下都是必需的。对于那些不涉及窗口聚合的流计算场景(例如,仅包含标量运算的流计算,或者在数据库只有一个 vnode 时的聚合流计算),就不会出现 agg task。在这种情况下,流计算的拓扑结构将简化为仅包含两级流计算任务,即 source task 和直接输出结果的下游任务。
|
||||
|
||||
### sink task
|
||||
|
||||
|
|
|
@ -11,16 +11,16 @@ TDengine 通过日志文件记录系统运行状态,帮助用户监控系统
|
|||
### 普通日志实现逻辑
|
||||
|
||||
- 普通日志分同步和异步两种方式,同步立即写入日志文件,异步写入到 buff 里,然后定时写入日志文件。
|
||||
- 异步方式日志文件缓存在循环 buff 里, buff 的大小为 buffSize = 20 M。如果某次写buf 的日志大小大于buf 可用空间,本次日志会舍弃,日志里记录: ...Lost N lines here...
|
||||
- 异步方式日志文件缓存在循环 buff 里, buff 的大小为 buffSize = 20M。如果某次写 buf 的日志大小大于buf 可用空间,本次日志会舍弃,日志里记录: ...Lost N lines here...
|
||||

|
||||
- 异步线程里每隔 1 s 会更新磁盘信息用于判断是否有空间写日志
|
||||
- 异步线程里每隔 1s 会更新磁盘信息用于判断是否有空间写日志
|
||||
- 异步线程每隔 Interval 时间处理一次写入逻辑。写入规则如下:
|
||||
- 如果buff 里数据小于 buffSize/10,不写入磁盘,除非超过1 s。
|
||||
- 如果buff 里数据大于 buffSize/10,全部写入磁盘。
|
||||
- 如果 buff 里数据小于 buffSize/10,不写入磁盘,除非超过 1s。
|
||||
- 如果 buff 里数据大于 buffSize/10,全部写入磁盘。
|
||||
- Interval 默认值为 25 ms,Interval 值会根据每次写入日志的大小动态调整。Interval 调试规则如下:
|
||||
- 数据量小时(小于 buffSize/10),增大写入间隔,Interval 每次增加 5ms,最大25ms。
|
||||
- 数据量小时(小于 buffSize/10),增大写入间隔,Interval 每次增加 5ms,最大 25ms。
|
||||
- 数据量大时(大于 buffSize/3),写入间隔最小,Interval 为 5ms。
|
||||
- 数据量比较大时(大于 buffSize/4,小于等于buffSize/3),减小写入间隔,Interval 每次减小 5ms,最小5ms。
|
||||
- 数据量比较大时(大于 buffSize/4,小于等于buffSize/3),减小写入间隔,Interval 每次减小 5ms,最小 5ms。
|
||||
- 数据量适中时(大于等于 buffSize/10,小于等于buffSize/4),写入间隔不变。
|
||||

|
||||
|
||||
|
@ -57,7 +57,7 @@ TDengine 通过日志文件记录系统运行状态,帮助用户监控系统
|
|||
- 因为客户端进程里可能存在很多个链接 connection,所以需要将慢查询日志根据 clusterId 来分组。分组方式通过临时文件名来实现,命名方式为 ```{tmp dir}/tdengine_slow_log/tdengeine-{clusterId1}-{processId}-{rand}```,processId 为进程ID,主要为了区分多个客户端的上报。
|
||||
- 如上图 connection 1 连接的是 cluster 1。connection 2,connection 3 连接的是 cluster 2,所以connection 1 的慢 sql 数据写入文件 ```{tmp dir}/tdengine_slow_log/tdengeine-{clusterId1}-{processId}-{rand}```,connection 2 和 connection 3的慢 sql 数据写入文件 ```{tmp dir}/tdengine_slow_log/tdengeine-{clusterId1}-{processId}-{rand}```
|
||||
#### 上报逻辑
|
||||
- 读取 ```{tmp dir}/tdengine_slow_log/tdengeine-{clusterId1}-{processId}-{rand}``` 临时文件内容,每行数据作为 json 数组的一个元素,组装成 json 数组上报(文件里数据每接近 1M大小上报一次,上报成功后记录读取文件进度,上报采用异步上报方式。在 callback 里继续根据上次的进度,继续读取文件的内容上报,直至整个文件读取上报完毕,上报完毕后,会清空临时文件,callback 里成功或失败都会继续读取文件,失败时会记录上报失败的数据日志)。每接近 1M 上报一次主要为了防止文件太大,放在一次上报失败)。
|
||||
- 读取 ```{tmp dir}/tdengine_slow_log/tdengeine-{clusterId1}-{processId}-{rand}``` 临时文件内容,每行数据作为 json 数组的一个元素,组装成 json 数组上报(文件里数据每接近 1M 大小上报一次,上报成功后记录读取文件进度,上报采用异步上报方式。在 callback 里继续根据上次的进度,继续读取文件的内容上报,直至整个文件读取上报完毕,上报完毕后,会清空临时文件,callback 里成功或失败都会继续读取文件,失败时会记录上报失败的数据日志)。每接近 1M 上报一次主要为了防止文件太大,放在一次上报失败)。
|
||||
#### 上报时机
|
||||
- 客户端运行过程中定时上报
|
||||
- 每个 monitorInterval 时间间隔上报数据。
|
||||
|
@ -67,19 +67,19 @@ TDengine 通过日志文件记录系统运行状态,帮助用户监控系统
|
|||
- 异常退出后再次与某个集群(clusterId)建立新的链接后遍历 ```{tmp dir}/tdengine_slow_log/``` 目录下 ```tdengine-{clusterId}``` 开头的所有文件进行重新上报(这些文件可能是另一个客户端进程或本进程正在操作的。所以每个文件打开时都需要添加文件锁),然后删除这个临时文件。
|
||||
#### 一些异常行为说明
|
||||
- 因为上报数据和删除文件里的上报内容没法作为一个原子操作,所以如果上报后还没删除数据就 crash,可能导致下次重复上报,重复上报的数据会覆盖,并没丢失,影响很小。
|
||||
- 另外为了保证性能, slow log thread 线程把慢 sql 日志写入临时文件缓存,只保证刷新到操作系统的磁盘缓冲区,并不真正每次都 fsync 到磁盘,所以如果机器断电,仍可能丢失数据。该异常出现概率很小,可以容忍此种情况下的数据丢失。
|
||||
- 另外为了保证性能,slow log thread 线程把慢 sql 日志写入临时文件缓存,只保证刷新到操作系统的磁盘缓冲区,并不真正每次都 fsync 到磁盘,所以如果机器断电,仍可能丢失数据。该异常出现概率很小,可以容忍此种情况下的数据丢失。
|
||||
### 慢日志行为说明
|
||||
- 慢日志一方面会记录到本地慢日志文件中,另一方面会通过 taosAdapter 发送到 taosKeeper 进行结构化存储(需打开 monitorr 开关)。
|
||||
- 慢日志一方面会记录到本地慢日志文件中,另一方面会通过 taosAdapter 发送到 taosKeeper 进行结构化存储(需打开 monitor 开关)。
|
||||
- 慢日志文件存储规则为:
|
||||
- 慢日志文件一天一个,如果当天没有慢日志,没有当天的文件。
|
||||
- 文件名为 taosSlowLog.yyyy-mm-dd(taosSlowLog.2024-08-02),日志存储路径通过 logDir 配置。
|
||||
- 多个客户端的日志存储在相应日志路径下的同一个 taosSlowLog.yyyy.mm.dd 文件里。
|
||||
- 慢日志文件不自动删除,不压缩。
|
||||
- 使用和普通日志文件相同的三个参数 logDir, minimalLogDirGB, asyncLog。另外两个参数 numOfLogLines,logKeepDays 不适用于慢日志。
|
||||
- 使用和普通日志文件相同的三个参数 logDir、minimalLogDirGB、asyncLog。另外两个参数 numOfLogLines、logKeepDays 不适用于慢日志。
|
||||
|
||||
## 日志级别说明
|
||||
|
||||
日志级别分为9种,如下所示:
|
||||
日志级别分为 9 种,如下所示:
|
||||
|
||||
```c
|
||||
typedef enum {
|
||||
|
@ -102,6 +102,6 @@ typedef enum {
|
|||
例如:
|
||||
- 131 = 128 + 2 + 1 文件 + info + error
|
||||
- 135 = 128 + 4 + 2 + 1 文件 + debug + info + error
|
||||
- 143 = 128 + 8 + 4 + 2 + 1 文件 + trace + debug + info + error
|
||||
- 143 = 128 + 8 + 4 + 2 + 1 文件 + trace + debug + info + error
|
||||
|
||||
通过设置日志开关的参数,可以开启不同级别的日志。
|
||||
|
|
|
@ -7,20 +7,20 @@ description: 一些常见问题的解决方法汇总
|
|||
|
||||
如果 FAQ 中的信息不能够帮到您,需要 TDengine 技术团队的技术支持与协助,请将以下两个目录中内容打包:
|
||||
|
||||
1. /var/log/taos (如果没有修改过默认路径)
|
||||
2. /etc/taos(如果没有指定其他配置文件路径)
|
||||
1. `/var/log/taos` (如果没有修改过默认路径)
|
||||
2. `/etc/taos` (如果没有指定其他配置文件路径)
|
||||
|
||||
附上必要的问题描述,包括使用的 TDengine 版本信息、平台环境信息、发生该问题的执行操作、出现问题的表征及大概的时间,在 [GitHub](https://github.com/taosdata/TDengine) 提交 issue。
|
||||
|
||||
为了保证有足够的 debug 信息,如果问题能够重复,请修改/etc/taos/taos.cfg 文件,最后面添加一行“debugFlag 135"(不带引号本身),然后重启 taosd, 重复问题,然后再递交。也可以通过如下 SQL 语句,临时设置 taosd 的日志级别。
|
||||
为了保证有足够的 debug 信息,如果问题能够重复,请修改 `/etc/taos/taos.cfg` 文件,最后面添加一行 `debugFlag 135`,然后重启 taosd, 重复问题,然后再递交。也可以通过如下 SQL 语句,临时设置 taosd 的日志级别。
|
||||
|
||||
```
|
||||
alter dnode <dnode_id> 'debugFlag' '135';
|
||||
```
|
||||
|
||||
其中 dnode_id 请从 show dnodes; 命令输出中获取。
|
||||
其中 dnode_id 请从 `show dnodes` 命令输出中获取。
|
||||
|
||||
但系统正常运行时,请一定将 debugFlag 设置为 131,否则会产生大量的日志信息,降低系统效率。
|
||||
但系统正常运行时,请一定将 debugFlag 设置为 `131`,否则会产生大量的日志信息,降低系统效率。
|
||||
|
||||
## 常见问题列表
|
||||
|
||||
|
@ -31,7 +31,7 @@ description: 一些常见问题的解决方法汇总
|
|||
1. 删除配置文件,执行 `sudo rm -rf /etc/taos/taos.cfg`
|
||||
2. 删除日志文件,执行 `sudo rm -rf /var/log/taos/`
|
||||
3. 确保数据已经不再需要的前提下,删除数据文件,执行 `sudo rm -rf /var/lib/taos/`
|
||||
4. 安装最新3.0稳定版本的 TDengine
|
||||
4. 安装最新 3.0 稳定版本的 TDengine
|
||||
5. 如果需要迁移数据或者数据文件损坏,请联系涛思数据官方技术支持团队,进行协助解决
|
||||
|
||||
### 2. Windows 平台下 JDBCDriver 找不到动态链接库,怎么办?
|
||||
|
@ -49,24 +49,24 @@ description: 一些常见问题的解决方法汇总
|
|||
1. 检查网络环境
|
||||
|
||||
- 云服务器:检查云服务器的安全组是否打开 TCP/UDP 端口 6030/6041 的访问权限
|
||||
- 本地虚拟机:检查网络能否 ping 通,尽量避免使用`localhost` 作为 hostname
|
||||
- 本地虚拟机:检查网络能否 ping 通,尽量避免使用 `localhost` 作为 hostname
|
||||
- 公司服务器:如果为 NAT 网络环境,请务必检查服务器能否将消息返回值客户端
|
||||
|
||||
2. 确保客户端与服务端版本号是完全一致的,开源社区版和企业版也不能混用
|
||||
|
||||
3. 在服务器,执行 `systemctl status taosd` 检查*taosd*运行状态。如果没有运行,启动*taosd*
|
||||
3. 在服务器,执行 `systemctl status taosd` 检查 *taosd* 运行状态。如果没有运行,启动 *taosd*
|
||||
|
||||
4. 确认客户端连接时指定了正确的服务器 FQDN (Fully Qualified Domain Name —— 可在服务器上执行 Linux/macOS 命令 hostname -f 获得),FQDN 配置参考:[一篇文章说清楚 TDengine 的 FQDN](https://www.taosdata.com/blog/2020/09/11/1824.html)。
|
||||
4. 确认客户端连接时指定了正确的服务器 FQDN (Fully Qualified Domain Name —— 可在服务器上执行 Linux/macOS 命令 `hostname -f` 获得),FQDN 配置参考 [一篇文章说清楚 TDengine 的 FQDN](https://www.taosdata.com/blog/2020/09/11/1824.html)。
|
||||
|
||||
5. ping 服务器 FQDN,如果没有反应,请检查你的网络,DNS 设置,或客户端所在计算机的系统 hosts 文件。如果部署的是 TDengine 集群,客户端需要能 ping 通所有集群节点的 FQDN。
|
||||
|
||||
6. 检查防火墙设置(Ubuntu 使用 ufw status,CentOS 使用 firewall-cmd --list-port),确保集群中所有主机在端口 6030/6041 上的 TCP/UDP 协议能够互通。
|
||||
|
||||
7. 对于 Linux 上的 JDBC(ODBC, Python, Go 等接口类似)连接, 确保*libtaos.so*在目录*/usr/local/taos/driver*里, 并且*/usr/local/taos/driver*在系统库函数搜索路径*LD_LIBRARY_PATH*里
|
||||
7. 对于 Linux 上的 JDBC(ODBC、Python、Go 等接口类似)连接,确保 *libtaos.so* 在目录 */usr/local/taos/driver* 里,并且 */usr/local/taos/driver* 在系统库函数搜索路径 *LD_LIBRARY_PATH* 里
|
||||
|
||||
8. 对于 macOS 上的 JDBC(ODBC, Python, Go 等接口类似)连接, 确保*libtaos.dylib*在目录*/usr/local/lib*里, 并且*/usr/local/lib*在系统库函数搜索路径*LD_LIBRARY_PATH*里
|
||||
8. 对于 macOS 上的 JDBC(ODBC、Python、Go 等接口类似)连接,确保 *libtaos.dylib* 在目录 */usr/local/lib* 里,并且 */usr/local/lib* 在系统库函数搜索路径 *LD_LIBRARY_PATH* 里
|
||||
|
||||
9. 对于 Windows 上的 JDBC, ODBC, Python, Go 等连接,确保*C:\TDengine\driver\taos.dll*在你的系统库函数搜索目录里 (建议*taos.dll*放在目录 _C:\Windows\System32_)
|
||||
9. 对于 Windows 上的 JDBC、ODBC、Python、Go 等连接,确保 *C:\TDengine\driver\taos.dll* 在你的系统库函数搜索目录里 (建议 *taos.dll* 放在目录 _C:\Windows\System32_)
|
||||
|
||||
10. 如果仍不能排除连接故障
|
||||
|
||||
|
@ -75,7 +75,7 @@ description: 一些常见问题的解决方法汇总
|
|||
检查服务器侧 TCP 端口连接是否工作:`nc -l {port}`
|
||||
检查客户端侧 TCP 端口连接是否工作:`nc {hostIP} {port}`
|
||||
|
||||
- Windows 系统请使用 PowerShell 命令 Test-NetConnection -ComputerName \{fqdn} -Port \{port} 检测服务段端口是否访问
|
||||
- Windows 系统请使用 PowerShell 命令 `Test-NetConnection -ComputerName \{fqdn} -Port \{port}` 检测服务段端口是否访问
|
||||
|
||||
11. 也可以使用 taos 程序内嵌的网络连通检测功能,来验证服务器和客户端之间指定的端口连接是否通畅:[运维指南](../../operation)。
|
||||
|
||||
|
@ -88,7 +88,7 @@ description: 一些常见问题的解决方法汇总
|
|||
3. 如果网络没有配置 DNS server,请检查客户端所在机器的 hosts 文件,查看该 FQDN 是否配置,并是否有正确的 IP 地址
|
||||
4. 如果网络配置 OK,从客户端所在机器,你需要能 Ping 该连接的 FQDN,否则客户端是无法连接服务器的
|
||||
5. 如果服务器曾经使用过 TDengine,且更改过 hostname,建议检查 data 目录的 dnode.json 是否符合当前配置的 EP,路径默认为/var/lib/taos/dnode。正常情况下,建议更换新的数据目录或者备份后删除以前的数据目录,这样可以避免该问题。
|
||||
6. 检查/etc/hosts 和/etc/hostname 是否是预配置的 FQDN
|
||||
6. 检查 /etc/hosts 和/etc/hostname 是否是预配置的 FQDN
|
||||
|
||||
### 6. 最有效的写入数据的方法是什么?
|
||||
|
||||
|
@ -105,7 +105,7 @@ properties.setProperty(TSDBDriver.LOCALE_KEY, "UTF-8");
|
|||
Connection = DriverManager.getConnection(url, properties);
|
||||
```
|
||||
|
||||
### 8. Windows 系统下客户端无法正常显示中文字符?
|
||||
### 8. Windows 系统下客户端无法正常显示中文字符?
|
||||
|
||||
Windows 系统中一般是采用 GBK/GB18030 存储中文字符,而 TDengine 的默认字符集为 UTF-8 ,在 Windows 系统中使用 TDengine 客户端时,客户端驱动会将字符统一转换为 UTF-8 编码后发送到服务端存储,因此在应用开发过程中,调用接口时正确配置当前的中文字符集即可。
|
||||
|
||||
|
@ -124,7 +124,7 @@ charset UTF-8
|
|||
|
||||
TDengine 是根据 hostname 唯一标志一台机器的,对于3.0版本,将数据文件从机器 A 移动机器 B 时,需要重新配置机器 B 的 hostname 为机器 A 的 hostname。
|
||||
|
||||
注:3.x 和 之前的1.x、2.x 版本的存储结构不兼容,需要使用迁移工具或者自己开发应用导出导入数据。
|
||||
注:3.x 和 之前的 1.x、2.x 版本的存储结构不兼容,需要使用迁移工具或者自己开发应用导出导入数据。
|
||||
|
||||
### 11. 如何在命令行程序 taos 中临时调整日志级别
|
||||
|
||||
|
@ -145,11 +145,11 @@ local_option: {
|
|||
|
||||
其含义是,在当前的命令行程序下,清空本机所有客户端生成的日志文件(resetLog),或修改一个特定模块的日志记录级别(只对当前命令行程序有效,如果 taos 命令行程序重启,则需要重新设置):
|
||||
|
||||
- value 的取值可以是:131(输出错误和警告日志),135( 输出错误、警告和调试日志),143( 输出错误、警告、调试和跟踪日志)。
|
||||
- value 的取值可以是:131(输出错误和警告日志)、135( 输出错误、警告和调试日志)、143( 输出错误、警告、调试和跟踪日志)。
|
||||
|
||||
### 12. go 语言编写组件编译失败怎样解决?
|
||||
|
||||
TDengine 3.0版本包含一个使用 go 语言开发的 taosAdapter 独立组件,需要单独运行,提供restful接入功能以及支持多种其他软件(Prometheus、Telegraf、collectd、StatsD 等)的数据接入功能。
|
||||
TDengine 3.0 版本包含一个使用 go 语言开发的 taosAdapter 独立组件,需要单独运行,提供 restful 接入功能以及支持多种其他软件(Prometheus、Telegraf、collectd、StatsD 等)的数据接入功能。
|
||||
使用最新 develop 分支代码编译需要先 `git submodule update --init --recursive` 下载 taosAdapter 仓库代码后再编译。
|
||||
|
||||
go 语言版本要求 1.14 以上,如果发生 go 编译错误,往往是国内访问 go mod 问题,可以通过设置 go 环境变量来解决:
|
||||
|
@ -192,21 +192,21 @@ TDengine 中时间戳的时区总是由客户端进行处理,而与服务端
|
|||
|
||||
这个现象可能是因为 taosAdapter 没有被正确启动引起的,需要执行:```systemctl start taosadapter``` 命令来启动 taosAdapter 服务。
|
||||
|
||||
需要说明的是,taosAdapter 的日志路径 path 需要单独配置,默认路径是 /var/log/taos ;日志等级 logLevel 有 8 个等级,默认等级是 info ,配置成 panic 可关闭日志输出。请注意操作系统 / 目录的空间大小,可通过命令行参数、环境变量或配置文件来修改配置,默认配置文件是 /etc/taos/taosadapter.toml 。
|
||||
需要说明的是,taosAdapter 的日志路径 path 需要单独配置,默认路径是 /var/log/taos ;日志等级 logLevel 有 8 个等级,默认等级是 info ,配置成 panic 可关闭日志输出。请注意操作系统 `/` 目录的空间大小,可通过命令行参数、环境变量或配置文件来修改配置,默认配置文件是 /etc/taos/taosadapter.toml 。
|
||||
|
||||
有关 taosAdapter 组件的详细介绍请看文档:[taosAdapter](../../reference/components/taosadapter/)
|
||||
|
||||
### 18. 发生了 OOM 怎么办?
|
||||
|
||||
OOM 是操作系统的保护机制,当操作系统内存(包括 SWAP )不足时,会杀掉某些进程,从而保证操作系统的稳定运行。通常内存不足主要是如下两个原因导致,一是剩余内存小于 vm.min_free_kbytes ;二是程序请求的内存大于剩余内存。还有一种情况是内存充足但程序占用了特殊的内存地址,也会触发 OOM 。
|
||||
OOM 是操作系统的保护机制,当操作系统内存(包括 SWAP)不足时,会杀掉某些进程,从而保证操作系统的稳定运行。通常内存不足主要是如下两个原因导致,一是剩余内存小于 vm.min_free_kbytes;二是程序请求的内存大于剩余内存。还有一种情况是内存充足但程序占用了特殊的内存地址,也会触发 OOM。
|
||||
|
||||
TDengine 会预先为每个 VNode 分配好内存,每个 Database 的 VNode 个数受 建库时的vgroups参数影响,每个 VNode 占用的内存大小受 buffer参数 影响。要防止 OOM,需要在项目建设之初合理规划内存,并合理设置 SWAP ,除此之外查询过量的数据也有可能导致内存暴涨,这取决于具体的查询语句。TDengine 企业版对内存管理做了优化,采用了新的内存分配器,对稳定性有更高要求的用户可以考虑选择企业版。
|
||||
|
||||
### 19. 在macOS上遇到Too many open files怎么办?
|
||||
### 19. 在macOS上遇到 Too many open files 怎么办?
|
||||
|
||||
taosd日志文件报错Too many open file,是由于taosd打开文件数超过系统设置的上限所致。
|
||||
taosd 日志文件报错 Too many open file,是由于 taosd 打开文件数超过系统设置的上限所致。
|
||||
解决方案如下:
|
||||
1. 新建文件 /Library/LaunchDaemons/limit.maxfiles.plist,写入以下内容(以下示例将limit和maxfiles改为10万,可按需修改):
|
||||
1. 新建文件 /Library/LaunchDaemons/limit.maxfiles.plist,写入以下内容(以下示例将 limit 和 maxfiles 改为 10万,可按需修改):
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
|
||||
|
@ -235,7 +235,7 @@ taosd日志文件报错Too many open file,是由于taosd打开文件数超过
|
|||
sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
|
||||
sudo chmod 644 /Library/LaunchDaemons/limit.maxfiles.plist
|
||||
```
|
||||
3. 加载 plist 文件 (或重启系统后生效。launchd在启动时会自动加载该目录的 plist)
|
||||
3. 加载 plist 文件 (或重启系统后生效。launchd 在启动时会自动加载该目录的 plist)
|
||||
```
|
||||
sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
|
||||
```
|
||||
|
@ -247,29 +247,29 @@ launchctl limit maxfiles
|
|||
该提示是创建 db 的 vnode 数量不够了,需要的 vnode 不能超过了 dnode 中 vnode 的上限。因为系统默认是一个 dnode 中有 CPU 核数两倍的 vnode,也可以通过配置文件中的参数 supportVnodes 控制。
|
||||
正常调大 taos.cfg 中 supportVnodes 参数即可。
|
||||
|
||||
### 21 在服务器上的使用 TDengine CLI能查到指定时间段的数据,但在客户端机器上查不到?
|
||||
### 21 在服务器上的使用 TDengine CLI 能查到指定时间段的数据,但在客户端机器上查不到?
|
||||
这种情况是因为客户端与服务器上设置的时区不一致导致的,调整客户端与服务器的时区一致即可解决。
|
||||
|
||||
### 22 表名确认是存在的,但在写入或查询时返回表名不存在,什么原因?
|
||||
TDengine 中的所有名称,包括数据库名、表名等都是区分大小写的,如果这些名称在程序或 TDengine CLI中没有使用反引号(`)括起来使用,即使你输入的是大写的,引擎也会转化成小写来使用,如果名称前后加上了反引号,引擎就不会再转化成小写,会保持原样来使用。
|
||||
TDengine 中的所有名称,包括数据库名、表名等都是区分大小写的,如果这些名称在程序或 TDengine CLI 中没有使用反引号(`)括起来使用,即使你输入的是大写的,引擎也会转化成小写来使用,如果名称前后加上了反引号,引擎就不会再转化成小写,会保持原样来使用。
|
||||
|
||||
### 23 在 TDengine CLI中查询,字段内容不能完全显示出来怎么办?
|
||||
可以使用 \G 参数来竖式显示,如 show databases\G; (为了输入方便,在"\"后加 TAB 键,会自动补全后面的内容)
|
||||
可以使用 `\G` 参数来竖式显示,如 `show databases\G;` (为了输入方便,在"\"后加 TAB 键,会自动补全后面的内容)
|
||||
|
||||
### 24 使用 taosBenchmark 测试工具写入数据查询很快,为什么我写入的数据查询非常慢?
|
||||
TDengine 在写入数据时如果有很严重的乱序写入问题,会严重影响查询性能,所以需要在写入前解决乱序的问题。如果业务是从 kafka 消费写入,请合理设计消费者,尽可能的一个子表数据由一个消费者去消费并写入,避免由设计产生的乱序。
|
||||
TDengine 在写入数据时如果有很严重的乱序写入问题,会严重影响查询性能,所以需要在写入前解决乱序的问题。如果业务是从 Kafka 消费写入,请合理设计消费者,尽可能的一个子表数据由一个消费者去消费并写入,避免由设计产生的乱序。
|
||||
|
||||
### 25 我想统计下前后两条写入记录之间的时间差值是多少?
|
||||
使用 DIFF 函数,可以查看时间列或数值列前后两条记录的差值,非常方便,详细说明见 SQL手册->函数->DIFF
|
||||
使用 DIFF 函数,可以查看时间列或数值列前后两条记录的差值,非常方便,详细说明见 SQL 手册->函数->DIFF
|
||||
|
||||
### 26 遇到报错 “DND ERROR Version not compatible,cliver : 3000700swr wer : 3020300”
|
||||
说明客户端和服务端版本不兼容,这里cliver的版本是3.0.7.0,server版本是 3.2.3.0。目前的兼容策略是前三位一致,client 和 sever才能兼容。
|
||||
### 26 遇到报错 “DND ERROR Version not compatible, client: 3000700, server: 3020300”
|
||||
说明客户端和服务端版本不兼容,这里 client 的版本是 3.0.7.0,server 版本是 3.2.3.0。目前的兼容策略是前三位一致,client 和 sever 才能兼容。
|
||||
|
||||
### 27 修改database的root密码后,启动taos遇到报错 “failed to connect to server, reason: Authentication failure”
|
||||
默认情况,启动taos服务会使用系统默认的用户名(root)和密码尝试连接taosd,在root密码修改后,启用taos连接就需要指明用户名和密码,例如: taos -h xxx.xxx.xxx.xxx -u root -p,然后输入新密码进行连接。
|
||||
### 27 修改 database 的 root 密码后,启动 taos 遇到报错 “failed to connect to server, reason: Authentication failure”
|
||||
默认情况,启动taos服务会使用系统默认的用户名(root)和密码尝试连接 taosd,在 root 密码修改后,启用 taos 连接就需要指明用户名和密码,例如 `taos -h xxx.xxx.xxx.xxx -u root -p`,然后输入新密码进行连接。
|
||||
|
||||
### 28 修改database的root密码后,Grafana监控插件TDinsight无数据展示
|
||||
TDinsight插件中展示的数据是通过taosKeeper和taosAdapter服务收集并存储于TD的log库中,在root密码修改后,需要同步更新taosKeeper和taosAdapter配置文件中对应的密码信息,然后重启taosKeeper和taosAdapter服务(注:若是集群需要重启每个节点上的对应服务)。
|
||||
### 28 修改 database 的 root 密码后,Grafana 监控插件 TDinsight 无数据展示
|
||||
TDinsight 插件中展示的数据是通过 taosKeeper 和 taosAdapter 服务收集并存储于 TD 的 log 库中,在 root 密码修改后,需要同步更新 taosKeeper 和 taosAdapter 配置文件中对应的密码信息,然后重启 taosKeeper 和 taosAdapter 服务(注:若是集群需要重启每个节点上的对应服务)。
|
||||
|
||||
### 29 遇到报错 “some vnode/qnode/mnode(s) out of service” 怎么办?
|
||||
客户端未配置所有服务端的 FQDN 解析。比如服务端有 3 个节点,客户端只配置了 1 个节点的 FQDN 解析。FQDN 配置参考:[一篇文章说清楚 TDengine 的 FQDN](https://www.taosdata.com/blog/2020/09/11/1824.html)
|
||||
|
@ -277,21 +277,21 @@ TDinsight插件中展示的数据是通过taosKeeper和taosAdapter服务收集
|
|||
### 30 为什么开源版 TDengine 的主进程会建立一个与公网的连接?
|
||||
这个连接只会上报不涉及任何用户数据的最基本信息,用于官方了解产品在世界范围内的分布情况,进而优化产品,提升用户体验,具体采集项目为:集群名、操作系统版本、cpu信息等。
|
||||
|
||||
该特性为可选配置项,在开源版中默认开启,具体参数为 telemetryReporting , 在官方文档中有做说明,链接如下:[参数简介](https://docs.taosdata.com/reference/components/taosd/#%E7%9B%91%E6%8E%A7%E7%9B%B8%E5%85%B3)
|
||||
该特性为可选配置项,在开源版中默认开启,具体参数为 telemetryReporting,在官方文档中有做说明,链接如下:[参数简介](https://docs.taosdata.com/reference/components/taosd/#%E7%9B%91%E6%8E%A7%E7%9B%B8%E5%85%B3)
|
||||
|
||||
您可以随时关闭该参数,只需要在taos.cfg 中修改telemetryReporting为 0,然后重启数据库服务即可。
|
||||
您可以随时关闭该参数,只需要在taos.cfg 中修改 telemetryReporting 为 0,然后重启数据库服务即可。
|
||||
|
||||
代码位于:[点击此处](https://github.com/taosdata/TDengine/blob/62e609c558deb764a37d1a01ba84bc35115a85a4/source/dnode/mnode/impl/src/mndTelem.c)
|
||||
代码位于:[点击此处](https://github.com/taosdata/TDengine/blob/62e609c558deb764a37d1a01ba84bc35115a85a4/source/dnode/mnode/impl/src/mndTelem.c)
|
||||
|
||||
此外,对于安全性要求极高的企业版 TDengine Enterprise 来说,此参数不会工作。
|
||||
|
||||
### 31 第一次连接集群时遇到“Sync leader is unreachable”怎么办?
|
||||
报这个错,说明第一次向集群的连接是成功的,但第一次访问的IP不是mnode的leader节点,客户端试图与leader建立连接时发生错误。客户端通过EP,也就是指定的fqdn与端口号寻找leader节点,常见的报错原因有两个:
|
||||
报这个错,说明第一次向集群的连接是成功的,但第一次访问的 IP 不是 mnode 的 leader 节点,客户端试图与 leader 建立连接时发生错误。客户端通过 EP,也就是指定的 fqdn 与端口号寻找 leader 节点,常见的报错原因有两个:
|
||||
|
||||
- 集群中其他节点的端口没有打开
|
||||
- 客户端的hosts未正确配置
|
||||
- 客户端的 hosts 未正确配置
|
||||
|
||||
因此用户首先要检查服务端,集群的所有端口(原生连接默认6030,http连接默认6041)有无打开;其次是客户端的hosts文件中是否配置了集群所有节点的fqdn与IP信息。
|
||||
因此用户首先要检查服务端,集群的所有端口(原生连接默认 6030,http 连接默认 6041)有无打开;其次是客户端的 hosts 文件中是否配置了集群所有节点的 fqdn 与 IP 信息。
|
||||
如仍无法解决,则需要联系涛思技术人员支持。
|
||||
|
||||
### 32 同一台服务器,数据库的数据目录 dataDir 不变,为什么原有数据库丢失且集群 ID 发生了变化?
|
||||
|
|
|
@ -16,7 +16,7 @@ TDengine 版本号由四个数字组成,中间由点号分隔,定义如下
|
|||
|
||||
## TDengine 2.x 下载
|
||||
|
||||
TDengine 2.x 各版本安装包请访问[这里](https://www.taosdata.com/all-downloads)
|
||||
TDengine 2.x 各版本安装包请访问 [这里](https://www.taosdata.com/all-downloads)
|
||||
|
||||
## TDengine 3.x 下载
|
||||
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue