セグメント化方法によって、E3C ストレージリポジトリでのデータの保存方法が決まります。E3C ストレージには、以下の論理的なレイヤーと物理的なレイヤーがあります。

データソースを Servigistics InService に追加するとき、ソースのロード先のコレクションを決定しなければなりません。通常、コレクションレベルは、オーサリングシステムからバンドルとして取得される基本単位を表します。コレクションレベルは論理的なレイヤーであるため、システムには影響を与えません。セグメントレイヤーは物理的なレイヤーであり、E3C ストレージではここにすべてのソースが保存されます。

コンテンツが Viewer サーバーにパブリッシングされると、そのコンテンツは E3C ストレージ内でセグメントに分割されます。これにより、サーチのパフォーマンスが適切に維持され、入出力操作の影響が最小限に抑えられます。セグメント化の計画の作成は、パブリッシングされた作成済みコンテンツによって大きく異なります。

セグメント化計画では、いくつかの事項を考慮に入れなければなりません。以下のセクションでは、データをセグメントに分割する方法を決定するときに役立つこれらの考慮事項の詳細について説明します。

データソースの数は、システムで作成されるセグメントの数に影響を与える重要な考慮事項の 1 つです。E3C ストレージのサイズに制限はありません。ただし、1 つのセグメント内に保存される語句の数には、そのオカレンスに基づいて、制限があります。

オカレンスとは、データ内の各単語 (および XML ドキュメント内の開くエレメントと閉じるエレメント) に関連付けられている数量です。コアセグメントのオカレンスは 2 GB に制限されています。セグメントの最大オカレンス容量にほぼ達すると、Viewer のパフォーマンス (サーチを実行するときなど) と増分アップデートのパフォーマンスの両方に影響が及びます。一般的に、セグメント内の単語 (オカレンス) の最大数として推奨されるのは 5 億 (0.5 GB) です。

セグメントあたりのソースの数とサイズを計画するには、データを分析し、単語の数を特定しなければなりません。この数に加えて、データの差分読み込みのためのバッファも考慮しなければなりません。次の分析方法を使用して、さまざまなデータサンプルの分析に基づいてセグメントを決定することをお勧めします。

セグメントに保存されるデータを決定するときに、オカレンスの容量が 25% ～ 50% (つまりオカレンスが約 500 MB ～ 1 GB) になることを目標にするのが理想的です。この数字は低すぎてはなりません。セグメントの数が多くなりすぎてオーバーヘッドが発生する可能性があるからです。セグメントの大半を占めるようになってもいけません。パフォーマンスに影響が及び、セグメントの制限に接近しすぎるからです。

次の表に、各データタイプに一般的に含まれているオカレンスの概算を示します。以下の割合 (%) は、セグメントの容量を 100% としています。

ファイルの数 (可能なかぎり 1000 ファイルに近い数を使用) に基づく結果は次のとおりです。

ディスクサイズ (可能なかぎり 10 MB を使用) に基づく結果は次のとおりです。

両方のテーブルに基づいてデータの計算を実行し、問題を回避するために平均または最も低い数字を選択することをお勧めします。

XML タイプには複数の異なるインデックシング定義があるため、以下の推奨されるデータサイズは IEXML タイプに基づいています。

これらのデータタイプを組み合わせる場合は、各タイプのデータサイズを相対的に算出して使用できます。たとえば、XML データは 3 GB、PDF データは 80 GB などです。

データサイズが表内の制限を超える場合は、データをいくつかのフラグメントに分割することをお勧めします。たとえば、XML が 20 GB で PDF が 500 GB の場合、6 つのセグメントが必要になると考えられます。

Servigistics InService では、ソース間で事前に定義されているリンクを使用して、1 つのデータソースから別のデータソース (ドキュメントやイメージなど) にリンクを設定できます。リンクは同じセグメント内でのみ設定できます。ほかのセグメント内のソースへのリンクは、Viewer では機能しません。したがって、リンクされているソースは同じセグメント内でロードされなければなりません。

データのタイプもセグメントのサイズに影響を与えます。たとえば、スキャンした PDF ドキュメントのセグメントサイズへの影響は最小限です。これらのドキュメントにはストレージ内にプロパティファイルがありますが、この場合、インデックシングされるオカレンスはごくわずかです。

したがって、データを分析して、セグメント内のさまざまなデータタイプを理解しなければなりません。

セグメント間のサーチは、ビジネスロジックレイヤーによって行われます。複数のセグメントにわたってサーチを行うことは非効率的です。サーチが各セグメントで個別に行われてから、このレイヤーが個別の結果を 1 つのサーチ結果リストに統合して整理するからです。システム内にあるセグメントが少なければ少ないほど、サーチの効率が上がります。

セグメント化を定義するときには、ほかの考慮事項とのバランスがとれるかぎり、セグメントの数をできるだけ少なくしてください。

共有ドキュメントとは、複数のコレクションにロードされるドキュメントです。共有モードでは、Servigistics InService は、このソースを含んでいるセグメント内のコレクションの数に関係なく、セグメントにつき 1 つの共有ドキュメントのコピーを保存します。

コレクションに共有ドキュメントが多数ある場合は、それらを単一のセグメントにロードして、これらのドキュメントのコピーの量を減らすことをお勧めします。

オフラインパッケージは 1 つのセグメントから作成されます。つまり、フルセグメントがすべての関連コレクションとともにオフラインシステムに配布されます。同じオフラインパッケージで配布しないコレクションは、複数のセグメントに分割しなければなりません。