시계열 데이터의 높은 기초 문제 이해하기: 근본 원인 분석 및 솔루션

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

하이 카디널리티란 무엇입니까?

카디널리티는 수학에서 집합의 요소 수를 나타내는 데 사용되는 스칼라로 정의됩니다. 예를 들어 유한 집합 A = {a, b, c}의 카디널리티는 3입니다. 무한 집합에 대한 카디널리티 개념도 있습니다. . 오늘 우리는 주로 컴퓨터 분야에 대해 이야기하지만 여기서는 확장하지 않겠습니다.

데이터베이스의 맥락에서 카디널리티에 대한 엄격한 정의는 없지만 카디널리티에 대한 모든 사람의 합의는 수학의 정의와 유사합니다. 즉, 데이터 열에 포함된 다양한 값의 수를 측정하는 데 사용됩니다. 예를 들어 , 사용자를 기록하는 데이터 테이블에는 일반적으로 여러 개의 열과 가 있습니다 . UID분명히 의 카디널리티 만큼 높지 않으며 의 열에는 상대적으로 적은 값이 있을 수 있습니다. 따라서 사용자 테이블의 예에서는 해당 열이 높은 기저에 속하고 해당 열이 낮은 기저에 속 한다고 할 수 있습니다 .NameGenderUIDIDNameUIDGenderUIDGender

시계열 데이터베이스 분야로 더 세분화되면 카디널리티는 종종 타임라인 수를 의미합니다. 일반적인 시나리오는 요청 시간을 기록하는 것입니다. API 서비스. 가장 간단한 예를 들면, 서로 다른 인스턴스의 API 서비스 각 인터페이스의 응답 시간에 대한 두 개의 레이블이 있습니다. 인터페이스가 20개이고 API Routes인스턴스 Instance가 5개인 경우 타임라인의 기준은 (20+1)x(5)입니다. +1)-1 = 125( +1한 인스턴스의 모든 인터페이스의 응답 시간이나 모든 인스턴스의 인터페이스의 응답 시간을 따로 볼 수 있다는 점을 고려하면), 그 값은 크지 않은 것 같지만, 주의할 점 오퍼레이터는 제품이므로 특정 라벨의 카디널리티가 높거나 새로운 라벨이 추가되면 타임라인의 카디널리티가 극적으로 증가합니다.

왜 중요한가요?

우리 모두 알고 있듯이, 모두에게 가장 친숙한 MySQL과 같은 관계형 데이터베이스에는 일반적으로 ID 열과 이메일, 주문 번호 등과 같은 공통 열이 있습니다. 이러한 열은 카디널리티가 높은 열이며 거의 들어본 적이 없습니다. 그러나 이러한 데이터 모델링으로 인해 특정 문제가 발생합니다. 사실 우리가 익숙한 OLTP 분야에서는 높은 카디널리티가 문제가 되지 않는 경우가 많지만, 타이밍 필드에서는 데이터 모델 때문에 문제를 일으키는 경우가 많습니다. .고베이스 데이터 세트가 실제로 무엇을 의미하는지 살펴보겠습니다.

내 생각에, 일반인의 관점에서 보면, 높은 기반의 데이터 세트는 많은 양의 데이터를 의미합니다. 데이터베이스의 경우, 데이터 양의 증가는 필연적으로 쓰기, 쿼리 및 저장에 영향을 미칠 것입니다. 글을 쓸 때의 영향은 지수입니다.

기존 데이터베이스의 높은 카디널리티

관계형 데이터베이스에서 인덱스를 생성하는 데 사용되는 가장 일반적인 데이터 구조인 B-트리를 예로 들면, 일반적으로 삽입 및 쿼리의 복잡도는 O(logN)이고, 공간 복잡도는 일반적으로 O(N)입니다. N은 우리가 말하는 카디널리티인 요소의 수입니다. 당연히 N이 클수록 어느 정도 영향을 미치겠지만, 삽입과 쿼리의 복잡도는 자연대수이기 때문에 데이터 규모가 특별히 크지 않으면 그 영향은 그다지 크지 않습니다.

그래서 고베이스 데이터는 무시할 수 없는 영향력을 가져오지 않는 것 같습니다. 반대로, 고베이스 데이터의 인덱스는 낮은 베이스 인덱스보다 선택적인 경우가 많습니다. 조건에 맞지 않는 부분 데이터를 쿼리 조건을 통해 걸러낼 수 있으므로 디스크 I/O 오버헤드를 줄일 수 있습니다. 데이터베이스 애플리케이션에서는 과도한 디스크 및 네트워크 I/O 오버헤드를 방지해야 합니다. 예를 들어 select * from users where gender = "male";결과 데이터 세트는 매우 크고 디스크 I/O 및 네트워크 I/O도 매우 커집니다. 실제로 이 낮은 카디널리티 인덱스만 사용하는 것은 의미가 없습니다.

