VictoriaMetrics에서 최적화를 진행하세요. 알렉산더 발리알킨

Alexander Valyalkin이 작성한 2019년 후반 보고서 "VictoriaMetrics의 Go 최적화" 내용을 읽어 보시기 바랍니다.

빅토리아메트릭스 — 시계열 형태로 데이터를 저장하고 처리하기 위한 빠르고 확장 가능한 DBMS(기록은 시간과 이 시간에 해당하는 값 집합을 형성합니다. 예를 들어 센서 상태에 대한 주기적인 폴링 또는 수집을 통해 얻은 값) 측정항목).

다음은 이 보고서의 동영상 링크입니다. https://youtu.be/MZ5P21j_HLE

슬라이드

자신에 대해 알려주십시오. 저는 알렉산더 발얄킨입니다. 여기 내 GitHub 계정. 저는 Go와 성능 최적화에 열정을 갖고 있습니다. 나는 유용하지만 그다지 유용하지 않은 라이브러리를 많이 썼습니다. 그들은 다음 중 하나로 시작합니다. fast, 또는 quick 접두사.

저는 현재 VictoriaMetrics에서 일하고 있습니다. 그게 뭐고, 내가 거기서 뭘 하고 있지? 이번 프레젠테이션에서 이에 대해 이야기하겠습니다.

보고서의 개요는 다음과 같습니다.

• 먼저 VictoriaMetrics가 무엇인지 알려드리겠습니다.
• 그럼 시계열이 무엇인지 알려드리겠습니다.
• 그런 다음 시계열 데이터베이스가 어떻게 작동하는지 알려 드리겠습니다.
• 다음으로 데이터베이스 아키텍처에 대해 설명하겠습니다. 구성 요소는 무엇입니까?
• 그런 다음 VictoriaMetrics의 최적화로 넘어가겠습니다. 이는 반전된 인덱스에 대한 최적화이자 Go의 비트세트 구현에 대한 최적화입니다.

청중 중에 VictoriaMetrics가 무엇인지 아는 사람이 있나요? 와, 이미 많은 분들이 알고 계시네요. 좋은 소식이에요. 모르는 사람들을 위해 이것은 시계열 데이터베이스입니다. 이는 ClickHouse 구현의 일부 세부 사항에 대한 ClickHouse 아키텍처를 기반으로 합니다. 예를 들어 MergeTree에서는 사용 가능한 모든 프로세서 코어에 대한 병렬 계산 및 프로세서 캐시에 있는 데이터 블록 작업을 통한 성능 최적화가 가능합니다.

VictoriaMetrics는 다른 시계열 데이터베이스보다 더 나은 데이터 압축을 제공합니다.

수직으로 확장됩니다. 즉, 한 컴퓨터에 더 많은 프로세서와 더 많은 RAM을 추가할 수 있습니다. VictoriaMetrics는 이러한 가용 리소스를 성공적으로 활용하고 선형 생산성을 향상시킬 것입니다.

VictoriaMetrics는 또한 수평적으로 확장됩니다. 즉, VictoriaMetrics 클러스터에 추가 노드를 추가할 수 있으며 성능은 거의 선형적으로 향상됩니다.

짐작하셨듯이 VictoriaMetrics는 빠른 데이터베이스입니다. 왜냐하면 저는 다른 사람을 작성할 수 없기 때문입니다. 그리고 그것은 Go로 작성되었기 때문에 이번 모임에서 그것에 대해 이야기하고 있습니다.

시계열이 무엇인지 아는 사람은 누구입니까? 그는 또한 많은 사람들을 알고 있습니다. 시계열은 일련의 쌍입니다. (timestamp, значение), 여기서 이러한 쌍은 시간별로 정렬됩니다. 값은 부동 소수점 숫자(float64)입니다.

각 시계열은 키로 고유하게 식별됩니다. 이 열쇠는 무엇으로 구성되어 있나요? 비어 있지 않은 키-값 쌍 세트로 구성됩니다.

다음은 시계열의 예입니다. 이 시리즈의 핵심은 쌍 목록입니다. __name__="cpu_usage" 측정항목의 이름입니다. instance="my-server" - 이 지표가 수집되는 컴퓨터입니다. datacenter="us-east" - 이 컴퓨터가 위치한 데이터 센터입니다.

우리는 세 개의 키-값 쌍으로 구성된 시계열 이름을 얻었습니다. 이 키는 쌍 목록에 해당합니다. (timestamp, value). t1, t3, t3, ..., tN - 이것은 타임스탬프입니다. 10, 20, 12, ..., 15 - 해당 값. 이는 특정 시리즈에 대한 특정 시간의 CPU 사용량입니다.

시계열은 어디에 사용될 수 있나요? 누구든지 어떤 생각을 가지고 있습니까?

• DevOps에서는 CPU, RAM, 네트워크, rps, 오류 수 등을 측정할 수 있습니다.
• IoT - 온도, 압력, 지리 좌표 등을 측정할 수 있습니다.
• 또한 금융 – 모든 종류의 주식과 통화의 가격을 모니터링할 수 있습니다.
• 또한 시계열은 공장의 생산 프로세스를 모니터링하는 데 사용될 수 있습니다. VictoriaMetrics를 사용하여 로봇용 풍력 터빈을 모니터링하는 사용자가 있습니다.
• 시계열은 다양한 장치의 센서에서 정보를 수집하는 데에도 유용합니다. 예를 들어, 엔진의 경우; 타이어 압력 측정용; 속도, 거리 측정용; 휘발유 소비량 측정 등
• 시계열은 항공기를 모니터링하는 데에도 사용될 수 있습니다. 각 항공기에는 항공기 상태의 다양한 매개변수에 대한 시계열을 수집하는 블랙박스가 있습니다. 시계열은 항공우주 산업에서도 사용됩니다.
• 헬스케어는 혈압, 맥박 등이다.

제가 잊어버린 응용 사례가 더 있을 수 있지만, 현대 사회에서는 시계열이 활발하게 사용되고 있다는 점을 이해해 주시길 바랍니다. 그리고 그 사용량은 매년 증가하고 있습니다.

시계열 데이터베이스가 필요한 이유는 무엇입니까? 시계열을 저장하기 위해 일반 관계형 데이터베이스를 사용할 수 없는 이유는 무엇입니까?

시계열에는 일반적으로 많은 양의 정보가 포함되어 있어 기존 데이터베이스에 저장하고 처리하기 어렵기 때문입니다. 따라서 시계열에 대한 전문적인 데이터베이스가 등장했습니다. 이 기지는 포인트를 효과적으로 저장합니다. (timestamp, value) 주어진 키로. 키, 단일 키-값 쌍, 여러 키-값 쌍 또는 정규 표현식을 통해 저장된 데이터를 읽기 위한 API를 제공합니다. 예를 들어, 미국 데이터 센터에 있는 모든 서비스의 CPU 로드를 찾으려면 이 의사 쿼리를 사용해야 합니다.

일반적으로 시계열 데이터베이스는 시계열 SQL이 그다지 적합하지 않기 때문에 특수 쿼리 언어를 제공합니다. SQL을 지원하는 데이터베이스가 있지만 그다지 적합하지는 않습니다. 다음과 같은 쿼리 언어 PromQL, InfluxQL, 유량, Q. 누군가가 이 언어 중 적어도 하나를 들어봤기를 바랍니다. 아마도 많은 사람들이 PromQL에 대해 들어봤을 것입니다. 이것은 Prometheus 쿼리 언어입니다.

이것은 VictoriaMetrics를 예로 사용하는 현대 시계열 데이터베이스 아키텍처의 모습입니다.

두 부분으로 구성됩니다. 이는 반전된 인덱스를 위한 저장소이자 시계열 값을 위한 저장소입니다. 이러한 저장소는 분리되어 있습니다.

새 레코드가 데이터베이스에 도착하면 먼저 반전된 인덱스에 액세스하여 주어진 세트에 대한 시계열 식별자를 찾습니다. label=value 특정 측정항목에 대해 이 식별자를 찾아 데이터 저장소에 값을 저장합니다.

TSDB에서 데이터를 검색하라는 요청이 오면 먼저 반전된 인덱스로 이동합니다. 모든 것을 얻자 timeseries_ids 이 세트와 일치하는 레코드 label=value. 그런 다음 데이터 웨어하우스에서 다음과 같이 색인화되어 필요한 모든 데이터를 가져옵니다. timeseries_ids.

시계열 데이터베이스가 들어오는 선택 쿼리를 처리하는 방법에 대한 예를 살펴보겠습니다.

• 우선 그녀는 모든 것을 얻습니다. timeseries_ids 주어진 쌍을 포함하는 반전된 인덱스에서 label=value, 또는 주어진 정규식을 만족시킵니다.
• 그런 다음 발견된 데이터에 대해 지정된 시간 간격으로 데이터 저장소에서 모든 데이터 포인트를 검색합니다. timeseries_ids.
• 그 후, 데이터베이스는 사용자의 요청에 따라 이러한 데이터 포인트에 대해 일부 계산을 수행합니다. 그리고 그 후에는 답을 반환합니다.

이번 프레젠테이션에서는 첫 번째 부분에 대해 설명하겠습니다. 검색입니다 timeseries_ids 반전된 인덱스로. 두 번째 부분과 세 번째 부분은 나중에 시청하시면 됩니다 VictoriaMetrics 소스, 아니면 제가 다른 보고서를 준비할 때까지 기다리세요 :)

반전된 인덱스로 넘어가겠습니다. 많은 사람들은 이것이 간단하다고 생각할 수도 있습니다. 반전 인덱스가 무엇이고 어떻게 작동하는지 아는 사람이 있나요? 아, 이제 사람이 많지 않네요. 그것이 무엇인지 이해하려고 노력합시다.

실제로는 간단합니다. 이는 단순히 키를 값에 매핑하는 사전입니다. 열쇠란 무엇입니까? 이 커플 label=value어디에서 label и value - 이것은 선입니다. 그리고 값은 세트입니다 timeseries_ids, 이는 주어진 쌍을 포함합니다. label=value.

역색인을 사용하면 모든 것을 빠르게 찾을 수 있습니다. timeseries_ids, 이는 label=value.

또한 빠르게 찾을 수 있도록 해줍니다. timeseries_ids 여러 쌍에 대한 시계열 label=value또는 커플용 label=regexp. 어떻게 이런 일이 발생하나요? 집합의 교집합을 찾아 timeseries_ids 각 쌍마다 label=value.

반전된 인덱스의 다양한 구현을 살펴보겠습니다. 가장 간단한 순진한 구현부터 시작해 보겠습니다. 그녀는 이렇게 생겼습니다.

기능 getMetricIDs 문자열 목록을 가져옵니다. 각 줄에는 다음이 포함됩니다. label=value. 이 함수는 목록을 반환합니다. metricIDs.

어떻게 작동하나요? 여기에는 전역 변수라는 전역 변수가 있습니다. invertedIndex. 이것은 일반 사전(map), 이는 문자열을 슬라이스 int에 매핑합니다. 줄에는 다음이 포함됩니다. label=value.

함수 구현: 가져오기 metricIDs 처음으로 label=value, 그런 다음 다른 모든 작업을 진행합니다. label=value, 우리는 그것을 얻습니다 metricIDs 그들을 위해. 그리고 함수를 호출하세요. intersectInts, 이에 대해서는 아래에서 설명합니다. 그리고 이 함수는 이들 목록의 교집합을 반환합니다.

보시다시피, 반전된 인덱스를 구현하는 것은 그리 복잡하지 않습니다. 그러나 이것은 순진한 구현입니다. 어떤 단점이 있나요? 순진한 구현의 가장 큰 단점은 이러한 반전된 인덱스가 RAM에 저장된다는 것입니다. 애플리케이션을 다시 시작하면 이 인덱스가 손실됩니다. 이 인덱스는 디스크에 저장되지 않습니다. 이러한 반전 인덱스는 데이터베이스에 적합하지 않습니다.

두 번째 단점은 메모리와도 관련이 있습니다. 반전된 인덱스는 RAM에 맞아야 합니다. RAM 크기를 초과하면 당연히 메모리 부족 오류가 발생합니다. 그리고 프로그램이 작동하지 않습니다.

이 문제는 다음과 같은 기성 솔루션을 사용하여 해결할 수 있습니다. 레벨DB또는 RocksDB.

간단히 말해서, 세 가지 작업을 빠르게 수행할 수 있는 데이터베이스가 필요합니다.

• 첫 번째 작업은 녹음입니다 ключ-значение 이 데이터베이스에. 그녀는 이 일을 아주 빨리 해냅니다. ключ-значение 임의의 문자열입니다.
• 두 번째 작업은 주어진 키를 사용하여 값을 빠르게 검색하는 것입니다.
• 그리고 세 번째 작업은 주어진 접두사를 기준으로 모든 값을 빠르게 검색하는 것입니다.

