Question

我使用Elasticsearch来存储系统漏洞。现在我的典型条目是

{
  _id: somenadomid
  _source: {
     "ip": "10.10.10.10",
     "vuln_name": "v1",
     "vuln_type": 1
}

此方法具有简化查询的优势（“具有类型1的漏洞的计算机的数量” - >聚合，“漏洞数量” - query_all搜索和关联的total值，...）。

它也有缺点，特别是：

信息被严重分解：有关一个主机的信息被复制到所有漏洞
有多少行是漏洞，而不是主机（平均多50倍）
自然容器是“主机”而不是“漏洞” - 它可以更容易地更新，删除等。

因此，我正在考虑将该计划更改为“主机”基础：

{
  _id: machine1
  _source: {
     "ip": "10.10.10.10",
     "vuln": [
         {
             "name": "v1",
             "type": 1
         },
         {
             "name": "v2",
             "type": 1
         }
      ]
}

我遇到的问题是我仍然从根本上查询漏洞，并且不知道如何在查询中“爆炸”它们。

具体来说（我相信我的问题会围绕这一系列的查询），我该如何查询

type 1的漏洞总数（不是主机 - 每个主机可能有几个类型1的漏洞，基本查询检索条目，即主机）
与上面相同，但是对漏洞名称（“type中带有”Microsoft“的name 1的漏洞数量）进行了一些过滤 - 过滤是针对某个功能的漏洞，而不是主机）

Answer 1

只是给你一个简单的概述，在Elasticsearch中你有两种管理嵌套数据的方法，你可以使用嵌套对象或内部对象，在场景后面它们完全不同。

嵌套类型是对象数据类型的专用版本，它允许对象数组彼此独立地编制索引和查询。

嵌套文档彼此存储在相同的Lucene块中，这有助于读取/查询性能。

阅读嵌套文档的速度比等效的父/子快。

更新嵌套文档中的单个字段（父级或嵌套子级）会强制ES重新索引整个嵌套文档。对于大型嵌套文档，这可能非常昂贵＆＃34;交叉引用＆＃34;嵌套文件是不可能的最适合不经常变化的数据

内部对象是嵌入在父文档中的对象。

简单，快速，高效只适用于一对一的关系维护不需要特殊查询嵌套

请查看以下链接，了解内部对象与嵌套对象之间差异的更多信息。

https://www.elastic.co/blog/managing-relations-inside-elasticsearch

要查询和汇总（获取总数），请查看以下链接：

查询：https://www.elastic.co/guide/en/elasticsearch/guide/master/nested-objects.html

汇总： https://www.elastic.co/guide/en/elasticsearch/guide/current/nested-aggregation.html

如何查询嵌套列表中的项目？

1 个答案: