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 접근 방식의 수집 기반 구조 (저장된 데이터의 정신적 모델과 일치)가 눈에 띄는 이점을 제공합니까?

답변

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

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

보정

“필요하지 않은 데이터를 필터링”하지 않습니다. 그 것이다 만을 선택 하여 필요한 데이터. 물론 WHERE 절에서 식별 된 열을 지원하는 인덱스가있는 경우 매우 빠르며 쿼리는 테이블 크기에 의존하지 않습니다 (160 억 행 테이블에서 1,000 개의 행을 가져옴). .
당신의 테이블에는 심각한 장애가 있습니다. 설명에 따르면 실제 PK는 (장치, 측정 항목, 날짜 시간)입니다. (TimeStamp라고 부르지 마십시오. 다른 의미가 있지만 사소한 문제입니다.) 행 의 고유성은 다음과 같이 식별됩니다.
```
   (Device, Metric, DateTime)
```
- 이 Id열은 아무 것도 수행하지 않으며 완전히 중복됩니다.
  - Id열은 키 (관계형 데이터베이스에 금지 중복 행은, 다른 방법으로 방지해야한다) 결코 없다.
  - 이 Id열에는 추가 색인이 필요합니다. 이는 분명히 속도를 방해하고 INSERT/DELETE사용 된 디스크 공간을 추가합니다.
  - 당신은 그것을 제거 할 수 있습니다. 부디.

높이

장애를 제거 했으므로이를 인식하지 못했을 수 있지만 테이블이 여섯 번째 정규 형식입니다. 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) 데이터 노화

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

단기간 (예 : 24 시간) 1 초의 원시 샘플
중간 기간 (예 : 1 주) 동안 5 분 세부 집계 샘플
1 시간 이상의 세부 정보 (예 : 최대 1 년)

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

자동 데이터 제거 (Redis의 EXPIRE 명령 참조)
다차원 집계 (예 : map-reduce 작업 a-la-Splunk)

2) 실시간 수집

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

답변

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

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

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

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

답변

파일을 작성하고 이름을 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를 살펴보십시오.

답변

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

답변

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

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

답변

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

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

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