Operate Metadata

Database Management

Create Database

According to the storage model we can set up the corresponding database. Two SQL statements are supported for creating databases, as follows:

  1. IoTDB > create database root.ln
  2. IoTDB > create database root.sgcc

We can thus create two databases using the above two SQL statements.

It is worth noting that when the path itself or the parent/child layer of the path is already created as database, the path is then not allowed to be created as database. For example, it is not feasible to create root.ln.wf01 as database when two databases root.ln and root.sgcc exist. The system gives the corresponding error prompt as shown below:

  1. IoTDB> CREATE DATABASE root.ln.wf01
  2. Msg: 300: root.ln has already been created as database.
  3. IoTDB> create database root.ln.wf01
  4. Msg: 300: root.ln has already been created as database.

The LayerName of database can only be characters, numbers, underscores. If you want to set it to pure numbers or contain other characters, you need to enclose the database name with backticks (``).

Besides, if deploy on Windows system, the LayerName is case-insensitive, which means it’s not allowed to create databases root.ln and root.LN at the same time.

Show Databases

After creating the database, we can use the SHOW DATABASES statement and SHOW DATABASES <PathPattern> to view the databases. The SQL statements are as follows:

  1. IoTDB> SHOW DATABASES
  2. IoTDB> SHOW DATABASES root.**

The result is as follows:

  1. +-------------+----+-------------------------+-----------------------+-----------------------+
  2. |database| ttl|schema_replication_factor|data_replication_factor|time_partition_interval|
  3. +-------------+----+-------------------------+-----------------------+-----------------------+
  4. |    root.sgcc|null|                        2|                      2|                 604800|
  5. |      root.ln|null|                        2|                      2|                 604800|
  6. +-------------+----+-------------------------+-----------------------+-----------------------+
  7. Total line number = 2
  8. It costs 0.060s

Delete Database

User can use the DELETE DATABASE <PathPattern> statement to delete all databases matching the pathPattern. Please note the data in the database will also be deleted.

  1. IoTDB > DELETE DATABASE root.ln
  2. IoTDB > DELETE DATABASE root.sgcc
  3. // delete all data, all timeseries and all databases
  4. IoTDB > DELETE DATABASE root.**

Count Databases

User can use the COUNT DATABASE <PathPattern> statement to count the number of databases. It is allowed to specify PathPattern to count the number of databases matching the PathPattern.

SQL statement is as follows:

  1. IoTDB> count databases
  2. IoTDB> count databases root.*
  3. IoTDB> count databases root.sgcc.*
  4. IoTDB> count databases root.sgcc

The result is as follows:

  1. +-------------+
  2. |     database|
  3. +-------------+
  4. |    root.sgcc|
  5. | root.turbine|
  6. |      root.ln|
  7. +-------------+
  8. Total line number = 3
  9. It costs 0.003s
  11. +-------------+
  12. |     database|
  13. +-------------+
  14. |            3|
  15. +-------------+
  16. Total line number = 1
  17. It costs 0.003s
  19. +-------------+
  20. |     database|
  21. +-------------+
  22. |            3|
  23. +-------------+
  24. Total line number = 1
  25. It costs 0.002s
  27. +-------------+
  28. |     database|
  29. +-------------+
  30. |            0|
  31. +-------------+
  32. Total line number = 1
  33. It costs 0.002s
  35. +-------------+
  36. |     database|
  37. +-------------+
  38. |            1|
  39. +-------------+
  40. Total line number = 1
  41. It costs 0.002s

Setting up heterogeneous databases (Advanced operations)

Under the premise of familiar with IoTDB metadata modeling,
users can set up heterogeneous databases in IoTDB to cope with different production needs.

Currently, the following database heterogeneous parameters are supported:

ParameterTypeDescription
TTLLongTTL of the Database
SCHEMA_REPLICATION_FACTORIntegerThe schema replication number of the Database
DATA_REPLICATION_FACTORIntegerThe data replication number of the Database
SCHEMA_REGION_GROUP_NUMIntegerThe SchemaRegionGroup number of the Database
DATA_REGION_GROUP_NUMIntegerThe DataRegionGroup number of the Database

Note the following when configuring heterogeneous parameters:

  • TTL and TIME_PARTITION_INTERVAL must be positive integers.
  • SCHEMA_REPLICATION_FACTOR and DATA_REPLICATION_FACTOR must be smaller than or equal to the number of deployed DataNodes.
  • The function of SCHEMA_REGION_GROUP_NUM and DATA_REGION_GROUP_NUM are related to the parameter schema_region_group_extension_policy and data_region_group_extension_policy in iotdb-common.properties configuration file. Take DATA_REGION_GROUP_NUM as an example:
    If data_region_group_extension_policy=CUSTOM is set, DATA_REGION_GROUP_NUM serves as the number of DataRegionGroups owned by the Database.
    If data_region_group_extension_policy=AUTO, DATA_REGION_GROUP_NUM is used as the lower bound of the DataRegionGroup quota owned by the Database. That is, when the Database starts writing data, it will have at least this number of DataRegionGroups.

Users can set any heterogeneous parameters when creating a Database, or adjust some heterogeneous parameters during a stand-alone/distributed IoTDB run.

Set heterogeneous parameters when creating a Database

The user can set any of the above heterogeneous parameters when creating a Database. The SQL statement is as follows:

  1. CREATE DATABASE prefixPath (WITH databaseAttributeClause (COMMA? databaseAttributeClause)*)?

