您采用的分段方法决定了数据在 E3C 存储信息库中的存储方式。E3C 存储具有以下逻辑层和物理层：

将数据源添加到 Servigistics InService 中时，应确定源将加载到的集合。集合级别通常表示基本单位 (作为创作系统中的束)。由于“集合”级别是逻辑层，它对系统没有任何影响。段层是所有源都存储在 E3C 存储中的物理层。

当内容发布到 Viewer 服务器时，内容在 E3C 存储内被划分为多个段，以保持搜索性能可接受，并将输入和输出操作的影响降至最低。开发分段计划很大程度上取决于已发布的创作内容。

对于分段计划，您应考虑以下一些注意事项。以下各部分提供了有关这些注意事项的详细信息，以帮助您决定如何将数据拆分为段。

数据源的数目是影响将在系统中创建的段数目的主要考虑因素之一。对 E3C 存储的大小没有任何限制。但是，对存储在段内的字和短语的数量 (依据其具体值) 有限制。

具体值是指与数据中的每个字 (以及 XML 文档中的每个开始和结束元素) 相关联的数值。核心段被限定为具体值 2 GB。如果几乎达到段的最大具体值容量，则会同时影响 Viewer 性能 (例如，执行搜索时) 和增量更新性能。通常情况下，每段的建议字数 (具体值) 最多为 500 MB (0.5 GB)。

为了计划每段中源的数目和大小，您必须分析数据，并标识字数。除了此数目之外，您还必须考虑用于增量数据加载的缓冲区。基于各种数据示例分析，建议使用以下分析方法来确定段。

当决定哪些数据进入某个段时，理想情况下，目标容量是 25% 到 50% 的具体值 (即大约 500 MB 至 1 GB 的具体值)。该数值不应过低，因为您可能会获得过多的段及其关联的开销。不过，段也不要太满，因为这会影响性能且太过于接近段限制。

下表提供了对于每种数据类型一般包含的具体值数目的粗略估计。下面的百分比基于段容量的 100%。

基于文件数的结果 (在可能的情况下，粒度大约为 1000 个文件) 为：

基于磁盘大小的结果 (在可能的情况下，粒度为 10MB) 为：

建议您根据两个表格执行数据计算，并为了安全起见，要么选择平均数值，要么选择最低数值。

考虑到具有不同索引定义的 XML 类型，根据 IEXML 类型推荐以下数据大小：

如果要混合数据类型，您可以使用文件的相对部分。例如，3 GB 的 XML 数据和 80 GB 的 PDF 数据。

如果数据大小超出表格限制，则数据很可能被分成多个段。例如，如果您有 20 GB 的 XML 和 500 GB 的 PDF，则您可能需要六个段。

通过 Servigistics InService，可以使用源之间预定义的链接从一个数据源链接到另一个数据源 (文档、图像等)。链接只能在同一个段内完成。其他段中源的链接无法在 Viewer 中运行。因此，链接的源必须在同一个段内加载。

数据类型也会对段的大小产生影响。例如，扫描的 PDF 文档对段大小的影响较小。这些文档在存储内有一个特性文件，但在这种情况下索引的具体值会非常少。

因此，您必须分析数据，以了解段中不同数据的类型。

段之间的搜索是通过业务逻辑层来实现的。在多个段中进行搜索会更浪费，因为搜索是分别在每个段中完成的，然后业务逻辑层会将各个结果统一并归类到一个搜索结果列表中。系统中存在的段越少，搜索的效率越高。

在定义分段时，考虑到其他考虑因素，应尽可能减少段数量。

共享文档是在多个集合中加载的文档。在共享模式下，无论段中包括此源的集合有多少，Servigistics InService 每段都仅存储共享文档的一个副本。

如果您拥有的集合包含多个共享文档，建议您将它们加载到单个段中以减少这些文档的副本数量。

从段创建离线包。这意味着完整段会被分发给离线系统及其所有关联集合。您应该将不应在同一个离线包中分发的集合拆分为不同的段。