クイズ: ReplacingMergeTree

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

• PRIMARY KEY 로 적은 열의 값이 같을 때
• 모든 열의 값이 똑같을 때
• ORDER BY 로 적은 정렬 키의 값이 같을 때
• ver 열의 값이 같을 때

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

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

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

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

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

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

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

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

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

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