시계열 데이터베이스의 높은 카디널리티

그렇다면 높은 기수 데이터 열이 문제를 일으키는 시계열 데이터베이스의 차이점은 무엇입니까? 시계열 데이터 분야에서는 데이터 모델링이든 엔진 설계이든 핵심은 타임라인을 중심으로 돌아갑니다. 앞서 언급했듯이 시계열 데이터베이스의 높은 카디널리티 문제는 타임라인의 수와 크기를 의미합니다. 이 크기는 단지 한 열의 카디널리티가 아니라 모든 레이블 열의 카디널리티의 곱입니다. , 일반적인 관계형 데이터베이스에서는 높은 기저가 특정 열에 격리되어 있습니다. 즉, 데이터 규모가 선형적으로 증가하는 반면 시계열 데이터베이스의 높은 기저는 비선형인 여러 열의 산물임을 이해할 수 있습니다. 성장. 시계열 데이터베이스에서 기본 타임라인이 어떻게 생성되는지 자세히 살펴보겠습니다. 먼저 첫 번째 시나리오를 살펴보겠습니다.

시계열 수량

우리는 타임라인의 수가 실제로 모든 레이블 기반의 데카르트 곱과 동일하다는 것을 알고 있습니다. 위 그림과 같이 타임라인 수는 100 * 10 = 1000 타임라인입니다. 이 지표에 6개의 태그를 추가하면 각 태그 값은 10개의 값을 가지며 타임라인 수는 10^9, 즉 1억 개가 됩니다. 타임라인을 보면 이 정도 규모를 상상할 수 있습니다.

태그에는 무한한 값이 있습니다.

두 번째 경우, 예를 들어 클라우드 네이티브 환경에서는 각 Pod에 ID가 있습니다. 다시 시작할 때마다 실제로 Pod가 삭제되고 다시 빌드되며 새 ID가 생성되므로 태그 값이 매우 커집니다. 여러 가지가 있으며, 완전히 다시 시작할 때마다 타임라인 수가 두 배로 늘어납니다. 위의 두 가지 상황은 시계열 데이터베이스에서 언급된 높은 카디널리티의 주요 이유입니다.

시계열 데이터베이스가 데이터를 구성하는 방법

우리는 얼마나 높은 카디널리티가 발생하는지 알고 있으며, 이로 인해 어떤 문제가 발생하는지 이해해야 하며 주류 시계열 데이터베이스가 데이터를 구성하는 방식도 이해해야 합니다.

그림의 위쪽은 데이터를 쓰기 전의 표현이고, 그림의 아래쪽은 데이터를 저장한 후의 논리적 표현을 나타낸다. 왼쪽은 시계열 부분의 인덱스 데이터, 오른쪽은 데이터이다. 부분.

각 시계열은 고유한 TSID를 생성할 수 있으며, 인덱스와 데이터는 TSID를 통해 연관되어 있습니다. 이 인덱스는 역 인덱스입니다.

메모리의 반전된 인덱스를 표현한 아래 그림을 살펴보겠습니다.

이는 2계층 맵이며, 외부 레이어는 먼저 태그 이름을 통해 내부 맵을 찾습니다. 내부 맵의 K는 태그 값이고, V는 해당 태그 값을 포함하는 TSID의 집합입니다.

이 시점에서 이전 소개와 결합하여 시계열 데이터의 기반이 높을수록 이중 레이어 맵이 더 커진다는 것을 알 수 있습니다. 지수 구조를 이해한 후 하이 베이시스 문제가 어떻게 발생하는지 이해해 볼 수 있습니다.

높은 쓰기 처리량을 달성하려면 이 인덱스를 메모리에 유지하는 것이 가장 좋습니다. 카디널리티가 높으면 인덱스가 확장되어 인덱스를 메모리에 맞출 수 없게 됩니다. 메모리를 저장할 수 없으면 디스크로 스왑해야 합니다. 디스크로 스왑한 후에는 대량의 랜덤 디스크 IO로 인해 쓰기 속도에 영향을 미칩니다. 쿼리를 다시 살펴보면 쿼리 조건과 같은 쿼리 프로세스를 추측할 수 있습니다 where status = 200 and method="get". 프로세스는 먼저 statuskey 를 사용하여 맵을 찾고 내부 맵을 가져온 다음 "200"모든 TSID 세트를 가져오고 확인하는 것입니다. 다시 같은 방식으로 조건을 적용한 다음 두 TSID 세트를 교차시킨 후 얻은 새로운 TSID 세트를 사용하여 TSID에 따라 데이터를 하나씩 검색합니다.

