来自Paul Robinson的16条建议很值得琢磨琢磨,这是关于在MOSS上配置企业级搜索时候遇到的问题,有几条还真让我恍然大悟。也解决了部分最近在项目中配置搜索功能时碰到的问题,简单的总结下,共勉之!如果有错误,望各位尽快提出,别在折腾我了...
1. 当我们的文档库启用审核功能时,是不能让普通用户查看或者搜索到没有发布和通过审核的文档,可是当我们的爬网账户权限足够大时,比如能够看到草稿状态的文稿,嘿嘿,你的秘密文稿就会被别人看个摘要,也就没有必要启用审核喽。我们因该给一个普通的读者身份给它,只能看到最后一次发布出去的文稿即可;
2. 搜索关键字中好像不支持通配符吧,比如AND,OR等。可是Nigel Bridport指出通过WebService,在高级搜索中配置SQL语句可以达到此效果,有待尝试;
3. 只有完全爬网才能重新对ASPX文件进行索引。所以了,小心了!一旦你从某个文档库或者列表中删除文档时,你会发现它们仍然出现在搜索结果当中,即使你做了一次增量爬网!所以Graham Tyler告诉我们如何堵住它们;
4. 测试结果推荐你在一个场中最多创建4个SSP,撑死20个(=5 farm)?,有待考证;
5. 测试结果推荐在所有的内容源索引中不要超过500000000个文档,也就是说通常建一个SSP对所有内容源爬网时!解决的办法是再建个SSP,负载均衡吧,因为每个SSP只能有一个索引服务器。对了,BDC的结果也计算在内;
6. 每个内容源的起始地址撑死500个,如果你的默认内容源不小心满了,额外的站点将没有他们的注册起始地址,最后你不得不手动的把它们添加到其他的内容源,或者更改下默认的内容源;
7. 留意了,关于索引和搜索数据库的大小信息最近将会在Technet上看到,期待中;
8. 索引服务器对每个WEB前端爬网并且启用的负载均衡时,每个WEB前端都会被命中,你可以指定索引服务器使用单独的WFE来改变这种状态。
9. 查询和索引角色可以跑在同一个服务器上,可是当你增加额外的查询服务器时,索引服务器就必须要单独生活了。举个例子:1Query+1Index = 1Server;2Query+1Index = 2Server;\o/
10. 适当的配置WFE和查询服务器在同一台服务器上可以提高查询性能,特别是在使用WFE自定义安全动作重复使用某一结果时;
11. 不同体系结构的角色可以混合在一起,比如说32bit的WFE和 62bit的索引服务器,但是最好不要在同一个角色中;
12. 索引服务器推荐使用64位的机器,但是很多第三方的IFilter目前并不支持64位的应用,比如Adobe的PDF,Lotus的什么什么等;
13. 对于索引服务器来说,可以下载和解析的最大文件大小默认为16M,当然了你可以去更改它以适应足够大的PPT文档,等等;
14. 允许进行干扰词查询选项默认是关闭的,你可以在核心搜索结果的部件中启用它,可是它会影响MOSS改良的搜索机制;
15. 搜索结果报告仅支持从客户端异步收集数据,也就是当用户使用MOSS的搜索结果页面时!因此,该报告将不能搜集使用API或者WebService查询的结果;
16. 显而易见,支持表单身份验证的外部站点是不支持爬网的;