HighLoad++, Andrey Gushchin(Zabbix): 고성능 및 기본 파티셔닝

Zabbix가 TimescaleDB 데이터베이스를 백엔드로 사용하여 어떻게 작동하는지 살펴보겠습니다. 처음부터 시작하는 방법과 PostgreSQL에서 마이그레이션하는 방법을 보여 드리겠습니다. 또한 두 구성의 비교 성능 테스트도 제공합니다.

HighLoad++ 시베리아 2019. 톰스크 홀. 24월 16일 00:XNUMX. 논문과 제출. 다음 HighLoad++ 컨퍼런스는 6년 7월 2020일과 XNUMX일에 상트페테르부르크에서 개최됩니다. 세부정보 및 티켓 링크.

Andrey Gushchin(이하 – AG): – 저는 트레이너인 ZABBIX 기술지원 엔지니어(이하 "Zabbix")입니다. 저는 6년 넘게 기술 지원 분야에서 일해 왔으며 성능에 대한 직접적인 경험을 했습니다. 오늘은 일반 PostgreSQL 10과 비교하여 TimescaleDB가 제공할 수 있는 성능에 대해 이야기하겠습니다. 또한 일반적인 작동 방식에 대한 소개 부분도 있습니다.

최고의 생산성 과제: 데이터 수집부터 데이터 정리까지

우선, 모든 모니터링 시스템이 직면하는 특정 성능 문제가 있습니다. 첫 번째 생산성 과제는 데이터를 빠르게 수집하고 처리하는 것입니다.

좋은 모니터링 시스템은 신속하고 적시에 모든 데이터를 수신하고, 트리거 표현식에 따라 처리해야 합니다. 즉, 일부 기준(시스템마다 다름)에 따라 처리하고, 이 데이터를 사용하기 위해 데이터베이스에 저장해야 합니다. 미래.

두 번째 성능 과제는 기록 저장입니다. 데이터베이스에 자주 저장하고 일정 기간 동안 수집된 이러한 측정항목에 빠르고 편리하게 액세스하세요. 가장 중요한 것은 이 데이터가 보고서, 그래프, 트리거, 일부 임계값, 경고 등에 사용하기 편리하다는 것입니다.

세 번째 성능 문제는 기록 지우기입니다. 즉, 5년(심지어 몇 달 또는 두 달) 동안 수집된 세부 지표를 저장할 필요가 없는 지점에 도달하는 경우입니다. 일부 네트워크 노드 또는 일부 호스트가 삭제되었습니다. 메트릭은 이미 오래되어 더 이상 수집되지 않으므로 더 이상 필요하지 않습니다. 데이터베이스가 너무 커지지 않도록 이 모든 것을 정리해야 합니다. 일반적으로 기록 지우기는 스토리지에 대한 심각한 테스트인 경우가 많으며 성능에 매우 큰 영향을 미치는 경우가 많습니다.

캐싱 문제를 해결하는 방법은 무엇입니까?

이제 Zabbix에 대해 구체적으로 이야기하겠습니다. Zabbix에서는 첫 번째와 두 번째 호출이 캐싱을 사용하여 해결됩니다.

데이터 수집 및 처리 - 우리는 RAM을 사용하여 이 모든 데이터를 저장합니다. 이제 이러한 데이터에 대해 더 자세히 설명하겠습니다.

또한 데이터베이스 측에는 그래프 및 기타 항목과 같은 주요 선택 항목에 대한 캐싱이 있습니다.

Zabbix 서버 자체 측의 캐싱: ConfigurationCache, ValueCache, HistoryCache, TrendsCache가 있습니다. 그것은 무엇입니까?

ConfigurationCache는 메트릭, 호스트, 데이터 항목, 트리거를 저장하는 기본 캐시입니다. 전처리 처리, 데이터 수집, 수집할 호스트, 빈도에 필요한 모든 것. 이 모든 것은 데이터베이스로 이동하여 불필요한 쿼리를 생성하지 않도록 ConfigurationCache에 저장됩니다. 서버가 시작된 후 이 캐시를 업데이트(생성)하고 주기적으로 업데이트합니다(구성 설정에 따라).

