我为斯堪的纳维亚黄页工作。该公司正在考虑将其定制的搜索技术转移到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文档。
它具有使用几种流行语言(C++/C#/Java)的非常强大的编程/集成SDK，用于添加内容和执行查询以及获取系统状态和管理集群服务。
ESP具有一种称为FAST Query Language(FQL)的查询语言，它非常强大，可以让您进行基本的 bool 搜索(AND，OR，NOT)以及短语和术语接近搜索。除此之外，它还有一个称为“范围搜索”的内容，可用于搜索文档元数据(XML)，该文档元数据的格式可能随文档的不同而不同。
就性能而言，它相当线性地扩展。如果对它进行基准测试以确定它在一台计算机上的性能，那么如果添加另一台计算机，通常可以使性能提高一倍。您可以在一台计算机(仅建议用于开发)上运行该系统，也可以在一台计算机(用于生产)上运行该系统。它具有容错能力(如果您的负载平衡索引之一脱机，它仍然可以提供一些结果)，并且具有完整的故障转移支持(一台或多台关键计算机可能会死亡或脱机进行维护，并且系统将继续运行)正常运行)
因此，其功能非常强大。如今的文档非常好。所以，你问，有什么弊端？
好吧，如果您需要使其可搜索的数据具有经常更改的格式，则可能会很麻烦。 ESP有一个称为“索引配置文件”的东西，它基本上是一个配置文件，用于确定重要的文档字段并应将其用于索引。即使您将数据库表行加载到ESP中，馈入ESP的所有内容都是“文档”。每个文档都有几个字段，典型字段为:标题，正文，关键字，标题，文档向量，处理时间等。您可以根据需要指定任意多个自定义字段。
如果您的内容基本上保持相同的格式(例如Web文档)，那么这不是什么大问题。但是，如果您必须对应该为哪些字段建立索引以及如何对待它们进行重大更改，则可能需要编辑索引配置文件。索引配置文件的某些更改为“热更新”，这意味着您可以进行更改而不会中断服务。但是，一些较大的更改是“冷更新”，在更改生效之前，它需要完整的数据重新馈送和索引编制。根据数据集的大小以及集群中的计算机数量，此操作可能需要数小时或数天。除非您有足够的现金购买可以在生产系统执行冷更新并重新加载数据的同时带到网上的额外硬件，否则很难安排冷更新。一年必须在生产集群上执行一次以上两次或两次以上，这需要大量的计划才能使停机时间最少或减少0％才能正确。
对于您的情况，我怀疑您的数据格式会非常频繁地更改。如果需要对其进行细微调整，则可以将其他元数据添加到作用域字段中，以避开进行任何完整数据重新加载的需要。
您可能会遇到的大多数麻烦是使用该产品的最初学习过程。一旦让开发集群(或节点)执行您想要的操作，并且不必不必频繁地对索引字段配置进行重大更改，它便是一个非常稳定且可靠的搜索引擎。对于您的应用程序来说，这听起来像是一个不错的选择，对于较小的公司或初创公司，这里有开源的选择，如果您不需要那么多的性能或耐用性，那么这些选择就不需要那么昂贵了。
希望这项评估对您有所帮助。 :)
真挚地，
迈克尔·麦金托什
TnR Global高级搜索架构师
关于database-design - 企业搜索: Has anybody developed on FAST ESP?您如何看待它？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/467121/