질문과 답변이 있는 고급 사용자를 위한 ClickHouse

XNUMX월에 Avito 엔지니어들은 주요 ClickHouse 개발자 Alexey Milovidov 및 Integros의 Golang 개발자인 Kirill Shvakov와 온라인 회의를 위해 모였습니다. 우리는 데이터베이스 관리 시스템을 사용하는 방법과 직면하는 어려움에 대해 논의했습니다.

회의를 바탕으로 백업, 데이터 리샤딩, 외부 사전, Golang 드라이버 및 ClickHouse 버전 업데이트에 대한 우리와 청중의 질문에 대한 전문가의 답변을 담은 기사를 편집했습니다. 이미 Yandex DBMS를 적극적으로 사용하고 있으며 현재와 미래에 관심이 있는 개발자에게 유용할 수 있습니다. 달리 작성하지 않는 한 기본적으로 답변은 Alexey Milovidov가 작성합니다.

컷 아래에 텍스트가 많으므로 주의하세요. 질문이 있는 콘텐츠가 탐색에 도움이 되기를 바랍니다.

내용

• ClickHouse는 지속적으로 업데이트되지만 데이터는 그렇지 않습니다. 어떻게 해야 할까요?
• ClickHouse의 데이터 백업에 대한 현재 모범 사례는 무엇입니까?
• 샤프트에서 복제품의 지연을 제어하는 ​​것이 가능합니까?
• 테이블 구조가 변경되면 어떻게 되나요?
• 데이터 리샤딩에 대한 현재 모범 사례는 무엇입니까?
• ClickHouse에는 클릭하우스 복사기 유틸리티가 있습니다. 그녀에 대해 말해 줄 수 있나요?
• 리샤딩이라는 파일럿 작업이 있었습니다. 그녀는 어쩌고?
• 느린 디스크로 이동하기 전에 모든 데이터 조각을 병합할 수 있습니까?
• 호환성을 미리 확인할 수 없는 경우 ClickHouse의 새 버전으로 마이그레이션하는 방법은 무엇입니까?
• 쿼리 종료는 쿼리를 종료해야 하지만 그렇지 않습니다. 왜?
• 읽기 부하 시 응답 시간을 계산하는 방법은 무엇입니까?
• 더 많은 데이터가 캐시에 저장되도록 ClickHouse에서 무엇을 조정할 수 있나요?
• RAM에 저장하기 위해 Storage_configuration을 어떻게 구성합니까?
• 낮은 카디널리티는 몇 개의 고유 값까지 유효합니까?
• XNUMX억 행이 있는 테이블에서 전체 텍스트를 검색하는 모범 사례는 무엇입니까?
• 다수의 사용자를 위해 ClickHouse에 대한 액세스를 구성하는 가장 좋은 방법은 무엇입니까?
• 하나의 쿼리 결과를 XNUMX명의 클라이언트에게 제공하는 것이 가능합니까?
• 비동기 작업과 구체화된 뷰는 어떻습니까?
• ClickHouse에는 많은 로그가 있습니다. 현재 서버에서 일어나는 모든 일을 어떻게 볼 수 있나요?
• 서버가 OOM에 충돌하지 않도록 병합에 영향을 미치는 방법은 무엇입니까?
• ClickHouse용 Golang 드라이버는 어떻게 개발되나요?
• lazy_load 설정이 활성화된 상태로 재부팅한 후에는 외부 사전이 로드되지 않습니다. 무엇을 해야 할까요?
• 시스템 다시 로드 사전 중 적어도 하나가 오류로 인해 충돌하는 경우 많은 사전 중 어느 것도 로드하지 않는다는 사실을 어떻게 해야 합니까?
• ClickHouse 구성에서 세부 정보를 구성하지만 오류가 발생할 경우 표시하지 않는 방법이 있습니까?
• 보너스: 모임에서 Zoom을 위한 배경

글을 읽기 싫으시면 모임녹화를 시청하시면 됩니다 우리 유튜브 채널에서. 타임코드는 영상 아래 첫 댓글에 있습니다.

ClickHouse는 지속적으로 업데이트되지만 데이터는 그렇지 않습니다. 어떻게 해야 할까요?

클릭하우스는 지속적으로 업데이트되며, 최적화된 최종 처리된 데이터는 업데이트되지 않고 백업본으로 보관됩니다.

문제가 발생하여 데이터가 손실되었다고 가정해 보겠습니다. 우리는 복원하기로 결정했고 백업 서버에 저장되어 있는 이전 파티션이 현재 사용되는 ClickHouse 버전과 매우 다른 것으로 나타났습니다. 이런 상황에서는 어떻게 해야 하며, 가능합니까?

이전 형식의 백업에서 데이터를 복원했지만 새 버전에 연결되지 않는 상황은 불가능합니다. ClickHouse의 데이터 형식은 항상 이전 버전과 호환되도록 보장합니다. 거의 사용되지 않는 일부 기능의 동작이 변경된 경우 이는 기능 면에서 이전 버전과의 호환성보다 훨씬 더 중요합니다. ClickHouse의 새 버전은 항상 디스크에 저장된 데이터를 읽을 수 있어야 합니다. 이것이 법이다.

ClickHouse의 데이터 백업에 대한 현재 모범 사례는 무엇입니까?

최종 작업, 테라바이트 단위의 거대한 데이터베이스, 지난 XNUMX일 동안 업데이트된 데이터를 최적화했는데 아무런 절차도 수행되지 않는다는 점을 고려하여 백업을 만드는 방법은 무엇입니까?

우리는 우리 자신의 솔루션을 만들고 bash에 쓸 수 있습니다. 이러한 백업 복사본을 이러한 방식으로 수집합니다. 목발을 짚을 필요도 없고 자전거가 오래 전에 발명된 건 아닐까?

모범 사례부터 시작해 보겠습니다. 내 동료들은 백업에 대한 질문에 대해 항상 이 문제가 이미 해결된 Yandex.Cloud 서비스에 대해 상기시키라고 조언합니다. 그러니 가능하다면 사용하세요.

ClickHouse에 XNUMX% 내장된 완벽한 백업 솔루션은 없습니다. 사용할 수 있는 공백이 있습니다. 완전한 솔루션을 얻으려면 수동으로 약간 수정하거나 스크립트 형식으로 래퍼를 만들어야 합니다.

데이터 양과 클러스터 크기에 따라 가장 간단한 솔루션부터 시작해 가장 정교한 솔루션으로 마무리하겠습니다. 클러스터가 클수록 솔루션이 더 복잡해집니다.

데이터가 있는 테이블이 몇 기가바이트만 차지하는 경우 다음과 같이 백업을 수행할 수 있습니다.

1. 테이블 정의, 즉 메타데이터 저장 - 테이블 생성 표시.
2. ClickHouse 클라이언트를 사용하여 덤프 만들기 - 고르다 * 테이블에서 파일로. 기본적으로 TabSeparated 형식의 파일을 받게 됩니다. 보다 효율적으로 작업하려면 기본 형식으로 수행할 수 있습니다.

데이터 양이 많으면 백업에 더 많은 시간과 공간이 소요됩니다. 이를 논리적 백업이라고 하며 ClickHouse 데이터 형식과 연결되지 않습니다. 그렇다면 최후의 수단으로 백업을 수행하고 복구를 위해 MySQL에 업로드할 수 있습니다.

고급 사례의 경우 ClickHouse에는 로컬 파일 시스템에서 파티션의 스냅샷을 생성하는 기능이 내장되어 있습니다. 이 기능은 요청 시 제공됩니다. 테이블 고정 파티션 변경. 아니면 단순히 테이블 고정 변경 - 전체 테이블의 스냅샷입니다.

스냅샷은 하나의 샤드에 있는 하나의 테이블에 대해 일관되게 생성됩니다. 즉, 이러한 방식으로 전체 클러스터의 일관된 스냅샷을 생성하는 것은 불가능합니다. 그러나 대부분의 작업에서는 그러한 필요가 없으며 각 샤드에서 요청을 실행하고 일관된 스냅샷을 얻는 것으로 충분합니다. 하드링크 형태로 생성되므로 추가 공간을 차지하지 않습니다. 그런 다음 이 스냅샷을 백업 서버 또는 백업에 사용하는 스토리지에 복사합니다.

이러한 백업을 복원하는 것은 매우 쉽습니다. 먼저 기존 테이블 정의를 사용하여 테이블을 만듭니다. 다음으로, 파티션의 저장된 스냅샷을 해당 테이블에 대한 디렉터리 분리에 복사하고 쿼리를 실행합니다. 파티션 연결. 이 솔루션은 가장 심각한 데이터 볼륨에 매우 적합합니다.

각 서버와 수백 대의 서버에 수십, 심지어 수백 테라바이트가 있는 경우에는 더 멋진 것이 필요할 때도 있습니다. Yandex.Metrica의 동료들로부터 제가 선택한 솔루션이 있습니다. 나는 그것을 모든 사람에게 추천하지는 않습니다. 읽어보고 그것이 적합한지 아닌지 스스로 결정하십시오.

먼저 대형 Disk Shelf가 있는 여러 서버를 생성해야 합니다. 다음으로, 이러한 서버에서 여러 ClickHouse 서버를 생성하고 동일한 샤드에 대한 또 다른 복제본으로 작동하도록 구성합니다. 그런 다음 이러한 서버에서 스냅샷을 생성할 수 있는 파일 시스템이나 일부 도구를 사용하십시오. 여기에는 두 가지 옵션이 있습니다. 첫 번째 옵션은 LVM 스냅샷이고, 두 번째 옵션은 Linux의 ZFS입니다.

그 후에는 매일 스냅샷을 만들어야 하며, 스냅샷은 누워서 공간을 차지하게 됩니다. 당연히 데이터가 변경되면 시간이 지남에 따라 공간이 늘어납니다. 이 스냅샷은 언제든지 꺼내어 데이터를 복원할 수 있습니다. 정말 이상한 해결책입니다. 또한 이러한 복제본이 리더가 되려고 하지 않도록 구성에서 이러한 복제본을 제한해야 합니다.

샤프트에서 복제품의 지연을 제어하는 ​​것이 가능합니까?

올해는 ClickHouse에서 샤프트를 만들 계획입니다. 복제본의 지연을 제어하여 구성할 수 있습니까? 우리는 이를 변경 및 기타 변경으로 인한 부정적인 시나리오로부터 자신을 보호하기 위해 사용하고 싶습니다.

변경 사항에 대해 일종의 롤백을 수행할 수 있습니까? 예를 들어, 기존 샤프트에서 지금까지 변경 사항을 적용하고 이 순간부터 변경 사항 적용을 중단한다고 가정해 보겠습니다.

명령이 클러스터에 와서 중단된 경우 시간 지연이 있는 조건부 복제본이 있습니다. 여기서는 지금은 사용하지만 마지막 XNUMX분 동안 변경 사항을 적용하지 않을 것이라고 말할 수 있습니다.

첫째, 복제본의 제어된 지연에 대해 설명합니다. 사용자들로부터 그런 요청이 있었고 우리는 Github에 "이것이 필요한 사람이 있다면 마음을 담아주세요"라는 요청으로 이슈를 만들었습니다. 아무도 배달하지 않았고 문제는 종료되었습니다. 그러나 ClickHouse를 설정하면 이미 이 기회를 얻을 수 있습니다. 사실입니다. 버전 20.3부터 시작됩니다.

ClickHouse는 백그라운드에서 지속적으로 데이터 병합을 수행합니다. 병합이 완료되면 특정 데이터 조각 세트가 더 큰 조각으로 대체됩니다. 동시에 이전에 있던 데이터 조각은 한동안 디스크에 계속 남아 있습니다.

첫째, 비차단 작업을 제공하기 위해 이를 사용하는 선택 쿼리가 있는 한 계속 저장됩니다. 선택 쿼리는 이전 청크에서 쉽게 읽을 수 있습니다.

둘째, 시간 임계값도 있습니다. 오래된 데이터 조각이 XNUMX분 동안 디스크에 남아 있습니다. 이 XNUMX분은 맞춤 설정이 가능하며 심지어 하루로 전환될 수도 있습니다. 이렇게 하면 디스크 공간이 소모됩니다. 데이터 흐름에 따라 마지막 날에는 데이터가 두 배일 뿐만 아니라 다섯 배 더 커질 수도 있습니다. 하지만 심각한 문제가 발생하면 ClickHouse 서버를 중지하고 모든 것을 정리할 수 있습니다.

이제 이것이 변경으로부터 어떻게 보호되는지에 대한 의문이 생깁니다. ClickHouse의 이전 버전에서는 변경 작업이 단순히 부분을 직접 변경하는 방식으로 작동했기 때문에 여기에서 더 자세히 살펴볼 가치가 있습니다. 일부 파일에 데이터 조각이 있는데, 예를 들어 다음과 같습니다. 드롭 열 변경. 그런 다음 이 열은 모든 청크에서 물리적으로 제거됩니다.

그러나 버전 20.3부터 변경 메커니즘이 완전히 변경되어 이제 데이터 조각은 항상 변경할 수 없습니다. 전혀 변경되지 않습니다. 이제 변경은 병합과 거의 동일한 방식으로 작동합니다. 즉석에서 부품을 교체하는 대신 새 부품을 만듭니다. 새 청크에서는 변경되지 않은 파일이 하드링크가 되며, 열을 삭제하면 새 청크에서 해당 열이 누락됩니다. 이전 부분은 기본적으로 XNUMX분 후에 삭제되며, 여기서 위에서 언급한 설정을 조정할 수 있습니다.

돌연변이와 같은 변경에도 동일하게 적용됩니다. 당신이 할 때 변경 삭제 또는 업데이트 변경, 조각을 변경하지 않고 새 조각을 만듭니다. 그런 다음 이전 항목을 삭제합니다.

테이블 구조가 변경되면 어떻게 되나요?

이전 구성표로 생성된 백업을 복원하는 방법은 무엇입니까? 두 번째 질문은 스냅샷과 파일 시스템 도구에 관한 것입니다. Linux LVM에서 ZFS 대신 Btrfs가 좋습니까?

만약 당신이 파티션 연결 구조가 다른 파티션을 사용하면 ClickHouse에서 이것이 불가능하다고 알려줍니다. 이것이 해결책입니다. 첫 번째는 이전 구조를 사용하여 MergeTree 유형의 임시 테이블을 생성하고, Attach를 사용하여 거기에 데이터를 첨부하고, 변경 쿼리를 수행하는 것입니다. 그런 다음 이 데이터를 복사 또는 전송하고 다시 첨부하거나 요청을 사용할 수 있습니다. 테이블 이동 파티션 변경.

이제 두 번째 질문은 Btrfs를 사용할 수 있는지 여부입니다. 우선 LVM이 있으면 LVM 스냅샷이면 충분하고 파일 시스템은 ext4일 수 있으므로 상관없습니다. Btrts를 사용하면 모든 것이 사용 경험에 따라 달라집니다. 이것은 성숙한 파일 시스템이지만 특정 시나리오에서 실제로 모든 것이 어떻게 작동할지에 대한 의심이 여전히 남아 있습니다. 프로덕션에 Btrfs가 없으면 이것을 사용하지 않는 것이 좋습니다.

데이터 리샤딩에 대한 현재 모범 사례는 무엇입니까?

리샤딩 문제는 복잡하고 다면적입니다. 여기에는 몇 가지 가능한 답변이 있습니다. 한쪽에서 이렇게 말할 수 있습니다. ClickHouse에는 리샤딩 기능이 내장되어 있지 않습니다. 하지만 이 답변은 누구에게도 적합하지 않을 것 같습니다. 따라서 반대편에서 ClickHouse에는 데이터를 재분할하는 다양한 방법이 있다고 말할 수 있습니다.

클러스터 공간이 부족하거나 로드를 처리할 수 없는 경우 새 서버를 추가합니다. 그러나 이러한 서버는 기본적으로 비어 있고 데이터도 없으며 로드도 없습니다. 더 큰 새 클러스터에 균등하게 분산되도록 데이터를 다시 정렬해야 합니다.

이를 수행할 수 있는 첫 번째 방법은 요청을 사용하여 파티션의 일부를 새 서버에 복사하는 것입니다. 테이블 가져오기 파티션 변경. 예를 들어 월별 파티션이 있고 2017년 첫 번째 달을 새 서버에 복사한 다음 세 번째 달을 다른 새 서버에 복사합니다. 그리고 어느 정도 균일해질 때까지 이 작업을 수행합니다.

녹화 중 변경되지 않는 파티션에 대해서만 전송이 가능합니다. 새로운 파티션의 경우 전송이 원자적이지 않기 때문에 기록을 비활성화해야 합니다. 그렇지 않으면 데이터에 중복이나 공백이 발생하게 됩니다. 그러나 이 방법은 실용적이고 매우 효과적으로 작동합니다. 미리 만들어진 압축 파티션은 네트워크를 통해 전송됩니다. 즉, 데이터가 압축되거나 다시 인코딩되지 않습니다.

이 방법에는 한 가지 단점이 있으며 샤딩 체계, 이 샤딩 체계를 약속했는지 여부, 어떤 샤딩 키를 가지고 있는지에 따라 다릅니다. 측정항목의 경우 샤딩 키는 경로의 해시입니다. 분산 테이블을 선택하면 클러스터의 모든 샤드로 한 번에 이동하여 거기에서 데이터를 가져옵니다.

즉, 어떤 데이터가 어떤 샤드에 저장되었는지는 실제로 중요하지 않습니다. 가장 중요한 것은 한 경로의 데이터가 하나의 샤드로 끝나지만 어느 샤드인지는 중요하지 않다는 것입니다. 이 경우 미리 만들어진 파티션을 전송하는 것이 완벽합니다. 선택 쿼리를 사용하면 리샤딩 전이든 후든 전체 데이터를 받을 수 있기 때문입니다. 구성표는 실제로 중요하지 않습니다.

그러나 더 복잡한 경우도 있습니다. 애플리케이션 논리 수준에서 특별한 샤딩 체계를 사용하는 경우 이 클라이언트는 이러한 샤드에 위치하며 요청은 분산 테이블이 아닌 샤드에서 직접 보낼 수 있습니다. 또는 상당히 최신 버전의 ClickHouse를 사용하고 있으며 설정을 활성화했습니다. 사용하지 않는 샤드 건너뛰기 최적화. 이 경우 선택 쿼리 중에 where 섹션의 표현식이 분석되고 샤딩 방식에 따라 어떤 샤드를 사용해야 하는지 계산됩니다. 이는 데이터가 이 샤딩 방식에 따라 정확하게 분할된 경우에 작동합니다. 수동으로 재배열한 경우 해당 내용이 변경될 수 있습니다.

이것이 첫 번째 방법입니다. 그리고 그 방법이 적합한지, 아니면 다음으로 넘어가도록 하겠는지, 여러분의 답변을 기다리고 있습니다.

Vladimir Kolobaev, Avito의 수석 시스템 관리자: Alexey, 당신이 언급한 방법은 독서를 포함하여 부하를 분산시켜야 할 때 잘 작동하지 않습니다. 월별 파티션을 가져와 이전 달을 다른 노드로 가져올 수 있지만 이 데이터에 대한 요청이 오면 해당 데이터만 로드합니다. 하지만 우리는 전체 클러스터를 로드하고 싶습니다. 그렇지 않으면 한동안 전체 읽기 로드가 두 개의 샤드에 의해 처리되기 때문입니다.

알렉세이 밀로비도프: 여기에 대한 대답은 이상합니다. 예, 나쁘지만 작동할 수도 있습니다. 그 방법을 구체적으로 설명하겠습니다. 데이터 이면의 로드 시나리오를 살펴보는 것이 좋습니다. 데이터를 모니터링하는 경우 요청의 대부분이 최신 데이터에 대한 것이라고 거의 확실하게 말할 수 있습니다.

새 서버를 설치하고 기존 파티션을 마이그레이션했을 뿐 아니라 최신 데이터가 기록되는 방식도 변경했습니다. 그리고 새로운 데이터가 클러스터 전체에 분산됩니다. 따라서 단 XNUMX분 후에는 마지막 XNUMX분 동안의 요청이 클러스터를 균등하게 로드하고, 하루 후에 XNUMX시간 동안의 요청은 클러스터를 균등하게 로드합니다. 그리고 안타깝게도 지난달에 대한 요청은 클러스터 서버의 일부로만 전달됩니다.

그러나 2019년 2019월에 대한 요청이 없는 경우가 많습니다. 요청이 2019년에 시작되면 XNUMX년 전체에 대한 요청이 될 가능성이 높습니다. 일부 작은 범위가 아닌 오랜 기간 동안 수행됩니다. 또한 이러한 요청은 클러스터를 균등하게 로드할 수도 있습니다. 그러나 일반적으로 이것이 데이터를 완전히 균등하게 분산시키지 않는 임시 솔루션이라는 귀하의 의견은 절대적으로 정확합니다.

질문에 답할 몇 가지 사항이 더 있습니다. 그 중 하나는 재샤딩으로 인해 고통이 덜하도록 샤딩 체계를 초기에 설계하는 방법에 관한 것입니다. 이것이 항상 가능한 것은 아닙니다.

예를 들어 모니터링 데이터가 있습니다. 모니터링 데이터는 세 가지 이유로 증가하고 있습니다. 첫 번째는 과거 데이터의 축적이다. 두 번째는 트래픽 증가이다. 셋째, 모니터링 대상의 증가이다. 저장해야 할 새로운 마이크로서비스와 지표가 있습니다.

이 중 가장 큰 증가는 세 번째 이유인 모니터링 사용 증가와 관련이 있을 수 있습니다. 이 경우 로드의 특성과 주요 선택 쿼리가 무엇인지 살펴볼 가치가 있습니다. 기본 선택 쿼리는 측정항목의 일부 하위 집합을 기반으로 할 가능성이 높습니다.

예를 들어 일부 서비스에 의한 일부 서버의 CPU 사용량입니다. 이 데이터를 얻는 데 사용되는 특정 키 하위 집합이 있는 것으로 나타났습니다. 그리고 이 데이터에 대한 요청 자체는 매우 간단할 가능성이 높으며 수십 밀리초 내에 완료됩니다. 모니터링 서비스 및 대시보드에 사용됩니다. 나는 이것을 올바르게 이해하기를 바랍니다.

블라디미르 콜로바예프: 사실 우리는 현재 상황을 과거 상황과 실시간으로 비교하기 때문에 과거 데이터에 매우 자주 호소합니다. 그리고 우리에게는 대량의 데이터에 빠르게 접근하는 것이 중요하며 ClickHouse는 이를 훌륭하게 수행합니다.

