在 Exchange 上使用扩展属性缓慢搜索项目

Question

手头的问题

我们的 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 ties some comments to search folders and restricted views，但是我不确定这些是否适用于我们的情况。

将视图应用于文件夹的行为会在 商店。创建搜索文件夹时，会对其进行缓存以供以后使用。如果 用户尝试创建一个已经存在的搜索文件夹， 使用缓存的搜索文件夹。这使得未来的观看是公平的 快的。默认情况下，Exchange 不会缓存所有搜索文件夹 无限期。

具体with regard to EWS:

同样重要的是要意识到第一次 发出 Exchange 存储搜索查询，它将运行非常缓慢并且 可能超时，而在未来的运行中它会响应 问题。这是由 Exchange 上发生的后端进程引起的 执行商店搜索时的服务器。

他们建议为不变的、非动态的查询创建搜索文件夹，这似乎不适合我们的案例，因为每个约会的查询都不同。

如果应用程序需要具有固定集合的特定查询 不变的参数，您可以使用搜索文件夹。 [...] 搜索 文件夹仅对不变的、非动态的查询有用。

本质上，我们需要的是在属性上创建一个“索引”（用数据库术语来说），确保在这个特定属性上的所有搜索都是快速的，无论时间或频率如何。

是否可以“索引”此属性？可以对客户端或服务器端进行任何配置以消除此初始延迟吗？

Answer 1

在阅读了这个帖子之后，我发现您不是在寻找具有扩展属性的所有项目，而是一个特定项目。抱歉，我在第一次回复中没有注意到这一点。我同意单独的搜索文件夹对您不起作用，因为您每次搜索项目时都需要更新过滤器。这显然会非常昂贵（可能比您当前的方法更糟）。我的一个想法是创建一个按您的扩展属性排序的视图。我可能是错的，但我相信您可以将此视图应用于上面的搜索文件夹（注意我说的是显式创建搜索文件夹和视图并将它们存储在邮箱中，它们可以隐藏或暴露给 OL UI在搜索文件夹树下）。搜索文件夹将仅过滤具有您的扩展属性的约会。然后视图将按属性值对文件夹进行排序。在我对 ESE 内部进行的一些阅读中，我看到一些评论表明按属性排序将导致 Exchange 在 ESE 上创建索引（希望我现在能找到它）。 ESE B-Tree Indexes 部分似乎证实了这一点：http://books.google.com/books?id=12VMxwe3OMwC&pg=PA73&lpg=PA73&dq=how+to+create+exchange+ese+indexes&source=bl&ots=D5hJyJIEo5&sig=ppZ6RFJh3PnrzeePRWHFJOwXgeU&hl=en&sa=X&ei=QQ7HUtgggvTbBdjcgfAP&ved=0CFwQ6AEwBQ#v=onepage&q=how%20to%20create%20exchange%20ese%20indexes&f=false

然后，您必须使用上面在搜索文件夹中使用的相同方法来查找符合您的条件的特定项目。一个挑战当然是 Exchange 丢弃您的索引的问题（这可能是您当前方法中正在发生的事情）。也许您可以定期以编程方式触摸搜索文件夹以确保不会发生这种情况？此链接也有助于了解创建搜索文件夹/视图对性能的影响：http://technet.microsoft.com/en-us/library/cc535025%28EXCHG.80%29.aspx

如果您找到了一个好的解决方案（或者这个解决方案有效），我很想知道它（我相信很多其他人也是如此）。哦，交流发展的乐趣:-)

Answer 2

我在集成项目中遇到了同样的问题。我希望有一个好的解决方案...

您不能为 Exchange 尚未索引的属性创建索引。如果约会的数量增长到足够高，则为每个人创建一个搜索文件夹是不可行的。单个文件夹上的搜索文件夹过多会导致进一步的问题，因为在将新项目添加到文件夹时，它们都需要更新。这是我的理解，至少。此外，Exchange 2007 仅限于每个父文件夹 11 个动态搜索文件夹，因此根据约会的数量和访问频率，它可能更不可行。使用现有的索引属性可能不可行，因为这些属性可能会被应用程序之外的用户更改。如果您有某种方法可以确保您创建的约会只能从您的应用程序中访问或更改，那就另当别论了。

数据库表是一个不错的选择，但有一个潜在的障碍，有些人直到为时已晚才看到。 ItemId 是链接到扩展属性的明显选择，但 ItemId 不是恒定的。它是基于其他几个计算得出的属性。如果将项目移动到另一个文件夹，它可能会改变，它也可能会随着服务包的安装或经过足够的时间而改变，或者我听说过。我至少可以确认第一个。 ItemId 对于长期存储是不可行的，至少在没有额外检查的情况下是不可行的。您可能会存储 ItemId 和您的扩展属性。如果使用 ItemId 的绑定失败，则回退到扩展属性搜索。如果绑定成功，则根据数据库中的扩展属性检查它以确保它匹配。如果项目不匹配，请在拥有项目后更新 ItemId。您是否需要处理 Appointment 对象之外的任何内容，即会议响应、转发通知等，还是仅与日历有关？

它并不漂亮，但它应该是一个合理的妥协。您可能仍然偶尔进行搜索，但只要用户不决定将约会移动到不同的文件夹或提前计划一些约会，它们应该很少而且相距甚远，即使这样，同步也应该有助于缓解这种情况.如果 Exchange 有升级，请准备好重新填充该表。

当然，如果 Microsoft 为此添加了对其他属性进行索引的功能，或者甚至在 Exchange 搜索的索引中添加了一个或两个空白字符串字段，我们就不会有这个问题。哎呀，约会和相关对象上的 GlobalObjectId 属性的索引会有所帮助，但是唉......不。我不喜欢重新利用现有的索引字段。并非所有这些都适用于约会以及用户往往需要或可编辑的约会。除非您确切知道自己在做什么，否则重新利用这些字段可能会在未来产生无法预料的后果。

无论如何，我并不声称自己是 EWS/Exchange 的所有方面的专家，所以也许有比这更好的方法。带上一粒盐。

Answer 3

以您的扩展属性为条件创建一个搜索文件夹是可行的方法。您将在最初构建搜索文件夹时付出代价，但在创建索引后，只要该文件夹存在并且正在运行，它就会由 Exchange 自动更新。我们使用这种技术非常成功地找到了众所周知的“大海捞针”。

http://msdn.microsoft.com/EN-US/library/dd633687(v=exchg.80).aspx

Answer 4

没有办法为您的资源启用索引。我不熟悉哪些属性在 Exchange 2007 中被索引。由于您的应用程序似乎正在使用约会，也许您可​​以重新利用其他非约会属性之一来存储您的唯一值。也许通过扩展属性使用 AssistantName 属性（以解决 EWS 架构和服务施加的限制）。这样，大多数客户端将不会将该属性用于日历项目。

根据本主题http://technet.microsoft.com/en-us/library/jj983804(v=exchg.150).aspx，该属性已编入索引（2013 年）。该属性已存在很长时间，因此可能会在 2007 年被编入索引。

嘿，这是一个长镜头，无论如何都不是最佳选择，但也许它可能适用于您的场景。