TDStore Engine Related
Last updated: 2025-07-23 14:18:33
What database protocols is TDStore compatible with?
TDStore is compatible with the MySQL 8.0 protocol. Users can treat it as a MySQL 8.0 instance, though certain operations may be restricted. For details, please refer to the User Guide.
Does TDStore Require a Shard Key?
TDStore does not require defining a shard key. Its table creation syntax is consistent with native MySQL. The sharding mechanism of TDStore is based on the native partitioned tables of MySQL. In most cases, a primary hash partitioned table is sufficient to cover the requirements. Hash partitions are distributed across all data nodes, balancing write pressure.
What Is the Difference Between the TDStore Engine and Native MySQL in Read-Write Performance?
As a native distributed database, TDStore maintains consistency between replicas of data units using the Raft protocol. By default, each data unit has three replicas, and the data is evenly distributed across all data nodes. This data distribution policy significantly improves the efficiency of handling large amounts of write operations, especially in business scenarios with more writes than reads.
Compared with the InnoDB storage engine of MySQL, TDStore can achieve a data compression rate of 3 to 9 times, which not only effectively reduces the need for storage space but also may improve I/O performance. Therefore, TDStore is particularly suitable for scenarios with relatively high requirements for write performance.
Does TDStore Provide the Read-Write Separation Capability?
Read-write separation is often used to solve the following two problems:
1. In a traditional leader/follower architecture, read-write separation can fully leverage the resources of the standby database.
2. For applications with distinct analytical processing (AP) and transaction processing (TP) business scenarios, read-write separation can avoid mutual interference between them.
However, the architecture of TDStore differs from traditional leader/follower architectures (such as InnoDB). In TDStore, data is evenly distributed across all nodes. As a result, the CPU, I/O, and other resources of each node can be fully utilized without the need to rely on read-write separation to utilize standby database resources.
For scenarios that require isolating AP reading SQL from TP scenarios, we will provide corresponding support in later versions.
Does TDStore Support Read-Only Accounts and Read-Only Nodes?
TDStore does not currently support read-only accounts and read-only nodes. In the hybrid node structure of TDStore, read-write requests can be dispersed across different nodes, thereby fully utilizing the resources of each node.
We will add support for read-only nodes in later versions. Stay tuned.
How Many Table Types Does TDStore Support? Does It Support Single Tables, Broadcast Tables, and Partitioned Tables?
TDStore currently mainly supports ordinary tables, including partitioned and non-partitioned ones.
For partitioned tables, the data in different partitions can be distributed across different nodes.
For non-partitioned tables, if the data volume is large, the RG will be split and evenly distributed to each node.
We will add support for broadcast tables in later versions. Stay tuned.
In TDStore, Do I Need to Use Partitioned Tables?
In the standalone edition, partitioned tables are primarily used to enhance SQL performance through partition pruning and to periodically clean data via the
drop partition method. In the TDStore distributed scenario, the benefits of using partitioned tables also include leveraging the write capability of multiple nodes, which is particularly important for processing large data volumes.Before proceeding with large-scale data migration, it is recommended to transform the large table into a hash-based partitioned table. In this way, the multi-node capability of TDStore can be leveraged to expedite the data import process.
If a single table is created without being partitioned, all write operations will be concentrated on a single data node at the beginning of data import, which may result in an I/O bottleneck. TDStore provides automatic splitting and data migration features, but if the table is not partitioned from the beginning, this process may be relatively slow. Furthermore, during the splitting and migration period, replica balancing will incur additional I/O overhead.
By creating a partitioned table, you can make full use of the capabilities of the TDStore distributed database. The cost of this transformation is rather low, as this requires only modifying the table creation statement and does not require any additional adaptation to the business code. For example, if your TDStore instance contains 30 nodes, after you create a primary hash partitioned table with 30 partitions, TDStore will create a primary replica on each node, thereby achieving the replica balance. Meanwhile, the incremental business data will be evenly distributed across all nodes. As a result, the pressure on each node will be relatively balanced.
In short, to fully leverage the distributed features of TDStore and avoid potential performance bottlenecks, creating a partitioned table is a recommended best practice.
Does TDStore Have Performance Problems in the Reading Scenario? How Do I Determine the Location of Data Shards?
In the TDStore distributed database, read performance may be affected by data sharding and query methods. The following are two common situations:
Queries with partition keys: If the query contains a partition key, TDStore can directly route the query to the specific data shard containing that partition key. This approach is highly efficient as it avoids unnecessary data traversal and directly locates the correct data node.
Queries without partition keys: When a query does not specify a partition key, TDStore needs to use a secondary index to determine the location of the data. In this case, the system will perform a traversal query on the nodes containing the table data, which may result in a slight performance drop because more data needs to be checked.
What Is the Maximum Supported Capacity of TDStore?
The maximum supported capacity of TDStore is theoretically infinite. As your business needs grow, you can expand the database capacity by adding more nodes to adapt to the growing demand for data storage and processing. Currently, you can deploy a TDStore instance with dozens of nodes on the public cloud.
TDStore also provides a visual interface to facilitate horizontal scale-out and scale-in operations. Its built-in automated migration and capacity balancing features make it possible to adjust data distribution among nodes automatically, ensuring that the system's performance and storage efficiency are always in the optimal status. Human intervention is not required.
Is the Query Performance of TDStore Based on LSM-Tree Lower Than That of Native MySQL?
Compared with MySQL's B+ tree index, LSM-tree (Log-Structured Merge-tree) has a significant advantage in write performance, possibly at the cost of compromising some read performance.
However, as a distributed database, TDStore provides multiple mechanisms to enhance its query performance:
1. Vertical/horizontal scaling: TDStore can expand the processing capability of the database by adding more nodes, thereby improving queries per second (QPS). This is not possible for stand-alone MySQL because its performance is restricted by the hardware resources of a single server.
2. Optimization policy: TDStore also adopts a series of optimization policies to improve the read performance of a single node:
Leveling compaction: TDStore stores all data (including primary keys and indexes) in a large, ordered key-value space. The data corresponds to multiple SST files on physical disks, divided into seven layers from L0 to L6. The leveling compaction policy ensures the uniqueness of keys in each layer except L0, which helps accelerate the query. The L0 layer is special, allowing range overlaps between files, but TDStore limits the number of files in the L0 layer, usually no more than four. When data needs to be accessed, TDStore first checks the memtable. If the data is not in the memtable, it checks the SST files on the disk in the hierarchical order. Since keys in layers L1 to L6 are unique, only one SST file per layer needs to be checked to determine the presence of the target data.
Bloom filter: When searching for data, TDStore uses a Bloom filter to quickly exclude SST files that are unlikely to contain the target key. This avoids unnecessary disk searches and saves resources.
Block cache: TDStore uses a block cache to store hotspot data, reducing disk I/O operations and further enhancing read performance.
In summary, although TDStore, based on LSM-tree, may underperform an optimized MySQL instance in read performance, it can provide efficient read-write performance through the distributed architecture and a series of optimization measures, especially in large-scale data processing and high-concurrency access scenarios.
Do InnoDB and TDStore Perform Similarly in Terms of Primary/Standby Latency for Large Transactions?
InnoDB and TDStore exhibit different characteristics in primary/standby latency for large transactions:
InnoDB: InnoDB uses binary logs (binlog) to synchronize primary/standby data. In high-concurrency and large-data-volume scenarios, large transactions may cause primary/standby latency due to the time-consuming replication and replay process of binlogs.
TDStore: As a distributed database based on the Raft protocol, TDStore synchronizes data between nodes in real time through Raft logs. In the Raft protocol, the leader node first adds a received client request as a new log entry to its local log after receiving the request, and then copies it to follower nodes. The leader node only responds to the client when the log entry has been copied to the majority of nodes and marked as ready for commitment. This design effectively reduces latency that may be caused by large transactions.
In TDStore, there is almost no delay in the apply operation between the leader/follower nodes. The only potential latency is that the follower node needs to wait for the leader node to send the next log entry (or heartbeat) to obtain the index that can be committed. However, this time interval is usually very short and can be ignored.
In addition, TDStore has limits on transaction size, especially for deletion operations. It is recommended to split large transactions into multiple small transactions for execution. This helps avoid excessive resource usage by a single transaction and reduces the impact on system performance.
In summary, compared with InnoDB, TDStore's Raft protocol synchronization mechanism provides lower primary/standby latency in processing large transactions, especially in high-concurrency and large-data-volume scenarios.
If a Transaction Is Eventually Rolled Back, What Will Happen to the Logs That Have Been Copied to Follower Nodes?
In the Raft protocol, if a transaction eventually needs to be rolled back, the log entries that have been copied to follower nodes will not be applied to the state machine, meaning that they will not affect the underlying data storage. This is because these log entries are deemed as "uncommitted".
The Raft protocol uses the following mechanism to ensure that uncommitted log entries are not incorrectly applied:
Maintain commitIndex: The Raft protocol uses a variable named commitIndex to track the maximum index of committed log entries. Only when a log entry's index is greater than commitIndex is it considered committed. If a transaction is rolled back, commitIndex remains unchanged, thus preventing uncommitted log entries from being applied to the state machine.
Log truncation: In some cases, for example, during a failover, a newly elected leader node may need to truncate its log to ensure cluster consistency. The new leader node deletes "uncommitted" entries in the log and synchronizes these changes to follower nodes. In this way, log entries related to rollback transactions are removed from the entire cluster.
Through these mechanisms, the Raft protocol ensures data consistency and integrity of the cluster even in the case of transaction rollback.
What Is the Impact of TDStore Compaction on Performance?
The compaction process in TDStore mainly involves two actions: reading the upper-layer files, performing a sort-merge operation, and then writing the results to files in the lower layer or layers. This process primarily consumes CPU and I/O resources. Therefore, as long as the system has sufficient resources, the compaction process usually does not have a significant impact or even has no impact on business performance.
In addition, since TDStore adopts a natural distributed architecture, it can leverage the resources of all nodes for compaction. In comparison, in traditional leader/follower architectures, typically only the resources of the primary database are used for processing read-write operations (excluding read-write separation scenarios). Therefore, TDStore's distributed feature effectively addresses the potential need for preparing additional resources for compaction.
Concerns about the impact of compaction on performance largely stem from the relatively simple compaction policy in early RocksDB implementations, which triggered lasting concerns about the impact of compaction. However, with continuous version iterations, compaction policies have been greatly optimized, making the impact on performance more controllable.
How Is the Capability of TDStore to Support Disaster Recovery?
TDStore possesses diversified service high-availability technologies, including disaster recovery via multiple replicas within instances and disaster recovery via physical standby databases between instances.
Disaster recovery via multiple replicas within instances.
Three replicas in the same IDC: Three replicas in the same IDC form an instance, which can prevent minority node failures but cannot prevent IDC-level failures.
Intra-city three-replica and three-IDC: For scenarios with three IDCs for one city. Three IDCs in the same city form an instance (each IDC is an AZ), with network latency between IDCs generally ranging from 0.5ms to 2ms. This can prevent minority node failures and single IDC failures, but cannot prevent city-level failures.
Disaster recovery via physical standby databases between instances: Currently, TDStore has already possessed the intra-city and cross-city disaster recovery capabilities. It is able to synchronize data and switch primary-standby databases between two entirely independent instances. When the primary database becomes unavailable due to planned or unplanned events, the standby database can take over the service.
Note:
1. Applications that handle key business have high requirements for business continuity. For this reason, they should be at the same disaster recovery level as the database. Otherwise, business will be affected in case of a failure even if the database can quickly recover.
2. If you choose disaster recovery via physical standby databases between instances, note that: Data synchronization between primary/standby instances is near real-time. Two switching modes are available: switchover (planned switch) and failover (switch when a failure is detected). Switchover can avoid losses, while failover causes losses (when failover is executed forcibly, it may typically incur under 5 seconds of data losses, depending on the actual lag of standby instance synchronization).
Does TDStore Support JSON?
It supports JSON and the two aggregate functions: JSON_ARRAYAGG and JSON_OBJECTAGG. (Currently consistent with MySQL)
Does TDStore Support Foreign Keys and Global Indexes?
TDStore does not support foreign keys and global indexes. If you need to confirm whether migrating instances involves these features, contact technical support personnel to obtain a scan tool for judgment.
Does TDStore Support Access Over Public Network?
For security and performance considerations, TDStore instances currently only support access over VPC.
Why Does the Auto-Increment Field in TDStore Jump Values?
In the TDStore database, auto-increment fields are currently only guaranteed to be globally unique, and global auto-increment is not guaranteed.
To improve the assignment efficiency of auto-increment values, TDStore adopts a sharding cache mechanism. For example, for three compute nodes, they may cache a consecutive range of auto-increment values respectively:
Cache auto-increment range for node A: 1-100.
Cache auto-increment range for node B: 101-200.
Cache auto-increment range for node C: 201-300.
When the cached value of node A is exhausted, it will obtain the next available auto-increment range, such as 301-400. This mechanism ensures that auto-increment values can be quickly assigned even in a distributed environment, but it may also cause auto-increment value jumps because the cached values between different nodes are discontinuous.
What Should I Do If the System Prompts "Instance Version Verification Error. Upgrade the Kernel to the Latest Version and Try Again"?
The kernel of the TDStore engine is being continuously iterated and upgraded. If you encounter the above system prompt, submit a ticket to contact Tencent Cloud engineers to upgrade the engine kernel.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback