클릭하우스로의 이전: 3년 후

XNUMX년 전 무대 위의 Yandex의 Viktor Tarnavsky와 Alexey Milovidov HighLoad ++ 말한, ClickHouse가 얼마나 좋은지, 속도가 느려지지 않는지. 그리고 다음 스테이지에는 알렉산더 자이체프 с 보고서 이사에 대해 클릭 하우스 다른 분석 DBMS에서 다음과 같은 결론을 얻었습니다. 클릭 하우스, 물론 좋지만 그다지 편리하지는 않습니다. 2016년 당시 회사는 LifeStreet당시 Alexander가 근무하던 곳은 멀티 페타바이트 분석 시스템을 클릭 하우스, 알 수 없는 위험이 가득한 매혹적인 “노란 벽돌길”이었습니다~ 클릭 하우스 그때는 지뢰밭 같았어요.

XNUMX 년 후에 클릭 하우스 훨씬 더 좋아졌습니다. 이 기간 동안 Alexander는 Altinity라는 회사를 설립했습니다. 클릭 하우스 수십 개의 프로젝트뿐만 아니라 Yandex의 동료들과 함께 제품 자체도 개선합니다. 지금 클릭 하우스 여전히 평온한 산책은 아니지만 더 이상 지뢰밭도 아닙니다.

Alexander는 2003년부터 분산 시스템을 다루면서 대규모 프로젝트를 개발해 왔습니다. MySQL, 오라클 и 버티 카. 마지막에 HighLoad ++ 2019 사용의 선구자 중 한 명인 알렉산더(Alexander) 클릭 하우스, 이 DBMS가 지금 무엇인지 말했습니다. 주요 기능에 대해 알아 보겠습니다. 클릭 하우스: 다른 시스템과 어떻게 다른지, 어떤 경우에 사용하는 것이 더 효과적인지. 예제를 사용하여 다음을 기반으로 시스템을 구축하기 위한 최근의 프로젝트 테스트 사례를 살펴보겠습니다. 클릭 하우스.

회고: 3년 전에 일어난 일

XNUMX년 전 회사를 이전했습니다. LifeStreet 에 클릭 하우스 다른 분석 데이터베이스에서 가져온 광고 네트워크 분석 마이그레이션은 다음과 같습니다.

• 2016년 XNUMX월. 오픈 소스 출연 클릭 하우스 그리고 우리 프로젝트가 시작되었습니다.
• 8 월. 개념의 증거: 대규모 광고 네트워크, 인프라 및 200-300테라바이트의 데이터;
• 십월. 첫 번째 생산 데이터;
• 10월. 전체 제품 로드는 하루에 50억~XNUMX억 개의 이벤트입니다.
• 2017년 XNUMX월. 사용자를 다음으로 성공적으로 마이그레이션했습니다. 클릭 하우스, 2,5개 서버로 구성된 클러스터에 60페타바이트의 데이터가 있습니다.

마이그레이션 과정에서 다음과 같은 이해가 커졌습니다. 클릭 하우스 작업하기 좋은 좋은 시스템이지만 이것은 Yandex의 내부 프로젝트입니다. 따라서 미묘한 차이가 있습니다. Yandex는 먼저 자체 내부 고객을 처리한 다음 커뮤니티와 외부 사용자의 요구 사항을 처리하며 ClickHouse는 많은 기능 영역에서 기업 수준에 도달하지 못했습니다. 그래서 우리는 2017년 XNUMX월에 Altinity를 설립했습니다. 클릭 하우스 Yandex뿐만 아니라 다른 사용자에게도 더욱 빠르고 편리해졌습니다. 이제 우리는:

• 우리는 다음을 기반으로 솔루션 구축을 교육하고 지원합니다. 클릭 하우스 고객이 문제에 빠지지 않고 궁극적으로 솔루션이 작동하도록
• 우리는 연중무휴 24시간 지원을 제공합니다 클릭 하우스- 설치;
• 우리는 자체 생태계 프로젝트를 개발합니다.
• 우리는 적극적으로 자신에게 헌신합니다. 클릭 하우스, 특정 기능을 보려는 사용자의 요청에 응답합니다.

물론 이사도 도와드립니다. 클릭 하우스 с MySQL의, 버티 카, 신탁, 그린플럼, 적색 편이 그리고 다른 시스템. 우리는 다양한 움직임에 참여해왔고 모두 성공했습니다.

왜 이사하는가? 클릭 하우스

속도를 늦추지 않습니다! 이것이 주된 이유입니다. 클릭 하우스 - 다양한 시나리오에 대한 매우 빠른 데이터베이스:

오랫동안 사람들과 함께 일해 온 사람들의 무작위 인용문 클릭 하우스.

확장성. 다른 데이터베이스에서는 하나의 하드웨어로 좋은 성능을 얻을 수 있지만 클릭 하우스 간단히 서버를 추가하면 수직적으로 확장할 수 있을 뿐만 아니라 수평적으로도 확장할 수 있습니다. 모든 것이 원하는 만큼 원활하게 작동하지는 않지만 작동합니다. 비즈니스 성장에 따라 시스템을 확장할 수 있습니다. 현재 솔루션에 국한되지 않고 항상 개발 가능성이 있다는 것이 중요합니다.

