ThingWorx에 데이터 저장
ThingWorx는 데이터를 저장하기 위한 엔티티와 방법을 제공합니다. 데이터 테이블, 사물 속성, 스트림, 가치 스트림 및 구성 테이블에 데이터를 저장할 수 있습니다.
솔루션을 개발하는 동안 ThingWorx가 데이터 스토리지를 처리하는 방법을 고려해야 합니다. 데이터 스토리지는 프로젝트의 결과, 프로젝트의 확장성과 안정성, 사용자 경험에 영향을 주므로 올바른 데이터 스토리지를 선택하는 것은 매우 중요합니다.
다음 단원에서는 ThingWorx 모델의 스토리지 옵션에 대해 설명합니다.
데이터 테이블
◦ 데이터 행이 100,000개 미만인 경우 사용합니다.
◦ 정적 데이터 집합 및 정적 조회 테이블에 사용합니다. 매우 동적이고 규모가 큰 데이터 집합의 경우 Database 사물 템플릿을 통해 연결된 관계형 데이터베이스를 사용합니다.
|
복잡한 질의 및 조인에는 관계형 데이터베이스를 사용합니다.
|
◦ 키 기반 질의 및 스토리지와 기본 키를 기반으로 한 용이한 업데이트 및 삭제에 사용합니다.
예: 스마트 커넥티드 자동판매기의 재고에 대한 정보를 저장할 수 있습니다. 여기서 재고의 각 위치는 기본 키입니다. 또한 데이터 테이블을 사용하여 작물 관리 장치에 사용할 수 있는 관개 프로그램에 대한 정보를 저장할 수 있습니다. 여기서 각 관개 프로그램은 기본 키가 있는 행입니다.
◦ 행 단위로 데이터를 조작하거나 질의하려면 데이터 테이블을 사용합니다.
◦ 데이터 테이블로 작업할 때는 색인을 사용합니다.
사물 속성
사물 속성을 사용하여 사물에 대한 데이터를 ThingWorx에 저장합니다. 속성에는 다음과 같은 데이터 스토리지 옵션이 있습니다.
◦ 읽기 전용 - 런타임에 변경되지 않아야 하는 정적 값에 읽기 전용 옵션을 사용합니다. 그러나 원하는 경우 기본값을 변경할 수 있습니다.
◦ 지속됨 - ThingWorx 서버가 다시 시작된 후에도 속성 값을 저장하려는 경우 및 속성 값이 런타임에 변경될 수 있는 경우 지속됨 옵션을 사용합니다.
◦ 로깅됨 - 값이 지속적으로 업데이트되는 속성에 로깅됨 옵션을 사용합니다. 이는 가치 스트림에 저장될 수 있는 시계열 데이터입니다.
|
기록 데이터를 저장하는 데 명시적 속성을 사용하지 마십시오. 대신 스트림이나 가치 스트림을 사용하십시오.
|
스트림
장치의 시간 제어 프로세스 이벤트 또는 작업을 로깅하는 데 사용합니다.
예를 들어, 장치 작업에 대한 문제를 로깅하기 위한 스트림을 만들거나 장치가 ThingWorx 플랫폼에서 연결 해제되었다가 다시 연결될 때 기록하기 위한 스트림을 만듭니다. 스트림은 고속 쓰기에 최적화되어 있으며 구성 가능한 캐시 시스템이 있습니다.
가치 스트림
사물의 속성에서 가져온 시계열 데이터를 저장하는 데 사용합니다.
스트림이 있으면 데이터 테이블이 작성됩니다. 가치 스트림을 사용하면 부족하게 채워진 데이터 테이블 작성 단계가 제거됩니다.
가치 스트림에서 사물 중심의 데이터 액세스는 다중 테넌시에 대한 기본 제공 지원을 제공합니다.
RDMS(PostgreSQL, MSSQL)를 사용하면 다른 사물에 대한 다른 가치 스트림에서 가져온 레코드를 포함하여 모든 레코드가 데이터베이스의 동일한 테이블에 작성됩니다.
PostgreSQL을 사용하면 PostgreSQL 데이터베이스의 ValueStream에 대한 테이블에서 각 행은 속성 하나에 대해서만 레코드를 보유합니다. 즉, 가치 스트림은 각 속성의 값 변경을 독립적으로 추적합니다. QueryPropertyHistory 서비스를 사용한 후 데이터 흐름에서 사물의 각 속성을 확인하고 모든 최신 업데이트(각각 업데이트 시간이 다름)를 하나의 인포테이블 결과에 수집합니다.
다음 표에서는 스트림과 가치 스트림의 주요 차이에 대한 정보를 제공합니다. 이 정보를 사용하여 솔루션에 시계열 데이터를 저장하는 데 사용할 엔티티의 유형을 결정합니다.
스트림
|
가치 스트림
|
스트림에 모든 유형의 시계열 데이터를 저장할 수 있습니다.
|
가치 스트림에 사물 속성의 시계열 데이터를 저장할 수 있습니다.
가치 스트림은 사물의 속성에 바인딩됩니다.
|
고유한 서비스를 사용하여 스트림에서 직접 데이터를 질의할 수 있습니다. 질의 결과는 전체 데이터 행입니다.
|
가치 스트림에서 데이터를 직접 질의할 수 없습니다. 대신 사물에 정의된 서비스를 사용하여 가치 스트림의 데이터를 질의합니다. 예: QueryPropertyHistory
|
스트림에 데이터 행을 추가하려면 WritePropertiesToStream 서비스를 사용합니다.
|
가치 스트림에 데이터를 추가하려면 속성에 대해 로깅됨 확인란을 선택합니다.
|
스트림에 컨텍스트 데이터를 저장할 수 있습니다. 예를 들어, 특정 이벤트가 트리거될 때마다 다른 속성의 값을 추가할 수 있습니다. 이는 데이터 분석에 유용합니다.
|
가치 스트림에 컨텍스트 데이터를 저장할 수 없습니다.
|
스트림 또는 가치 스트림을 사용하는 경우
◦ 시계열 데이터를 저장하고 검색하려면 가치 스트림 및 스트림을 사용합니다. 저장해야 하는 데이터의 양에 따라 올바른 데이터 스토리지 옵션을 선택합니다.
◦ 스트림은 단기간의 데이터를 질의하려는 경우에만 사용합니다.
◦ 사물을 여러 가치 스트림으로 분할하여 색인 성능을 개선합니다.
구성 테이블
ThingWorx Platform에서 안전하게 업그레이드할 수 있는 사용자 정의 가능한 솔루션을 빌드하려면 사용합니다.
사전 정의된 데이터 셰이프를 기반으로 매쉬업 엔티티에 구성 테이블을 추가할 수 있습니다. 이렇게 하면 사용자 정의 가능한 확장 매쉬업을 빌드하는 프로세스가 간소화되며 확장 업그레이드 동안 구성 테이블 값이 전달되므로 이 경우에도 내부 업그레이드가 여전히 지원됩니다.
데이터 공급자를 위한 데이터베이스 중단 복구
데이터베이스가 다시 시작되거나 중단되어 수집된 데이터를 데이터 공급자에서 지속할 수 없는 경우, platform-settings.json에서 필수 지속성 공급자에 대해 다음 구성 가능한 속성을 설정하여 데이터 손실을 방지하기 위해 해당 작업을 다시 시도하도록 시스템을 구성할 수 있습니다.
• acquireRetryAttempts: ThingWorx가 포기하기 전에 데이터베이스에서 새 연결을 취득하려고 시도하는 횟수를 정의합니다.
• acquireRetryDelay: 취득 시도 간 ThingWorx가 대기하는 시간(밀리초)입니다.
따라서 ThingWorx는 구성된 설정에 따라 각 시도 사이에 acquireRetryDelay만큼 지연하고 최대 acquireRetryAttempts번 다시 시도합니다. 예를 들어, 데이터베이스가 다시 온라인 상태가 될 때까지 ThingWorx에서 5초 동안 대기해야 하는 경우 acquireRetryAttempts=5 및 acquireRetryDelay=1000을 설정합니다.
모든 재시도 시도가 실패하면 다음 오류 메시지가 ApplicationLog에 로깅되어 엔트리를 지속하지 못했음을 나타냅니다. Failed to connect to persistence provider after retrying 5 times in 10 seconds.
|
acquireRetryAttempts를 0보다 작거나 같은 값으로 설정하지 않는 것이 좋습니다. 그런 경우 응용 프로그램이 엔트리 지속을 무한대로 다시 시도하므로 데이터베이스가 장기간 중단될 경우 플랫폼도 중단될 수 있기 때문입니다.
|
InfluxDB를 선택적 지속성 공급자로 사용하는 동안 데이터베이스 작업을 구성된 횟수로 다시 시도하도록 DatabaseWriteRetryAttempts를 구성해야 합니다.
|
자주 변경되는 지속된 속성 및 로깅된 속성의 경우 배치 기반 처리로 인해 매우 적은 데이터 손실은 불가피합니다. 이러한 시나리오에서는 ApplicationLog에 다음과 같은 메시지가 로깅됩니다.
지속된 속성: BatchUpdateException error occurred executing batch update of persistent properties.
로깅된 속성 또는 ValueStream 수집: Error executing batch.
|
|
데이터를 수집 속도에 따라 보유하도록 대기열 크기를 적절히 구성해야 합니다.
|
InfluxDB를 선택적 지속성 공급자로 사용하는 동안 데이터베이스 작업을 구성된 횟수로 다시 시도하도록 DatabaseWriteRetryAttempts를 구성해야 합니다.
|
자주 변경되는 지속된 속성 및 로깅된 속성의 경우 배치 기반 처리로 인해 매우 적은 데이터 손실은 불가피합니다. 이러한 시나리오에서는 ApplicationLog에 다음과 같은 메시지가 로깅됩니다.
지속된 속성: BatchUpdateException error occurred executing batch update of persistent properties.
로깅된 속성 또는 ValueStream 수집: Error executing batch.
|
|
데이터를 수집 속도에 따라 보유하도록 대기열 크기를 적절히 구성해야 합니다.
|
성능에 대한 자세한 내용은
성능 보고서를 참조하십시오.
데이터 중심 모델링 처리를 위한 모범 사례
ThingWorx에서 데이터 중심 모델링을 처리하려면 다음과 같은 일반 모범 사례를 사용하십시오.
• 변경되지 않거나 다음에 변경되고 로드될 때 덮어쓰여질 데이터가 있으며 해당 데이터가 사물과 연관되어 있는 경우 해당 사물에 대한 인포테이블 속성을 생성하고 적합한 데이터 셰이프를 지정합니다. 이러한 방식으로 사물을 통해 데이터에 액세스할 수 있습니다. 구성 테이블을 사용하거나 데이터의 양이 많은 경우에도 데이터 테이블을 사용할 수 있습니다.
• 데이터 캐시를 가능한 한 많이 사용합니다.
예를 들어, 각 DataChange 이벤트에 대해 데이터베이스를 질의하는 대신 설정된 간격마다 새로 고쳐지는 인포테이블로 캐시를 구현합니다.
• 더 이상 필요하지 않은 데이터는 보관합니다.
솔루션을 설계하는 동안 자주 사용되는 데이터를 결정해야 합니다. 이 데이터는 솔루션 데이터베이스에 저장할 수 있습니다. 이전 데이터를 가능한 한 빨리 외부 서버(예: ThingWorx 페더레이션 인스턴스 또는 데이터베이스 서버)로 이동합니다.
• 질의 메소드에 시작 및 종료 날짜 매개 변수를 제공하여 질의가 검색하는 데이터의 양을 제한합니다. 이렇게 하면 처리 시간이 줄어들고 성능이 개선됩니다.
• 데이터 테이블의 행이 100,000개 미만이어야 합니다.
• 데이터 테이블 및 스트림에서 데이터 질의 시 몇 초 정도만 소요되어야 합니다. 이러한 데이터 테이블과 스트림에 행이 100,000개 이상 있으면 질의 속도가 느려집니다.
• 이전 데이터를 제거하는 방법을 계획해야 합니다. 데이터 제거는 솔루션의 성능을 개선하는 데 도움을 주므로 중요합니다.