我正在开发一个应用程序，需要通过搜索来做有趣的事情，包括全文搜索、命中突出显示、分面搜索等......
该数据集可能有 3000-10000 条记录，每条记录有 20-30 个字段，并且全部存储在 MySQL 中。该网站的流量概况可能是中小型。
所有这些要求都可以在 MySQL 中（笨拙地）实现，但是在什么时候（就数据大小和流量水平而言）值得考虑更集中的技术，例如 Solr 或 Sphinx？
这个问题需要一个非常广泛的答案，需要从各个方面来回答。在特殊用例中，有一些特定的细节可能会使一个系统优于另一个系统，但我想在这里介绍一些基础知识。
我将完全以 Solr 作为几个功能大致相同的搜索引擎的示例。
我想从一些确凿的事实开始：
您不能依赖 Solr/Lucene 作为安全数据库。有一系列事实，但它们主要包括缺少恢复选项、缺乏酸性事务、可能的复杂性等。如果您决定使用 solr，则需要从其他来源（如 SQL 表）填充索引。事实上，solr 非常适合存储包含来自多个表和关系的数据的文档，否则需要构建复杂的联接。
Solr/Lucene 提供令人兴奋的文本分析/词干提取/全文搜索评分/模糊功能。 MySQL 无法做到的事情。事实上，MySql 中的全文搜索仅限于 MyIsam，并且评分非常微不足道且有限。对字段进行加权、根据某些指标增强文档、根据短语邻近度对结果进行评分、匹配准确性等是非常艰巨的工作，几乎是不可能的。
在 Solr/Lucene 中你有文档。你无法真正存储关系和过程。当然，您可以在某个文档的多值字段内对其他文档的键进行索引，这样您就可以实际存储 1:n 关系，并以两种方式获取 n:n，但会产生数据开销。不要误会我的意思，它对于很多用途来说都是完美且高效的（例如，对于某些产品目录，您想要存储产品的经销商，并且您只想搜索某些经销商或其他地方提供的零件）。但你会因为“有”/“没有”而到达可能性的尽头。您几乎不能做“获取至少 3 个经销商提供的所有产品”之类的事情。
Solr/Lucene 具有非常好的分面功能和搜索后分析。例如：在进行了 40000 次匹配的非常广泛的搜索之后，您可以显示，如果您将搜索细化为将此字段设置为该值，而将该字段设置为该值的组合，则您只会获得 3 次匹配。需要在 MySQL 中进行额外查询的事情可以高效且方便地完成。
那么我们总结一下
Lucene 的强大之处在于文本搜索/分析。由于反向索引结构，它的速度也快得令人难以置信。确实可以做很多后期处理，满足其他需求。尽管它是面向文档的并且没有像 SPARQL 中的三元组存储那样的“图形查询”，但可以存储和查询基本的 N:M 关系。如果您的应用程序专注于文本搜索，如果您没有充分的理由（例如非常复杂的多维范围过滤器查询），那么您绝对应该选择 Solr/Lucene。
如果您没有文本搜索，而是可以点击某些内容但不能输入文本，那么旧的关系数据库可能是更好的选择。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