이식성. 한 가지에도 집착이 없습니다. 예를 들어, 아마존 레드 시프트 어딘가로 이동하는 것이 어렵습니다. ㅏ 클릭 하우스 노트북, 서버에 설치하고 클라우드에 배포하고 다음으로 이동할 수 있습니다. Kubernetes — 인프라 운영에는 제한이 없습니다. 이는 모든 사람에게 편리하며 다른 유사한 데이터베이스가 자랑할 수 없는 큰 장점입니다.

유연성. 클릭 하우스 예를 들어 Yandex.Metrica와 같은 한 가지에만 국한되지 않고 점점 더 다양한 프로젝트와 산업에서 발전하고 사용됩니다. 새로운 문제를 해결하기 위해 새로운 기능을 추가하여 확장할 수 있습니다. 예를 들어 데이터베이스에 로그를 저장하는 것은 예의에 어긋난다고 생각되어 탄성 검색. 하지만 유연성 덕분에 클릭 하우스, 여기에 로그를 저장할 수도 있으며 종종 이것이 훨씬 더 좋습니다. 탄성 검색 -에 클릭 하우스 철분은 10배 적게 필요합니다.

무료 오픈 소스. 비용을 지불할 필요가 없습니다. 노트북이나 서버에 시스템을 설치하기 위해 허가를 협상할 필요가 없습니다. 숨겨진 수수료가 없습니다. 동시에 다른 어떤 오픈 소스 데이터베이스 기술도 속도 측면에서 경쟁할 수 없습니다. 클릭 하우스. MySQL, 마리아DB, 그린플럼 - 모두 훨씬 느립니다.

커뮤니티, 드라이브 및 장난. 에 클릭 하우스 훌륭한 커뮤니티: 모임, 채팅, 그리고 에너지와 낙천주의로 우리 모두를 충전하는 Alexey Milovidov.

클릭하우스로 이사

가기 위해 클릭 하우스 어떤 이유로든 다음 세 가지만 필요합니다.

• 한계 이해 클릭 하우스 그리고 그것이 적합하지 않은 것.
• 이용하다 기술과 그 가장 큰 장점.
• 실험. 작동 원리를 이해하는 것조차 클릭 하우스, 언제 더 빨라질지, 언제 더 느려질지, 언제 좋아질지, 언제 더 나빠질지 예측하는 것이 항상 가능한 것은 아닙니다. 그러니 시도해 보세요.

이사 문제

"그러나"는 단 하나뿐입니다. 클릭 하우스 다른 것에서 나온 경우 일반적으로 문제가 발생합니다. 우리는 우리가 가장 좋아하는 데이터베이스에서 작동하는 몇 가지 관행과 것들에 익숙합니다. 예를 들어, 함께 일하는 사람은 SQL-데이터베이스는 다음 기능 세트를 필수로 간주합니다.

• 업무;
• 제약;
• 일관성;
• 색인;
• 업데이트/삭제;
• NULL;
• 밀리초;
• 자동 유형 캐스트;
• 다중 조인;
• 임의의 파티션;
• 클러스터 관리 도구.

모집은 필수인데, XNUMX년 전 클릭 하우스 이러한 기능을 사용할 수 없었습니다! 이제 구현되지 않은 것 중 트랜잭션, 제약 조건, 일관성, 밀리초 및 유형 캐스팅 등 절반 미만이 남아 있습니다.

그리고 가장 중요한 것은 클릭 하우스 일부 표준 관행 및 접근 방식은 우리가 익숙한 것과 다르게 작동하거나 작동하지 않습니다. 에 나타나는 모든 것 클릭 하우스, "에 해당합니다.클릭하우스 방식", 즉. 기능은 다른 데이터베이스와 다릅니다. 예를 들어:

• 인덱스는 선택되지 않았지만 건너뛰었습니다.
• 업데이트/삭제 동기식은 아니고 비동기식입니다.
• 조인이 여러 개 있지만 쿼리 플래너가 없습니다. 그런 다음 수행되는 방법은 일반적으로 데이터베이스 세계의 사람들에게 명확하지 않습니다.

클릭하우스 스크립트

1960년 헝가리 출신의 미국 수학자 위그너 EP "라는 기사를 썼다.자연과학에서 수학의 불합리한 효율성"( "자연 과학에서 수학의 이해할 수없는 효율성") 우리 주변의 세계는 어떤 이유에서인지 수학 법칙으로 잘 설명되어 있습니다. 수학은 추상과학이며, 수학적 형태로 표현된 물리법칙은 사소하지 않으며, 위그너 EP 매우 이상하다고 강조했습니다.

내 관점에서, 클릭 하우스 - 똑같은 이상 함. Wigner의 말을 바꿔 말하면 다음과 같이 말할 수 있습니다. 상상할 수 없는 효율성은 놀랍습니다. 클릭 하우스 다양한 분석 응용 분야에서!