Zabbix에서 캐싱. 데이터 수집

여기서 다이어그램은 상당히 큽니다.

이 계획의 주요 항목은 다음 수집가입니다.

이는 조립 프로세스 자체이며 다양한 유형의 조립을 담당하는 다양한 "폴러"입니다. icmp, ipmi 및 다양한 프로토콜을 통해 데이터를 수집하고 이를 모두 전처리로 전송합니다.

전처리 기록캐시

또한 계산된 데이터 요소(Zabbix에 익숙한 사람들은 알고 있음), 즉 계산된 집계 데이터 요소가 있는 경우 이를 ValueCache에서 직접 가져옵니다. 나중에 어떻게 채워지는지 알려드릴게요. 이러한 수집기는 모두 ConfigurationCache를 사용하여 작업을 수신한 다음 전처리에 전달합니다.

또한 전처리는 ConfigurationCache를 사용하여 전처리 단계를 얻고 이 데이터를 다양한 방식으로 처리합니다. 버전 4.2부터 프록시로 이동했습니다. 전처리 자체가 다소 어려운 작업이기 때문에 이는 매우 편리합니다. 그리고 데이터 요소 수가 많고 수집 빈도가 높은 Zabbix가 매우 큰 경우 작업이 크게 단순화됩니다.

따라서 전처리를 사용하여 어떤 방식으로든 이 데이터를 처리한 후 추가 처리를 위해 HistoryCache에 저장합니다. 이것으로 데이터 수집이 마무리됩니다. 우리는 주요 프로세스로 이동합니다.

히스토리 싱크로의 작업

Zabbix의 주요 프로세스(모놀리식 아키텍처이므로)는 기록 동기화 장치입니다. 이는 각 데이터 요소, 즉 각 값의 원자적 처리를 구체적으로 다루는 주요 프로세스입니다.

• 값이 옵니다(HistoryCache에서 가져옴).
• 구성 동기화 장치에서 확인: 계산을 위한 트리거가 있는지 여부 - 이를 계산합니다.
  있는 경우 - 구성에 따라 필요한 경우 이벤트를 생성하고 경고를 생성하기 위한 에스컬레이션을 생성합니다.
• 후속 처리, 집계를 위한 기록 트리거; 지난 XNUMX시간 동안 집계하는 경우 이 값은 기록 테이블로 이동하지 않도록 ValueCache에 의해 기억됩니다. 따라서 ValueCache는 트리거, 계산된 요소 등을 계산하는 데 필요한 필수 데이터로 채워집니다.
• 그런 다음 기록 동기화 장치가 모든 데이터를 데이터베이스에 기록합니다.
• 데이터베이스는 이를 디스크에 기록합니다. 여기에서 처리 프로세스가 종료됩니다.

데이터 베이스. 캐싱

데이터베이스 측에서는 이벤트에 대한 그래프나 일부 보고서를 보고자 할 때 다양한 캐시가 있습니다. 하지만 이 보고서에서는 이에 대해 언급하지 않겠습니다.

MySQL의 경우 Innodb_buffer_pool과 구성할 수 있는 다양한 캐시가 있습니다.
그러나 주요 내용은 다음과 같습니다.

• 공유_버퍼;
• 효과적인_캐시_크기;
• 공유_풀.

모든 데이터베이스에는 쿼리에 자주 필요한 데이터를 RAM에 저장할 수 있는 특정 캐시가 있다고 말씀드렸습니다. 그들은 이에 대한 자체 기술을 가지고 있습니다.

데이터베이스 성능 정보

따라서 Zabbix 서버가 데이터를 수집하고 기록하는 경쟁적인 환경이 존재합니다. 다시 시작하면 기록에서 읽어 ValueCache 등을 채웁니다. 여기에서는 웹 인터페이스에 구축된 Zabbix API를 사용하는 스크립트와 보고서를 가질 수 있습니다. Zabbix API는 데이터베이스에 들어가서 그래프, 보고서 또는 일종의 이벤트 목록, 최근 문제를 얻는 데 필요한 데이터를 받습니다.