당신 말이 맞습니다. 다른 모니터링 시스템과 마찬가지로 우리는 마지막 날에 대부분의 읽기 요청을 경험합니다. 그러나 동시에 과거 데이터에 대한 부하도 상당히 큽니다. 이는 기본적으로 XNUMX초마다 돌아가며 ClickHouse에 다음과 같이 말하는 경고 시스템에서 나온 것입니다. “지난 XNUMX주 동안의 데이터를 주세요. 이제 그것들로부터 일종의 이동 평균을 만들고 현재 가치를 과거 가치와 비교해 보겠습니다.”

매우 최근의 요청에 대해 이틀 동안의 데이터만 저장하고 주요 요청이 그 테이블로 이동하는 또 다른 작은 테이블이 있다고 말하고 싶습니다. 대규모 기록 쿼리는 대규모로 분할된 테이블에만 보냅니다.

알렉세이 밀로비도프: 불행하게도 이는 귀하의 시나리오에 적합하지 않은 것으로 밝혀졌습니다. 사용할 필요는 없지만 내 친구의 서비스에서 사용되는 두 가지 나쁘고 복잡한 샤딩 방식에 대해 설명하겠습니다.

Yandex.Metrica 이벤트가 있는 기본 클러스터가 있습니다. 이벤트는 페이지 조회, 클릭, 전환입니다. 대부분의 요청은 특정 웹사이트로 이동합니다. Yandex.Metrica 서비스를 열고 웹사이트(avito.ru)가 있고 보고서로 이동하면 웹사이트에 대한 요청이 이루어집니다.

그러나 내부 분석가가 제출한 분석적 요청과 글로벌 요청도 있습니다. 만약을 대비해 내부 분석가는 Yandex 서비스에 대해서만 요청한다는 점에 주목합니다. 그럼에도 불구하고 Yandex 서비스조차도 전체 데이터에서 상당한 부분을 차지합니다. 이는 특정 카운터에 대한 요청이 아니라 더 광범위한 필터링에 대한 요청입니다.

하나의 카운터와 글로벌 쿼리에 대해 모든 것이 효율적으로 작동하도록 데이터를 구성하는 방법은 무엇입니까? 또 다른 어려움은 Metrics 클러스터에 대한 ClickHouse의 요청 수가 초당 수천 건이라는 것입니다. 동시에 하나의 ClickHouse 서버는 예를 들어 초당 수천 건의 중요하지 않은 요청을 처리할 수 없습니다.

클러스터 크기는 XNUMX대 정도의 서버입니다. 단순히 이 클러스터를 통해 분산 테이블을 가져와 수천 개의 요청을 보내면 하나의 서버로 보내는 것보다 훨씬 더 나빠질 것입니다. 반면에 데이터가 균등하게 분산되어 모든 서버에 요청하는 옵션은 즉시 해제됩니다.

정반대의 옵션이 있습니다. 여러 사이트에 걸쳐 데이터를 샤딩하고 한 사이트에 대한 요청이 하나의 샤드로 이동한다고 상상해 보세요. 이제 클러스터는 초당 XNUMX개의 요청을 처리할 수 있지만 하나의 샤드에서는 요청 하나가 너무 느리게 작동합니다. 더 이상 처리량 측면에서 확장되지 않습니다. 특히 이것이 avito.ru 사이트인 경우. Avito가 RuNet에서 가장 많이 방문한 사이트 중 하나라고 말하면 비밀을 밝히지 않겠습니다. 그리고 이를 하나의 샤드에서 처리하는 것은 미친 일이 될 것입니다.

따라서 샤딩 방식은 더욱 교활한 방식으로 설계되었습니다. 전체 클러스터는 레이어라고 불리는 여러 클러스터로 나뉩니다. 각 클러스터에는 XNUMX개에서 수십 개의 샤드가 포함됩니다. 그러한 클러스터는 총 XNUMX개가 있습니다.

이 모든 것이 어떻게 확장됩니까? 클러스터 수는 변하지 않습니다. 몇 년 전 XNUMX개였던 것처럼 그대로 유지됩니다. 하지만 각각의 데이터를 축적하면서 샤드의 수를 점차 늘려갑니다. 샤딩 체계 전체는 다음과 같습니다. 이러한 클러스터는 웹사이트로 나누어지며, 어떤 웹사이트가 어떤 클러스터에 있는지 이해하기 위해 MySQL의 별도 메타베이스가 사용됩니다. 하나의 사이트 - 하나의 클러스터에 있습니다. 그리고 그 내부에서는 방문자 ID에 따라 샤딩이 발생합니다.

녹화시 방문자ID를 나눈 나머지 부분으로 나누어 기록합니다. 그러나 새 샤드를 추가하면 샤딩 체계가 변경되어 계속 분할되지만 나머지 부분은 다른 숫자로 분할됩니다. 이는 한 명의 방문자가 이미 여러 서버에 위치하므로 이에 의존할 수 없음을 의미합니다. 이는 데이터를 더 잘 압축하기 위해서만 수행됩니다. 그리고 요청을 할 때 클러스터를 살펴보고 수십 개의 서버에 액세스하는 분산 테이블로 이동합니다. 정말 어리석은 계획이네요.

하지만 우리가 이 계획을 포기했다고 말하지 않으면 내 이야기는 불완전할 것입니다. 새로운 구성표에서는 clickhouse-copier를 사용하여 모든 것을 변경하고 모든 데이터를 복사했습니다.

새로운 계획에서는 모든 사이트가 크고 작은 두 가지 범주로 나뉩니다. 임계값이 어떻게 선택되었는지는 모르겠지만 결과적으로 대규모 사이트가 하나의 클러스터에 기록되었으며, 여기에는 각각 120개의 복제본이 있는 360개의 샤드, 즉 120개의 서버가 있습니다. 그리고 샤딩 방식은 모든 요청이 한 번에 모든 샤드로 전달되는 방식입니다. 이제 Yandex.Metrica에서 avito.ru에 대한 보고서 페이지를 열면 요청이 120개의 서버로 이동합니다. RuNet에는 대규모 사이트가 거의 없습니다. 그리고 요청은 초당 XNUMX개가 아니라 XNUMX개 미만입니다. 이 모든 것은 각각 XNUMX개의 서버로 처리되는 분산 테이블에 의해 조용히 처리됩니다.

두 번째 클러스터는 소규모 사이트용입니다. 다음은 사이트 ID를 기반으로 한 샤딩 방식이며, 각 요청은 정확히 하나의 샤드로 이동합니다.

ClickHouse에는 클릭하우스 복사기 유틸리티가 있습니다. 그녀에 대해 말해 줄 수 있나요?

이 솔루션은 더 번거롭고 생산성도 다소 떨어진다고 바로 말씀드리겠습니다. 장점은 지정한 패턴에 따라 데이터가 완전히 번진다는 것입니다. 하지만 이 유틸리티의 단점은 전혀 재샤딩되지 않는다는 것입니다. 한 클러스터 스키마에서 다른 클러스터 스키마로 데이터를 복사합니다.

즉, 작동하려면 두 개의 클러스터가 있어야 합니다. 동일한 서버에 있을 수 있지만 그럼에도 불구하고 데이터는 증분 이동되지 않고 복사됩니다.

예를 들어 서버가 XNUMX개 있었는데 지금은 XNUMX개가 되었습니다. 모든 서버에 새 분산 테이블, 새 로컬 테이블을 만들고 clickhouse-copier를 실행하여 거기에서 읽어야 하는 작업 체계를 표시하고 새 샤딩 체계를 수락하고 그곳으로 데이터를 전송합니다. 그리고 오래된 서버에는 현재보다 XNUMX배 더 많은 공간이 필요합니다. 왜냐하면 오래된 데이터가 서버에 남아 있어야 하고 동일한 오래된 데이터의 절반이 서버 위에 도착하기 때문입니다. 데이터를 다시 샤딩해야 하고 공간이 있다고 미리 생각했다면 이 방법이 적합합니다.

clickhouse-copier는 내부에서 어떻게 작동합니까? 하나의 샤드에서 하나의 테이블의 하나의 파티션을 처리하기 위해 모든 작업을 일련의 작업으로 나눕니다. 이러한 모든 작업은 병렬로 실행될 수 있으며 clickhouse-copier는 여러 인스턴스의 다른 시스템에서 실행될 수 있지만 하나의 파티션에 대해 수행되는 작업은 삽입 선택에 지나지 않습니다. 데이터를 읽고, 압축을 풀고, 다시 파티션을 나눈 다음 다시 압축하고, 어딘가에 쓰고, 다시 정렬합니다. 이것은 더 어려운 결정입니다.

리샤딩이라는 파일럿 작업이 있었습니다. 그녀는 어쩌고?

2017년에는 리샤딩이라는 파일럿 작업이 있었습니다. ClickHouse에는 옵션도 있습니다. 내가 이해하는 한, 그것은 이륙하지 않았습니다. 왜 이런 일이 일어났는지 말해줄 수 있나요? 매우 관련성이 높은 것 같습니다.

전체적인 문제는 데이터를 제자리에 다시 샤딩해야 하는 경우 이를 원자적으로 수행하려면 매우 복잡한 동기화가 필요하다는 것입니다. 이 동기화가 어떻게 작동하는지 살펴보기 시작했을 때 근본적인 문제가 있다는 것이 분명해졌습니다. 그리고 이러한 근본적인 문제는 이론적일 뿐만 아니라 매우 간단하게 설명할 수 있는 형태로 실제로 실제로 나타나기 시작했습니다. 아무것도 작동하지 않습니다.

느린 디스크로 이동하기 전에 모든 데이터 조각을 병합할 수 있습니까?

병합의 맥락에서 느린 디스크로 이동 옵션이 ​​포함된 TTL에 대한 질문입니다. cron을 통하지 않고 모든 부분을 느린 디스크로 이동하기 전에 하나로 병합할 수 있는 방법이 있습니까?

질문에 대한 대답은 모든 조각을 전송하기 전에 자동으로 하나로 붙이는 것이 가능하다는 것입니다. 나는 이것이 필요하다고 생각하지 않습니다. 모든 부분을 하나로 병합할 필요는 없지만 자동으로 느린 디스크로 전송된다는 점만 고려하면 됩니다.

전송 규칙에는 두 가지 기준이 있습니다. 첫 번째는 채워진 그대로입니다. 현재 스토리지 계층의 여유 공간이 일정 비율 미만인 경우 하나의 청크를 선택하여 더 느린 스토리지로 이동합니다. 또는 오히려 느리지 않고 다음 속도로 구성합니다.

두 번째 기준은 크기입니다. 큰 조각을 옮기는 것입니다. 빠른 디스크의 여유 공간에 따라 임계값을 조정할 수 있으며 데이터가 자동으로 전송됩니다.

호환성을 미리 확인할 수 없는 경우 ClickHouse의 새 버전으로 마이그레이션하는 방법은 무엇입니까?

이 주제는 정기적으로 논의됩니다. ClickHouse 텔레그램 채팅에서 다른 버전을 고려하더라도 여전히 그렇습니다. 버전 19.11에서 19.16으로, 예를 들어 19.16에서 20.3으로 업그레이드하는 것이 얼마나 안전합니까? 샌드박스에서 미리 호환성을 확인할 수 없는 상태에서 새 버전으로 마이그레이션하는 가장 좋은 방법은 무엇입니까?

여기에는 몇 가지 "황금"규칙이 있습니다. 첫 번째 - 변경 로그를 읽어보세요. 규모가 크지만 이전 버전과 호환되지 않는 변경 사항에 대한 별도의 단락이 있습니다. 이러한 점을 위험 신호로 취급하지 마십시오. 이는 일반적으로 사용하지 않을 가능성이 높은 일부 엣지 기능과 관련된 사소한 비호환성입니다.