예를 들어 실시간 데이터 웨어하우스, 데이터가 거의 지속적으로 로드됩니다. 우리는 두 번째 지연을 통해 요청을 받고 싶습니다. - 사용해 주세요 클릭 하우스, 이것이 설계된 시나리오이기 때문입니다. 클릭 하우스 이것이 바로 웹뿐만 아니라 마케팅, 금융 분석에서도 사용되는 방식입니다. 애드텍h, 뿐만 아니라 사기 탐지N. 안에 실시간 데이터 웨어하우스 "별"이나 "눈송이"와 같은 복잡한 구조의 계획이 사용됩니다. JOIN (때때로 여러 개) 데이터는 일반적으로 일부 시스템에 저장되고 변경됩니다.

또 다른 시나리오를 살펴보겠습니다. 시계열: 장치, 네트워크, 사용 통계, 사물 인터넷 모니터링. 여기서 우리는 시간에 맞춰 정렬된 매우 간단한 이벤트를 접하게 됩니다. 클릭 하우스 원래는 이를 위해 개발되지 않았지만 자체적으로 잘 작동하는 것으로 나타났습니다. 이것이 바로 대기업이 사용하는 이유입니다. 클릭 하우스 정보 모니터링을 위한 저장소로 사용됩니다. 적합한지 알아보기 위해 클릭 하우스 시계열의 경우 접근 방식과 결과를 기반으로 벤치마크를 만들었습니다. 인플럭스DB и 타임스케일DB - 전문 시계열 데이터베이스. 그것은 밝혀졌다.그 클릭 하우스, 이러한 작업에 대한 최적화 없이도 외국 분야에서 승리합니다.

В 시계열 일반적으로 좁은 테이블(여러 개의 작은 열)이 사용됩니다. 모니터링을 통해 많은 양의 데이터(초당 수백만 개의 레코드)가 생성될 수 있으며 일반적으로 작은 단위로 생성됩니다(실시간 스트리밍). 따라서 다른 삽입 스크립트가 필요하며 쿼리 자체에는 고유한 세부 사항이 있습니다.

로그 관리. 데이터베이스에 로그를 수집하는 것은 일반적으로 좋지 않지만 클릭 하우스 이는 위에서 설명한 대로 몇 가지 주석을 사용하여 수행할 수 있습니다. 많은 기업에서 사용하고 있는 클릭 하우스 바로 이 목적을 위해. 이 경우 전체 로그를 저장하는 플랫 와이드 테이블을 사용합니다(예: 다음 형식). JSON) 또는 조각으로 자르십시오. 데이터는 일반적으로 대규모 배치(파일)로 로드되며 일부 필드를 기준으로 검색합니다.

이러한 각 기능에는 일반적으로 특수 데이터베이스가 사용됩니다. 클릭 하우스 사람은 모든 것을 할 수 있고 너무 잘해서 다른 사람보다 더 뛰어난 성과를 낼 수 있습니다. 이제 자세히 살펴보겠습니다. 시계열 시나리오와 올바르게 "요리"하는 방법 클릭 하우스 이 시나리오의 경우.

시계열

현재 이것이 주요 시나리오입니다. 클릭 하우스 표준 솔루션으로 간주됩니다. 시계열 시간에 따른 일련의 사건으로, 시간이 지남에 따라 일부 프로세스의 변화를 나타냅니다. 예를 들어 일일 심박수 또는 시스템의 프로세스 수가 될 수 있습니다. 일부 차원에서 시간을 표시하는 모든 것은 시계열:

이러한 유형의 이벤트는 대부분 모니터링에서 발생합니다. 이는 웹 모니터링뿐만 아니라 자동차, 산업 시스템, 만약 IoT, Yandex가 이미 트렁크에 넣은 생산 또는 무인 택시 클릭 하우스-섬기는 사람.

예를 들어 선박에서 데이터를 수집하는 회사가 있습니다. 몇 초마다 컨테이너 선박의 센서는 수백 가지의 다양한 측정값을 보냅니다. 엔지니어들은 이를 연구하고, 모델을 만들고, 선박이 얼마나 효율적으로 사용되는지 이해하려고 노력합니다. 컨테이너 선박은 단 한 순간도 유휴 상태로 있어서는 안 되기 때문입니다. 가동 중지 시간은 금전적 손실이므로 중단을 최소화하도록 경로를 예측하는 것이 중요합니다.

요즘에는 측정을 위한 전문 데이터베이스가 성장하고 있습니다. 시계열. 현장 DB 엔진 다양한 데이터베이스에는 순위가 지정되어 있으며 유형별로 볼 수 있습니다.

가장 빠르게 성장하는 유형은 다음과 같습니다. 시계열에스. 그래프 데이터베이스도 성장하고 있지만 시계열지난 몇 년 동안 더 빠르게 성장해 왔습니다. 이 데이터베이스 제품군의 일반적인 대표자는 다음과 같습니다. 인플럭스DB, 프로 메테우스, KDB, 타임스케일DB (기반 PostgreSQL), 솔루션 아마존. 클릭 하우스 여기서도 사용할 수 있고 사용됩니다. 몇 가지 공개적인 예를 들어보겠습니다.

