아는 개발자

Virtual Thread in JAVA

kwony — Wed, 14 Jan 2026 11:46:00 +0900

작업마다 Java Thread 를 생성하면 OS 단위에서 Thread 를 생성하기 때문에 비싸고 시간도 오래 걸린다. 그래서 Java 진영에선 기존에 생성하던 Java Thread 를 Platform Thread 라고 정의하고 Virtual Thread 라는 것을 새로 만들어서 Platform Thread 위에서 실행되는 구조를 잡았다.

출처: 우아한기술블로그 (https://techblog.woowahan.com/15398/)

Virtual Thread 는 Heap 메모리에 있는 객체다. Virtual 스레드는 생성 작업이 JVM 위에서 이뤄지기 때문에 Platform Thread 에 비해서 생성 비용도 싸다. Stack 이나 IP 같은 저장공간도 JVM 내에서 컨텍스트 스위칭 되는 형태이기 때문에 불필요한 시스템 콜이 없어지게 된다

Java Thread 에 비해서 커널레벨까지 내려가서 실행하는 시스템 작업이 없어 효율적이다.

추가로 Virtual Thread 의 강점은 Blocking I/O 를 Non blocking I/O 로 실행하게 된다는 점이다.

기존 Java Thread 를 사용할 경우 I/O 작업이 오래 걸리면 끝까지 기다리게 된다. 반면에 Virtual Thread 에서는 JVM 이 Blocking 을 감지하면 실행하고 있던 Virtual Thread 를 중지하고 다른 Virtual Thread 를 실행한다.

그래서 하나의 Java Thread 를 사용해도 두개의 작업을 동시에 실행하는 효과를 내게 된다.

public class TEST {
    private static final int TASKS = 1000;

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        ioBoundTask();
        System.out.printf("Time %dms\n", System.currentTimeMillis() - start);
    }

    private static void ioBoundTask() {
        try (ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor()) {

            for (int i = 0; i < TASKS; i++) {
                executorService.submit(() -> {
                    for (int j = 0; j < 100; j++) {
                        System.out.println("Executing Blocking Task: " + Thread.currentThread());
                        try {
                            Thread.sleep(10);
                        } catch (InterruptedException e) {
                            throw new RuntimeException(e);
                        }
                    }
                });
            }
        }
    }

 }

Virtual Thread 를 sleep 코드에서 blocking 이 발생하지 않아서 새로운 쓰레드 생성을 계속한다. 그래서 1000개의 쓰레드를 생성하는데 1233ms 만 소요된다