문제의 핵심은 데이터가 타임라인에 따라 정리되어 있기 때문에 먼저 타임라인을 구한 다음 타임라인에 따라 데이터를 찾아야 한다는 점이라고 볼 수 있습니다. 쿼리에 관련된 타임라인이 많을수록 쿼리 속도가 느려집니다.

해결 방법

우리의 분석이 정확하고 시계열 데이터 분야의 하이 베이시스 문제의 원인을 알고 있다면 문제의 원인을 살펴보겠습니다.

데이터 수준: C(L1) * C(L2) * C(L3) * ... * C(Ln)로 인해 발생하는 인덱스 유지 관리 및 쿼리 문제입니다.
기술 수준: 데이터가 타임라인에 따라 구성되므로 타임라인을 먼저 가져온 다음 타임라인에 따라 데이터를 찾아야 합니다.

편집자는 다음 두 가지 측면에서 솔루션을 논의합니다.

데이터 모델링 최적화

1 불필요한 라벨을 제거하세요

실수로 일부 불필요한 필드를 라벨로 설정하여 타임라인이 부풀어오르는 경우가 많습니다. 예를 들어, 서버 상태를 모니터링할 때 , 가 있는 경우가 많습니다 instance_name. ip실제로 이 두 필드는 반드시 레이블이 될 필요는 없습니다. 그 중 하나는 속성으로 설정할 수 있습니다.

2. 실제 쿼리 기반의 데이터 모델링

사물 인터넷의 센서 모니터링을 예로 들어보겠습니다.

10w 장치
100개 지역
10개 장치

Prometheus에서 측정항목으로 모델링하면 10w * 100 * 10 = 1억의 타임라인이 생성됩니다. (엄격하지 않은 계산) 생각해 보세요. 쿼리가 이런 식으로 수행됩니까? 예를 들어, 특정 지역의 특정 유형 장비의 타임라인을 쿼리하는 방법은 무엇입니까? 장치가 지정되면 유형이 결정되므로 두 레이블이 실제로 함께 있을 필요는 없으므로 이는 불합리해 보입니다. 그러면 다음과 같이 될 수 있습니다.

metric_one: 10w 장치
metric_two:
- 100개 지역
- 10개 장치
metric_3: (데이터 수집을 위해 장치를 다른 지역으로 이동할 수 있다고 가정)
- 10w 장치
- 100개 지역

총 10w + 100 10 + 10w 100~1010w 의 타임라인 으로 위보다 10배 정도 적습니다.

3. 귀중한 고베이스 타임라인 데이터를 별도로 관리

물론, 데이터 모델링이 쿼리와 매우 일치하지만 데이터 규모가 너무 커서 여전히 타임라인을 줄일 수 없다면 이 핵심 지표와 관련된 모든 서비스를 더 나은 시스템에 배치하세요.

시계열 데이터베이스 기술 최적화

첫 번째 효과적인 솔루션은 수직 분할입니다. 업계의 대부분의 주류 시계열 데이터베이스는 시간에 따라 지수를 분할하는 유사한 방법을 채택했습니다. 왜냐하면 이 분할이 수행되지 않으면 시간이 지남에 따라 지수가 확장되기 때문입니다. 점점 더 많아지면 결국 메모리에 저장할 수 없게 되는데, 시간에 따라 나누어지면 오래된 인덱스 청크를 디스크로 스왑하거나 심지어 원격 스토리지에도 최소한 영향을 미치지는 않을 것입니다.
수직 분할의 반대는 수평 분할입니다. 일반적으로 쿼리 조건자 사용 빈도가 가장 높은 하나 또는 여러 개의 태그가 될 수 있습니다. 범위 또는 해시 분할은 이러한 태그의 값을 기반으로 수행됩니다. 분산 분할 정복 아이디어는 단일 머신의 병목 현상을 해결합니다. 가격은 쿼리 조건에 샤딩 키가 포함되어 있지 않으면 연산자를 푸시다운할 수 없고 데이터를 머신으로만 이동할 수 있다는 것입니다. 계산을 위한 최상위 레이어입니다.

위의 두 가지 방법은 전통적인 해결책으로 문제를 어느 정도 완화할 수 있을 뿐 근본적으로 문제를 해결할 수는 없습니다. 다음 두 가지 솔루션은 기존 솔루션이 아니지만 GreptimeDB가 탐색하려는 방향입니다. 여기서는 참조용으로 심층 분석 없이 간략하게만 언급합니다.