선구자 중 하나는 회사입니다. CloudFlare (CDN-공급자). 그들은 그들의 CDN 를 통해 클릭 하우스 (DNS-요청, HTTP-쿼리) 엄청난 로드 - 초당 6만 개의 이벤트. 모든 것이 통과됩니다 카프카, 로 이동 클릭 하우스, 시스템의 이벤트 대시보드를 실시간으로 볼 수 있는 기회를 제공합니다.

컴캐스트 - 미국 통신 분야의 리더 중 하나: 인터넷, 디지털 TV, 전화 통신. 그들은 유사한 제어 시스템을 만들었습니다. CDN 안에 오픈 소스 계획 아파치 트래픽 제어 당신의 거대한 데이터를 다루기 위해. 클릭 하우스 분석을 위한 백엔드로 사용됩니다.

퍼 코나 내장 클릭 하우스 너의 안에 PMM다양한 모니터링을 저장하기 위해 MySQL의.

특정 요구 사항

시계열 데이터베이스에는 고유한 특정 요구 사항이 있습니다.

• 많은 에이전트로부터 빠른 삽입. 우리는 많은 스트림에서 데이터를 매우 빠르게 삽입해야 합니다. 클릭 하우스 모든 삽입물이 비차단형이기 때문에 이 작업이 잘 수행됩니다. 어느 삽입하다 디스크의 새 파일이며 작은 삽입은 어떤 방식으로든 버퍼링될 수 있습니다. 안에 클릭 하우스 한 번에 한 줄씩 데이터를 삽입하는 것보다 큰 배치로 데이터를 삽입하는 것이 좋습니다.
• 유연한 계획. 에 시계열 우리는 일반적으로 데이터 구조를 완전히 알지 못합니다. 특정 애플리케이션에 대한 모니터링 시스템을 구축하는 것은 가능하지만 다른 애플리케이션에 사용하기는 어렵습니다. 이를 위해서는 보다 유연한 계획이 필요합니다. 클릭 하우스를 사용하면 강력한 형식의 기본임에도 불구하고 이 작업을 수행할 수 있습니다.
• 효율적인 저장 및 데이터 잊어버리기. 보통 시계열 엄청난 양의 데이터이므로 최대한 효율적으로 저장해야 합니다. 예를 들어, 인플럭스DB 좋은 압축이 주요 특징입니다. 하지만 저장하는 것 외에도 오래된 데이터를 "잊고" 일종의 작업을 수행할 수 있어야 합니다. 다운 샘플링 — 집계의 자동 계산.
• 집계된 데이터에 대한 빠른 쿼리. 때로는 지난 5분을 밀리초 단위의 정확도로 보는 것이 흥미롭지만 월별 데이터에서는 분 또는 초 단위의 세분성이 필요하지 않을 수도 있습니다. 일반 통계만으로 충분합니다. 이런 종류의 지원이 필요합니다. 그렇지 않으면 3개월 요청을 완료하는 데 매우 오랜 시간이 걸립니다. 클릭 하우스.
• "와 같은 요청마지막 지점 현재». 이는 다음의 경우에 일반적입니다. 시계열 쿼리: 특정 시점의 마지막 측정값이나 시스템 상태를 확인하세요. t. 이는 데이터베이스에 대한 그다지 유쾌한 쿼리는 아니지만 이를 수행할 수 있어야 합니다.
• "접착" 시계열. 시계열 시계열이다. 두 개의 시계열이 있는 경우 연결 및 상관관계가 필요한 경우가 많습니다. 특히 정렬되지 않은 시계열의 경우 모든 데이터베이스에서 이 작업을 수행하는 것은 편리하지 않습니다. 여기에는 몇 가지 시점이 있고 다른 시점도 있습니다. 평균을 고려할 수 있지만 갑자기 거기에 여전히 구멍이 생기기 때문에 명확하지 않습니다.

이러한 요구 사항이 어떻게 충족되는지 살펴 보겠습니다. 클릭 하우스.

계획

В 클릭 하우스 계획 시계열 데이터의 규칙성 정도에 따라 다양한 방식으로 수행될 수 있습니다. 모든 지표를 미리 알면 일반 데이터를 기반으로 시스템을 구축하는 것이 가능합니다. 예를 들면 이런 짓을 했어요 CloudFlare 모니터링으로 CDN 잘 최적화된 시스템입니다. 전체 인프라와 다양한 서비스를 모니터링하는 보다 일반적인 시스템을 구축할 수 있습니다. 불규칙한 데이터의 경우 우리는 무엇을 모니터링하고 있는지 미리 알 수 없으며 이것이 아마도 가장 일반적인 경우일 것입니다.

일반 데이터. 열. 구성표는 간단합니다. 필수 유형이 있는 열은 다음과 같습니다.

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

이것은 일종의 시스템 로딩 활동을 모니터링하는 일반 테이블입니다(사용자, 체계, 유휴, 좋은). 간단하고 편리하지만 유연하지는 않습니다. 보다 유연한 체계를 원한다면 배열을 사용할 수 있습니다.

