여러 시계열 데이터베이스를 테스트한 방법

지난 몇 년 동안 시계열 데이터베이스는 이상한 것(개방형 모니터링 시스템(및 특정 솔루션과 연결) 또는 빅 데이터 프로젝트에 사용되는 고도로 전문화된 것)에서 "소비자 제품"으로 변했습니다. 러시아 연방 영토에서는 이에 대해 Yandex와 ClickHouse에 특별한 감사를 표해야 합니다. 지금까지는 대량의 시계열 데이터를 저장해야 한다면 엄청난 Hadoop 스택을 구축하고 유지 관리해야 한다는 점을 인정하거나 각 시스템에 대해 개별적인 프로토콜과 통신해야 했습니다.

2019년에는 TSDB를 사용할 가치가 있는 기사가 "그냥 ClickHouse를 사용하세요"라는 단 한 문장으로만 구성될 것으로 보일 수 있습니다. 하지만... 미묘한 차이가 있습니다.

실제로 ClickHouse는 적극적으로 개발 중이고 사용자 기반이 성장하고 있으며 지원도 매우 활발합니다. 그러나 더 효과적이고 신뢰할 수 있는 다른 솔루션을 무색하게 만든 ClickHouse의 대중적 성공에 우리가 인질이 되었습니까?

작년 초에 우리는 자체 모니터링 시스템을 재작업하기 시작했으며 그 동안 데이터 저장에 적합한 데이터베이스를 선택하는 문제가 발생했습니다. 저는 여기서 이 선택의 역사에 대해 이야기하고 싶습니다.

문제 성명

우선 필요한 서문입니다. 자체 모니터링 시스템이 필요한 이유는 무엇이며 어떻게 설계되었습니까?

우리는 2008년에 지원 서비스를 제공하기 시작했고, 2010년에는 당시 존재했던 솔루션으로는 클라이언트 인프라에서 발생하는 프로세스에 대한 데이터를 집계하는 것이 어려워졌다는 것이 분명해졌습니다(우리는 God 용서해 주세요, Cacti, Zabbix에 대해 이야기하고 있습니다). 그리고 신흥 흑연).

우리의 주요 요구 사항은 다음과 같습니다.

• 하나의 시스템 내에서 (당시에는 수십 개, 앞으로는 수백 개) 클라이언트를 지원하고 동시에 중앙 집중식 경고 관리 시스템도 존재합니다.
• 경보 시스템 관리의 유연성(직무 담당자 간 경보 에스컬레이션, 일정 관리, 지식 기반)
• 그래프를 자세히 설명하는 기능(당시 Zabbix는 그래프를 그림 형태로 렌더링했습니다)
• 대용량 데이터(XNUMX년 이상)의 장기 저장과 빠른 검색 능력.

이 기사에서 우리는 마지막 요점에 관심이 있습니다.

스토리지에 대한 요구 사항은 다음과 같습니다.

• 시스템은 빠르게 작동해야 합니다.
• 시스템에 SQL 인터페이스가 있는 것이 바람직합니다.
• 시스템은 안정적이어야 하며 활성 사용자 기반과 지원이 있어야 합니다(더 이상 개발되지 않은 MemcacheDB 또는 버그 추적기가 중국어로 유지되는 MooseFS 분산 스토리지와 같은 시스템을 지원해야 할 필요성에 직면했을 때: 우리 프로젝트가 원하지 않았기 때문에 이 이야기를 반복합니다);
• CAP 정리 준수: 일관성(필수) - 데이터는 최신이어야 하며, 경고 관리 시스템이 새 데이터를 수신하지 않고 모든 프로젝트에 대한 데이터가 도착하지 않았다는 경고를 내뱉는 것을 원하지 않습니다. Partition Tolerance (필수) - 우리는 Split Brain 시스템을 원하지 않습니다. 가용성(활성 복제본이 있는 경우 중요하지 않음) - 사고 발생 시 코드를 사용하여 백업 시스템으로 직접 전환할 수 있습니다.

