0

我目前正在将 Elasticsearch 作为搜索接口嵌入到现有应用程序中。该应用程序是带有 oracle SQL 数据库的经典 3 层应用程序。

我有实体“人”（数据库表），具有以下属性：

  • 名
  • 姓
  • 全名（包含连接的名字和姓氏）
  • 人号
  • 公司名称
  • 地址列表：街道、邮政编码、城市、电话和电子邮件。

到目前为止，我将它 1:1 放入 elasticsearch，每个 db-column 在 elasticsearch 中都有一个属性。数据的同步和满载是没有问题的。但我正在努力提供“良好”的搜索体验，因为有许多不同的事情需要注意：

  • 模糊搜索（允许一两个编辑距离）
  • 通配符搜索（如果我输入“Ange”，它也应该找到带有“Angelina”的结果）
  • 电子邮件地址搜索（我已经将uax_url_email标记器与keyword数据类型结合使用）

据我所知，multi_matchtypecross_fields是一个不错的选择，但它不能进行模糊搜索和通配符。typebest_fields也不是选项，因为它不能进行通配符搜索（据我所知？）。most_fields也不适合，phrase matching不能做模糊。

因此，我目前正在使用simple_query_string，例如：

在搜索字段中，我输入Tom fisher： 中的查询simple_query_string是：

(tom* | tom~1)+(fisher* | fisher~1)

我现在的问题是，只在字段“entity_content”上包含所有字段的内容是不是一个坏主意？这就像我有一个包含有关此人的所有信息的 .txt 文档。

  • 有什么优点/缺点？
4

1 回答 1

0

默认情况下，Elastic 有_all字段，它已经是包罗万象的字段，例如，所有信息都存储在该字段中，而不管它来自哪里。

_all 字段可能很有用，尤其是在使用简单过滤探索新数据时。但是，通过将字段值连接成一个大字符串，_all 字段失去了短字段（更相关）和长字段（不太相关）之间的区别。对于搜索相关性很重要的用例，最好专门查询各个字段。

_all 字段不是免费的：它需要额外的 CPU 周期并使用更多的磁盘空间。如果不需要，可以在每个字段的基础上完全禁用或自定义它。

于 2017-01-31T11:31:58.863 回答