2014-11-18 13 views
2

저는 현재 프로젝트를 개발 중이며 PLC (예 : 제어 모터, 속도, 스위치 등 기계 공장의 컨트롤러)에 연결된 산업 공장 센서에서 데이터를 검색하는 최선의 방법을 연구 중입니다. ...).산업용 데이터 센서 용 카산드라 저축 시계열

나는 달성 할 수있는 목표를 설명하고 나는 내 경우는 산업의 너무 많은 다른 종류에 추정 할 수 있다고 생각 : 나는 나에게 다른 데이터 값을 많이주는 몇 가지의 PLC를

  1. . (이 값들 중 상당수는 부울 뿐이며 다른 것은 아날로그 값입니다. 예를 들어 실제 타입입니다.)

  2. 전체 공장에는 10,000 개 이상의 센서가 있습니다.

  3. 아날로그 값 (예 : 모터 rmp, 온도, 습도 ....)에 대해 최소한 1 초마다 데이터를 검색하려고합니다.

  4. 디지털 값의 경우 데이터가 이벤트가 나타날 때 타임 스탬프와 함께 저장됩니다.

저는 카산드라와 함께 시계를 사용하고 싶습니다. 가장 유망하고 빠른 기술로 보입니다.

제 질문은 매초 아날로그 값을 저장하는 것에 관한 것입니다. 더 나은 같은 스키마하는 것입니다 :

타임 스탬프, 센서 1, 센서 2, 센서 2, sensor4

및 행 그룹을 부품으로 공장에서이거나 더 잘

모든 센서는 자신의 표가

?

전체 시스템이 Java로 개발되고 데이터를 분석하기 위해 외부 회사에 데이터를 제공합니다.

+0

이 질문을 게시 한 이후의 모든 업데이트는 문제를 어떻게 해결했는지에 대한 질문입니까? –

답변

3

검색어가 명확하지 않습니다. 당신은 언급 "나는 아날로그 값 (예 : 모터 rmp, 온도, 습도 ....)에 대한 최소한 매초마다 데이터를 검색하고 싶습니다".

모든 10K 센서에 대해 매초마다 쿼리하고 있다는 의미입니까? 또는 특정 센서 또는 센서 그룹의 경우? 카산드라에서는 데이터 모델을보기 전에 쿼리가 무엇인지 파악하는 것이 중요합니다. 1 초 분량을 찾고있는 경우 들어오는 데이터 스트림을 Spark Streaming에 공급하고 Spark Streaming 코드를 쿼리하려는 항목에 맞는 Cassandra 테이블에 저장하는 것이 좋습니다.

귀하가 언급 한 옵션에 대해서는 검색어의 정확한 특성을 모른 채 말하기가 어렵습니다. 하나의 키를 두 번째 키로 돌리면 옵션 일 수 있습니다. 이는 데이터 속도 또는 센서 당 1/s라고 가정 할 때 파티션 당 10K 정도의 항목을 의미합니다. 센서 당 테이블을 갖는 것은 별 다를 것이 없지만 각 엔트리마다 타임 스탬프가있는 센서 당 파티션을 가질 수 있습니다. 그것은 당신의 질문에 정말로 달려 있습니다.

아마도 데이터를 가져 오는 방법에 대한 예제를 주신다면 더 잘 할 수 있을까요?

+0

빠른 답장을 보내 주셔서 감사합니다. 센서 데이터를 저장하고 싶지만 적용 할 쿼리를 만들지 않았습니다. 내가 알고있는 유일한 데이터는 주식 시세 표시기와 같은 그래픽의 아날로그 값이 될 것입니다 (시간, 일, 월을 선택하면 그래픽이 표시됨). 그러나 실제로이 데이터 중 무엇이 표시되는지는 알지 못합니다. 같은 시간이지. – Guel135

+0