불규칙한 데이터. 배열:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

구조 중첩 두 개의 배열이 있습니다. 측정항목.이름 и 측정항목.값. 여기에는 각 이벤트에 대한 이름 배열 및 측정값 배열과 같은 임의 모니터링 데이터를 저장할 수 있습니다. 추가 최적화를 위해 이러한 구조를 하나만 만드는 대신 여러 개를 만들 수 있습니다. 예를 들어, 뜨다-가치, 또 다른 -에 대한 INT-왜냐하면 의미 INT 좀 더 효율적으로 보관하고 싶어요.

그러나 그러한 구조는 접근하기가 더 어렵습니다. 먼저 인덱스 값을 가져온 다음 배열 값을 꺼내려면 특수 함수를 사용하는 특수 구성을 사용해야 합니다.

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

그러나 여전히 매우 빠르게 작동합니다. 불규칙한 데이터를 저장하는 또 다른 방법은 행 단위입니다.

불규칙한 데이터. 문자열. 이 전통적인 방법에서는 배열이 없으면 이름과 값이 동시에 저장됩니다. 한 장치에서 동시에 5개의 측정값이 나오면 데이터베이스에 000개의 행이 생성됩니다.

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

클릭 하우스 이에 대처합니다 - 특별한 확장 기능이 있습니다 클릭 하우스 SQL. 예를 들어, 최대 경우 — 일부 조건이 충족되면 메트릭으로 최대값을 계산하는 특수 기능입니다. 하나의 요청으로 이러한 표현식을 여러 개 작성하고 여러 측정항목의 값을 즉시 계산할 수 있습니다.

세 가지 접근 방식을 비교해 보겠습니다.

세부

여기서는 일부 테스트 데이터 세트에 대해 "디스크 데이터 크기"를 추가했습니다. 열의 경우 데이터 크기가 가장 작습니다(최대 압축, 최대 쿼리 속도). 하지만 모든 것을 한 번에 기록해야 하므로 비용을 지불합니다.

배열의 경우 모든 것이 조금 더 나쁩니다. 데이터는 여전히 잘 압축되어 있으며 불규칙한 패턴이 저장될 수 있습니다. 하지만 클릭 하우스 - 컬럼형 데이터베이스이며 모든 것을 배열에 저장하기 시작하면 XNUMX행으로 바뀌고 효율성과 유연성에 대한 대가를 지불합니다. 어떤 작업을 수행하든 전체 배열을 메모리로 읽어온 다음 그 안에서 원하는 요소를 찾아야 합니다. 배열이 커지면 속도가 저하됩니다.

이 접근 방식을 사용하는 회사 중 하나(예: 동네 짱), 배열은 128개 요소의 조각으로 잘립니다. 하루에 200TB의 데이터 볼륨을 갖는 수천 개의 메트릭 데이터는 하나의 어레이가 아닌 특수한 스토리지 로직을 통해 10개 또는 30개의 어레이에 저장됩니다.

가장 간단한 접근 방식은 문자열을 사용하는 것입니다. 하지만 데이터 압축이 제대로 되지 않고, 테이블 크기가 크고, 쿼리가 여러 지표를 기반으로 하는 경우에도 ClickHouse가 최적으로 작동하지 않습니다.

하이브리드 방식

배열 회로를 선택했다고 가정해 봅시다. 그러나 대부분의 대시보드에 사용자 및 시스템 측정항목만 표시된다는 사실을 알고 있다면 다음과 같은 방식으로 이러한 측정항목을 테이블 수준 배열의 열로 추가로 구체화할 수 있습니다.

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

삽입할 때 클릭 하우스 자동으로 계산됩니다. 이렇게 하면 비즈니스와 즐거움을 결합할 수 있습니다. 계획은 유연하고 일반적이지만 가장 자주 사용되는 열을 뽑아냈습니다. 이는 인서트를 변경할 필요가 없다는 점에 유의하십시오. ETL계속해서 테이블에 배열을 삽입합니다. 우리는 방금 했어요 ALTER TABLE, 두 개의 스피커를 추가했으며 즉시 사용할 수 있는 더 빠른 하이브리드 구성표를 얻었습니다.

코덱 및 압축

에 시계열 정보의 양이 매우 클 수 있으므로 데이터를 얼마나 잘 압축하는지가 중요합니다. 안에 클릭 하우스 1:10, 1:20, 때로는 그 이상의 압축 효과를 얻기 위한 도구 세트가 있습니다. 이는 디스크에 압축을 푼 데이터 1TB가 50~100GB를 차지한다는 의미입니다. 크기가 작을수록 좋으며, 데이터를 더 빨리 읽고 처리할 수 있습니다.

높은 수준의 압축을 달성하려면, 클릭 하우스 다음 코덱을 지원합니다:

예제 테이블:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

여기서 우리는 코덱을 정의합니다 더블델타 한 경우에는, 두 번째 경우에는 - 고릴라, 그리고 우리는 확실히 더 많은 것을 추가할 것입니다 LZ4 압축. 결과적으로 디스크의 데이터 크기가 크게 줄어듭니다.