또한 매우 인기 있는 시각화 솔루션은 사용자가 사용하는 Grafana입니다. Zabbix API와 데이터베이스를 통해 직접 로그인할 수 있습니다. 이는 또한 데이터 획득을 위한 특정 경쟁을 야기합니다. 결과 및 테스트의 신속한 전달을 준수하려면 데이터베이스를 더 세밀하고 더 잘 조정해야 합니다.

기록을 삭제합니다. Zabbix에는 가정부가 있습니다

Zabbix에서 사용되는 세 번째 호출은 Housekeeper를 사용하여 기록을 지우는 것입니다. Housekeeper는 모든 설정을 따릅니다. 즉, 데이터 요소는 저장 기간(일), 추세 저장 기간 및 변화의 역학을 나타냅니다.

즉석에서 계산하는 TrendCache에 대해서는 언급하지 않았습니다. 데이터가 도착하면 한 시간 동안 집계하고(대부분 지난 시간의 숫자입니다) 양은 평균/최소이며 한 시간에 한 번씩 기록합니다. 변화의 역학(“추세”) 표. "Housekeeper"는 일반 선택을 사용하여 데이터베이스에서 데이터를 시작하고 삭제하지만 항상 효과적인 것은 아닙니다.

그것이 효과가 없다는 것을 어떻게 이해합니까? 내부 프로세스의 성능 그래프에서 다음 그림을 볼 수 있습니다.

기록 동기화 장치가 계속 사용 중입니다(빨간색 그래프). 그리고 맨 위에 있는 "빨간색" 그래프. 이는 데이터베이스를 시작하고 데이터베이스가 지정한 모든 행을 삭제할 때까지 기다리는 "관리자"입니다.

일부 항목 ID를 살펴보겠습니다. 마지막 5개를 삭제해야 합니다. 물론 인덱스로요. 그러나 일반적으로 데이터세트는 상당히 큽니다. 데이터베이스는 여전히 이를 디스크에서 읽어 캐시에 저장하는데, 이는 데이터베이스에 있어 매우 비용이 많이 드는 작업입니다. 크기에 따라 특정 성능 문제가 발생할 수 있습니다.

간단한 방법으로 Housekeeper를 비활성화할 수 있습니다. 친숙한 웹 인터페이스가 있습니다. 관리 일반 설정("Housekeeper" 설정)에서는 내부 기록 및 추세에 대한 내부 관리를 비활성화합니다. 따라서 Housekeeper는 더 이상 다음 사항을 통제하지 않습니다.

다음에는 무엇을 할 수 있나요? 이 기능을 끄면 그래프가 균일해집니다. 이 경우 어떤 문제가 더 발생할 수 있습니까? 무엇이 도움이 될까요?

파티셔닝(섹셔닝)

일반적으로 이는 내가 나열한 각 관계형 데이터베이스에서 다른 방식으로 구성됩니다. MySQL에는 자체 기술이 있습니다. 그러나 PostgreSQL 10과 MySQL의 경우 전반적으로 매우 유사합니다. 물론, 모든 구현 방식과 성능에 미치는 영향에는 내부적으로 많은 차이가 있습니다. 그러나 일반적으로 새 파티션을 생성하면 특정 문제가 발생하는 경우가 많습니다.

설정(하루에 생성하는 데이터의 양)에 따라 일반적으로 최소값을 설정합니다. 이는 1일/배치이고 "트렌드"의 경우 변경 역학은 1개월/새 배치입니다. 설정이 매우 큰 경우에는 변경될 수 있습니다.

설정 크기에 대해 바로 말해 보겠습니다. 초당 최대 5개의 새로운 값(소위 nvps) - 이는 작은 "설정"으로 간주됩니다. 평균 – 초당 5~25개 값. 위의 모든 내용은 매우 신중한 데이터베이스 구성이 필요한 대규모 설치입니다.

