Clickhouse 데이터 삭제 - ALTER DELETE vs DROP PARTITION

 ClickHouse에서 잘못 적재된 데이터를 지워야 하는 상황이 생겼다.

 

 MySQL이라면 그냥 DELETE FROM ... WHERE ... 날리면 끝인데, ClickHouse 클러스터 환경에서는 그게 안 된다. DELETE FROM 문법 자체는 존재하지만, ON CLUSTER를 지원하지 않아 클러스터 전체에 적용되지 않는다. 클러스터 환경에서는 반드시 ALTER TABLE ... DELETE나 DROP PARTITION을 써야 한다.

 

 이 글은 클러스터 환경을 전제로 데이터를 삭제하는 두 가지 방법인 ALTER DELETE와 DROP PARTITION을 비교하고, 각각 언제 쓰는 게 맞는지 정리한다.

 

 방법 선택의 기준은 데이터 양이 아니라 삭제 패턴이다. 작은 양이라도 ALTER DELETE는 파트 재작성이 필요한 구조라 느리고, DROP PARTITION은 용량과 무관하게 빠르다. 파티션 단위로 통째로 교체할 수 있는 상황인가가 기준이다.

 

 

 

---

ClickHouse에서 DELETE가 느린 이유

https://clickhouse.com/docs/assets/ideal-img/part.323bb36.2048.png

 

 ClickHouse는 데이터를 파트(Part) 단위로 디스크에 저장한다. INSERT가 들어올 때마다 새로운 파트가 생성되고, 백그라운드에서 주기적으로 파트들을 병합(Merge)한다.

 

 이 구조 덕분에 대용량 INSERT와 SELECT가 빠르지만, 반대로 특정 행만 골라서 삭제하는 건 비용이 많이 드는 작업이다. 해당 파트 전체를 읽어서 조건에 맞는 행을 제외한 뒤 새 파트로 다시 써야 하기 때문이다.

 

 이게 바로 ClickHouse의 삭제 방식인 Mutation이다.

 

 

---

방법 1: ALTER DELETE (Mutation)

ALTER TABLE local.user_events_local ON CLUSTER my_cluster
DELETE WHERE event_date = '2026-03-18';

 

 

동작 방식

https://clickhouse.com/uploads/mutation_01_24b8cb7f88.png

 

  삭제 작업이 Mutation 큐에 등록되고, 백그라운드에서 비동기로 처리된다. 대상 파트를 디스크에서 읽어 조건에 해당하는 행을 제외한 뒤 새 파트로 재작성한다.

 

 기본값은 비동기라 쿼리가 바로 반환되지만, 삭제가 완전히 끝났다는 보장이 없다. 모든 Replica에서 완료될 때까지 기다리려면 mutations_sync 설정을 추가한다.

 

ALTER TABLE local.user_events_local ON CLUSTER my_cluster
DELETE WHERE event_date = '2026-03-18'
SETTINGS mutations_sync = 2;  -- 0: 비동기(기본), 1: 현재 서버 완료 대기, 2: 모든 Replica 완료 대기

 

 

특징

• 조건부 삭제 가능 : WHERE 절로 원하는 행만 정확히 제거할 수 있다.
• 느리고 높은 I/O 비용 : 파트 전체를 재작성하기 때문에 느리다.
• ON CLUSTER 지원 : 각 Shard로 자동 전파된다. 클러스터 환경에서 조건부 삭제가 필요하다면 이 방법만 가능하다.

 

 

---

방법 2: DROP PARTITION

-- 반드시 로컬 테이블 + ON CLUSTER 조합으로 실행
ALTER TABLE local.user_events_local ON CLUSTER my_cluster
DROP PARTITION '20260318';

 

 

동작 방식

https://clickhouse.com/uploads/partition_delete_3ee4669374.png

 

 파티션을 비활성 상태로 표시하고 약 10분 후 완전히 삭제한다. 파트를 읽거나 재작성하지 않고 통째로 버리기 때문에 매우 빠르다. 쿼리 반환 시점에는 이미 해당 파티션이 조회에서 제외되므로 체감상 즉시 삭제처럼 동작한다.

 

 

