目前,我们正在使用sql server全文搜索,但它太不灵活了。
我们做的主要工作是根据搜索查询从数据库中查找人的姓名。搜索要快,而且要模糊。SQL全文搜索并不真正支持模糊匹配,特别是当与同义词库选项相结合时。因此,我需要一个更好的解决办法。
我的研究表明lucene和solr是广泛使用的企业解决方案,但我的搜索表明这些解决方案更适合于索引文档和网页之类的内容,也就是所谓的“非结构化数据”。
我们的数据结构很好,因此我不确定它是否适合这种类型的工作,或者我是否应该研究另一种产品。根据“我的Solr1.4EnterpriseSearchServer”一书,它支持上述所有内容,但除了前缀匹配之外,它还声明子字符串搜索存在性能问题。
你认为solr/lucene是解决我问题的好技术吗?如果没有,你有别的选择吗?
欢迎任何建议。我是一个.NET开发人员,因此solrnet而不是solr。
发布于 2013-12-19 16:45:35
我只对Solr和狮身人面像有过经验,所以不能比得太多。我们不用太多的“模糊”搜索。但我和Solr合作过很多,我觉得我很了解医生。
首先,必须以非常技术性的方式来理解“文件”一词。这绝不是将搜索限制在典型的文本文档上。我们使用Solr从数据库中搜索产品,在这种情况下,文档只是表示单个产品的非规范化数据流,通常所有文本信息都直接附在产品文档的相关表中。所以,不管你想搜索什么,如果它有某种独特的标识和文字描述(标签,类别,分类,品牌.)它有资格成为文件。
好的,回到模糊的地方。这种搜索是很困难的,因为在这里您不能真正地使用索引。您必须将一个字符串与每个索引字符串进行比较,并计算某种“距离”值,然后根据最大距离进行选择。Solr提供模糊搜索和邻近搜索,但是由于我们不使用它,我不能说它们的性能有多好。但是,正如人们可以从4.0版的互联网上看到的那样,Lucene使用了一种叫做Levenshtein的东西,它应该能够对非常大的索引进行模糊搜索。
也许这里也很有趣,比如Solr建立索引的方式。在索引每个字符串之前,每个字符串都要经过筛选器和标记器。有一些神奇的事情发生了,你可以强烈地影响指数对你的数据有多好。已经有很多默认的过滤器和托卡器,但是您甚至可以编写自己的。因此,也许会有一些方法来提高这里的性能。
除此之外,还有几件事是Solr真正伟大的。主要是面向搜索,其中您搜索和计数,例如,多少产品是在一个给定的品种。只需列出所有的分类和计数,然后继续做同样的列表,在几乎实时与一个搜索词。或者选择另一个方面(比如brand=CocaCola),一个搜索词(q=light),然后再得到一个包含所有种类和产品数量的列表。这种交叉引用出现得如此之快,以至于我们实际上用Solr查询替换了几乎每一个SQL产品列表或我们网站上的搜索。
https://softwareengineering.stackexchange.com/questions/221887
复制相似问题