Technical Overview of Tencent Cloud CynosDB Distributed Storage and Compute‑Storage Separation Architecture
The Beijing technical exchange detailed Tencent Cloud CynosDB’s compute-storage separation architecture, explaining how CynosStore’s block and file-system layers asynchronously persist write-ahead logs via Raft, provide multi-transaction atomicity, continuous snapshots, and rapid recovery, while benchmarks demonstrate high log-throughput and the Q&A covered tenancy, failover, and scaling.
On March 16, Tencent Cloud + Community hosted a CynosDB technical exchange in Beijing, providing a comprehensive introduction to CynosDB, its architecture, high‑availability design, rapid recovery, compute‑intelligent storage, and distributed storage.
Download the PPT by replying "032" to the official WeChat of Cloud+ Community.
The speaker, the head of CynosStore (the distributed storage component of CynosDB), is responsible for database kernel development, product architecture, planning, and implementation.
I will share key technologies of CynosDB for PostgreSQL distributed storage. Historically, two main cluster models dominate the market: Google Spanner‑like and Amazon Aurora‑like architectures.
NewSQL aims to combine NoSQL’s massive scale, high throughput, elasticity, and automatic fault‑tolerance with SQL’s generality, complex query support, and distributed transactions. CynosDB achieves this by separating compute and storage, a concept we will detail further.
Traditional databases ensure consistency by using a write‑ahead log (WAL). The log is written sequentially (fast) while data pages are written randomly (slow). CynosDB’s storage layer can replay logs to generate new data pages, eliminating the need for the database to persist data pages itself. This is the core of our compute‑storage separation.
The storage system, CynosStore, provides two abstraction layers: a block‑device layer and a file‑system layer. The block layer presents a virtual disk to the database, while the file‑system layer offers a file‑system abstraction that is completely decoupled from the underlying shard distribution.
All write‑ahead logs from MySQL or PostgreSQL are asynchronously written to CynosStore, where they are serialized, persisted, and replicated via Raft. The database process only needs to write logs to CynosStore; concurrency control, ordering, and durability are handled by the storage layer.
The storage system supports Multi‑Transaction Records (MTR), which provide atomicity for multi‑page operations such as B‑Tree splits. Each MTR has a continuous log sequence number, and the final log entry is a VDL (Versioned Data Log).
Snapshots (backups) are created continuously. Full data snapshots and incremental log backups are taken per shard. Restoration involves locating a consistent LSN across all shards, replaying logs to that point, and rebuilding the pool.
Performance is measured with a custom benchmark that counts persisted logs per second. Operations include SetByte (write a byte range) and SetBit (modify a single bit).
The Q&A session covered tenancy model, automatic failover, Raft leader failure handling, storage expansion/reduction, and mapping consistency.
Download the PPT by replying "032" to the official WeChat of Cloud+ Community.
Recommended reading: Is Your Database Really Secure?
Follow the Cloud+ Community WeChat and reply 3 to join the reader group.
Tencent Cloud Developer
Official Tencent Cloud community account that brings together developers, shares practical tech insights, and fosters an influential tech exchange community.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.