All Products
Search

This Product

    Lindorm:Constraint policies for schemas

    Document Center

    Lindorm:Constraint policies for schemas

    Last Updated:Jan 11, 2024

    You can configure constraint policies for schemas to specify whether to check the existence of tables, the consistency between the table schemas, and the consistency of the field data types when you write data to table. The supported constraint policies for schemas vary with the method that you use to write data. This topic describes the constraint policies for schemas in LindormTSDB and how to use these policies.

    Schema of the Lindorm time series model

    LindormTSDB abstracts the concept of time series tables based on the information about business data models in time series scenarios. When you develop applications based on LindormTSDB, you can access time series tables in a similar manner in which relational tables are accessed in traditional relational databases.

    However, the time series model is different from the relational data model. The time series model is more like a semi-structured data model that supports data queries based on the specified structure and allows columns to be dynamically added or reduced in application performance management (APM), IoT, or traditional industrial scenarios. The structure of the semi-structured data model is different from the tabular structure of data models that are associated with relational databases. In actual business scenarios, data models that are generated by devices may frequently change because the devices continue to be improved, upgraded, or iterated. For example, the number of fields that are generated by devices is increased and the field types are changed.

    LindormTSDB provides the ALTER TABLE statement to allow you to change time series tables. However, in some time series scenarios, if the constraints on the table schemas are as strict as the constraints on the schemas of tables in relational databases, application development may become more difficult.

    In this case, LindormTSDB provides more flexible policies for users to apply constraints on table schemas.

    Schema constraints

    In most cases, schema constraints take effect when data is written to tables. The schema constraints can define whether the written fields are consistent with the fields that are contained in the predefined table schema, whether the data types of the written fields are consistent with or compatible with the predefined data types, or whether the table to which data is written exists. In traditional relational databases, strict constraints are applied.

    Based on the schema constraints in LindormTSDB, the system performs the following verification operations:

    • Verify whether the destination table to which data is written exists.

    • Verify whether the TAG or FIELD column to which data is written is predefined.

    • Verify whether the types of the data that is written are consistent with the data types that are predefined.

    • Verify whether the data types of fields that are returned are consistent with the data types that are specified when the table is created.

    Supported schema constraint policies

    LindormTSDB provides three types of schema constraint policies: strong constraint, weak constraint, and no constraint. You can select a policy based on your business requirements.

    • Strong constraint

      LindormTSDB strictly verifies the name of the table to which data is written, the field name of data that is written, and the types of data that is written based on the predefined table schema. This process is similar to the verification process in traditional relational databases. An error is reported if the table name, field name, or data type is inconsistent with that predefined in the table schema.

    • Weak constraint

      • When the table to which data is written does not exist, LindormTSDB does not report an error. Instead, LindormTSDB automatically creates a table.

      • When a tag or field is added to the data that is written, LindormTSDB does not report an error. Instead, LindormTSDB automatically adds a TAG or FIELD column to the time series table.

      • If the data type of a field to which data is written changes, the data fails to be written because LindormTSDB detects that the data type of the field is inconsistent with the predefined data type. In this case, you must execute the ALTER TABLE statement to manually modify the data type of the field.

      Note

      When a weak constraint policy is used, some verification operations are still performed. For example, if you try to write a non-string value to the TAG column or write data of a non-timestamp type to the timestamp column, the verification fails.

    • No constraint

      No constraints are applied. If you use this policy, no error is reported when the table to which you want to write data does not exist. You can call interfaces that are compatible with Time Series Database (TSDB) to query the written data. If you manually create a table when the table to which you want to write data does not exist, you can execute SQL statements to query the written data. However, no error is reported for inconsistent field data types.

      Note

      The no constraint policy is reserved by the system to ensure the compatibility with TSDB. For more information, see Overview of application development.

    Select a schema constraint policy based on the data writing method

    In LindormTSDB, the schema constraint policies that are used when data is written are closely related to the methods used to write data. The following table describes schema constraint policies that correspond to different data writing methods.

    Data writing method

    Schema constraint policy

    Sample code used to change schema constraint policies

    JDBC Driver

    Only strong constraint is supported.

    N/A

    Java Native SDK

    Supported constraint policies:

    • Strong constraint (default)

    • Weak constraint

    • No constraint

    // Specify the endpoint.
String url = "http://ld-bp1489gr5t*****-proxy-tsdb.lindorm.rds.aliyuncs.com:8242";
// Create a LindormTSDB client. A LindormTSDB client is thread-safe and can be reused. You do not need to create a client for each thread and then shutdown the client after operations are complete.
ClientOptions options = ClientOptions
        .newBuilder(url)
        .setSchemaPolicy(SchemaPolicy.WEAK)
        .build();
LindormTSDBClient lindormTSDBClient = LindormTSDBFactory.connect(options);

    HTTP SQL API

    Only strong constraint is supported.

    N/A

    InfluxDB line protocol

    Supported constraint policies:

    • Strong constraint

    • Weak constraint (default)

    • No constraint

    curl -X POST 'http://ld-bp1489gr5t*****-proxy-tsdb.lindorm.rds.aliyuncs.com:8242/api/v2/write?db=default&schema_policy=WEAK' -d 'sensor,device_id=F07A1260,region=north-cn temperature=12.1,humidity=45 1619076780000'

    Multi-value data writing

    Supported constraint policies:

    • Weak constraint

    • Strong constraint

    • No constraint (default)

     curl -X POST http://ld-bp1489gr5t*****-proxy-tsdb.lindorm.rds.aliyuncs.com:8242/api/config -d'{"schema.policy.opentsdb":"WEAK"}'

    Single-value data writing

    Only no constraint is supported.

    N/A