LevelDB 및 RocksDB - 이 데이터베이스는 Google과 Facebook에서 개발했습니다. 처음에는 LevelDB가 나왔습니다. 그러다가 Facebook 사람들이 LevelDB를 가져와 개선하기 시작했고 RocksDB를 만들었습니다. 이제 RocksDB 및 MySQL로 전송된 데이터베이스를 포함하여 거의 모든 내부 데이터베이스가 Facebook 내부의 RocksDB에서 작동합니다. 그들은 그에게 이름을 지어주었다 마이록스.

반전 인덱스는 LevelDB를 사용하여 구현할 수 있습니다. 어떻게 하나요? 우리는 열쇠로 저장합니다 label=value. 그리고 값은 쌍이 존재하는 시계열의 식별자입니다. label=value.

주어진 쌍에 대해 많은 시계열이 있는 경우 label=value, 그러면 이 데이터베이스에는 동일한 키와 다른 행이 많이 있을 것입니다. timeseries_ids. 모든 목록을 얻으려면 timeseries_ids, 이것으로 시작하는 label=prefix, 우리는 이 데이터베이스가 최적화된 범위 스캔을 수행합니다. 즉, 다음으로 시작하는 모든 행을 선택합니다. label=prefix 그리고 필요한 것을 얻으세요 timeseries_ids.

Go에서 어떻게 보일지에 대한 샘플 구현은 다음과 같습니다. 반전된 인덱스가 있습니다. 레벨DB 입니다.

기능은 단순 구현과 동일합니다. 거의 한 줄씩 순진한 구현을 반복합니다. 유일한 요점은 map 반전된 인덱스에 액세스합니다. 우리는 첫 번째 값을 모두 얻습니다. label=value. 그런 다음 나머지 모든 쌍을 살펴보겠습니다. label=value 그에 상응하는 metricID 세트를 가져옵니다. 그런 다음 교차점을 찾습니다.

모든 것이 괜찮은 것 같지만 이 솔루션에는 단점이 있습니다. VictoriaMetrics는 처음에 LevelDB를 기반으로 한 반전 인덱스를 구현했습니다. 하지만 결국 포기해야 했어요.

왜? LevelDB는 순진한 구현보다 느리기 때문입니다. 순진한 구현에서는 주어진 키가 주어지면 전체 슬라이스를 즉시 검색합니다. metricIDs. 이는 매우 빠른 작업입니다. 전체 슬라이스를 사용할 준비가 되었습니다.

LevelDB에서는 함수가 호출될 때마다 GetValues 다음으로 시작하는 모든 줄을 통과해야 합니다. label=value. 그리고 각 줄의 값을 얻으십시오. timeseries_ids. 그런 것 중 timeseries_ids 이것들 중 한 조각을 모아라 timeseries_ids. 분명히 이것은 단순히 키로 일반 맵에 액세스하는 것보다 훨씬 느립니다.

두 번째 단점은 LevelDB가 C로 작성되었다는 것입니다. Go에서 C 함수를 호출하는 것은 그다지 빠르지 않습니다. 수백 나노초가 걸립니다. 1~5나노초가 걸리는 go로 작성된 일반 함수 호출과 비교하면 성능 차이가 수십 배나 되기 때문에 이는 그리 빠르지 않습니다. VictoriaMetrics의 경우 이는 치명적인 결함이었습니다 :)

그래서 저는 반전된 인덱스를 구현하는 방법을 직접 작성했습니다. 그리고 그는 그녀에게 전화를 했어요 병합 세트.

Mergeset은 MergeTree 데이터 구조를 기반으로 합니다. 이 데이터 구조는 ClickHouse에서 차용되었습니다. 분명히 머지셋은 빠른 검색을 위해 최적화되어야 합니다. timeseries_ids 주어진 키에 따라. Mergeset은 전적으로 Go로 작성되었습니다. 너는 볼 수있어 GitHub의 VictoriaMetrics 소스. 병합 집합의 구현은 폴더에 있습니다. /lib/병합 집합. 거기에서 무슨 일이 일어나고 있는지 알아 내려고 노력할 수 있습니다.

mergeset API는 LevelDB 및 RocksDB와 매우 유사합니다. 즉, 새 레코드를 거기에 빠르게 저장하고 주어진 접두어로 레코드를 빠르게 선택할 수 있습니다.

나중에 mergeset의 단점에 대해 이야기하겠습니다. 이제 역 인덱스를 구현할 때 프로덕션 환경에서 VictoriaMetrics에 어떤 문제가 발생했는지 이야기해 보겠습니다.

왜 그런 일들이 일어났는가?

첫 번째 이유는 높은 이탈률입니다. 러시아어로 번역하면 시계열이 자주 변경됩니다. 이것은 시계열이 끝나고 새로운 시계열이 시작되거나 많은 새로운 시계열이 시작되는 때입니다. 그리고 이런 일이 자주 발생합니다.

두 번째 이유는 시계열의 수가 많기 때문입니다. 모니터링이 인기를 끌던 초기에는 시계열의 수가 적었습니다. 예를 들어, 각 컴퓨터에 대해 CPU, 메모리, 네트워크 및 디스크 로드를 모니터링해야 합니다. 컴퓨터당 시계열 4개. 컴퓨터 100대와 시계열 400개가 있다고 가정해 보겠습니다. 이것은 매우 적습니다.

시간이 지나면서 사람들은 더욱 세부적인 정보를 측정할 수 있다는 사실을 깨달았습니다. 예를 들어 전체 프로세서의 부하가 아닌 각 프로세서 코어의 부하를 별도로 측정합니다. 40개의 프로세서 코어가 있는 경우 프로세서 로드를 측정할 수 있는 시계열이 40배 더 많습니다.

그러나 그것이 전부는 아닙니다. 각 프로세서 코어는 유휴 상태인 경우와 같은 여러 상태를 가질 수 있습니다. 또한 사용자 공간, 커널 공간 및 기타 상태에서도 작업합니다. 그리고 이러한 각 상태는 별도의 시계열로 측정될 수도 있습니다. 이로 인해 행 수가 7~8배 추가로 늘어납니다.

하나의 측정항목에서 단 하나의 컴퓨터에 대해 40 x 8 = 320개의 측정항목을 얻었습니다. 100을 곱하면 32이 아닌 000이 됩니다.

