Servigistics InService のパブリッシングおよびロード > パブリッシングとロードの使用 > TAL コンフィギュレーション > セグメント化方法の定義
  
セグメント化方法の定義
セグメント化方法によって、E3C ストレージリポジトリでのデータの保存方法が決まります。E3C ストレージには、以下の論理的なレイヤーと物理的なレイヤーがあります。
セグメントレイヤー - 1 つ以上のコレクションの物理的な分離またはコンテンツホルダー。
コレクションレイヤー - データを分割して Servigistics InService にロードする論理的な方法。
これは、バンドル内のさまざまなコンテキストを集約したものです。
データソースを Servigistics InService に追加するとき、ソースのロード先のコレクションを決定しなければなりません。通常、コレクションレベルは、オーサリングシステムからバンドルとして取得される基本単位を表します。コレクションレベルは論理的なレイヤーであるため、システムには影響を与えません。セグメントレイヤーは物理的なレイヤーであり、E3C ストレージではここにすべてのソースが保存されます。
コンテンツが Viewer サーバーにパブリッシングされると、そのコンテンツは E3C ストレージ内でセグメントに分割されます。これにより、サーチのパフォーマンスが適切に維持され、入出力操作の影響が最小限に抑えられます。セグメント化の計画の作成は、パブリッシングされた作成済みコンテンツによって大きく異なります。
セグメント化計画では、いくつかの事項を考慮に入れなければなりません。以下のセクションでは、データをセグメントに分割する方法を決定するときに役立つこれらの考慮事項の詳細について説明します。
セグメントあたりのソースの数とサイズ
データソースの数は、システムで作成されるセグメントの数に影響を与える重要な考慮事項の 1 つです。E3C ストレージのサイズに制限はありません。ただし、1 つのセグメント内に保存される語句の数には、そのオカレンスに基づいて、制限があります。
オカレンスとは、データ内の各単語 (および XML ドキュメント内の開くエレメントと閉じるエレメント) に関連付けられている数量です。コアセグメントのオカレンスは 2 GB に制限されています。セグメントの最大オカレンス容量にほぼ達すると、Viewer のパフォーマンス (サーチを実行するときなど) と増分アップデートのパフォーマンスの両方に影響が及びます。一般的に、セグメント内の単語 (オカレンス) の最大数として推奨されるのは 5 億 (0.5 GB) です。
セグメントあたりのソースの数とサイズを計画するには、データを分析し、単語の数を特定しなければなりません。この数に加えて、データの差分読み込みのためのバッファも考慮しなければなりません。次の分析方法を使用して、さまざまなデータサンプルの分析に基づいてセグメントを決定することをお勧めします。
セグメントに保存されるデータを決定するときに、オカレンスの容量が 25% ~ 50% (つまりオカレンスが約 500 MB ~ 1 GB) になることを目標にするのが理想的です。この数字は低すぎてはなりません。セグメントの数が多くなりすぎてオーバーヘッドが発生する可能性があるからです。セグメントの大半を占めるようになってもいけません。パフォーマンスに影響が及び、セグメントの制限に接近しすぎるからです。
次の表に、各データタイプに一般的に含まれているオカレンスの概算を示します。以下の割合 (%) は、セグメントの容量を 100% としています。
ファイルの数 (可能なかぎり 1000 ファイルに近い数を使用) に基づく結果は次のとおりです。
データタイプ
ファイルの数
オカレンス寄与
オカレンス寄与 (%)
PartsList
1042 (XMD 付きの場合は 2084)
749364
0.0375
PDF
906
41093041
2
IEXML
1000
2833986
0.14
ディスクサイズ (可能なかぎり 10 MB を使用) に基づく結果は次のとおりです。
データタイプ
サイズ
オカレンス寄与
オカレンス寄与 (%)
PartsList
10 MB
277542
0.0138
PDF
10 MB
37020
0.002
IEXML
10 MB
1190750
0.06
両方のテーブルに基づいてデータの計算を実行し、問題を回避するために平均または最も低い数字を選択することをお勧めします。
XML タイプには複数の異なるインデックシング定義があるため、以下の推奨されるデータサイズは IEXML タイプに基づいています。
データタイプ
データサイズ
XML (PartList、IEXML)
5 ~ 7 GB
PDF
150 ~ 200 GB
これらのデータタイプを組み合わせる場合は、各タイプのデータサイズを相対的に算出して使用できます。たとえば、XML データは 3 GB、PDF データは 80 GB などです。
データサイズが表内の制限を超える場合は、データをいくつかのフラグメントに分割することをお勧めします。たとえば、XML が 20 GB で PDF が 500 GB の場合、6 つのセグメントが必要になると考えられます。
ドキュメント間の参照
Servigistics InService では、ソース間で事前に定義されているリンクを使用して、1 つのデータソースから別のデータソース (ドキュメントやイメージなど) にリンクを設定できます。リンクは同じセグメント内でのみ設定できます。ほかのセグメント内のソースへのリンクは、Viewer では機能しません。したがって、リンクされているソースは同じセグメント内でロードされなければなりません。
データのタイプ
データのタイプもセグメントのサイズに影響を与えます。たとえば、スキャンした PDF ドキュメントのセグメントサイズへの影響は最小限です。これらのドキュメントにはストレージ内にプロパティファイルがありますが、この場合、インデックシングされるオカレンスはごくわずかです。
したがって、データを分析して、セグメント内のさまざまなデータタイプを理解しなければなりません。
複数のセグメントにわたるサーチ
セグメント間のサーチは、ビジネスロジックレイヤーによって行われます。複数のセグメントにわたってサーチを行うことは非効率的です。サーチが各セグメントで個別に行われてから、このレイヤーが個別の結果を 1 つのサーチ結果リストに統合して整理するからです。システム内にあるセグメントが少なければ少ないほど、サーチの効率が上がります。
セグメント化を定義するときには、ほかの考慮事項とのバランスがとれるかぎり、セグメントの数をできるだけ少なくしてください。
コレクション間の共有ドキュメントの数
共有ドキュメントとは、複数のコレクションにロードされるドキュメントです。共有モードでは、Servigistics InService は、このソースを含んでいるセグメント内のコレクションの数に関係なく、セグメントにつき 1 つの共有ドキュメントのコピーを保存します。
コレクションに共有ドキュメントが多数ある場合は、それらを単一のセグメントにロードして、これらのドキュメントのコピーの量を減らすことをお勧めします。
オフラインセグメント
オフラインパッケージは 1 つのセグメントから作成されます。つまり、フルセグメントがすべての関連コレクションとともにオフラインシステムに配布されます。同じオフラインパッケージで配布しないコレクションは、複数のセグメントに分割しなければなりません。