ClickHouse를 처음 쓰다 보면 한 번쯤 이런 경험을 한다. MySQL에서는 아무 문제 없이 돌아가던 JOIN 쿼리가 ClickHouse에서는 유독 느리거나, WHERE 조건을 다 걸었는데도 풀스캔 수준의 시간이 걸리는 것이다. 이 글에서는 그 이유를 ClickHouse의 내부 동작 방식에서 찾고, 실제로 쓸 수 있는 최적화 전략을 정리한다. 어떤 상황인가 수억 건의 유저 행동 로그(page_view_log)와 주문 데이터(order_log)를 JOIN해서 페이지를 본 특정 기간, 특정 유저의 구매 건수를 집계한다고 해보자. 아래처럼 쓰는 것이 자연스럽다.SELECT count(*)FROM default.page_view_log p JOIN default.order_log o ON ..

문제 상황 특정 사용자의 데이터를 일괄 삭제하는 배치에서 두 종류의 타임아웃이 발생했다.Lock wait timeout exceeded; try restarting transaction ← 서브쿼리 DELETE 단계Query execution was interrupted (max_statement_time exceeded) ← PK 기반 SELECT+DELETE 단계 두 에러는 동시에 발생한 것이 아니다. 서브쿼리 DELETE를 사용할 때 Lock wait timeout이 발생했고, PK 기반 SELECT+DELETE로 전환한 뒤 max_statement_time exceeded가 발생했다. 타임아웃 종류가 바뀐 것 자체가 분석 포인트다. 초기 코드는 서브쿼리 DELETE 구조였다.DELET..

ClickHouse 클러스터를 처음 사용하다 보면 당황스럽다. 분명히 특정 날짜 데이터를 삭제했는데, 조회해보면 데이터가 여전히 남아있다. 분명 DROP PARTITION을 실행했는데. 알고 보면 삭제된 건 클러스터 전체가 아니라 일부 Shard의 데이터뿐이다. 이 글에서는 왜 이런 일이 생기는지, 그리고 어떻게 해야 클러스터 전체에 올바르게 적용할 수 있는지 정리한다. 배경: Distributed 테이블은 라우터다앞선 글에서 다뤘지만 다시 짚고 넘어가자.ClickHouse 클러스터에서 테이블은 두 벌이다.default.user_events ← Distributed 테이블 (라우터, 데이터 없음)local.user_events_local ← 로컬 테이블 (실제 데이터 저장..

ClickHouse에서 잘못 적재된 데이터를 지워야 하는 상황이 생겼다. MySQL이라면 그냥 DELETE FROM ... WHERE ... 날리면 끝인데, ClickHouse 클러스터 환경에서는 그게 안 된다. DELETE FROM 문법 자체는 존재하지만, ON CLUSTER를 지원하지 않아 클러스터 전체에 적용되지 않는다. 클러스터 환경에서는 반드시 ALTER TABLE ... DELETE나 DROP PARTITION을 써야 한다. 이 글은 클러스터 환경을 전제로 데이터를 삭제하는 두 가지 방법인 ALTER DELETE와 DROP PARTITION을 비교하고, 각각 언제 쓰는 게 맞는지 정리한다. 방법 선택의 기준은 데이터 양이 아니라 삭제 패턴이다. 작은 양이라도 ALTER DELETE는 파트..

ClickHouse를 처음 접했을 때 가장 혼란스러웠던 건 용어였다. MySQL이나 MariaDB에서는 그냥 테이블 만들고 쿼리 날리면 됐는데, ClickHouse는 처음부터 "Shard", "Replica", "Distributed 테이블", "ZooKeeper"가 튀어나온다. 심지어 테이블도 두 종류가 있다고 한다. 이 글에서는 ClickHouse 클러스터가 어떤 구조로 이루어져 있는지, 각 개념이 무슨 역할을 하는지 한 눈에 이해할 수 있도록 정리해본다. ClickHouse는 왜 클러스터 구조를 쓸까? ClickHouse는 대용량 분석 쿼리에 최적화된 컬럼형 DB다. 수억 건의 데이터를 빠르게 집계하는 게 주 목적이다 보니, 데이터를 여러 서버에 나눠 저장하고 병렬로 처리하는 구조가 기본이 ..

이번에 맥북을 새로 사게 되면서 개발 환경을 새로 새팅하고, 기존에 윈도우에서 개발했던 Spring Boot 서버를 실행했다. 근데 MySQL DB가 연결이 안되는 에러가 발생했다. 새로 새팅한 MySQL의 개발 환경이 안맞는 문제로 발생한 에러였다. 에러access denied for user 'root'@'localhost' (using password: yes) 해결 구글링 해보니 사용자의 비밀번호가 틀렸을 때 나타나는 오류라고 한다. 그래서 비밀번호를 재설정해보았다. + 비밀번호가 MySQL 8에서는 보안성을 높이기 위해 8자리부터 가능하니 8자리 이상으로도 바꿔보기!!! 다른 문제그런데 나는 아무리 비밀번호를 재설정하고 연결하려고 해도 연결이 되지 않았다...