数据建模提示

编辑

使用结构化和非结构化字段

编辑

注释通常是将结构化信息编织到非结构化文本中以实现更高精度搜索的一种方式。

实体解析 是由专业软件或人员进行的文档增强的一种形式,其中通过附加规范 ID 来消除文档中对实体的引用。该 ID 用于解析任意数量的别名或区分同名的人。维基百科文章之间的超链接就是编织到文本中的已解析实体 ID 的一个很好的例子。

这些 ID 可以作为注释嵌入到 annotated_text 字段中,但通常将它们包含在专用的结构化字段中以支持通过聚合进行发现更有意义。

PUT my-index-000001
{
  "mappings": {
    "properties": {
      "my_unstructured_text_field": {
        "type": "annotated_text"
      },
      "my_structured_people_field": {
        "type": "text",
        "fields": {
          "keyword" : {
            "type": "keyword"
          }
        }
      }
    }
  }
}

然后应用程序通常会提供内容并按如下方式发现它。

# Example documents
PUT my-index-000001/_doc/1
{
  "my_unstructured_text_field": "[Shay](%40kimchy) created elasticsearch",
  "my_twitter_handles": ["@kimchy"] 
}

GET my-index-000001/_search
{
  "query": {
    "query_string": {
        "query": "elasticsearch OR logstash OR kibana",
        "default_field": "my_unstructured_text_field"
    }
  },
  "aggregations": {
  	"top_people" :{
  	    "significant_terms" : { 
	       "field" : "my_twitter_handles.keyword"
  	    }
  	}
  }
}

请注意 my_twitter_handles 包含在非结构化文本中使用的注释值的列表。(请注意,annotated_text 语法需要转义)。通过在结构化字段中重复注释值,此应用程序确保在结构化字段中发现的标记可用于非结构化字段中的搜索和突出显示。

在此示例中,我们搜索讨论 Elastic Stack 组件的文档。

我们在这里使用 my_twitter_handles 字段来发现与 Elastic Stack 密切相关的人员。

避免过度匹配注释

编辑

根据设计,常规文本标记和注释标记共存在同一个索引字段中,但在极少数情况下,这可能导致一些过度匹配。

注释的值通常表示一个命名实体(人、地点或公司)。这些命名实体的标记未经分词插入,并且与典型的文本标记不同,因为它们通常

  • 混合大小写,例如 Madonna
  • 多个单词,例如 Jeff Beck
  • 可能包含标点符号或数字,例如 Apple Inc.@kimchy

这意味着,在大多数情况下,在注释文本字段中搜索命名实体不会出现任何误报,例如,当从聚合结果中选择 Apple Inc. 时,您可以向下钻取以突出显示文本中的用法,而不会在此上下文中对任何文本标记(如单词 apple)进行“过度匹配”。

the apple was very juicy

但是,如果您的命名实体恰好是一个单一术语且为小写,例如公司 elastic,则会出现问题。在这种情况下,在注释文本字段中对标记 elastic 进行搜索可能会匹配如下文本文档。

they fired an elastic band

为了避免此类错误匹配,用户应考虑为注释值添加前缀,以确保它们不会与文本标记发生名称冲突,例如:

[elastic](Company_elastic) released version 7.0 of the elastic stack today