What Are the Differences in Read/Write Performance Between TDSQL Boundless Engine and Native MySQL?
TDSQL Boundless is a native distributed database. It maintains consistency among replicas of data units via 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 massive write operations, delivering excellent performance especially in write-intensive, read-light business scenarios.
Compared with MySQL's InnoDB storage engine, TDSQL Boundless achieves a data compression ratio 3 to 9 times higher. This not only significantly reduces storage space requirements but can also improve write I/O performance. Consequently, TDSQL Boundless is particularly well-suited for scenarios that demand high write performance.
Is the Query Performance of TDSQL Boundless 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, TDSQL Boundless provides multiple mechanisms to enhance query performance:
1. Vertical/Horizontal Scaling: TDSQL Boundless can scale out database processing capacity by adding more nodes, thereby increasing queries per second (QPS). This capability cannot be achieved by standalone MySQL, as its performance is constrained by the hardware resources of a single server.
2. Optimization Policy: Even on a single node, TDSQL Boundless employs a series of optimization policies to enhance read performance:
Leveling Compaction: TDSQL Boundless stores all data, including primary keys and indexes, in a large, ordered key-value space. This data corresponds to multiple SST files on physical disks, organized into seven levels from L0 to L6. The Leveling Compaction policy ensures key uniqueness within each level except L0, which helps accelerate queries. The L0 level is special, allowing range overlaps between files. However, TDSQL Boundless limits the number of files in L0, typically to no more than four. When data needs to be accessed, TDSQL Boundless first checks the in-memory memtable. If the data is not in the memtable, it checks the SST files on disk in level order. Because keys are unique from L1 to L6, only one SST file per level needs to be checked to determine whether the target data exists.
Bloom Filter: When searching for data, TDSQL Boundless uses a Bloom filter to quickly exclude SST files that cannot contain the target key. This avoids unnecessary disk lookups, thereby saving resources.
Block Cache: TDSQL Boundless uses block cache to store hot data, reducing disk I/O operations and further improving read performance.
In summary, although LSM-tree-based systems are generally perceived as write-strong and read-weak, their read performance can fully meet the demands of various high-concurrency, low-latency online scenarios through a series of engineering optimizations. At the same time, thanks to its distributed architecture, TDSQL Boundless can achieve throughput exceeding one million operations per second with a single instance, a performance target unattainable by traditional architectures.
What Impact Does Compaction Have on the Performance of TDSQL Boundless?
The Compaction process in TDSQL Boundless primarily involves two actions: reading files from the previous level, performing a sort-merge operation, and then writing the results to files in the next level or levels. This process mainly consumes CPU and I/O resources. Therefore, as long as the system has sufficient resources, Compaction itself typically does not significantly impact business performance, and may even have no impact at all.
Furthermore, because TDSQL Boundless employs a natively distributed architecture, it can utilize the resources of all nodes for Compaction. This differs from traditional leader/follower architectures, where typically only the primary database's resources are used to handle read and write operations (disregarding read-write separation scenarios). Consequently, the distributed nature of TDSQL Boundless effectively mitigates the potential issue of needing to allocate 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.
Are There Performance Issues in TDSQL Boundless Read Scenarios? How to Determine the Location of a Data Shard?
In the TDSQL Boundless distributed database, read performance can be affected by data shards and query methods. The following are two common scenarios:
Queries with a partition key: If a query includes a partition key, TDSQL Boundless can directly route the query to the specific data shard containing that key. This approach is highly efficient because it avoids unnecessary data traversal and directly locates the correct data node.
Queries without a partition key: When a query does not specify a partition key, TDSQL Boundless needs to use a secondary index to locate the data. In this scenario, the system performs a scan query on the nodes containing the table data. This may cause a slight performance degradation because more data needs to be checked.
Does InnoDB Have the Same Performance as TDSQL Boundless Regarding Primary/Secondary Replication Lag in Large Transactions?
InnoDB and TDSQL Boundless exhibit different characteristics when handling primary/secondary latency issues caused by large transactions:
InnoDB: InnoDB uses binary logs (binlogs) 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.
TDSQL Boundless: TDSQL Boundless is a distributed database based on the Raft protocol, which synchronizes data between nodes in real time via Raft logs. In the Raft protocol, after receiving a client request, the Leader node first appends the request as a new log entry to its local log and then replicates it to Follower nodes. The Leader node responds to the client only after the log entry is replicated to a majority of nodes and marked as committed. This design effectively reduces the latency that large transactions might cause.
In TDSQL Boundless, the apply operation between primary and secondary nodes is almost never delayed. The only potential latency arises because a Follower node must 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 typically very short and negligible.
Additionally, TDSQL Boundless imposes a limit on transaction size, especially for delete operations. It is recommended to split large transactions into multiple smaller ones for execution. This helps prevent a single transaction from consuming excessive resources and reduces the impact on system performance.
In summary, compared to InnoDB, the Raft protocol synchronization mechanism of TDSQL Boundless provides lower primary/secondary latency when large transactions are handled, especially in high-concurrency and large-data-volume scenarios.