For example:

  1. CREATE DATABASE root.db WITH SCHEMA_REPLICATION_FACTOR=1, DATA_REPLICATION_FACTOR=3, SCHEMA_REGION_GROUP_NUM=1, DATA_REGION_GROUP_NUM=2;

Adjust heterogeneous parameters at run time

Users can adjust some heterogeneous parameters during the IoTDB runtime, as shown in the following SQL statement:

  1. ALTER DATABASE prefixPath WITH databaseAttributeClause (COMMA? databaseAttributeClause)*

For example:

  1. ALTER DATABASE root.db WITH SCHEMA_REGION_GROUP_NUM=1, DATA_REGION_GROUP_NUM=2;

Note that only the following heterogeneous parameters can be adjusted at runtime:

  • SCHEMA_REGION_GROUP_NUM
  • DATA_REGION_GROUP_NUM

Show heterogeneous databases

The user can query the specific heterogeneous configuration of each Database, and the SQL statement is as follows:

  1. SHOW DATABASES DETAILS prefixPath?

For example:

  1. IoTDB> SHOW DATABASES DETAILS
  2. +--------+--------+-----------------------+---------------------+---------------------+--------------------+-----------------------+-----------------------+------------------+---------------------+---------------------+
  3. |Database|     TTL|SchemaReplicationFactor|DataReplicationFactor|TimePartitionInterval|SchemaRegionGroupNum|MinSchemaRegionGroupNum|MaxSchemaRegionGroupNum|DataRegionGroupNum|MinDataRegionGroupNum|MaxDataRegionGroupNum|
  4. +--------+--------+-----------------------+---------------------+---------------------+--------------------+-----------------------+-----------------------+------------------+---------------------+---------------------+
  5. |root.db1|    null|                      1|                    3|            604800000|                   0|                      1|                      1|                 0|                    2|                    2|
  6. |root.db2|86400000|                      1|                    1|            604800000|                   0|                      1|                      1|                 0|                    2|                    2|
  7. |root.db3|    null|                      1|                    1|            604800000|                   0|                      1|                      1|                 0|                    2|                    2|
  8. +--------+--------+-----------------------+---------------------+---------------------+--------------------+-----------------------+-----------------------+------------------+---------------------+---------------------+
  9. Total line number = 3
  10. It costs 0.058s

The query results in each column are as follows:

  • The name of the Database
  • The TTL of the Database
  • The schema replication number of the Database
  • The data replication number of the Database
  • The time partition interval of the Database
  • The current SchemaRegionGroup number of the Database
  • The required minimum SchemaRegionGroup number of the Database
  • The permitted maximum SchemaRegionGroup number of the Database
  • The current DataRegionGroup number of the Database
  • The required minimum DataRegionGroup number of the Database
  • The permitted maximum DataRegionGroup number of the Database

TTL

IoTDB supports storage-level TTL settings, which means it is able to delete old data automatically and periodically. The benefit of using TTL is that hopefully you can control the total disk space usage and prevent the machine from running out of disks. Moreover, the query performance may downgrade as the total number of files goes up and the memory usage also increase as there are more files. Timely removing such files helps to keep at a high query performance level and reduce memory usage.

The default unit of TTL is milliseconds. If the time precision in the configuration file changes to another, the TTL is still set to milliseconds.

Set TTL

The SQL Statement for setting TTL is as follow:

  1. IoTDB> set ttl to root.ln 3600000

This example means that for data in root.ln, only 3600000 ms, that is, the latest 1 hour will remain, the older one is removed or made invisible.

  1. IoTDB> set ttl to root.sgcc.** 3600000

It supports setting TTL for databases in a path. This example represents setting TTL for all databases in the root.sgcc path.

  1. IoTDB> set ttl to root.** 3600000

This example represents setting TTL for all databases.

Unset TTL

To unset TTL, we can use follwing SQL statement:

  1. IoTDB> unset ttl to root.ln

After unset TTL, all data will be accepted in root.ln.

  1. IoTDB> unset ttl to root.sgcc.**

Unset the TTL setting for all databases in the root.sgcc path.

  1. IoTDB> unset ttl to root.**

Unset the TTL setting for all databases.

Show TTL

To Show TTL, we can use following SQL statement:

  1. IoTDB> SHOW ALL TTL
  2. IoTDB> SHOW TTL ON StorageGroupNames

The SHOW ALL TTL example gives the TTL for all databases.
The SHOW TTL ON root.ln,root.sgcc,root.DB example shows the TTL for the three storage
groups specified.
Note: the TTL for databases that do not have a TTL set will display as null.

  1. IoTDB> show all ttl
  2. +----------+-------+
  3. | database|ttl(ms)|
  4. +---------+-------+
  5. |  root.ln|3600000|
  6. |root.sgcc|   null|
  7. |  root.DB|3600000|
  8. +----------+-------+

Schema Template

IoTDB supports the schema template function, enabling different entities of the same type to share metadata, reduce the memory usage of metadata, and simplify the management of numerous entities and measurements.

Note: The schema keyword in the following statements can be omitted.

Create Schema Template

The SQL syntax for creating a metadata template is as follows:

  1. CREATE SCHEMA TEMPLATE <templateName> ALIGNED? '(' <measurementId> <attributeClauses> [',' <measurementId> <attributeClauses>]+ ')'