특징

• 빠르고 낮은 I/O 비용
• 파티션 단위로만 삭제 가능 : 조건부 삭제 불가. 파티션 키 단위로만 끊어서 지울 수 있다.
• Distributed 테이블에서 실행하면 안 됨 : 반드시 로컬 테이블 + ON CLUSTER 조합으로 실행해야 한다.

 

 

---

비교

항목	ALTER DELETE	DROP PARTITION
속도	느림	빠름
I/O	높음	낮음
삭제 단위	행 단위 (조건부)	파티션 단위
ON CLUSTER 지원	지원	로컬 테이블에서만
Distributed 테이블 실행	자동 전파	한 노드에만 적용
즉시 반영	비동기 (기본)	비활성 즉시 / 실제 삭제 ~10분 후
적합한 경우	특정 조건의 일부 행 삭제	날짜 단위 전체 재처리

 

 

 

---

언제 뭘 써야 하나?

DROP PARTITION을 쓰는 경우

 테이블 파티션이 날짜 단위로 나뉘어 있고, 특정 날짜 데이터를 통째로 다시 적재해야 할 때 적합하다.

 

 예를 들어 배치 잡이 특정 날짜에 잘못된 데이터를 적재했고, 해당 날짜 전체를 지우고 다시 넣어야 하는 상황이다. 데이터 양에 상관없이 빠르고, 지우고 다시 넣는 패턴이 가장 깔끔하다.

-- 1. 잘못된 파티션 삭제
ALTER TABLE local.user_events_local ON CLUSTER my_cluster
DROP PARTITION '20260318';

-- 2. 올바른 데이터 재적재
INSERT INTO default.user_events SELECT ...

 

 

ALTER DELETE를 쓰는 경우

 파티션 경계와 무관하게 특정 조건의 행만 골라서 지워야 할 때 사용한다. 여러 파티션에 걸쳐있는 특정 조건의 데이터를 지워야 하거나, 파티션 단위로 끊기 어려운 경우다. 단, 느리다는 점을 감수해야 한다.

-- 특정 사용자의 이벤트 데이터만 삭제
ALTER TABLE local.user_events_local ON CLUSTER my_cluster
DELETE WHERE user_id = 12345
SETTINGS mutations_sync = 2;

 

 참고로 DELETE FROM table WHERE ... 문법은 클러스터 환경에서 쓸 수 없다. ON CLUSTER를 지원하지 않기 때문에 단일 노드에만 적용된다. 클러스터 환경에서는 반드시 ALTER TABLE ... DELETE ON CLUSTER 형태로 실행해야 한다.

 

 

 

 

---

정리

• 특정 날짜(파티션) 데이터를 통째로 재처리해야 한다 → DROP PARTITION. 데이터 양에 상관없이 빠르다.
• 파티션 경계와 무관하게 특정 조건의 행만 골라서 지워야 한다 → ALTER DELETE ON CLUSTER. 느린 건 감수해야 한다.
• 소량 row 삭제가 잦다 → ClickHouse 자체가 맞지 않는다.

 

 

---

마치며

 ClickHouse에서 데이터를 지우는 건 MySQL처럼 가볍지 않다. 특히 클러스터 환경에서는 DELETE FROM 같은 편의 문법도 쓸 수 없다. 그래서 처음부터 "잘못 들어오면 어떻게 고칠 것인가"를 설계 단계에서 함께 고려하는 게 좋다.

 

 파티션을 잘 설계해두면 재처리가 필요할 때 DROP PARTITION으로 빠르게 처리할 수 있다. 반대로 파티션 설계가 잘못되면 매번 느린 ALTER DELETE에 의존하게 된다.

 

 결국 보정 방식의 선택은 테이블 설계에서 이미 결정된다고 할 수 있다.

 

 

 

---

참고

• https://clickhouse.com/blog/handling-updates-and-deletes-in-clickhouse

Handling Updates and Deletes in ClickHouse