분할 접근 방식은 데이터를 E3C 스토리지 저장소에 저장하는 방식을 결정합니다. E3C 스토리지에는 다음과 같은 논리적 및 물리적 레이어가 있습니다.

Servigistics InService에 데이터 소스를 추가할 때 소스가 로드될 컬렉션을 결정해야 합니다. 컬렉션 레벨은 일반적으로 저작 시스템에서 번들로 가져오는 기본 단위를 나타냅니다. 컬렉션 레벨은 논리적 레이어이므로 시스템에 영향을 주지 않습니다. 세그먼트 레이어는 모든 소스가 E3C 스토리지에 저장되는 물리적 레이어입니다.

콘텐츠가 Viewer 서버에 게시되면 입력 및 출력 작업의 영향을 최소화하고 허용 가능한 검색 성능을 유지하기 위해 콘텐츠가 E3C 스토리지 내의 세그먼트로 분할됩니다. 분할 계획 개발은 게시된 작성 콘텐츠에 따라 크게 달라집니다.

분할 계획에 대한 몇 가지 사항을 고려해야 합니다. 다음 단원에서는 데이터를 세그먼트로 분할하는 방법을 결정하는 데 도움이 되는 고려 사항에 대해 자세히 설명합니다.

데이터 소스의 수는 시스템에서 생성될 세그먼트 수에 영향을 주는 주요 고려 사항 중 하나입니다. E3C 스토리지 크기에 대한 제한은 없습니다. 그러나 단어 및 구문의 수에 대한 제한이 있습니다. 이러한 제한은 세그먼트 내에 저장된 발생을 기준으로 합니다.

발생은 데이터의 모든 단어(XML 문서의 모든 여는 요소 및 닫는 요소)와 연관된 수입니다. 코어 세그먼트는 2GB의 발생으로 제한됩니다. 세그먼트에 대한 최대 발생 용량에 거의 다다르면 Viewer 성능(예: 검색 수행 시)과 증분 업데이트 성능 둘 다에 영향을 줍니다. 일반적으로 세그먼트당 권장되는 단어(발생) 수는 최대 5억(0.5GB)입니다.

세그먼트당 소스 수 및 크기를 계획할 때 데이터를 분석하고 단어 수를 식별해야 합니다. 이 수 이외에도 증분 데이터 로드에 대한 버퍼를 고려해야 합니다. 다양한 데이터 샘플 분석을 기반으로 다음 분석 접근 방식을 사용하여 세그먼트를 결정하는 것이 좋습니다.

원칙적으로 세그먼트에 넣을 데이터를 결정할 때 목표는 25% ~ 50% 발생 용량(약 500MB ~ 1GB 발생)입니다. 이 수는 너무 적지 않아야 합니다. 세그먼트 및 연관된 오버헤드가 너무 많아져서 종료될 수 있기 때문입니다. 또한 세그먼트를 너무 꽉 채우지 않아야 합니다. 성능에 영향을 주고 세그먼트 제한에 너무 가까워질 수 있기 때문입니다.

다음 표에서는 각 데이터 유형이 일반적으로 포함하는 발생 양에 대한 대략적인 추정치를 제공합니다. 아래 백분율은 100%의 세그먼트 용량을 기준으로 합니다.

파일 수(가능한 경우 약 1000개의 파일로 세분화)를 기반으로 한 결과입니다.

디스크 크기(가능한 경우 10MB로 세분화)를 기반으로 한 결과입니다.

이 두 표를 기반으로 데이터 계산을 수행하고 안전한 쪽에 해당하는 평균 또는 가장 낮은 수를 선택하는 것이 좋습니다.

색인 정의가 서로 다른 XML 유형 고려 시 IEXML 유형에 따라 다음 데이터 크기가 권장됩니다.

데이터 유형을 혼합하려면 파일의 상대적 부분을 사용할 수 있습니다. 예를 들어, 3GB의 XML 데이터와 80GB의 PDF 데이터입니다.

데이터 크기가 표에 있는 제한을 초과하면 데이터는 여러 조각으로 나뉘어 표시됩니다. 예를 들어, 20GB의 XML 및 500GB의 PDF가 있으면 6개의 조각이 필요합니다.

Servigistics InService를 사용하면 소스 간에 사전 정의된 링크를 사용하여 한 데이터 소스에서 다른 데이터 소스(문서, 이미지 등)로 연결할 수 있습니다. 링크는 동일한 세그먼트 내에서만 수행할 수 있습니다. 다른 세그먼트의 소스에 대한 링크는 Viewer에서 작동하지 않습니다. 따라서 연결된 소스는 동일한 세그먼트에 로드되어야 합니다.

데이터 유형은 세그먼트의 크기에도 영향을 줍니다. 예를 들어, 검색한 PDF 문서는 세그먼트 크기에 약간의 영향을 줍니다. 이러한 문서에는 저장소 내에서 함께 보관되는 등록 정보 파일이 있지만 이 경우 색인화될 발생은 매우 적습니다.

따라서 세그먼트에 있는 여러 데이터 유형을 파악하려면 해당 데이터를 분석해야 합니다.

세그먼트 간 검색은 비즈니스 로직 레이어에 의해 수행됩니다. 여러 세그먼트 간에 검색을 수행하면 더 많은 시간을 소비합니다. 검색이 세그먼트마다 개별적으로 완료된 다음 레이어가 별도의 결과를 하나의 검색 결과 목록으로 결합하고 정렬하기 때문입니다. 시스템에 있는 세그먼트의 수가 적을수록 검색이 더 효율적으로 수행됩니다.

분할을 정의할 때 다른 고려 사항을 감안하여 세그먼트의 수를 가능한 적게 유지하십시오.

공유 문서는 둘 이상의 컬렉션에 로드되는 문서입니다. 공유 모드에서 Servigistics InService는 이 소스를 포함하는 세그먼트의 컬렉션 수에 상관없이 세그먼트당 공유 문서 복사본 하나만 저장합니다.

공유 문서가 많은 컬렉션이 있는 경우 이러한 문서의 복사본 양을 줄이기 위해 해당 컬렉션을 단일 세그먼트에 로드하는 것이 좋습니다.

오프라인 패키지는 세그먼트에서 생성됩니다. 즉, 전체 세그먼트가 연관된 모든 컬렉션과 함께 오프라인 시스템에 배포됩니다. 동일한 오프라인 패키지에 배포되지 않아야 할 컬렉션은 서로 다른 세그먼트로 분할해야 합니다.