Example 1: Create a template containing two non-aligned timeseires

  1. IoTDB> create schema template t1 (temperature FLOAT encoding=RLE, status BOOLEAN encoding=PLAIN compression=SNAPPY)

Example 2: Create a template containing a group of aligned timeseires

  1. IoTDB> create schema template t2 aligned (lat FLOAT encoding=Gorilla, lon FLOAT encoding=Gorilla)

The lat and lon measurements are aligned.

Set Schema Template

After a schema template is created, it should be set to specific path before creating related timeseries or insert data.

It should be ensured that the related database has been set before setting template.

It is recommended to set schema template to database path. It is not suggested to set schema template to some path above database

It is forbidden to create timeseries under a path setting schema template. Schema template shall not be set on a prefix path of an existing timeseries.

The SQL Statement for setting schema template is as follow:

  1. IoTDB> set schema template t1 to root.sg1.d1

Activate Schema Template

After setting the schema template, with the system enabled to auto create schema, you can insert data into the timeseries. For example, suppose there’s a database root.sg1 and t1 has been set to root.sg1.d1, then timeseries like root.sg1.d1.temperature and root.sg1.d1.status are available and data points can be inserted.

Attention: Before inserting data or the system not enabled to auto create schema, timeseries defined by the schema template will not be created. You can use the following SQL statement to create the timeseries or activate the schema template, act before inserting data:

  1. IoTDB> create timeseries using schema template on root.sg1.d1

Example: Execute the following statement

  1. IoTDB> set schema template t1 to root.sg1.d1
  2. IoTDB> set schema template t2 to root.sg1.d2
  3. IoTDB> create timeseries using schema template on root.sg1.d1
  4. IoTDB> create timeseries using schema template on root.sg1.d2

Show the time series:

  1. show timeseries root.sg1.**
  1. +-----------------------+-----+-------------+--------+--------+-----------+----+----------+--------+-------------------+
  2. |             timeseries|alias|     database|dataType|encoding|compression|tags|attributes|deadband|deadband parameters|
  3. +-----------------------+-----+-------------+--------+--------+-----------+----+----------+--------+-------------------+
  4. |root.sg1.d1.temperature| null|     root.sg1|   FLOAT|     RLE|     SNAPPY|null|      null|    null|               null|
  5. |     root.sg1.d1.status| null|     root.sg1| BOOLEAN|   PLAIN|     SNAPPY|null|      null|    null|               null|
  6. |        root.sg1.d2.lon| null|     root.sg1|   FLOAT| GORILLA|     SNAPPY|null|      null|    null|               null|
  7. |        root.sg1.d2.lat| null|     root.sg1|   FLOAT| GORILLA|     SNAPPY|null|      null|    null|               null|
  8. +-----------------------+-----+-------------+--------+--------+-----------+----+----------+--------+-------------------+

Show the devices:

  1. show devices root.sg1.**
  1. +---------------+---------+
  2. |        devices|isAligned|
  3. +---------------+---------+
  4. |    root.sg1.d1|    false|
  5. |    root.sg1.d2|     true|
  6. +---------------+---------+

Show Schema Template

  • Show all schema templates

The SQL statement looks like this:

  1. IoTDB> show schema templates

The execution result is as follows:

  1. +-------------+
  2. |template name|
  3. +-------------+
  4. |           t2|
  5. |           t1|
  6. +-------------+
  • Show nodes under in schema template

The SQL statement looks like this:

  1. IoTDB> show nodes in schema template t1

The execution result is as follows:

  1. +-----------+--------+--------+-----------+
  2. |child nodes|dataType|encoding|compression|
  3. +-----------+--------+--------+-----------+
  4. |temperature|   FLOAT|     RLE|     SNAPPY|
  5. |     status| BOOLEAN|   PLAIN|     SNAPPY|
  6. +-----------+--------+--------+-----------+
  • Show the path prefix where a schema template is set
  1. IoTDB> show paths set schema template t1

The execution result is as follows:

  1. +-----------+
  2. |child paths|
  3. +-----------+
  4. |root.sg1.d1|
  5. +-----------+
  • Show the path prefix where a schema template is used (i.e. the time series has been created)
  1. IoTDB> show paths using schema template t1

The execution result is as follows:

  1. +-----------+
  2. |child paths|
  3. +-----------+
  4. |root.sg1.d1|
  5. +-----------+

Deactivate Schema Template

To delete a group of timeseries represented by schema template, namely deactivate the schema template, use the following SQL statement:

  1. IoTDB> delete timeseries of schema template t1 from root.sg1.d1

or

  1. IoTDB> deactivate schema template t1 from root.sg1.d1

The deactivation supports batch process.

  1. IoTDB> delete timeseries of schema template t1 from root.sg1.*, root.sg2.*

or

  1. IoTDB> deactivate schema template t1 from root.sg1.*, root.sg2.*

If the template name is not provided in sql, all template activation on paths matched by given path pattern will be removed.

Unset Schema Template

The SQL Statement for unsetting schema template is as follow:

  1. IoTDB> unset schema template t1 from root.sg1.d1

Attention: It should be guaranteed that none of the timeseries represented by the target schema template exists, before unset it. It can be achieved by deactivation operation.

Drop Schema Template

The SQL Statement for dropping schema template is as follow:

  1. IoTDB> drop schema template t1

Attention: Dropping an already set template is not supported.

Alter Schema Template