둘째, 샌드박스에서 호환성을 확인할 수 있는 방법이 없고 프로덕션에서 즉시 업데이트하려는 경우에는 이 작업을 수행할 필요가 없다는 것이 권장됩니다. 먼저 샌드박스를 만들고 테스트해 보세요. 테스트 환경이 없다면 대규모 회사가 아닐 가능성이 높습니다. 즉, 일부 데이터를 노트북에 복사하여 모든 것이 올바르게 작동하는지 확인할 수 있다는 의미입니다. 머신에서 로컬로 여러 복제본을 생성할 수도 있습니다. 또는 근처 어딘가에서 새 버전을 선택하고 거기에 일부 데이터를 업로드할 수 있습니다. 즉, 즉석에서 테스트 환경을 만들 수 있습니다.

또 다른 규칙은 프로덕션에서 버그를 잡아내고 그에 따른 빠른 수정을 위해 버전 출시 후 일주일 동안 업데이트하지 않는 것입니다. 혼동하지 않도록 ClickHouse 버전의 번호 매기기를 알아 보겠습니다.

버전 20.3.4가 있습니다. 숫자 20은 제조 연도 인 2020을 나타냅니다. 내부 내용의 관점에서 볼 때 이는 중요하지 않으므로주의를 기울이지 않겠습니다. 다음 - 20.3. 우리는 몇 가지 새로운 기능이 포함된 릴리스를 출시할 때마다 두 번째 숫자(이 경우 3)를 늘립니다. ClickHouse에 일부 기능을 추가하려면 이 숫자를 늘려야 합니다. 즉, 버전 20.4에서는 ClickHouse가 더욱 잘 작동합니다. 세 번째 숫자는 20.3.4입니다. 여기 4는 새로운 기능을 추가하지 않았지만 일부 버그를 수정한 패치 릴리스의 수입니다. 4는 XNUMX번을 했다는 의미입니다.

이것이 끔찍한 일이라고 생각하지 마십시오. 일반적으로 사용자는 최신 버전을 설치할 수 있으며 연간 가동 시간에 문제 없이 작동합니다. 그러나 중국 동지들이 추가한 비트맵 처리 기능 중 일부 기능에서 잘못된 인수를 전달하면 서버가 충돌한다고 상상해 보세요. 우리는 이 문제를 해결할 책임이 있습니다. 새로운 패치 버전을 출시할 예정이며 클릭하우스는 더욱 안정화될 예정입니다.

ClickHouse를 프로덕션 환경에서 실행 중이고 ClickHouse의 새 버전이 추가 기능과 함께 출시되는 경우(예: 20.4.1이 첫 번째 버전인 경우) 첫날부터 서둘러 프로덕션에 투입하지 마세요. 왜 필요한가요? ClickHouse를 아직 사용하지 않았다면 설치할 수 있으며 대부분 모든 것이 잘 될 것입니다. 하지만 ClickHouse가 이미 안정적으로 작동하고 있다면 패치와 업데이트를 계속 주시하여 어떤 문제를 해결하고 있는지 확인하세요.

키릴 슈바코프: 테스트 환경에 대해 조금 추가하고 싶습니다. 모든 사람은 테스트 환경을 매우 두려워하며 어떤 이유로 ClickHouse 클러스터가 매우 큰 경우 테스트 환경이 그보다 작거나 최소한 XNUMX배는 작아야 한다고 믿습니다. 전혀 그렇지 않습니다.

나는 내 자신의 예를 통해 당신에게 말할 수 있습니다. 프로젝트가 있고 ClickHouse가 있습니다. 우리의 테스트 환경은 그를 위한 것입니다. 이것은 절대적으로 모든 것이 배포되는 XNUMX유로의 Hetzner에 있는 작은 가상 머신입니다. 이를 위해 Ansible에서 완전 자동화를 수행하므로 원칙적으로 하드웨어 서버로 이동하거나 가상 머신에 배포하는 등 어디로 이동하든 차이가 없습니다.

무엇을 할 수 있나요? 집에 소규모 클러스터를 배포하는 방법에 대한 예를 ClickHouse 문서에 제공하는 것이 좋을 것입니다. Docker, LXC에서 아마도 Ansible 플레이북을 생성할 수 있습니다. 왜냐하면 사람마다 배포가 다르기 때문입니다. 그러면 많이 단순화될 것입니다. XNUMX분 안에 클러스터를 가져와 배포하면 뭔가를 알아내기가 훨씬 쉬워집니다. 테스트하지 않은 프로덕션 버전으로 전환하는 것은 아무데도 가지 않기 때문에 훨씬 더 편리합니다. 때로는 작동하고 때로는 작동하지 않습니다. 그러므로 성공을 바라는 것은 나쁘다.

Maxim Kotyakov, 선임 백엔드 엔지니어 Avito: 대기업이 직면한 일련의 문제 중에서 테스트 환경에 대해 조금 추가하겠습니다. 우리는 본격적인 ClickHouse 수용 클러스터를 보유하고 있으며, 데이터 체계 및 설정 측면에서 이는 생산 중인 것과 정확히 동일한 복사본입니다. 이 클러스터는 최소한의 리소스를 사용하여 상당히 낡은 컨테이너에 배포됩니다. 우리는 여기에 프로덕션 데이터의 일정 비율을 기록합니다. 다행히 Kafka에서 스트림을 복제하는 것이 가능합니다. 용량과 흐름 측면에서 모든 것이 동기화되고 확장되며 이론적으로 다른 모든 것이 동일하다면 측정 항목 측면에서 생산처럼 작동해야 합니다. 폭발 가능성이 있는 모든 물질은 먼저 이 스탠드에 굴려 준비될 때까지 며칠 동안 방치됩니다. 그러나 당연히 이 솔루션은 비용이 많이 들고 어렵고 지원 비용이 XNUMX이 아닙니다.

알렉세이 밀로비도프: Yandex.Metrica 친구들의 테스트 환경이 어떤지 알려드리겠습니다. 한 클러스터에는 600여 개의 서버가 있고, 다른 클러스터에는 360개가 있으며, 세 번째 클러스터와 여러 클러스터가 있습니다. 그 중 하나에 대한 테스트 환경은 각각 XNUMX개의 복제본이 있는 XNUMX개의 샤드입니다. 왜 샤드가 두 개인가요? 그래서 당신은 혼자가 아닙니다. 그리고 복제본도 있어야 합니다. 감당할 수 있는 최소한의 금액만 있으면 됩니다.

이 테스트 환경을 사용하면 쿼리가 작동하는지, 주요 내용이 손상되었는지 확인할 수 있습니다. 그러나 모든 것이 작동하지만 부하에 약간의 변화가 있을 때 완전히 다른 성격의 문제가 발생하는 경우가 많습니다.

예를 들어 보겠습니다. 우리는 ClickHouse의 새 버전을 설치하기로 결정했습니다. 테스트 환경에 게시되었으며 Yandex.Metrica 자체에서 자동화된 테스트가 완료되어 전체 파이프라인을 실행하면서 이전 버전과 새 버전의 데이터를 비교합니다. 물론 CI에 대한 친환경 테스트도 진행됩니다. 그렇지 않았다면 우리는 이 버전을 제안하지도 않았을 것입니다.

모든 것이 괜찮습니다. 우리는 생산에 들어가기 시작했습니다. 그래프의 로드가 여러 번 증가했다는 메시지를 받았습니다. 버전을 롤백하는 중입니다. 그래프를 보면 실제로 로드가 롤아웃 중에 여러 번 증가했다가 롤아웃할 때 다시 감소했습니다. 그런 다음 버전 롤백을 시작했습니다. 그리고 부하는 같은 방식으로 증가하고 같은 방식으로 감소했습니다. 따라서 결론은 다음과 같습니다. 레이아웃으로 인해 부하가 증가한 것은 놀라운 일이 아닙니다.

그런 다음 동료들에게 새 버전을 설치하도록 설득하는 것이 어려웠습니다. 나는 이렇게 말합니다. “괜찮습니다. 출시하세요. 손가락을 계속 교차시키면 모든 것이 작동할 것입니다. 이제 그래프의 부하가 증가했지만 모든 것이 정상입니다. 거기 참으세요." 일반적으로 우리는 이것을 수행했고 그게 전부입니다. 버전이 생산용으로 출시되었습니다. 그러나 거의 모든 레이아웃에서 비슷한 문제가 발생합니다.

쿼리 종료는 쿼리를 종료해야 하지만 그렇지 않습니다. 왜?

일종의 분석가인 사용자가 나에게 와서 내 ClickHouse 클러스터를 배치하는 요청을 생성했습니다. 요청이 전달된 복제본 또는 샤드에 따라 일부 노드 또는 전체 클러스터. 이 서버의 모든 CPU 리소스가 선반에 있고 모든 것이 빨간색으로 표시되어 있습니다. 동시에 ClickHouse 자체가 요청에 응답합니다. 그리고 저는 이렇게 썼습니다. "어떤 요청이 이런 광기를 일으켰는지 프로세스 목록을 보여주세요."

나는 이 요청을 찾아 거기에 kill을 씁니다. 그리고 나는 아무 일도 일어나지 않는다는 것을 알았습니다. 내 서버는 선반에 있고 ClickHouse는 나에게 몇 가지 명령을 제공하고 서버가 살아 있음을 보여주며 모든 것이 훌륭합니다. 하지만 모든 사용자 요청이 저하되고 ClickHouse의 레코드부터 저하가 시작되며 종료 쿼리가 작동하지 않습니다. 왜? 나는 kill query가 쿼리를 죽이기로 되어 있다고 생각했지만 그렇지 않습니다.

이제 다소 이상한 대답이 나올 것입니다. 요점은 쿼리 종료가 쿼리를 종료하지 않는다는 것입니다.

Kill 쿼리는 "이 쿼리를 종료하고 싶습니다."라는 작은 상자를 선택합니다. 그리고 요청 자체는 각 블록을 처리할 때 이 플래그를 확인합니다. 설정된 경우 요청 작동이 중지됩니다. 아무도 요청을 죽이지 않으며 모든 것을 확인하고 중지해야한다는 것이 밝혀졌습니다. 그리고 이는 요청이 데이터 블록을 처리하는 상태인 모든 경우에 작동합니다. 다음 데이터 블록을 처리하고 플래그를 확인한 후 중지합니다.

일부 작업에서 요청이 차단된 경우에는 작동하지 않습니다. 사실, 귀하에 따르면 이는 엄청난 양의 서버 리소스를 사용하기 때문에 귀하의 경우가 아닐 가능성이 높습니다. 외부 정렬 및 일부 기타 세부사항에서는 이것이 작동하지 않을 수도 있습니다. 그러나 일반적으로 이런 일은 발생해서는 안 됩니다. 이는 버그입니다. 그리고 제가 추천할 수 있는 유일한 것은 ClickHouse를 업데이트하는 것입니다.

읽기 부하 시 응답 시간을 계산하는 방법은 무엇입니까?

항목 집계(다양한 카운터)를 저장하는 테이블이 있습니다. 줄 수는 약 1억 개입니다. 1개의 항목에 XNUMX개의 RPS를 쏟아부으면 예측 가능한 응답 시간을 기대할 수 있습니까?

문맥에 따라 쓰기에 문제가 없기 때문에 읽기 부하에 대해 이야기하고 있습니다. 심지어 천, 심지어 십만, 때로는 수백만 행을 삽입할 수도 있습니다.

