@Rocky if i am setting up a multi tenant environment, can I set priority of cache eviction ? I want cache from one type of workload to be prioritized over other ? I want to check all types of cache - query and data both.

In StarRocks, there is no direct setting to assign a "priority" for cache eviction to specific workloads or resource groups. Both the Data Cache (disk-based) and Query Cache (memory-based) are managed as global resources on each node. However, you can achieve your goals for a multi-tenant environment using the following strategies: 1. Data Cache (Block Cache) The Data Cache (used for data lake and shared-data clusters) does not support per-workload priority, but it provides mechanisms to protect hot data: * SLRU (Segmented LRU) Policy: In StarRocks v3.4.0+, the default eviction policy is

slru

(controlled by

datacache_eviction_policy

). SLRU divides the cache into "eviction" and "protection" segments. Data only moves to the protection segment after being accessed multiple times. This prevents one-off large scans (e.g., an ETL workload) from immediately evicting the "hot" data used by a high-priority dashboard. * Physical Isolation (CN Groups): In shared-data (cloud-native) architectures, the most effective way to prioritize one workload's cache is to use separate Compute Node (CN) groups. You can point a specific Resource Group to a dedicated set of CN nodes. Since each CN node has its own local disk cache, the workloads will not compete for the same cache space. * Time-based Prioritization: You can use the table property

datacache.partition_duration

to only cache data within a certain time window (e.g., the last 7 days). This ensures that "old" data from background workloads doesn't take up space that could be used by "fresh" data. * Manual Warmup: You can use

CACHE SELECT

to proactively load data into the cache for a specific tenant before they start their workday, though this doesn't protect it from later eviction if the disk fills up. 2. Query Cache The Query Cache (Result Cache) is managed by the FE or BE using a global memory limit: * Eviction Policy: It uses a standard

LRU

(Least Recently Used) policy. * No Multi-tenant Quotas: There are currently no settings to reserve portions of the Query Cache for specific users or resource groups. If one tenant runs many unique queries, they could theoretically evict the cached results of another tenant. * Control: You can enable or disable Query Cache at the session level (

SET enable_query_cache = true/false

). You might consider disabling it for heavy ETL workloads to prevent them from "polluting" the cache with results that are unlikely to be reused. Summary for Multi-tenant Environments If you need strict cache isolation where one tenant's activity cannot evict another's: 1. Use separate CN groups for the different tenants/workloads. 2. Use Resource Groups to route the specific tenants to their respective CN groups. 3. For shared clusters, rely on the

slru

policy to protect hot data from "bursty" or "heavy scan" workloads. If you have specific performance issues with cache contention, you may want to check the official StarRocks Documentation on Resource Management or discuss your architecture with the community on Slack. References • faq/resource_isolation_faq.md • administration/management/resource_management/resource_group.md • administration/management/monitoring/metrics.md

@Rocky You can point a specific Resource Group to a dedicated set of CN nodes. - this is availble in which starrocks version?

In StarRocks, the ability to "point a workload to a dedicated set of nodes" and "prioritize cache eviction" depends on the cluster architecture and version. 1. Can you set priority for cache eviction? There is no direct "priority" setting (e.g., High/Medium/Low) for cache eviction in either the Query Cache or Data Cache. Eviction is globally managed: * Query Cache (Result Cache): Uses a standard LRU (Least Recently Used) policy based on memory limits. You cannot reserve a portion of this cache for specific tenants. * Data Cache (Disk Cache): Uses an SLRU (Segmented LRU) policy (v3.4.0+). This naturally protects "hot" data from being evicted by one-off large scans, but it does not distinguish between different tenants or workloads. 2. Pointing Workloads to Dedicated Nodes (Compute Groups) The feature you are describing—mapping specific workloads or resource groups to dedicated sets of compute nodes—is known as Compute Groups or Multi-warehouse. * Availability: This is primarily an Enterprise / Managed feature (available in CelerData Cloud, CelerData Enterprise, and EMR Serverless StarRocks). * Version: It was introduced in StarRocks v3.1 (Enterprise Edition) and refined in v3.3+. * How it works: You create separate Compute Groups (sets of CN nodes). You can then route queries to a specific group using the session variable

SET warehouse = 'group_name';

. Since each group has its own local disks, the Data Cache is physically isolated. 3. Solutions for Multi-tenant Isolation If you are using the Open Source (Community) Edition, you have two main strategies for multi-tenancy: A. Resource Groups (v2.2+) Standard Resource Groups allow you to limit CPU and Memory per tenant, but they apply uniformly across all nodes in the cluster. * Pros: Easy to set up; prevents one tenant from hogging all CPU/RAM. * Cons: No cache isolation. A heavy scan from Tenant A can still evict the hot data cache used by Tenant B because they share the same physical disks/nodes. B. Multiple Clusters (Shared-Data Architecture) Since StarRocks v3.0+ supports a shared-data (cloud-native) architecture where data is stored in S3/HDFS: * You can deploy two separate StarRocks clusters (with their own FEs and CNs) pointing to the same remote storage. * Tenant A uses Cluster 1; Tenant B uses Cluster 2. * This provides 100% isolation for both Query and Data Cache, as each cluster has its own independent compute and local disk cache. Summary Feature | OS / Community | Enterprise / Managed | Version Resource Isolation (CPU/Mem) | Yes (Resource Groups) | Yes | v2.2+ Physical Cache Isolation | Multiple Clusters | Yes (Warehouses) | v3.1+ Cache Eviction Priority | No | No | N/A For strict multi-tenant environments where you want to protect the cache of one workload from another, we recommend using the shared-data architecture with either separate clusters (OS) or Compute Groups (Enterprise). References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • deployment/shared_data/feature-support-shared-data.md References • release_notes/release-3.1.md