퀴즈: ReplacingMergeTree

6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. ReplacingMergeTree 표에서 두 행이 "같은 행" 으로 취급되어 병합 때 하나로 줄어드는 기준은?

   1. PRIMARY KEY 로 적은 열의 값이 같을 때
   2. 모든 열의 값이 똑같을 때
   3. ORDER BY 로 적은 정렬 키의 값이 같을 때
   4. ver 열의 값이 같을 때

2. 병합을 멈춘 표에서 `count()` 는 135,166 인데 `count() ... FINAL` 은 94,892 였다. FINAL 이 한 일은?

   1. 조회하면서 정렬 키마다 ver 가 가장 큰 행만 남기고 삭제 표시가 이긴 키를 뺐다
   2. 디스크의 파트를 하나로 합쳐 옛 버전을 영구히 지웠다
   3. is_deleted = 1 인 행만 빼고 나머지를 모두 셌다
   4. 정확 개수 대신 근사 개수를 돌려주었다

3. `OPTIMIZE TABLE t FINAL` 로 합친 뒤에도 `count()` 가 FINAL 로 센 값보다 5,108 많았다. 이유는?

   1. OPTIMIZE 가 파트 하나를 빼먹고 합쳤다
   2. ver 가 같은 행끼리는 병합되지 않는다
   3. OPTIMIZE FINAL 은 버전 열을 무시하고 모든 행을 남긴다
   4. 병합은 탈퇴 표시 행을 지우지 않고 사용자당 하나로 남겨 두기 때문이다

4. `ORDER BY (user_id, plan)` 으로 만든 ReplacingMergeTree 에서 FINAL 로 센 사용자 수가 실제보다 많았다. 원인은?

   1. plan 이 LowCardinality 라서 병합에서 빠졌다
   2. 요금제가 바뀌면 정렬 키가 달라져 옛 행과 새 행이 다른 무리가 되어 둘 다 남는다
   3. 정렬 키가 두 열이면 FINAL 이 첫 열만 본다
   4. OPTIMIZE FINAL 을 두 번 해야 두 번째 열까지 합쳐진다

5. CLEANUP 병합으로 탈퇴 행까지 지운 표에 옛 버전(ver 1) 행이 다시 들어왔다. FINAL 결과는 어떻게 되나?

   1. 탈퇴했던 사용자가 되살아난다 — 이길 탈퇴 표시 행이 더 이상 없기 때문이다
   2. ver 1 은 이미 지운 버전이라 INSERT 가 거절된다
   3. CLEANUP 한 표는 옛 버전을 자동으로 무시하도록 기억한다
   4. FINAL 이 오류를 내고 OPTIMIZE 를 다시 요구한다

6. "병합 전" 상태를 보려고 세 버전을 `INSERT INTO t SELECT * FROM src` 한 번으로 넣었더니 처음부터 사용자당 한 행이었다. 왜인가?

   1. INSERT 가 끝나자마자 백그라운드 병합이 반드시 돈다
   2. SELECT * 는 원본 표의 FINAL 결과를 돌려준다
   3. optimize_on_insert 가 켜져 있어 한 INSERT 블록 안의 중복은 넣는 순간 병합 규칙으로 줄어든다
   4. ReplacingMergeTree 는 INSERT 때 정렬 키로 유일성 검사를 한다