In a scenario where measurements need to be added, you can modify the schema template to add measurements to all devices using the schema template.

The SQL Statement for altering schema template is as follow:

  1. IoTDB> alter schema template t1 add (speed FLOAT encoding=RLE, FLOAT TEXT encoding=PLAIN compression=SNAPPY)

When executing data insertion to devices with schema template set on related prefix path and there are measurements not present in this schema template, the measurements will be auto added to this schema template.

Timeseries Management

Create Timeseries

According to the storage model selected before, we can create corresponding timeseries in the two databases respectively. The SQL statements for creating timeseries are as follows:

  1. IoTDB > create timeseries root.ln.wf01.wt01.status with datatype=BOOLEAN,encoding=PLAIN
  2. IoTDB > create timeseries root.ln.wf01.wt01.temperature with datatype=FLOAT,encoding=RLE
  3. IoTDB > create timeseries root.ln.wf02.wt02.hardware with datatype=TEXT,encoding=PLAIN
  4. IoTDB > create timeseries root.ln.wf02.wt02.status with datatype=BOOLEAN,encoding=PLAIN
  5. IoTDB > create timeseries root.sgcc.wf03.wt01.status with datatype=BOOLEAN,encoding=PLAIN
  6. IoTDB > create timeseries root.sgcc.wf03.wt01.temperature with datatype=FLOAT,encoding=RLE

From v0.13, you can use a simplified version of the SQL statements to create timeseries:

  1. IoTDB > create timeseries root.ln.wf01.wt01.status BOOLEAN encoding=PLAIN
  2. IoTDB > create timeseries root.ln.wf01.wt01.temperature FLOAT encoding=RLE
  3. IoTDB > create timeseries root.ln.wf02.wt02.hardware TEXT encoding=PLAIN
  4. IoTDB > create timeseries root.ln.wf02.wt02.status BOOLEAN encoding=PLAIN
  5. IoTDB > create timeseries root.sgcc.wf03.wt01.status BOOLEAN encoding=PLAIN
  6. IoTDB > create timeseries root.sgcc.wf03.wt01.temperature FLOAT encoding=RLE

Notice that when in the CREATE TIMESERIES statement the encoding method conflicts with the data type, the system gives the corresponding error prompt as shown below:

  1. IoTDB > create timeseries root.ln.wf02.wt02.status WITH DATATYPE=BOOLEAN, ENCODING=TS_2DIFF
  2. error: encoding TS_2DIFF does not support BOOLEAN

Please refer to Encoding for correspondence between data type and encoding.

Create Aligned Timeseries

The SQL statement for creating a group of timeseries are as follows:

  1. IoTDB> CREATE ALIGNED TIMESERIES root.ln.wf01.GPS(latitude FLOAT encoding=PLAIN compressor=SNAPPY, longitude FLOAT encoding=PLAIN compressor=SNAPPY)

You can set different datatype, encoding, and compression for the timeseries in a group of aligned timeseries

It is also supported to set an alias, tag, and attribute for aligned timeseries.

Delete Timeseries

To delete the timeseries we created before, we are able to use (DELETE | DROP) TimeSeries <PathPattern> statement.

The usage are as follows:

  1. IoTDB> delete timeseries root.ln.wf01.wt01.status
  2. IoTDB> delete timeseries root.ln.wf01.wt01.temperature, root.ln.wf02.wt02.hardware
  3. IoTDB> delete timeseries root.ln.wf02.*
  4. IoTDB> drop timeseries root.ln.wf02.*

Show Timeseries

  • SHOW LATEST? TIMESERIES pathPattern? whereClause? limitClause?

    There are four optional clauses added in SHOW TIMESERIES, return information of time series

Timeseries information includes: timeseries path, alias of measurement, database it belongs to, data type, encoding type, compression type, tags and attributes.

Examples:

  • SHOW TIMESERIES

    presents all timeseries information in JSON form

  • SHOW TIMESERIES <PathPattern>

    returns all timeseries information matching the given <PathPattern>. SQL statements are as follows:

  1. IoTDB> show timeseries root.**
  2. IoTDB> show timeseries root.ln.**

The results are shown below respectively:

  1. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  2. |                     timeseries|   alias|     database|dataType|encoding|compression|                                       tags|                                              attributes|deadband|deadband parameters|
  3. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  4. |root.sgcc.wf03.wt01.temperature|    null|    root.sgcc|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  5. |     root.sgcc.wf03.wt01.status|    null|    root.sgcc| BOOLEAN|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  6. |             root.turbine.d1.s1|newAlias| root.turbine|   FLOAT|     RLE|     SNAPPY|{"newTag1":"newV1","tag4":"v4","tag3":"v3"}|{"attr2":"v2","attr1":"newV1","attr4":"v4","attr3":"v3"}|    null|               null|
  7. |     root.ln.wf02.wt02.hardware|    null|      root.ln|    TEXT|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  8. |       root.ln.wf02.wt02.status|    null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  9. |  root.ln.wf01.wt01.temperature|    null|      root.ln|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  10. |       root.ln.wf01.wt01.status|    null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  11. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  12. Total line number = 7
  13. It costs 0.016s
  15. +-----------------------------+-----+-------------+--------+--------+-----------+----+----------+--------+-------------------+
  16. |                   timeseries|alias|     database|dataType|encoding|compression|tags|attributes|deadband|deadband parameters|
  17. +-----------------------------+-----+-------------+--------+--------+-----------+----+----------+--------+-------------------+
  18. |   root.ln.wf02.wt02.hardware| null|      root.ln|    TEXT|   PLAIN|     SNAPPY|null|      null|    null|               null|
  19. |     root.ln.wf02.wt02.status| null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|null|      null|    null|               null|
  20. |root.ln.wf01.wt01.temperature| null|      root.ln|   FLOAT|     RLE|     SNAPPY|null|      null|    null|               null|
  21. |     root.ln.wf01.wt01.status| null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|null|      null|    null|               null|
  22. +-----------------------------+-----+-------------+--------+--------+-----------+----+----------+--------+-------------------+
  23. Total line number = 4
  24. It costs 0.004s

  • SHOW TIMESERIES LIMIT INT OFFSET INT

    returns all the timeseries information start from the offset and limit the number of series returned. For example,

  1. show timeseries root.ln.** limit 10 offset 10

  • SHOW TIMESERIES WHERE TIMESERIES contains ‘containStr’

    The query result set is filtered by string fuzzy matching based on the names of the timeseries. For example:

  1. show timeseries root.ln.** where timeseries contains 'wf01.wt'

