ClickHouse를 효과적으로 활용해보세요. 알렉세이 밀로비도프(Yandex)

ClickHouse는 특수 시스템이므로 사용 시 아키텍처의 특징을 고려하는 것이 중요합니다. 이 보고서에서 Alexey는 ClickHouse를 사용할 때 비효율적인 작업으로 이어질 수 있는 일반적인 실수의 예에 대해 설명합니다. 실제 사례에서는 하나 또는 다른 데이터 처리 방식을 선택하면 성능이 몇 배나 달라질 수 있는지 보여줍니다.

안녕하세요 여러분! 제 이름은 Alexey이고 ClickHouse를 만들고 있습니다.

먼저, 서둘러 여러분을 기쁘게 해드리고 싶습니다. 오늘은 ClickHouse가 무엇인지 말씀드리지 않겠습니다. 솔직히 말하면 지쳤어요. 매번 나는 그것이 무엇인지 말해 줍니다. 그리고 아마 다들 이미 알고 있을 겁니다.

대신 발생할 수 있는 실수, 즉 ClickHouse를 잘못 사용할 수 있는 방법을 알려 드리겠습니다. 사실 우리는 ClickHouse를 간단하고 편리하며 즉시 사용할 수 있는 시스템으로 개발하고 있기 때문에 두려워할 필요가 없습니다. 설치했는데 문제없네요.

하지만 이 시스템이 전문화되어 있고 이 시스템을 익숙한 영역에서 벗어나게 하는 특이한 사용 사례를 쉽게 발견할 수 있다는 점을 고려해야 합니다.

그렇다면 어떤 종류의 갈퀴가 있습니까? 대부분은 분명한 것에 대해 이야기하겠습니다. 모든 것이 모든 사람에게 분명하고 모든 사람이 모든 것을 이해하고 자신이 너무 똑똑하다는 사실에 기뻐할 수 있으며 이해하지 못하는 사람은 새로운 것을 배울 것입니다.

불행하게도 자주 발생하는 첫 번째이자 가장 간단한 예는 작은 배치가 포함된 다수의 삽입물, 즉 다수의 작은 삽입물입니다.

ClickHouse가 삽입을 수행하는 방법을 고려하면 한 번의 요청으로 최소 테라바이트의 데이터를 보낼 수 있습니다. 문제가 되지 않습니다.

그리고 일반적인 성능이 무엇인지 살펴보겠습니다. 예를 들어 Yandex.Metrica 데이터의 테이블이 있습니다. 조회수. 105개 열. 압축되지 않은 경우 700바이트입니다. 그리고 우리는 백만 개의 행을 일괄적으로 삽입할 것입니다.

MergeTree를 테이블에 삽입하면 초당 400만 행이 생성됩니다. 엄청난. 복제된 테이블에서는 초당 약 000행으로 조금 더 작습니다.

그리고 쿼럼 삽입을 활성화하면 약간 적지만 여전히 괜찮은 성능(초당 250항)을 얻을 수 있습니다. 쿼럼 삽입은 ClickHouse*에서 문서화되지 않은 기능입니다.

* 2020년 기준, 이미 문서화됨.

나쁜 짓을 하면 어떻게 되나요? MergeTree 테이블에 하나의 행을 삽입하고 초당 59개의 행을 얻습니다. 10배 더 느립니다. ReplicatedMergeTree에서 – 초당 000행. 그리고 쿼럼이 켜져 있으면 초당 6줄이 나옵니다. 제 생각에는 이것은 일종의 절대적인 쓰레기입니다. 어떻게 그렇게 속도를 늦출 수 있나요? ClickHouse가 속도를 늦추면 안 된다는 내용을 티셔츠에 써 놓기도 했습니다. 그러나 그럼에도 불구하고 가끔 그런 일이 발생합니다.

사실 이게 우리의 단점이다. 우리는 모든 것이 잘 작동하도록 쉽게 만들 수 있었지만 그렇지 않았습니다. 그리고 우리 스크립트에서 요구하지 않았기 때문에 그렇게 하지 않았습니다. 우리에겐 이미 부치가 있었습니다. 방금 입구에서 일괄 배송을 받았는데 문제가 없었습니다. 그것을 삽입하면 모든 것이 잘 작동합니다. 그러나 물론 모든 종류의 시나리오가 가능합니다. 예를 들어, 데이터가 생성되는 여러 서버가 있는 경우입니다. 그리고 데이터를 자주 삽입하지는 않지만 여전히 자주 삽입하게 됩니다. 그리고 우리는 어떻게든 이것을 피해야 합니다.

기술적인 관점에서 볼 때 중요한 점은 ClickHouse에서 삽입을 수행할 때 데이터가 어떤 메모리 테이블에도 남지 않는다는 것입니다. 실제 로그 구조인 MergeTree도 없고 MergeTree만 있습니다. 로그도 memTable도 없기 때문입니다. 우리는 이미 열로 배열된 파일 시스템에 데이터를 즉시 기록합니다. 그리고 100개의 열이 있는 경우 200개가 넘는 파일을 별도의 디렉터리에 작성해야 합니다. 이 모든 것이 매우 번거롭습니다.

그리고 "올바른 방법은 무엇입니까?"라는 질문이 생깁니다. 상황이 여전히 ClickHouse에 데이터를 기록해야 하는 경우입니다.

방법 1. 이것이 가장 쉬운 방법입니다. 일종의 분산 대기열을 사용하십시오. 예를 들어 카프카. Kafka에서 데이터를 추출하고 XNUMX초에 한 번씩 일괄 처리하면 됩니다. 그리고 모든 것이 잘 될 것입니다. 녹음하면 모든 것이 잘 작동합니다.

단점은 Kafka가 또 다른 부피가 큰 분산 시스템이라는 것입니다. 회사에 이미 Kafka가 있는지도 이해합니다. 좋아요, 편리해요. 하지만 존재하지 않는다면 또 다른 분산 시스템을 프로젝트에 끌어들이기 전에 세 번 생각해야 합니다. 따라서 대안을 고려해 볼 가치가 있습니다.

방법 2. 이것은 구식 대안이면서 동시에 매우 간단합니다. 로그를 생성하는 일종의 서버가 있습니까? 그리고 로그를 파일에 기록합니다. 예를 들어 XNUMX초에 한 번씩 이 파일의 이름을 바꾸고 새 파일을 떼어냅니다. 그리고 cron이나 일부 데몬을 통해 별도의 스크립트가 가장 오래된 파일을 가져와 ClickHouse에 씁니다. XNUMX초에 한 번씩 로그를 기록하면 모든 것이 괜찮을 것입니다.

하지만 이 방법의 단점은 로그가 생성된 서버가 어딘가에서 사라지면 데이터도 사라진다는 것입니다.

방법 3. 임시 파일이 전혀 필요하지 않은 또 다른 흥미로운 방법이 있습니다. 예를 들어, 일종의 광고 스피너나 데이터를 생성하는 다른 흥미로운 데몬이 있습니다. 그리고 RAM, 버퍼에 직접 많은 데이터를 축적할 수 있습니다. 그리고 충분한 시간이 지나면 이 버퍼를 한쪽으로 치워두고 새 버퍼를 만든 다음 별도의 스레드에서 이미 축적된 것을 ClickHouse에 삽입합니다.