읽기 요청은 매우 다릅니다. 선택 1에서 ClickHouse는 초당 약 수만 건의 요청을 수행할 수 있으므로 하나의 키에 대한 요청에도 이미 일부 리소스가 필요합니다. 그리고 이러한 포인트 쿼리는 읽기마다 인덱스별로 데이터 블록을 읽어야 하기 때문에 일부 키-값 데이터베이스보다 더 어렵습니다. 우리의 색인은 각 레코드가 아니라 각 범위를 다룹니다. 즉, 전체 범위를 읽어야 합니다. 이는 기본적으로 8192줄입니다. 그리고 압축된 데이터 블록을 64KB에서 1MB로 압축을 풀어야 합니다. 일반적으로 이러한 대상 쿼리는 완료하는 데 몇 밀리초가 걸립니다. 그러나 이것은 가장 간단한 옵션입니다.

간단한 산수를 시도해 봅시다. 몇 밀리초에 1000을 곱하면 몇 초가 됩니다. 초당 수천 개의 요청을 처리하는 것이 불가능한 것처럼 보이지만 실제로는 여러 개의 프로세서 코어가 있기 때문에 가능합니다. 따라서 원칙적으로 ClickHouse는 때때로 XNUMX RPS를 보유할 수 있지만 짧은 요청, 특히 대상이 지정된 요청의 경우에는 가능합니다.

단순 요청 수에 따라 ClickHouse 클러스터를 확장해야 하는 경우 가장 간단한 방법을 권장합니다. 즉, 복제본 수를 늘리고 요청을 무작위 복제본으로 보내는 것입니다. 하나의 복제본이 초당 XNUMX개의 요청을 처리하는 경우(완전히 현실적임), XNUMX개의 복제본은 XNUMX개를 처리합니다.

물론 때로는 최대 포인트 판독 수에 맞게 ClickHouse를 구성할 수도 있습니다. 이를 위해 무엇이 필요합니까? 첫 번째는 인덱스의 세분성을 줄이는 것입니다. 이 경우 64개로 줄여서는 안 되며, 서버당 인덱스 항목 수가 수백만 또는 수천만 개가 된다는 점을 기준으로 해야 합니다. 테이블에 XNUMX억 개의 행이 있는 경우 세분성을 XNUMX로 설정할 수 있습니다.

압축된 블록의 크기를 줄일 수 있습니다. 이에 대한 설정이 있습니다 최소 압축 블록 크기, 최대 압축 블록 크기. 이를 줄이고 데이터로 다시 채울 수 있으며 그러면 대상 쿼리가 더 빨라집니다. 하지만 여전히 ClickHouse는 키-값 데이터베이스가 아닙니다. 작은 요청이 많이 발생하는 것은 로드 방지 패턴입니다.

키릴 슈바코프: 거기에 일반 계정이 있으면 조언을 드리겠습니다. ClickHouse가 일종의 카운터를 저장할 때 이는 상당히 표준적인 상황입니다. 나는 사용자가 있는데, 그는 이러저러한 나라 출신이고, 세 번째 분야에서 왔으며, 점진적으로 무언가를 늘려야 합니다. MySQL을 사용하여 고유 키를 만드십시오. MySQL에서는 중복 키이고 PostgreSQL에서는 충돌입니다. 그리고 더하기 기호를 추가하십시오. 이것은 훨씬 더 잘 작동할 것입니다.

데이터가 많지 않으면 ClickHouse를 사용해도 별 의미가 없습니다. 일반 데이터베이스가 있으며 이를 잘 수행합니다.

더 많은 데이터가 캐시에 저장되도록 ClickHouse에서 무엇을 조정할 수 있나요?

상황을 상상해 봅시다. 서버에는 256GB의 RAM이 있고 일상적으로 ClickHouse는 최대 60GB까지 약 80-130GB를 사용합니다. 캐시에 더 많은 데이터가 있도록 활성화하고 조정할 수 있는 항목은 다음과 같습니다. 디스크로의 이동 횟수가 적습니까?

일반적으로 운영 체제의 페이지 캐시가 이 작업을 잘 수행합니다. 상단을 열면 캐시됨 또는 사용 가능 여부가 표시됩니다. 또한 캐시된 양도 표시됩니다. 그러면 사용 가능한 모든 메모리가 캐시에 사용되는 것을 알 수 있습니다. 그리고 이 데이터를 읽을 때 디스크가 아니라 RAM에서 읽혀집니다. 동시에, 캐시되는 압축된 데이터이기 때문에 캐시가 효과적으로 사용된다고 할 수 있습니다.

그러나 일부 간단한 쿼리의 속도를 더욱 높이고 싶다면 ClickHouse 내부의 압축이 풀린 데이터에 캐시를 활성화할 수 있습니다. 그것은이라고 압축되지 않은 캐시. config.xml 구성 파일에서 압축되지 않은 캐시 크기를 필요한 값으로 설정합니다. 나머지는 페이지 캐시 아래에 저장되므로 여유 RAM의 절반 이하를 권장합니다.

또한 두 가지 요청 수준 설정이 있습니다. 첫 번째 설정 - 압축되지 않은 캐시 사용 - 그 사용이 포함됩니다. 모든 데이터를 읽고 캐시를 플러시할 수 있는 과도한 요청을 제외한 모든 요청에 ​​대해 활성화하는 것이 좋습니다. 그리고 두 번째 설정은 캐시를 사용할 최대 라인 수와 같은 것입니다. 캐시를 우회하도록 대규모 쿼리를 자동으로 제한합니다.

RAM에 저장하기 위해 Storage_configuration을 어떻게 구성합니까?

새로운 ClickHouse 문서에서 관련 섹션을 읽었습니다. 데이터 저장 장치가 있는. 설명에는 빠른 SSD의 예가 포함되어 있습니다.

볼륨 핫 메모리로 동일한 것을 어떻게 구성할 수 있는지 궁금합니다. 그리고 질문 하나 더. Select는 이 데이터 구성에서 어떻게 작동합니까? 전체 세트를 읽습니까, 아니면 디스크에 있는 세트만 읽습니까? 이 데이터는 메모리에 압축되어 있습니까? 그리고 이러한 데이터 조직에서 사전 위치 섹션은 어떻게 작동합니까?

이 설정은 데이터 청크의 저장에 영향을 미치며 해당 형식은 어떤 식으로든 변경되지 않습니다.
좀 더 자세히 살펴보겠습니다.

RAM에 데이터 저장소를 구성할 수 있습니다. 디스크에 대해 구성된 것은 경로뿐입니다. 파일 시스템의 일부 경로에 마운트되는 tmpfs 파티션을 만듭니다. 이 경로를 가장 인기 있는 파티션의 데이터를 저장하기 위한 경로로 지정하면 데이터 조각이 도착하여 거기에 기록되기 시작합니다. 모든 것이 정상입니다.

하지만 안정성이 낮기 때문에 이 작업을 권장하지 않습니다. 하지만 서로 다른 데이터 센터에 복제본이 XNUMX개 이상 있으면 가능합니다. 어떤 일이 발생하면 데이터가 복원됩니다. 갑자기 서버가 꺼졌다가 다시 켜졌다고 가정해 보겠습니다. 파티션을 다시 마운트했지만 거기에는 아무것도 없었습니다. ClickHouse 서버가 시작되면 ZooKeeper 메타데이터에 따르면 이러한 부분이 있어야 하지만 이러한 부분이 없음을 확인합니다. 그는 어떤 복제본에 해당 항목이 있는지 확인하고 요청하고 다운로드합니다. 이렇게 하면 데이터가 복원됩니다.

이러한 의미에서 RAM에 데이터를 저장하는 것은 디스크에 데이터를 저장하는 것과 근본적으로 다르지 않습니다. 왜냐하면 데이터가 디스크에 기록되면 먼저 페이지 캐시에 저장되고 물리적으로 나중에 기록되기 때문입니다. 이는 파일 시스템 마운트 옵션에 따라 다릅니다. 하지만 만일을 대비해 ClickHouse는 삽입 시 fsync를 수행하지 않는다고 말씀드리겠습니다.

이 경우 RAM의 데이터는 디스크와 정확히 동일한 형식으로 저장됩니다. 같은 방식으로 선택 쿼리는 읽어야 할 조각을 선택하고 조각에서 필요한 데이터 범위를 선택하여 읽습니다. 그리고 데이터가 RAM에 있든 디스크에 있든 상관없이 prewhere는 정확히 동일하게 작동합니다.

낮은 카디널리티는 몇 개의 고유 값까지 유효합니까?

낮은 카디널리티는 영리하게 설계되었습니다. 데이터 사전을 컴파일하지만 로컬입니다. 첫째, 각 작품마다 다른 사전이 있고, 둘째, 한 작품 내에서도 각 범위마다 다를 수 있습니다. 고유한 값의 수가 임계값(XNUMX만 개)에 도달하면 사전은 단순히 보류되고 새 사전이 생성됩니다.

대답은 일반적으로 다음과 같습니다. 각 지역 범위(예: 매일)에 대해 최대 백만 개의 고유 값에 대해 낮은 카디널리티가 효과적입니다. 그 후에는 단지 하나가 아닌 다양한 사전이 사용되는 단순한 대체가 있을 것입니다. 일반 문자열 열과 거의 동일하게 작동하며 약간 덜 효율적일 수도 있지만 심각한 성능 저하가 없습니다.

XNUMX억 행이 있는 테이블에서 전체 텍스트를 검색하는 모범 사례는 무엇입니까?

다른 대답이 있습니다. 첫 번째는 ClickHouse가 전체 텍스트 검색 엔진이 아니라는 점입니다. 이를 위한 특별한 시스템이 있습니다. 예를 들어, 탄성 검색 и 스핑크스. 하지만 Elasticsearch에서 ClickHouse로 전환하고 있다고 말하는 사람들이 점점 늘어나고 있습니다.

왜 이런 일이 발생합니까? 그들은 Elasticsearch가 인덱스 구성부터 시작하여 일부 볼륨의 로드 처리를 중단한다는 사실로 이를 설명합니다. 인덱스가 너무 번거로워지고 단순히 데이터를 ClickHouse로 전송하면 용량 측면에서 몇 배 더 효율적으로 저장되는 것으로 나타났습니다. 동시에, 검색어는 형태를 고려하여 전체 데이터 양에서 일부 문구를 찾아야 할 정도가 아니었지만 완전히 다른 문구를 찾는 경우가 많았습니다. 예를 들어 지난 몇 시간 동안의 로그에서 일부 바이트 시퀀스를 찾습니다.

이 경우 ClickHouse에 인덱스를 생성합니다. 인덱스의 첫 번째 필드는 날짜와 시간이 됩니다. 그리고 가장 큰 데이터 컷오프는 기간을 기준으로 합니다. 선택한 날짜 범위 내에서는 일반적으로 like를 사용하는 무차별 방식을 사용하더라도 전체 텍스트 검색을 수행하는 것이 이미 가능합니다. ClickHouse의 좋아요 연산자는 찾을 수 있는 가장 효율적인 유사 연산자입니다. 더 좋은 거 찾으면 말해주세요.

하지만 여전히 전체 스캔과 같습니다. 그리고 전체 스캔은 CPU뿐만 아니라 디스크에서도 느려질 수 있습니다. 갑자기 하루에 XNUMX테라바이트의 데이터가 생겨서 하루 동안 단어를 검색하면 테라바이트를 스캔해야 합니다. 그리고 아마도 일반 하드 드라이브에 있을 것이며 결국에는 SSH를 통해 이 서버에 액세스할 수 없는 방식으로 로드될 것입니다.