The result is shown below:

  1. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  2. |                     timeseries|   alias|     database|dataType|encoding|compression|                                       tags|                                              attributes|deadband|deadband parameters|
  3. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  4. |  root.ln.wf01.wt01.temperature|    null|      root.ln|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  5. |       root.ln.wf01.wt01.status|    null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  6. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  7. Total line number = 2
  8. It costs 0.016s

  • SHOW TIMESERIES WHERE DataType=type

    The query result set is filtered by data type. For example:

  1. show timeseries root.ln.** where dataType=FLOAT

The result is shown below:

  1. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  2. |                     timeseries|   alias|     database|dataType|encoding|compression|                                       tags|                                              attributes|deadband|deadband parameters|
  3. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  4. |root.sgcc.wf03.wt01.temperature|    null|    root.sgcc|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  5. |             root.turbine.d1.s1|newAlias| root.turbine|   FLOAT|     RLE|     SNAPPY|{"newTag1":"newV1","tag4":"v4","tag3":"v3"}|{"attr2":"v2","attr1":"newV1","attr4":"v4","attr3":"v3"}|    null|               null|
  6. |  root.ln.wf01.wt01.temperature|    null|      root.ln|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  7. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  8. Total line number = 3
  9. It costs 0.016s

  • SHOW LATEST TIMESERIES

    all the returned timeseries information should be sorted in descending order of the last timestamp of timeseries

It is worth noting that when the queried path does not exist, the system will return no timeseries.

Count Timeseries

IoTDB is able to use COUNT TIMESERIES <Path> to count the number of timeseries matching the path. SQL statements are as follows:

  • WHERE condition could be used to fuzzy match a time series name with the following syntax: COUNT TIMESERIES <Path> WHERE TIMESERIES contains 'containStr'.
  • WHERE condition could be used to filter result by data type with the syntax: COUNT TIMESERIES <Path> WHERE DataType=<DataType>'.
  • WHERE condition could be used to filter result by tags with the syntax: COUNT TIMESERIES <Path> WHERE TAGS(key)='value' or COUNT TIMESERIES <Path> WHERE TAGS(key) contains 'value'.
  • LEVEL could be defined to show count the number of timeseries of each node at the given level in current Metadata Tree. This could be used to query the number of sensors under each device. The grammar is: COUNT TIMESERIES <Path> GROUP BY LEVEL=<INTEGER>.
  1. IoTDB > COUNT TIMESERIES root.**
  2. IoTDB > COUNT TIMESERIES root.ln.**
  3. IoTDB > COUNT TIMESERIES root.ln.*.*.status
  4. IoTDB > COUNT TIMESERIES root.ln.wf01.wt01.status
  5. IoTDB > COUNT TIMESERIES root.** WHERE TIMESERIES contains 'sgcc' 
  6. IoTDB > COUNT TIMESERIES root.** WHERE DATATYPE = INT64
  7. IoTDB > COUNT TIMESERIES root.** WHERE TAGS(unit) contains 'c' 
  8. IoTDB > COUNT TIMESERIES root.** WHERE TAGS(unit) = 'c' 
  9. IoTDB > COUNT TIMESERIES root.** WHERE TIMESERIES contains 'sgcc' group by level = 1

For example, if there are several timeseries (use show timeseries to show all timeseries):

  1. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  2. |                     timeseries|   alias|     database|dataType|encoding|compression|                                       tags|                                              attributes|deadband|deadband parameters|
  3. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  4. |root.sgcc.wf03.wt01.temperature|    null|    root.sgcc|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  5. |     root.sgcc.wf03.wt01.status|    null|    root.sgcc| BOOLEAN|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  6. |             root.turbine.d1.s1|newAlias| root.turbine|   FLOAT|     RLE|     SNAPPY|{"newTag1":"newV1","tag4":"v4","tag3":"v3"}|{"attr2":"v2","attr1":"newV1","attr4":"v4","attr3":"v3"}|    null|               null|
  7. |     root.ln.wf02.wt02.hardware|    null|      root.ln|    TEXT|   PLAIN|     SNAPPY|                               {"unit":"c"}|                                                    null|    null|               null|
  8. |       root.ln.wf02.wt02.status|    null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|                    {"description":"test1"}|                                                    null|    null|               null|
  9. |  root.ln.wf01.wt01.temperature|    null|      root.ln|   FLOAT|     RLE|     SNAPPY|                                       null|                                                    null|    null|               null|
  10. |       root.ln.wf01.wt01.status|    null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|                                       null|                                                    null|    null|               null|
  11. +-------------------------------+--------+-------------+--------+--------+-----------+-------------------------------------------+--------------------------------------------------------+--------+-------------------+
  12. Total line number = 7
  13. It costs 0.004s