그런 다음 Kubernetes가 나타났습니다. 그리고 Kubernetes가 다양한 서비스를 호스팅할 수 있기 때문에 상황은 더욱 악화되었습니다. Kubernetes의 각 서비스는 여러 포드로 구성됩니다. 그리고 이 모든 것을 모니터링해야 합니다. 또한 당사는 귀하의 서비스에 대한 새로운 버전을 지속적으로 배포하고 있습니다. 새 버전마다 새 시계열을 생성해야 합니다. 결과적으로 시계열의 개수가 기하급수적으로 늘어나고, 이를 하이 카디널리티(high-cardinality)라고 부르는 시계열 개수가 많아지는 문제에 직면하게 됩니다. VictoriaMetrics는 다른 시계열 데이터베이스와 비교하여 이에 성공적으로 대처합니다.

높은 이탈률에 대해 자세히 살펴보겠습니다. 생산 과정에서 이탈률이 높은 이유는 무엇입니까? 라벨과 태그의 일부 의미는 끊임없이 변하기 때문입니다.

예를 들어 다음과 같은 개념이 있는 Kubernetes를 살펴보겠습니다. deployment, 즉 애플리케이션의 새 버전이 출시되는 경우입니다. 어떤 이유로 Kubernetes 개발자는 배포 ID를 레이블에 추가하기로 결정했습니다.

이것이 무엇으로 이어졌나요? 또한 새로운 배포가 있을 때마다 이전 시계열이 모두 중단되고 대신 새 시계열이 새 레이블 값으로 시작됩니다. deployment_id. 그러한 행은 수십만, 심지어 수백만 개가 있을 수 있습니다.

이 모든 것에서 중요한 점은 시계열의 전체 개수는 늘어나지만 현재 활성화되어 데이터를 수신하는 시계열의 개수는 일정하게 유지된다는 점입니다. 이 상태를 높은 이탈률이라고 합니다.

높은 이탈률의 주요 문제는 특정 시간 간격 동안 특정 레이블 집합에 대한 모든 시계열에 대해 일정한 검색 속도를 보장하는 것입니다. 일반적으로 이는 지난 시간 또는 마지막 날의 시간 간격입니다.

이 문제를 해결하는 방법? 첫 번째 옵션은 다음과 같습니다. 이는 반전된 지수를 시간에 따라 독립된 부분으로 나누는 것입니다. 즉, 약간의 시간 간격이 지나면 현재 반전 인덱스 작업이 완료됩니다. 그리고 새로운 반전 인덱스를 생성합니다. 또 다른 시간 간격이 지나면 우리는 또 다른 시간 간격을 만듭니다.

그리고 이러한 반전된 인덱스에서 샘플링할 때 주어진 간격 내에 속하는 반전된 인덱스 집합을 찾습니다. 따라서 우리는 거기에서 시계열의 ID를 선택합니다.

이렇게 하면 주어진 간격에 속하지 않는 부분을 볼 필요가 없기 때문에 리소스가 절약됩니다. 즉, 일반적으로 지난 시간의 데이터를 선택하면 이전 시간 간격에 대해서는 요청을 건너뜁니다.

이 문제를 해결하는 또 다른 옵션이 있습니다. 이는 해당 날짜에 발생한 시계열 ID의 별도 목록을 매일 저장하기 위한 것입니다.

이전 솔루션에 비해 이 솔루션의 장점은 시간이 지나도 사라지지 않는 시계열 정보를 복제하지 않는다는 것입니다. 그것들은 끊임없이 존재하며 변하지 않습니다.

단점은 이러한 솔루션을 구현하기가 더 어렵고 디버그하기가 더 어렵다는 것입니다. 그리고 VictoriaMetrics는 이 솔루션을 선택했습니다. 역사적으로 이런 일이 일어났습니다. 이 솔루션은 이전 솔루션에 비해 성능도 좋습니다. 왜냐하면 변경되지 않는, 즉 시간이 지나도 사라지지 않는 시계열에 대해 각 파티션에 데이터를 복제해야 한다는 사실 때문에 이 솔루션이 구현되지 않았기 때문입니다. VictoriaMetrics는 주로 디스크 공간 소비에 맞춰 최적화되었으며 이전 구현으로 인해 디스크 공간 소비가 더 심해졌습니다. 그러나 이 구현은 디스크 공간 소비를 최소화하는 데 더 적합하므로 선택되었습니다.

나는 그녀와 싸워야 했다. 어려움은 이 구현에서 여전히 훨씬 더 큰 숫자를 선택해야 한다는 것이었습니다. timeseries_ids 역 인덱스가 시간 분할된 경우보다 데이터의 경우.

이 문제를 어떻게 해결했나요? 우리는 하나의 식별자 대신 각 반전된 인덱스 항목에 여러 개의 시계열 식별자를 저장하는 독창적인 방식으로 이 문제를 해결했습니다. 즉, 우리는 열쇠를 가지고 있습니다 label=value, 이는 모든 시계열에서 발생합니다. 이제 우리는 여러 가지를 저장합니다 timeseries_ids 한 항목에.

여기에 예가 있습니다. 이전에는 N개의 항목이 있었지만 이제는 접두사가 다른 모든 항목과 동일한 항목이 하나 있습니다. 이전 항목의 경우 값에는 모든 시계열 ID가 포함됩니다.

이를 통해 이러한 반전 인덱스의 스캔 속도를 최대 10배까지 높일 수 있었습니다. 그리고 이제 문자열을 저장하므로 캐시에 대한 메모리 소비를 줄일 수 있었습니다. label=value 캐시에 한 번만 N 번 함께 저장됩니다. 그리고 태그와 라벨에 Kubernetes가 삽입하기를 좋아하는 긴 줄을 저장하면 이 줄이 커질 수 있습니다.

반전된 인덱스에서 검색 속도를 높이는 또 다른 옵션은 샤딩입니다. 하나가 아닌 여러 개의 반전된 인덱스를 생성하고 키별로 데이터를 샤딩합니다. 이것은 세트입니다 key=value 증기. 즉, 여러 프로세서에서 병렬로 쿼리할 수 있는 여러 개의 독립적인 반전 인덱스를 얻습니다. 이전 구현에서는 단일 프로세서 모드에서만 작업이 허용되었습니다. 즉, 하나의 코어에서만 데이터를 스캔할 수 있었습니다. 이 솔루션을 사용하면 ClickHouse가 선호하는 것처럼 한 번에 여러 코어의 데이터를 스캔할 수 있습니다. 이것이 우리가 구현할 계획입니다.