시계열 데이터베이스에 실제로 반전 인덱스가 필요한지 생각해 볼 수 있습니다. TimescaleDB는 B-트리 인덱스를 사용하고 InfluxDB_IOx에는 반전 인덱스가 없습니다. 높은 카디널리티 쿼리의 경우 min-max와 결합된 OLAP 데이터베이스에서 일반적으로 사용되는 파티션 스캔을 사용합니다. 일부 가지치기 최적화를 수행하면 효과가 더 좋아질까요?
비동기식 스마트 인덱싱을 위해서는 먼저 행동을 수집하고 분석하여 사용자의 각 쿼리에서 쿼리 속도를 높이기 위해 가장 적합한 인덱스를 비동기적으로 구축해야 합니다. 이에 대한 반전은 생성되지 않습니다. 위의 두 가지 솔루션을 결합하면 쓰기 시 반전이 비동기식으로 구축되므로 쓰기 속도에 전혀 영향을 미치지 않습니다.

쿼리를 다시 살펴보면 시계열 데이터에 시간 속성이 있으므로 데이터를 타임스탬프에 따라 버킷화할 수 있습니다. 해결 방법은 하드 스캔을 수행하고 가지치기 최적화를 위해 일부 최소-최대 인덱스를 결합하는 것입니다. 수천만 또는 수억 줄을 몇 초 만에 스캔하는 것이 여전히 가능합니다.

쿼리가 오면 먼저 몇 개의 타임라인이 포함될지 추정하고, 양이 적으면 반전을 사용하고, 많을 경우 반전 없이 바로 스캔+필터로 이동합니다.

우리는 위의 아이디어를 계속 탐구하고 있으며 아직 완벽하지 않습니다.

결론

높은 기반이 항상 문제가 되는 것은 아닙니다. 때로는 높은 기반이 필요합니다. 우리가 해야 할 일은 우리가 사용하는 도구의 특성과 비즈니스 조건을 기반으로 자체 데이터 모델을 구축하는 것입니다. 물론 도구에는 특정 시나리오 제한이 있습니다. 예를 들어 Prometheus는 기본적으로 각 메트릭 아래에 레이블을 색인화합니다. 이는 단일 시스템 시나리오에서는 큰 문제가 아니며 사용자에게도 편리합니다. 대규모 데이터를 처리할 때 늘어납니다. GreptimeDB는 독립형 시나리오와 대규모 시나리오 모두에서 통합 솔루션을 만들기 위해 최선을 다하고 있습니다. 우리는 또한 높은 수준의 문제에 대한 기술적 시도를 모색하고 있으며 누구나 이에 대해 논의할 수 있습니다.

참조

Greptime 소개:

Greptime Greptime Technology는 스마트 자동차, 사물 인터넷, 가시성 등 대량의 시계열 데이터를 생성하는 분야에 효율적인 실시간 데이터 저장 및 분석 서비스를 제공하여 고객이 데이터의 깊은 가치를 채굴할 수 있도록 지원하는 데 전념하고 있습니다. 현재 3가지 주요 제품이 있습니다.

GreptimeDB는 Rust 언어로 작성된 시계열 데이터베이스로, 분산형, 오픈 소스, 클라우드 기반이며 호환성이 뛰어납니다. 이는 기업이 시계열 데이터를 실시간으로 읽고, 쓰고, 처리하고 분석하는 데 도움이 되며, 장기적인 저장 비용도 절감됩니다.
GreptimeCloud는 관찰 가능성, 사물 인터넷 및 기타 분야와 고도로 통합될 수 있는 완전 관리형 DBaaS 서비스를 사용자에게 제공할 수 있습니다.
GreptimeAI는 LLM 애플리케이션에 맞춰진 관찰 솔루션입니다.
차량-클라우드 통합 솔루션은 자동차 회사의 실제 비즈니스 시나리오에 깊이 파고들어 회사의 차량 데이터가 기하급수적으로 증가한 후 실제 비즈니스 문제점을 해결하는 시계열 데이터베이스 솔루션입니다.

GreptimeCloud 및 GreptimeAI는 공식적으로 테스트되었습니다. 최신 개발 소식을 보려면 공식 계정이나 공식 웹사이트를 팔로우하세요! GreptimDB의 엔터프라이즈 버전에 관심이 있으시면 어시스턴트에게 문의하실 수 있습니다(어시스턴트를 추가하려면 WeChat에서 greptime을 검색하세요).

공식 홈페이지: https://greptime.cn/

GitHub: https://github.com/GreptimeTeam/greptimedb

문서: https://docs.greptime.cn/

트위터: https://twitter.com/Greptime

슬랙: https://www.greptime.com/slack

링크드인: https://www.linkedin.com/company/greptime