Then the Metadata Tree will be as below:

Operate Metadata - 图1

As can be seen, root is considered as LEVEL=0. So when you enter statements such as:

  1. IoTDB > COUNT TIMESERIES root.** GROUP BY LEVEL=1
  2. IoTDB > COUNT TIMESERIES root.ln.** GROUP BY LEVEL=2
  3. IoTDB > COUNT TIMESERIES root.ln.wf01.* GROUP BY LEVEL=2

You will get following results:

  1. +------------+-----------------+
  2. |      column|count(timeseries)|
  3. +------------+-----------------+
  4. |   root.sgcc|                2|
  5. |root.turbine|                1|
  6. |     root.ln|                4|
  7. +------------+-----------------+
  8. Total line number = 3
  9. It costs 0.002s
  11. +------------+-----------------+
  12. |      column|count(timeseries)|
  13. +------------+-----------------+
  14. |root.ln.wf02|                2|
  15. |root.ln.wf01|                2|
  16. +------------+-----------------+
  17. Total line number = 2
  18. It costs 0.002s
  20. +------------+-----------------+
  21. |      column|count(timeseries)|
  22. +------------+-----------------+
  23. |root.ln.wf01|                2|
  24. +------------+-----------------+
  25. Total line number = 1
  26. It costs 0.002s

Note: The path of timeseries is just a filter condition, which has no relationship with the definition of level.

Tag and Attribute Management

We can also add an alias, extra tag and attribute information while creating one timeseries.

The differences between tag and attribute are:

  • Tag could be used to query the path of timeseries, we will maintain an inverted index in memory on the tag: Tag -> Timeseries
  • Attribute could only be queried by timeseries path : Timeseries -> Attribute

The SQL statements for creating timeseries with extra tag and attribute information are extended as follows:

  1. create timeseries root.turbine.d1.s1(temprature) with datatype=FLOAT, encoding=RLE, compression=SNAPPY tags(tag1=v1, tag2=v2) attributes(attr1=v1, attr2=v2)

The temprature in the brackets is an alias for the sensor s1. So we can use temprature to replace s1 anywhere.

IoTDB also supports using AS function to set alias. The difference between the two is: the alias set by the AS function is used to replace the whole time series name, temporary and not bound with the time series; while the alias mentioned above is only used as the alias of the sensor, which is bound with it and can be used equivalent to the original sensor name.

Notice that the size of the extra tag and attribute information shouldn’t exceed the tag_attribute_total_size.

We can update the tag information after creating it as following:

  • Rename the tag/attribute key
  1. ALTER timeseries root.turbine.d1.s1 RENAME tag1 TO newTag1
  • Reset the tag/attribute value
  1. ALTER timeseries root.turbine.d1.s1 SET newTag1=newV1, attr1=newV1
  • Delete the existing tag/attribute
  1. ALTER timeseries root.turbine.d1.s1 DROP tag1, tag2
  • Add new tags
  1. ALTER timeseries root.turbine.d1.s1 ADD TAGS tag3=v3, tag4=v4
  • Add new attributes
  1. ALTER timeseries root.turbine.d1.s1 ADD ATTRIBUTES attr3=v3, attr4=v4
  • Upsert alias, tags and attributes

add alias or a new key-value if the alias or key doesn’t exist, otherwise, update the old one with new value.

  1. ALTER timeseries root.turbine.d1.s1 UPSERT ALIAS=newAlias TAGS(tag3=v3, tag4=v4) ATTRIBUTES(attr3=v3, attr4=v4)
  • Show timeseries using tags. Use TAGS(tagKey) to identify the tags used as filter key
  1. SHOW TIMESERIES (<`PathPattern`>)? timeseriesWhereClause

returns all the timeseries information that satisfy the where condition and match the pathPattern. SQL statements are as follows:

  1. ALTER timeseries root.ln.wf02.wt02.hardware ADD TAGS unit=c
  2. ALTER timeseries root.ln.wf02.wt02.status ADD TAGS description=test1
  3. show timeseries root.ln.** where TAGS(unit)='c'
  4. show timeseries root.ln.** where TAGS(description) contains 'test1'

The results are shown below respectly:

  1. +--------------------------+-----+-------------+--------+--------+-----------+------------+----------+--------+-------------------+
  2. |                timeseries|alias|     database|dataType|encoding|compression|        tags|attributes|deadband|deadband parameters|
  3. +--------------------------+-----+-------------+--------+--------+-----------+------------+----------+--------+-------------------+
  4. |root.ln.wf02.wt02.hardware| null|      root.ln|    TEXT|   PLAIN|     SNAPPY|{"unit":"c"}|      null|    null|               null|
  5. +--------------------------+-----+-------------+--------+--------+-----------+------------+----------+--------+-------------------+
  6. Total line number = 1
  7. It costs 0.005s
  9. +------------------------+-----+-------------+--------+--------+-----------+-----------------------+----------+--------+-------------------+
  10. |              timeseries|alias|     database|dataType|encoding|compression|                   tags|attributes|deadband|deadband parameters|
  11. +------------------------+-----+-------------+--------+--------+-----------+-----------------------+----------+--------+-------------------+
  12. |root.ln.wf02.wt02.status| null|      root.ln| BOOLEAN|   PLAIN|     SNAPPY|{"description":"test1"}|      null|    null|               null|
  13. +------------------------+-----+-------------+--------+--------+-----------+-----------------------+----------+--------+-------------------+
  14. Total line number = 1
  15. It costs 0.004s
  • count timeseries using tags
  1. COUNT TIMESERIES (<`PathPattern`>)? timeseriesWhereClause
  2. COUNT TIMESERIES (<`PathPattern`>)? timeseriesWhereClause GROUP BY LEVEL=<INTEGER>

