ELK, Big Query 및 TimescaleDB를 대신하여 Clickhouse 사용

클릭하우스 Yandex에서 만든 온라인 OLAP(분석 쿼리 처리)용 오픈 소스 열 기반 데이터베이스 관리 시스템입니다. Yandex, CloudFlare, VK.com, Badoo 및 전 세계의 기타 서비스에서 매우 많은 양의 데이터(초당 수천 행 삽입 또는 디스크에 저장된 페타바이트 데이터 삽입)를 저장하는 데 사용됩니다.

일반적인 "문자열" DBMS(예: MySQL, Postgres, MS SQL Server)에서 데이터는 다음 순서로 저장됩니다.

이 경우 하나의 행과 관련된 값이 물리적으로 나란히 저장됩니다. columnar DBMS에서는 서로 다른 column의 값을 별도로 저장하고 한 column의 데이터를 함께 저장한다.

열 기반 DBMS의 예로는 Vertica, Paraccel(Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB(VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+가 있습니다.

회사는 메일 포워더 큐윈트리 저는 2018년에 보고를 위해 Clickhouse를 사용하기 시작했고 그 단순성, 확장성, SQL 지원 및 속도에 깊은 인상을 받았습니다. 이 DBMS의 속도는 마법에 가까웠다.

편함

Clickhouse는 단일 명령으로 Ubuntu에 설치됩니다. SQL을 알고 있다면 필요에 따라 Clickhouse를 즉시 사용할 수 있습니다. 그러나 이것이 MySQL에서 "생성 테이블 표시"를 수행하고 Clickhouse에서 SQL을 복사하여 붙여넣을 수 있음을 의미하지는 않습니다.

MySQL과 비교할 때 이 DBMS의 테이블 스키마 정의에는 중요한 데이터 유형 차이가 있으므로 테이블 스키마 정의를 변경하고 테이블 엔진을 익히려면 여전히 시간이 필요합니다.

Clickhouse는 추가 소프트웨어 없이 훌륭하게 작동하지만 복제를 사용하려면 ZooKeeper를 설치해야 합니다. 쿼리 성능 분석은 우수한 결과를 보여줍니다. 시스템 테이블에는 모든 정보가 포함되어 있으며 모든 데이터는 오래되고 지루한 SQL을 사용하여 얻을 수 있습니다.

Производительность

• 기준 구성 서버에서 Clickhouse와 Vertica 및 MySQL 비교: 소켓 5개 Intel® Xeon® CPU E2650-2 v2.60 @ 128GHz; 5GiB RAM; 8 6TB SATA HDD의 md RAID-4, extXNUMX.
• 기준 Clickhouse와 Amazon RedShift 클라우드 스토리지 비교.
• 블로그 발췌 Clickhouse 성능에 대한 Cloudflare:

ClickHouse 데이터베이스는 디자인이 매우 단순합니다. 클러스터의 모든 노드는 동일한 기능을 가지며 조정을 위해 ZooKeeper만 사용합니다. 우리는 여러 노드의 작은 클러스터를 구축하고 테스트를 수행했으며 그 동안 시스템이 분석 DBMS 벤치마크에서 주장된 이점에 해당하는 상당히 인상적인 성능을 가지고 있음을 발견했습니다. ClickHouse의 개념을 자세히 살펴보기로 했습니다. 연구의 첫 번째 장애물은 도구의 부족과 ClickHouse의 소규모 커뮤니티였기 때문에 작동 방식을 이해하기 위해 이 DBMS의 설계를 조사했습니다.

ClickHouse는 단순한 데이터베이스이므로 Kafka에서 직접 데이터 수신을 지원하지 않으므로 Go에서 자체 어댑터 서비스를 작성했습니다. Kafka에서 Cap'n Proto로 인코딩된 메시지를 읽고 TSV로 변환한 다음 HTTP 인터페이스를 통해 일괄적으로 ClickHouse에 삽입했습니다. 우리는 나중에 성능을 개선하기 위해 자체 ClickHouse 인터페이스와 함께 Go 라이브러리를 사용하도록 이 서비스를 다시 작성했습니다. 수신 패킷의 성능을 평가할 때 중요한 사실을 발견했습니다. ClickHouse의 경우 이 성능은 패킷의 크기, 즉 동시에 삽입되는 행의 수에 크게 좌우된다는 것이 밝혀졌습니다. 이런 일이 발생하는 이유를 이해하기 위해 ClickHouse가 데이터를 저장하는 방법을 연구했습니다.

데이터 저장을 위해 ClickHouse에서 사용하는 기본 엔진 또는 오히려 테이블 엔진 제품군은 MergeTree입니다. 이 엔진은 Google BigTable 또는 Apache Cassandra에서 사용되는 LSM 알고리즘과 개념적으로 유사하지만 중간 메모리 테이블을 구축하지 않고 데이터를 디스크에 직접 씁니다. 이렇게 하면 삽입된 각 패킷이 "기본 키" 기본 키에 의해서만 정렬되고 압축되고 세그먼트를 형성하기 위해 디스크에 기록되기 때문에 뛰어난 쓰기 처리량이 제공됩니다.

메모리 테이블이 없거나 데이터의 "신선도" 개념이 없다는 것은 추가만 가능하고 시스템은 변경이나 삭제를 지원하지 않는다는 것을 의미합니다. 현재 데이터를 삭제하는 유일한 방법은 세그먼트가 월 경계를 넘지 않기 때문에 월 단위로 데이터를 삭제하는 것입니다. ClickHouse 팀은 이 기능을 사용자 정의할 수 있도록 적극적으로 노력하고 있습니다. 반면에 쓰기 및 병합 세그먼트에 경합이 없도록 하므로 수신 처리량은 I/O 또는 코어가 포화될 때까지 병렬 삽입 수에 따라 선형적으로 확장됩니다.
그러나 이 상황은 시스템이 작은 패킷에 적합하지 않다는 것을 의미하므로 Kafka 서비스 및 삽입기가 버퍼링에 사용됩니다. 또한 백그라운드의 ClickHouse는 지속적으로 세그먼트를 병합하므로 많은 작은 정보가 더 많이 결합되고 기록되므로 기록 강도가 높아집니다. 그러나 관련되지 않은 부품이 너무 많으면 병합이 계속되는 한 삽입이 과도하게 조절됩니다. 실시간 데이터 수집과 수집 성능 간의 최상의 절충안은 테이블에 초당 제한된 수의 삽입을 허용하는 것입니다.

테이블 읽기 성능의 핵심은 디스크에서 데이터의 인덱싱 및 위치입니다. 아무리 처리 속도가 빨라도 엔진이 디스크에서 테라바이트의 데이터를 스캔하고 그 중 일부만 사용해야 하는 경우에는 시간이 걸립니다. ClickHouse는 열 저장소이므로 각 세그먼트에는 각 행에 대해 정렬된 값이 있는 각 열(열)에 대한 파일이 포함됩니다. 따라서 쿼리에 없는 전체 열을 먼저 건너뛴 다음 여러 셀을 벡터화된 실행과 병렬로 처리할 수 있습니다. 전체 스캔을 방지하기 위해 각 세그먼트에는 작은 인덱스 파일이 있습니다.

모든 열이 "기본 키"로 정렬되는 경우 인덱스 파일에는 매우 큰 테이블의 경우에도 메모리에 유지할 수 있도록 모든 N번째 행의 레이블(캡처된 행)만 포함됩니다. 예를 들어 기본 설정을 "8192번째 행마다 표시"로 설정한 다음 1조 개의 테이블을 "빈약하게" 인덱싱하도록 설정할 수 있습니다. 메모리에 쉽게 들어가는 줄은 122자만 있으면 됩니다.

시스템 개발

Clickhouse의 개발 및 개선은 다음에서 추적할 수 있습니다. Github 레포 "성장"의 과정이 인상적인 속도로 진행되고 있는지 확인하십시오.

인기

Clickhouse의 인기는 특히 러시아어를 사용하는 커뮤니티에서 기하급수적으로 증가하고 있는 것 같습니다. 작년 High load 2018 컨퍼런스(모스크바, 8년 9월 2018-40일)에서는 vk.com 및 Badoo와 같은 괴물이 동시에 수만 대의 서버에서 데이터(예: 로그)를 삽입하는 Clickhouse를 사용하는 것으로 나타났습니다. XNUMX분짜리 영상으로 VKontakte 팀의 Yuri Nasretdinov가 수행 방법에 대해 설명합니다.. 곧 우리는 자료 작업의 편의를 위해 Habr에 대본을 게시할 것입니다.

응용 분야

시간을 들여 조사한 결과 ClickHouse가 유용하거나 MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot 및 드루이드. 다음은 ClickHouse를 이용하여 위의 DBMS를 업그레이드하거나 완전히 교체하는 내용입니다.

MySQL 및 PostgreSQL 확장

가장 최근에는 뉴스레터 플랫폼용으로 MySQL을 ClickHouse로 부분적으로 교체했습니다. 마우틱 뉴스레터. 문제는 잘못된 설계로 인해 MySQL이 전송된 모든 이메일과 해당 이메일의 모든 링크를 base64 해시로 기록하여 거대한 MySQL 테이블(email_stats)을 생성한다는 것입니다. 서비스 가입자에게 10만 개의 이메일을 보낸 후 이 테이블은 150GB의 파일 공간을 차지했고 MySQL은 간단한 쿼리에서 "바보"가 되기 시작했습니다. 파일 공간 문제를 해결하기 위해 InnoDB 테이블 압축을 성공적으로 사용하여 4배로 줄였습니다. 그러나 어떤 이유로 전체 스캔을 수행해야 하는 간단한 쿼리로 인해 스왑 및 과도한 I/O가 발생하기 때문에 단지 읽기 기록을 위해 MySQL에 20-30만 개 이상의 이메일을 저장하는 것은 여전히 ​​이치에 맞지 않습니다. 정기적으로 Zabbix 경고를 받았습니다.

Clickhouse는 두 가지 압축 알고리즘을 사용하여 데이터 양을 약 3-4 번, 하지만 이 특별한 경우에는 데이터가 특히 "압축 가능"했습니다.

엘케이 교체

내 경험에 따르면 ELK 스택(ElasticSearch, Logstash 및 Kibana, 이 경우에는 ElasticSearch)을 실행하려면 로그를 저장하는 데 필요한 것보다 훨씬 더 많은 리소스가 필요합니다. ElasticSearch는 우수한 전체 텍스트 로그 검색을 원하는 경우(그리고 실제로 필요하지 않다고 생각하는 경우) 훌륭한 엔진이지만 이것이 사실상의 표준 로깅 엔진이 된 이유가 궁금합니다. Logstash와 결합된 수집 성능으로 인해 상당히 가벼운 워크로드에서도 문제가 발생했으며 점점 더 많은 RAM과 디스크 공간을 추가해야 했습니다. 데이터베이스로서 Clickhouse는 다음과 같은 이유로 ElasticSearch보다 낫습니다.

• SQL 언어 지원;
• 저장된 데이터의 최상의 압축 정도
• 전체 텍스트 검색 대신 Regex 검색 지원
• 향상된 쿼리 스케줄링 및 전반적인 성능 향상.

현재 ClickHouse와 ELK를 비교할 때 발생하는 가장 큰 문제는 로그 업로드 솔루션이 부족하고 이 주제에 대한 문서 및 자습서가 부족하다는 것입니다. 동시에 각 사용자는 Digital Ocean 매뉴얼을 사용하여 ELK를 설정할 수 있으며 이는 이러한 기술의 신속한 구현에 매우 중요합니다. 여기에는 데이터베이스 엔진이 있지만 ClickHouse용 Filebeat는 아직 없습니다. 예, 있습니다 유창한 로그 작업을 위한 시스템 통나무 집, 도구가 있습니다 클릭 테일 ClickHouse에 로그 파일 데이터를 입력하려면 시간이 더 걸립니다. 그러나 ClickHouse는 단순성으로 인해 여전히 선두를 달리고 있으므로 초보자도 쉽게 설치하고 단 10분 만에 모든 기능을 사용할 수 있습니다.

미니멀한 솔루션을 선호하는 저는 Kafka 사용을 피하면서 ClickHouse와 함께 매우 낮은 메모리 로그 업로드 도구인 FluentBit을 사용하려고 했습니다. 그러나 다음과 같은 사소한 비호환성 문제를 해결해야 합니다. 날짜 형식 문제데이터를 FluentBit에서 ClickHouse로 변환하는 프록시 레이어 없이 수행할 수 있습니다.

Kibana 대신 ClickHouse를 백엔드로 사용할 수 있습니다. 그라 파나. 내가 이해하는 한, 이것은 특히 이전 버전의 Grafana에서 엄청난 수의 데이터 포인트를 렌더링할 때 성능 문제를 일으킬 수 있습니다. Qwintry에서는 아직 시도하지 않았지만 Telegram의 ClickHouse 지원 채널에 이에 대한 불만이 수시로 나타납니다.

Google Big Query 및 Amazon RedShift 대체(대기업용 솔루션)

BigQuery의 이상적인 사용 사례는 1TB의 JSON 데이터를 로드하고 이에 대한 분석 쿼리를 실행하는 것입니다. Big Query는 확장성을 과대평가하기 어려운 훌륭한 제품입니다. 이것은 내부 클러스터에서 실행되는 ClickHouse보다 훨씬 더 복잡한 소프트웨어이지만 고객의 관점에서 ClickHouse와 공통점이 많습니다. BigQuery는 각 SELECT에 대한 비용을 지불하기 시작하면 빠르게 "가격을 올릴" 수 있으므로 모든 장단점이 있는 진정한 SaaS 솔루션입니다.

ClickHouse는 계산 비용이 많이 드는 쿼리를 많이 실행할 때 최상의 선택입니다. 매일 실행하는 SELECT 쿼리가 많을수록 Big Query를 ClickHouse로 교체하는 것이 더 중요해집니다. 이러한 교체를 통해 처리 중인 테라바이트의 데이터에서 수천 달러를 절약할 수 있기 때문입니다. 이것은 Big Query에서 처리하기에 상당히 저렴한 저장된 데이터에는 적용되지 않습니다.

Altinity의 공동 설립자 Alexander Zaitsev의 기사에서 "클릭하우스로 이동" 이러한 DBMS 마이그레이션의 이점에 대해 설명합니다.

TimescaleDB 교체

TimescaleDB는 일반 데이터베이스에서 시계열 작업을 최적화하는 PostgreSQL 확장입니다(https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

ClickHouse는 시계열 틈새 시장에서 심각한 경쟁자는 아니지만 열 구조 및 벡터 쿼리 실행 측면에서 대부분의 분석 쿼리 처리에서 TimescaleDB보다 훨씬 빠릅니다. 동시에 ClickHouse 패킷 데이터를 수신하는 성능은 약 3배 더 높으며 디스크 공간을 20배 적게 사용하므로 대량의 기록 데이터를 처리하는 데 매우 중요합니다. 
https://www.altinity.com/blog/ClickHouse-for-time-series.

ClickHouse와 달리 TimescaleDB에서 일부 디스크 공간을 절약하는 유일한 방법은 ZFS 또는 유사한 파일 시스템을 사용하는 것입니다.

ClickHouse에 대한 향후 업데이트는 델타 압축을 도입하여 시계열 데이터를 처리하고 저장하는 데 훨씬 더 적합할 것입니다. TimescaleDB는 다음과 같은 경우 베어 ClickHouse보다 나은 선택일 수 있습니다.

• 매우 작은 RAM(<3GB)을 사용하는 소규모 설치
• 큰 조각으로 버퍼링하지 않으려는 많은 수의 작은 INSERT
• 더 나은 일관성, 균일성 및 ACID 요구 사항;
• PostGIS 지원;
• Timescale DB는 본질적으로 PostgreSQL이므로 기존 PostgreSQL 테이블과 병합합니다.

Hadoop 및 MapReduce 시스템과의 경쟁

Hadoop 및 기타 MapReduce 제품은 많은 복잡한 계산을 수행할 수 있지만 대기 시간이 매우 긴 경향이 있습니다. ClickHouse는 테라바이트의 데이터를 처리하고 거의 즉시 결과를 생성하여 이 문제를 해결합니다. 따라서 ClickHouse는 데이터 과학자가 관심을 가져야 하는 빠른 대화형 분석 연구를 수행하는 데 훨씬 더 효율적입니다.

Pinot 및 Druid와의 경쟁

ClickHouse의 가장 가까운 경쟁자는 선형 확장 가능한 오픈 소스 제품인 Pinot 및 Druid입니다. 이 시스템을 비교하는 훌륭한 작업이 기사에 게시되어 있습니다. 로마나 레벤토바 1 2 월 2018

이 기사는 업데이트가 필요합니다. ClickHouse는 UPDATE 및 DELETE 작업을 지원하지 않는다고 합니다. 이는 최신 버전과 관련하여 전적으로 사실이 아닙니다.

우리는 이러한 DBMS에 대한 경험이 많지 않지만 Druid 및 Pinot를 실행하는 데 필요한 기본 인프라의 복잡성이 마음에 들지 않습니다. 모든 측면에서 Java로 둘러싸인 "움직이는 부분" 전체입니다.

Druid와 Pinot는 Apache 인큐베이터 프로젝트로, Apache가 GitHub 프로젝트 페이지에서 자세히 다룹니다. Pinot은 2018년 8월 인큐베이터에 나타났고 Druid는 XNUMX개월 전인 XNUMX월에 태어났습니다.

AFS가 어떻게 작동하는지에 대한 정보의 부족은 나에게 몇 가지, 아마도 어리석은 질문을 제기합니다. Pinot의 저자는 Apache Foundation이 Druid에 대해 더 많은 성향을 가지고 있으며 경쟁자에 대한 그러한 태도가 부러움을 불러 일으켰는지 궁금합니다. 전자를 지원하는 스폰서가 갑자기 후자에 관심을 갖게 되면 Druid의 개발 속도가 느려지고 Pinot의 개발 속도가 빨라질까요?

클릭하우스의 단점

미성숙: 분명히 아직은 지루한 기술이지만, 어쨌든 다른 컬럼형 DBMS에서는 이런 것을 볼 수 없습니다.

작은 삽입은 고속에서 잘 수행되지 않습니다. 작은 삽입의 성능은 각 행의 열 수에 비례하여 저하되기 때문에 삽입은 큰 청크로 분할되어야 합니다. 이것은 ClickHouse가 디스크에 데이터를 저장하는 방법입니다. 각 열은 1개 이상의 파일을 의미하므로 1개의 열이 포함된 100개의 행을 삽입하려면 최소 100개의 파일을 열고 써야 합니다. 이것이 삽입 버퍼링에 중개자가 필요한 이유입니다(클라이언트 자체가 버퍼링을 제공하지 않는 한). 일반적으로 Kafka 또는 일종의 큐잉 시스템입니다. 또한 Buffer 테이블 엔진을 사용하여 나중에 MergeTree 테이블에 대량의 데이터를 복사할 수 있습니다.

테이블 조인은 서버 RAM에 의해 제한되지만 최소한 존재합니다! 예를 들어, Druid와 Pinot는 노드 간에 많은 양의 데이터 이동을 지원하지 않는 분산 시스템에서 직접 구현하기 어렵기 때문에 이러한 연결이 전혀 없습니다.

조사 결과

앞으로 우리는 Qwintry에서 ClickHouse를 광범위하게 사용할 계획입니다. 이 DBMS는 성능, 낮은 오버헤드, 확장성 및 단순성의 뛰어난 균형을 제공하기 때문입니다. ClickHouse 커뮤니티가 중소형 설치에서 사용할 수 있는 더 많은 방법을 제시하면 빠르게 확산될 것이라고 확신합니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com