DataStax Enterprise를 지속성 공급자로 사용

Composer의 ThingWorx 모델 정의 > 데이터 스토리지 > 지속성 공급자 > DataStax Enterprise를 지속성 공급자로 사용

개요

ThingWorx Platform 버전 8.5.0부터 DSE는 더 이상 판매되지 않으며 향후 릴리즈에서 지원되지 않습니다. 자세한 내용은 판매 종료 기사를 참조하십시오.

모델에 빅 데이터 확장성이 요구되는 경우 ThingWorx에서 확장 가져오기를 통해 지속성 공급자로 DSE(DataStax Enterprise)를 사용할 수 있습니다. 확장 DsePersistenceProviderPackage.zip은 통합 제공으로 Solr 검색 엔진이 있는 Cassandra의 DataStax Enterprise 에디션(오픈 소스/커뮤니티 에디션 아님)을 사용하기 위해 작성되었습니다. DSE는 Apache Cassandra에 구축된 빅 데이터 플랫폼으로 실시간, 분석 및 엔터프라이즈 검색 데이터를 관리합니다.

Cassandra는 확장 가능한 오픈 소스 NoSQL 데이터베이스로, 여러 데이터 센터와 클라우드에서 대량의 데이터를 관리할 수 있습니다. Cassandra는 단일 실패 지점이 없는 여러 상품 서버에 지속적인 가용성, 선형 확장성 및 작동 간편성을 제공하며, 최대의 유연성과 빠른 응답 시간을 위해 설계된 강력한 데이터 모델을 제공합니다.

DSE를 시작할 때 DSE를 등록, 설치 및 구성해야 합니다. 이 프로세스는 대부분 ThingWorx와 독립적으로 수행되며 해당 설명이 여기에 나와 있습니다.

DataStax Enterprise 배포 계획을 세우려면 먼저 해당 아키텍처 및 특히 일반 관계형 데이터베이스와 비교했을 때의 차이를 이해해야 합니다. Cassandra를 처음 사용하는 경우 DataStax Academy에서 제공하는 무료 온라인 강좌, 특히 다음부터 시작하는 것이 좋습니다.

• https://academy.datastax.com/courses/understanding-cassandra-architecture

• https://academy.datastax.com/courses/installing-and-configuring-cassandra

다음 단원에서는 몇 가지 세부 사항을 안내합니다.

• http://datastax.com/documentation/cassandra/2.0/cassandra/architecture/architecturePlanningAbout_c.html

DSE 및 ThingWorx 시작 환경

다음은 이 문서에서 DSE에 대한 구성을 언급할 때 사용되는 용어입니다.

• 노드 - 데이터를 저장하는 위치입니다. Cassandra의 기본 인프라 구성 요소입니다.

• 데이터 센터 - 관련 노드의 컬렉션입니다. 데이터 센터는 물리적 데이터 센터 또는 가상 데이터 센터일 수 있습니다. 서로 다른 워크로드에서 사용하는 데이터 센터는 서로 달라야 합니다(물리적 데이터 센터 또는 가상 데이터 센터). 복제는 데이터 센터에 의해 설정됩니다. 이렇게 서로 다른 데이터 센터를 사용해야 Cassandra 트랜잭션이 다른 워크로드의 영향을 받지 않으며, 더 짧은 대기 시간을 위해 요청을 서로 가깝게 유지합니다. 복제 요소에 따라 데이터를 여러 데이터 센터에 기록할 수 있습니다. 그러나 데이터 센터는 물리적 위치를 범위에 두지 않아야 합니다.

• 클러스터 - 클러스터에 하나 이상의 데이터 센터가 포함되어 있습니다. 클러스터는 물리적 위치에 걸쳐 있을 수 있습니다.

ThingWorx에서의 DSE 구현에 대한 상위 레벨 프로세스

1. DSE가 데이터에 대한 올바른 솔루션인지 확인합니다. 자세한 내용은 크기 조정 및 계획 섹션을 참조하십시오.

2. DSE를 등록하고 설치합니다.

이 프로세스는 ThingWorx와 독립적으로 수행됩니다. 배포 예가 제공됩니다.

3. DSE 지속성 공급자 확장을 ThingWorx로 가져옵니다.

4. DSE 데이터 저장소에 연결하는 ThingWorx에서 지속성 공급자 인스턴스를 생성합니다.

5. ThingWorx의 지속성 공급자에 대한 설정을 구성합니다. 자세한 설정은 아래 표에 나와 있습니다.

