Recently, PingCAP, an enterprise-level open source distributed database vendor, officially released TiDB 7.1, which is also the first LTS (Long Term Support) version released in 2023, bringing together functional enhancements, cumulative optimizations and fixes from 20+ real scenarios 140+ features designed to improve business-critical stability and performance, help developers and database administrators increase productivity and further reduce total cost of ownership (TCO). Users can use TiDB 7.1 in the production environment.
TiDB semi-annual version review
TiDB 7.1 LTS has been half a year since the last LTS version 6.5. During this period, PingCAP has made a lot of enhancements and optimizations to the key capabilities of the product. The most important features are:
● TiDB 7.0 provides resource control based on resource groups (Resource Control) : This enables TiDB to respond well to multi-tenant scenarios. In fact, users often hope to integrate multiple business systems into one cluster with the help of TiDB's scalability, so that cluster management and resource utilization can be effectively improved. The resource management and control feature provides support for multi-tenants and solves the problem of resource contention among different tenants. In the new version, users can easily use this function to improve the usage scenarios of database integration.
● Multi-RocksDB feature : By splitting the RocksDB in a single TiKV instance into multiple shares, the write throughput of TiKV is increased by nearly three times; The overhead caused by small maintenance fragments reduces the fixed CPU consumption required for unit storage and saves costs. This makes TiDB's performance substantially improved in data serving scenarios where large write throughput or a large amount of warm data needs to be stored.
These important heavyweight features will continue to be polished and strengthened in new versions. In the past six months, the performance of TiDB in some key scenarios has also been greatly improved:
● The performance of data import into Lightning has been improved by nearly 30% ;
● Under the real business test, the performance of Analyze Table is improved by 42%+ ;
● Under the standard test TPC-H and the real business test, TiDB’s analysis capabilities were increased by 15% and 25% respectively ;
● TiCDC can improve the performance of large single-table replication by up to 90%+ .
TiDB 7.1 Features
TiDB 7.1 is the first of two long-term support (LTS) releases that PingCAP plans to release in 2023, providing a future-proof database that can power a variety of business-critical applications. TiDB 7.1 will bring the following features to users:
● Support key business loads more stably , provide DBA with multi-workload stability control, and significantly improve tail delay;
● Provide better performance with fewer resources , achieve higher throughput and faster online DDL through architectural enhancements.
In addition, TiDB 7.1 Enterprise Edition has enhanced the database auditing function, which greatly improves the system's auditing capabilities through finer-grained event filtering control, more friendly filter condition setting methods, new JSON file output format, and audit log lifecycle management .
2.1 More stable support for key business loads
2.1.1 Improve the user experience of resource management and control through resource groups to provide better isolation
PingCAP has added the function of resource management and control through resource groups in TiDB 7.0, laying the foundation for the TiDB database consolidation (database integration) solution, which is a milestone. Multiple businesses can share the same TiDB cluster, and the DBA can set resource quotas and priorities for different workloads, such as assigning higher priorities to key businesses to ensure that they can obtain resources first and avoid interference from other workloads.
In TiDB 7.1, the resource management and control feature is officially GA, and two feature enhancements have been added:
● Reduced tail latency in heavy write-intensive workloads: Resource groups control workloads through resource quotas and priorities. Priority is controlled by storage class. When the workload is heavily written, the priority-based rescheduling mechanism sometimes causes higher tail latency (Tail Latency). In version 7.1, tail lag was corrected to expected levels.
● Add native load calibration tools to help users set more accurate resource allocation: the basis of resource allocation is that users have an understanding of load resource usage. The newly added calibration tool will help you evaluate relevant information to allocate resource groups reasonably. The fastest way is to run calibration commands from the SQL interface to estimate resource usage for benchmarks such as TPC-C and sysbench.
2.1.2 Improved performance and stability in multiple hotspot scenarios
There are three key enhancements to TiKV, TiDB's underlying row store, to reduce latency and improve stability (measured by p99 latency). The new version introduces three optimizations to deal with hotspots at three levels: Key level, Fragment (Region) level and Node level:
● Key-level hotspot: lock conflict optimization
● Region-level hotspot: batch processing of TiKV subtasks
● Node-level hotspots: introduces load-based replica reads
Lock conflict optimization (GA)
TiDB introduces optimizations for handling key-level hotspots. In loads that encounter many single-point pessimistic lock conflicts, the algorithm for waking up waiting requests will be more stable in the new version, minimizing the resource waste of retries, thus saving resources of the entire cluster and reducing tails. Delay. Tests have shown that when lock conflict optimization is enabled, the new version reduces tail latency by 40-60% even in the most conflict-heavy workloads when throughput is relatively small.
Batch TiKV subtasks (GA)
Queries that are less selective can result in a lot of data being read. In TiDB's distributed storage-computing separation architecture, such a query may bring tens of thousands or hundreds of thousands of RPC requests to obtain data. If index reading is used, this burden will be further aggravated.
As a TiKV client, the TiDB server can now identify batch tasks for the same shard and send these batches to the corresponding storage nodes. This greatly reduces RPC overhead on the network, making these queries more stable. This enhancement can reduce latency in corresponding scenarios by up to 50%.
Load-Based Replica Reads (GA)
This feature is used to optimize node-level read hotspots. Node hotspots can occur when large batches of queries initiate reads in an uneven manner. Common things like injecting Index Lookup JOINs can cause this. Once that happens, read requests are queued, and when the queue fills up, some requests may wait a considerable amount of time. PingCAP hopes to reduce latency by distributing work more evenly.
In the new version, TiDB introduces load-based replica reading to achieve this. It provides a configurable duration threshold for the queue, which when exceeded tells TiDB to start prioritizing replica reads. In the case of read hotspots, this function can increase the read throughput by 70% to 200% compared with undistributed read hotspots.
2.2 Fewer resources, better performance
TiDB 7.1 improves the performance of TiDB read, write and management operations to provide a better user experience. In the new version, TiDB adds a multi-value index to improve query efficiency for JSON. Additionally, numerous improvements and optimizations have been made in write throughput, analytical query speed, and background task efficiency.
2.2.1 Multi-valued indexing (GA) for increased speed and flexibility
Multi-value index is also called "JSON index", this new type of auxiliary index was introduced in TiDB 6.6 and GA in 7.1. Multi-valued indexes support an N:1 mapping of index records to data records, enabling queries to quickly check for specific values stored in JSON arrays.
Whether this data is stored as a blob, or the zip codes are stored directly as a zip array, users can create a multi-valued index to locate which row a particular zip code exists in.
Indexes are created using expressions that logically parse JSON data into a Generated Column and a secondary index on that column. If a user stores JSON as a blob and needs to support queries that traverse multiple levels of nesting, just create an index for retrieval.
2.2.2 Faster TTL (GA)
TTL (Time to live) was introduced as an experimental feature in PingCAP's TiDB 6.5, and this feature is GA in 7.1. In addition, in the new version, TiDB nodes can share TTL-related tasks and execute them concurrently, resulting in better performance and resource utilization.
2.2.3 Latency Materialization Accelerated Analysis Query (GA)
TiFlash is TiDB's columnar storage engine. In version 7.1, the delayed materialization feature is GA. When the table scan has high filterability, the TiDB optimizer can choose to enable TiFlash to enable lazy materialization. After enabling this feature, TiFlash supports pushing down part of the filter conditions to the TableScan operator, that is, to scan the column data related to the filter conditions first, and then scan the other column data of these rows to continue subsequent calculations, thus reducing Computational amount of IO scanning and data processing.
The impact of this feature depends on the actual load and data distribution. In some cases, it can significantly reduce latency (up to 70% lower latency in PingCAP's tests). TiDB's query optimizer can decide whether to use it, and it is safe to enable it by default.
2.2.4 Multi-RocksDB storage engine brings huge performance improvement
In TiDB 6.6, PingCAP introduces major changes to the TiKV storage architecture. While this architecture is still experimental (off by default and only enabled on new clusters), in this LTS release the feature has been significantly enhanced and has received good test feedback in pre-production environments.
Before TiDB 6.6, all Regions of a single TiKV node shared a RockDB storage engine. The new architecture stores different Regions in different RocksDBs. The benefits of the new architecture are significant:
● Reduce the load of LSM corresponding to RocksDB and increase the throughput. The test results show that the write throughput has increased by 200% .
● Using different RocksDBs will also reduce write amplification caused by compaction and reduce resource consumption.
● Better write throughput increases the cluster's scaling speed by 500% .
● When testing some real customer workloads, PingCAP observed a nearly 50% reduction in tail latency .
● Smaller unit storage consumption further enhances cluster scalability.
In TiDB 7.1, PingCAP further improves the performance and stability of this feature, and adds network bandwidth optimization. What is still missing is the support of ecological tools such as TiCDC and BR. When these are completed, PingCAP will announce this feature as GA.
2.2.5 Significant improvement of Online DDL (experimental feature)
In TiDB 7.1, similar to the aforementioned TTL improvements, PingCAP introduces a framework for distributing DDL jobs across TiDB nodes to further improve performance.