반면, kill -9를 사용하면 데이터도 사라집니다. 서버가 충돌하면 이 데이터가 손실됩니다. 또 다른 문제는 데이터베이스에 쓸 수 없으면 데이터가 RAM에 축적된다는 것입니다. RAM이 부족하거나 단순히 데이터가 손실됩니다.

방법 4. 또 다른 흥미로운 방법입니다. 어떤 종류의 서버 프로세스가 있습니까? 그리고 즉시 ClickHouse에 데이터를 보낼 수 있지만 한 번의 연결로 수행됩니다. 예를 들어, transfer-encoding: insert와 함께 청크된 http 요청을 보냈습니다. 그리고 청크를 생성하는 경우는 그리 드물지 않습니다. 각 라인을 보낼 수 있지만 이 데이터를 구성하는 데 오버헤드가 발생합니다.

다만, 이 경우 해당 데이터는 즉시 ClickHouse로 전송됩니다. ClickHouse는 이를 자체적으로 버퍼링합니다.

그러나 문제도 발생합니다. 이제 프로세스가 종료되거나 ClickHouse 프로세스가 종료되는 경우를 포함하여 데이터가 손실됩니다. 왜냐하면 불완전한 삽입이 되기 때문입니다. 그리고 ClickHouse에서 삽입은 행 크기의 지정된 특정 임계값까지 원자성입니다. 원칙적으로 이것은 흥미로운 방법입니다. 또한 사용할 수 있습니다.

방법 5. 또 다른 흥미로운 방법이 있습니다. 이것은 데이터 일괄 처리를 위해 커뮤니티에서 개발한 일종의 서버입니다. 제가 직접 살펴보지 않아서 어떤 것도 보장할 수 없습니다. 그러나 ClickHouse 자체에 대해서는 어떠한 보증도 제공되지 않습니다. 이것도 오픈 소스이지만, 반면에 우리가 제공하려고 하는 일부 품질 표준에 익숙할 수도 있습니다. 하지만 이것에 대해서는 잘 모르겠습니다. GitHub로 가서 코드를 살펴보세요. 아마도 그들은 정상적인 것을 썼을 것입니다.

* 2020년 기준, 고려 사항에 추가되어야 함 새끼 고양이집.

방법 6. 또 다른 방법은 버퍼 테이블을 사용하는 것입니다. 이 방법의 장점은 사용을 시작하기가 매우 쉽다는 것입니다. 버퍼 테이블을 생성하고 삽입합니다.

단점은 문제가 완전히 해결되지 않는다는 것입니다. MergeTree와 같은 속도에서 초당 하나의 배치로 데이터를 그룹화해야 하는 경우 버퍼 테이블의 속도에서는 초당 최대 수천 개까지 그룹화해야 합니다. 초당 10개 이상이면 여전히 좋지 않습니다. 그리고 일괄적으로 삽입하면 초당 십만 줄이 되는 것을 볼 수 있습니다. 그리고 이것은 이미 상당히 많은 데이터에 있습니다.

또한 버퍼 테이블에는 로그가 없습니다. 그리고 서버에 문제가 있으면 데이터가 손실됩니다.

그리고 보너스로 최근 ClickHouse에서 Kafka에서 데이터를 검색할 수 있는 기회를 얻었습니다. 테이블 엔진인 Kafka가 있습니다. 당신은 단지 창조합니다. 그리고 여기에 구체화된 표현을 걸 수 있습니다. 이 경우 자체적으로 Kafka에서 데이터를 추출하여 필요한 테이블에 삽입합니다.

그리고 이 기회가 특히 기분 좋은 것은 그것을 우리가 한 것이 아니라는 점이다. 커뮤니티 기능입니다. 그리고 제가 "커뮤니티 기능"이라고 말할 때는 아무런 경멸 없이 의미하는 것입니다. 코드를 읽고 검토한 결과 제대로 작동할 것입니다.

* 2020년 현재 유사한 지원이 나타남 RabbitMQ.

데이터를 삽입할 때 불편하거나 예상치 못한 일이 또 있을까요? 값 삽입 요청을 하고 값에 계산된 표현식을 작성하는 경우. 예를 들어 now()도 계산된 표현식입니다. 그리고 이 경우 ClickHouse는 각 줄에서 이러한 표현식의 해석기를 실행해야 하며 성능은 몇 배나 떨어집니다. 이것을 피하는 것이 좋습니다.

* 현재 문제는 완전히 해결되었으며, VALUES에서 표현식을 사용할 때 더 이상 성능 저하가 발생하지 않습니다.

또 다른 예는 여러 파티션에 속하는 하나의 배치에 데이터가 있을 때 몇 가지 문제가 있을 수 있는 경우입니다. 기본적으로 ClickHouse 파티션은 월 단위입니다. 그리고 백만 행의 배치를 삽입하고 몇 년 동안의 데이터가 있는 경우 거기에 수십 개의 파티션이 있게 됩니다. 그리고 이는 내부에서 항상 먼저 파티션으로 나누어지기 때문에 크기가 수십 배 더 작은 배치가 있다는 사실과 동일합니다.

* 최근 실험 모드에서 ClickHouse는 미리 쓰기 로그를 사용하여 RAM의 청크 및 청크의 컴팩트 형식에 대한 지원을 추가하여 문제를 거의 완전히 해결했습니다.

이제 두 번째 유형의 문제인 데이터 입력을 살펴보겠습니다.

데이터 유형은 엄격하거나 문자열일 수 있습니다. String은 방금 가져오고 모든 필드가 문자열 유형이라고 선언한 경우입니다. 이건 짜증나. 이렇게 할 필요는 없습니다.

필드와 문자열이 있다고 말하고 ClickHouse가 스스로 알아내도록 하려는 경우에 이를 올바르게 수행하는 방법을 알아봅시다. 저는 귀찮게 하지 않겠습니다. 그러나 여전히 노력할 가치가 있습니다.

예를 들어 IP 주소가 있습니다. 어떤 경우에는 이를 문자열로 저장했습니다. 예를 들어 192.168.1.1입니다. 또 다른 경우에는 UInt32* 유형의 숫자가 됩니다. IPv32 주소에는 4비트이면 충분합니다.

첫째, 이상하게도 데이터는 거의 동일하게 압축됩니다. 물론 차이가 있겠지만 그렇게 크지는 않습니다. 따라서 디스크 I/O에는 특별한 문제가 없습니다.

그러나 프로세서 시간과 쿼리 실행 시간에는 심각한 차이가 있습니다.

고유한 IP 주소를 숫자로 저장하면 그 개수를 세어 보겠습니다. 이는 초당 137억 37만 줄에 해당합니다. 동일한 내용이 문자열 형태라면 초당 4만 줄이 됩니다. 왜 이런 우연이 일어났는지 모르겠습니다. 나는 이러한 요청을 직접 수행했습니다. 하지만 여전히 약 XNUMX배 더 느립니다.