이제 양으로 돌아가서 교차 기능으로 돌아가 보겠습니다. timeseries_ids. 어떤 구현이 있을 수 있는지 생각해 봅시다. 이 기능을 사용하면 다음을 찾을 수 있습니다. timeseries_ids 주어진 세트에 대해 label=value.

첫 번째 옵션은 순진한 구현입니다. 두 개의 중첩 루프. 여기서 우리는 함수 입력을 얻습니다. intersectInts 두 조각 - a и b. 출력에서는 이러한 조각의 교차점을 반환해야 합니다.

순진한 구현은 다음과 같습니다. 우리는 슬라이스의 모든 값을 반복합니다 a, 이 루프 내에서 우리는 슬라이스의 모든 값을 살펴봅니다. b. 그리고 우리는 그것들을 비교합니다. 일치하면 교차점을 찾은 것입니다. 그리고 그것을 저장하세요. result.

단점은 무엇입니까? XNUMX차 복잡성이 주요 단점입니다. 예를 들어 차원이 슬라이스인 경우 a и b 한 번에 백만 개를 입력하면 이 함수는 결코 답을 반환하지 않습니다. XNUMX조 번의 반복이 필요하기 때문입니다. 이는 현대 컴퓨터의 경우에도 많은 양입니다.

두 번째 구현은 지도를 기반으로 합니다. 지도를 작성합니다. 우리는 슬라이스의 모든 값을 이 맵에 넣습니다. a. 그런 다음 별도의 루프에서 슬라이스를 진행합니다. b. 그리고 이 값이 슬라이스에서 나온 것인지 확인합니다. b 지도에서. 존재하는 경우 결과에 추가하십시오.

이점은 무엇입니까? 장점은 선형 복잡도만 있다는 것입니다. 즉, 더 큰 조각에 대해 함수가 훨씬 빠르게 실행됩니다. 백만 크기 조각의 경우 이 함수는 이전 함수의 2조 반복과 달리 XNUMX만 반복으로 실행됩니다.

단점은 이 함수가 이 맵을 생성하는 데 더 많은 메모리가 필요하다는 것입니다.

두 번째 단점은 해싱에 대한 오버헤드가 크다는 것입니다. 이 단점은 그다지 명확하지 않습니다. 그리고 우리에게도 그것은 그다지 명확하지 않았기 때문에 처음에는 VictoriaMetrics에서 교차로의 구현이 지도를 통해 이루어졌습니다. 그러나 프로파일링을 통해 메인 프로세서 시간이 맵에 쓰고 이 맵에 값이 있는지 확인하는 데 소요되는 것으로 나타났습니다.

왜 이런 곳에서 CPU 시간이 낭비되나요? Go는 이러한 라인에 대해 해싱 작업을 수행하기 때문입니다. 즉, HashMap의 지정된 인덱스에 액세스하기 위해 키의 해시를 계산합니다. 해시 계산 작업은 수십 나노초 안에 완료됩니다. VictoriaMetrics의 경우 속도가 느립니다.

나는 이 경우에 특별히 최적화된 비트셋을 구현하기로 결정했습니다. 이것이 두 조각의 교차점의 모습입니다. 여기서는 비트세트를 만듭니다. 첫 번째 슬라이스의 요소를 여기에 추가합니다. 그런 다음 두 번째 슬라이스에 이러한 요소가 있는지 확인합니다. 그리고 결과에 추가하세요. 즉, 앞선 예와 거의 다르지 않습니다. 여기서 유일한 것은 지도에 대한 액세스를 사용자 정의 함수로 대체했다는 것입니다. add и has.

언뜻 보기에는 이전에 표준 지도를 사용한 다음 다른 함수를 호출하면 이 작업이 더 느리게 작동해야 하는 것처럼 보이지만, 프로파일링을 보면 VictoriaMetrics의 경우 이 작업이 표준 지도보다 10배 더 빠르게 작동하는 것으로 나타났습니다.

또한 맵 구현에 비해 훨씬 적은 메모리를 사용합니다. 왜냐하면 여기에 XNUMX바이트 값 대신 비트를 저장하기 때문입니다.

이 구현의 단점은 그렇게 명확하지도 사소하지도 않다는 것입니다.

많은 사람들이 눈치채지 못하는 또 다른 단점은 이 구현이 어떤 경우에는 제대로 작동하지 않을 수 있다는 것입니다. 즉, VictoriaMetrics 시계열 ID가 교차하는 특정 사례에 대해 최적화되었습니다. 이는 모든 경우에 적합하다는 의미는 아닙니다. 잘못 사용하면 성능이 향상되지 않지만 메모리 부족 오류가 발생하고 성능이 저하됩니다.

이 구조의 구현을 고려해 봅시다. 보고 싶다면 VictoriaMetrics 소스의 폴더에 있습니다. lib/uint64set. 특히 VictoriaMetrics 사례에 최적화되어 있습니다. timeseries_id 은 64비트 값으로, 처음 32비트는 기본적으로 일정하고 마지막 32비트만 변경됩니다.

이 데이터 구조는 디스크에 저장되지 않고 메모리에서만 작동합니다.

API는 다음과 같습니다. 별로 복잡하지 않습니다. API는 VictoriaMetrics 사용의 특정 예에 맞게 특별히 맞춤화되었습니다. 즉, 여기에는 불필요한 기능이 없습니다. VictoriaMetrics에서 명시적으로 사용하는 함수는 다음과 같습니다.

기능이 있습니다 add, 새로운 가치를 추가합니다. 기능이 있습니다 has, 새 값을 확인합니다. 그리고 기능이 있는데 del, 값을 제거합니다. 도우미 기능이 있습니다 len, 세트의 크기를 반환합니다. 기능 clone 클론을 많이 합니다. 그리고 기능 appendto 이 세트를 슬라이스로 변환합니다. timeseries_ids.

이것이 이 데이터 구조의 구현 모습입니다. 세트에는 두 가지 요소가 있습니다.

• ItemsCount 세트의 요소 수를 빠르게 반환하는 도우미 필드입니다. 이 보조 필드 없이도 가능하지만 VictoriaMetrics는 종종 알고리즘에서 비트 세트 길이를 쿼리하기 때문에 여기에 추가해야 했습니다.

• 두 번째 필드는 buckets. 이것은 구조의 일부입니다. bucket32. 각 구조물은 매장 hi 필드. 상위 32비트입니다. 그리고 두 조각 - b16his и buckets 으로 bucket16 구조.

