[ Question Category : Query Cache ] Hi, forks! Does StarRocks Shared-Data use a “write-through” cache policy? Specifically, when using ROUTINE LOAD, does StarRocks write to the cache first and then write to object storage? My understanding is that the data is written only to object storage, and the cache is populated after the first query (warm-up). However, I recently heard someone mention that it follows a write-through policy, so I wanted to confirm.

it will write through, so the later query will be able to hit the cache directly.

Then that means even without running any

SELECT queries

, the Local Volume (Cache Data) will keep increasing as ingestion happens, right? Since the ingested data becomes “hot data.” Is this the default behavior without any additional configuration? 👀

yes, it is

oh, thanks for apply, so I have questions 😅 --- Let’s say we currently have [CN-1] and [CN-2], and we add a new [CN-3]. Since CN-1 and CN-2 are using write-through, they will already have a warm cache (hot data), so we can expect a high cache hit rate. However, CN-3 will experience cache misses and a latency spike unless we explicitly warm its cache? 🤔 As far as I know, the FE Node tries to optimize cache hit rates by routing the same query patterns to the same CN nodes. If that’s the case, wouldn’t CN-3 naturally have lower cache hit rates compared to the existing nodes? 🤔

when CN-3 is joined the cluster, tablets will be balanced from cn-1/cn-2 to cn-3, these tablets will experience cache miss again until the cache get warmed up on cn-3.

oh.. I was planning to guarantee high

p99

performance

sub-second

by running

cache select

to pre-warm the cache on a CN node before joining it to the cluster. But since Tablet metadata rebalancing is handled by the FE node, it seems that the CN can only start warming up the cache after it has already joined the FE and received its tablet assignments. Is that correct?

yes, it is

In a shared-data architecture, it would be difficult to guarantee p99 performance during scale-in or scale-out operations, since cache hit rates will naturally drop. So in shared-data mode, the cache can be populated through the following three mechanisms: 1. Write-through caching, based on the tablets assigned to each CN node 2. Cache reloads on cache misses, when a CN has to fetch data from object storage 3. User-initiated pre-warming, using explicit

CACHE SELECT

operations Is my understanding correct?

yes, you are right, properly range the cn node scale-in/out along with cache select, could archive a stable p99 performance.

yes, you are right, properly range the cn node scale-in/out along with cache select, could archive a stable p99 performance.

I'm a bit confused by your earlier advice. 👀 If we have a user-facing query with continuously high traffic—let’s say around *1000 TPS*—then even if we issue a

CACHE SELECT

command to the FE node when a new CN node scales in or out, wouldn’t the assumption of a stable p99 latency still break? Is my understanding incorrect? 🤔

I mean, planned cn node scale-in/out during the non-busy hours, keep the cluster stable during busy hours.

Ah, I see. That makes sense. To achieve that, we could test the expected query patterns and traffic during non-busy hours to estimate the resulting p99 latency, and make adjustments accordingly. Of course, having well-prepared pre-aggregations with Async MVs would also help. Have you personally experienced achieving stable p99 performance in a shared-data setup using this kind of approach? 👀