To provide a more cost-effective database service for users in a multi-cloud environment, OceanBase Database implements a shared storage (SS) architecture based on a general-purpose object storage. In the shared-nothing (SN) architecture, the system caches hot data in memory to improve performance. In the SS architecture, in addition to memory caching, it also introduces local persistent caching to cache sub-hot data.
In the preceding figure:
Memory caching: caches the most hot data, such as microblocks and index data.
Persistent caching: the storage medium can be a local physical disk or cloud disk, and is used to cache sub-hot data. Its main functions include:
Caching data read from object storage.
Pre-reading data. For example, during a full table scan, data to be read is cached locally in advance.
Preheating. Before a major compaction, hot data is loaded to local caching. After a short downtime and restart, persistent caching remains effective, reducing performance jitter in disaster recovery scenarios.
To ensure RTO, the access sequence of local persistent caching is synchronized in real time to follower replicas. Leader and follower replicas have nearly identical cached data. During replication migration, local cached data is also transferred to the destination to ensure performance after migration.
Write caching. Local disks are used as write caching to record important local states, such as meta files, the latest clogs, and mini dumps.
Object storage: stores all data of the system, including shared clogs and baseline data across the cluster, as well as node-private data written when local physical disks or cloud disks are full, such as incremental data and temporary files. Object storage has almost unlimited capacity but has high access latency.
The above multi-tier caching ensures the access performance of hot data and provides a product form that meets both TP and AP business requirements based on object storage.