我为斯堪的纳维亚黄页工作。该公司正在考虑将其定制搜索技术转移到 FAST ESP。
像所有安装相对较少的大型昂贵系统一样,很难获得有关系统优势和劣势的反馈。
有没有 FAST ESP 经验的 stackoverflowers 想要分享?
我为斯堪的纳维亚黄页工作。该公司正在考虑将其定制搜索技术转移到 FAST ESP。
像所有安装相对较少的大型昂贵系统一样,很难获得有关系统优势和劣势的反馈。
有没有 FAST ESP 经验的 stackoverflowers 想要分享?
:) 我是一名搜索架构师,从 1997 年作为 Lycos 软件工程师开始就一直在开发和集成搜索引擎技术。
我们使用 FAST ESP 作为支持http://thomasnet.com的搜索引擎。自 2003 年以来,我一直在使用 ESP(当时称为 FDS 3.2)。
FAST ESP 非常灵活,可以处理多种文档类型(html、pdf、word 等)的索引。它有一个非常强大的 Web 文档爬虫,您可以使用它们的中间 FastXML 格式将自定义文档格式加载到系统中或使用它们的 Content API。
该引擎中我最喜欢的部分之一是它的文档处理管道,它允许您使用数十个开箱即用的处理插件以及使用 Python API 来编写您自己的自定义文档处理阶段。我们编写的自定义阶段的一个示例是查看网站 URL 并尝试识别它属于哪个公司,以便可以将其他元数据附加到 Web 文档。
它有一个非常强大的编程/集成 SDK,支持多种流行语言(C++/C#/Java),用于添加内容和执行查询以及获取系统状态和管理集群服务。
ESP 有一种称为 FAST Query Language (FQL) 的查询语言,它非常健壮,允许您进行基本的布尔搜索(AND、OR、NOT)以及短语和术语邻近搜索。除此之外,它还有一种称为“范围搜索”的功能,可用于搜索文档元数据 (XML),其格式因文档而异。
在性能方面,它的扩展相当线性。如果你对它进行基准测试以确定它在一台机器上的性能,如果你添加另一台机器,它通常可以使性能翻倍。您可以在一台机器(仅推荐用于开发)或多台机器(用于生产)上运行系统。它是容错的(如果您的负载平衡索引之一脱机,它仍然可以提供一些结果)并且它具有完整的故障转移支持(一台或多台关键机器可能会死机或脱机以进行维护,系统将继续运行正常运行)
所以,它非常强大。现在的文档非常好。所以,你问,有什么缺点?
好吧,如果您需要使其可搜索的数据具有经常更改的格式,那可能会很痛苦。ESP 有一个叫做“索引配置文件”的东西,它基本上是一个配置文件,它用来确定哪些文档字段是重要的并且应该用于索引。馈入 ESP 的所有内容都是“文档”,即使您将数据库表行加载到其中。每个文档都有几个字段,典型字段是:标题、正文、关键字、标题、文档向量、处理时间等。您可以根据需要指定任意数量的自定义字段。
如果您的内容基本上保持相同的格式(如 Web 文档),那不是什么大问题。但是,如果您必须对应该索引哪些字段以及应该如何处理它们进行重大更改,您可能需要编辑索引配置文件。对索引配置文件的一些更改是“热更新”,这意味着您可以进行更改而不会中断服务。但是,一些较大的更改是“冷更新”,它需要在更改生效之前重新提供完整的数据和索引。根据数据集的大小和集群中的机器数量,此操作可能需要数小时或数天。冷更新很难安排,除非您有足够的现金购买额外的硬件,而您的生产系统正在执行冷更新并重新加载数据。
对于您的情况,我怀疑您的数据格式会经常更改。如果您需要对其进行细微调整,您可以将额外的元数据添加到范围字段,以回避进行任何完整数据重新加载的需要。
您可能会遇到的大部分麻烦是使用该产品的初始学习曲线。一旦你得到一个开发集群(或节点)做你想做的事,并且如果不需要经常对索引字段配置进行重大更改,它是一个非常稳定和可靠的搜索引擎。对于您的应用程序来说,这听起来很合适,对于较小的公司或初创公司来说,有一些开源选项,如果您不需要那么多的性能或耐用性,那么这些选项并不那么昂贵。
我希望你觉得这个评估有帮助。:)
此致 Michael McIntosh 高级搜索架构师@TnR Global
2008-2009 年间,我在俄罗斯黄页 (yell.ru) 担任“搜索引擎工程师”的工作。我的主要职责是使用 FAST ESP 系统。我为我们的特定数据处理编写和维护自定义文档处理器(自定义阶段),用于数据推送管道的一些“胶水”代码。关于 FAST ESP。我对此有一种“混合”的感觉。这里有一些缺点。
这是一种昂贵的产品。除了一次性初始付款外,您还必须支付年度(和值得注意的)许可费,否则您的服务器将停止工作。我们的错误是获取(相对)低成本许可证,该许可证具有非常有限的“每秒最大请求”速率(最大每秒查询 10 个)。虽然我们多次被告知这只是“业务限制”,但实际上这是服务器峰值吞吐量的硬技术限制。我们的性能被这个峰值限制破坏了,我们切换回临时“评估”许可证(令人惊讶!)没有任何性能限制(只是一个时间段限制)。
文档很好,但技术细节不是很深入。仅仅通过阅读文档是不可能做一些真正棘手的事情的。细节不在这里。一旦我们被告知我们需要联系他们的“解决方案部门”(并购买“解决方案”),因为这并不意味着由客户完成。
有些部分出奇地棘手和错误。一些例子:将自定义词典放在非英语符号的几个问题中。如果我们加载一堆具有自定义提升值的短语,有时系统会变得缓慢且不负责任。
到处都有一些奇怪的技术限制。例如 - 我们只能为可搜索字段分配 8 个不同的提升值。
总的来说,我们很难满足用户的需求,将 FAST ESP 作为我们网站的基础搜索引擎。最后,系统被另一个(开源)解决方案取代,我被解雇了 ;-) 故事结束。
@Michael McIntosh:为避免冷更新,您可以将通用字段添加到索引中。例如,您添加 5 个通用整数、5 个字符串和 5 个日期。当您需要突然引入一个新整数时,您可以使用已有的“填充”,例如 igeneric1。
一段时间后,您可能想要进行冷更新,然后合并这些字段并为其命名等。
FAST ESP 技术是可靠的,但您需要记住,它实际上是一个搜索平台(因此是“ESP”),而不是开箱即用的搜索体验。结果的质量与索引的质量直接相关,这意味着您确实需要针对您的内容调整文档处理管道和索引配置文件。
对此没有硬性规定;你真的需要了解平台和你的内容。这确实需要时间和大量的反复试验。此外,它资源匮乏,因此您不能吝啬硬件。如果你有时间和资源把它做好,它会很好用,但半途而废不会比开箱即用的东西甚至 Lucene 更好(甚至可能更糟)。
只是评论一个关于 filetraverser 没有接受 ACL 更改的先前答案(我没有足够的声誉直接回复答案):
您可以通过启用 aclplugin 让文件遍历器获取文件权限更改
filetraverser -c <collection> -r <dir> -M -E -J $FASTSEARCH/etc/filetraverser/aclplugin.xml
我们发现的唯一烦人的事情是你一次只能使用一个插件,所以你不能同时使用原生的 acl 和lazy 插件。我们通过创建自定义插件解决了这个问题,尽管它只是调用了它们。
我已经支持 FAST ESP 好几年了。总体4/5。
迄今为止,我的经验是 FAST ESP 平台坚如磐石,但各种连接器都有一些怪癖。
Lotus Notes 连接器特别差,当索引超过 100,000 个文档时会定期中断。
其他怪癖可能相当大,例如文件遍历器在文件的 NTFS 权限更新时不反映文档更新。这意味着每个人都可以看到他们不应该看到的文档——糟糕的安全问题。
我在这里附和其他人的观点,FAST ESP 非常好,但它肯定不是一个“开箱即用”的解决方案。预计将花费 3 到 12 个月的时间来实施——但您将获得一个非常强大的引擎。
我们已经实施了大量的 FAST ESP 应用程序,并且在所有情况下 ESP 都被证明是一个非常稳定的高性能平台,只要您预先投入相对较高的实施成本。关于黄页问题 - 我们使用 ESP 实施和管理美国最大的在线目录站点,它处理巨大的 QPS(每秒查询数)。正如其他人所提到的,关键的替代技术——例如谷歌、Solr/Lucene 也非常有能力,您的选择实际上取决于技术/用户要求和预算。
I worked in projects for GE Search group for about 4 years, they use FAST ESP and I found that it is very flexible, powerful and multilingual document handling. It allowed me to search into documents with at least 20 different language inside included Japanese, Chinese and Korean with Latino languages and Greek. Also I was able to index documents from Databases, Crawlers (XML based), PDF, Office, etc. all mixed in a single search using different collection of data mixed by search engine. Also allowed me to crate different pipelines to approach different content ingestion.
我正在为一些公司 Intranet 站点(大公司)实施 FAST ESP。我在搜索技术方面做了一些工作(90 年代后期的 Verity)。
幸运的是,在我们真正开始之前,我参加了 FAST ESP 开发人员课程。这些课程真的很简单,如果你学得很快,你可能只做在线课程。这些对我来说最大的好处是在项目开始之前就提前了解了 API。在快速浏览并使用 API 进行了一些编程实验室之后,我意识到我需要编写相当多的代码。
我对 API 很失望。不到一年前,MS 刚刚购买了 FAST ESP,因此希望他们能在清理 .NET API 方面获得一些帮助。.NET API 就像有人单击一个按钮并制作了一个 COM 包装器来与本机 Java servlet 交互一样。API 命名约定和方法很容易让您熟悉(只要您记住所有 FAST ESP 集合/数组都是从 1 开始的,而不是从 0 开始的)。但是,我相信他们可以在这里做很多工作。Java API 看起来很像我见过和使用过的所有其他 Java API。命名约定和结构看起来像标准的 Java API,可能是因为 FAST ESP 是一个基于 Java 的搜索引擎,其开发人员是 Java 软件工程师,而不是 .NET 软件工程师。
起初,由于我使用的是 ASP.NET,因此我开发了一组模仿 MS SharePoint Web 控件功能的 Web 控件。在课堂和所有 ASP.NET 示例中,所有内容都是内联 ASP.NET 编码,没有或很少有“代码隐藏”编码。雅虎!Developer Network 有一些很好的设计模式用于设计搜索界面、结果、寻呼机等。
总的来说,到目前为止,它运作良好。我们仍处于开发阶段,将在接下来的几周内开始对我们的网站进行 beta 测试。FQL(快速查询语言)有点过于复杂——我们的用户可能会抱怨这种语言对他们来说不够“类似于谷歌”。如果您搜索一些 FQL pdf 文件,您将能够预览该语言。您也可以只使用简单的搜索(所有术语、任何术语等)。
如果您想知道任何具体的信息,请询问,我会尽力获取信息。我们在 VM 环境中使用 FAST ESP - 他们说不支持,但它工作正常并且基准测试结果对我们来说还可以。
FAST ESP 很好。至少与 Google Search Appliance 相比。但是,选择哪个企业搜索引擎完全取决于要求。
@anand,您可以使用 FAST ESP .NET API。安装中有 PDF 文档、示例代码和 API 参考资料。
关于编写高级文档处理插件的任何材料?例如,从内容中提取自定义信息?我听说它是用 Python 完成的,但似乎没有材料可以学习如何实际做到这一点。
@anand:您可以在 .NET Content API 之间进行选择,也可以通过 HTTP/XML 进行所有操作,并根据需要设置 XML 样式。
除了 FAST ESP,您只有两个其他可能的选择,Autonomy 的 IDOL 平台 (AFAIK) 和 Apache Solr。