[Clickhouse] Engine: Buffer (Legacy)

Buffer는 보조적인 용도를 위해 존재하는 인메모리 테이블 엔진이다.
특히 쓰기 처리량을 높이기 위해서, 쓰기 데이터를 버퍼링했다가 한번에 붓는 용도로 쓴다.

만약 이런 식으로 원본 테이블이 있다고 하면

다음과 같이 원본에 대한 버퍼 테이블을 정의할 수 있다.

CREATE TABLE 버퍼테이블명 AS 원본테이블명
ENGINE = Buffer(
    currentDatabase(), -- 대상 DB
    '테이블명',          -- 대상 테이블
    16,                -- num_layers
    5, 60,             -- min_time, max_time
    10000, 1000000,    -- min_rows, max_rows
    1048576, 104857600 -- min_bytes, max_bytes
);

덕지덕지 붙은 옵션들이 자동 flush 조건을 정의하는 부분들이다.
min은 최소한 저만큼은 되어야 flush한다는 것이고, max는 최종 임계점이다. max에 도달하면 반드시 원본 테이블에 쓰기를 넘긴다.
버퍼에 쌓인 바이트 크기, 버퍼에 쌓인 시간, 행 개수 단위로 flush 규칙을 정의할 수 있다.

그리고 buffer에 insert하면

처음에는 버퍼에만 보이다가

기준을 충족하면 원본 테이블에도 부어질 것이다.

참고로, buffer는 양방향 통신처럼 동작한다.
events에 있는 데이터는 buffer에서도 조회가 가능하다.

Buffer의 한계

그냥 얼핏 보면 좋아보일 수도 있는데, 단점이 많다.

일단 Buffer -> MergeTree로의 Insert는 exactly once가 보장되지 않는다, 동일 행이 여러번 Insert가 될 수 있다는 것이다.

그리고 당연하지만 유실 위험이 있다. 인메모리라서 서버가 셧다운되면 증발하는 것이다.

위와 같은 단점들을 감수함에도, 쓰기 성능이 극적이지는 않다. 특히 한 행씩 Insert하는 것은 Buffer를 쓰더라도 효율적이지 않ㄴ다.

Buffer vs async Insert

게다가 Buffer는 현 시점에는 그다지 권장되지 않는 기능이다. clickhouse 커뮤니티에서는 Buffer를 레거시로 간주하고, async insert 기능을 좋은 대안으로서 권장한다.
둘 다 clickhouse가 인메모리로 버퍼링을 하다가 모아서 테이블에 write를 날린다는 대전제는 같다. 실제로도 async insert가 buffer를 대체하기 위해 나온 기능이기도 하다.

async insert는 buffer보다 많은 보장 수준을 제공하고, batch insert 최적화도 잘 해준다.
wait_for_async_insert 같은 옵션이 있어서 쓰기에 대한 보장을 가져가는 것도 가능하다.
https://blog.naver.com/sssang97/223973565751

참조
https://clickhouse.com/docs/engines/table-engines/special/buffer