이 경우에는 작은 트릭을 하나 더 제공할 준비가 되었습니다. 실험적이므로 작동할 수도 있고 그렇지 않을 수도 있습니다. ClickHouse에는 트라이그램 블룸 필터 형태의 전체 텍스트 색인이 있습니다. Arenadata의 동료들은 이미 이러한 인덱스를 사용해 보았고 의도한 대로 정확하게 작동하는 경우가 많습니다.

이를 올바르게 사용하려면 작동 방식, 즉 트라이그램 블룸 필터가 무엇인지, 크기를 선택하는 방법을 잘 이해해야 합니다. 데이터에서 거의 발견되지 않는 일부 희귀한 문구, 하위 문자열에 대한 쿼리에 도움이 될 것이라고 말할 수 있습니다. 이 경우 하위 범위는 인덱스에 의해 선택되며 더 적은 양의 데이터가 읽혀집니다.

최근 ClickHouse에는 전체 텍스트 검색을 위한 더욱 향상된 기능이 추가되었습니다. 이는 첫째, UTF-8 또는 ASCII만 지원하는 대/소문자 구분 옵션을 포함하여 한 번에 여러 하위 문자열을 검색하는 것입니다. 필요한 가장 효과적인 것을 선택하십시오.

한 번에 여러 정규식을 검색하는 기능도 나타났습니다. X를 하나의 하위 문자열처럼 쓰거나 X를 다른 하위 문자열처럼 쓸 필요는 없습니다. 즉시 작성하면 모든 것이 최대한 효율적으로 완료됩니다.

셋째, 이제 정규식에 대한 대략적인 검색과 하위 문자열에 대한 대략적인 검색이 가능합니다. 누군가 단어 철자를 잘못 입력한 경우 최대 일치 항목을 검색합니다.

다수의 사용자를 위해 ClickHouse에 대한 액세스를 구성하는 가장 좋은 방법은 무엇입니까?

다수의 소비자와 분석가를 위한 액세스를 구성하는 최선의 방법을 알려주십시오. 대기열을 형성하고, 최대 동시 쿼리의 우선순위를 지정하는 방법과 어떤 도구를 사용합니까?

클러스터가 충분히 크다면 좋은 해결책은 분석가의 진입점이 될 서버를 두 대 더 늘리는 것입니다. 즉, 분석가가 클러스터의 특정 샤드에 액세스하는 것을 허용하지 않고, 데이터 없이 두 개의 빈 서버를 생성하고 이에 대한 액세스 권한을 구성하면 됩니다. 이 경우 분산 요청에 대한 사용자 설정이 원격 서버로 전송됩니다. 즉, 이 두 서버의 모든 것을 구성하면 해당 설정이 전체 클러스터에 영향을 미칩니다.

원칙적으로 이러한 서버에는 데이터가 없지만 RAM 용량은 요청을 실행하는 데 매우 중요합니다. 외부 집계 또는 외부 정렬이 활성화된 경우 디스크는 임시 데이터에도 사용될 수 있습니다.

가능한 모든 제한과 관련된 설정을 살펴보는 것이 중요합니다. 이제 분석가로서 Yandex.Metrica 클러스터로 이동하여 요청을 하면 조회수에서 개수 선택, 그러면 요청을 실행할 수 없다는 예외가 즉시 제공됩니다. 스캔할 수 있는 최대 행 수는 XNUMX억 개이며 클러스터의 한 테이블에는 총 XNUMX조 개의 행이 있습니다. 이것이 첫 번째 제한 사항입니다.

행 제한을 제거하고 쿼리를 다시 실행한다고 가정해 보겠습니다. 그러면 다음 예외가 표시됩니다. 설정이 활성화되었습니다. 날짜별 강제 인덱스. 날짜 범위를 지정하지 않으면 쿼리를 완료할 수 없습니다. 수동으로 지정하기 위해 분석가에게 의존할 필요가 없습니다. 일반적인 경우는 이벤트 날짜가 주 사이에 날짜 범위가 기록되는 경우입니다. 그리고 그들은 단순히 잘못된 위치에 대괄호를 지정했고 그 대신에 또는 - 또는 URL 일치로 판명되었습니다. 제한이 없으면 URL 열을 크롤링하여 엄청난 양의 리소스를 낭비하게 됩니다.

또한 ClickHouse에는 두 가지 우선순위 설정이 있습니다. 불행히도 그들은 매우 원시적입니다. 하나는 간단히 호출됩니다. 우선. 우선순위 ≠ 0이고 어떤 우선순위가 있는 요청이 실행되고 있지만 우선순위 값이 더 높은 요청이 실행되고 있는 경우 우선순위 값이 더 크므로 우선순위가 낮은 요청이 실행됩니다. , 단순히 일시 중지되었으며 이 시간 동안에는 전혀 작동하지 않습니다.

이는 매우 조잡한 설정이므로 클러스터의 로드가 일정한 경우에는 적합하지 않습니다. 그러나 짧고 폭주하는 중요한 요청이 있고 클러스터가 대부분 유휴 상태인 경우 이 설정이 적합합니다.

다음 우선순위 설정이 호출됩니다. OS 스레드 우선순위. Linux 스케줄러의 모든 요청 실행 스레드에 대해 좋은 값을 설정하기만 하면 됩니다. 그것은 그렇게 작동하지만 여전히 작동합니다. 최소 nice 값(값이 가장 크므로 우선순위가 가장 낮음)을 설정하고 우선순위가 높은 요청에 대해 -19를 설정하면 CPU는 우선순위가 높은 요청보다 낮은 우선순위 요청을 약 XNUMX배 적게 소비합니다.

또한 최대 요청 실행 시간(예: XNUMX분)을 구성해야 합니다. 쿼리 실행의 최소 속도가 가장 좋습니다. 이 설정은 오랫동안 사용되어 왔으며 ClickHouse가 느려지지 않는다고 주장할 뿐만 아니라 강제로 실행해야 합니다.

상상해 보십시오. 일부 쿼리가 초당 XNUMX만 행 미만을 처리하는 경우에는 그렇게 할 수 없습니다. 이는 우리의 좋은 이름과 좋은 데이터베이스를 불명예스럽게 만듭니다. 이것만 금지하자. 실제로 두 가지 설정이 있습니다. 하나는 최소 실행 속도 - 초당 라인 수, 초는 최소 실행 속도를 확인하기 전 시간 초과라고 합니다. 기본적으로 XNUMX초입니다. 즉, XNUMX초가 가능하며, 느리다면 예외를 발생시키고 요청을 중단하면 됩니다.

할당량도 설정해야 합니다. ClickHouse에는 리소스 소비를 계산하는 할당량 기능이 내장되어 있습니다. 그러나 불행히도 CPU, 디스크와 같은 하드웨어 리소스가 아니라 논리적 리소스, 즉 처리된 요청 수, 읽은 라인 및 바이트 수입니다. 예를 들어 XNUMX분 내에 최대 XNUMX개의 요청과 시간당 XNUMX개의 요청을 구성할 수 있습니다.

왜 중요 함? 일부 분석 쿼리는 ClickHouse 클라이언트에서 직접 수동으로 수행되기 때문입니다. 그리고 모든 것이 잘 될 것입니다. 하지만 회사에 고급 분석가가 있다면 그들이 스크립트를 작성하게 되는데, 스크립트에 오류가 있을 수 있습니다. 그리고 이 오류로 인해 요청이 무한 루프로 실행됩니다. 이것이 바로 우리가 우리 자신을 보호해야 하는 것입니다.

하나의 쿼리 결과를 XNUMX명의 클라이언트에게 제공하는 것이 가능합니까?

같은 시점에 매우 큰 요청을 받기를 원하는 여러 사용자가 있습니다. 요청이 크고 원칙적으로 신속하게 실행되지만 동시에 요청이 많기 때문에 매우 고통스럽습니다. XNUMX번 연속으로 도착한 동일한 요청을 한 번 실행하고 그 결과를 XNUMX명의 클라이언트에게 제공하는 것이 가능합니까?

문제는 중간 데이터의 캐시나 캐시 결과가 없다는 점입니다. 운영 체제의 페이지 캐시가 있어 디스크에서 데이터를 다시 읽을 수 없지만 안타깝게도 데이터는 여전히 압축 해제, 역직렬화 및 재처리됩니다.

중간 데이터를 캐싱하거나 일종의 대기열에 유사한 쿼리를 정렬하고 결과 캐시를 추가하여 이를 방지하고 싶습니다. 현재 요청 캐시를 추가하는 하나의 풀 요청이 개발 중에 있지만 in 및 Join 섹션의 하위 쿼리에만 해당됩니다. 즉, 솔루션이 불완전합니다.

그러나 우리도 그런 상황에 직면해 있습니다. 특히 표준적인 예는 페이지를 매긴 쿼리입니다. 보고서가 있고 여러 페이지로 구성되어 있으며 10을 제한하라는 요청이 있습니다. 그러면 동일한 것이지만 10,10을 제한합니다. 그런 다음 또 다른 다음 페이지. 문제는 왜 우리가 매번 이 모든 것을 계산하는가 하는 것입니다. 하지만 이제는 해결책도 없고, 피할 방법도 없습니다.

ClickHouse 옆에 사이드카로 배치되는 대체 솔루션이 있습니다. 클릭하우스 프록시.

키릴 슈바코프: ClickHouse Proxy에는 속도 제한기와 결과 캐시가 내장되어 있습니다. 비슷한 문제가 해결되고 있었기 때문에 많은 설정이 이루어졌습니다. 프록시를 사용하면 요청을 대기열에 추가하여 요청을 제한하고 요청 캐시가 유지되는 기간을 구성할 수 있습니다. 요청이 실제로 동일한 경우 Proxy는 요청을 여러 번 보내지만 ClickHouse에는 한 번만 이동합니다.

Nginx에는 무료 버전에도 캐시가 있으며 이것도 작동합니다. Nginx에는 요청이 동시에 도착하면 요청이 완료될 때까지 다른 요청의 속도를 늦추는 설정도 있습니다. 그러나 ClickHouse Proxy에서는 설정이 훨씬 더 잘 수행됩니다. 이는 특히 ClickHouse를 위해, 특히 이러한 요청을 위해 제작되었으므로 더 적합합니다. 음, 설치가 쉽습니다.

비동기 작업과 구체화된 뷰는 어떻습니까?

재생 엔진 작업이 비동기식이라는 문제가 있습니다. 먼저 데이터가 기록된 다음 축소됩니다. 일부 집계가 포함된 구체화된 태블릿이 기호 아래에 있는 경우 복제본이 해당 기호에 기록됩니다. 그리고 복잡한 논리가 없으면 데이터가 중복됩니다. 이에 대해 무엇을 할 수 있나요?

분명한 해결책이 있습니다. 즉, 비동기식 축소 작업 중에 특정 클래스의 matview에 대한 트리거를 구현하는 것입니다. 비슷한 기능을 구현할 묘책이나 계획이 있나요?

중복 제거가 어떻게 작동하는지 이해하는 것은 가치가 있습니다. 지금 말씀드릴 내용은 질문과 관련이 없지만, 기억해 둘 만한 경우를 대비해서 말씀드리겠습니다.

복제된 테이블에 삽입하면 삽입된 전체 블록에 대한 중복 제거가 수행됩니다. 동일한 수의 동일한 행이 포함된 동일한 블록을 동일한 순서로 다시 삽입하면 데이터가 중복 제거됩니다. 삽입에 대한 응답으로 "Ok"를 받게 되지만 실제로는 하나의 데이터 패킷이 기록되며 중복되지 않습니다.

