我为斯堪的纳维亚黄页工作.该公司正在考虑将其定制的搜索技术转移到FAST ESP.
像所有安装相对较少的大型昂贵系统一样,很难获得有关系统优缺点的反馈.
有没有拥有FAST ESP经验并希望分享的stackoverflowers?
:)我是一名搜索架构师,自1997年起担任Lycos软件工程师以来,一直在开发和集成搜索引擎技术.
我们使用FAST ESP作为http://thomasnet.com的搜索引擎.我从2003年开始使用ESP(当时称为FDS 3.2).
FAST ESP非常灵活,可以处理许多文档类型(html,pdf,word等)的索引.它具有非常强大的Web文档爬虫,您可以使用其中间FastXML格式将自定义文档格式加载到系统中或使用其内容API.
我最喜欢的引擎部分之一是它的文档处理管道,它允许您使用几十个开箱即用的处理插件,以及使用Python API编写您自己的自定义文档处理阶段.我们编写的自定义阶段的一个示例是查看网站URL并尝试识别它所属的公司,以便可以将其他元数据附加到Web文档.
它有一个非常强大的编程/集成SDK,有几种流行的语言(C++/C#/ Java),用于添加内容和执行查询以及获取系统状态和管理集群服务.
ESP有一种称为FAST查询语言(FQL)的查询语言,它非常强大,允许您进行基本的布尔搜索(AND,OR,NOT)以及短语和术语邻近搜索.除此之外,它还具有称为"范围搜索"的功能,可用于搜索文档元数据(XML),其格式可能因文档而异.
在性能方面,它相当线性地扩展.如果您对其进行基准测试以确定它在一台计算机上的执行情况,那么如果您添加另一台计 您可以在一台机器上运行系统(仅建议用于开发),或者许多(用于生产).它是容错的(如果你的一个负载平衡索引脱机,它仍可以提供一些结果)并且它具有完全的故障转移支持(一个或多个关键机器可能会死亡或被脱机进行维护,系统将继续正常运作)
所以,它非常强大.现在的文档非常好.所以,你问,有什么缺点?
好吧,如果你需要搜索的数据有一个经常变化的格式,那可能会很痛苦.ESP有一种称为"索引配置文件"的东西,它基本上是一个配置文件,用于确定哪些文档字段很重要,应该用于索引.输入ESP的所有内容都是"文档",即使您的加载数据库表行也是如此.每个文档都有几个字段,典型字段为:标题,正文,关键字,标题,文档向量,处理时间等.您可以根据需要指定任意数量的自定义字段.
如果您的内容大致保持相同的格式(如Web文档),那么这不是一个大问题.但是,如果您必须对哪些字段应编入索引以及如何处理它们进行重大更改,则可能需要编辑索引配置文件.对索引配置文件的一些更改是"热更新",这意味着您可以进行更改而不是中断服务.但是,一些更大的变化是"冷更新",它需要在更改生效之前重新输入完整的数据并进行索引.根据数据集的大小以及群集中的计算机数量,此操作可能需要数小时或数天.除了你的生产系统执行冷更新和重新加载数据时你可以带上额外硬件的额外硬件时,冷更新很难安排.
对于您的情况,我怀疑您的数据格式会经常变化.如果您需要对其进行微调,可以向范围字段添加其他元数据,以便对执行任何完整数据重新加载的需求进行支持.
您可能遇到的大多数麻烦都是使用该产品的初始学习曲线.一旦你得到一个开发集群(或节点)做你想要的,如果不必经常对索引字段配置进行重大更改,它是一个非常非常稳定和可靠的搜索引擎.对于您的应用程序来说,这听起来很合适,对于小型公司或初创公司而言,如果您不需要那么多的性能或耐用性,那么前面的开源选项并不昂贵.
我希望你觉得这个评估很有帮助.:)
此致,Michael McIntosh高级搜索建筑师@TnR Global