ClickHouse 100일 챌린지 22일차: 고속 분석

출처: Dev.to

ClickHouse®를 사용할 때 개발자들이 가장 많이 묻는 질문 중 하나는:

“JSON 데이터를 어떻게 저장해야 할까요?”

The answer isn’t as simple as choosing between a String column and the native JSON data type. It depends on how your application ingests, stores, and queries data.

JSON은 현대 애플리케이션의 표준 포맷이 되었습니다. API 요청, 애플리케이션 로그, 이벤트 스트림, 텔레메트리 기록, 사용자 상호작용 등 모든 것이 데이터베이스에 도달하기 전에 일반적으로 JSON으로 표현됩니다. 스키마 유연성 덕분에 새로운 속성이 즉시 데이터베이스 마이그레이션 없이 추가될 수 있는 진화 가능한 시스템에 이상적입니다.

하지만 분석용 데이터베이스는 속도를 위해 설계되었으며, 속도는 구조에서 비롯됩니다.

역사적으로 ClickHouse®에서 가장 흔한 방법은 JSON을 String으로 저장하고, JSONExtractString(), JSONExtractUInt() 및 JSONExtractBool()와 같은 함수를 사용해 쿼리 실행 중에 필드를 추출하는 방식이었습니다. 이 방식은 원본 문서가 그대로 유지되기 때문에 매우 유연합니다.

하지만 트레이드오프가 있습니다.

각 필드를 액세스하는 쿼리는 JSON 문서를 다시 파싱해야 합니다. 소규모 데이터셋에서는 이 오버헤드가 무시할 수 있지만, 수십억 건의 행에서는 JSON을 반복적으로 파싱하는 것이 비용이 많이 들고 CPU 사용량을 늘립니다.

이것은 ClickHouse가 네이티브 JSON 데이터 타입을 도입한 주요 이유 중 하나입니다.

JSON을 평범한 텍스트로 취급하는 대신, ClickHouse는 내부적으로 문서의 구조를 이해합니다. 무엇보다도 lazy parsing(지연 파싱)을 사용해 쿼리에서 참조되는 필드만 처리합니다. 쿼리가 user_id만 필요하면 ClickHouse는 문서 내 모든 중첩 속성을 파싱하는 시간을 낭비하지 않습니다.

이것은 많은 반구조화된 워크로드의 효율을 크게 향상시키면서 개발자가 기대하는 JSON의 유연성을 유지합니다.

하지만 네이티브 JSON은 만능 해결책이 아닙니다.

가장 큰 오해 중 하나는 네이티브 JSON이 사용 가능해지면 모든 속성이 JSON 객체 안에 그대로 남아야 한다고 belief하는 것입니다.

실제로는 쿼리 패턴이 스키마 설계를 주도해야 합니다.

필드가 WHERE 절, GROUP BY, 조인, 대시보드 또는 보고서에 자주 사용된다면 별도의 전용 컬럼을 두는 것이 일반적입니다. 구조화된 컬럼은 ClickHouse가 JSON 경로를 반복적으로 탐색하는 것보다 저장소, 인덱싱 및 쿼리 실행을 훨씬 더 효율적으로 최적화할 수 있게 합니다.

이것은 생산 시스템의 많은 부분에서 채택하는 하이브리드 접근법으로 이어집니다.

핵심 비즈니스 속성 — 예: user_id, event_type, 또는 timestamp —은 자주 쿼리되는 therefore 별도 컬럼으로 저장됩니다.

자주 변경되거나 자주 접근되지 않는 추가 메타데이터는 JSON 컬럼 안에 그대로 남습니다.

이것은 다음과 같은 장점을 모두 제공합니다:

• 빠른 분석 쿼리
• 유연한 스키마
• 간결한 인gestion 파이프라인
• 애플리케이션 진화에 따른 유지보수 감소

또 다른 중요한 교훈은 인gestion 패턴과 쿼리 패턴이 거의 동일하지 않다는 점입니다.

데이터가 JSON으로 도착한다고 해서 영원히 그대로 저장해야 한다는 의미는 아닙니다. 분석가와 애플리케이션이 실제로 데이터를 소비하는 방식에 맞춰 스키마를 설계하면 장기적인 성능이 크게 향상됩니다.

개발자 입장에서는 인gestion을 간단히 만드는 데 집중하기 쉽지만, 분석 시스템에서는 쿼리 성능이 전반적인 사용자 경험을 좌우합니다.

오늘날 배운 가장 큰 교훈은 JSON은 스키마 설계 전략이 아니라 도구라는 점입니다.

ClickHouse는 다음 옵션을 제공합니다:

• 원본 JSON을 String으로 저장
• 진화하는 스키마에 네이티브 JSON 데이터 타입 사용
• 자주 액세스되는 속성을 별도 컬럼으로 모델링

적절한 조합 선택은 여러분의 워크로드, 데이터, 그리고 쿼리 패턴에 따라 달라집니다.

이러한 트레이드오프를 이해하는 것은 데이터가 수백만 건에서 수십억 건으로 성장할 때 효율적으로 스케일링되는 데이터베이스와 단순히 작동하는 데이터베이스를 구분짓는 핵심 요소입니다.

분석 스택에서 JSON을 어떻게 다루고 있나요? 네이티브 JSON, 전통적인 추출 함수, 아니면 하이브리드 스키마를 사용하고 있나요?

저는 여러분의 경험을 듣고 싶습니다.

자세히 보기… https://quantrail-data.com/working-with-json-in-clickhouse-guide/