Does Tencent Cloud TCHouse-D support renaming columns?
Since version 1.2.0, if you enable "light_schema_change"="true" Optionally, you can modify the column name.
Before version 1.2.0 or when the "light_schema_change"="true" option is not enabled, you cannot modify the column name.
In the Doris kernel used by Tencent Cloud TCHouse-D, column names are directly written into the data file, and queries find the corresponding columns via column names. Therefore, renaming a column is not just a simple metadata modification but also involves rewriting data, which is a heavy operation. Renaming columns is supported after enabling light schema change, but this feature is currently immature and should be used with caution.
Can the tables of the Unique Key model support the creation of materialized views?
Not support.
The table of the Unique Key model is business-friendly because of its unique feature of deduplication based on primary keys, which can easily synchronization business databases with frequently changing data. Therefore, many users will first consider using the Unique Key model when connecting data.
Unfortunately, it is not possible to create a materialized view for a table in the Unique Key model. The reason is that the essence of materialized views is to pre-calculated data through pre-calculation so that the calculated data can be directly returned during the query to speed up the query. In a materialized view, the pre-calculated data is usually some aggregated metrics, such as sum and count. In this case, if the data changes, such as being updated or deleted, the pre-calculated data cannot be updated synchronously because the detailed information has been lost. For example, a sum of 5 may be 1+4 or 2+3. Because of the loss of detailed information, we cannot know how the sum is calculated and cannot meet the update requirements.
Is the information viewed through show backends/frontends incomplete?
When executing statements such as show backends/frontends, you may find that some columns in the results are incomplete. For example, information such as disk capacity cannot be viewed in the result of show backends.
Usually, this problem occurs when the cluster has multiple FEs. If the user connects to a non-Master FE node to execute these statements, the information seen will be incomplete. This is because such information only exists on the Master FE node. For example, BE's disk usage information. Therefore, only the direct connection to Master FE allows you to get complete information.
Of course, users can also execute set forward_to_master=true; before executing these statements. After this session variable is set to true, some subsequent information viewing statements will be automatically forwarded to Master FE to obtain results. In this way, no matter which FE the user is connected to, the complete results can be obtained.
Unique Key model query results are inconsistent?
In some cases, when a user uses the same SQL to query a table of the Unique Key model, inconsistent query results may occur. The query results always vary between 2-3 types.
This may be because data with the same key but different values appear in the same batch of imported data, which will lead to inconsistent results between different replicas due to the uncertain order of data overwriting.
For example, the table definition is k1, v1. A batch of imported data is as follows:
Then, the result of replica 1 may be 1, "abc", and the result of replica 2 is 1, "def". This results in data inconsistency.To ensure that the data sequence between different replicas is unique, see the Sequence column feature.