Overview

Database caching is a performance enhancement technique that stores frequently accessed data in high-speed memory, reducing reliance on slower disk storage and significantly improving query response times.

Preloading data into caches before the database is actively used is known as a warm-up. Without warming up, data is only loaded into caches when it is first accessed by a query, which can cause delays in performance until the data is cached.

Cache data is temporarily stored in memory and is cleared either when the server restarts or through manual clearance. After a restart, caches can be reloaded using the warm-up operation, or when the data is accessed by a query, as long as the corresponding cache type is enabled.

Cache Types

Caches can store various types of data. Ultipa supports the following cache types:

• Graph cache: Contains the graph topology, speeding up graph traversal.
• Node cache: Includes the LTE-ed node properties, accelerating node filtering.
• Edge cache: Includes the LTE-ed edge properties, accelerating edge filtering.

Cache Sizes and Eviction Strategies

The cache sizes for graph, node, and edge caches are defined by graph_cache_size, node_cache_size, and edge_cache_size settings. Once a cache reaches its size limit, data is evicted according to the selected strategy. The graph cache can use one of three strategies: lru, unlimited, or noeviction, while node and edge caches default to lru. These settings are configured in the Server Configurations.

Cache Type Status

You can view the status of a cache type for all shard servers using the cache.<cacheType>.status() statement.

// Views graph cache status
cache.graph.status()

// Views node cache status
cache.node.status()

// Views edge cache status
cache.edge.status()

It returns tables _cache_shard_1, _cache_shard_2 and so on. Each table _cache_shard_<N> contains information about the cache type for the shard with id <N>, and includes the following fields:

Turning On a Cache Type

You can turn on a cache type for all shard servers using the cache.<cacheType>.turnOn() statement. This operation runs as a job, you may run show().job(<id?>) afterward to verify the success of the completion.

This operation aligns with the enable_graph_cache, enable_node_cache, and enable_edge_cache settings defined in Server Configurations. Note that these settings will revert to their original configuration upon server restart.

// Enables graph cache for all leader replicas across all graphsets
cache.graph.turnOn()

// Enables graph cache for both leader and follower replicas across all graphsets
cache.graph.turnOn({followers: true})

// Enables node cache for all leader replicas across all graphsets
cache.node.turnOn()

// Enables node cache for both leader and follower replicas across all graphsets
cache.node.turnOn({followers: true})

// Enables edge cache for all leader replicas across all graphsets
cache.edge.turnOn()

// Enables edge cache for both leader and follower replicas across all graphsets
cache.edge.turnOn({followers: true})

Turning Off a Cache Type

You can turn off a specific cache type for all shard servers using the cache.<cacheType>.turnOff() statement.

This operation aligns with the enable_graph_cache, enable_node_cache, and enable_edge_cache settings defined in Server Configurations. Note that these settings will revert to their original configuration upon server restart.

// Disables graph cache for all leader replicas across all graphsets
cache.graph.turnOff()

// Disables graph cache for both leader and follower replicas across all graphsets
cache.graph.turnOff({followers: true})

// Disables node cache for all leader replicas across all graphsets
cache.node.turnOff()

// Disables node cache for both leader and follower replicas across all graphsets
cache.node.turnOff({followers: true})

// Disables edge cache for all leader replicas across all graphsets
cache.edge.turnOff()

// Disables edge cache for both leader and follower replicas across all graphsets
cache.edge.turnOff({followers: true})

Warming Up

You can load data from the current graphset into caches using the cache.<cacheType>.warmup() statement. The warm-up runs as a job, you may run show().job(<id?>) afterward to verify the success of the completion. This operation consumes memory and can only be performed when the corresponding cache type is enabled.

// Loads graph topology into cache for the leader replica
cache.graph.warmup()

// Loads graph topology into cache for both leader and follower replicas
cache.graph.warmup({followers: true})

// Loads all LTE-ed node properties into cache for the leader replica
cache.node.warmup()

// Loads all LTE-ed node properties into cache for both leader and follower replicas
cache.node.warmup({followers: true})

// Loads all LTE-ed edge properties into cache for the leader replica
cache.edge.warmup()

// Loads all LTE-ed edge properties into cache for both leader and follower replicas
cache.edge.warmup({followers: true})

Clearing Cache

You can clear cache of the current graphset using the cache.<cacheType>.clear() statement. This operation frees up memory.

// Clears graph topology from cache for the leader replica
cache.graph.clear()

// Clears graph topology from cache for both leader and follower replicas
cache.graph.clear({followers: true})

// Clears all LTE-ed node properties from cache for the leader replica
cache.node.clear()

// Clears all LTE-ed node properties from cache for both leader and follower replicas
cache.node.clear({followers: true})

// Clears all LTE-ed edge properties from cache for the leader replica
cache.edge.clear()

// Clears all LTE-ed edge properties from cache for both leader and follower replicas
cache.edge.clear({followers: true})

Server Configurations

The caching settings are located in the ComputeEngine section of each shard server' configuration file. The following related items control how different types of caches are managed, including enabling or disabling caches, setting cache sizes, and defining eviction policies: