시계열 데이터를 관계형 또는 비 저장 형?


185

SNMP를 사용하여 (아마도) 5 분 간격으로 CPU 사용률, 디스크 사용률, 온도 등과 같은 다양한 메트릭스에 대한 데이터를 위해 장치를 폴링하는 시스템을 만들고 있습니다. 궁극적 인 목표는 시계열 그래프 형식으로 시스템 사용자에게 시각화를 제공하는 것입니다.

과거에는 RRDTool을 사용하는 것을 살펴 봤지만 캡처 된 데이터를 무기한으로 저장하는 것이 프로젝트에 중요하므로 거부했으며 캡처 된 데이터에 대한 높은 수준의 유연한 액세스를 원합니다. 그래서 내 질문은 정말로 :

더 좋은 점은 그래프로 데이터를 쿼리 할 때 성능과 관련하여 관계형 데이터베이스 (예 : MySQL 또는 PostgreSQL) 또는 관계형 또는 NoSQL 데이터베이스 (예 : MongoDB 또는 Redis)입니다.

관계형

관계형 데이터베이스가 주어지면 data_instances테이블을 사용합니다.이 테이블에는 모든 장치에 대해 측정되는 모든 메트릭에 대해 캡처 된 모든 데이터 인스턴스가 다음 필드와 함께 저장됩니다.

필드: id fk_to_device fk_to_metric metric_value timestamp

특정 장치에서 특정 메트릭에 대한 그래프를 그리려면이 단일 테이블을 쿼리 하여 다른 장치를 필터링 하고이 장치에 대해 분석되는 다른 메트릭을 쿼리해야합니다 .

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

이 테이블의 행 수는 다음과 같습니다.

d * m_d * f * t

여기서 d의 개수 장치 , m_d축적이다 메트릭 수가 , 모든 기기에 기록되지 f는 IS 주파수 데이터 및 폴링되는 t총량 인 시각 시스템이 데이터를 수집하고있다.

1 년 동안 5 분마다 3 개의 장치에 대해 10 개의 메트릭을 기록하는 사용자의 경우 5 백만 건 미만의 레코드를 갖게 됩니다.

인덱스

의 인덱스없이 fk_to_device하고 fk_to_metric이 지속적으로 확대 테이블을 스캔하는 것은 너무 많은 시간이 걸릴 것이다. 따라서 위에서 언급 한 필드를 색인화하고 timestamp(현지화 된 기간으로 그래프를 작성하기위한) 요구 사항입니다.

비 관계형 (NoSQL)

MongoDB는 테이블을 설정하지 않고 프로그래밍 방식으로 만들 수있는 테이블과 달리 컬렉션 개념을 가지고 있습니다. 이를 통해 각 장치의 데이터 스토리지 또는 각 장치에 대해 기록 된 각 메트릭을 분할 할 수있었습니다.

나는 NoSQL에 대한 경험이 없으며 인덱싱과 같은 쿼리 성능 향상 기능을 제공하는지 여부를 알지 못하지만 이전 단락에서는 NoSQL에서 데이터가 저장되는 구조에서 전통적인 관계형 쿼리 작업의 대부분을 제안합니다.

미정

올바른 인덱싱을 사용하는 관계형 솔루션이 1 년 안에 크롤링으로 줄어 듭니까? 또는 NoSQL 접근 방식의 수집 기반 구조 (저장된 데이터의 정신적 모델과 일치)가 눈에 띄는 이점을 제공합니까?


1
매우 유효한 질문입니다. 관계형 DB가 실제로 계층 적 인 데이터 구조 (SNMP 구조)를 저장하는 올바른 방법인지 여부에 대해 스스로 생각했습니다. 때로는 사소한 데이터를 가져 오기 위해 쿼리를 작성할 때 쿼리가 너무 복잡 해져서 데이터가 고유하지 않은 형식으로 엉켜 버려야한다고 생각했습니다. 예를 들어 ifname과 해당 인덱스를 일치시키는 것은 사소한 작업으로, 둘 다 동일한 부모 무효의 자식입니다. 그러나 관계형 DB에 저장되는 방식은 원래 구조와 관련이 없으며 계층 적 방식으로 저장하는 것이 더 효율적이라고 생각합니다.
베니

"1 년 동안 5 분마다 3 개의 장치에 대해 10 개의 메트릭을 기록하는 사용자의 경우 5 백만 건 미만의 레코드를 보유하게됩니다." 하지 (10) * 3 * 12 * 24 (365)은 대략하지 않은 3,000,000 동일 * 단지 5,000,000하에?
Mathieu Borderé

답변:


152

확실히 관계형. 무제한의 유연성과 확장 성.

개념과 적용 모두에 대한 두 가지 수정과 고도 상승.

보정

  1. "필요하지 않은 데이터를 필터링"하지 않습니다. 그 것이다 만을 선택 하여 필요한 데이터. 물론 WHERE 절에서 식별 된 열을 지원하는 인덱스가있는 경우 매우 빠르며 쿼리는 테이블 크기에 의존하지 않습니다 (160 억 행 테이블에서 1,000 개의 행을 가져옴). .

  2. 당신의 테이블에는 심각한 장애가 있습니다. 설명에 따르면 실제 PK는 (장치, 측정 항목, 날짜 시간)입니다. (TimeStamp라고 부르지 마십시오. 다른 의미가 있지만 사소한 문제입니다.) 의 고유성은 다음과 같이 식별됩니다.

       (Device, Metric, DateTime)
    
    • Id열은 아무 것도 수행하지 않으며 완전히 중복됩니다.

      • Id열은 키 (관계형 데이터베이스에 금지 중복 행은, 다른 방법으로 방지해야한다) 결코 없다.
      • Id열에는 추가 색인이 필요합니다. 이는 분명히 속도를 방해하고 INSERT/DELETE사용 된 디스크 공간을 추가합니다.

      • 당신은 그것을 제거 할 수 있습니다. 부디.

높이

  1. 장애를 제거 했으므로이를 인식하지 못했을 수 있지만 테이블이 여섯 번째 정규 형식입니다. PK에 하나의 인덱스 만있는 초고속. 이해를 위해 읽고, 이 답변 로부터 여섯 번째 정규 양식은 무엇입니까? 앞으로 향하고 있습니다.

    • (나는 3 개가 아닌 하나의 인덱스 만 가지고 있습니다. 비 SQL에서는 3 개의 인덱스가 필요할 수 있습니다).

    • 나는 정확히 같은 테이블을 가지고 있습니다 ( Id물론 "키"는 없습니다). 추가 열이 Server있습니다. 여러 고객을 원격으로 지원합니다.

      (Server, Device, Metric, DateTime)

    이 테이블을 사용 하여 정확히 동일한 SQL 코드를 사용하여 데이터를 피벗하거나 (예 : Devices위쪽 및 Metrics아래쪽으로 피벗하거나 피벗) 셀을 전환 할 수 있습니다. 이 표를 사용하여 고객의 서버 성능을 위해 다양한 그래프와 차트를 무제한으로 세웁니다.

    • 통계 데이터 모델 모니터 .
      (인라인의 경우 너무 큽니다. 일부 브라우저는 인라인을로드 할 수 없습니다. 링크를 클릭하십시오. 또한 구식 데모 버전이므로 상용 제품 DM을 표시 할 수 없습니다.)

    • 단일 SELECT 명령을 사용하여 고객으로부터 원시 모니터링 통계 파일을 수신 한 후 6 건의 키 입력 과 같은 차트 를 생성 할 수 있습니다 . 믹스 앤 매치에 주목하십시오. 동일한 차트의 OS 및 서버 다양한 피벗. 물론 통계 행렬의 수와 차트에 제한이 없습니다. (고객의 친절한 허가와 함께 사용)

    • 관계형 데이터베이스 모델링 표준에 익숙하지 않은 독자는 IDEF1X 표기법이 도움이 될 수 있습니다.

하나 더

마지막으로 SQL은 IEC / ISO / ANSI 표준입니다. 프리웨어는 실제로 비 SQL입니다. 표준을 제공하지 않는 경우 SQL이라는 용어를 사용하는 것은 사기입니다. 그들은 "엑스트라 (extras)"를 제공 할 수 있지만, 기본은 없다.


1
@PerformanceDBA 1 분 빈도로 최대 3 백만 개의 측정 값을 처리해야하는 설정에 제안 된 스키마를 사용 하시겠습니까? 그러한 테이블에 대해 PK를 어떻게 주문 하시겠습니까? Device, Metric, DateTime이 조각화를 생성하지 않고 RDBMS를 많은 페이지 분할로 강제하지 않습니까? 대신 DateTime을 먼저 넣으면 조각화가 줄어 듭니다 (시간 순서의 삽입을 가정합니다).하지만 읽기는 최악입니다.
marcob

1
@ 부치 Sybase ASE를 사용합니다. 그러나 이것은 플랫폼 문제가 아닙니다 (확실히 높은 플랫폼은 저급보다 수십 배 더 나은 성능을 제공합니다. 오라클보다 3 배 더 나은 성능을 제공하지만 요점은 아닙니다), 표에서 차트의 발기 " 모든 플랫폼에서 작동합니다. 작업에 적합한 도구를 사용하십시오. RDBMS는 그래프 도구가 아닌 데이터베이스 도구입니다. gnuplot, Apple Numbers (또는 MS Excel의 절반으로 10 배를 지불하려는 경우)는 데이터베이스 도구가 아닌 차트 도구입니다. 오늘날 우리는 도구를 사용하여 결과를 만들어 내고 모놀리스는 공룡입니다.
PerformanceDBA

1
marco 귀하의 질문은 좋은 것이지만 의견에 제대로 대답 할 수는 없습니다. 새 질문을 열고 이메일을 보내면 (프로필로 이동) 대답하겠습니다. 빠른 답변을 원하시면 여기를 클릭하십시오. (1) ~ 3 백만 미터법. 훌륭할수록 INSERT 포인트가 아름답게 퍼져 마지막 페이지에서 충돌을 보장 할 수 있습니다. 서버는 멀티 스레드입니다. 테이블을 분할하십시오. FILLFACTOR를 사용하고 인서트를위한 공간을 확보하여 페이지 분할을 피하십시오. (2) ~ 3 Mill은 지표가 정규화되지 않았 음을 나타내며,이를 수정하면 여전히 더 빠릅니다.
PerformanceDBA

1
marco (3) 주어진 인덱스를 정확하게 사용하여 인서트를 하중하에 분산시켜 충돌을 방지합니다. (4) 따라서, 제있어서 취득 모두 충돌없이 삽입 SELECT들에 고성능.
PerformanceDBA

2
@Loic. SQL 플랫폼에 투자 (데이터; 코드)를 가지고 있고 시계열 데이터를 쉽고 높은 성능 (답변에 자세히 설명 된대로)으로 처리하는 사람이 SQL없이 TSDB로 마이그레이션하는 이유는 무엇입니까? 시계열 데이터를 제외하고는 알려지지 않은 속도? 시계열 데이터 전용을 초과하는 요구 사항을 가진 사람이 SQL 플랫폼을 사용 하지 않는 이유는 무엇 입니까? 마음이 흔들린다. TSDB는 데이터가 db에 저장되었지만 관계형으로 정규화 되지 않은 슬픈 인스턴스 에서만 관계형보다 빠릅니다 . 예 : 열이 "키"로 사용될 때 . "이론가"의 조언에 따라. Id
PerformanceDBA

21

위의 답변에서 매우 흥미로운 것을 발견했습니다. 여기에 몇 가지 추가 고려 사항을 추가하려고합니다.

1) 데이터 노화

시계열 관리는 일반적으로 에이징 정책을 만들어야합니다. 일반적인 시나리오 (예 : 모니터링 서버 CPU)는 다음을 저장해야합니다.

  • 단기간 (예 : 24 시간) 1 초의 원시 샘플

  • 중간 기간 (예 : 1 주) 동안 5 분 세부 집계 샘플

  • 1 시간 이상의 세부 정보 (예 : 최대 1 년)

관계형 모델을 사용하면 (내 회사는 수만 개의 데이터 시리즈를 보유한 일부 대규모 고객을 위해 대규모 중앙 데이터베이스를 구현할 수 있음)이를 적절하게 관리 할 수 ​​있지만 새로운 유형의 데이터 저장소는 다음과 같은 흥미로운 기능을 추가합니다.

  • 자동 데이터 제거 (Redis의 EXPIRE 명령 참조)

  • 다차원 집계 (예 : map-reduce 작업 a-la-Splunk)

2) 실시간 수집

더 중요한 것은 일부 비 관계형 데이터 저장소가 본질적으로 분산되어 핫스팟 생성 (삽입 중 인덱싱 관리)으로 인해 RDBMS에서 문제가 될 수있는 훨씬 더 효율적인 실시간 (또는 거의 실시간) 데이터 수집을 허용한다는 점입니다. 단일 테이블). RDBMS 공간에서이 문제는 일반적으로 일괄 가져 오기 프로 시저 (이전에는 이런 방식으로 관리함)로 되돌 리면서 해결되었으며, SQL 기술은 대규모 실시간 수집 및 집계에 성공하지 못했습니다 (예 : 이전 답변에서 언급 한 Splunk 참조) .


7

단일 테이블에 데이터가 있습니다. 따라서 관계형과 비 관계형은 문제가되지 않습니다. 기본적으로 많은 순차 데이터를 읽어야합니다. 이제 몇 년 동안 가치있는 데이터를 저장할 RAM이 충분하다면 Redis / MongoDB 등을 사용하는 것과 같은 것은 없습니다.

대부분 NoSQL 데이터베이스는 여러 디스크 액세스를 피하기 위해 데이터를 디스크의 동일한 위치에 압축 된 형식으로 저장합니다.

NoSQL은 장치 ID 및 메트릭 ID에서 색인을 작성하는 것과 동일한 방식으로 자체 방식으로 작업합니다. 데이터베이스를 사용 하더라도이 작업을 수행하더라도 색인과 데이터는 다른 위치에있을 수 있으며 많은 디스크 IO가있을 수 있습니다.

Splunk와 같은 도구는 NoSQL 백엔드를 사용하여 시계열 데이터를 저장 한 다음 map reduce를 사용하여 집계를 만듭니다 (나중에 원할 수도 있음). 그래서 사람들이 비슷한 유스 케이스를 위해 이미 시도 했으므로 NoSQL을 사용하는 것이 옵션입니다. 그러나 백만 행이 데이터베이스를 크롤링하게합니다 (하드웨어 및 적절한 구성이 아닐 수도 있음).


1
테이블이 "정규화되지 않은"방법을 설명해 주시겠습니까? Marcus는 테이블에 오류가 있지만 정규화 오류가 아닙니다.
PerformanceDBA

나는 테이블을 전통적인 의미로 정규화합니다. 유스 케이스에 하나의 테이블에 모든 데이터가 있다는 의미에서 비정규 화되었습니다.
Ravindra

4

파일을 작성하고 이름을 1_2.data로 지정하십시오. 위 어드 아이디어? 당신이 얻는 것 :

  • 모든 데이터 포인트에 대해 fk_to_device 및 fk_to_metric 값을 반복 할 필요가 없기 때문에 최대 50 %의 공간을 절약 할 수 있습니다.
  • 인덱스가 필요 없으므로 더 많은 공간을 절약 할 수 있습니다.
  • 타임 스탬프별로 무료로 주문할 수 있도록 데이터를 추가하여 파일에 (timestamp, metric_value) 쌍을 저장하십시오. (소스가 기기에 대해 순서가 잘못된 데이터를 보내지 않는다고 가정)

=> 이진 검색을 사용하여 파일에서 읽을 올바른 위치를 찾을 수 있기 때문에 타임 스탬프 별 쿼리가 매우 빠르게 실행됩니다.

훨씬 더 최적화 된 경우 파일을 분할하는 방법에 대해 생각하십시오.

  • 1_2_january2014.data
  • 1_2_february2014.data
  • 1_2_march2014.data

또는 http://kx.com의 kdb +를 사용하십시오. 열 중심이 도움이 될 수 있습니다.

클라우드 기반 열 지향 솔루션이 팝업되므로 http://timeseries.guru를 살펴보십시오.


나는 그 주제에 관한 블로그 글을 썼습니다. 구글 번역하면 도움이 될 것입니다 : blog.michaelwittig.info/die-spaltenorientierte-datenbank-kdb
hellomichibye

3

GPL 패키지를보고 있다면 RRDTool 을 살펴 보는 것이 좋습니다. 시계열 데이터를 저장, 추출 및 그래프 작성하는 데 유용한 도구입니다. 사용 사례는 시계열 데이터와 똑같습니다.


2

이것은 ApiAxle에서 해결해야 할 문제입니다. 우리는 블로그 포스트 쓴 우리가 레디 스를 사용했던 방법을. 오랫동안 거기에 없었지만 효과적이라는 것이 입증되었습니다.

나는 또 다른 프로젝트에 RRDTool 을 사용 했습니다 .


2

이런 종류의 질문에 대한 답은 주로 데이터베이스가 스토리지를 사용하는 방식에 관한 것이어야한다고 생각합니다. 일부 데이터베이스 서버는 RAM과 디스크를 사용하고 일부는 RAM 만 사용 (선택적으로 지속성을 위해 디스크) 등을 사용합니다. 가장 일반적인 SQL 데이터베이스 솔루션은 메모리 + 디스크 저장소를 사용하고 행 기반 레이아웃으로 데이터를 기록합니다 (삽입 된 모든 원시 파일은 동일하게 기록됨) 물리적 위치). 시계열 매장의 경우 대부분의 경우 워크로드는 다음과 같습니다. 상대적으로 적은 양의 삽입 간격이 비교적 짧은 반면 읽기는 열을 기준으로합니다 (대부분의 경우 특정 열에서 특정 범위의 데이터를 읽고 싶어합니다)

Columnar Databases (Google, MonetDB, InfoBright, parAccel 등)가 시계열에서 훌륭한 일을하고 있음을 발견했습니다.

귀하의 질문에 관해서는, 개인적으로 다소 유효하지 않다고 생각합니다 (결함 용어 NoSQL-IMO를 사용하는 모든 토론) : 한 손으로 SQL을 대화 할 수있는 데이터베이스 서버를 사용할 수 있으므로 모든 사람들이 SQL을 알고 있기 때문에 인생을 매우 쉽게 만들 수 있습니다 수년 동안이 언어는 데이터 쿼리를 위해 계속해서 완성되었습니다. RAM, CPU 캐시 및 디스크를 컬럼 형 방식으로 여전히 활용하여 솔루션을 시계열에 가장 적합하게 만듭니다.


2

5 백만 행은 오늘날의 급류 데이터에는 해당되지 않습니다. 단 몇 개월 만에 데이터가 TB 또는 PB에있을 것으로 예상됩니다. 이 시점에서 RDBMS는 작업에 맞게 확장되지 않으며 NoSql 데이터베이스의 선형 확장 성이 필요합니다. 데이터를 저장하는 데 사용되는 기둥 형 파티션의 성능을 달성하여 열을 늘리고 행을 줄이면 개념을 향상시켜 성능을 향상시킵니다. HBASE 또는 MapR_DB 등에서 수행 된 Open TSDB 작업을 활용하십시오.


"RDBMS는 작업에 맞게 확장되지 않습니다"-왜 그렇지 않습니까? code.facebook.com/posts/190251048047090/…
Zathrus 작가

1

나는 비슷한 요구 사항을 정기적으로 직면하고 있으며 최근 Zabbix를 사용하여 이러한 유형의 데이터를 수집하고 저장하기 시작했습니다. Zabbix는 자체 그래프 기능을 가지고 있지만 Zabbix의 데이터베이스에서 데이터를 추출하여 원하는대로 처리하는 것은 쉽습니다. Zabbix를 아직 체크 아웃하지 않았다면 그렇게 할 가치가 있습니다.


예, Zabbix는 훌륭하며 이미 SNMP 모니터링과 통합되어 있습니다. Zabbix는 MySQL 또는 PostgreSQL을 사용할 수 있으며 우분투에서 기본적으로 작동합니다.
Dirk Eddelbuettel

감사합니다. Zabbix와 다른 많은 SNMP 도구에 대해 알고 있습니다. 그러나 나는 여기서 논의 된 주제와 다른 많은 측면에서이 프로젝트를 교육 과정으로 개발하고 있습니다. 그래도 좋은 지적입니다!
Marcus Whybrow

0

시계열 데이터베이스를 살펴 봐야 합니다 . 이 목적을 위해 만들어졌습니다.

시계열 데이터베이스 (TSDB)는 시계열 데이터, 시간별로 색인 된 숫자 배열 (날짜 또는 날짜 / 시간 범위)을 처리하도록 최적화 된 소프트웨어 시스템입니다.

시계열 데이터베이스 InfluxDB 의 인기있는 예


이 목록에 timescaledb를 추가하십시오
PirateApp
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.