스트림, 가치 스트림 및 데이터 테이블의 경우 버킷 설정을 구성할 수 있습니다. 이러한 설정은 DSE 지속성 공급자 인스턴스 구성을 재정의합니다.

이름

기본값

설명

연결 정보

Cassandra 클러스터 호스트

192.168.234.136,192.168.234.136

Cassandra 클러스터에 대한 IP 주소입니다. Cassandra 클러스터를 설치하기 위해 DSE를 설정하는 중 구성된 IP 주소 또는 호스트 이름입니다.

Cassandra 클러스터 포트

9042

Cassandra 클러스터를 설치하기 위해 DSE를 설정하는 중 구성된 Cassandra 클러스터에 대한 포트입니다.

Cassandra 사용자 이름

해당 없음

선택 사항이며, 클러스터에 대해 인증을 활성화하지 않으려는 한 유지됩니다. 이러한 경우 이 필드는 필수 사항입니다.

인증의 활성화는 Cassandra 클러스터에서 수행해야 합니다. 사용자는 키스페이스를 생성하기 위해 적절한 승인 수준이 필요합니다.

Cassandra 암호

해당 없음

선택 사항이며, 클러스터에 대해 인증을 활성화하지 않으려는 한 유지됩니다. 이러한 경우 이 필드는 필수 사항입니다. (위 사항 참조).

Cassandra 키스페이스 이름

thingworxnd

ThingWorx 데이터가 가리키는 위치입니다. 관계형 데이터베이스의 스키마와 유사합니다.

DsePersistenceProviderPackage.zip의 1.0 버전에서 업그레이드할 경우 이 필드는 필수 사항입니다.

Solr 클러스터 URL

http://localhost

데이터 테이블을 사용하는 경우 Cassandra 클러스터를 설치하기 위해 DSE를 설정하는 동안 구성된 도메인 또는 IP를 비롯하여 완전한 호스트 이름 또는 IP를 제공합니다.

Solr 클러스터 포트

8983

데이터 테이블을 사용하는 경우 Cassandra 클러스터를 설치하기 위해 DSE를 설정하는 동안 구성된 포트를 제공합니다.

Cassandra 키스페이스 설정

replication = {'class':'NetworkTopologyStrategy', 'Cassandra':1, 'Solr':1}