returns all the number of timeseries that satisfy the where condition and match the pathPattern. SQL statements are as follows:

  1. count timeseries
  2. count timeseries root.** where TAGS(unit)='c'
  3. count timeseries root.** where TAGS(unit)='c' group by level = 2

The results are shown below respectly :

  1. IoTDB> count timeseries
  2. +-----------------+
  3. |count(timeseries)|
  4. +-----------------+
  5. |                6|
  6. +-----------------+
  7. Total line number = 1
  8. It costs 0.019s
  9. IoTDB> count timeseries root.** where TAGS(unit)='c'
  10. +-----------------+
  11. |count(timeseries)|
  12. +-----------------+
  13. |                2|
  14. +-----------------+
  15. Total line number = 1
  16. It costs 0.020s
  17. IoTDB> count timeseries root.** where TAGS(unit)='c' group by level = 2
  18. +--------------+-----------------+
  19. |        column|count(timeseries)|
  20. +--------------+-----------------+
  21. |  root.ln.wf02|                2|
  22. |  root.ln.wf01|                0|
  23. |root.sgcc.wf03|                0|
  24. +--------------+-----------------+
  25. Total line number = 3
  26. It costs 0.011s

Notice that, we only support one condition in the where clause. Either it’s an equal filter or it is an contains filter. In both case, the property in the where condition must be a tag.

create aligned timeseries

  1. create aligned timeseries root.sg1.d1(s1 INT32 tags(tag1=v1, tag2=v2) attributes(attr1=v1, attr2=v2), s2 DOUBLE tags(tag3=v3, tag4=v4) attributes(attr3=v3, attr4=v4))

The execution result is as follows:

  1. IoTDB> show timeseries
  2. +--------------+-----+-------------+--------+--------+-----------+-------------------------+---------------------------+--------+-------------------+
  3. |    timeseries|alias|     database|dataType|encoding|compression|                     tags|                 attributes|deadband|deadband parameters|
  4. +--------------+-----+-------------+--------+--------+-----------+-------------------------+---------------------------+--------+-------------------+
  5. |root.sg1.d1.s1| null|     root.sg1|   INT32|     RLE|     SNAPPY|{"tag1":"v1","tag2":"v2"}|{"attr2":"v2","attr1":"v1"}|    null|               null|
  6. |root.sg1.d1.s2| null|     root.sg1|  DOUBLE| GORILLA|     SNAPPY|{"tag4":"v4","tag3":"v3"}|{"attr4":"v4","attr3":"v3"}|    null|               null|
  7. +--------------+-----+-------------+--------+--------+-----------+-------------------------+---------------------------+--------+-------------------+

Support query：

  1. IoTDB> show timeseries where TAGS(tag1)='v1'
  2. +--------------+-----+-------------+--------+--------+-----------+-------------------------+---------------------------+--------+-------------------+
  3. |    timeseries|alias|     database|dataType|encoding|compression|                     tags|                 attributes|deadband|deadband parameters|
  4. +--------------+-----+-------------+--------+--------+-----------+-------------------------+---------------------------+--------+-------------------+
  5. |root.sg1.d1.s1| null|     root.sg1|   INT32|     RLE|     SNAPPY|{"tag1":"v1","tag2":"v2"}|{"attr2":"v2","attr1":"v1"}|    null|               null|
  6. +--------------+-----+-------------+--------+--------+-----------+-------------------------+---------------------------+--------+-------------------+

The above operations are supported for timeseries tag, attribute updates, etc.

Node Management

Show Child Paths

  1. SHOW CHILD PATHS pathPattern

Return all child paths and their node types of all the paths matching pathPattern.

node types: ROOT -> DB INTERNAL -> DATABASE -> INTERNAL -> DEVICE -> TIMESERIES

Example：

  • return the child paths of root.ln：show child paths root.ln
  1. +------------+----------+
  2. | child paths|node types|
  3. +------------+----------+
  4. |root.ln.wf01|  INTERNAL|
  5. |root.ln.wf02|  INTERNAL|
  6. +------------+----------+
  7. Total line number = 2
  8. It costs 0.002s

get all paths in form of root.xx.xx.xx：show child paths root.xx.xx

Show Child Nodes

  1. SHOW CHILD NODES pathPattern

Return all child nodes of the pathPattern.

Example：

  • return the child nodes of root：show child nodes root
  1. +------------+
  2. | child nodes|
  3. +------------+
  4. |          ln|
  5. +------------+
  • return the child nodes of root.ln：show child nodes root.ln
  1. +------------+
  2. | child nodes|
  3. +------------+
  4. |        wf01|
  5. |        wf02|
  6. +------------+

