Release Notes
Product Introduction
- Overview
- Scenarios
- Product Architecture
- Instance Types
- Compatibility Notes
- Usage specification recommendations
Kernel Features
- Kernel Overview
- Kernel Version Release Notes
- Functionality Features
- Performance Features
Billing
Getting Started
- Creating an Instance
- Connect to Instances
User Guide
- Use Limits
- Data Migration
- Data Subscription
- Instance Management
- Configuration Change
- Parameter Configuration
- Account Management
- Security Group
- Backup and Restoration
- Tag Management
Use Cases
Developer Guide
- Developer Guide (MySQL Compatibility Mode)
- Developer Guide (HBase Compatibility Mode)
Performance Tuning
- Performance Tuning Overview
- SQL Tuning
- DDL Tuning
Performance White Paper
API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- Security Group APIs
- Task APIs
- Backup APIs
- Rollback APIs
- Parameter APIs
- Database APIs
- Data Types
- Error Codes
General Reference
- System Architecture
- SQL Reference
- Database Parameter Description
- TPC-H benchmark data model reference
- Error Code Information
Security and Compliance
FAQs
Agreements
Contact Us
Glossary

Performance Optimization Points

Baixar

Modo Foco

Tamanho da Fonte

Última atualização: 2026-05-26 11:28:34

TDStore introduces multiple self-developed optimizations based on the native RocksDB BlobDB. Most of these optimizations are disabled by default and are enabled by DBAs only when further performance improvement is needed or specific issues need to be resolved. The following table lists only the features and their value.
Optimizations
Problem Solved
Business Benefit
Active GC Based on Garbage Ratio
The native RocksDB GC selects files based solely on "age", potentially leaving valid data in old files.
More precise reclamation and more efficient disk space usage
GC Priority Metadata
Active GC requires persisting the "which blobs need more urgent garbage collection" marker, which is absent in the native BlobDB.
GC progress is preserved after restart, and DBAs can intervene with urgent blobs.
Small Blob File Merging
Frequent Compaction generates a large number of fragmented small Blob files.
Reduced number of files and lower metadata overhead
Direct Copy for Blob GC
The default GC requires decompressing and then recompressing Blob data.
GC CPU overhead is significantly reduced (benchmark shows approximately 1.5x speedup for 5KB values and 1.4x for 10KB values).
Optimization of Blob Write Sync
RocksDB's default behavior of forcing a RangeSync every 1MB becomes a bottleneck on modern SSDs.
Blob write IOPS is increased and tail latency is reduced.
Lazy Loading of Blob Values
During range scans, the iterator preloads Blobs even if the Value is ultimately not read.
Improved range scan performance (for example, SELECT COUNT(*), uniqueness verification)
DeleteRange Acceleration
Bulk range deletion updates Blob reference counts one by one.
Faster bulk deletion
Shared Blob Cache
By default, there is no Blob Cache, so every Blob read is a disk I/O.
Reduced latency for hot Blob reads (requires restart)
Starting Level for Blob
Data in the upper levels (L0/L1) is short-lived, and separating it actually increases GC pressure.
Separation starts from L1 by default for a more balanced state.
Setting Compression Algorithm by Level
Data at different levels has varying hot/cold characteristics, making uniform compression inflexible.
Cold data can be strongly compressed using ZSTD to save space.
Location of Optimization Points in the Data Flow
﻿
Note:
The nodes highlighted in yellow (Blob File / Blob Cache / Active GC) are the core locations where the aforementioned ten optimizations take effect.

Ajuda e Suporte

Esta página foi útil?

Você também pode entrar em contato com a Equipe de vendas ou Enviar um tíquete em caso de ajuda.

comentários

tencent cloud

TDSQL Boundless

Performance Optimization Points

Ajuda e Suporte

Optimizations	Problem Solved	Business Benefit
Active GC Based on Garbage Ratio	The native RocksDB GC selects files based solely on "age", potentially leaving valid data in old files.	More precise reclamation and more efficient disk space usage
GC Priority Metadata	Active GC requires persisting the "which blobs need more urgent garbage collection" marker, which is absent in the native BlobDB.	GC progress is preserved after restart, and DBAs can intervene with urgent blobs.
Small Blob File Merging	Frequent Compaction generates a large number of fragmented small Blob files.	Reduced number of files and lower metadata overhead
Direct Copy for Blob GC	The default GC requires decompressing and then recompressing Blob data.	GC CPU overhead is significantly reduced (benchmark shows approximately 1.5x speedup for 5KB values and 1.4x for 10KB values).
Optimization of Blob Write Sync	RocksDB's default behavior of forcing a RangeSync every 1MB becomes a bottleneck on modern SSDs.	Blob write IOPS is increased and tail latency is reduced.
Lazy Loading of Blob Values	During range scans, the iterator preloads Blobs even if the Value is ultimately not read.	Improved range scan performance (for example, `SELECT COUNT(*)`, uniqueness verification)
DeleteRange Acceleration	Bulk range deletion updates Blob reference counts one by one.	Faster bulk deletion
Shared Blob Cache	By default, there is no Blob Cache, so every Blob read is a disk I/O.	Reduced latency for hot Blob reads (requires restart)
Starting Level for Blob	Data in the upper levels (L0/L1) is short-lived, and separating it actually increases GC pressure.	Separation starts from L1 by default for a more balanced state.
Setting Compression Algorithm by Level	Data at different levels has varying hot/cold characteristics, making uniform compression inflexible.	Cold data can be strongly compressed using ZSTD to save space.