DSE를 설정하는 동안 생성된 Cassandra 클러스터 구성에 따라 달라집니다. 사용된 데이터 센터 및 연관된 복제 요소를 주로 정의합니다(자세한 내용은 http://datastax.com/documentation/cql/3.1/cql/cql_reference/create_keyspace_r.html 참조). 관리자가 키스페이스를 수동으로 생성한 경우 이러한 설정이 수동으로 생성된 키스페이스 설정과 일치해야 합니다.

Cassandra 일관성 수준

{'Cluster' : { 'read' : 'ONE', 'write' : 'ONE' }}

노드 수에 대한 일관성 수준을 읽고 씁니다.

쓰기에 대해 중복 복사본을 포함하도록 둘 이상의 노드를 구현합니다. 자세한 내용은 http://datastax.com/documentation/cassandra/2.1/cassandra/dml/dml_config _consistency_c.html을 참조하십시오.

CQL 질의 결과 제한

5000

Cassandra Query Language 질의 결과 제한은 데이터를 질의할 때 반환되는 행 수를 지정합니다. 이렇게 하면 플랫폼에서 성능 문제를 발생할 수 있는 대량의 결과 집합이 반환되지 않도록 하여 ThingWorx의 안정성을 향상합니다.

연결 유지

true

Cassandra 클러스터에 대한 연결을 유지할 수 있습니다. 특히 방화벽에 대해 비활성 연결을 삭제할 수 있습니다.

ThingWorx와 Cassandra 클러스터 간에 방화벽을 구현하지 마십시오.

연결 제한 시간(밀리초)

30000

초기 연결 제한 시간(밀리초)입니다. ThingWorx와 Cassandra 클러스터 간의 네트워크 대기 시간에 따라 달라집니다.

압축 알고리즘

없음

ThingWorx가 클러스터에 데이터를 보낼 때 다음과 같은 세 가지 옵션이 있습니다.

• Lz4 압축

• Snappy 압축

• 압축 없음

ThingWorx와 Cassandra 클러스터 간의 네트워크 대역폭이 낮을 경우 압축을 사용하면 처리양이 증가합니다.

압축은 ThingWorx가 실행되는 시스템에서 더 많은 CPU 주기를 소모합니다.

최대 질의 재시도 횟수

질의에 대해 활성화된 최대 재시도 횟수입니다. 기본값은 3회입니다.

로컬 코어 연결

데이터를 읽거나 쓸 수 있는 최소 연결 수입니다.

로컬 최대 연결

데이터를 읽거나 쓸 수 있는 최대 연결 수입니다.

원격 코어 연결

데이터를 읽거나 쓸 수 있는 최소 원격 연결 수입니다.

원격 최대 연결

데이터를 읽거나 쓸 수 있는 최대 원격 연결 수입니다.

추적 사용

false

로깅입니다. 디버깅에 대해 활성화할 수 있습니다.

최대 비동기 요청

1000

클래식 스트림 설정

캐시 초기 크기

10000

초기 캐시 크기입니다. 이 값은 소스 수에 따라 달라집니다.

구성된 소스 수 이상을 사용하십시오.

캐시 최대 크기

100000

최대 캐시 크기입니다. 메모리 사용을 제어합니다.

캐시 동시성

동시에 액세스할 수 있는 스레드 수입니다. 최소값은 원격 최대 연결에 설정된 값을 반영해야 합니다.

클래식 스트림 기본값

소스 버킷 개수

1000

소스를 버킷에 넣을 수 있습니다. 소스 수는 실행해야 할 질의 수와 동일합니다. 예를 들어, 소스가 100,000개인 경우 이 필드는 사용되는 버킷의 수를 결정합니다.

데이터가 작성된 후 이 설정이 변경되면 ThingWorx를 통해 데이터에 액세스할 수 없습니다. 데이터가 작성된 후 이 설정을 변경해야 할 경우 설정을 변경하기 전에 데이터를 내보낸 다음 데이터를 다시 가져오십시오.

시간 버킷 크기(시간)

버킷을 생성하는 시간입니다. 소스 버킷 크기가 설정되는 방식에 따라 달라집니다. 예를 들어, 시간 버킷 크기가 24로 설정되면 24시간마다 버킷이 생성됩니다. 목표는 2백만 개의 데이터 점을 초과하지 않는 것입니다. 따라서 가치 스트림당 또는 클래식 스트림당 데이터 소비 속도(R/s)에 따라: 시간 버킷 크기 = 2mil/(R * 60 * 60)

데이터 테이블 기본값

데이터 테이블 버킷 개수

데이터 테이블을 버킷으로 분할할 수 있습니다. 이렇게 하면 DSE 노드에 데이터 테이블을 분산할 수 있습니다. 부하에 따라 노드의 수가 증가할 때 데이터 분산을 허용하기 위해 클러스터의 노드 수보다 높은 값이 권장됩니다. 고려할 다른 요소는 데이터 테이블에 예상되는 행 수입니다. 버킷당 200,000개의 행으로 제한하는 것을 고려하십시오. 여기의 설정은 기본값입니다. 버킷 개수는 데이터 테이블마다 지정할 수 있습니다.

데이터가 작성된 후 이 설정이 변경되면 플랫폼을 통해 데이터에 액세스할 수 없습니다. 데이터가 작성된 후 이 설정을 변경해야 할 경우 설정을 변경하기 전에 데이터를 내보낸 다음 데이터를 다시 가져오십시오.

가치 스트림 설정

캐시 초기 크기

10000

초기 캐시 크기입니다. 이 값은 소스 수에 소스당 속성의 수를 곱한 값에 따라 달라집니다.

캐시 최대 크기

100000

최대 캐시 크기입니다. 메모리 사용을 제어합니다.

캐시 동시성

동시에 액세스할 수 있는 스레드 수입니다.

가치 스트림 기본값

소스 버킷 개수

1000

속성 버킷 개수

1000

버킷의 수는 가치 스트림 및 질의 패턴당 속성의 수에 따라 달라집니다. 속성에 분산되는 질의가 있는 경우 작은 버킷 크기가 최고의 성능을 제공합니다.

시간 버킷 크기(시간)

버킷의 크기입니다. 소스 버킷 크기가 설정되는 방식에 따라 달라집니다. 예를 들어, 시간 버킷 크기가 24로 설정되면 24시간마다 버킷이 생성됩니다.

6. 필요한 경우 엔티티 및 데이터를 마이그레이션합니다.

7. DSE 구현을 모니터링하고 유지 관리합니다. 성공적인 유지 관리 계획 작성에 대한 모범 사례는 여기에 설명되어 있습니다.