캐시 세 가지 (결과 캐시, 로컬 디스크 캐시, 메타데이터)
Snowflake 의 결과 캐시, 웨어하우스 로컬 디스크 캐시, 메타데이터 캐시가 각각 어디에 있고 언제 쓰이는지, 캐시를 살리는 설정과 깨는 습관, 성능 테스트할 때 캐시를 끄는 방법을 정리합니다.
세 가지 캐시 비교
| 캐시 | 위치 | 유지 기간 | 비용 | 쓰이는 조건 |
|---|---|---|---|---|
| 결과 캐시 | 클라우드 서비스 계층 | 마지막 사용 후 24시간, 다시 쓰일 때마다 연장, 최대 31일 | 웨어하우스 크레딧 없음 | 같은 쿼리 문장, 바뀌지 않은 데이터, 권한 있음 |
| 로컬 디스크 캐시 | 웨어하우스 노드의 SSD 와 메모리 | 웨어하우스가 켜져 있는 동안 | 웨어하우스가 켜져 있어야 함 | 같은 웨어하우스가 같은 파티션을 다시 읽을 때 |
| 메타데이터 | 클라우드 서비스 계층 | 항상 | 없음 (클라우드 서비스) | COUNT(*), MIN, MAX 등 통계로 답할 수 있을 때 |
결과 캐시
쿼리 결과를 24시간 동안 들고 있다가, 같은 쿼리가 다시 들어오면 웨어하우스를 깨우지 않고 바로 돌려줍니다. 결과가 다시 쓰일 때마다 24시간이 연장되고, 처음 실행부터 최대 31일까지 유지됩니다.
결과 캐시가 쓰이려면 다음을 모두 만족해야 합니다.
- 쿼리 문장이 글자 그대로 같아야 합니다. 공백이나 대소문자, 별칭이 달라도 다른 쿼리로 봅니다.
- 쿼리가 읽는 테이블의 데이터가 바뀌지 않았어야 합니다. 마이크로 파티션이 하나라도 바뀌면 무효입니다.
CURRENT_TIMESTAMP(),RANDOM(),UUID_STRING()같은 실행마다 값이 바뀌는 함수가 없어야 합니다. (CURRENT_DATE()는 예외로 허용됩니다)- 외부 함수, 일부 UDF 를 쓰지 않아야 합니다.
- 실행하는 역할이 원래 테이블을 읽을 권한이 있어야 합니다. 결과 캐시는 역할과 상관없이 공유되지만 권한 확인은 매번 합니다.
-- 세션에서 결과 캐시 끄기 (성능 테스트, 벤치마크)
ALTER SESSION SET USE_CACHED_RESULT = FALSE;
-- 바로 직전 결과를 다시 거르기 (웨어하우스 거의 안 씀)
SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) WHERE amount > 1000;팁 BI 도구가 대시보드를 열 때마다 같은 SQL 을 보낸다면 결과 캐시가 크게 효과를 냅니다. 대시보드 쿼리에
CURRENT_TIMESTAMP()를 넣는 습관만 고쳐도 웨어하우스가 깨어나는 횟수가 줄어듭니다.
로컬 디스크 캐시 (웨어하우스 캐시)
웨어하우스가 원격 스토리지에서 읽은 마이크로 파티션 파일은 노드의 SSD 와 메모리에 남습니다. 같은 웨어하우스가 같은 파티션을 다시 읽으면 원격으로 가지 않고 로컬에서 읽어 빨라집니다. Query Profile 의 Percentage scanned from cache 가 이 비율입니다.
- 웨어하우스가 일시 중지되면 캐시가 사라집니다. 다시 켜면 처음부터 원격으로 읽습니다.
- 크기를 바꾸면 늘어난 노드는 빈 캐시로 시작합니다.
- 멀티 클러스터에서는 클러스터마다 캐시가 따로입니다.
AUTO_SUSPEND 와 캐시의 줄다리기
| 워크로드 | 권장 AUTO_SUSPEND | 이유 |
|---|---|---|
| 배치 적재, 일회성 변환 | 60초 | 캐시 재사용이 거의 없음, 빨리 꺼서 크레딧 절약 |
| 사람이 쓰는 BI 대시보드 | 300~600초 | 연달아 들어오는 비슷한 쿼리가 캐시 덕을 봄 |
| 계속 쿼리가 오는 서비스 | 끄지 않는 것과 비슷하게 길게 | 캐시를 유지해 지연 시간을 낮춤 |
웨어하우스는 켤 때마다 최소 60초가 과금되므로 AUTO_SUSPEND 를 60초 아래로 내리는 것은 대개 의미가 없습니다. 생성 기본값은 600초입니다.
메타데이터로 답하는 쿼리
-- 웨어하우스 없이 클라우드 서비스만으로 끝나는 예
SELECT COUNT(*) FROM sales.orders;
SELECT MIN(order_date), MAX(order_date) FROM sales.orders;Query Profile 에 METADATA-BASED RESULT 가 보이면 메타데이터만으로 답한 것입니다. 조건이 붙거나 다른 집계가 섞이면 웨어하우스가 필요합니다.
캐시와 성능 테스트
새 웨어하우스 크기나 Gen2 를 비교할 때 캐시가 섞이면 결과가 왜곡됩니다.
USE_CACHED_RESULT = FALSE로 결과 캐시를 끕니다.- 웨어하우스를
ALTER WAREHOUSE ... SUSPEND후RESUME해서 로컬 캐시를 비웁니다. - 같은 쿼리를 여러 번 돌려 첫 실행(콜드)과 이후(웜)를 따로 기록합니다.
QUERY_HISTORY의BYTES_SCANNED,PERCENTAGE_SCANNED_FROM_CACHE,EXECUTION_TIME을 비교합니다.
SELECT query_id, warehouse_name, warehouse_size,
execution_time / 1000 AS exec_sec,
bytes_scanned, percentage_scanned_from_cache
FROM snowflake.account_usage.query_history
WHERE query_tag = 'bench_2026_10'
ORDER BY start_time;자주 하는 오해
- "결과 캐시는 내 역할만 쓴다": 아닙니다. 같은 계정에서 같은 쿼리를 읽을 권한이 있는 사용자는 결과 캐시를 함께 씁니다.
- "웨어하우스를 키우면 캐시도 그대로": 늘어난 노드는 비어 있고, 줄일 때는 빠지는 노드의 캐시가 사라집니다.
- "캐시 덕에 빠른 것을 성능이 좋다고 판단": 운영 첫 실행은 콜드인 경우가 많습니다. 콜드 성능으로 크기를 정합니다.
트러블슈팅
- 증상: 대시보드를 새로 고칠 때마다 웨어하우스가 깨어납니다.
- 원인: 쿼리 안에 실행마다 바뀌는 함수가 있거나, BI 도구가 쿼리에 주석과 타임스탬프를 붙입니다. 또는 원본 테이블이 몇 분마다 적재되어 결과 캐시가 계속 무효가 됩니다.
- 해결: 시간 조건은
CURRENT_DATE()기준으로 바꾸고, 자주 적재되는 원본 대신 Dynamic Tables 로 만든 집계 테이블을 대시보드가 읽게 합니다.