16비트 구조의 두 번째 부분의 상위 64비트가 여기에 저장됩니다. 그리고 여기에는 각 바이트의 하위 16비트에 대한 비트 세트가 저장됩니다.

Bucket64 배열로 구성 uint64. 길이는 이러한 상수를 사용하여 계산됩니다. 하나의 bucket16 최대 저장 가능 2^16=65536 조금. 이것을 8로 나누면 8KB가 됩니다. 다시 8로 나누면 1000이 됩니다 uint64 의미. 그건 Bucket16 – 이것이 8킬로바이트 구조입니다.

새 값을 추가하기 위한 이 구조의 메서드 중 하나가 어떻게 구현되는지 살펴보겠습니다.

모든 것은 다음과 같이 시작됩니다. uint64 의미. 상위 32비트를 계산하고 하위 32비트를 계산합니다. 모든 것을 살펴 보자 buckets. 각 버킷의 상위 32비트를 추가되는 값과 비교합니다. 일치하면 함수를 호출합니다. add 구조 b32에서 buckets. 그리고 거기에 하위 32비트를 추가합니다. 그리고 그것이 돌아왔다면 true, 이는 우리가 거기에 그러한 값을 추가했지만 그러한 값이 없다는 것을 의미합니다. 반환되는 경우 false, 그렇다면 그러한 의미는 이미 존재했습니다. 그런 다음 구조의 요소 수를 늘립니다.

필요한 것을 찾지 못한 경우 bucket 필요한 높은 값을 사용하여 함수를 호출합니다. addAlloc, 이는 새로운 것을 생성할 것입니다. bucket, 버킷 구조에 추가합니다.

이것이 함수의 구현이다 b32.add. 이전 구현과 유사합니다. 우리는 최상위 16비트, 최하위 16비트를 계산합니다.

그런 다음 상위 16비트를 모두 살펴봅니다. 우리는 일치하는 것을 찾습니다. 일치하는 항목이 있으면 add 메서드를 호출합니다. 이에 대해서는 다음 페이지에서 살펴보겠습니다. bucket16.

그리고 여기에는 가능한 한 많이 최적화되어야 하는 가장 낮은 수준이 있습니다. 우리는 다음을 계산합니다. uint64 슬라이스 비트의 id 값과 bitmask. 이는 해당 비트의 존재 여부를 확인하거나 설정하는 데 사용할 수 있는 지정된 64비트 값에 대한 마스크입니다. 이 비트가 설정되어 있는지 확인하고 설정한 후 현재 상태를 반환합니다. 이것이 우리의 구현입니다. 이를 통해 기존 지도에 비해 시계열의 교차 ID 작업 속도를 10배 높일 수 있었습니다.

이 최적화 외에도 VictoriaMetrics에는 다른 많은 최적화 기능이 있습니다. 이러한 최적화의 대부분은 이유 때문에 추가되었지만 프로덕션에서 코드를 프로파일링한 후에 추가되었습니다.

이것이 최적화의 주요 규칙입니다. 여기에 병목 현상이 있을 것이라고 가정하고 최적화를 추가하지 마세요. 거기에는 병목 현상이 없을 것으로 판명될 수도 있기 때문입니다. 최적화는 일반적으로 코드 품질을 저하시킵니다. 따라서 프로파일링 후에만 최적화할 가치가 있으며 가급적이면 프로덕션 환경에서 실제 데이터가 되도록 해야 합니다. 누구든지 관심이 있다면 VictoriaMetrics 소스 코드를 보고 거기에 있는 다른 최적화를 탐색할 수 있습니다.

비트셋에 관해 질문이 있습니다. C++ 벡터 bool 구현과 매우 유사하며 최적화된 비트 세트입니다. 거기에서 구현을 가져 왔습니까?

아니요, 거기부터는 아닙니다. 이 비트 세트를 구현할 때 VictoriaMetrics에서 사용되는 이러한 ID 시계열의 구조에 대한 지식을 바탕으로 안내를 받았습니다. 그리고 그 구조는 상위 32비트가 기본적으로 일정하다는 구조이다. 하위 32비트는 변경될 수 있습니다. 비트가 낮을수록 더 자주 변경될 수 있습니다. 따라서 이 구현은 특히 이 데이터 구조에 최적화되어 있습니다. 내가 아는 한 C++ 구현은 일반적인 경우에 최적화되어 있습니다. 일반적인 경우에 맞게 최적화하면 특정 경우에 가장 적합하지 않다는 의미입니다.

또한 Alexey Milovid의 보고서를 시청하는 것이 좋습니다. 약 한 달 전 그는 특정 전문 분야에 대한 ClickHouse의 최적화에 대해 이야기했습니다. 그는 단지 일반적인 경우 C++ 구현이나 다른 구현이 병원에서 평균적으로 잘 작동하도록 맞춤화되어 있다고 말합니다. 이는 상위 32비트가 대부분 일정하다는 것을 알고 있는 우리와 같은 지식별 구현보다 성능이 나쁠 수 있습니다.

두 번째 질문이 있습니다. InfluxDB와의 근본적인 차이점은 무엇입니까?

근본적인 차이점이 많이 있습니다. 성능 및 메모리 소비 측면에서 InfluxDB는 테스트에서 카디널리티 시계열이 많을 때(예: 수백만 개) 높은 카디널리티 시계열에 대해 10배 더 많은 메모리 소비를 보여줍니다. 예를 들어 VictoriaMetrics는 백만 개의 활성 행당 1GB를 소비하는 반면 InfluxDB는 10GB를 소비합니다. 그리고 그것은 큰 차이입니다.

두 번째 근본적인 차이점은 InfluxDB에는 Flux와 InfluxQL이라는 이상한 쿼리 언어가 있다는 것입니다. 시계열 작업에 비해 그다지 편리하지 않습니다. PromQL, 이는 VictoriaMetrics에서 지원됩니다. PromQL은 Prometheus의 쿼리 언어입니다.

또 한 가지 차이점은 InfluxDB에는 약간 이상한 데이터 모델이 있다는 것입니다. 각 줄은 서로 다른 태그 세트를 사용하여 여러 필드를 저장할 수 있습니다. 이 줄은 다양한 테이블로 더 나뉩니다. 이러한 추가적인 문제로 인해 이 데이터베이스를 사용한 후속 작업이 복잡해집니다. 지지하고 이해하기가 어렵습니다.

