Clickhouse 가 빠른 이유

 

Clickhouse 는 Online Analytic Processing(OLAP) 에 최적화된 데이터베이스로 다른 데이터베이스에 비해 월등한 검색 속도를 자랑한다.

 

이번 포스트에서는 어떤 요소들 때문에 Clickhouse 가 속도가 빠른지 정리했다

---

Column oriented DBMS

Clickhouse 는 칼럼형 데이터베이스를 사용하고 있다. 칼럼형 구조가 생소할 수 있는데 먼저 이것과 반대되는 개념인 로우형(Row-oriented) 데이터베이스에 대해서 먼저 알아보자

Row-oriented DBMS

같은 행에 있는 데이터 단위로 저장되는 형태다. MySQL 과 PostgreSQL 이 대표적인 Row 형 데이터베이스다

 

만약 (시간, 주소, 전화번호) 정보를 저장하는 데이터베이스라면 세가지 데이터를 같은 묶음으로 저장된다. 테이블 데이터를 폴더 단위로 나눈다고 생각하면 (세시, 강남구, 010-0000-0000) 같은 행 데이터가 같은 폴더에 저장된다고 생각하면 된다

 

로우형 구조는 검색할 때 성능이 좋지 않다. 왜냐면 select 문으로 이름 정보만 가져오려고 해도 데이터가 같은 묶음으로 저장되어 있기 때문에 모든 데이터를 찾아봐야 하기 때문이다. 

 

그림상에서 보면 Time, Location, MobilePhone 정보만 가져오려고 하는데, 진한 노란색으로 칠해진 부분에서 보이듯 모든 정보를 찾아와야 하는 문제점이 있다. 

Column-oriented DBMS

같은 칼럼에 있는 데이터 단위로 저장한다. Clickhouse 가 대표적인 칼럼형 데이터베이스다

 

(시간, 위치, 전화번호) 정보를 저장한다면 각각의 칼럼별로 데이터를 저장한다. 같은 행이여도 시간이 저장된 곳과 주소가 저장된 곳의 위치가 다르다. 폴더 단위로 구분한다면 시간이 저장된 폴더와 주소 데이터가 저장된 폴더가 다르다고 생각하면 된다.

 

검색할 때 우수한 성능을 보인다. 특히 select 문으로 몇개의 Column 에 있는 데이터만 가져오고 싶다면 모든 데이터를 찾는게 아니라 연관된 Column 에 있는 데이터만 찾아보면 되기 때문에 성능상 이점을 보인다.

 

그림상으로 보면 Time, Location, Mobile Phone 과 관련된 데이터만 따로 수집할 수 있기 때문에 검색 속도가 빨라지는 장점이 있다. 

Attention to Low-level Details

Clickhouse 는 Low-level detail (저수준 설계) 에 집중했다. 예시로 hash table 은 다양한 구현 방법이 있는데 Clickhouse 에서는 쿼리에 따라서 30개가 넘는 hash table 변형 버전을 사용하고 있다.

 

일반 알고리즘 상황에서도 동일함. 만약 정렬을 해야하는 경우 다양한 고려사항이 있는데

• 정렬 데이터가 숫자냐 튜플이냐 문자열이냐?
• full sort 냐 partial sort 냐
• 비교는 어떻게 구현하냐
• 이미 부분적으로 정렬된 데이터를 사용하냐

이런 상황에 대해서 최적화 고민을 많이 했다고 한다. 

 

대부분 일반적인(generic) 한 방법을 적용하는데 클릭하우스 같은 경우에는 최선의 결과를 내기 위해 알고리즘에도 고민을 많이 기울였다고 한다. 

Other techniques

이것외에도 일반 데이터베이스에서 적용하는 스킬을 사용했다

Indexes

필요한 행의 범위만 읽어올 수 있도록 최적화 하는 방법

Data Compression

데이터를 압축해서 저장하는 방법

Vectorized Query Execution

칼럼 단위로 데이터를 처리하도록 해서 CPU 캐시 유용성을 극대화하고 SIMD 명령어를 사용해서 멀티코어의 이점을 살린다

Scability

하나의 쿼리를 멀티 코어, 멀티 서버 단위에서 처리하도록 한다. 부하를 분산 시킬 수 있는 장점이 있다.

---

 

What is ClickHouse? | ClickHouse Docs