이는 확실성을 위해 필요합니다. 삽입 중에 "확인"이 표시되면 데이터가 삽입된 것입니다. ClickHouse에서 오류가 발생하면 삽입되지 않았으므로 삽입을 반복해야 함을 의미합니다. 하지만 삽입 도중 연결이 끊어지면 데이터가 삽입되었는지 여부를 알 수 없습니다. 유일한 옵션은 삽입을 다시 반복하는 것입니다. 데이터가 실제로 삽입되었다가 다시 삽입된 경우 블록 중복 제거가 수행됩니다. 이는 중복을 방지하는 데 필요합니다.

또한 구체화된 뷰에서 작동하는 방식도 중요합니다. 데이터가 기본 테이블에 삽입될 때 중복 제거된 경우 구체화된 뷰에도 들어가지 않습니다.

이제 질문에 대해. 개별 라인의 중복을 녹음하기 때문에 상황이 더 복잡합니다. 즉, 전체 팩이 복제되는 것이 아니라 특정 라인이 복제되며 백그라운드에서 붕괴됩니다. 실제로 데이터는 기본 테이블에서 축소되지만 축소되지 않은 데이터는 구체화된 뷰로 이동하며 병합 중에 구체화된 뷰에는 아무 일도 일어나지 않습니다. 구체화된 뷰는 삽입 트리거에 지나지 않기 때문입니다. 다른 작업 중에는 추가 작업이 발생하지 않습니다.

그리고 여기서는 당신을 행복하게 해줄 수 없어요. 이 경우에 대한 구체적인 해결책을 찾으면 됩니다. 예를 들어 구체화된 뷰에서 재생할 수 있으며 중복 제거 방법도 동일한 방식으로 작동할 수 있습니다. 그러나 불행히도 항상 그런 것은 아닙니다. 집계하는 경우에는 작동하지 않습니다.

키릴 슈바코프: 옛날에는 목발 공사도 했어요. 광고 노출수가 있다는 문제가 있었는데, 실시간으로 보여드릴 수 있는 데이터도 있는데, 이건 그냥 노출수일 뿐입니다. 중복되는 경우는 거의 없지만, 이런 일이 발생하면 어쨌든 나중에 축소할 것입니다. 그리고 복제할 수 없는 것들이 있었습니다. 클릭 수와 이 모든 이야기가 그랬습니다. 하지만 나는 또한 거의 즉시 보여주고 싶었습니다.

구체화된 뷰는 어떻게 만들어졌나요? 직접 작성된 뷰가 있었습니다. 즉, 원시 데이터에 기록되고 뷰에 기록되었습니다. 어떤 시점에서는 데이터가 정확하지 않거나 중복되는 등의 현상이 발생합니다. 그리고 테이블의 두 번째 부분이 있는데, 여기서는 구체화된 뷰와 완전히 동일하게 보입니다. 즉, 구조가 완전히 동일합니다. 때때로 우리는 데이터를 다시 계산하고, 중복 없이 데이터를 계산하고, 해당 테이블에 씁니다.

우리는 API를 살펴봤습니다. 이는 ClickHouse에서 수동으로 작동하지 않습니다. 그리고 API는 다음과 같습니다. 테이블에 마지막으로 추가된 날짜가 있을 때 올바른 데이터가 이미 계산되었음을 보장하고 한 테이블과 다른 테이블에 요청합니다. 하나의 요청에서는 특정 시간까지 선택하고 다른 하나에서는 아직 계산되지 않은 시간을 가져옵니다. 그리고 그것은 작동하지만 ClickHouse만으로는 작동하지 않습니다.

분석가용, 사용자용 등 일종의 API가 있는 경우 원칙적으로 이는 옵션입니다. 당신은 항상 세고 있고, 항상 세고 있습니다. 이 작업은 하루에 한 번 또는 다른 시간에 수행할 수 있습니다. 필요하지 않고 중요하지 않은 범위를 스스로 선택합니다.

ClickHouse에는 많은 로그가 있습니다. 서버에 일어나는 모든 일을 한 눈에 어떻게 볼 수 있나요?

ClickHouse에는 매우 많은 수의 다양한 로그가 있으며 이 숫자는 점점 늘어나고 있습니다. 새 버전에서는 일부 기능이 기본적으로 활성화되어 있으며, 이전 버전에서는 업데이트할 때 활성화해야 합니다. 그러나 그 수가 점점 더 많아지고 있습니다. 궁극적으로, 일종의 요약 대시보드를 통해 현재 내 서버에서 무슨 일이 일어나고 있는지 확인하고 싶습니다.

이러한 로그를 완제품으로 표시하는 기성 대시보드의 일부 기능을 지원하는 ClickHouse 팀 또는 친구의 팀이 있습니까? 궁극적으로 ClickHouse에서 로그를 보는 것만으로도 좋습니다. 하지만 이미 대시보드 형태로 준비되어 있다면 정말 멋질 것 같습니다. 나는 이것에서 킥을 얻을 것입니다.

표준화되지는 않았지만 대시보드가 ​​있습니다. 우리 회사에서는 약 60개 팀이 ClickHouse를 사용하고 있는데, 가장 이상한 점은 그들 중 많은 팀이 스스로 만든 대시보드를 가지고 있고 약간씩 다른 대시보드를 가지고 있다는 것입니다. 일부 팀은 내부 Yandex.Cloud 설치를 사용합니다. 필요한 보고서는 아니지만 일부 기성 보고서가 있습니다. 다른 사람들은 자신의 것을 가지고 있습니다.

Metrica의 동료들은 Grafana에 자체 대시보드를 갖고 있고 저는 그들의 클러스터를 위한 자체 대시보드를 가지고 있습니다. 나는 serif 캐시에 대한 캐시 적중과 같은 것을 보고 있습니다. 그리고 더욱 어려운 점은 우리가 다른 도구를 사용한다는 것입니다. 저는 Graphite-web이라는 아주 오래된 도구를 사용하여 대시보드를 만들었습니다. 그는 완전히 못 생겼습니다. Grafana가 아마도 더 편리하고 아름다울 것 같지만 저는 여전히 이 방식을 사용하고 있습니다.

대시보드의 기본 사항은 동일합니다. 클러스터에 대한 시스템 측정항목은 CPU, 메모리, 디스크, 네트워크입니다. 기타 - 동시 요청 수, 동시 병합 수, 초당 요청 수, MergeTree 테이블 파티션의 최대 청크 수, 복제 지연, 복제 대기열 크기, 초당 삽입된 행 수, 초당 삽입된 블록 수. 이는 로그가 아닌 메트릭에서 얻은 전부입니다.

블라디미르 콜로바예프: Alexey, 조금 수정하고 싶습니다. 그라파나가 있습니다. Grafana에는 ClickHouse라는 데이터 소스가 있습니다. 즉, Grafana에서 ClickHouse로 직접 요청할 수 있습니다. ClickHouse에는 로그가 포함된 테이블이 있으며 이는 모든 사람에게 동일합니다. 결과적으로 Grafana에서 이 로그 테이블에 액세스하여 내 서버가 보내는 요청을 확인하고 싶습니다. 이런 대시보드가 ​​있으면 정말 좋을 것 같아요.

제가 직접 자전거를 탔어요. 하지만 질문이 있습니다. 모든 것이 표준화되어 있고 모든 사람이 Grafana를 사용한다면 Yandex에는 왜 그러한 공식 대시보드가 ​​없나요?

키릴 슈바코프: 실제로 ClickHouse로 이동하는 데이터 소스는 이제 Altinity를 지원합니다. 그리고 저는 어디를 파고 누구를 밀어야 하는지에 대한 벡터를 제공하고 싶습니다. Yandex가 여전히 ClickHouse를 만들고 주변 이야기를 만들지 않기 때문에 그들에게 물어볼 수 있습니다. Altinity는 현재 ClickHouse를 홍보하는 주요 회사입니다. 그들은 그를 버리지 않고 지지할 것이다. 원칙적으로 Grafana 웹사이트에 대시보드를 업로드하려면 대시보드를 등록하고 업로드하기만 하면 되기 때문에 특별한 문제는 없습니다.

알렉세이 밀로비도프: 지난 해 ClickHouse에는 많은 쿼리 프로파일링 기능이 추가되었습니다. 리소스 사용량에 대한 각 요청에 대한 측정항목이 있습니다. 그리고 최근에는 쿼리가 매 밀리초마다 소비되는 위치를 확인하기 위해 더 낮은 수준의 쿼리 프로파일러를 추가했습니다. 하지만 이 기능을 사용하려면 콘솔 클라이언트를 열고 요청을 입력해야 하는데, 항상 잊어버리곤 합니다. 어딘가에 저장했는데 정확히 어디에 있는지 계속 잊어버리네요.

여기에 쿼리 클래스별로 그룹화된 무거운 쿼리가 있다고 알려주는 도구가 있었으면 좋겠습니다. 하나를 눌렀더니 그래서 무겁다고 하더라구요. 지금은 그런 해결책이 없습니다. 사람들이 저에게 "Grafana용으로 미리 만들어진 대시보드가 ​​있나요?"라고 물으면 저는 이렇게 말합니다. "Grafana 웹사이트에 가면 "Dashboards" 커뮤니티가 있고 대시보드도 있습니다. Dimka의 대시보드는 Kostyan의 대시보드입니다. 나는 그것이 무엇인지 모릅니다. 나는 그것을 직접 사용하지 않았습니다.”

서버가 OOM에 충돌하지 않도록 병합에 영향을 미치는 방법은 무엇입니까?

테이블이 있는데 테이블에 파티션이 하나만 있는데 ReplacingMergeTree입니다. 나는 XNUMX년 동안 그것에 데이터를 써왔습니다. 변경하고 일부 데이터를 삭제해야 했습니다.

이렇게 했는데 이 요청을 처리하는 동안 클러스터에 있는 모든 서버의 메모리가 모두 소모되어 클러스터에 있는 모든 서버가 OOM 상태가 되었습니다. 그런 다음 그들은 모두 함께 일어나 동일한 작업, 이 데이터 블록을 병합하기 시작했고 다시 OOM에 빠졌습니다. 그러다가 그들은 다시 일어났다가 다시 넘어졌습니다. 그리고 이 일은 멈추지 않았습니다.

그러다가 이것이 실제로 사람들이 고친 버그라는 것이 밝혀졌습니다. 정말 멋지네요. 정말 감사합니다. 하지만 잔여물이 남았습니다. 이제 테이블에 어떤 종류의 병합을 만드는 것에 대해 생각할 때 질문이 있습니다. 왜 이러한 병합에 영향을 미칠 수 없습니까? 예를 들어 필요한 RAM 양 또는 원칙적으로 이 특정 테이블을 처리할 양으로 제한합니다.

"Metrics"라는 테이블이 있습니다. 두 개의 스레드로 처리해 주세요. XNUMX~XNUMX개의 병합을 병렬로 생성할 필요는 없으며 XNUMX개로 수행합니다. XNUMX개에 대한 메모리는 충분하다고 생각하지만 XNUMX개를 처리하기에는 부족할 수도 있습니다. 왜 두려움이 남아 있습니까? 테이블이 커지고 있기 때문에 언젠가는 원칙적으로 더 이상 버그로 인한 것이 아니라 데이터가 너무 많이 변경되어 메모리가 충분하지 않은 상황에 직면하게 될 것입니다. 섬기는 사람. 그런 다음 병합할 때 서버가 OOM에 충돌합니다. 게다가 돌연변이를 취소할 수도 있지만 Merji는 더 이상 존재하지 않습니다.