이는 동일한 데이터가 차지하는 공간을 보여 주지만 서로 다른 코덱과 압축을 사용합니다.

• 디스크의 GZIP 파일에 있습니다.
• ClickHouse에서는 코덱이 없지만 ZSTD 압축이 사용됩니다.
• ClickHouse에서 코덱과 압축 LZ4 및 ZSTD를 사용합니다.

코덱이 있는 테이블이 훨씬 적은 공간을 차지하는 것을 볼 수 있습니다.

크기 문제

덜 중요하지 않다 선택 올바른 데이터 유형:

위의 모든 예에서 내가 사용한 플로트64. 하지만 우리가 선택했다면 플로트32, 그러면 그게 더 좋을 것 같아요. 이것은 위에 링크된 기사에서 Perkona의 사람들에 의해 잘 입증되었습니다. 작업에 적합한 가장 컴팩트한 유형을 사용하는 것이 중요합니다. 쿼리 속도보다 디스크 크기가 훨씬 적습니다. 클릭 하우스 이것에 매우 민감합니다.

당신이 사용할 수 있다면 int32 대신 int64, 그러면 성능이 거의 두 배 증가할 것으로 예상됩니다. 데이터는 메모리를 덜 차지하며 모든 "산술"이 훨씬 빠르게 작동합니다. 클릭 하우스 내부적으로는 매우 엄격한 유형의 시스템이므로 최신 시스템이 제공하는 모든 가능성을 최대한 활용합니다.

집계 및 구체화 된 뷰

집계 및 구체화된 뷰를 사용하면 다양한 경우에 대한 집계를 생성할 수 있습니다.

예를 들어, 집계되지 않은 소스 데이터가 있을 수 있으며 특수 엔진을 통한 자동 합산을 통해 다양한 구체화된 뷰를 여기에 연결할 수 있습니다. SummingMergeTree(SMT). SMT 집계를 자동으로 계산하는 특수 집계 데이터 구조입니다. 원시 데이터가 데이터베이스에 삽입되고 자동으로 집계되며 대시보드를 즉시 사용할 수 있습니다.

TTL - 오래된 데이터를 "잊어"

더 이상 필요하지 않은 데이터를 "잊는" 방법은 무엇입니까? 클릭 하우스 이 작업을 수행하는 방법을 알고 있습니다. 테이블을 생성할 때 다음을 지정할 수 있습니다. TTL 예를 들어, 하루 동안의 분 데이터, 30일 동안의 일일 데이터를 저장하고 주별 또는 월별 데이터를 절대 건드리지 않는다는 것입니다.

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

다 계층 - 디스크 전체에 데이터 분할

이 아이디어를 더 발전시키면 데이터를 다음 위치에 저장할 수 있습니다. 클릭 하우스 다른 장소에서. 매우 빠른 로컬 컴퓨터에 지난 주의 핫 데이터를 저장하고 싶다고 가정해 보겠습니다. SSD, 더 많은 과거 데이터를 다른 곳에 두었습니다. 안에 클릭 하우스 이제 이것이 가능합니다:

스토리지 정책(스토리지 정책) 그래서 클릭 하우스 특정 조건에 도달하면 자동으로 데이터를 다른 저장소로 전송합니다.

하지만 그게 전부는 아닙니다. 특정 테이블 수준에서 데이터가 콜드 스토리지에 들어가는 정확한 시점에 대한 규칙을 정의할 수 있습니다. 예를 들어 데이터는 7일 동안 매우 빠른 디스크에 저장되고 오래된 모든 데이터는 느린 디스크로 전송됩니다. 이는 비용을 제어하고 콜드 데이터에 돈을 낭비하지 않으면서 시스템을 최대 성능으로 유지할 수 있기 때문에 좋습니다.

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

독특한 기능 클릭 하우스

거의 모든 것에서 클릭 하우스 이러한 "하이라이트"가 있지만 다른 데이터베이스에는 없는 독점성으로 인해 상쇄됩니다. 예를 들어, 다음은 몇 가지 고유한 기능입니다. 클릭 하우스:

• 어레이. 에 클릭 하우스 배열에 대한 매우 훌륭한 지원은 물론 배열에 대한 복잡한 계산을 수행하는 기능도 있습니다.
• 데이터 구조 집계. 이것은 "킬러 기능" 중 하나입니다. 클릭 하우스. Yandex 직원이 데이터를 집계하고 싶지 않다고 말했음에도 불구하고 모든 것이 클릭 하우스, 빠르고 편리하기 때문이죠.
• 구체화된 뷰. 데이터 구조 집계와 함께 구체화된 뷰를 사용하면 편리하게 실시간 집합.
• 클릭하우스SQL. 이것은 언어 확장입니다 SQL 에서만 사용할 수 있는 추가 및 독점 기능이 포함되어 있습니다. 클릭 하우스. 이전에는 한편으로는 확장 같았고 다른 한편으로는 단점이었습니다. 이제 거의 모든 단점이 비교되었습니다. SQL92 우리는 그것을 제거했고 이제는 단지 확장일 뿐입니다.
• 람다- 표현. 아직도 데이터베이스에 있나요?
• ML-지원하다. 이는 다양한 데이터베이스에서 사용할 수 있으며 일부는 더 좋고 일부는 더 나쁩니다.
• 오픈 소스. 우리는 확장할 수 있습니다 클릭 하우스 함께. 지금에 클릭 하우스 약 500명의 기여자가 있으며 이 숫자는 지속적으로 증가하고 있습니다.

