Quiz: Parts, Granules and Column Compression

SELECT sum(amount) FROM sales 가 행 지향 DB 보다 열 지향 저장에서 훨씬 적게 읽는 이유는?

• 열 지향 저장은 결과를 미리 계산해 두기 때문이다
• amount 열의 파일만 읽고 나머지 열 파일은 열지 않기 때문이다
• 열 지향 저장은 행 수를 절반으로 줄여 저장하기 때문이다
• sum 은 인덱스만 보고 답할 수 있기 때문이다

system.parts 의 marks 가 246 인 파트가 있다. 기본 설정이라면 이 숫자가 뜻하는 것은?

• 이 파트가 백그라운드 병합을 246번 거쳐 만들어졌다
• 이 파트 디렉터리 안에 열 데이터 파일이 246개 있다
• 이 파트가 8192행 안팎의 그래뉼 약 245개로 나뉘어 있다
• 이 파트를 읽은 쿼리가 지금까지 246번 있었다

정렬 키가 (site, ts) 인 표에서 WHERE country = 'KR' 로 거르면 rows_read 가 전체 행 수와 같다. 무엇을 뜻하나?

• 인덱스가 손상되었다
• country 가 정렬 키에 없어 건너뛸 그래뉼을 고를 근거가 없다
• LowCardinality 가 아닌 열로는 거를 수 없다
• 파트가 하나라서 건너뛰기가 꺼졌다

SELECT sum(length(url)) FROM t 가 url 열 크기보다 훨씬 적은, 행당 8바이트만 읽었다. 이유는?

• length 는 문자열 내용이 아니라 길이 부분열(url.size)만 읽도록 최적화된다
• 결과를 캐시에서 읽었다
• url 이 LowCardinality 로 저장돼 있었다
• 압축된 바이트만 세어서 작게 나왔다

방금 돌린 쿼리를 system.query_log 에서 찾았는데 보이지 않는다. 가장 먼저 할 일은?

• 서버를 다시 시작한다
• 쿼리를 한 번 더 돌린다
• log_queries 를 켜는 서버 설정을 추가한다
• SYSTEM FLUSH LOGS 로 버퍼에 있는 로그를 표로 밀어 넣는다

작은 INSERT 가 초당 여러 번 들어오는 표에서 Compact 파트 형식이 도움이 되는 이유는?

• Compact 파트는 병합이 필요 없어서
• Compact 파트는 압축을 하지 않아 쓰기가 빨라서
• 모든 열을 한 파일에 담아 작은 파트마다 생기는 파일 수를 줄여서
• Compact 파트는 인덱스를 만들지 않아서