クイズ: スキッピングインデックスとプロジェクション

운영 중인 표에 ALTER TABLE t ADD INDEX idx trace_id TYPE bloom_filter GRANULARITY 1 을 실행했는데 기존 자료의 조회가 전혀 빨라지지 않는다. 가장 알맞은 설명은?

• 블룸 필터는 UInt64 열에는 쓸 수 없어서 무시된다
• 인덱스는 정의만 생겼고 기존 파트에는 인덱스 파일이 없다 — MATERIALIZE INDEX 가 필요하다
• 인덱스는 다음 서버 재시작 때부터 적용된다
• GRANULARITY 1 은 인덱스를 끄는 값이다

정렬 키가 ts 인 표에서 user_id(시간과 무관하게 고루 퍼진 값)에 minmax 인덱스를 걸었다. WHERE user_id BETWEEN 100 AND 120 의 EXPLAIN Skip 칸은 어떻게 나올 가능성이 큰가?

• Granules: 1/123 — 조건에 맞는 그래뉼 하나만 남는다
• Skip 칸 자체가 나오지 않는다
• Granules: 123/123 — 모든 그래뉼의 최솟값·최댓값 범위가 조건을 품어 하나도 건너뛰지 못한다
• Granules: 0/123 — 값이 적어 전부 건너뛴다

인덱스 효과를 재려고 같은 SELECT 를 두 번 돌렸더니 두 번째 rows_read 가 0 이었다. 26.8 에서 먼저 의심할 것은?

• 쿼리 조건 캐시가 그래뉼을 기억해 건너뛰었다 — 캐시를 끄고 잰다
• 건너뛰기 인덱스가 첫 실행 때 저절로 MATERIALIZE 되었다
• 결과 캐시가 켜져 있어 표를 읽지 않았다
• 두 번째 실행은 통계에 집계되지 않는 것이 정상이다

프로젝션 p_user (SELECT * ORDER BY user_id) 를 만들고 MATERIALIZE 했다. SELECT ... FROM logs WHERE user_id = 4242 가 그것을 썼는지 가장 확실히 아는 방법은?

• 쿼리 문장에 FROM logs.p_user 라고 직접 적어 결과가 같은지 본다
• system.parts 에서 활성 파트 이름에 p_user 가 붙었는지 본다
• 프로젝션을 만들기 전보다 쿼리가 빨리 끝났는지 잰다
• query_log 의 projections 열이나 EXPLAIN 의 읽는 대상을 본다

ADD PROJECTION p (SELECT service, toStartOfHour(ts), count(), avg(latency_ms) GROUP BY service, toStartOfHour(ts)) 의 숨은 사본은 어떤 형태로 저장되나?

• 원본 행 전체를 service 순으로 다시 정렬한 사본
• GROUP BY 열마다 한 줄씩 집계 상태를 갖는 AggregatingMergeTree 형태의 사본
• 쿼리 결과를 한 번 계산해 둔 뒤 더 이상 바뀌지 않는 스냅숏
• 별도 데이터베이스에 만들어지는 구체화 뷰의 대상 표

p_user 프로젝션이 있는 표에서 DELETE FROM skp.logs WHERE user_id = 1 을 기본 설정으로 실행하면?

• 프로젝션도 함께 표시되어 문제없이 지워진다
• 원본 행만 지워지고 프로젝션에는 남아 결과가 어긋난다
• 거절된다 — 기본값 throw 가 경량 DELETE 를 막는다
• 프로젝션이 자동으로 삭제된 뒤 DELETE 가 진행된다