Executing Blocking Task: VirtualThread[#686]/runnable@ForkJoinPool-1-worker-5
Executing Blocking Task: VirtualThread[#482]/runnable@ForkJoinPool-1-worker-2
Executing Blocking Task: VirtualThread[#688]/runnable@ForkJoinPool-1-worker-2
Executing Blocking Task: VirtualThread[#635]/runnable@ForkJoinPool-1-worker-4
Executing Blocking Task: VirtualThread[#645]/runnable@ForkJoinPool-1-worker-8
Executing Blocking Task: VirtualThread[#937]/runnable@ForkJoinPool-1-worker-1
Executing Blocking Task: VirtualThread[#972]/runnable@ForkJoinPool-1-worker-6
Tasks took 1233ms to complete

newCachedThreadPool 을 사용하는 경우 Java Thread 를 생성해야 하기 때문에 시간이 더 소요되고 경우에 따라선 하드웨어 자원이 부족해 crash 가 발생하게 된다.

Executing Blocking Task: Thread[#286,pool-1-thread-259,5,main]
Executing Blocking Task: Thread[#1006,pool-1-thread-979,5,main]
Executing Blocking Task: Thread[#286,pool-1-thread-259,5,main]
Executing Blocking Task: Thread[#1006,pool-1-thread-979,5,main]
Tasks took 1760ms to complete

java volatile

kwony — Thu, 8 Jan 2026 15:21:22 +0900

아래와 같은 클래스가 있다고 해보자.

public static class SharedClass {
    private int x = 0;
    private int y = 0;

    public  void increment() {
        x++;
        y++;
    }

    public  void checkForDataRace() {
        if (y > x) {
            System.out.println("y > x - Data Race is detected");
        }
    }
}

x에 대한 증가가 y에 대한 증가보다 먼저 작성되었기 때문에 이론상으로 x>=y 인 상황만 발행해야하고 checkForDataRace 에서 if 문에 걸릴 일은 없다.

그런데 멀티 쓰레드 환경에서 실행해보면 y>x 인 케이스가 발생한다. 놀랍게도

public class Main {
    public static void main(String[] args) {
        SharedClass sharedClass = new SharedClass();
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < Integer.MAX_VALUE; i++) {
                sharedClass.increment();
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < Integer.MAX_VALUE; i++) {
                sharedClass.checkForDataRace();
            }

        });

        thread1.start();
        thread2.start();
    }
 //

y > x - Data Race is detected
y > x - Data Race is detected
y > x - Data Race is detected
y > x - Data Race is detected

컴파일러와 CPU는 성능 최적화를 위해서 종종 연산의 순서를 바꾸기도 한다. 논리적인 정확성을 유지하면서 순서를 바꾸는데 멀티 쓰레드환경에서는 규칙이 지켜지지 않는 문제가 발생한다.

위의 예제 코드에선 y++ 를 CPU가 먼저 실행하고 thread2 에서 이때 상태로 check를 걸었기 때문에 문제가 된다.

해결책은 두가지가 있다.

첫번째는 SharedClass 의 함수에다가 synchronized 를 걸어주는 방법이다.

public static class SharedClass {
    private int x = 0;
    private int y = 0;

    public synchronized void increment() {
        x++;
        y++;
    }

    public synchronized void checkForDataRace() {
        if (y > x) {
            System.out.println("y > x - Data Race is detected");
        }
    }
}

직관적이긴 하지만 이 방법은 Core Grained Locking 이 되어서 성능이 덜어진다.

두번째는 volatile 을 사용하는 방법이다. volatile 로 선언된 변수에 대해선 실행의 재정렬을 막아주고 변수의 변경을 쓰레드가 즉시 볼 수 있게 해준다.

위의 클래스에서 volatile 을 붙여주면 y>x 인 케이스가 발생하지 않게 된다

    public static class SharedClass {
        private volatile int x = 0;
        private volatile int y = 0;

        public void increment() {
            x++;
            y++;
        }

        public void checkForDataRace() {
            if (y > x) {
                System.out.println("y > x - Data Race is detected");
            }
        }
    }

단 연산의 원자성을 보장하진 않는다. 멀티쓰레드 환경에서 여러 쓰레드가 동시에 연산을 실행하면 결과 값이 예상과 달라질 수 있다.

그래서 Volatile 의 경우 쓰레드 하나만 값을 업데이트하고 나머지는 읽기 연산을 수행할 때 쓰는게 좋다.

이걸 Single Writer Multiple Reader 패턴이라고 Chat GPT 는 알려줬다.

개념 자체는 알겠는데 실전에서 쓰려면 기억이 안나서 실수가 잦는 키워드다.

추가로 double, long 타입에 대한 reference operation 에서 원자성을 보장한다

원래 자바에서는 int, boolean 같은 primitive 타입에선 특별한 동기화 작업을 걸지 않아도 원자성을 보장하는데 long, double 타입의 경우에는 예외였다.

private int getter() {
	return intVal;
}

하지만 volatile 을 사용하면 reference 오퍼레이션에 대해서도 원자성을 보장한다

public static class Metrics {
    private long count = 0;
    private volatile double average = 0.0; 

    public synchronized void addSample(long sample) {
		// 여기에선 volatile 로 선언 안해도 괜춘함
		// synchronized 에서 쓰레드가 하나씩만 접근하게 되므로
        double currentSum = average * count; 
        count++;
        average = (currentSum + sample) / count;
    }

    public double getAverage() {
        // average 변수를 volatile 로 선언해줘야
        // reference 가 atomic operation 임이 보장된다
		// double, long 타입은 volatile 을 반드시 붙여줘야함
        return average;
    }
}

logi options+ 무한로딩 ㅡㅡ

kwony — Wed, 7 Jan 2026 14:34:57 +0900

오늘 아침에 로지텍 마우스로 커스텀 설정해둔 버튼이 동작하지 않아서 logi options+ 를 실행해보니 동글뱅이가 멈출생각을 하지 않았다

뭔가 잘못된 것 같아서 삭제하고 재실행해봐도 동일하고 chat GPT 가 시키는걸 했는데도 그대로였다.

레딧에 들어가보니 나와 같은 장애를 겪고 있는 사람들이 올린 댓글이 다수 있었다.

사람들 추측으론 동시에 많은 사람들이 안되는로 보아 백엔드쪽이 맛이 간것 같고 맥 시스템 날짜를 변경하면 된다는 글을 보니까 인증서 문제로 보인다.

매해 1월마다 많은 서비스들이 인증서 교체작업을 하는데 logi options+ 앱도 마찬가지인듯

클리앙에도 뜬걸로 보아 한국 사용자들도 같은 문제를 겪고 있는듯

그런데 하드웨어 기기를 인터넷이 되는 환경에서만 사용할 수 있다는게 말이 되는건가 싶다.

물론 아예 안되는건 아니고 커스텀하게 설정한 기능들을 사용할 수 없는거긴 하지만 요것도 서버 통신이 되는 환경에서만 쓸 수 있다는게 아이러니하다

로지텍도 참 실망스럽다. 최소 7시간째 장애를 겪고 있는데 아직도 대응을 안하고 있다니. 그것도 제품을 구매한 사용자들이 쓰는 기능인데 말이다.

레딧 댓글처럼 담당자가 휴가가서 발생하는 이슈라면 부담당자라도 얼른 대처해야하는거 아닌가.

Python GIL

kwony — Sun, 28 Dec 2025 17:53:23 +0900

CPython

파이선 스크립트 엔진중에 가장 메인. 공식 배포판에서도 이걸 쓴다.

C 언어로 작성되었고 공식 배포판이다
가장 완벽하고 모든 최신 기능을 제공한다
커뮤니티가 가장 크고 풍부한 문서를 제공한다

터미널에서 python 명령어를 실행하면 CPython 엔진으로 파이선 파일을 실행하게 된다

GIL

글로벌 인터프리터 락 (Global Interpreter Lock). 쓰레드간에 동시성을 제어하기 위해 사용되는 메커니즘. GIL 은 동시에 하나의 쓰레드만 바이트코드를 실행할 수 있도록 허용하며 메모리 관리와 객체 모델의 일관성을 보장한다

왜 파이썬은 하나의 스레드만 바이트 코드를 실행하게 했는지 궁금할 수 있는데 자세히 들어가면 복잡하니 C 언어 생태계에서 단일스레드 성능을 높이기 위함이였다 정도로 짧게 이해하고가자

동작방식

락의 획득과 해제: CPython 인터프리터가 파이선 코드 실행시 GIL 을 획득하고 다른 쓰레드는 GIL 을 실행할 때까지 대기. 인터프리터는 주기적으로 GIL 을 해제하여 다른 쓰레드가 실행될 수 있도록 한다

스레드 전환: GIL 은 바이트코드 실행 주기 또는 I/O 작업이 발생할 때마다 다른 쓰레드로 전환된다. 단일 코어에서 다중 쓰레드가 실행되는것처럼 보이지만 실제로는 하나의 쓰레드만 실행된다

장점

메모리 관리 간소화: 쓰레드가 동시에 메모리 객체에 접근해도 GIL 은 일관성을 유지할 수 있게 해준다

안전성: GIL 덕분에 파이썬 내부 데이터 구조가 쓰레드 안정성을 유지한다

단점

멀티코어 CPU 활용 제한: 파이썬 쓰레드는 동시에 하나의 쓰레드만 실행되므로 병렬처리가 제한된다. CPU 바운드 작업에서 성능 저하를 초래한다

쓰레드 성능 저하: I/O 바운드 작업에서는 큰 문제가 안되지만 CPU 바운드 작업에선 멀티쓰레딩의 이점을 누리지 못함

다음코드가 GIL 병목의 대표적인 예제 코드다

import threading

def work():
    x = 0
    for _ in range(10**8):
        x += 1

threads = [threading.Thread(target=work) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()

x+=1 단순한 코드를 돌리는데 멀티 스레드 환경이지만 한번에 하나의 스레드만 실행이 가능하다. 실질적으로 하나의 스레드로 돌리는 것과 비슷한 속도가 발생

CPU 바운드 작업이 높은 서비스의 경우에는 c++ 을 이용한 내장 라이브러리를 적극 활용해야 GIL 병목에 걸리지 않는다 -> 암호 해체 관련된 작업의 경우 락에서 보내는 시간이 많아질수도

반면에 I/O 관련 작업이 많다면 GIL에서 걸리는 시간이 많지 않다.

Django

장고도 CPython 으로 실행하면 GIL 때문에 쓰레드 동시성 문제를 겪게됨. 그래서 wsgi 를 이용해 worker 프로세스를 여러개 둬서 멀티 프로세싱을 사용한다.

멀티 쓰레드도 두긴 하는데 이건 I/O 바운드 작업을 최적화 하기 위함임

넷플릭스가 클릭하우스를 최적화시킨 방법

kwony — Tue, 18 Nov 2025 19:38:56 +0900

How Netflix optimized its petabyte-scale logging system with ClickHouse

“To make our logging system work, we had to make a lot of choices. The key is how you simplify things in order to do the least amount of work.” Daniel Muino, Software Engineer

clickhouse.com

클릭하우스 공식 블로그를 번역 + 개인적인 의견을 첨가한 포스팅

모든 종류의 로깅 시스템을 압도한다고 말하는데 얼마나 대단하면 이런 말을 할 수 있는 것인가 ㅎㅎ 넷플릭스는 자부심이 대단한듯

Safe to say, this is a scale that would overwhelm most logging platforms. Making that kind of interactivity possible—logs that are searchable within seconds, queries that feel instant—took not just the right database (ClickHouse!) but a series of carefully engineered optimizations.

Clickhouse 는 시스템의 중심에 있으며 hot tier 로 동작한다. 속도가 생명인 최신 로그를 저장하고 빠른 쿼리와 상호작용하는 디버깅을 제공한다. 클릭하우스 덕분에 최신 데이터를 빨리 보내줄 수 있다고 관계자는 말한다 (Daniel)

ClickHouse sits at the heart of the system as the hot tier. It stores recent logs where speed is critical, powering fast queries and interactive debugging. “Thanks to ClickHouse, we’re able to serve this data very fresh,” Daniel says. “All the buffering we do along the way doesn’t really affect us much.”

시스템이 거의 동시에 일어나고 있는것처럼 느껴진다. 로그는 발생한지 20초만에 조회가 가능하고 종종 2초 latency 만에 라이브 로그를 전달받기도 한다고함.

The result is a system that feels almost instantaneous. Logs are usually searchable within 20 seconds of being generated, far faster than Netflix’s 5-minute SLA. In some cases, engineers can even stream live logs with two-second latency. They can click into events, expand JSON payloads, group millions of messages by fingerprint hash, or drill into surrounding logs, all without waiting for queries to churn.

아무튼 여기까지가 넷플릭스 성능에 대한 자랑이었고 다음부터는 최적화 기법에 대해서 설명하고 있다.

Ingestion - Fingerprinting

로그 사용성을 높이기 위해서 우선 비슷한 메시지끼리 묶어주는 처리를 함. Fingerpinting 이라고 부르는 기법인데 요 방식이 수백만개의 비슷한 요소들을 하나의 패턴으로 묶어서 노이즈를 줄이게 해줌. 이게 없으면 로그에서 조회하는 작업은 매우 압도적이라고 할 수 있음.

처음에는 머신러닝 모델을 이용해서 로그를 그룹화하는 시도를 했음. 이론적으로는 동작했으나 실전에서는 모델을 돌리기에는 컴퓨팅 리소스가 부족했음.

그러고 나서 정규표현식 패턴 매칭 방식을 사용했고 generic token 을 swap out 했음. 동작은 했으나 정규표현식은 초당 천만데이터는 따라잡지 못했음.

팀은 Fingerprinting 을 다시 조정했고 자바로 구현된 tokenizer JFlex Lexer 라는 것을 만들어냈음. 런타임에 복잡한 정규표현식을 평가하는거 대신 이 시스템은 패턴을 효율적인 코드로 컴파일했음.

넷플릭스처럼 돈많은 회사들도 비용절감을 위해 상당히 로우레벨로 까지 내려가고있다는 점. 이래서 회사에서 알고리즘을 면접때 보는 것일지도 모르겠다

Hub - Serialization

로그를 fingerprint 했으면 클릭하우스에 작성돼야함. 다른 병목이 있는데 바로 직렬화임.

처음에는 JDBC 배치 inserts 방식에 의존했음. 간단하고 친숙했지면 효과적이지 않았다. 모든 준비된 구문들이 클라이언트가 스키마와 직렬화에 대해서 협상해야했고 오버헤드가 있었음.

추상화 스택을 포기하고 클릭하우스 low level 자바 클라이언트에게 노출된 RowBinary 포맷을 사용하기로함. 칼럼 단위로 수동으로 직렬화를 시켜줌. 성능이 매우 증가했으나 충분하지는 않았다고함

RowBinary 포맷을 사용하면 불필요한 인코딩 데이터들이 포함되지 않기 때문에 데이터 양도 적고 속도도 빨라지게 된다

So the team dropped down a level in the abstraction stack, using the RowBinary format exposed by ClickHouse’s low-level Java client. This meant manually serializing data column by column—writing map lengths, encoding DateTime64 as nanoseconds since the epoch, and handling other quirks. It gave them a “huge performance boost,” Daniel says, but it still wasn’t enough.

input 포맷별 벤치마크에 대한 블로그 글을 읽고 혁신적인 방식을 고안함. native protocol 이 RowBinary 보다 더 나은 성능을 보였으나 Java client 는 지원하지 않았고 Go client 만 지원했음.

Beyond the ClickHouse command-line client, the native interface is currently supported only by the C++ and Go clients, with Rust support planned. All main language clients, except C++, support the HTTP interface.

직렬화까지 내려간거면 정말 낮은 시스템 레벨에서 성능을 올리기 위해 고민해본거라 할 수 있을것 같다. 일반적인 서비스에서는 고민하기 힘든 일임. 그래서 넷플릭스 개발자들이 돈을 많이 받는 이유일지도 모르겠다 ㅋㅋ

나도 일을 하면서 이정도까지 깊이 있게 파본적은 없는거 같은데. 아무튼 대단하고 동기부여가 된다

Queries - Custom Tag

Ingestion, Serialization 은 쓰기가 오래 걸리는 작업이라면 세번째 병목은 읽는 부분이었음. 엔지니어들은 tag 에 강하게 의존하고 있는데 요 태그가 마이크로서비스, 요청 id, 그외 다른 속성들을 걸러주는 역할을 함. 유용할 수록 태그는 시스템에서 가장 머리아픈 구석이 됨.

태그는 원래 Map(String, String) 타입으로 저장되어 있었음. 내부적으로 클릭하우스는 키와 값으로 구성된 두개의 병렬 배열 로 표현함. Lookup 할 때마다 특정 키를 찾기 위해선 배열을 linear 하게 스캔해야함. 넷플릭스 환경에선 시간당 25,000 개의 unique key 와 천만개의 unique values 가 쿼리 성능 저하시키는 요인임

클릭하우스 창업자와 얘기한 결과 LowCardinality types 라는 걸 추천 받았고 키 값에는 효과가 있었으나 값은 너무 다양했기 떄문에 완전히 해결하진 못함

해결책은 의외로 간단했는데 map 을 샤드하는 방식이다. 태그 키들을 31개의 작은 맵으로 쪼개고 나니 쿼리가 모든 키 값을 확인할 필요 없이 바로 다음 샤드를 확인하게 됐따.

Clickhouse Materialized views

kwony — Fri, 7 Nov 2025 22:41:10 +0900

테이블에 데이터가 추가될 때마다 특정한 쿼리를 실행하고 결과를 target 테이블에 전송하는 테이블이다. 데이터가 추가될수록 결과가 타겟 테이블에 전송되고 중간 result 는 업데이트되고 병합된다. 병합된 결과는 기존 데이터에 대한 쿼리와 동등하다.

target 테이블에 미리 계산된 결과를 전달하고 싶을때 사용하는 테이블이라고 보면됨.

아래 up_down_votes_per_day_mv 테이블은 up_down_votes_per_day 테이블에 일별 데이터를 모아서 전송해주는 역할을 하는 materialized 테이블이다

CREATE MATERIALIZED VIEW up_down_votes_per_day_mv TO up_down_votes_per_day AS
SELECT toStartOfDay(CreationDate)::Date AS Day,
       countIf(VoteTypeId = 2) AS UpVotes,
       countIf(VoteTypeId = 3) AS DownVotes
FROM votes
GROUP BY Day

리얼타입에 데이터를 유입시킬 수 있으며 점진적으로 업데이트되는 인덱스와 비슷한 역할을 한다고 볼 수 있다. 다른 디비의 경우 materialized view 가 특정 상태의 snapshot 을 저장하고 새로고침을 해줘야 하는 것에 비해서 요건 클릭하우스 고유한 특징이라고 볼 수 있다.

별도의 애플리케이션 돌릴 필요 없이 테이블을 이용해서 데이터 전처리를 해줄 수 있는 테이블이라고 볼 수 있다. 여기에 Aggregate Engine 같은걸 이용하면 효율을 더 높일수도 있다.

Clickhouse Projections

kwony — Fri, 7 Nov 2025 20:39:15 +0900

Projections

Projections | ClickHouse Docs

Page describing what projections are, how they can be used to improve query performance, and how they differ from materialized views.

clickhouse.com

Projection 은 클릭하우스에서 속도를 올리기 위한 기술중 하나다.

실질적으로 Projection 은 기존 테이블에 숨겨진 추가 테이블이라고 볼 수 있다. projection 은 기존 테이블과 행의 순서도 다르고 primary index 도 다르다. 데이터가 들어올 때마다 자동으로 그리고 점진적으로 aggregate values 들을 구해준다

Practically, a Projection can be thought of as an additional, hidden table to the original table. The projection can have a different row order, and therefore a different primary index, to that of the original table and it can automatically and incrementally pre-compute aggregate values

Projection 은 여러개의 행도 가지고 있고 삽입 시점에 미리 Aggregation 을 해준다는 점에서 Materialized Views 랑 비슷하다. 단 Materialized View 랑은 달리 기존 테이블 데이터를 주기적으로 싱크를 맞추고 있다는 점에서 다르다.

Original Table 에 대한 쿼리 요청이 들어오면 클릭하우스에서는 동일한 결과를 낼 수 있는 Projection 테이블을 선택하는데 로직은 아래와 같다.

25.5 버전부터 projection 에 두가지 방식중 하나를 선택할 수 있는데 기존처럼 모든 칼럼을 저장할지 아니면 sortingkey +_part_offset

을 같이 이용하는 방법이 있다. 후자의 경우 기존 테이블에서 데이터를 읽어오는 방식이기 때문에 용량을 차지하지는 않지만 I/O 리소스가 발생한다.

예시;

PK 가 아닌 칼럼에 대해서 필터링을 걸고 싶을때

SELECT
  tip_amount,
  trip_id,
  dateDiff('minutes', pickup_datetime, dropoff_datetime) AS trip_duration_min
FROM nyc_taxi.trips WHERE tip_amount > 200 AND trip_duration_min > 0
ORDER BY tip_amount, trip_id ASC

위의 쿼리에서는 trip_duration_min 칼럼에 대해서 조건문을 걸어주고 있는데 이게 PK 가 아니기 때문에 성능이 좋지 않다

자주쓰이는 쿼리라면 여기에 projection 을 걸어줄 수 있다. 새로운 테이블을 만든건 아니지만 dateDiff 함수를 사용할대 아래 프로젝션 로직을 사용하게 된다

ALTER TABLE nyc_taxi.trips_with_projection
ADD PROJECTION prj_tip_amount
(
    SELECT *
    ORDER BY tip_amount, dateDiff('minutes', pickup_datetime, dropoff_datetime)
)

ALTER TABLE nyc.trips_with_projection MATERIALIZE PROJECTION prj_tip_amount

Projection 을 사용하고 나면 query_log 에 projection 을 사용했다고 나온다. 반복되는 쿼리 요청이 있다면 projection 사용해서 간편하게 처리해줄 수 있을듯하다

   ┌─query─────────────────────────────────────────────────────────────────────────┬─projections──────────────────────┐
   │ SELECT                                                                       ↴│ ['default.trips.prj_tip_amount'] │
   │↳  tip_amount,                                                                ↴│                                  │
   │↳  trip_id,                                                                   ↴│                                  │
   │↳  dateDiff('minutes', pickup_datetime, dropoff_datetime) AS trip_duration_min↴│                                  │
   │↳FROM trips WHERE tip_amount > 200 AND trip_duration_min > 0                   │                                  │
   └───────────────────────────────────────────────────────────────────────────────┴──────────────────────────────────┘

Clickhouse Skip Index

kwony — Fri, 7 Nov 2025 20:33:43 +0900

Understanding ClickHouse Data Skipping Indexes | ClickHouse Docs

Skip indexes enable ClickHouse to skip reading significant chunks of data that are guaranteed to have no matching values.

clickhouse.com

전통적인 방식에서는 B-tree 구조로 데이터베이스가 행을 log(n) 시간에 찾을 수 있게 했다. 하지만 클릭하우스의 경우 개별 row 가 존재하는게 아니기 때문에 작동하지 않는다.

대신 클릭하우스에선 skip 인덱스라는 걸 사용해서 불필요한 데이터 chunk 를 읽지 않아도 되는 방식을 제공한다. 각 구조마다 Skip 인덱스 표시가 되어 있어서 청크 단위로 읽지 않아도 되는 데이터를 표시를 해준다.

Instead, ClickHouse provides a different type of index, which in specific circumstances can significantly improve query speed. These structures are labeled "Skip" indexes because they enable ClickHouse to skip reading significant chunks of data that are guaranteed to have no matching values.

유저가 data skipping index 를 만들면 data part 경로에 파일이 두개가 추가된다

skp_idx_{index_name}.idx, which contains the ordered expression values
skp_idx_{index_name}.mrk2, which contains the corresponding offsets into the associated data column files.

where 조건문에 index 가 걸린 칼럼에 대해서 접근하면 clickhouse 에서는 index 파일 데이터를 이용해서 처리해야하는 관련된 블록을 결정하고 걸러야 할 건 bypass 한다.

block 의 크기는 granularity 로 관리를 하는데 모든 색인된 블록은 별도의 granularity 를 갖고 있다. 볼지 말지 결정하는 chunk 의 크기이며 granularity 가 클수록 필터링하는 단위가 커진다.

예시

CREATE TABLE skip_table
(
  my_key UInt64,
  my_value UInt64
)
ENGINE MergeTree primary key my_key
SETTINGS index_granularity=8192;

INSERT INTO skip_table SELECT number, intDiv(number,4096) FROM numbers(100000000);

위와 같은 테이블에서 my_value 칼럼에 대해서 데이터를 조회하려고 하면 100m 개의 데이터를 모두 스캔해야하는 문제가 있다. 그래서 0.079 초가 걸림

SELECT * FROM skip_table WHERE my_value IN (125, 700)

┌─my_key─┬─my_value─┐
│ 512000 │      125 │
│ 512001 │      125 │
│    ... |      ... |
└────────┴──────────┘

8192 rows in set. Elapsed: 0.079 sec. Processed 100.00 million rows, 800.10 MB (1.26 billion rows/s., 10.10 GB/s.

여기에 인덱스를 추가하고 다시 스캐닝 해보면 속도가 0.02s 단축된 것을 확인할 수 있다. 데이터가 얼마 없어서 그리 차이는 나지 않은듯

ALTER TABLE skip_table ADD INDEX vix my_value TYPE set(100) GRANULARITY 2;

SELECT * FROM skip_table WHERE my_value IN (125, 700)

┌─my_key─┬─my_value─┐
│ 512000 │      125 │
│ 512001 │      125 │
│    ... |      ... |
└────────┴──────────┘

8192 rows in set. Elapsed: 0.051 sec. Processed 32.77 thousand rows, 360.45 KB (643.75 thousand rows/s., 7.08 MB/s.)

skip index 종류도 여러가지가 있어서 요구사항에 맞게 사용할 수 있다.

minmax 의 경우 차지하는 용량도 많지 않고 가장 간단하게 구현할 수 있는 방식이라고 한다. 최소랑 최대만 확인해주면 되기 때문에 부담이 적은듯하다. 블룸필터 같은거 쓰려면 용량도 그렇고 자료구조도 복잡해질 것 같긴 하다.

예시에서는 vix 타입의 skip index 를 사용했는데 문서상에는 vix 에 대한 설명은 나와있지 않아서 당황스럽다;

Best Practice

MySQL, PG 처럼 row 기반 DB 에서 index 는 읽어야 하는 값을 찾아주는 용도로 사용된다. 반면에 Clickhouse 는 granule 단위로 스캔하지 않아도 되는 범위를 찾는데 효과가 있다.

timestamp 처럼 row 별로 저장되는 값이 다른 경우 SKIP 할 수 있는 데이터가 많으나 gender 처럼 비슷한 데이터가 전반에 분포되어 있는 경우 SKIP 하는 granule 이 별로 없다 (block 단위로 male, female 값이 모두 존재할 것이기 때문에)

즉 데이터가 고르게 분포되어 있는 경우에는 index의 효과를 보기 어렵다고 볼 수 없다. 아래 그림처럼 대부분의 데이터에 1001 값이 존재한다면 인덱스를 걸어도 모든 granule 을 읽게 되기 때문에 효과를 보기 어렵다

clickhouse 속도를 올리기 위해 index 를 사용하는 유즈케이스의 경우 대부분은 잘못사용하는 경우라고 한다. 그래서 대안요소들을 먼저 조사하고 pk 를 바꿔보고 projection 이나 materialized view 까지 써본 다음에 최종적으로 사용하는게 좋다.

Clickhouse JSON 칼럼

kwony — Mon, 27 Oct 2025 17:12:56 +0900

How we built a new powerful JSON data type for ClickHouse

We’re excited to introduce our new and significantly enhanced JSON data type, purpose-built to deliver high-performance handling of JSON data. Our core engineer, Pavel Kruglov, dives into how we built this feature on top of ClickHouse's columnar storage.

clickhouse.com

공식 블로그 글을 읽고 공부했던 내용을 정리했다

Variant

Variant 칼럼이란게 있다.

기존 구조에서는 칼럼에는 하나의 데이터 타입만 둘 수 있었다면 Variant Type 에서는 여러가지 데이터 타입을 가질 수 있는 기능. 하나의 칼럼에 여러가지 데이터 타입의 값을 저장할 수 있다.

아래 사진을 보면 하나의 칼럼에 Int64, String, Array (String or Int64) 이렇게 다양한 타입을 저장할 수 있도록 선언했다

Variant Type 은 하나의 칼럼으로 보이지만 실제로 저장될 때는 같은 데이터 타입인 값들 끼리 별도의 서브 칼럼 형태로 저장된다. 위의 예시에서 C.Int64 는 정수형 데이터, C.string 은 문자열이 저장되는 방식이다.

For such a column, ClickHouse stores all values with the same concrete data type in separate subcolumns (type variant column data files, which by themselves look almost identical to the column data files in the previous example)

Variant 칼럼의 경우 타입에 해당하는 값만 읽어오도록 할 수 있다. Int64 타입의 데이터만 읽어오고 싶은 경우에는 아래처럼 선언해주면 된다

SELECT C.Int64 -- Int64 타입의 데이터만 읽어오는 방법
FROM test;

   ┌─C.Int64─┐
1. │      42 │
2. │    ᴺᵁᴸᴸ │
3. │    ᴺᵁᴸᴸ │
4. │      43 │
5. │    ᴺᵁᴸᴸ │
6. │    ᴺᵁᴸᴸ │
7. │      44 │
8. │    ᴺᵁᴸᴸ │
9. │    ᴺᵁᴸᴸ │
   └─────────┘

Dynamic

Variant 타입의 진화된 버전. 칼럼에 다양한 데이터 타입을 저장하면서 동시에 사용 가능한 데이터 타입의 수도 저장이 가능하다.

Variant Type 에서는 데이터 타입을 지정해줘야 했던 반면에 Dynamic 에선 별도의 데이터 타입을 지정하지 않고도 여러가지 타입의 데이터를 저장할 수 있다.

디스크 형태에 저장되는 방식은 Variant column 과 동일하고 추가적인 정보가 같이 저장된다. 위 그림에서 C.dynamic_structure.bin 파일이 있는 점이 Variant type 과 다른 점이다.

Dynamic type 에서는 추가할 수 있는 타입의 개수에 제한을 둘 수 있다. 하지만 제한을 초과한다고 저장을 못하는건 아니다. 제한을 초과한 데이터들은 공유 칼럼에 하나의 데이터로 모두 들어가게된다. 아래 그림에서 C.SharedVariant.bin 여기에 정보가 저장된다

Clickhouse JSON Type

JSON 데이터 타입은 Variant 와 Dynamic 타입을 조합해서 칼럼 데이터 타입이다. JSON 타입이 다양한 자료구조를 지원하고 있기 때문에 Variant, Dynamic 타입을 조합하는 식으로 구현한 모양이다 (이렇게 안하면 다른 방법이 없기도 하고)

JSON 칼럼 선언 방법은 아래와 같다

<column_name> JSON(
  max_dynamic_paths=N, 
  max_dynamic_types=M, 
  some.path TypeName, 
  SKIP path.to.skip, 
  SKIP REGEXP 'paths_regexp')

max_dynamic_paths: 서브 칼럼으로 저장할 수 있는 json key 의 개수. 만약에 제한을 초과하면 key 들은 동일한 서브 칼럼에 저장되게 된다.
max_dynamic_types: 같은 키인데 서로 다른 데이터 타입가 서브 칼럼으로 저장될 수 있는 수. 제한이 초과되면 마찬가지로 싱글 칼럼으로 저장되게 된다.
some.path TypeName 특정 JSON 경로에 대한 타입 힌트를 의미한다. 해당 경로로 저장되는 데이터는 특정 서브 칼럼으로 분류되기 때문에 성능이 보장된다
skip path.to.skip 특정 JSON 경로에 대해서는 저장하지 않는다. 무시할 경로에 대해서 사용하면 편함
skip regex 'path_regexp' 특정 정규식 조건의 JSON 에 대해서는 저장하지 않도록 설정한다.

JSON 칼럼 Storage 를 다이어그램으로 아래와 같이 표현할 수 있다.

a.b, a.c path 의 경우에는 타입힌트로 분류되었기 때문에 별도의 서브 칼럼으로 저장된다. a.d, a.d, a.e 의 경우에는 타입 힌트로 분류되지 않았으나 현재 칼럼이 max_dynamic_paths 조건을 초과하지 않았기 때문에 서브 칼럼으로 분류가 됐다.

여기에서 서브 칼럼의 존재를 눈여겨볼 필요가 있는데 타입힌트의 경우 dynamic 보다 데이터를 빠르게 조회할 수 있는 이유가 서브칼럼 때문이다. 개발자 시각에선 하나의 칼럼에 데이터를 저장하는것처럼 보이지만 실제론 path 별로 해당하는 데이터를 별도의 서브 칼럼에 저장했고 path 별로 스캔할 양이 달라지기 때문

max_dynamic_paths 에서도 서브 칼럼이 사용되며 max_dynamic_paths 범위를 벗어나는 경우에는 공유 칼럼을 사용하고 성능의 이점도 떨어지게 된다

c.f path 에 해당하는 데이터의 경우 dynamic paths 를 초과하는 케이스인데 저장하는 데이터 칼럼을 공유하며 내부에 저장되는 데이터 타입도 같이 저장된다

JSON 칼럼의 경우에는 python, javascript 처럼 ‘.’ 을 이용해서 json 경로 데이터에 접근하고 읽을수 있다

SELECT C.a.b
FROM test;

저장된 데이터의 서브 칼럼 타입도 같이 확인할 수 있는데 Type hint 로 따로 지정하지 않았다면 아래처럼 Dynamic 으로 표시가 된다. 다른 타입에선 어떻게 나올지는 나중에 테이블을 만들어봐야 할듯함

SELECT
    C.a.d,
    toTypeName(C.a.d)
FROM test;

   ┌─C.a.d───┬─toTypeName(C.a.d)─┐
1. │ 42      │ Dynamic           │
2. │ 43      │ Dynamic           │
3. │ ᴺᵁᴸᴸ    │ Dynamic           │
4. │ foo     │ Dynamic           │
5. │ [23,24] │ Dynamic           │
6. │ ᴺᵁᴸᴸ    │ Dynamic           │
   └─────────┴───────────────────┘

최적화

대부분 시나리오에선 dynamic json 경로가 동일한 타입을 갖고 있을 것이라고 예상할 수 있는데 이런 경우 Dynamic 타입 구분자 파일이 동일한 값을 갖게 될거고 별도의 압축이 없다면 불필요한 저장공간을 차지하게 될 것이다. discriminator 는 아래 그림처럼 행별로 타입을 구분해주는 칼럼을 의미함

비슷하게 유니크 하지만 다양한 json paths 를 저장하게 되면 각 경로의 discriminator 파일은 대부분 255 (NULL 을 의미) 값을 갖게 될 것임.

두가지 경우 모두 discriminators 파일은 압축될 것이지만 대부분의 행이 같은 값을 가지기 때문에 redundant 할 것이다.

이걸 최적화시키기 위해서 컴팩트하게 discriminator 직렬화 시키기 위한 포맷을 만들었다. discriminator 를 보통의 UInt8 로 작성하기보다 discriminator 가 target 수치와 동일하다면 세가지 데이터만 직렬화를 시킨다고 한다

클릭하우스 업데이트 빠르게 만들기

kwony — Fri, 3 Oct 2025 10:19:51 +0900

클릭하우스 업데이트는 왜 느릴까?

How we built fast UPDATEs for the ClickHouse column store – Part 1: Purpose-built enginesClickHouse is a column store, but that doesn’t mean updates are slow. In this post, we explore how purpose-built engines like ReplacingMergeTree deliver fast, effi

selfish-developer.com

지난 포스트에서 클릭하우스 업데이트가 느린 이유를 설명했고 이번 포스트에서는 업데이트 속도를 올리기 위한 클릭하우스의 트릭(?) 여러가지를 소개함. 이것도 클릭하우스 블로그 글을 읽어보고 중요한 부분들만 요약 발췌했다 .

기존 업데이트 방식

업데이트가 발생하면 클릭하우스는 뒤에서 mutation 을 실행하고 세가지 단계로 진행된다.

1. 업데이트에 대해서 새로운 block number 가 발행됨

2. mutated part 가 디스크에 저장되고 새로운 버전이 된다

3. mutation 은 기존 버전보다 낮은 part 에 대해서 적용된다.

업데이트된 칼럼에 대해서는 새로운 part 랑 링크가 추가되고 그렇지 않은 컬럼에 대해서는 hard linked 로 관리된다. 이런 작업이 백그라운드에서 진행되며 최종적으로 mutation 이 끝나고나면 데이터가 visible 하게 된다.

On the Fly updates

업데이트 결과물을 빠르게 보기 위한 방법. 실제 데이터가 rewrite 되기 전에 업데이트를 보여주게 된다.

To reduce the latency between issuing an UPDATE and seeing the result, ClickHouse introduced on-the-fly mutations, an optimization that makes updates visible immediately, even before any part is rewritten.

업데이트 결과물을 메모리에 저장하고 데이터를 로딩할 때 메모리를 거쳐서 가져간다. 이렇게하면 mutation 완료 전에도 데이터를 빠르게 볼 수 있다는 장점이 있지만 백그라운드 rewrite 작업을 피할 수 없고 update 데이터 양이 많으면 속도가 느려질 우려도 존재한다. 메모리 공간도 유한하기 계속 의지할 수 없기도 하다.

Patch part

블로그에서 중점적으로 설명하는 기술. fast insert 랑 백그라운드 머지 방법을 generalize 해서 사용하는 방식임

Patch parts borrow two proven ideas from our specialized engines, fast inserts and background merges, and generalize them, fully encapsulated for flexible, SQL-style updates:

기존 mutation 과 다르게 클릭하우스가 전체 칼럼 part 를 재작성하는게 아니라 수정된 부분에 대해서만 patch part 를 만듬

Unlike classic mutations, ClickHouse doesn’t rewrite the entire column or part. Instead, it creates a new, compact patch part that contains only:

Patch part 는 백그라운드에서 진행하는 작업에 편승하는 작업이며 오버헤드는 거의 없다

Patch parts piggyback on merges already happening in the background, they hook into the process ClickHouse already runs continuously, with almost zero overhead:

시스템 칼럽 (_part offset, _block_offset) 을 활용해서 정렬 작업을 최적화한다. 기존 데이터와 Patch part 데이터가 호환이 잘 될수 있도록 만들기 위한 작업인듯

patch part 로직을 활용하기 위해 모든 행은 세가지 시스템 칼럼을 사용한다. 칼럼을 이용해서 merge 시 인덱싱 속도를 높이는데 자세한 내용까지는 알 필요는 없을 것 같고 필요하다면 여기 읽어보기

업데이트 자체는 merge 를 기다리지 않는 non blocking 방식임: 백그라운드에서 merge 가 진행 되더라도 외부에 보여주는 데이터 자체는 이미 머지가 진행된 상태. 기존 방식에서는 백그라운드 머지가 완료된 상태여야 했다. 각각의 업데이트는 업데이트가 시작될 때의 데이터 스냅샷 기준으로 실행된다.

ClickHouse updates are non-blocking: they don’t wait for merges to finish. Instead, each update runs against a snapshot of the parts that exist when the UPDATE begins.

Featherweight Deletes

삭제 작업에서도 동일한 로직을 적용할 수 있다. Patch Part 방식처럼 삭제가 적용되는 일부 row 에다가만 업뎃을 해준다. 그래서 삭제 작업은 더이상 ALTER 명령이 아니게 된다

In Stage 1.5, lightweight DELETEs already gave us a win: they rewrote only the _row_exists deletion mask via an ALTER UPDATE, avoiding full-row rewrites.

Patch part 에서 _part_offset 1 에 해당하는 row 에 대하여 _row_exists = 0 으로 설정했고 Merged 일 때 mouse 가 삭제된 체로 업데이트 되는것을 확인할 수 있다.

How patch-on-read works

성능에 미치는 영향을 최소화해서 만들었다고함.

쿼리에서 고른 데이터는 날짜에 따라서 여러개의 data 영역 (data range) 으로 나눠짐. 요 영역들은 쿼리 엔진에 따라서 별개의 parallel stream stages 로 나눠지고 병렬 처리 절차를 따르며 결과가 나오게됨

Usually, the data selected for a query (after index analysis) is located in several data ranges (consecutive blocks of rows) in several data parts. These ranges are dynamically spread by the query engine across ① separate and parallel stream stages (data streams) and then processed by ② parallel processing lanes that filter, aggregate, sort, and limit the data into its final result:

Patch Part 는 특별한 요소처럼 보이지만 결국에는 클릭하우스 regular part 의 일종이며 다른 patch part 와 최종적으로 머지됨.

위와 같은 테크닉을 써서 성능에 영향을 미치지 않았다고 하지만 실제로 이렇게 동작하는지는 주의깊게 살펴볼 필요는 있다고 생각함.

Patch parts may seem special, but under the hood, they’re just regular parts in ClickHouse. That means:

They are merged with other patch parts using the ReplacingMergeTree algorithm, with _data_version as a version column. This ensures each patch part stores only the latest version of each updated row.
They’re automatically cleaned up once their changes are fully materialized into all affected data parts, or when merged with another patch part. Background cleanup threads handle this safely.
They count toward the TOO_MANY_PARTS threshold, which applies per partition. To mitigate this, patch parts are stored in separate partitions based on the set of updated columns. So if you run multiple UPDATE statements that affect different columns, like SET x = …, SET y = …, and SET x = …, y = …, you’ll get separate patch partitions, each with its own part count.

This design keeps patch parts fast, efficient, and deeply integrated with MergeTree mechanics.

part 가 늘어나면 일반적으로는 읽어야할 파일의 수가 늘어나기 때문에 성능에 무리가 가게 될텐데 업데이트가 많아질수록 patch part 데이터가 늘어나면서 문제가 생길 수 있는게 아닐까 싶다.