Подход к сегментации определяет порядок сохранения данных в репозитории хранилища E3C. Хранилище E3C содержит следующие логические и физические уровни.

При добавлении источников данных в Servigistics InService необходимо решить, в какой набор эти источники будут загружаться. Уровень набора обычно представляет базовый блок, который поступает в виде пакета из создавшей системы. Поскольку уровень набора является логическим уровнем, он не оказывает воздействия на систему. Уровень сегмента - это физический уровень, на котором сохраняются все источники в хранилище E3C.

При публикации на серверах Viewer содержимое в хранилище E3C разбивается на сегменты для обеспечения приемлемой производительности поиска и минимизации воздействия операций ввода и вывода. Разработка плана сегментации существенно зависит от публикуемого созданного содержимого.

При разработке плана сегментации необходимо учитывать несколько факторов. В следующих разделах представлены подробные сведения об этих факторах, которые помогут в принятии решения о порядке разделения данных на сегменты.

Количество источников данных является одним из основных факторов, влияющих на количество сегментов, создаваемых в системе. Размер хранилища E3C не ограничен. Однако существует ограничение на количество слов и фраз (на основе вхождений), хранящихся в сегменте.

Вхождение - это число, связанное с каждым словом (и каждым открывающим и закрывающим элементом в XML-документе) в составе данных. Размер основного сегмента ограничен 2 ГБ вхождений. Приближение к максимальному количеству вхождений в сегменте влияет как на производительность сервера Viewer (например, при выполнении поиска), так и на производительность инкрементного обновления. Как правило, рекомендованное количество слов (вхождений) в сегменте не превышает 500 миллионов (0,5 ГБ).

Для планирования количества и размера источников на сегмент необходимо выполнить анализ данных и определить количество слов. Помимо этого количества, необходимо учитывать размер буфера для инкрементной загрузки данных. Исходя из анализа различных образцов данных, рекомендуется использовать следующий подход к анализу для определения параметров сегментов.

В идеале при определении количества данных в сегменте следует ориентироваться на вместимость от 25 до 50 % вхождений (то есть примерно от 500 МБ до 1 ГБ вхождений). Это число не должно быть слишком низким, чтобы избежать создания слишком большого количества сегментов и связанных с этим накладных расходов. Кроме того, не следует слишком сильно заполнять сегменты, так как это будет влиять на производительность и приводить к чрезмерному приближению к предельным характеристикам сегментов.

В следующих таблицах представлена грубая оценка количества вхождений, которое обычно содержится в каждом типе данных. Приведенные ниже процентные значения основаны на 100 % вместимости сегмента.

Результаты на основе количества файлов (с гранулярностью порядка 1000 файлов, насколько это возможно).

Результаты на основе размера диска (с гранулярностью 10 МБ, насколько это возможно).

Рекомендуется выполнить расчет данных на основе обеих таблиц и для большей верности выбрать среднее или меньшее из полученных значений.

С учетом типов XML с различными определениями индексирования рекомендуется использовать следующие размеры данных, в зависимости от типа IEXML.

В случае смешанных типов данных можно использовать относительную долю файлов. Например, 3 ГБ данных XML и 80 ГБ данных PDF.

Если размер данных превышает предел, указанный в таблице, то данные будут разбиты на несколько фрагментов. Например, при наличии 20 ГБ данных XML и 500 ГБ данных PDF потребуется примерно шесть сегментов.

Servigistics InService позволяет связывать один источник данных с другим (документ, изображение и т. д.) с помощью предварительно определенных ссылок между источниками. Ссылки можно использовать только в пределах одного сегмента. Ссылки на источники в других сегментах не будут работать на сервере Viewer. Поэтому источники, соединяемые ссылками, необходимо загружать в один и тот же сегмент.

Тип данных также влияет на размер сегмента. Например, сканированные документы PDF слабо влияют на размер сегмента. Внутри хранилища такие документы сопровождаются файлом свойств, но в этом случае будет индексироваться очень мало вхождений.

Поэтому необходимо проанализировать данные, чтобы понять, какие типы данных содержатся в сегменте.

Для поиска между сегментами используется уровень бизнес-логики. Поиск по нескольким сегментам более трудоемок, так как осуществляется отдельно в каждом сегменте с последующим объединением и сортировкой данных на уровне бизнес-логики для получения единого списка результатов поиска. Чем меньше сегментов в системе, тем больше будет эффективность такого поиска.

При определении сегментации используйте как можно меньшее количество сегментов с учетом остальных факторов.

Общие документы - это документы, которые загружены более чем в один набор. В общем режиме в Servigistics InService сохраняется только одна копия общего документа на сегмент, независимо от того, сколько наборов в сегменте включают этот источник.

При наличии наборов с большим количеством общих документов рекомендуется загружать эти наборы в один сегмент, чтобы уменьшить число копий таких документов.

Автономные пакеты создаются из сегмента. Это означает, что в автономную систему распределяются полные сегменты вместе со всеми связанными наборами. Необходимо разделить наборы, которые не должны распределяться в один и тот же автономный пакет, по разным сегментам.