クイズ: 疎な主キーとキーの順序

ORDER BY (site, user_id) 표에서 WHERE user_id = 4242 의 EXPLAIN 에 Search Algorithm: generic exclusion search 가 나왔다. 왜 이진 탐색이 아닌가?

• user_id 가 UInt32 라서 이진 탐색을 쓸 수 없다
• 파트가 여러 개일 때만 이진 탐색을 쓴다
• 쿼리 조건 캐시가 켜져 있으면 검색 방식이 바뀐다
• user_id 는 사이트마다 다시 정렬돼 전체로는 정렬돼 있지 않다

ORDER BY (user_id, site) 표(사용자 5만 명, 그래뉼 245개)에서 WHERE site = 'docs.example' 이 245/245 그래뉼을 읽었다. 가장 정확한 설명은?

• site 가 LowCardinality 라서 인덱스에 들어가지 않는다
• 앞 열 user_id 가 그래뉼마다 바뀌어 뒤 열로 제외할 구간이 없다
• site 의 값이 다섯 가지뿐이라 거를 필요가 없다고 판단했다
• OPTIMIZE FINAL 을 하지 않아 인덱스가 만들어지지 않았다

같은 자료·같은 정렬 키에서 index_granularity 를 8192 에서 1024 로 줄였더니 user_id 조회의 rows_read 가 73,728 에서 9,216 으로 줄었다. 그 대가로 늘어난 것은?

• 마크 수와 기본 키 파일 크기 — 인덱스가 쓰는 메모리
• 열 데이터 파일(.bin)의 압축 후 크기가 8배로
• INSERT 한 번이 만드는 파트 수
• 정렬 키에 들어갈 수 있는 열의 개수 제한

CREATE TABLE t (...) ENGINE = MergeTree PRIMARY KEY (user_id) ORDER BY (site, user_id) 를 실행하면?

• user_id 만 인덱스에 적히고 정렬은 (site, user_id) 로 된다
• PRIMARY KEY 가 우선해 정렬도 user_id 로 바뀐다
• 기본 키가 정렬 키의 앞부분이 아니라서 표가 만들어지지 않는다
• 경고만 남기고 PRIMARY KEY 를 무시한다

WHERE site = 'api.example' AND ts 하루 범위 쿼리가 ORDER BY (site, user_id) 표에서 40만 행을 읽는다. 읽는 행을 가장 크게 줄이는 새 정렬 키는?

• (user_id, site)
• (site, user_id, ts)
• (dur_ms, site)
• (site, ts)

같은 SELECT 를 두 번 돌렸더니 첫 번째는 rows_read 73,728, 두 번째는 40,960 이었다. 26.8 에서 가장 먼저 의심할 것은?

• 그 사이 백그라운드 병합이 파트를 줄였다
• 쿼리 조건 캐시가 맞는 행이 없던 그래뉼을 기억해 건너뛰었다
• 첫 번째 실행이 결과를 쿼리 캐시에 넣어 두 번째는 캐시에서 읽었다
• 기본 키가 첫 실행 때 메모리로 올라와 인덱스가 정밀해졌다