如果查询在引号之间，如何从elasticsearch获取精确的文本匹配

如果查询在引号之间，如何从elasticsearch获取精确的文本匹配

据

content

我了解，您的字段会很大，因为许多文档可能超过2-3 MB，这是很多话。

keyword

根据您之前提到的问题的答案，使用字段来进行完全匹配毫无意义

keyword

。 仅当数据结构化时，才
应使用

keyword

数据类型进行完全匹配
__

我了解的是

content

您所拥有的领域是无组织的。在这种情况下，您可能想在您的字段上使用Whitespace
Analyzer

content

。

另外，对于精确的词组匹配，您还可以查看“
匹配词组”查询。

以下是满足您的用例的示例索引，文档和查询。

对应：

PUT mycontent_index{  "mappings": {    "properties": {      "content":{        "type":"text",        "analyzer": "whitespace" <----- Note this      }    }  }}

样本文件：

POST mycontent_index/_doc/1{  "content": """      There is no pain you are receding      A distant ship smoke on the horizon      You are only coming through in waves      Your lips move but I can't hear what you're saying  """}POST mycontent_index/_doc/2{  "content": """     there is no pain you are receding      a distant ship smoke on the horizon      you are only coming through in waves      your lips move but I can't hear what you're saying  """}

词组匹配：（按顺序搜索单词）

POST mycontent_index/_search{  "query": {    "bool": {      "must": [        {          "match_phrase": {        <---- Note this for phrase match "content": "There is no pain"          }        }      ]    }  }}

匹配查询：

POST mycontent_index/_search{  "query": {    "bool": {      "must": [        {          "match": {    <---- Use this for token based search "content": "there"          }        }      ]    }  }}

请注意，您的答复应相应。

要完全匹配一个单词，只需使用一个简单的Match查询即可。

请注意，当您不指定任何分析器时，默认情况下，ES使用标准分析器，这将导致将所有令牌转换为小写，然后再将它们存储在反向索引中。但是，Whitespace Analyzer
不会
将令牌转换为小写字母。结果

There

，

there

它们作为两个不同的令牌存储在ES索引中。

我假设您了解Analysis和Analyzer的概念，如果不了解，建议您浏览链接，因为这将帮助您更多地了解我在说什么。

更新的答案：

了解您的要求后，您将无法在单个字段上应用多个分析器，因此基本上您有两个选择：

选项1： 使用多个索引

选项2：
在映射中使用多字段，如下所示：

这样，您的脚本或服务层将具有根据输入值推送到不同索引或字段的逻辑（一个具有双反逗号和一个简单令牌）。

多字段映射：

PUT <your_index_name>{    "mappings":{       "properties":{          "content":{  "type":"text",          <--- Field with standard analyzer "fields":{     "whitespace":{        "type":"text",    <--- Field with whitespace       "analyzer":"whitespace"} }         }      }   }}

理想情况下，我希望拥有第一个解决方案，即使用具有不同映射关系的多个索引，但是我强烈建议您重新审视用例，因为这在管理这样的查询中没有意义，但在您的调用中再无用处。

注意： 单节点集群是 您可能曾经做过的最糟糕的选择，特别是对于生产而言。

我建议您在一个单独的问题中详细说明文档数量，未来5年的增长率或类似情况，并且您的用例会比较繁琐或密集？其他团队可能也想利用这个集群吗？我建议您阅读更多内容，并与您的团队或经理讨论，以使您的方案更加清晰。

希望这可以帮助。