그리고 디스크 공간의 차이를 계산하면 차이도 있습니다. 그리고 그 차이는 약 XNUMX/XNUMX 정도인데, 고유한 IP 주소가 꽤 많기 때문입니다. 그리고 소수의 서로 다른 의미를 가진 줄이 있다면 사전에 따라 거의 같은 볼륨으로 쉽게 압축될 것입니다.

그리고 XNUMX배의 시차는 도로에 있지 않습니다. 물론 별 신경 안 쓰실 수도 있겠지만 그런 차이를 보면 안타깝습니다.

다양한 사례를 살펴보겠습니다.

1. 서로 다른 고유 값이 거의 없는 경우입니다. 이 경우에는 여러분이 알고 있고 모든 DBMS에 사용할 수 있는 간단한 방법을 사용합니다. 이 모든 것이 ClickHouse에만 해당되는 것은 아닙니다. 숫자 식별자를 데이터베이스에 기록하기만 하면 됩니다. 그리고 애플리케이션 측면에서 문자열로 변환하거나 다시 변환할 수 있습니다.

예를 들어 지역이 있습니다. 그리고 이를 문자열로 저장하려고 합니다. 그리고 거기에는 모스크바와 모스크바 지역이 기록될 것입니다. 그리고 '모스크바'라고 적힌 걸 보면 별거 아닌데, 모스크바라면 어쩐지 완전 슬프다. 이것은 몇 바이트입니다.

대신 단순히 Ulnt32와 250이라는 숫자를 적습니다. Yandex에는 250이 있지만 귀하의 숫자는 다를 수 있습니다. 만일을 대비해 ClickHouse에는 지리 기반 작업 기능이 내장되어 있다고 말씀드리겠습니다. 계층적 디렉터리를 포함하여 지역이 포함된 디렉터리를 작성하기만 하면 됩니다. 즉, 모스크바, 모스크바 지역 및 필요한 모든 것이 있을 것입니다. 그리고 요청 수준에서 변환할 수 있습니다.

두 번째 옵션은 거의 동일하지만 ClickHouse 내부에서 지원됩니다. 이것은 Enum 데이터 유형입니다. Enum 내부에 필요한 모든 값을 작성하면 됩니다. 예를 들어 장치 유형을 입력하고 데스크톱, 모바일, 태블릿, TV 등으로 기록합니다. 총 4가지 옵션이 있습니다.

단점은 주기적으로 바꿔줘야 한다는 것. 옵션이 하나만 추가되었습니다. 테이블을 변경해 봅시다. 실제로 ClickHouse의 변경 테이블은 무료입니다. 디스크의 데이터는 변경되지 않으므로 Enum의 경우 특히 무료입니다. 그럼에도 불구하고 alter는 테이블에 대한 잠금*을 획득하고 모든 선택이 실행될 때까지 기다려야 합니다. 그리고 이것이 변경된 후에야 실행됩니다. 즉, 여전히 몇 가지 불편함이 있습니다.

* 최신 버전의 ClickHouse에서는 ALTER가 완전히 비차단으로 만들어졌습니다.

ClickHouse의 또 다른 독특한 옵션은 외부 사전을 연결하는 것입니다. ClickHouse에 숫자를 기록하고 어떤 시스템에나 편리하게 디렉토리를 보관할 수 있습니다. 예를 들어 MySQL, Mongo, Postgres를 사용할 수 있습니다. http를 통해 이 데이터를 전송하는 자체 마이크로서비스를 만들 수도 있습니다. ClickHouse 수준에서는 이 데이터를 숫자에서 문자열로 변환하는 함수를 작성합니다.

이는 외부 테이블에서 조인을 수행하는 전문적이면서도 매우 효율적인 방법입니다. 그리고 두 가지 옵션이 있습니다. 일 실시예에서, 이 데이터는 완전히 캐시되고 RAM에 완전히 존재하며 일정 빈도로 업데이트됩니다. 또 다른 옵션으로, 이 데이터가 RAM에 맞지 않으면 부분적으로 캐시할 수 있습니다.

여기에 예가 있습니다. Yandex.Direct가 있습니다. 그리고 광고 회사와 배너가 있습니다. 아마도 수천만 개의 광고 회사가 있을 것입니다. 그리고 그들은 대략 RAM에 맞습니다. 그리고 수십억 개의 배너가 있는데 맞지 않습니다. 그리고 우리는 MySQL의 캐시된 사전을 사용합니다.

유일한 문제는 적중률이 100%에 가까우면 캐시된 사전이 제대로 작동한다는 것입니다. 크기가 더 작다면 각 데이터 배치에 대한 쿼리를 처리할 때 실제로 누락된 키를 가져와서 MySQL에서 데이터를 가져와야 합니다. ClickHouse에 대해서는 여전히 보장할 수 있습니다. 예, 속도가 느려지지 않으며 다른 시스템에 대해서는 이야기하지 않겠습니다.

그리고 보너스로 사전은 ClickHouse에서 데이터를 소급하여 업데이트하는 매우 쉬운 방법입니다. 즉, 광고 회사에 대한 보고서가 있었는데 사용자가 단순히 광고 회사를 변경했고 모든 이전 데이터, 모든 보고서에서 이 데이터도 변경되었습니다. 테이블에 행을 직접 쓰면 업데이트할 수 없습니다.

문자열의 식별자를 어디서 얻을 수 있는지 모르는 경우의 또 다른 방법입니다. 간단히 해시할 수 있습니다. 게다가 가장 간단한 옵션은 64비트 해시를 사용하는 것입니다.

유일한 문제는 해시가 64비트인 경우 거의 확실하게 충돌이 발생한다는 것입니다. 왜냐하면 거기에 XNUMX억 개의 라인이 있다면 그 확률은 이미 눈에 띄게 되기 때문입니다.

그리고 이런 식으로 광고 회사의 이름을 해싱하는 것은 그리 좋지 않을 것입니다. 여러 회사의 광고 캠페인이 뒤섞여 있으면 이해할 수 없는 일이 생길 것입니다.

그리고 간단한 트릭이 있습니다. 사실, 심각한 데이터에는 적합하지 않지만, 심각하지 않은 경우 클라이언트 식별자를 사전 키에 추가하면 됩니다. 그런 다음 충돌이 발생하지만 하나의 클라이언트 내에서만 발생합니다. 그리고 우리는 Yandex.Metrica의 링크 맵에 이 방법을 사용합니다. 거기에 URL이 있고 해시를 저장합니다. 그리고 우리는 물론 충돌이 있다는 것을 알고 있습니다. 그러나 페이지가 표시될 때 한 사용자의 한 페이지에 일부 URL이 서로 붙어 있어 이를 발견할 가능성은 무시할 수 있습니다.

보너스로 많은 작업에서는 해시만으로 충분하며 문자열 자체를 어디에도 저장할 필요가 없습니다.

또 다른 예는 웹 사이트 도메인과 같이 문자열이 짧은 경우입니다. 그대로 저장할 수 있습니다. 또는 예를 들어 브라우저 언어 ru – 2바이트입니다. 물론 바이트가 너무 아쉽지만 2바이트도 아쉽지 않으니 걱정하지 마세요. 걱정하지 말고 그대로 유지해주세요.