VictoriaMetrics에서는 모든 것이 훨씬 간단해졌습니다. 여기에서 각 시계열은 키-값입니다. 값은 포인트 집합입니다. (timestamp, value), 그리고 열쇠는 세트입니다 label=value. 필드와 측정값이 구분되지 않습니다. 내가 아는 한 서로 다른 행 간의 계산이 아직 구현되지 않은 InfluxDB와 달리 데이터를 선택한 다음 결합, 더하기, 빼기, 곱하기, 나누기가 가능합니다. 구현한다고 해도 어렵고, 코드도 많이 작성해야 합니다.

명확한 질문이 있습니다. 당신이 말한 어떤 종류의 문제가 있다는 것, 이 반전된 인덱스가 메모리에 맞지 않아서 거기에 파티셔닝이 있다는 것을 제가 올바르게 이해했습니까?

먼저 표준 Go 맵에서 반전된 인덱스를 순진하게 구현하는 방법을 보여주었습니다. 이 반전된 인덱스는 디스크에 저장되지 않으며 데이터베이스는 다시 시작할 때 이 데이터를 계속 사용할 수 있도록 디스크에 저장해야 하기 때문에 데이터베이스에 적합하지 않습니다. 이 구현에서는 애플리케이션을 다시 시작하면 반전된 인덱스가 사라집니다. 그리고 모든 데이터를 찾을 수 없기 때문에 모든 데이터에 액세스할 수 없게 됩니다.

안녕하세요! 신고해 주셔서 감사합니다! 제 이름은 파벨이에요. 저는 와일드베리 출신이에요. 몇 가지 질문이 있습니다. 질문 2. 애플리케이션의 아키텍처를 구축할 때 다른 원칙을 선택하고 시간이 지남에 따라 데이터를 분할했다면 한 파티션에 다른 파티션에 대한 데이터가 포함되어 있다는 사실에만 근거하여 검색 시 데이터를 교차할 수 있었을 것이라고 생각하십니까? 즉, 한 시간 간격으로 조각이 다르게 흩어져 있다는 사실에 대해 걱정할 필요가 없습니까? 질문 XNUMX - 비트 세트 및 기타 모든 항목을 사용하여 유사한 알고리즘을 구현하고 있으므로 프로세서 명령어를 사용해 보셨나요? 아마도 그러한 최적화를 시도해 보셨나요?

바로 두 번째 답변 드리겠습니다. 우리는 아직 그 지점에 도달하지 못했습니다. 하지만 필요하다면 우리는 그곳에 갈 것입니다. 첫 번째 질문은 무엇이었나요?

두 가지 시나리오를 논의했습니다. 그리고 그들은 더 복잡한 구현을 가진 두 번째 것을 선택했다고 말했습니다. 그리고 그들은 데이터가 시간별로 분할되는 첫 번째 것을 선호하지 않았습니다.

예. 첫 번째 경우에는 인덱스의 총 볼륨이 더 커집니다. 왜냐하면 각 파티션에서 이러한 모든 파티션을 통해 계속되는 시계열에 대한 중복 데이터를 저장해야 하기 때문입니다. 그리고 시계열 이탈률이 작은 경우, 즉 동일한 계열이 지속적으로 사용되는 경우 첫 번째 경우 두 번째 경우에 비해 차지하는 디스크 공간 양이 훨씬 더 많이 손실됩니다.

그리고 그렇습니다. 시간 분할은 좋은 선택입니다. 프로메테우스는 그것을 사용합니다. 그러나 프로메테우스에는 또 다른 단점이 있습니다. 이러한 데이터 조각을 병합할 때 모든 레이블 및 시계열에 대한 메타 정보를 메모리에 유지해야 합니다. 따라서 병합하는 데이터 조각이 크면 VictoriaMetrics와 달리 병합 중에 메모리 소비가 매우 많이 증가합니다. 병합할 때 VictoriaMetrics는 메모리를 전혀 소비하지 않으며 병합된 데이터 조각의 크기에 관계없이 몇 킬로바이트만 소비합니다.

사용 중인 알고리즘은 메모리를 사용합니다. 값이 포함된 시계열 태그를 표시합니다. 그리고 이 방법으로 한 데이터 배열과 다른 데이터 배열에서 쌍을 이루는 존재를 확인합니다. 그리고 교차가 발생했는지 여부를 이해합니다. 일반적으로 데이터베이스는 이러한 작업의 단순한 복잡성으로 인해 현재 콘텐츠를 저장하고 정렬된 데이터를 실행하는 커서와 반복기를 구현합니다.

데이터를 탐색하기 위해 커서를 사용하면 어떨까요?

네.

정렬된 행을 LevelDB 또는 mergeset에 저장합니다. 커서를 움직여 교차점을 찾을 수 있습니다. 우리는 그것을 사용하지 않는 이유는 무엇입니까? 느리기 때문이죠. 커서는 각 줄에 대해 함수를 호출해야 함을 의미하기 때문입니다. 함수 호출은 5나노초입니다. 그리고 100개의 라인이 있다면 우리는 함수를 호출하는 데 000초를 소비하게 됩니다.

그런 게 있어요, 그렇죠. 그리고 마지막 질문입니다. 질문이 조금 이상하게 들릴 수도 있습니다. 데이터가 도착하는 순간 필요한 모든 집계를 읽고 필요한 형식으로 저장하는 것이 왜 불가능합니까? VictoriaMetrics, ClickHouse 등과 같은 일부 시스템에서 막대한 볼륨을 저장한 다음 여기에 많은 시간을 소비하는 이유는 무엇입니까?

더 명확하게하기 위해 예를 들어 보겠습니다. 작은 장난감 속도계가 어떻게 작동하는지 가정해 볼까요? 그것은 당신이 여행한 거리를 기록하며, 항상 이를 하나의 값에 추가하고 두 번째 시간에 추가합니다. 그리고 나눕니다. 그리고 평균 속도를 얻습니다. 당신도 같은 일을 할 수 있습니다. 필요한 모든 사실을 즉석에서 추가하세요.

좋아요, 질문을 이해했습니다. 귀하의 모범이 그 자리를 차지했습니다. 필요한 집계가 무엇인지 알고 있다면 이것이 최선의 구현입니다. 하지만 문제는 사람들이 이러한 지표와 일부 데이터를 ClickHouse에 저장하고 나중에 이를 어떻게 집계하고 필터링할지 아직 모르기 때문에 모든 원시 데이터를 저장해야 한다는 것입니다. 하지만 무언가를 평균으로 계산해야 한다는 것을 알고 있다면 거기에 여러 개의 원시 값을 저장하는 대신 계산을 해보는 것은 어떨까요? 그러나 이는 필요한 것이 무엇인지 정확히 알고 있는 경우에만 해당됩니다.

