 |
 |
产品 | 支持 | 搜索 | Microsoft指南 |
 |
 |
|
| 主页 | 活动&培训 | 订阅 | 中国微软 | 美国微软 | 关于站点 | | ||
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
  |
 Microsoft内幕新闻
操作microsoft.com
深入两个站点
解决方案/最佳案例
其他站点信息
内幕新闻档案
网站发展历程 |
|
|
|
 项目经理 Amy Benton，开发负责人 Larry Jordan，开发师 Michael Ruggiero 以及本地化项目经理 Gerald Heidenreich 是负责重写 microsoft.com 的搜索引擎后台程序的小组的部分人员。在过去几个月里，他们一直忙碌，希望能为搜索引擎用户提供以更好的搜索结果。 查看 microsoft.com 上 Search 的新版本，您可能发现不了太多变化，至少从外表来看是这样的。与其前任 Search 2.0 相比，新版本的用户界面只是有稍许简化（参见 Site Server 3.0 + ADO 2.1 = Search 的制胜组合）。但用户界面的背后却是一个模块化的搜索应用程序，它让查询效率变得更高，效能变得更强。 新加入的和经改进的功能包括：高级同义词匹配、扩展 Best Bets（最佳匹配）逻辑（返回最相关的一组预编辑推荐的搜索结果），以及最热门搜索智能缓存。另外，由于周密的安排和本地化人员的辛勤工作，Search 现已有 26 种语言版本提供，其中包括使用双向字符集的语言，如希伯来语。 分割攻克 从开发角度而言，代码的组件化（模块化）是第一位的。以前版本三个主要的搜索功能，即 Search Results（搜索结果）、Vocabulary（词表）和 Best Bets（最佳匹配），均与用户界面紧紧绑在一起。而 Search 2.5 由于把应用程序分割为不同模块，分别处理代码的执行和用户界面的表示，从而实现了代码与界面的分离。这是通过 XML 和 XSL 来实现的。（见图 1）。  图 1. 用户提交查询后，(1) 查询先被提交给解析器 (Parser) 进行词条分割和词表解析，(2) 找到项目的显示术语 (Display Term) 被传给 Best Bets，(3) 找到项目的首选术语 (Preferred Term) 和剩余项目被传给 Search Results，(4) 使用 XSL 编译生成并转换为 XML 格式的结果文档，(5) HTML 被提交到用户 Web 浏览器。单击左图可以放大。 为了更好地调收到搜索结果，Search 现在拥有一项称为“智能默认”的功能：即一种全部词条匹配 (All Words) 搜索，它使用同义词扩展捕捉到关键产品和技术的其他常见称呼和印刷名称，然后返回所有 Best Bets 和匹配全文，以及 Site Server 搜索结果。Search 新版本的另一目标是：优化性能，从而让后端增强设备不致陷入响应时间的泥潭。为了达到这一目标，我们的小组增强和扩展了缓存技术（见后面的详细讨论）。 搜索流程 这里列出了用户在搜索框中输入查询后进行的工作。首先，解析器组件试图在由终端用户派生出的同义词列表中查找匹配。然后它使用在站点词表中找到的首选术语生成一个扩展查询，并返回扩展查询的结果。 同义词扩展并不完全是一项新功能。如果在 Search 2.0 中查询“IE”，您将得到一个包含术语 Internet Explorer 的结果列表，同时还有一列 Best Bets。只要您只输入的是一个缩写词，Search 2.0 就会毫无问题地将其扩展为最合适的 Microsoft 术语。但您不能在一行中输入几个缩写词，还想得到类似的结果。 为了说明这一问题，让我们将几个缩写词组成一个字符串 — ASP IE WIN2K and ADSI — 然后通过 Search 2.0 进行查询。在这一旧版 Search 中，该查询的精确短语匹配 (Exact Phrase) 搜索返回的命中结果为 0，跟您预想的一样。All Words（全部词条匹配）搜索只返回一个结果：即包含全部四个缩写词的一篇文章。跟预计的一样，由于使用了多个缩写词，两种搜索都没有返回 Best Bets。 这种情况已经不会再发生了。新的 Microsoft Search 逻辑知道如何复述一个查询，打破查询字符串，并判断哪些词应组合在一起。这一场景的幕后，Search 实际上构造了一个 Boolean（布尔型）查询，基本意思是“查找包含所有这些术语（或这些术语的已知缩写词）的内容，返回每个术语的最佳匹配和首选术语建议”。例如，一个“IE5 Win2K”查询将扩展为类似下面的信息："("IE 5.0" or "Internet Explorer 5.0") and ("Win 2K" or "Windows 2000")"。这一转换过程发生在幕后，对用户来说是完全透明的。 新的 Search 解析器还能处理多词条搜索。如果一个查询包含短语“Internet Explorer”，解析器组件能够识别出这是一个短语，而不是两个分立的词条。类似的，对 Microsoft 的搜索日志的研究表明，用户在查询中经常将精确短语匹配与关键词查找结合在一起，并用引号表示精确短语。根据这一情况，Search 假定引号括起来的词语是指精确短语。由于布尔运算符在全部词条匹配的搜索中无关紧要，所以它们跟没有意义的干扰词（如 an、the、with、between 等）一起被删除。 顺便提一句，在确定哪些是空格，哪些是词条，哪些词条应连到一起时，决定使用什么样的逻辑是一个很大的挑战，尤其对亚洲语言而言，因为很多亚洲语言词间不使用空格。为了解决这一难题，我们的小组借助了 Microsoft 自然语言部门开发的一些组件。 Best Bets 功能 在整理和解析完查询后，解析器组件执行实际的词表解析，即搜索包含 Microsoft 术语的 XML 文件以确定有没有匹配。如果有匹配，它就将结果发送给 Best Bets 组件。 Best Bets 是与典型的 Microsoft 术语相关的编辑推荐搜索结果。例如，如果查询包含术语“Windows 2000”，Best Bets 将提供一个有关 Microsoft Windows 2000 的最热门链接列表。Search 小组的编辑人员已经收到一些对 Best Bets 的反馈，搜索用户对这种预先选择的搜索结果还是非常满意的，认为它的确很有用。 但 Search 的以前版本只有大约 20% 的时间能够提供 Best Bets，并且只有在精确匹配时才行。虽然还没得到确切数据，但小组估计新的词表逻辑将会把 Best Bets 的可用性大约提高到所有查询的 80%，并可返回多组结果。这也是重写词表和搜索组件得到的重大收获之一。 对于一般查询，同义词和 Best Bets 匹配的全部过程只需一两秒钟。所有数据都被积聚起来以后，查询马上被传给 Search Results 组件，在那里 Microsoft Site Server 3.0 扫描经过选择的编目，查找与经解析和词表匹配的搜索词条相匹配的内容。然后 Search Results 组件将基于这一内容列表的结果返回给用户。 速度制胜 microsoft.com 上的内容数量正不断增加 — 最近的计数已达到 400,000 页。所有这些内容每天都要被索引，以便 Search Results 组件能够提供最新的结果。同时，为了加快查询速度，Microsoft 系统部门在服务器上添加了足够多的内存（Microsoft 的大型编目服务器是 2 GB 内存），以让我们在查询时将编目完全都载入内存。您可以想象，这对性能改善有很大好处。 新的解析和词表匹配步骤增加了系统开销，使得尽可能地改善性能变地势在必行。因此重写的应用程序被完全分割开来。 在 Search 2.0 中，开发小组编写的 Best Bets 和 Related Terms 代码以 XML 格式返回结果，这是实现内容和代码分离很重要的第一步。在 Search 2.5 中我们继承光大了这一做法，实际上，所有数据使用 XSL 提供和翻译，通过 XML 格式提交。 但不幸的是，小组还没有找到让客户端 XML 在 Search 环境下有效运行的好方法。客户端翻译通常在返回的多数内容都是静态(比如在 microsoft.com 首页上）时才能很好运行。也就是说，服务器环境和查询程序体系结构中的效率有待提高。 我们找到了同时在两个地方实现加速的方法。一种方法是在服务器上使用“应用程序作用域”缓存。IIS 支持在服务器内存中载入自由线程 COM 组件。这一技术让 COM 组件的负载和破坏性达到最小。如果 COM 组件有与之相关的数据（如 XML 文件），这一技术还可以节省文件 I/O 和解析。为了利用这一服务，您必须使用一类很特定的对象。XML 使用所谓的自由线程文档对象模型 (DOM) 对象。与 COM 对象不同，自由线程对象任何人，任何时间都可以调用，而后者通常建立在与调用它的应用程序间的一对一关系中。 缓存 当您装载一个 XML 格式的文件时，XML 解析引擎首先必须遍历和创建所有树和节点，这是 XML 解析器中对性能影响比较大的地方。新的 Search 并不是在每次调用时才从硬盘加载及解析 XML 和 XSL 文件，相反，它只从硬盘上加载一次，然后就把它们存储在 Web 服务器的内存中。由于对所有只读 XML 和 XSL 文件都使用内存内数据库结构，Search 小组能够从服务器中挤榨出很多性能收益。这节省了文件 I/O 和节点解析的时间。 其它一些缓存技术也提高了系统效率。Search 2.0 中，一个特定的查询第一次执行时，应用程序先到硬盘上去查找结果。如果找到精确短语匹配，这些结果就被缓存起来，给定时间内再有查询就可以直接引向内存内数据。Search 2.5 采用了这一缓存逻辑的扩展版本，添加了一个让最热门搜索一整天都保留在内存中的机制。一个自动化程序负责收集搜索数据，然后将其汇总到聚集查询中，探明查询频率最高的一些搜索，并加上待缓存标记。 当这其中的一个查询完全给出时，一天中的第一批结果就从 Site Server 返回来，因此会有少许性能延迟。但这些结果马上会保存到服务器的缓存中，当天以后再有查询就可以从缓存结果中取出。每天晚上编录都要重建索引，前一天的搜索将过期，新的结果文件生成并输入到缓存中，每天都是如此。 所以，尽管 Search 2.5 和前任相比看起来没有多大改变，但外表下面确实变化很大。其结果就是用户发现他们能够更快找到要找的东西了。 © 2000 Microsoft Corporation。保留所有权利。使用规定。 最近更新日期： 2000 年 8 月 1 日
|
|
||||||||