이상하게도 당시 MySQL은 우리에게 이상적인 솔루션이었습니다. 우리의 데이터 구조는 매우 간단했습니다. 서버 ID, 카운터 ID, 타임스탬프 및 값; 대용량 버퍼 풀을 통해 핫 데이터의 빠른 샘플링이 보장되었으며, SSD를 통해 기록 데이터 샘플링이 보장되었습니다.

따라서 우리는 데이터가 완전히 렌더링되기 전 200ms까지의 세부 정보를 포함하는 새로운 XNUMX주 데이터 샘플을 얻었고 꽤 오랫동안 이 시스템에서 살았습니다.

그러는 사이 시간은 흐르고 데이터의 양은 늘어났다. 2016년까지 데이터 볼륨은 수십 테라바이트에 이르렀으며 이는 임대 SSD 스토리지 측면에서 상당한 비용이었습니다.

이때쯤에는 열형 데이터베이스가 널리 보급되어 우리가 적극적으로 생각하기 시작했습니다. 열형 데이터베이스에서는 데이터가 아시다시피 열에 저장되어 있으며 데이터를 보면 큰 것을 쉽게 볼 수 있습니다. 열 기반 데이터베이스를 사용하는 경우 압축을 사용하여 압축할 수 있는 중복 수입니다.

하지만 회사의 핵심 시스템은 계속해서 안정적으로 작동했고, 다른 것으로 전환하는 실험을 하고 싶지 않았습니다.

2017년 산호세에서 열린 Percona Live 컨퍼런스에서 Clickhouse 개발자는 아마도 처음으로 자신을 발표했을 것입니다. 언뜻 보기에 시스템은 생산 준비가 되어 있었고(Yandex.Metrica는 가혹한 생산 시스템입니다) 지원은 빠르고 간단했으며, 가장 중요한 것은 작동이 간단했다는 것입니다. 2018년부터 우리는 전환 과정을 시작했습니다. 그러나 그 당시에는 많은 "성인용" 및 오랜 테스트를 거친 TSDB 시스템이 있었고 우리는 요구 사항에 따라 Clickhouse에 대한 대체 솔루션이 없는지 확인하기 위해 상당한 시간을 투자하고 대안을 비교하기로 결정했습니다.

이미 지정된 스토리지 요구 사항 외에도 새로운 요구 사항이 나타났습니다.

• 새로운 시스템은 동일한 양의 하드웨어에서 최소한 MySQL과 동일한 성능을 제공해야 합니다.
• 새 시스템의 스토리지는 훨씬 적은 공간을 차지합니다.
• DBMS는 여전히 관리하기 쉬워야 합니다.
• DBMS를 변경할 때 애플리케이션의 변경을 최소화하고 싶었습니다.

우리는 어떤 시스템을 고려하기 시작했습니까?

아파치 하이브/아파치 임팔라
오래되고 전투 테스트를 거친 Hadoop 스택입니다. 본질적으로 이는 HDFS에 기본 형식으로 데이터를 저장하는 것 위에 구축된 SQL 인터페이스입니다.

찬성.

• 안정적인 운영으로 데이터 확장이 매우 쉽습니다.
• 데이터 저장(적은 공간)을 위한 컬럼 솔루션이 있습니다.
• 리소스를 사용할 수 있을 때 병렬 작업을 매우 빠르게 실행합니다.

단점.

• Hadoop인데 사용하기 어렵습니다. 클라우드에서 기성 솔루션을 사용할 준비가 되지 않은 경우(그리고 비용 측면에서도 준비가 되지 않은 경우) 관리자가 전체 스택을 조립하고 지원해야 하며 실제로는 원하지 않습니다. 이것.
• 데이터가 집계됩니다. 정말 빠르다.

그러나 :