대규모 설치에서는 1일이 최적이 아닐 수 있습니다. 저는 개인적으로 MySQL에서 하루에 40GB의 파티션을 본 적이 있습니다(더 많을 수도 있습니다). 이는 매우 많은 양의 데이터이므로 몇 가지 문제가 발생할 수 있습니다. 줄여야합니다.

파티셔닝이 필요한 이유는 무엇입니까?

파티셔닝이 제공하는 것은 모두가 알고 있는 테이블 파티셔닝입니다. 종종 이는 디스크 및 스팬 요청에 대한 별도의 파일입니다. 일반 파티셔닝의 일부인 경우 하나의 파티션을 더 최적으로 선택합니다.

특히 Zabbix의 경우 범위, 범위별로 사용됩니다. 즉, 타임스탬프(일반 숫자, 에포크 시작 이후의 시간)를 사용합니다. 하루의 시작/끝을 지정하며 이것이 파티션입니다. 따라서 이틀이 지난 데이터를 요청하는 경우 큰 테이블이 아닌 파일 하나만 캐시에 로드하고 반환하면 되므로 데이터베이스에서 모든 것이 더 빨리 검색됩니다.

또한 많은 데이터베이스는 삽입(하나의 하위 테이블에 삽입) 속도를 높입니다. 지금은 추상적으로 말하고 있지만 이것도 가능합니다. 파티셔닝은 종종 도움이 됩니다.

NoSQL용 Elasticsearch

최근 3.4에서는 NoSQL 솔루션을 구현했습니다. Elasticsearch에 작성하는 기능이 추가되었습니다. 특정 유형을 쓸 수 있습니다. 선택합니다. 숫자나 기호를 쓸 수 있습니다. 문자열 텍스트가 있으므로 Elasticsearch에 로그를 작성할 수 있습니다... 따라서 웹 인터페이스도 Elasticsearch에 액세스합니다. 이것은 어떤 경우에는 훌륭하게 작동하지만 지금은 사용할 수 있습니다.

TimescaleDB. 하이퍼테이블

4.4.2에서는 TimescaleDB와 같은 한 가지에 주의를 기울였습니다. 그것은 무엇입니까? 이것은 PostgreSQL의 확장입니다. 즉, 기본 PostgreSQL 인터페이스가 있습니다. 또한 이 확장 기능을 사용하면 시계열 데이터를 사용하여 훨씬 더 효율적으로 작업하고 자동 분할 기능을 사용할 수 있습니다. 모습:

이것은 하이퍼테이블입니다. Timescale에는 그러한 개념이 있습니다. 이것은 사용자가 생성하는 하이퍼테이블이며 청크를 포함합니다. 청크는 파티션이고, 제가 착각하지 않는다면 이것은 하위 테이블입니다. 정말 효과적입니다.

TimescaleDB 및 PostgreSQL

TimescaleDB 제조업체는 쿼리 처리, 특히 삽입에 대해 보다 정확한 알고리즘을 사용하므로 데이터 세트 삽입 크기가 증가함에 따라 거의 일정한 성능을 유지할 수 있다고 확신합니다. 즉, 200억 행의 Postgres 이후에는 일반적인 Postgres가 매우 많이 처지기 시작하고 문자 그대로 성능이 XNUMX으로 떨어지는 반면 Timescale을 사용하면 모든 양의 데이터에 대해 최대한 효율적으로 삽입을 삽입할 수 있습니다.

TimescaleDB를 설치하는 방법은 무엇입니까? 간단 해!

문서에 설명되어 있습니다. 어떤 패키지에서든 설치할 수 있습니다... 공식 Postgres 패키지에 따라 다릅니다. 수동으로 컴파일할 수 있습니다. 그래서 데이터베이스용으로 컴파일해야 했습니다.

Zabbix에서는 Extension을 활성화하기만 하면 됩니다. Postgres에서 Extention을 사용하신 분들은... Extention을 활성화하고 사용 중인 Zabbix 데이터베이스용으로 생성하면 됩니다.

그리고 마지막 단계..

TimescaleDB. 기록 테이블 마이그레이션

