ClickHouse — 열 지향 분석 DB 를 속까지 · 건너뛰기 인덱스와 프로젝션 · 测验
퀴즈: 건너뛰기 인덱스와 프로젝션
6道题. 完成作答后会显示正确答案和解析。
운영 중인 표에 `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 가 진행된다