질문에 대해 조금은 알 필요가 있습니다. 시간, 요일, 달을 지정해 주겠다고 말하면 센서 또는 센서 모음을 지정합니까? 시간의 세분성은 무엇입니까? 2 초 안에 100 초의 이벤트를 예상하지 않는다면 ((day, hour, second), sensor_id) * 좋은 기본 키일 수 있습니다. 다시 말해서, 쿼리를 모른 채, 우리는 어둠에 던지고 있습니다. 사실 어떤 종류의 쿼리가 필요한지 확인하기 위해 요구 사항을 분석했습니다. 쿼리 기반 모델링은 마음을 바꿔 주지만 카산드라에게는 필수적입니다. – ashic

+0

우리는 스페인에서 지붕에서 집을 짓는 것과 같다는 말은 어떻게 되니? 나는 내 마음을 바꾸어야하고 나중에는 그것에 대한 적절한 시스템을 구축 할 수 있습니다. 그러나 우리는 나중에 어떤 데이터가 사용 될지 알지 못하는 문제에 직면하게되고 이것이 카산드라의 DB를 개발하는 데 문제가되고 있습니다. – Guel135

3

마지막으로 센서와 시간별로 데이터를 쿼리하고 싶다고 생각합니다. 테이블을 두 개 가지지 않고 각 데이터 포인트를 둘 다 쓰는 이유는 없습니다. (! 트위터는 트윗을 다음 각 사람에 대해 다른 테이블에 각 트윗을 쓰기)

을 당신이 쓰는 것 몇 가지 가능성이 테이블은 다음과 같습니다

CREATE TABLE factory_status (
    date timestamp, 
    hour int, 
    minute int, 
    second int, 
    sensor_status_map map<uuid, float> 
    PRIMARY KEY ((date, hour, minute, second)) 
) 

이 표는 기본적으로 공장에서 모든 센서의 상태를 기록 할 것 매 초. 각 파티션에는 팩토리의 스냅 샷이 포함됩니다. 이것은 당신이 효과적으로 시간의 범위를 얻을 수 없기 때문에 (각 초는 그것의 자신의 쿼리가 될 것입니다), 쿼리에서 유용하지는 않을 것입니다. 그러나 공장에서 분석을하고 실패에 대한 모델을 개발할 때 매우 강력 할 수 있습니다.

CREATE TABLE sensor_status (
    sensor_id uuid, 
    date timestamp, 
    time timestamp, 
    sensor_val float, 
    PRIMARY KEY ((sensor_id, date), time) 
) 

이 테이블은 기본적으로 각 센서의 출력을 기록합니다. 각 날짜는 시간의 일부가 절단됩니다. 그렇지 않으면 초당 1 회의 센서가 센서를 통해 카산드라의 기둥 제한을 빠르게 압도하게됩니다. 이렇게하면 특정 시간 또는 일정 기간에 센서의 상태를 쉽게 조회 할 수 있습니다.

"지붕에서 내려다보기"를 설계하는 데 어려움이있는 경우 반복 쿼리를 사용하여 이전 쿼리의 형태와 맞지 않는 새로운 쿼리를 찾을 때마다 새 테이블을 추가하십시오. .

+0

. 나는 당신에게 지금 포인트를줍니다. 몇 가지 질문에 성능 제한이있을 때 콜럼의 개수와 같은 제한이 있습니까? 또는 내가 처음으로 접근하는 방식으로지도를 연속으로 배치하는 것이 쉬운 접근법 일뿐만 아니라 나를 위해 매우 유연합니다 (새 센서 데이터를 추가하는 것이 일반적입니다). – Guel135

+0

카산드라는 넓은 행을 매우 효과적으로 처리합니다. 열의 수는 속도에 큰 영향을 미치지 않습니다. 열의 하위 집합을 쿼리하는 것도 효율적입니다. 쿼리 된 원시 데이터 양이 매우 커질 때 (약 2MB보다 큼) 스트리밍 문제가 있습니다.각 센서마다 단일 값 또는 소수의 값만 있다고 가정하면 10,000 개의 센서로 문제가 발생하면 놀랄 것입니다 (10 만 개가 더 우려 될 수 있음). – mildewey