Count Nodes

IoTDB is able to use COUNT NODES <PathPattern> LEVEL=<INTEGER> to count the number of nodes at
the given level in current Metadata Tree considering a given pattern. IoTDB will find paths that
match the pattern and counts distinct nodes at the specified level among the matched paths.
This could be used to query the number of devices with specified measurements. The usage are as
follows:

  1. IoTDB > COUNT NODES root.** LEVEL=2
  2. IoTDB > COUNT NODES root.ln.** LEVEL=2
  3. IoTDB > COUNT NODES root.ln.wf01.** LEVEL=3
  4. IoTDB > COUNT NODES root.**.temperature LEVEL=3

As for the above mentioned example and Metadata tree, you can get following results:

  1. +------------+
  2. |count(nodes)|
  3. +------------+
  4. |           4|
  5. +------------+
  6. Total line number = 1
  7. It costs 0.003s
  9. +------------+
  10. |count(nodes)|
  11. +------------+
  12. |           2|
  13. +------------+
  14. Total line number = 1
  15. It costs 0.002s
  17. +------------+
  18. |count(nodes)|
  19. +------------+
  20. |           1|
  21. +------------+
  22. Total line number = 1
  23. It costs 0.002s
  25. +------------+
  26. |count(nodes)|
  27. +------------+
  28. |           2|
  29. +------------+
  30. Total line number = 1
  31. It costs 0.002s

Note: The path of timeseries is just a filter condition, which has no relationship with the definition of level.

Show Devices

  • SHOW DEVICES pathPattern? (WITH DATABASE)? devicesWhereClause? limitClause?

Similar to Show Timeseries, IoTDB also supports two ways of viewing devices:

  • SHOW DEVICES statement presents all devices’ information, which is equal to SHOW DEVICES root.**.
  • SHOW DEVICES <PathPattern> statement specifies the PathPattern and returns the devices information matching the pathPattern and under the given level.
  • WHERE condition supports DEVICE contains 'xxx' to do a fuzzy query based on the device name.

SQL statement is as follows:

  1. IoTDB> show devices
  2. IoTDB> show devices root.ln.**
  3. IoTDB> show devices root.ln.** where device contains 't'

You can get results below:

  1. +-------------------+---------+
  2. |            devices|isAligned|
  3. +-------------------+---------+
  4. |  root.ln.wf01.wt01|    false|
  5. |  root.ln.wf02.wt02|    false|
  6. |root.sgcc.wf03.wt01|    false|
  7. |    root.turbine.d1|    false|
  8. +-------------------+---------+
  9. Total line number = 4
  10. It costs 0.002s
  12. +-----------------+---------+
  13. |          devices|isAligned|
  14. +-----------------+---------+
  15. |root.ln.wf01.wt01|    false|
  16. |root.ln.wf02.wt02|    false|
  17. +-----------------+---------+
  18. Total line number = 2
  19. It costs 0.001s

isAligned indicates whether the timeseries under the device are aligned.

To view devices’ information with database, we can use SHOW DEVICES WITH DATABASE statement.

  • SHOW DEVICES WITH DATABASE statement presents all devices’ information with their database.
  • SHOW DEVICES <PathPattern> WITH DATABASE statement specifies the PathPattern and returns the
    devices’ information under the given level with their database information.

SQL statement is as follows:

  1. IoTDB> show devices with database
  2. IoTDB> show devices root.ln.** with database

You can get results below:

  1. +-------------------+-------------+---------+
  2. |            devices|     database|isAligned|
  3. +-------------------+-------------+---------+
  4. |  root.ln.wf01.wt01|      root.ln|    false|
  5. |  root.ln.wf02.wt02|      root.ln|    false|
  6. |root.sgcc.wf03.wt01|    root.sgcc|    false|
  7. |    root.turbine.d1| root.turbine|    false|
  8. +-------------------+-------------+---------+
  9. Total line number = 4
  10. It costs 0.003s
  12. +-----------------+-------------+---------+
  13. |          devices|     database|isAligned|
  14. +-----------------+-------------+---------+
  15. |root.ln.wf01.wt01|      root.ln|    false|
  16. |root.ln.wf02.wt02|      root.ln|    false|
  17. +-----------------+-------------+---------+
  18. Total line number = 2
  19. It costs 0.001s

Count Devices

  • COUNT DEVICES /

The above statement is used to count the number of devices. At the same time, it is allowed to specify PathPattern to count the number of devices matching the PathPattern.

SQL statement is as follows:

  1. IoTDB> show devices
  2. IoTDB> count devices
  3. IoTDB> count devices root.ln.**

You can get results below:

  1. +-------------------+---------+
  2. |            devices|isAligned|
  3. +-------------------+---------+
  4. |root.sgcc.wf03.wt03|    false|
  5. |    root.turbine.d1|    false|
  6. |  root.ln.wf02.wt02|    false|
  7. |  root.ln.wf01.wt01|    false|
  8. +-------------------+---------+
  9. Total line number = 4
  10. It costs 0.024s
  12. +--------------+
  13. |count(devices)|
  14. +--------------+
  15. |             4|
  16. +--------------+
  17. Total line number = 1
  18. It costs 0.004s
  20. +--------------+
  21. |count(devices)|
  22. +--------------+
  23. |             2|
  24. +--------------+
  25. Total line number = 1
  26. It costs 0.004s