Медленный поиск предметов с использованием расширенного свойства на Exchange
Проблема под рукой
Наше приложение C# для Windows использует EWS Managed API 2.0 для создания встреч в календаре пользователя. Каждое назначение имеет расширенное свойство с уникальной ценностью. Позже он находит назначение с помощью FindItems и ItemView,
Пользователи испытывают значительные задержки при первом поиске. Последующее время ответа вполне приемлемо.
("первый раз" здесь немного расплывчатый, потому что пользователи могут снова столкнуться с задержкой позже в тот же день)
// locate ID of appointment where extended property value equals 1234:
var filter = new Ews.SearchFilter.IsEqualTo(extendedPropertyDefinition, 1234);
var view = new ItemView(1, 0);
view.PropertySet = BasePropertySet.IdOnly;
var folder = new FolderId(WellKnownFolderName.Calendar, new Mailbox("..."));
var result = service.FindItems(folder, filter, view);
Удаленный сервер - это Exchange Server 2007 SP1.
Исследование
MSDN связывает некоторые комментарии с папками поиска и ограниченными представлениями, однако я не уверен, применимы ли они к нашей ситуации.
Акт применения представления к папке создает папки поиска в магазине. Когда папка поиска создается, она кэшируется для последующего использования. Если пользователь пытается создать папку поиска, которая уже существует, используется кэшированная папка поиска. Это позволяет в будущем просматривать довольно быстро. По умолчанию Exchange не кэширует все папки поиска бесконечно.
В частности, в отношении EWS:
Также важно учитывать тот факт, что при первом выполнении поискового запроса хранилища Exchange он будет выполняться очень медленно и, возможно, по истечении времени ожидания, тогда как при будущих запусках он будет отвечать без проблем. Это вызвано внутренними процессами, которые происходят на сервере Exchange при выполнении поиска в хранилище.
Они предлагают создавать папки поиска для неизменяемых, не динамических запросов, что в нашем случае не подходит, так как запрос различен для каждой встречи.
Если приложению требуется определенный запрос с фиксированным набором неизменяемых параметров, вы можете использовать папки поиска. [...] папки поиска полезны только для неизменяющихся, нединамических запросов.
По сути, нам нужно создать "индекс" - в терминах базы данных - свойства, обеспечивающий быстрый поиск по этому конкретному свойству независимо от времени и частоты.
Можно ли "проиндексировать" это свойство? Можно ли что-либо настроить на стороне клиента или на сервере, чтобы убрать эту начальную задержку?
4 ответа
Я столкнулся с такой же проблемой с интеграционным проектом. Хотелось бы, чтобы было хорошее решение...
Вы не можете создать индекс для свойства, которое еще не проиндексировано Exchange. Создание папки поиска для каждой нецелесообразно, если количество встреч растет достаточно высоко. Слишком много папок поиска в одной папке вызовет дальнейшие проблемы, поскольку все они должны будут обновляться при добавлении нового элемента в папку. Это мое понимание, по крайней мере. Кроме того, Exchange 2007 ограничен 11 папками динамического поиска на родительскую папку, поэтому он может быть еще менее жизнеспособным в зависимости от количества встреч и частоты их обращения. Использование существующих индексированных свойств может быть нежизнеспособным, так как они могут быть изменены пользователем за пределами вашего приложения. Если у вас есть какой-то способ убедиться, что созданные вами встречи могут быть доступны или изменены только из вашего приложения, то это уже другая история.
Таблица базы данных - хороший способ, но есть потенциальная загвоздка, которую некоторые люди не видят, пока не стало слишком поздно. ItemId является очевидным выбором для ссылки на ваше расширенное свойство, но ItemId НЕ является константой. Это расчетное свойство, основанное на нескольких других. Это может измениться, если элемент будет перемещен в другую папку, и это также может измениться при установке пакета обновления или если прошло достаточно времени, как я слышал. Я могу подтвердить, по крайней мере, первый. ItemId не подходит для длительного хранения, по крайней мере, без дополнительных проверок. Вы можете потенциально хранить ItemId и ваше расширенное свойство. Если привязка с использованием ItemId не удалась, вернитесь к расширенному поиску свойств. Если связывание прошло успешно, проверьте его по расширенному свойству в базе данных, чтобы убедиться, что оно совпадает. Обновите ItemId, если у вас есть элемент, если он не совпадает. Нужно ли вам работать с чем-либо, кроме объектов Встречи, например с ответами на собрания, предварительными уведомлениями и т. Д., Или это касается только Календаря?
Это не красиво, но это должен быть несколько разумный компромисс. У вас все еще может быть случайный поиск, но их может быть немного и далеко, если пользователь не решит перенести встречи в разные папки или планирует некоторые встречи заранее, и даже в этом случае синхронизация также должна помочь смягчить это., Просто будьте готовы заполнить эту таблицу, если появятся обновления до Exchange.
Конечно, если бы Microsoft добавила возможность индексировать дополнительные свойства или даже добавила пустое строковое поле или два к индексу в поиске Exchange для этой цели, у нас не было бы этой проблемы. Черт, индекс свойств GlobalObjectId для назначений и связанных объектов помог бы, но, увы... нет. Я не фанат перепрофилирования существующих проиндексированных полей. Не все из них применимы к встречам, а те, которые обычно требуются или редактируются пользователем. Если вы точно не знаете, что делаете, перепрофилирование этих полей может иметь непредвиденные последствия в будущем.
В любом случае, я не претендую на звание эксперта по всем вопросам EWS/Exchange, поэтому, возможно, есть лучший способ, чем этот. Возьми это с зерном соли.
Нет способа включить индексирование для вашей собственности. Я не знаю, какие свойства индексируются в Exchange 2007. Поскольку в вашем приложении, по-видимому, используются встречи, возможно, вы могли бы переназначить одно из других свойств, не связанных с встречей, для сохранения вашего уникального значения. Возможно, используйте свойство AssistantName через расширенное свойство (чтобы обойти ограничения, накладываемые схемой и службой EWS). Таким образом, большинство клиентов не будут использовать это свойство для элементов календаря.
Согласно этой теме, http://technet.microsoft.com/en-us/library/jj983804(v=exchg.150).aspx, это свойство индексируется (в 2013 году). Это свойство существует уже давно, поэтому его можно проиндексировать на 2007 год.
Эй, это длинный выстрел, и он никоим образом не оптимален, но, возможно, он подойдет для вашего сценария.
После прочтения этой ветки я вижу, что вы ищете не все элементы с расширенным свойством, а определенный элемент. Извините, я не уловил это в своем первом ответе. Я согласен, что папка поиска сама по себе не будет работать, поскольку вам придется обновлять фильтр каждый раз, когда вы искали свой элемент. Это, очевидно, будет довольно дорого (вероятно, хуже, чем ваш нынешний подход). У меня есть идея создать вид, который сортируется по вашему расширенному свойству. Я могу ошибаться, но я полагаю, что вы можете применить это представление к указанной выше папке поиска (обратите внимание, что я имею в виду явное создание папки поиска и просмотра и сохранение их в почтовом ящике, они могут быть скрыты или доступны для пользовательского интерфейса OL). под деревом папок поиска). Папка поиска будет фильтровать только встречи с расширенным свойством. Затем представление будет сортировать папку по значению свойства. В некотором чтении, которое я делал о внутренностях ESE, я видел некоторые комментарии, которые указывают, что сортировка по свойству заставит Exchange создать индекс на ESE (хотелось бы найти его сейчас). Раздел, посвященный индексам B-деревьев ESE, похоже, подтверждает это: = & ен са = Х & е = QQ7HUtgggvTbBdjcgfAP & вед =0CFwQ6AEwBQ#v= OnePage& д = как%20to%20create%20exchange%20ese%20indexes& F = ложь
Затем вам нужно будет использовать тот же подход, который вы использовали выше в папке поиска, чтобы найти конкретный элемент, соответствующий вашим критериям. Конечно, одной из проблем является проблема, связанная с тем, что Exchange отбрасывает ваш индекс (что, вероятно, и происходит в вашем текущем подходе). Возможно, вы могли бы периодически программно касаться папки поиска, чтобы этого не произошло? Эта ссылка также полезна для понимания влияния производительности на создание папки поиска / просмотра: http://technet.microsoft.com/en-us/library/cc535025%28EXCHG.80%29.aspx
Если вы найдете хорошее решение (или это работает), мне очень интересно услышать об этом (и я уверен, что многие другие тоже). Ой радость от развития Exchange:-)
Создание папки поиска с расширенным свойством в качестве критерия - это путь. Вы заплатите цену, пока папка поиска создается изначально, но после создания индекса, пока папка существует и работает, она будет автоматически обновляться Exchange. Мы используем эту технику довольно успешно, чтобы найти пресловутую "иголку в стоге сена".
http://msdn.microsoft.com/EN-US/library/dd633687(v=exchg.80).aspx