까다로운 쿼리

В 클릭 하우스 동일한 작업을 수행하는 방법에는 여러 가지가 있습니다. 예를 들어, 다음 세 가지 방법으로 테이블의 마지막 값을 반환할 수 있습니다. CPU (네 번째도 있지만 훨씬 더 이국적입니다).

첫 번째는 다음에서 수행하는 것이 얼마나 편리한지 보여줍니다. 클릭 하우스 확인하고 싶을 때 쿼리 튜플 하위 쿼리에 포함되어 있습니다. 이것은 제가 개인적으로 다른 데이터베이스에서 정말 놓쳤던 부분입니다. 하위 쿼리와 비교하려는 경우 다른 데이터베이스에서는 스칼라만 비교할 수 있지만 여러 열에 대해 작성해야 합니다. JOIN. 에 클릭 하우스 튜플을 사용할 수 있습니다.

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

두 번째 방법은 동일한 작업을 수행하지만 집계 함수를 사용합니다. 인수최대:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В 클릭 하우스 수십 개의 집계 함수가 있으며 조합자를 사용하면 조합법의 법칙에 따라 약 천 개를 얻게 됩니다. ArgMax - 최대값을 계산하는 함수 중 하나: 요청이 값을 반환합니다. 사용법_사용자, 최대값에 도달하는 지점 생성_시간:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

가입부터 — 다른 시간의 행을 "접착"합니다. 이는 데이터베이스에서만 사용할 수 있는 고유한 기능입니다. kdb +. 시간이 서로 다른 두 개의 시계열이 있는 경우 가입부터 한 번의 요청으로 이동하고 병합할 수 있습니다. 한 시계열의 각 값에 대해 다른 시계열에서 가장 가까운 값을 찾아 동일한 줄에 반환합니다.

분석 기능

표준에서 SQL-2003 다음과 같이 작성할 수 있습니다.

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В 클릭 하우스 그렇게 할 수 없습니다. 표준을 지원하지 않습니다. SQL-2003 그리고 아마 절대 그렇게 하지 않을 것이다. 대신에 클릭 하우스 다음과 같이 작성하는 것이 관례입니다.

나는 람다를 약속했습니다. 여기 있습니다!

이는 표준의 분석 쿼리와 유사합니다. SQL-2003: 그는 둘 사이의 차이를 센다 타임스탬프, 기간, 서수 - 일반적으로 분석 기능을 고려하는 모든 것. 안에 클릭 하우스 배열을 통해 개수를 계산합니다. 먼저 데이터를 배열로 축소한 다음 배열에서 원하는 모든 작업을 수행한 다음 다시 확장합니다. 매우 편리하지는 않습니다. 최소한 함수형 프로그래밍에 대한 애정이 필요하지만 매우 유연합니다.

특별한 기능

게다가 에서는 클릭 하우스 많은 전문 기능. 예를 들어, 동시에 진행되는 세션 수를 확인하는 방법은 무엇입니까? 일반적인 모니터링 작업은 한 번의 요청으로 최대 로드를 결정하는 것입니다. 안에 클릭 하우스 이 목적을 위한 특별한 기능이 있습니다:

일반적으로 ClickHouse에는 다양한 목적을 위한 특수 기능이 있습니다.

• runningDifference, runningAccumulate, 이웃;
• sumMap(키, 값);
• timeSeriesGroupSum(uid, 타임스탬프, 값);
• timeSeriesGroupRateSum(uid, 타임스탬프, 값);
• SkewPop, SkewSamp, KurtPop, KurtSamp;
• 채우기 포함 / 넥타이 포함;
• 단순선형회귀, 확률적선형회귀.

이것은 전체 기능 목록이 아니며 총 500-600개입니다. 힌트: 모든 기능은 클릭 하우스 시스템 테이블에 있습니다(모두 문서화되어 있지는 않지만 모두 흥미롭습니다).

select * from system.functions order by name

클릭 하우스 다음을 포함하여 자체에 대한 많은 정보를 저장합니다. 로그 테이블, 쿼리_로그, 추적 로그, 데이터 블록 작업 로그(부품로그), 메트릭 로그, 시스템 로그 등이 있으며 일반적으로 디스크에 기록됩니다. 로그 측정항목은 시계열 в 클릭 하우스 사실은 클릭 하우스: 데이터베이스 자체가 역할을 할 수 있다 시계열 데이터베이스 자체를 "삼키게" 됩니다.