그런데 시계열을 저장하는 데이터베이스는 집계 계산을 지원합니다. 예를 들어 프로메테우스는 다음을 지원합니다. 녹음 규칙. 즉, 어떤 단위가 필요한지 알고 있다면 이 작업을 수행할 수 있습니다. VictoriaMetrics에는 아직 이 기능이 없지만 일반적으로 Prometheus가 앞에 나오며 이는 녹음 규칙에서 수행할 수 있습니다.

예를 들어 이전 직장에서는 지난 한 시간 동안 슬라이딩 창에서 이벤트 수를 계산해야 했습니다. 문제는 Go에서 맞춤 구현, 즉 이 항목을 계산하는 서비스를 만들어야 한다는 것입니다. 이 서비스는 계산이 어렵기 때문에 궁극적으로 사소하지 않았습니다. 고정된 시간 간격으로 일부 집계를 계산해야 하는 경우 구현이 간단할 수 있습니다. 슬라이딩 창에서 이벤트 수를 계산하려면 보기만큼 간단하지 않습니다. 구현하기 어렵기 때문에 ClickHouse나 시계열 데이터베이스에는 아직 구현되지 않은 것 같습니다.

그리고 질문 하나 더. 우리는 단지 평균화에 대해 이야기하고 있었는데 한때 Carbon 백엔드를 갖춘 Graphite와 같은 것이 있었다는 것을 기억했습니다. 그리고 그는 오래된 데이터를 얇게 만드는 방법, 즉 분당 XNUMX포인트, 시간당 XNUMX포인트 등을 남겨 두는 방법을 알고 있었습니다. 원칙적으로 이것은 상대적으로 한 달 동안 원시 데이터가 필요하고 다른 모든 것이 필요할 경우 매우 편리합니다. 엷어지다. 그러나 Prometheus와 VictoriaMetrics는 이 기능을 지원하지 않습니다. 지원할 예정인가요? 그렇지 않다면 왜 안 됩니까?

질문해주셔서 감사합니다. 우리 사용자들은 주기적으로 이 질문을 합니다. 그들은 언제 다운샘플링 지원을 추가할 것인지 묻습니다. 여기에는 몇 가지 문제가 있습니다. 첫째, 모든 사용자가 이해합니다. downsampling 뭔가 다른 것: 누군가는 주어진 간격에서 임의의 지점을 얻고 싶어하고 누군가는 최대, 최소, 평균 값을 원합니다. 많은 시스템이 데이터베이스에 데이터를 기록하는 경우 이를 모두 하나로 묶을 수 없습니다. 각 시스템마다 서로 다른 희석이 필요할 수 있습니다. 그리고 이것은 구현하기가 어렵습니다.

두 번째는 ClickHouse와 마찬가지로 VictoriaMetrics도 대량의 원시 데이터 작업에 최적화되어 있으므로 시스템에 코어가 많은 경우 50초 이내에 000억 줄을 처리할 수 있다는 것입니다. VictoriaMetrics의 시계열 포인트 스캔 – 코어당 초당 000 포인트. 그리고 이 성능은 기존 코어로 확장됩니다. 즉, 예를 들어 코어가 20개라면 초당 XNUMX억 개의 포인트를 스캔하게 됩니다. 그리고 VictoriaMetrics와 ClickHouse의 이러한 속성은 다운샘플링의 필요성을 줄여줍니다.

또 다른 특징은 VictoriaMetrics가 이 데이터를 효과적으로 압축한다는 것입니다. 프로덕션 평균 압축률은 포인트당 0,4~0,8바이트입니다. 각 포인트는 타임스탬프 + 값입니다. 그리고 평균적으로 XNUMX바이트 미만으로 압축됩니다.

세르게이. 질문이 있습니다. 최소 녹음 시간 퀀텀은 얼마입니까?

XNUMX밀리초. 우리는 최근 다른 시계열 데이터베이스 개발자들과 대화를 나누었습니다. 최소 시간 조각은 XNUMX초입니다. 예를 들어 Graphite의 경우에도 XNUMX초입니다. OpenTSDB에서도 XNUMX초입니다. InfluxDB는 나노초 정밀도를 갖습니다. VictoriaMetrics에서는 XNUMX밀리초입니다. Prometheus에서는 XNUMX밀리초이기 때문입니다. VictoriaMetrics는 원래 Prometheus용 원격 스토리지로 개발되었습니다. 하지만 이제는 다른 시스템의 데이터를 저장할 수 있습니다.

나와 대화한 사람은 초 단위의 정확도를 가지고 있다고 말했습니다. 이는 시계열 데이터베이스에 저장되는 데이터 유형에 따라 달라지기 때문에 그것만으로도 충분합니다. 이것이 DevOps 데이터이거나 분당 30초 간격으로 수집하는 인프라의 데이터라면 초 단위의 정확성이면 충분하므로 그 이하는 더 이상 필요하지 않습니다. 그리고 고주파 거래 시스템에서 이 데이터를 수집하는 경우 나노초 정확도가 필요합니다.

VictoriaMetrics의 밀리초 정확도는 DevOps 사례에도 적합하며 보고서 시작 부분에서 언급한 대부분의 사례에 적합할 수 있습니다. 적합하지 않을 수 있는 유일한 것은 고주파 거래 시스템입니다.

감사합니다! 그리고 또 다른 질문입니다. PromQL의 호환성이란 무엇입니까?

완전한 이전 버전과의 호환성. VictoriaMetrics는 PromQL을 완벽하게 지원합니다. 또한 PromQL에 고급 기능을 추가합니다. 측정항목QL. 이 확장된 기능에 대해 YouTube에 대한 이야기가 있습니다. 저는 봄에 상트페테르부르크에서 열린 모니터링 모임에서 연설했습니다.

전보 채널 빅토리아메트릭스.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

Prometheus의 장기 스토리지로 VictoriaMetrics로 전환하는 것을 방해하는 이유는 무엇입니까? (댓글로 적어주시면 설문조사에 추가하겠습니다)

• 71,4%나는 Prometheus5를 사용하지 않습니다

• 28,6%VictoriaMetrics2에 대해 몰랐습니다.

7명의 사용자가 투표했습니다. 12명의 사용자가 기권했습니다.

출처 : habr.com