속도는 컴퓨팅 서버 수를 확장하여 달성됩니다. 간단히 말해서, 우리가 분석에 종사하는 대기업이고 비즈니스가 가능한 한 빨리 정보를 집계하는 것이 중요하다면(많은 양의 컴퓨팅 리소스를 사용하는 비용이 들더라도) 이것이 우리의 선택일 수 있습니다. 그러나 우리는 작업 속도를 높이기 위해 하드웨어를 늘릴 준비가 되어 있지 않았습니다.

드루이드/피노

특히 TSDB에 대해 훨씬 더 많은 내용이 있지만 다시 Hadoop 스택에 대해 설명합니다.

이 Druid와 Pinot와 ClickHouse의 장단점을 비교한 훌륭한 기사 .

간단히 말해서: 다음과 같은 경우에는 Druid/Pinot가 Clickhouse보다 더 좋아 보입니다.

• 데이터의 이질적인 특성이 있습니다(우리의 경우 서버 측정항목의 시계열만 기록하며 실제로 이는 하나의 테이블입니다. 그러나 장비 시계열, 경제 시계열 등 다른 경우도 있을 수 있습니다. - 각각 집계 및 처리가 필요한 자체 구조).
• 게다가 이런 데이터도 많아요.
• 시계열이 포함된 테이블과 데이터가 나타나고 사라집니다(즉, 일부 데이터 세트가 도착하여 분석되고 삭제되었습니다).
• 데이터를 분할할 수 있는 명확한 기준은 없습니다.

반대의 경우에는 ClickHouse의 성능이 더 좋으며 이것이 우리의 경우입니다.

클릭 하우스

• SQL과 유사한
• 관리가 용이합니다.
• 사람들은 그것이 효과가 있다고 말합니다.

테스트 후보로 선정됩니다.

인플럭스DB

ClickHouse에 대한 외국 대안. 단점: 고가용성은 상용 버전에만 있지만 비교가 필요합니다.

테스트 후보로 선정됩니다.

카산드 라

한편으로는 다음과 같은 모니터링 시스템에서 측정항목 시계열을 저장하는 데 사용된다는 것을 알고 있습니다. 시그널FX 또는 OkMeter. 그러나 구체적인 사항이 있습니다.

Cassandra는 전통적인 의미의 컬럼형 데이터베이스가 아닙니다. 행 보기와 더 비슷해 보이지만 각 줄에는 서로 다른 열 수가 있을 수 있으므로 열 보기를 쉽게 구성할 수 있습니다. 이러한 의미에서 2억 개의 열 제한을 사용하면 일부 데이터를 열(및 동일한 시계열)에 저장할 수 있다는 것이 분명합니다. 예를 들어, MySQL에는 4096개의 열 제한이 있으며 동일한 작업을 시도하면 코드 1117 오류가 발생하기 쉽습니다.

Cassandra 엔진은 마스터가 없는 분산 시스템에서 대량의 데이터를 저장하는 데 중점을 두고 있으며, 위에서 언급한 Cassandra CAP 정리는 AP, 즉 데이터 가용성 및 파티셔닝에 대한 저항에 관한 것입니다. 따라서 이 도구는 데이터베이스에 쓰기만 하고 데이터베이스에서 거의 읽지 않아도 되는 경우에 유용할 수 있습니다. 그리고 여기에서는 Cassandra를 "콜드" 저장소로 사용하는 것이 논리적입니다. 즉, 거의 필요하지 않지만 필요한 경우 검색할 수 있는 대량의 기록 데이터를 저장할 수 있는 장기적이고 안정적인 장소입니다. 그럼에도 불구하고 완성도를 위해 테스트도 해보겠습니다. 그러나 앞서 말했듯이 선택한 데이터베이스 솔루션에 대한 코드를 적극적으로 다시 작성할 의사가 없으므로 데이터베이스 구조를 Cassandra의 세부 사항에 맞게 조정하지 않고 다소 제한적으로 테스트할 것입니다.