또 다른 경우는 반대로 라인이 많고 그 안에 고유한 라인이 많고 세트도 잠재적으로 무제한인 경우입니다. 일반적인 예로는 검색 문구나 URL이 있습니다. 오타를 포함한 검색어. 하루에 고유한 검색 문구가 몇 개나 있는지 살펴보겠습니다. 그리고 그것은 모든 사건의 거의 절반이라는 것이 밝혀졌습니다. 그리고 이런 경우에는 데이터를 정규화하고 식별자를 세어 별도의 테이블에 넣어야 한다고 생각할 수도 있습니다. 하지만 그렇게 할 필요는 없습니다. 이 줄을 그대로 유지하세요.

별도로 저장하는 경우 조인을 수행해야 하므로 아무것도 만들지 않는 것이 좋습니다. 그리고 이 조인은 여전히 ​​메모리에 적합하다면 기껏해야 메모리에 대한 무작위 액세스입니다. 맞지 않으면 문제가 발생합니다.

그리고 데이터가 제자리에 저장되어 있으면 파일 시스템에서 필요한 순서대로 읽기만 하면 모든 것이 정상입니다.

URL이나 기타 복잡한 긴 문자열이 있는 경우 일종의 추출을 미리 계산하여 별도의 열에 쓸 수 있다는 점을 고려해 볼 가치가 있습니다.

예를 들어 URL의 경우 도메인을 별도로 저장할 수 있습니다. 도메인이 꼭 필요한 경우 이 열을 사용하면 URL이 거기에 있으므로 건드릴 필요도 없습니다.

차이점이 무엇인지 살펴보겠습니다. ClickHouse에는 도메인을 계산하는 특화된 기능이 있습니다. 매우 빠르므로 최적화했습니다. 그리고 솔직히 말해서 RFC를 준수하지도 않지만 그럼에도 불구하고 우리에게 필요한 모든 것을 고려합니다.

그리고 어떤 경우에는 단순히 URL을 얻고 도메인을 계산할 것입니다. 이는 166밀리초로 계산됩니다. 그리고 기성 도메인을 사용하면 67밀리초에 불과합니다. 즉, 거의 XNUMX배 더 빠릅니다. 계산을 해야 하기 때문이 아니라 읽는 데이터가 적기 때문에 더 빠릅니다.

이것이 바로 느린 요청 하나가 초당 기가바이트라는 더 빠른 속도를 갖는 이유입니다. 더 많은 기가바이트를 읽기 때문입니다. 전혀 불필요한 데이터입니다. 요청이 더 빨리 실행되는 것 같지만 완료하는 데 시간이 더 오래 걸립니다.

그리고 디스크에 있는 데이터의 양을 보면 URL은 126MB이고, 도메인은 5MB에 불과한 것으로 드러납니다. 25 배 더 적은 것으로 나타났습니다. 그러나 그럼에도 불구하고 요청은 4배 더 빠르게 실행됩니다. 하지만 그건 데이터가 뜨겁기 때문이에요. 그리고 추운 날씨라면 디스크 I/O로 인해 아마도 25배 더 빨라졌을 것입니다.

그런데 도메인이 URL에 비해 얼마나 작은지 추정해 보면 약 4배 정도 작은 것으로 나오지만 어떤 이유에서인지 디스크에서 데이터는 25배나 적게 차지합니다. 왜? 압축으로 인해. 그리고 URL이 압축되고, 도메인도 압축됩니다. 그러나 종종 URL에 쓰레기가 많이 포함되어 있습니다.

그리고 물론, 원하는 값에 맞게 특별히 설계되었거나 적합한 올바른 데이터 유형을 사용하는 것이 좋습니다. IPv4를 사용하는 경우 UInt32*를 저장하십시오. IPv6인 경우 IPv16 주소가 6비트이므로 이진 형식으로 직접 저장되므로 FixString(128)입니다.

하지만 IPv4 주소가 있는 경우도 있고 IPv6 주소가 있는 경우도 있다면 어떻게 될까요? 예, 둘 다 저장할 수 있습니다. 한 열은 IPv4용이고 다른 열은 IPv6용입니다. 물론 IPv4에 IPv6를 표시하는 옵션도 있습니다. 이 방법도 작동하지만 요청에 IPv4 주소가 자주 필요한 경우 별도의 열에 입력하는 것이 좋습니다.

* ClickHouse에는 이제 데이터를 숫자만큼 효율적으로 저장하고 문자열처럼 편리하게 표시하는 별도의 IPv4, IPv6 데이터 유형이 있습니다.

데이터를 미리 전처리하는 것이 가치가 있다는 점에 유의하는 것도 중요합니다. 예를 들어 일부 원시 로그를 받습니다. 아무 것도 하지 않고 모든 것이 작동할 수 있지만, 즉시 ClickHouse에 넣으면 안 됩니다. 그러나 가능한 계산을 수행하는 것은 여전히 ​​가치가 있습니다.

예를 들어 브라우저 버전입니다. 손가락질하고 싶지 않은 가까운 일부 부서에서는 브라우저 버전이 다음과 같이 문자열로 저장됩니다. 12.3. 그런 다음 보고서를 작성하기 위해 이 문자열을 배열로 나눈 다음 배열의 첫 번째 요소로 나눕니다. 당연히 모든 것이 느려집니다. 나는 그들이 왜 이런 짓을 하는지 물었다. 그들은 성급한 최적화를 좋아하지 않는다고 말했습니다. 그리고 나는 성급한 비관을 좋아하지 않습니다.

따라서 이 경우에는 4열로 나누는 것이 더 정확할 것입니다. 여기는 ClickHouse이니까 두려워하지 마세요. ClickHouse는 열 기반 데이터베이스입니다. 그리고 작은 기둥이 깔끔할수록 좋습니다. 5개의 BrowserVersion이 있으며 5개의 열을 만듭니다. 이건 괜찮아.

이제 매우 긴 문자열, 매우 긴 배열이 많은 경우 어떻게 해야 하는지 살펴보겠습니다. ClickHouse에 전혀 저장할 필요가 없습니다. 대신 ClickHouse에만 식별자를 저장할 수 있습니다. 그리고 이 긴 줄을 다른 시스템에 넣으세요.

예를 들어, 당사의 분석 서비스 중 하나에는 몇 가지 이벤트 매개변수가 있습니다. 그리고 이벤트에 대한 매개변수가 많으면 처음으로 접하는 512개만 저장하면 됩니다. 512개는 아쉽지 않으니까요.

데이터 유형을 결정할 수 없는 경우 ClickHouse에 데이터를 기록할 수도 있지만 임시 데이터를 위한 특수 로그 유형의 임시 테이블에 기록할 수도 있습니다. 그런 다음 거기에 어떤 값이 분포되어 있는지, 일반적으로 무엇이 있는지 분석하고 올바른 유형을 만들 수 있습니다.

*ClickHouse에는 이제 데이터 유형이 있습니다. 낮은 카디널리티 이를 통해 적은 노력으로 효율적으로 문자열을 저장할 수 있습니다.

