Tinybird 공동창업자, ClickHouse 18.4부터 6년간 페타바이트 클러스터 운영 경험 정리

Tinybird가 관리형 ClickHouse를 팔기 때문에 ® 표기와 비제휴 문구를 반복하는 건 법적 예방책 같음. 그래도 방문자 입장에선 ClickHouse, Inc.가 뭔지 찾아보게 되고 직접 경쟁사라는 걸 알게 되니 역효과일 수도 있음

20k rows/s를 넘고 사람이 계속 변경을 넣는 환경이면 클러스터와 이상한 쿼리를 전담해서 볼 사람이 필요하다는 말에 공감함. 예전 DBA는 쿼리와 스키마 변경을 검토하고 변화 속도를 제한하는 관문 역할을 했음

대부분 스타트업은 전통적인 컴퓨트와 스토리지 분리 구조로도 충분함. DuckDB와 S3 조합이 99.9% 사용 사례에서 얼마나 잘 버티는지 보면 놀랄 거임

요즘은 평범한 개발자에게 DB 전문가, 클라우드 전문가, 온콜 담당, 리눅스 로그 분석, AWS 비용 최적화, 고객 대응까지 다 맡기고 급여는 그대로임

다음 버전에서 고객 쿼리를 재실행할 때 now()나 근사 집계를 쓰는 쿼리는 결과를 어떻게 비교하는지 궁금함. 예상된 차이와 실제 회귀를 분리할 방법이 필요함

ClickHouse는 Pinot과 가장 가까운 편이고, 일부 면에서만 Trino가 다음으로 비슷함. Spark는 훨씬 거리가 멂

용도에 따라 다르지만 웹 분석과 로그 관리에서는 ClickHouse가 ElasticSearch를 대체하기 좋음

Trino는 연합 쿼리 엔진이고 ClickHouse, Pinot, StarRocks, Druid는 OLAP 데이터스토어라 같은 선에서 비교하면 안 됨. ClickHouse는 가장 널리 쓰이지만 조인과 상태성 데이터는 약하다고 봄

"모든 ClickHouse 회사가 수집 문제로 고생한다"는 말은 맞음. PostHog에서 수집을 맡았을 때 too many parts 문제를 겪었고, 디스크를 너무 빡빡하게 잡아 머지가 따라가려면 계속 용량을 늘려야 했음

몇 달간 MacBook에서 Langfuse를 켜둔 탓에 테라바이트 규모 ClickHouse를 운영하게 됐음. ClickHouse는 디스크 공간을 정말 좋아하지만 애플리케이션 로그 용량 효율은 다른 도구보다 좋은 편임