프로 메테우스

글쎄, 우리는 호기심에서 Prometheus 스토리지의 성능을 테스트하기로 결정했습니다. 단지 우리가 현재 솔루션보다 빠른지 느린지, 얼마나 빠른지 이해하기 위해서였습니다.

테스트 방법 및 결과

그래서 우리는 ClickHouse(5노드), ClickHouse(6노드용 분산 테이블), InfluxDB, Mysql 1, Cassandra(3노드) 및 Prometheus의 8가지 구성에서 3개의 데이터베이스를 테스트했습니다. 테스트 계획은 다음과 같습니다.

1. 일주일 동안의 기록 데이터 업로드(일일 840억 208천만 개의 값, XNUMX개의 측정항목)
2. 기록 로드를 생성합니다(6개의 로드 모드가 고려되었습니다. 아래 참조).
3. 기록과 병행하여 주기적으로 선택하여 차트 작업을 하는 사용자의 요청을 에뮬레이트합니다. 상황을 너무 복잡하게 하지 않기 위해 일주일 동안 10개의 지표(정확히 CPU 그래프에 있는 지표 수)에 대한 데이터를 선택했습니다.

15초마다 한 번씩 각 측정항목에 값을 보내는 모니터링 에이전트의 동작을 에뮬레이션하여 로드합니다. 동시에 우리는 다음과 같은 변화에 관심이 있습니다.

• 데이터가 기록되는 총 측정항목 수
• 하나의 메트릭에 값을 보내는 간격;
• 배치 크기.

배치 크기에 대해. 단일 삽입으로 거의 모든 실험 데이터베이스를 로드하는 것은 권장되지 않으므로 들어오는 측정 항목을 수집하여 그룹으로 그룹화하고 일괄 삽입으로 데이터베이스에 기록하는 릴레이가 필요합니다.

또한 수신된 데이터를 해석하는 방법을 더 잘 이해하기 위해 단순히 여러 개의 메트릭을 보내는 것이 아니라 메트릭이 서버로 구성되어 서버당 125개의 메트릭이 있다고 가정해 보겠습니다. 여기서 서버는 단순히 가상 엔터티입니다. 예를 들어 10000개의 메트릭이 약 80개의 서버에 해당한다는 점을 이해하면 됩니다.

이 모든 것을 고려한 6가지 데이터베이스 쓰기 로드 모드는 다음과 같습니다.

여기에는 두 가지 점이 있습니다. 첫째, Cassandra의 경우 이러한 배치 크기가 너무 큰 것으로 판명되어 50 또는 100의 값을 사용했습니다. 둘째, Prometheus는 엄격하게 풀 모드에서 작동하므로, 즉 자체적으로 메트릭 소스에서 데이터를 수집하고(이름에도 불구하고 pushgateway조차도 상황을 근본적으로 바꾸지 않음) 해당 로드는 정적 구성 조합을 사용하여 구현되었습니다.

테스트 결과는 다음과 같습니다.

주목할 가치가있는 것: Prometheus의 환상적으로 빠른 샘플, Cassandra의 매우 느린 샘플, InfluxDB의 용납할 수 없을 정도로 느린 샘플; 녹음 속도 측면에서 ClickHouse는 모두를 이겼고 Prometheus는 자체적으로 삽입물을 만들고 우리는 아무것도 측정하지 않기 때문에 경쟁에 참여하지 않습니다.

그 결과,: ClickHouse와 InfluxDB가 최고임을 입증했지만 Influx의 클러스터는 Enterprise 버전을 기반으로만 구축할 수 있으므로 비용이 많이 드는 반면 ClickHouse는 비용이 들지 않으며 러시아에서 제작됩니다. 미국에서는 아마도 inInfluxDB를 선호하고 우리나라에서는 ClickHouse를 선호하는 것이 논리적입니다.

출처 : habr.com