병합할 때 RAM의 양은 하나의 작은 범위의 데이터에만 사용되기 때문에 병합할 때 서버가 OOM에 빠지지 않습니다. 따라서 데이터의 양에 관계없이 모든 것이 잘 될 것입니다.

블라디미르 콜로바예프: 괜찮은. 여기서는 버그가 수정된 후 새 버전을 직접 다운로드하고 파티션이 많은 작은 테이블인 다른 테이블에서 비슷한 작업을 수행한 순간입니다. 그리고 병합 중에 서버에서 약 100GB의 RAM이 소모되었습니다. 150개 점유, 100개 먹음, 50GB 윈도우가 남아있어서 OOM에 빠지지 않았습니다.

실제로 100GB의 RAM을 소비하는 경우 OOM에 빠지지 않도록 현재 보호하는 방법은 무엇입니까? 갑자기 병합의 RAM이 부족해지면 어떻게 해야 합니까?

알렉세이 밀로비도프: 특히 병합을 위한 RAM 소비가 제한되지 않는 문제가 있습니다. 그리고 두 번째 문제는 어떤 종류의 병합이 할당되면 복제 로그에 기록되기 때문에 반드시 실행해야 한다는 점이다. 복제 로그는 복제본을 일관된 상태로 만드는 데 필요한 작업입니다. 이 복제 로그를 롤백하는 수동 조작을 수행하지 않는 경우 병합은 어떤 방식으로든 수행되어야 합니다.

물론 "만일의 경우" OOM으로부터 보호하는 RAM 제한을 두는 것은 불필요한 일이 아닙니다. 병합이 완료되는 데 도움이 되지 않고 다시 시작되어 특정 임계값에 도달하고 예외가 발생한 다음 다시 시작됩니다. 이로 인해 좋은 결과가 나오지 않습니다. 그러나 원칙적으로는 이러한 제한을 도입하는 것이 유용할 것입니다.

ClickHouse용 Golang 드라이버는 어떻게 개발되나요?

Kirill Shvakov가 작성한 Golang 드라이버는 이제 ClickHouse 팀에서 공식적으로 지원됩니다. 그 ClickHouse 저장소에서, 그는 이제 크고 진짜입니다.

작은 메모. 무한한 질서의 정상적인 형태를 담은 훌륭하고 사랑받는 저장소가 있습니다. 바로 Vertica입니다. 또한 Vertica 개발자가 지원하는 자체 공식 Python 드라이버도 있습니다. 그리고 스토리지 버전과 드라이버 버전이 상당히 극적으로 갈라지는 일이 여러 번 발생했으며 어느 시점에서 드라이버가 작동을 멈췄습니다. 그리고 두 번째 요점. 이 공식 드라이버에 대한 지원은 "니플" 시스템에 의해 수행되는 것 같습니다. 문제를 작성하면 영원히 중단됩니다.

두 가지 질문이 있습니다. 이제 Kirill의 Golang 드라이버는 Golang에서 ClickHouse와 통신하는 거의 기본 방법입니다. 누군가가 그런 식으로 좋아하기 때문에 여전히 http 인터페이스를 통해 통신하지 않는 한. 이 드라이버의 개발은 어떻게 진행되나요? 저장소 자체의 주요 변경 사항과 동기화됩니까? 그리고 문제를 고려하는 절차는 무엇입니까?

키릴 슈바코프: 첫 번째는 모든 것이 관료적으로 조직되는 방식입니다. 이 점은 논의되지 않았으므로 답변 할 것이 없습니다.

문제에 대한 질문에 대답하려면 드라이버에 대한 약간의 기록이 필요합니다. 저는 데이터가 많은 회사에서 일했습니다. 어딘가에 저장해야 하는 수많은 이벤트가 포함된 광고 스피너였습니다. 그리고 어느 순간 ClickHouse가 나타났습니다. 데이터로 채웠고 처음에는 모든 것이 괜찮았지만 ClickHouse가 충돌했습니다. 그 순간 우리는 그것이 필요하지 않다고 결정했습니다.

XNUMX년 후, 우리는 ClickHouse를 사용하자는 생각으로 돌아왔고, 거기에 어떻게든 데이터를 써야 했습니다. 소개 메시지는 다음과 같습니다. 하드웨어가 매우 약하고 리소스가 거의 없습니다. 그러나 우리는 항상 이런 방식으로 작업해왔기 때문에 기본 프로토콜을 지향했습니다.

우리는 Go로 작업하고 있었기 때문에 Go 드라이버가 필요하다는 것이 분명했습니다. 나는 거의 풀타임으로 그 일을 했습니다. 그것은 내 업무였습니다. 우리는 그것을 특정 지점까지 가져왔고 원칙적으로 누구도 우리 외에 다른 사람이 그것을 사용할 것이라고 생각하지 않았습니다. 그런 다음 CloudFlare에 정확히 동일한 문제가 발생했고, 동일한 작업을 수행했기 때문에 한동안 우리는 매우 원활하게 작업했습니다. 게다가 우리는 ClickHouse와 드라이버 모두에서 이 작업을 수행했습니다.

ClickHouse와 작업 측면에서 내 활동이 약간 바뀌었기 때문에 어느 시점에서 나는 그것을 그만 두었습니다. 따라서 문제가 종결되지 않습니다. 주기적으로 무언가가 필요한 사람들은 저장소에 커밋합니다. 그러다가 풀 리퀘스트를 보고 때로는 직접 편집하기도 하는데 이런 일은 거의 발생하지 않습니다.

나는 운전사에게 돌아가고 싶다. 몇 년 전 이 모든 일이 시작되었을 때 ClickHouse도 달랐고 기능도 달랐습니다. 이제 우리는 드라이버가 잘 작동하도록 리메이크하는 방법을 이해했습니다. 이런 일이 발생하면 축적된 목발로 인해 어떤 경우에도 버전 2가 호환되지 않습니다.

이 문제를 어떻게 정리해야 할지 모르겠습니다. 나 자신에게는 시간이 별로 없다. 어떤 사람이 운전을 마치면 나는 그들을 도와주고 무엇을 해야 할지 말해 줄 수 있습니다. 그러나 프로젝트 개발에 Yandex의 적극적인 참여는 아직 논의되지 않았습니다.

알렉세이 밀로비도프: 실제로 아직 이러한 운전자에 대한 관료주의는 없습니다. 유일한 것은 공식 조직에 제출된다는 것입니다. 즉, 이 드라이버는 Go의 공식 기본 솔루션으로 인식됩니다. 다른 드라이버도 있지만 별도로 옵니다.

이러한 드라이버에 대한 내부 개발은 없습니다. 문제는 특정 운전자가 아닌 모든 커뮤니티 운전자의 발전을 위해 개인을 고용할 수 있는지, 아니면 외부에서 누군가를 찾을 수 있는지입니다.

lazy_load 설정이 활성화된 상태로 재부팅한 후에는 외부 사전이 로드되지 않습니다. 무엇을 해야 할까요?

lazy_load 설정을 활성화했으며 서버를 재부팅한 후 사전이 자체적으로 로드되지 않습니다. 사용자가 이 사전에 액세스한 후에만 발생합니다. 그리고 처음 접속하면 오류가 뜹니다. ClickHouse를 사용하여 사전을 자동으로 로드하는 것이 가능합니까? 아니면 사용자가 오류를 받지 않도록 항상 사전 준비 상태를 직접 제어해야 합니까?

아마도 ClickHouse의 이전 버전이 있어서 사전이 자동으로 로드되지 않았을 수 있습니다. 이런 일이 일어날 수 있습니까?

첫째, 쿼리를 사용하여 사전을 강제로 로드할 수 있습니다. 시스템 다시 로드 사전. 둘째, 오류 관련 - 사전이 이미 로드된 경우 쿼리는 로드된 데이터를 기반으로 작동합니다. 사전이 아직 로드되지 않은 경우 요청 중에 직접 로드됩니다.

이는 무거운 사전에는 그리 편리하지 않습니다. 예를 들어, MySQL에서 백만 개의 행을 가져와야 합니다. 누군가 간단한 선택을 수행하지만 이 선택은 동일한 백만 행을 기다립니다. 여기에는 두 가지 해결책이 있습니다. 첫 번째는lazy_load를 끄는 것입니다. 둘째, 서버가 작동 중일 때 로드를 가하기 전에 다음을 수행하십시오. 시스템 다시 로드 사전 아니면 사전을 사용하는 쿼리를 수행하세요. 그러면 사전이 로드됩니다. ClickHouse가 사전을 자동으로 로드하지 않기 때문에,lazy_load 설정이 활성화된 사전의 가용성을 제어해야 합니다.

마지막 질문에 대한 대답은 버전이 오래되었거나 디버깅이 필요하다는 것입니다.

시스템 다시 로드 사전 중 적어도 하나가 오류로 인해 충돌하는 경우 많은 사전 중 어느 것도 로드하지 않는다는 사실을 어떻게 해야 합니까?

시스템 다시 로드 사전에 대한 또 다른 질문이 있습니다. 두 개의 사전이 있습니다. 하나는 로드되지 않았고, 두 번째는 로드되었습니다. 이 경우 시스템 다시 로드 사전은 사전을 로드하지 않으며 시스템 다시 로드 사전을 사용하여 이름별로 특정 사전을 하나씩 로드해야 합니다. 이것도 ClickHouse 버전과 관련이 있나요?

나는 당신을 행복하게 만들고 싶습니다. 이 행동은 변화하고 있었습니다. 이는 ClickHouse를 업데이트하면 변경된다는 의미입니다. 현재 행동이 만족스럽지 않다면 시스템 다시 로드 사전, 업데이트하고 더 나은 방향으로 변경되기를 바랍니다.

ClickHouse 구성에서 세부 정보를 구성하지만 오류가 발생할 경우 표시하지 않는 방법이 있습니까?

다음 질문은 사전과 관련된 오류, 즉 세부사항에 관한 것입니다. 사전에 대한 ClickHouse 구성에 연결 세부 정보를 지정했으며, 오류가 있는 경우 해당 세부 정보와 비밀번호를 응답으로 받습니다.

ODBC 드라이버 구성에 세부 정보를 추가하여 이 오류를 해결했습니다. ClickHouse 구성에서 세부 정보를 구성하지만 오류가 발생할 경우 이러한 세부 정보를 표시하지 않는 방법이 있습니까?

여기서 실제 해결 방법은 odbc.ini에서 이러한 자격 증명을 지정하고 ClickHouse 자체에서는 ODBC 데이터 소스 이름만 지정하는 것입니다. 이는 다른 사전 소스에서는 발생하지 않습니다. MySQL이 포함된 사전이나 다른 사전 소스에서는 오류 메시지가 표시될 때 비밀번호가 표시되어서는 안 됩니다. ODBC의 경우도 살펴보겠습니다. 존재하는 경우 제거하기만 하면 됩니다.

보너스: 모임에서 Zoom을 위한 배경

사진을 클릭하면 가장 끈질긴 독자들을 위해 모임의 보너스 배경이 열립니다. 우리는 Avito 기술 마스코트와 함께 불을 끄고, 시스템 관리자실이나 옛날 컴퓨터 클럽의 동료들과 회의를 하고, 낙서를 배경으로 다리 아래에서 매일 회의를 진행합니다.

출처 : habr.com