이제 또 다른 흥미로운 사례를 살펴보겠습니다. 때때로 사람들에게는 상황이 이상하게 작동합니다. 들어와서 이거 보는데 그리고 이 작업은 MySQL 버전 3.23 설정에 대한 광범위한 경험을 가진 경험이 풍부하고 똑똑한 관리자가 수행한 것으로 즉시 보입니다.

여기에서 우리는 천 개의 테이블을 볼 수 있으며, 각 테이블은 누가 무엇을 천으로 나눈 나머지를 기록합니다.

원칙적으로 나는 이 경험을 통해 얻을 수 있는 고통에 대한 이해를 포함하여 다른 사람의 경험을 존중합니다.

그리고 그 이유는 다소 명확합니다. 이는 다른 시스템과 작업하면서 축적되었을 수 있는 오래된 고정관념입니다. 예를 들어 MyISAM 테이블에는 클러스터된 기본 키가 없습니다. 그리고 이러한 데이터 분할 방식은 동일한 기능을 얻으려는 필사적인 시도일 수도 있습니다.

또 다른 이유는 큰 테이블에서는 변경 작업을 수행하기 어렵다는 것입니다. 모든 것이 차단됩니다. 최신 버전의 MySQL에서는 이 문제가 더 이상 심각하지 않습니다.

또는 마이크로 샤딩을 예로 들 수 있지만 이에 대해서는 나중에 자세히 설명합니다.

ClickHouse에서는 이 작업을 수행할 필요가 없습니다. 왜냐하면 먼저 기본 키가 클러스터링되어 있고 데이터가 기본 키에 따라 정렬되기 때문입니다.

그리고 때때로 사람들은 "ClickHouse의 범위 쿼리 성능은 테이블 크기에 따라 어떻게 달라지나요?"라고 묻습니다. 전혀 변하지 않는다고 합니다. 예를 들어, XNUMX억 개의 행이 있는 테이블이 있고 백만 행의 범위를 읽습니다. 모든 것이 괜찮습니다. 테이블에 XNUMX조 개의 행이 있고 백만 개의 행을 읽는 경우 거의 동일합니다.

둘째, 수동 파티션과 같은 모든 종류의 작업이 필요하지 않습니다. 들어가서 파일 시스템에 무엇이 있는지 살펴보면 테이블이 꽤 크다는 것을 알 수 있습니다. 그리고 내부에는 파티션 같은 것이 있습니다. 즉, ClickHouse가 귀하를 위해 모든 작업을 수행하므로 귀하는 어려움을 겪을 필요가 없습니다.

열 추가/삭제를 변경하는 경우 ClickHouse의 변경은 무료입니다.

그리고 작은 테이블을 만들어서는 안 됩니다. 테이블에 행이 10개든 행이 10개든 전혀 상관이 없기 때문입니다. ClickHouse는 지연 시간이 아닌 처리량을 최적화하는 시스템이므로 000라인을 처리하는 것은 의미가 없습니다.

큰 테이블 하나를 사용하는 것이 맞습니다. 오래된 고정관념을 없애면 모든 것이 잘 될 것입니다.

그리고 보너스로 최신 버전에서는 이제 개별 파티션에 대해 모든 종류의 유지 관리 작업을 수행하기 위해 임의의 파티션 키를 생성할 수 있는 기능이 있습니다.

예를 들어, 작은 테이블이 많이 필요한 경우, 예를 들어 일부 중간 데이터를 처리해야 하는 경우 청크를 수신하고 최종 테이블에 쓰기 전에 해당 청크에 대한 변환을 수행해야 합니다. 이 경우에는 훌륭한 테이블 엔진인 StripeLog가 있습니다. TinyLog와 비슷하지만 더 좋습니다.

* 이제 ClickHouse에도 테이블 함수 입력.

또 다른 안티패턴은 마이크로샤딩입니다. 예를 들어, 데이터를 샤딩해야 하고 5개의 서버가 있고 내일은 6개의 서버가 있을 것입니다. 그리고 이 데이터의 균형을 재조정하는 방법에 대해 생각합니다. 대신 5개의 샤드로 분할되지 않고 1개의 샤드로 분할됩니다. 그런 다음 각 마이크로샤드를 별도의 서버에 매핑합니다. 예를 들어, 한 서버에 000개의 ClickHouse를 얻을 수 있습니다. 별도의 포트 또는 별도의 데이터베이스에 인스턴스를 분리합니다.

하지만 ClickHouse에서는 이것이 별로 좋지 않습니다. 하나의 ClickHouse 인스턴스라도 하나의 요청을 처리하기 위해 사용 가능한 모든 서버 리소스를 사용하려고 하기 때문입니다. 즉, 일종의 서버가 있고 예를 들어 56개의 프로세서 코어가 있습니다. 56초가 걸리는 쿼리를 실행 중이며 200개의 코어를 사용합니다. 그리고 한 서버에 10개의 ClickHouse를 배치하면 000개의 스레드가 시작되는 것으로 나타났습니다. 일반적으로 모든 것이 매우 나쁠 것입니다.

또 다른 이유는 이러한 인스턴스 전반에 걸쳐 작업 분포가 고르지 않기 때문입니다. 일부는 더 일찍 완료되고 일부는 나중에 완료됩니다. 이 모든 것이 한 인스턴스에서 발생한 경우 ClickHouse는 스레드 간에 데이터를 올바르게 배포하는 방법을 자체적으로 파악합니다.

또 다른 이유는 TCP를 통해 프로세서 간 통신이 가능하다는 것입니다. 데이터는 직렬화 및 역직렬화되어야 하며 이는 엄청난 수의 마이크로샤드입니다. 그것은 단순히 효과적으로 작동하지 않을 것입니다.

또 다른 안티패턴이지만 안티패턴이라고 부르기는 어렵습니다. 이는 사전 집계된 양이 많습니다.

일반적으로 사전 집계가 좋습니다. 1억 개의 행이 있었고 이를 집계하여 000개의 행이 되었으며 이제 쿼리가 즉시 실행됩니다. 모든것이 좋아. 당신은 이것을 할 수 있습니다. 이를 위해 ClickHouse에도 데이터가 삽입될 때 증분 집계를 수행하는 AggregatingMergeTree라는 특수 테이블 유형이 있습니다.

그런데 우리가 이렇게 데이터를 집계하고, 이렇게 데이터를 집계하겠다라고 생각할 때가 있습니다. 그리고 인근 일부 부서에서는 어느 부서인지 말하고 싶지 않습니다. SummingMergeTree 테이블을 사용하여 기본 키로 요약하고 약 20개의 열이 기본 키로 사용됩니다. 만일을 대비해 비밀 유지를 위해 일부 열의 이름을 변경했지만 그게 전부입니다.

그리고 이런 문제가 발생합니다. 첫째, 데이터 볼륨이 너무 많이 줄어들지 않습니다. 예를 들어, XNUMX배로 감소합니다. 데이터가 집계되지 않은 경우 발생하는 무제한 분석 기능을 감당할 수 있는 좋은 가격은 세 번입니다. 데이터가 집계되면 분석 대신 불쌍한 통계만 얻게 됩니다.

