Elasticsearch 嵌套字段 vs 深度？通过 Kibana 检查文档深度？

Question

我正在阅读有关elasticsearch 中的映射的信息，我看到了这两个术语：Nested-field & Depth。我认为这两个术语非常等效。我目前对这些 2 感到困惑。请任何人清除我？谢谢你。顺便说一句，有没有办法通过 Kibana 检查文档深度？

对不起我的英语不好。

Answer 1

混淆的根源可能是因为在 Elasticsearch 中术语nested可以在两种不同的上下文中使用：

• “嵌套”作为一个常规的JSON 符号嵌套，即 JSON 对象内的 JSON 对象；
• “嵌套”为 Elasticsearchnested数据类型。

在映射文档页面中，当他们提到“深度”时，他们指的是第一个含义。此处的设置index.mapping.depth.limit定义了 JSON 文档的嵌套深度。

Elasticsearch 映射如何解释 JSON 深度？

以下是深度为 1 的 JSON 文档示例：

 {
    "name": "John",
    "age": 30
 }

现在深度 2：

 {
    "name": "John",
    "age": 30,
    "cars": {
        "car1": "Ford",
        "car2": "BMW",
        "car3": "Fiat"
    }
 }

默认情况下（从 ES 6.3 开始）深度不能超过 20。

什么是nested数据类型，为什么它与深度> 1 的文档不同？

nested数据类型允许索引对象数组并通过nestedquery单独查询它们的项目。这意味着 Elasticsearch 将以不同的方式索引具有此类字段的文档（有关更多解释，请参阅权威指南的嵌套对象页面）。

例如，如果在下面的示例中我们没有在映射中定义"user"为nested字段，则查询user.first: John和user.last: White将返回匹配项，这将是一个错误：

{
  "group" : "fans",
  "user" : [ 
    {
      "first" : "John",
      "last" :  "Smith"
    },
    {
      "first" : "Alice",
      "last" :  "White"
    }
  ]
}

如果我们这样做，Elasticsearch 会将"user"列表中的每一项作为隐式子文档进行索引，因此将使用更多资源、更多磁盘和内存。这就是为什么在映射上还有另一个设置：index.mapping.nested_fields.limit规定nested可以声明多少个不同的字段（默认为50）。要对此进行自定义，您可以查看此答案。

因此，深度 > 1 的 Elasticsearch 文档不会被编入索引，nested除非您明确要求它这样做，这就是区别。

我可以nested在里面有字段nested吗？

是的你可以！只是为了阻止这种混淆，是的，您可以在映射中的nested字段内定义一个字段nested。它看起来像这样：

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "user": {
          "type": "nested",
          "properties": {
            "name": {
              "type": "keyword"
            },
            "cars": {
              "type": "nested",
              "properties": {
                "brand": {
                  "type": "keyword"
                }
              }
            }
          }
        }
      }
    }
  }
}

但请记住，要建立索引的隐式文档的数量将成倍增加，而且效率不会那么高。

我可以从 Kibana 获取 JSON 对象的深度吗？

很可能您可以使用脚本来完成，请查看此博客文章以获取更多详细信息：在 Kibana 脚本化字段中使用 Painless。