Overview of custom hot data caching strategies

In OceanBase Database's shared storage mode, full data is stored in cost-effective object storage, while frequently accessed or actively used hot data is cached locally to accelerate business queries. Caching hot data is an effective method to optimize storage costs and database performance. By default, the system dynamically caches hot data (frequently accessed) and evicts cold data (infrequently accessed) based on access frequency and data generation time. However, for sensitive queries, this automatic identification of hot and cold data can introduce unexpected latency (RT jitter) during queries.

In scenarios with clear hot and cold data patterns, such as time-series data, users can define custom hot data caching strategies. By specifying hot data ranges based on business characteristics (e.g., time boundaries), users can overcome the limitations of automatic hot/cold data identification, enhancing performance predictability. Pre-caching hot data locally ensures consistent query performance and avoids RT jitter during queries.

Applicable scenarios

• Time-sensitive business: such as businesses that only need to view recent data.
• Businesses with high requirements for RT stability: such as businesses that frequently access data in a specific range and are sensitive to query latency.

Hot data caching mechanism

• Data attribute types:

  • HOT: Data is hot data, and will be cached locally as much as possible. If the local storage capacity allows, all hot data will be cached locally.

  • AUTO: The system automatically identifies data as hot or cold based on access frequency and dynamically prefetches and caches the data.

  • NONE: Inherit the cold/hot caching strategy from the parent entity (such as the main table). For example, if the caching strategy of a local index is NONE, it dynamically inherits the strategy from the main table.

    Note

    When the hot cache strategy follows the value of STORAGE_CACHE_POLICY from the parent level, the following applies:

    • The parent level of a subpartition is the partition.
    • The parent level of a partition is the table level.
    • The parent level of an index table is the main table.

• Priority mechanism:

  • User-specified hot data has a higher priority than automatically identified hot data.

Support for hot cache policies

• OceanBase Database supports defining hot cache policies for tables (user tables and index tables) at the table and partition levels when you create tables in shared storage mode:

  • You can specify the table-level and partition-level STORAGE_CACHE_POLICY parameter when you create a table.
  • You can modify the table-level and partition-level STORAGE_CACHE_POLICY parameter for a table.

• OceanBase Database allows you to configure global hot cache policies:

  • You can configure the default cache policy by using the default_storage_cache_policy parameter.
  • You can enable user-defined hot cache policies by using the enable_manual_storage_cache_policy parameter.
  • You can pause background cache tasks by using the suspend_storage_cache_task parameter.

• OceanBase Database provides views for viewing cache policies:

  • You can query the V$OB_TABLET_LOCAL_CACHE view to obtain the overall cache information of each tenant on the current OBServer node.
  • You can query the V$OB_STORAGE_CACHE_TASKS view to obtain the cache task information of each tenant on the current OBServer node.

References

• Shared storage multi-level cache
• Create a table-level hotspot cache policy
• Create a partition-level hotspot cache policy
• Modify a table-level hotspot cache policy
• Modify a partition-level hotspot cache policy
• O&M guide for custom hotspot cache policies