이것은 또한 독특한 일입니다. 우리가 좋은 일을 하고 있기 때문입니다. 시계열, 왜 우리는 필요한 모든 것을 우리 자신 안에 저장할 수 없습니까? 우리는 필요하지 않다 프로 메테우스, 우리는 모든 것을 스스로에게 맡깁니다. 연결됨 그라 파나 그리고 우리는 우리 자신을 모니터링합니다. 그러나 만일 클릭 하우스 넘어지면 이유를 알 수 없기 때문에 일반적으로 그렇게하지 않습니다.

큰 클러스터 또는 여러 개의 작은 클러스터 클릭 하우스

하나의 큰 클러스터 또는 여러 개의 작은 ClickHouse 중 무엇이 더 낫습니까? 전통적인 접근 방식 DWH 각 애플리케이션에 회선이 할당되는 대규모 클러스터입니다. 우리는 데이터베이스 관리자를 찾아갔습니다. 우리에게 다이어그램을 주자 그들은 우리에게 다음과 같은 다이어그램을 주었습니다.

В 클릭 하우스 다르게 할 수 있습니다. 각 애플리케이션을 자신만의 것으로 만들 수 있습니다. 클릭 하우스:

더 이상 그 거대하고 괴물스러운 것은 필요하지 않습니다. DWH 그리고 다루기 힘든 관리자. 각 애플리케이션에 고유한 기능을 제공할 수 있습니다. 클릭 하우스, 개발자가 직접 할 수 있습니다. 클릭 하우스 설치가 매우 쉽고 복잡한 관리가 필요하지 않습니다.

하지만 우리가 가진 것이 많으면 클릭 하우스, 자주 설치해야 하는 경우 이 프로세스를 자동화하려고 합니다. 이를 위해 예를 들어 다음을 사용할 수 있습니다. Kubernetes и 클릭하우스-운영자. 안에 쿠버네티스 클릭하우스 "클릭 시"로 설정할 수 있습니다. 버튼을 클릭하고 매니페스트를 실행하면 데이터베이스가 준비됩니다. 즉시 다이어그램을 만들고 여기에 지표 업로드를 시작하면 5분 안에 대시보드가 ​​준비됩니다. 그라 파나. 정말 간단해요!

결과는 어떻습니까?

따라서, 클릭 하우스 - 이것:

• 빨리. 모두가 이것을 알고 있습니다.
• 다만. 조금 논란의 여지가 있지만 훈련은 어렵고 전투는 쉽다고 생각합니다. 방법을 이해했다면 클릭 하우스 작동하면 모든 것이 매우 간단합니다.
• 보편적으로. 다양한 시나리오에 적합합니다. DWH, 시계열, 로그 스토리지. 하지만 그렇지 않다 OLTP 데이터베이스에 짧은 삽입이나 읽기를 시도하지 마세요.
• 재미있게. 아마 같이 일하는 사람이겠지 클릭 하우스, 좋은 의미와 나쁜 의미에서 많은 흥미로운 순간을 경험했습니다. 예를 들어, 새 릴리스가 나왔고 모든 것이 작동을 멈췄습니다. 혹은 이틀 동안 한 가지 일로 어려움을 겪었는데, 텔레그램 채팅으로 질문하고 나면 XNUMX분 만에 일이 해결되기도 했습니다. 또는 Lesha Milovidov 보고서의 회의에서와 같이 클릭 하우스 방송을 끊었다 HighLoad ++. 이런 일은 늘 일어나며 우리의 삶을 힘들게 합니다. 클릭 하우스 밝고 흥미롭다!

프레젠테이션을 시청할 수 있습니다. 여기에.

오랫동안 기다려온 고부하 시스템 개발자 회의 HighLoad ++ Skolkovo에서 9월 10일과 XNUMX일에 개최됩니다. 마지막으로, HighLoad++의 에너지는 온라인으로 담을 수 없기 때문에 이것은 오프라인 컨퍼런스가 될 것입니다(비록 모든 예방 조치가 이루어졌지만).

컨퍼런스를 위해 우리는 기술의 최대 기능에 대한 사례를 찾고 보여줍니다. HighLoad++는 Facebook, Yandex, VKontakte, Google 및 Amazon이 작동하는 방식을 이틀 안에 배울 수 있는 유일한 장소였으며 앞으로도 그럴 것입니다.

2007년부터 쉬지 않고 모임을 이어온 우리는 올해로 14번째 모임을 갖게 되었습니다. 이 기간 동안 컨퍼런스는 10배 성장했으며, 지난해에는 업계 핵심 행사로 3339명의 참가자, 165명의 발표자, 보고서 및 밋업이 모였으며 16개 트랙이 동시에 진행되었습니다.
작년에는 버스 20대, 차와 커피 5280리터, 과일 음료 1650리터, 생수 10200병이 있었습니다. 그리고 또 다른 음식 2640kg, 접시 16개, 컵 000개입니다. 그런데 재활용 종이로 모은 돈으로 참나무 모종 25그루를 심었습니다 :)

티켓을 구매하실 수 있습니다 여기에, 컨퍼런스 소식을 받아보세요 - 여기에, 모든 소셜 네트워크에서 대화하세요. 텔레그램, 페이스북, 명 Vkontakte и 트위터.

출처 : habr.com