그리고 무엇이 그렇게 특별한가요? 사실은 이웃 부서의 사람들이 가끔 가서 기본 키에 다른 열을 추가해 달라고 요청하는 것입니다. 즉, 이렇게 데이터를 집계했는데 이제는 좀 더 많은 것을 원합니다. 그러나 ClickHouse에는 대체 기본 키가 없습니다. 따라서 우리는 C++로 일부 스크립트를 작성해야 합니다. 그리고 저는 C++로 작성된 스크립트를 좋아하지 않습니다.

그리고 ClickHouse가 만들어진 이유를 살펴보면 집계되지 않은 데이터가 바로 이것이 탄생한 시나리오입니다. 집계되지 않은 데이터에 ClickHouse를 사용하고 있다면 올바르게 수행하고 있는 것입니다. 집계하면 때로는 용서받을 수 있습니다.

또 다른 흥미로운 사례는 무한 루프의 쿼리입니다. 가끔 프로덕션 서버에 가서 거기에 있는 프로세스 목록 표시를 살펴봅니다. 그리고 뭔가 끔찍한 일이 일어나고 있다는 것을 발견할 때마다.

예를 들면 다음과 같습니다. 한 번의 요청으로 모든 것이 완료될 수 있다는 것이 즉시 분명해졌습니다. 거기에 URL과 목록을 적으면 됩니다.

무한 루프에서 이러한 쿼리가 많은 이유는 무엇입니까? 인덱스를 사용하지 않으면 동일한 데이터에 대해 여러 번 전달됩니다. 그러나 예를 들어 인덱스가 사용되는 경우 ru에 대한 기본 키가 있고 거기에 url = 무엇인가를 씁니다. 그리고 테이블에서 단 하나의 URL만 읽으면 모든 것이 괜찮을 것이라고 생각합니다. 하지만 실제로는 그렇지 않습니다. ClickHouse는 모든 작업을 일괄적으로 수행하기 때문입니다.

특정 범위의 데이터를 읽어야 할 경우 ClickHouse의 인덱스가 희박하기 때문에 조금 더 읽습니다. 이 인덱스를 사용하면 테이블에서 하나의 개별 행을 찾을 수 없으며 특정 범위만 찾을 수 있습니다. 그리고 데이터는 블록 단위로 압축됩니다. 한 줄을 읽으려면 전체 블록을 가져와서 풀어야 합니다. 그리고 많은 쿼리를 수행하는 경우 중복되는 부분이 많아지고 반복해서 수행해야 할 작업도 많아지게 됩니다.

보너스로 ClickHouse에서는 메가바이트, 심지어 수백 메가바이트까지 IN 섹션으로 전송하는 것을 두려워해서는 안 됩니다. 예를 들어 MySQL에서 IN 섹션에 여러 값을 전송하면 100MB의 일부 숫자를 전송하면 MySQL은 10GB의 메모리를 소비하고 아무 일도 일어나지 않는다는 연습을 기억합니다. 제대로 작동하지 않습니다.

두 번째는 ClickHouse에서 쿼리가 인덱스를 사용하는 경우 항상 전체 스캔보다 느리지 않습니다. 즉, 거의 전체 테이블을 읽어야 하는 경우 순차적으로 진행되어 전체 테이블을 읽습니다. 일반적으로 그는 스스로 알아낼 것입니다.

그러나 그럼에도 불구하고 몇 가지 어려움이 있습니다. 예를 들어, 하위 쿼리가 있는 IN은 인덱스를 사용하지 않는다는 사실입니다. 하지만 이것은 우리의 문제이고 우리는 그것을 고쳐야 합니다. 여기에는 근본적인 것이 없습니다. 고쳐드리겠습니다*.

그리고 또 다른 흥미로운 점은 매우 긴 요청이 있고 분산 요청 처리가 진행 중인 경우 이 매우 긴 요청이 압축되지 않고 각 서버로 전송된다는 것입니다. 예를 들어 100MB 및 500개의 서버입니다. 따라서 네트워크를 통해 50GB가 전송됩니다. 전송되면 모든 것이 성공적으로 완료됩니다.

* 이미 사용 중입니다. 약속대로 모든 것이 해결되었습니다.

그리고 매우 일반적인 경우는 요청이 API에서 오는 경우입니다. 예를 들어, 자신만의 서비스를 만들었습니다. 누군가 귀하의 서비스가 필요하면 API를 열고 말 그대로 이틀 후에 이해할 수 없는 일이 일어나고 있음을 알게 됩니다. 모든 것이 과부하 상태이고 결코 일어나지 말아야 할 끔찍한 요청이 들어오고 있습니다.

그리고 해결책은 하나뿐입니다. API를 열었다면 잘라내야 합니다. 예를 들어 일종의 할당량을 도입합니다. 다른 일반적인 옵션은 없습니다. 그렇지 않으면 즉시 스크립트를 작성하고 문제가 발생합니다.

그리고 ClickHouse에는 할당량 계산이라는 특별한 기능이 있습니다. 또한 할당량 키를 전송할 수도 있습니다. 예를 들어 내부 사용자 ID입니다. 그리고 할당량은 각각에 대해 독립적으로 계산됩니다.

이제 또 다른 흥미로운 점입니다. 수동 복제입니다.

저는 ClickHouse에 복제 지원 기능이 내장되어 있음에도 불구하고 사람들이 ClickHouse를 수동으로 복제하는 경우를 많이 알고 있습니다.

원리는 무엇입니까? 데이터 처리 파이프라인이 있습니다. 예를 들어 여러 데이터 센터에서 독립적으로 작동합니다. ClickHouse에서도 같은 방식으로 같은 데이터를 작성합니다. 사실, 실습을 통해 코드의 일부 기능으로 인해 데이터가 여전히 분기되는 것으로 나타났습니다. 나는 그것이 당신 안에 있기를 바랍니다.

그리고 때때로 수동으로 동기화해야 하는 경우도 있습니다. 예를 들어, 한 달에 한 번 관리자는 rsync를 수행합니다.

실제로 ClickHouse에 내장된 복제 기능을 사용하는 것이 훨씬 쉽습니다. 그러나 ZooKeeper를 사용해야 하기 때문에 몇 가지 금기 사항이 있을 수 있습니다. ZooKeeper에 대해 나쁜 말은 하지 않겠습니다. 원칙적으로 시스템은 작동하지만 사람들이 자바 공포증 때문에 사용하지 않는 경우가 있습니다. 왜냐하면 ClickHouse는 C++로 작성된 매우 좋은 시스템이기 때문입니다. 모든 것이 괜찮을 것입니다. 그리고 ZooKeeper는 Java에 있습니다. 보고 싶지도 않은데 수동 복제를 사용할 수 있습니다.

ClickHouse는 실용적인 시스템입니다. 그녀는 귀하의 필요를 고려합니다. 수동 복제가 있는 경우 수동 복제본을 보고 이들 사이에 장애 조치를 수행하는 분산 테이블을 생성할 수 있습니다. 그리고 라인이 체계적으로 갈라지더라도 실패를 피할 수 있는 특별한 옵션도 있습니다.

