在Exchange上使用扩展属性缓慢搜索项目 [英] Slow search for items using extended property on Exchange
问题描述
眼前的问题
我们的C#Windows应用程序使用 EWS托管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，具体关于EWS :
了解以下事实也很重要: 发出Exchange存储搜索查询，它将运行非常缓慢，并且 可能会超时，而在将来运行时，它将响应而无需 问题.这是由Exchange上发生的后端进程引起的 服务器在执行商店搜索时.
他们建议为不变的，非动态的查询创建搜索文件夹，这在我们的情况下似乎不合适，因为每个约会的查询都不同.
如果应用程序需要特定的查询，且该查询具有一组固定的 不变的参数，您可以使用搜索文件夹. [...] 搜索 文件夹仅对不变的，非动态的查询有用.
本质上，我们需要在属性上创建一个索引"(以数据库术语)，以确保对该特定属性的所有搜索都是快速的，无论时间或频率如何./p>
是否可以为该属性编制索引"?可以在客户端或服务器端进行任何配置以消除此初始延迟吗?
我在集成项目中遇到了同样的问题.我希望有一个好的解决方案...
您不能为Exchange尚未建立索引的属性创建索引.如果约会数量增加到足够高，则无法为每个文件夹创建搜索文件夹.单个文件夹上的搜索文件夹过多会导致更多问题，因为将新项目添加到该文件夹时，都需要更新它们.至少这是我的理解.此外，Exchange 2007每个父文件夹最多只能有11个动态搜索文件夹，因此根据约会的数量和访问频率，约会的可行性甚至更低.使用现有的索引属性可能不可行，因为用户可能会在应用程序外部对其进行更改.如果您有某种方法可以确保只能从您的应用程序访问或更改您创建的约会，那么情况就不同了.
使用数据库表是个不错的方法，但是有一个潜在的障碍，有些人直到为时已晚才看不到. ItemId是链接到扩展属性的明显选择，但ItemId不是常数.这是一个基于其他几个属性的计算得出的属性.如果将项目移动到另一个文件夹，它可能会更改，并且可能会随着Service Pack的安装或经过足够的时间而更改，或者我听说过.我至少可以确认第一个. ItemId对于长期存储不可行，至少在没有其他检查的情况下也是如此.您可能会存储ItemId和您的扩展属性.如果使用ItemId的绑定失败，则退回到扩展属性搜索.如果绑定成功，则将其与数据库中的扩展属性进行检查，以确保其匹配.如果没有匹配项，则更新ItemId.您是否需要使用约会对象以外的任何东西，例如会议响应，转发通知等，还是只与日历有关?
这不是很漂亮，但这应该是一个合理的折衷方案.您可能仍会偶尔进行搜索，但只要用户不决定将约会移动到其他文件夹或提前计划一些约会，它们之间的距离就应该很少，即使如此，同步也应有助于缓解这种情况. .如果要升级到Exchange，只需准备重新填充该表即可.
当然，如果为此目的，Microsoft要么添加了对其他属性进行索引的功能，甚至为Exchange搜索中的索引添加了一个或两个空白字符串字段，我们就不会遇到这个问题.哎呀，在约会和关联对象上的GlobalObjectId属性上的索引会有所帮助，但可惜...没有.我不喜欢重新利用现有的索引字段.并非所有这些都适用于约会，而这些约会往往是用户所必需或可编辑的.除非您确切地知道自己在做什么，否则重新利用这些字段可能会在将来产生无法预料的后果.
无论如何，我并不声称自己在EWS/Exchange的所有事务上都是专家，所以也许有比这更好的方法.撒一粒盐.
Problem at hand
Our C# Windows application uses EWS Managed API 2.0 to create appointments in a user's calendar. Each appointment has an extended property with a unique value. It later locates an appointment using FindItems and an ItemView.
Users experience significant delays the first time this search is performed. Subsequent response times are entirely acceptable.
("first time" is a little vague here, because users may experience the delay again later in the day)
// 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);
Remote server is an Exchange Server 2007 SP1.
Research
MSDN ties some comments to search folders and restricted views, however I am uncertain if these apply to our situation.
The act of applying a view to a folder creates search folders in the store. When a search folder is created, it is cached for later use. If a user tries to create a search folder which already exists, the cached search folder is used. This allows future viewings to be fairly quick. By default, Exchange does not cache all search folders indefinitely.
Specifically with regard to EWS:
It is also important to be aware of the fact that the first time an Exchange store search query is issued, it will run very slowly and possibly time out, whereas on future runs it will respond without issue. This is caused by back-end processes that occur on the Exchange server when a store search is performed.
They suggest creating search folders for non-changing, non-dynamic queries, which doesn't seem fitting in our case, since the query is different for each appointment.
If an application requires a specific query that has a fixed set of nonchanging parameters, you can use search folders. [...] search folders are useful only for nonchanging, nondynamic queries.
What we need is in essence to create an "index" - in database terms - on the property, ensuring that all searches on this specific property are fast, no matter the time or frequency.
Is it possible to "index" this property? Can anything be configured either client or server side to remove this initial delay?
I've hit the same sort of problem with an integration project. I wish there was a good solution...
You cannot create an index for a property that is not already indexed by Exchange. Creating a search folder for each is not viable if the number of Appointments grows high enough. Too many search folders on a single folder will cause further problems as they will all need to be updated when a new item is added to the folder. That's my understanding, at least. Also, Exchange 2007 is limited to 11 dynamic search folders per parent folder, so it may be even less viable depending on the number of appointments and how often they're accessed. Using existing indexed properties may not be viable as these can likely be changed by the user outside of your application. If you have some way of ensuring that the Appointments you create can only be accessed or altered from your application, then that's a different story.
The database table is a good way to go, but there's a potential snag that some people don't see until it's too late. ItemId is the obvious choice to link to your extended property, but ItemId is NOT constant. It's a calculated property based on several others. It can change if the item is moved to another folder, and it may also change with the installation of a service pack or given enough time passing, or so I've heard. I can confirm at the least the first one. ItemId is not viable for long-term storage, at least not without additional checks. You could potentially store ItemId and your extended property. If a bind using the ItemId fails, fall back to the extended property search. If the bind is successful, then check it against the extended property in the database to be certain that it matches. Update the ItemId once you have the item if it doesn't match up. Do you need to work with anything beyond the Appointment objects, ie, meeting responses, forward notifications, etc, or is this concerned only with the Calendar?
It isn't pretty, but it should be a somewhat reasonable compromise. You may still have the occasional search, but they should be few and far between as long as the user doesn't decide to move Appointments to different folders or plans some Appointments way in advance, and even then the sync should help mitigate that as well. Just be prepared to repopulate that table if there are upgrades to Exchange.
Of course, if Microsoft had either added the capability to index additional properties or even added a blank string field or two to the index in Exchange Search for this very purpose, we wouldn't have this problem. Heck, an index on the GlobalObjectId properties on Appointments and associated objects would help, but alas...no. I'm not a fan of repurposing existing indexed fields. Not all of them are applicable to Appointments and the ones that are tend to be either required or editable by the user. Unless you know precisely what you're doing, repurposing those fields could potentially have unforeseen consequences down the road.
In any case, I don't claim to be an expert in all matters of EWS/Exchange, so maybe there is a better way than this. Take it with a grain of salt.
这篇关于在Exchange上使用扩展属性缓慢搜索项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