하이퍼테이블을 생성해야 합니다. 이를 위한 특별한 기능인 하이퍼테이블 생성이 있습니다. 여기에서 첫 번째 매개변수는 이 데이터베이스에 필요한 테이블입니다(하이퍼테이블을 생성해야 함).

생성할 필드와 Chunk_time_interval(청크(사용해야 하는 파티션)의 간격입니다. 86은 400일입니다.

Migrate_data 매개변수: true로 삽입하면 모든 현재 데이터가 사전 생성된 청크로 마이그레이션됩니다.

나는 migration_data를 직접 사용했습니다. 데이터베이스 크기에 따라 상당한 시간이 걸립니다. 테라바이트가 넘는 용량이 있었는데 생성하는 데 XNUMX시간 이상이 걸렸습니다. 어떤 경우에는 테스트 중에 텍스트(history_text) 및 문자열(history_str)에 대한 기록 데이터를 삭제하여 전송하지 않도록 했습니다. 실제로는 흥미롭지 않았습니다.

그리고 db_extention에서 마지막 업데이트를 수행합니다. 데이터베이스, 특히 Zabbix가 db_extention이 있음을 이해할 수 있도록 timescaledb를 설치합니다. 그는 이를 활성화하고 TimescaleDB에 필요한 "기능"을 사용하여 데이터베이스에 대한 올바른 구문과 쿼리를 사용합니다.

서버 구성

저는 두 대의 서버를 사용했습니다. 첫 번째 서버는 20개의 프로세서, 16GB의 RAM을 갖춘 매우 작은 가상 머신입니다. Postgres 10.8을 구성했습니다.

운영 체제는 Debian이고 파일 시스템은 xfs입니다. Zabbix 자체에서 사용할 설정을 제외하고 이 특정 데이터베이스를 사용하기 위한 최소한의 설정을 지정했습니다. 동일한 시스템에는 Zabbix 서버, PostgreSQL 및 로드 에이전트가 있었습니다.

저는 다양한 결과를 빠르게 생성하기 위해 LoadableModule을 사용하는 50개의 활성 에이전트를 사용했습니다. 그들은 문자열, 숫자 등을 생성한 사람들입니다. 나는 데이터베이스를 많은 데이터로 채웠다. 처음에는 구성에 호스트당 5개의 데이터 요소가 포함되어 있었고 대략 각 데이터 요소에는 트리거가 포함되어 있었습니다. 이를 위해서는 실제 설정이 필요했습니다. 때로는 사용할 트리거가 두 개 이상 필요할 수도 있습니다.

50개의 에이전트를 사용하는 것(더 추가)뿐만 아니라 동적 데이터 요소를 사용하고 업데이트 간격을 4초로 줄여 업데이트 간격과 로드 자체를 조절했습니다.

성능 검사. PostgreSQL: 36 NVP

제가 처음으로 실행한 첫 번째 설정은 이 하드웨어의 순수 PostreSQL 10(초당 35개 값)이었습니다. 일반적으로 화면에서 볼 수 있듯이 데이터를 삽입하는 데는 몇 초도 걸리지 않습니다. 모든 것이 훌륭하고 빠릅니다. SSD 드라이브(200GB). 유일한 것은 20GB가 매우 빨리 채워진다는 것입니다.

앞으로도 이런 그래프가 꽤 많이 나올 겁니다. 이것은 표준 Zabbix 서버 성능 대시보드입니다.

첫 번째 그래프는 초당 값 수(파란색, 왼쪽 상단)이며, 이 경우 35개 값입니다. 이(상단 중앙)는 빌드 프로세스를 로드하는 것이고, 이(오른쪽 상단)는 내부 프로세스를 로드하는 것입니다. 여기(하단 중앙)는 꽤 오랫동안 실행되어 온 히스토리 동기화 장치 및 하우스키퍼입니다.

이 그래프(하단 중앙)는 ValueCache 사용량, 즉 트리거에 대한 ValueCache 적중 횟수(초당 수천 개의 값)를 보여줍니다. 또 다른 중요한 그래프는 네 번째 그래프(왼쪽 아래)로 앞서 이야기한 HistoryCache의 사용을 보여주는데, 이는 데이터베이스에 삽입하기 전의 버퍼입니다.

성능 검사. PostgreSQL: 50 NVP

다음으로 동일한 하드웨어에서 로드를 초당 50만 값으로 늘렸습니다. Housekeeper에서 로드하면 계산과 함께 10~2초 만에 3개의 값이 기록되었습니다. 실제로 다음 스크린샷에 표시된 내용은 다음과 같습니다.

'하우스키퍼'는 이미 작업에 방해가 되기 시작했지만, 일반적으로 히스토리 싱커 트래퍼의 부하는 여전히 60% 수준입니다(세 번째 그래프, 오른쪽 상단). Housekeeper가 실행되는 동안 HistoryCache가 이미 활발하게 채워지기 시작했습니다(왼쪽 아래). 약 20GB, XNUMX% 정도 찼습니다.

성능 검사. PostgreSQL: 80 NVP

그런 다음 초당 80만 값으로 늘렸습니다.

대략 400만 개의 데이터 요소, 280만 개의 트리거였습니다. 보시다시피, 히스토리 싱커(30개가 있음)의 로드 측면에서 삽입은 이미 상당히 높았습니다. 그런 다음 다양한 매개변수를 늘렸습니다: 히스토리 싱커, 캐시... 이 하드웨어에서 히스토리 싱커의 로드는 거의 "선반에서" 최대치로 증가하기 시작했습니다. 따라서 HistoryCache의 로드는 매우 높아졌습니다.

이번에는 모든 시스템 매개변수(프로세서 사용 방식, RAM)를 모니터링하고 디스크 활용도가 최대임을 확인했습니다. 이 하드웨어, 이 가상 머신에서 이 디스크의 최대 용량을 달성했습니다. "Postgres"는 이러한 강도로 매우 적극적으로 데이터를 덤프하기 시작했으며 디스크에는 더 이상 쓰고 읽을 시간이 없었습니다.

저는 이미 48개의 프로세서와 128GB의 RAM을 갖춘 다른 서버를 사용했습니다.

나는 또한 그것을 "조정"했습니다. History syncer(60개)를 설치하고 허용 가능한 성능을 달성했습니다. 사실, 우리는 "선반"에 있지는 않지만 아마도 생산성의 한계일 것이며 이에 대해 이미 조치를 취해야 할 것입니다.

성능 검사. TimescaleDB: 80NVP

나의 주요 업무는 TimescaleDB를 사용하는 것이었습니다. 각 그래프는 하락을 보여줍니다.

이러한 실패는 바로 데이터 마이그레이션입니다. 그 후 Zabbix 서버에서는 보시다시피 히스토리 싱커의 로딩 프로필이 많이 변경되었습니다. 이를 통해 데이터를 거의 3배 더 빠르게 삽입하고 HistoryCache를 덜 사용할 수 있으므로 데이터가 제 시간에 전달됩니다. 다시 말하지만, 초당 80개의 값은 상당히 높은 비율입니다(물론 Yandex의 경우는 아님). 전반적으로 이것은 하나의 서버를 갖춘 상당히 큰 설정입니다.

PostgreSQL 성능 테스트: 120만 NVP

다음으로 데이터 요소 수의 값을 125만개로 늘렸고 초당 XNUMX개의 계산된 값을 받았습니다.

그리고 나는 다음과 같은 그래프를 얻었습니다.

원칙적으로 이것은 작업 설정이므로 꽤 오랫동안 작동할 수 있습니다. 하지만 내겐 1,5테라바이트의 디스크밖에 없었기 때문에 며칠 만에 다 써버렸습니다. 가장 중요한 것은 동시에 TimescaleDB에 새로운 파티션이 생성되었는데 이는 MySQL에 대해서는 말할 수 없는 성능 측면에서 전혀 눈에 띄지 않았다는 것입니다.

일반적으로 파티션은 밤에 생성됩니다. 이는 일반적으로 삽입 및 테이블 작업을 차단하고 서비스 성능 저하를 초래할 수 있기 때문입니다. 이 경우에는 그렇지 않습니다! 주요 작업은 TimescaleDB의 기능을 테스트하는 것이었습니다. 결과는 초당 120개의 값이었습니다.

커뮤니티에는 다음과 같은 예도 있습니다.

그 사람은 또한 TimescaleDB를 켰고 io.weight 사용에 대한 부하가 프로세서에 떨어졌습니다. TimescaleDB를 포함함으로써 내부 프로세스 요소의 사용도 감소했습니다. 또한 이는 일반 팬케이크 디스크, 즉 SSD가 아닌 일반 디스크의 일반 가상 머신입니다!

디스크 성능으로 인해 제한되는 일부 소규모 설정의 경우 TimescaleDB가 매우 좋은 솔루션이라고 생각합니다. 이를 통해 데이터베이스를 위해 더 빠른 하드웨어로 마이그레이션하기 전에 계속 작업할 수 있습니다.

모스크바 회의, 리가 정상회담 등의 행사에 여러분 모두를 초대합니다. Telegram, 포럼, IRC 등의 채널을 사용하세요. 질문이 있으시면 저희 데스크로 오세요. 모든 것에 대해 이야기해 드릴 수 있습니다.

청중 질문

청중의 질문(이하 A): - TimescaleDB가 구성하기 쉽고 성능이 크게 향상된다면 Postgres로 Zabbix를 구성하는 모범 사례로 이를 사용해야 합니까? 그리고 이 솔루션에는 함정과 단점이 있습니까? 아니면 결국 제가 Zabbix를 직접 만들기로 결정했다면 쉽게 Postgres를 사용하여 거기에 Timescale을 설치하고 사용할 수 있으며 어떤 문제도 생각하지 않을 수 있습니까?

AG: – 예, 이것이 좋은 권장 사항이라고 말하고 싶습니다. Postgres를 TimescaleDB 확장과 함께 즉시 사용하십시오. 이미 말했듯이 이 "기능"이 실험적이라는 사실에도 불구하고 많은 좋은 리뷰가 있습니다. 그러나 실제로 테스트를 통해 이것이 훌륭한 솔루션(TimescaleDB 포함)이라는 것이 나타났으며 앞으로 발전할 것이라고 생각합니다! 우리는 이 확장 프로그램이 어떻게 개발되고 필요에 따라 변경될 것인지 모니터링하고 있습니다.

개발 중에도 우리는 잘 알려진 "기능" 중 하나에 의존했습니다. 즉, 청크를 조금 다르게 작업하는 것이 가능했습니다. 하지만 다음 릴리스에서는 이 코드를 삭제했고 우리는 이 코드에 더 이상 의존하지 않게 되었습니다. 다양한 설정에서 이 솔루션을 사용하는 것이 좋습니다. MySQL을 사용하는 경우... 평균 설정의 경우 모든 솔루션이 잘 작동합니다.

A : – 커뮤니티의 마지막 그래프에는 "Housekeeper"라는 그래프가 있었습니다.

그는 계속 일했습니다. Housekeeper는 TimescaleDB로 무엇을 합니까?

AG: – 지금은 확실히 말씀드릴 수 없습니다. – 코드를 보고 좀 더 자세히 말씀드리겠습니다. 청크를 삭제하는 것이 아니라 어떻게든 집계하기 위해 TimescaleDB 쿼리를 사용합니다. 아직 이 기술적인 질문에 답변할 준비가 되지 않았습니다. 자세한 내용은 오늘이나 내일 스탠드에서 알아보겠습니다.

A : – Timescale의 삭제 작업 성능에 대해 비슷한 질문이 있습니다.
A(청중의 답변): – 테이블에서 데이터를 삭제할 때 삭제를 통해 수행하는 경우 테이블을 통과해야 합니다. 삭제, 정리, 향후 진공을 위해 모든 것을 표시합니다. Timescale에서는 청크가 있으므로 삭제할 수 있습니다. 대략적으로 말하면, 빅데이터에 있는 파일에 "삭제!"라고 말하면 됩니다.

Timescale은 그러한 덩어리가 더 이상 존재하지 않는다는 것을 단순히 이해합니다. 그리고 쿼리 플래너에 통합되어 있기 때문에 후크를 사용하여 선택 또는 기타 작업에서 조건을 파악하고 이 청크가 더 이상 존재하지 않는다는 것을 즉시 이해합니다. "더 이상 거기에 가지 않겠습니다!" (데이터를 사용할 수 없음). 그게 다야! 즉, 테이블 스캔을 바이너리 파일 삭제로 대체하므로 속도가 빠릅니다.

A : – 우리는 이미 비SQL 주제를 다루었습니다. 내가 아는 한 Zabbix는 실제로 데이터를 수정할 필요가 없으며 이 모든 것은 로그와 같습니다. 데이터를 변경할 수 없지만 동시에 훨씬 빠르게 저장, 축적 및 배포할 수 있는 특수 데이터베이스를 사용할 수 있습니까? 예를 들어 Kafka와 같은 Clickhouse?.. Kafka도 로그입니다! 어떻게든 통합할 수 있나요?

AG: - 언로드가 가능합니다. 버전 3.4부터 특정 "기능"이 있습니다. 모든 기록 파일, 이벤트, 기타 모든 것을 파일에 쓸 수 있습니다. 그런 다음 일부 핸들러를 사용하여 다른 데이터베이스로 보냅니다. 실제로 많은 사람들이 재작업을 하고 데이터베이스에 직접 기록합니다. 즉시 히스토리 싱커는 이 모든 것을 파일에 기록하고, 이러한 파일을 회전시키는 등의 작업을 수행하며 이를 클릭하우스로 전송할 수 있습니다. 계획에 대해서는 말할 수 없지만 NoSQL 솔루션(예: Clickhouse)에 대한 추가 지원은 계속될 것입니다.

A : – 일반적으로 Postgres를 완전히 제거할 수 있다는 것이 밝혀졌습니다.

AG: – 물론, Zabbix에서 가장 어려운 부분은 가장 많은 문제와 사건을 만들어내는 기록 테이블입니다. 이 경우 이벤트를 장기간 저장하지 않고 다른 빠른 스토리지에 트렌드와 함께 히스토리를 저장하면 일반적으로 문제가 없을 것이라고 생각합니다.

A : – 예를 들어 Clickhouse로 전환하면 모든 것이 얼마나 더 빨리 작동할지 예측할 수 있습니까?

AG: – 테스트해본 적은 없습니다. Clickhouse에 자체 인터페이스가 있다는 점을 고려하면 최소한 동일한 수치를 매우 간단하게 달성할 수 있다고 생각하지만 확실하게 말할 수는 없습니다. 테스트해 보는 것이 좋습니다. 그것은 모두 구성, 즉 보유하고 있는 호스트 수 등에 따라 다릅니다. 삽입도 중요하지만 이 데이터(Grafana 등)를 검색해야 합니다.

A : – 그렇다면 우리는 동등한 싸움에 대해 이야기하고 있는 것이지 이러한 빠른 데이터베이스의 큰 이점에 대해서는 이야기하고 있지 않습니까?

AG: - 통합하면 좀 더 정확한 테스트가 나올 것 같아요.

A : – 옛날 RRD는 어디로 갔나요? SQL 데이터베이스로 전환하게 된 이유는 무엇입니까? 처음에는 모든 지표가 RRD에서 수집되었습니다.

AG: – Zabbix에는 아마도 매우 오래된 버전의 RRD가 있었습니다. SQL 데이터베이스는 항상 존재해 왔으며 이는 고전적인 접근 방식입니다. 고전적인 접근 방식은 MySQL, PostgreSQL입니다(매우 오랫동안 존재해 왔습니다). 우리는 SQL 및 RRD 데이터베이스에 공통 인터페이스를 거의 사용하지 않았습니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $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