기본 테이블 엔진을 사용하면 더 많은 문제가 발생할 수 있습니다. ClickHouse는 다양한 테이블 엔진을 갖춘 생성자입니다. 모든 심각한 경우에는 문서에 명시된 대로 MergeTree 제품군의 테이블을 사용하세요. 나머지는 모두 개별 사례 또는 테스트의 경우입니다.

MergeTree 테이블에서는 날짜와 시간이 필요하지 않습니다. 여전히 사용할 수 있습니다. 날짜와 시간이 없으면 기본값은 2000이라고 씁니다. 이는 작동하며 리소스가 필요하지 않습니다.

그리고 새 버전의 서버에서는 파티션 키 없이 사용자 정의 파티셔닝을 갖도록 지정할 수도 있습니다. 그것은 동일할 것이다.

반면에 기본 테이블 엔진을 사용할 수도 있습니다. 예를 들어, 데이터를 한 번 채우고 보고, 비틀고, 삭제하세요. 로그를 사용할 수 있습니다.

또는 중간 처리를 위해 소량을 저장하는 방법은 StripeLog 또는 TinyLog입니다.

데이터의 양이 적고 RAM의 내용을 간단히 조작할 수 있는 경우 메모리를 사용할 수 있습니다.

ClickHouse는 재정규화된 데이터를 별로 좋아하지 않습니다.

여기에 전형적인 예가 있습니다. 이것은 엄청난 수의 URL입니다. 다음 테이블에 넣으세요. 그런 다음 그들은 그들과 함께 JOIN을 수행하기로 결정했지만 ClickHouse는 Hash JOIN만 지원하기 때문에 일반적으로 작동하지 않습니다. 연결해야 하는 많은 데이터에 비해 RAM이 충분하지 않으면 JOIN이 작동하지 않습니다*.

데이터의 카디널리티가 높더라도 걱정하지 마세요. 비정규화된 형식으로 저장하면 URL이 기본 테이블에 바로 위치하게 됩니다.

* 이제 ClickHouse에는 병합 조인도 있으며 중간 데이터가 RAM에 맞지 않는 조건에서도 작동합니다. 그러나 이는 효과가 없으며 권장 사항은 여전히 ​​유효합니다.

몇 가지 예가 더 있지만 그것이 반패턴인지 아닌지는 이미 의심스럽습니다.

ClickHouse에는 알려진 결함이 하나 있습니다. 업데이트 방법을 모릅니다*. 어떤 면에서는 이것이 심지어 좋은 일이기도 합니다. 예를 들어 회계와 같은 중요한 데이터가 있는 경우 업데이트가 없기 때문에 누구도 이를 보낼 수 없습니다.

* 배치 모드에서 업데이트 및 삭제에 대한 지원은 오래 전에 추가되었습니다.

그러나 백그라운드에서처럼 업데이트를 허용하는 몇 가지 특별한 방법이 있습니다. 예를 들어, RecreMergeTree와 같은 테이블이 있습니다. 백그라운드 병합 중에 업데이트됩니다. 최적화 테이블을 사용하여 이를 강제할 수 있습니다. 하지만 이 작업을 너무 자주 수행하지 마십시오. 파티션을 완전히 덮어쓰게 되기 때문입니다.

ClickHouse의 분산 JOIN도 쿼리 플래너에서 제대로 처리되지 않습니다.

나쁘지만 가끔은 괜찮습니다.

ClickHouse를 사용하면 select*를 사용하여 데이터를 다시 읽을 수 있습니다.

번거로운 계산에는 ClickHouse를 사용하지 않는 것이 좋습니다. 그러나 우리는 이미 이 권장 사항에서 벗어나고 있기 때문에 이는 전적으로 사실이 아닙니다. 그리고 최근에는 ClickHouse - Catboost에 기계 학습 모델을 적용하는 기능을 추가했습니다. 그리고 “정말 끔찍한 일이구나. 이것은 바이트당 몇 사이클인지를 나타냅니다! 나는 바이트 단위로 시계를 낭비하는 것을 정말 싫어합니다.

하지만 두려워하지 마세요. ClickHouse를 설치하면 모든 것이 잘 될 것입니다. 어쨌든 우리에게는 커뮤니티가 있습니다. 그런데 커뮤니티는 바로 당신입니다. 문제가 있는 경우 최소한 채팅에 참여하시면 도움이 될 것입니다.

질문

신고해 주셔서 감사합니다! ClickHouse 충돌에 대해 어디에서 불만을 제기할 수 있나요?

지금 당장 저에게 개인적으로 불만을 제기하실 수 있습니다.

최근 ClickHouse를 사용하기 시작했습니다. 나는 즉시 cli 인터페이스를 삭제했습니다.

당신은 운이 좋다.

조금 후에 작은 선택으로 서버가 충돌했습니다.

당신은 재능이 있습니다.

GitHub 버그를 열었지만 무시되었습니다.

우리는 볼 것이다.

Alexey는 당신이 내부 데이터에 접근하는 방법을 알려 주겠다고 약속하면서 나를 속여 보고서에 참석하도록 했습니다.

아주 간단합니다.

나는 이것을 어제 깨달았다. 더 구체적인 내용.

거기에는 끔찍한 트릭이 없습니다. 블록별 압축만 있습니다. 기본값은 LZ4이며 ZSTD*를 활성화할 수 있습니다. 64KB에서 1MB까지 차단합니다.

* 다른 알고리즘과 함께 체인에서 사용할 수 있는 특수 압축 코덱도 지원됩니다.

블록은 단지 원시 데이터입니까?

완전히 원시는 아닙니다. 배열이 있습니다. 숫자 열이 있는 경우 행의 숫자는 배열에 배치됩니다.

알 겠어.

IP를 통한 uniqExact의 예인 Alexey, 즉 uniqExact가 숫자보다 줄로 계산하는 데 시간이 더 오래 걸린다는 사실 등입니다. 교정할 때 귀로 페인팅을 해서 캐스팅을 하면 어떨까요? 즉, 우리 디스크에서는 크게 다르지 않다고 말씀하신 것 같습니다. 디스크에서 라인을 읽고 캐스팅하면 집계가 더 빨라질까요, 아니면 안 될까요? 아니면 여기서도 약간의 이득을 얻을 수 있을까요? 이것을 테스트한 것 같지만 어떤 이유로 벤치마크에 표시되지 않았습니다.

캐스팅을 하지 않은 것보다 느릴 것 같아요. 이 경우 문자열에서 IP 주소를 구문 분석해야 합니다. 물론 ClickHouse에서는 IP 주소 구문 분석도 최적화되어 있습니다. 우리는 매우 열심히 노력했지만 거기에는 만분의 일 형식으로 숫자가 적혀 있습니다. 매우 불편합니다. 반면에 uniqExact 함수는 문자열일 뿐 아니라 알고리즘의 다른 특수화가 선택되었기 때문에 문자열에서 더 느리게 작동합니다. 문자열은 단순히 다르게 처리됩니다.

좀 더 원시적인 데이터 유형을 취하면 어떻게 될까요? 예를 들어 우리가 갖고 있는 사용자 아이디를 한 줄로 적어서 뒤섞어 놓으면 더 재미있을지 안 좋을지?

나는 의심한다. 숫자를 파싱하는 것은 결국 심각한 문제이기 때문에 더욱 슬픈 일이 될 것 같습니다. 제가 보기엔 이 동료가 숫자를 만 단위 형식으로 구문 분석하는 것이 얼마나 어려운지에 대한 보고서를 제출한 것 같지만 그렇지 않을 수도 있습니다.

Alexey, 보고서를 보내주셔서 정말 감사합니다! 그리고 ClickHouse를 이용해 주셔서 대단히 감사합니다! 계획에 관해 질문이 있습니다. 사전을 불완전하게 업데이트하는 기능에 대한 계획이 있나요?

즉, 부분 재부팅인가요?

예 예. 거기에 MySQL 필드를 설정하는 기능과 같습니다. 즉, 사전이 매우 큰 경우 이 데이터만 로드되도록 나중에 업데이트합니다.

매우 흥미로운 기능입니다. 그리고 어떤 사람이 채팅에서 제안한 것 같아요. 어쩌면 당신이었을 수도 있습니다.

나는 그렇게 생각하지 않습니다.

좋습니다. 이제 두 가지 요청이 있는 것으로 나타났습니다. 그리고 천천히 시작해도 됩니다. 하지만 이 기능은 구현하기가 매우 간단하다는 점을 즉시 경고하고 싶습니다. 즉, 이론적으로는 테이블에 버전 번호를 쓴 다음 다음과 같이 쓰면 됩니다. 이는 아마도 우리가 이것을 매니아들에게 제공할 것이라는 것을 의미합니다. 당신은 열성팬인가요?

예, 하지만 안타깝게도 C++에서는 지원되지 않습니다.

동료들이 C++로 작성하는 방법을 알고 있습니까?

내가 누군가를 찾아볼게.

엄청난*.

* 이 기능은 보고서가 작성된 지 XNUMX개월 후에 추가되었습니다. - 질문 작성자가 이 기능을 개발하여 자신의 풀 요청.

감사합니다!

안녕하세요! 신고해 주셔서 감사합니다! ClickHouse가 사용 가능한 모든 리소스를 매우 잘 소비한다고 언급하셨습니다. 그리고 Luxoft 옆에 있는 발표자는 Russian Post에 대한 그의 솔루션에 대해 이야기했습니다. 그는 ClickHouse를 정말 좋아했지만 CPU를 모두 잡아먹기 때문에 주요 경쟁사 대신 사용하지 않았다고 말했습니다. 그리고 그들은 그것을 그들의 아키텍처, 도커를 사용하는 ZooKeeper에 연결할 수 없었습니다. ClickHouse가 사용 가능한 모든 항목을 소비하지 않도록 어떻게든 제한할 수 있습니까?

예, 가능하며 매우 쉽습니다. 더 적은 코어를 소비하려면 다음을 작성하십시오. set max_threads = 1. 이것이 바로 하나의 코어에서 요청을 실행하는 것입니다. 또한 사용자마다 다른 설정을 지정할 수 있습니다. 그러니 문제 없습니다. 그리고 Luxoft의 동료들에게 문서에서 이 설정을 찾지 못한 것은 좋지 않다고 말하세요.

알렉세이, 안녕하세요! 이 질문에 대해 묻고 싶습니다. 많은 사람들이 ClickHouse를 로그 저장소로 사용하기 시작했다는 소식을 들은 것은 이번이 처음이 아닙니다. 보고서에서 이렇게 하지 말라고 하셨습니다. 즉, 긴 문자열을 저장할 필요가 없습니다. 당신이 그것에 대해 어떻게 생각하십니까?

첫째, 로그는 원칙적으로 긴 문자열이 아닙니다. 물론 예외도 있습니다. 예를 들어, Java로 작성된 일부 서비스에서는 예외가 발생하고 기록됩니다. 이런 식으로 무한 루프가 발생하면 하드 드라이브 공간이 부족해집니다. 해결책은 매우 간단합니다. 줄이 너무 길면 잘라주세요. 길다은 무슨 뜻인가요? 수십 킬로바이트는 좋지 않습니다*.

* 최신 버전의 ClickHouse에서는 "적응형 인덱스 세분성"이 활성화되어 긴 행을 저장하는 문제가 대부분 제거됩니다.

킬로바이트가 정상인가요?

정상입니다.

안녕하세요! 신고해 주셔서 감사합니다! 이미 채팅으로 문의했는데 답변을 받았는지 기억이 나지 않습니다. CTE 방식으로 WITH 섹션을 확장할 계획이 있나요?

아직 아님. 우리의 WITH 섹션은 다소 경솔합니다. 그것은 우리에게 작은 기능과 같습니다.

이해합니다. 감사합니다!

신고해 주셔서 감사합니다! 매우 흥미로운! 글로벌 질문입니다. 일종의 스텁 형태로 데이터 삭제를 수정할 계획이 있나요?

반드시. 이것이 우리 대기열의 첫 번째 작업입니다. 이제 우리는 모든 일을 올바르게 수행하는 방법에 대해 적극적으로 생각하고 있습니다. 그리고 키보드*를 누르기 시작해야 합니다.

* 키보드의 버튼을 누르고 모든 작업을 수행했습니다.

이것이 시스템 성능에 어떤 영향을 미칠까요, 안 될까요? 지금처럼 삽입 속도가 빨라질까요?

삭제 자체와 업데이트 자체가 매우 무거울 수도 있지만 이는 선택 성능이나 삽입 성능에 영향을 미치지 않습니다.

그리고 또 하나의 작은 질문이 있습니다. 프레젠테이션에서 기본 키에 대해 이야기하셨습니다. 따라서 우리는 기본적으로 월별 파티셔닝을 갖고 있습니다. 맞나요? 그리고 한 달에 맞는 날짜 범위를 설정하면 이 파티션만 읽히죠?

네.

질문입니다. 기본 키를 선택할 수 없는 경우 "날짜" 필드에 따라 구체적으로 수행하여 백그라운드에서 이 데이터가 더 질서정연하게 맞도록 재배열하는 일이 줄어드는 것이 맞습니까? 범위 쿼리가 없고 기본 키를 선택할 수도 없는 경우 기본 키에 날짜를 입력하는 것이 가치가 있습니까?

네.

이 필드를 기준으로 정렬하면 데이터를 더 잘 압축할 수 있는 필드를 기본 키에 넣는 것이 합리적일 수 있습니다. 예를 들어 사용자 ID입니다. 예를 들어 사용자는 동일한 사이트로 이동합니다. 이 경우 사용자 ID와 시간을 입력합니다. 그러면 데이터가 더 잘 압축됩니다. 날짜의 경우, 날짜에 대한 범위 쿼리가 실제로 없고 전혀 없는 경우 기본 키에 날짜를 넣을 필요가 없습니다.

알았어 정말 고마워!

출처 : habr.com