2017-08-01 38 views
0

我使用Elasticsearch來存儲系統漏洞。現在我的典型項是如何查詢嵌套列表中的項目?

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

這種方法的優點在於簡化查詢(「機器的數量與類型1的vuln」 - >聚集,「漏洞的數量」 - 一個query_all搜索和相關total值,...)。

它ASLO有缺點,特別是:

  • 的信息在很大程度上demultiplied:關於一臺主機的信息被複制的所有漏洞
  • 有一樣多的行的漏洞,而不是主機(50倍平均更多)
  • 自然容器是「主機」而不是「漏洞」 - 它可以更容易地更新,刪除等。

所以我正在考慮改變計劃,「主機」基地之一:

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

我遇到的問題是,我仍然從根本上查詢的漏洞和不知道如何「爆炸」他們在查詢中。

具體(我相信我的問題會傾向於圍繞這個家庭的查詢),我怎麼可以查詢

  • type 1(而不是主機的漏洞總數 - 可以有1型的數vulns每個主機的基本查詢檢索作爲主機的條目)
  • 與上面相同,但是對漏洞名稱(例如type 1與name中的「Microsoft」的漏洞數量)進行了一些過濾 - 過濾是針對漏洞的一個功能,而不是主機)

回答

1

只是給你一個簡單的概述, 在Elasticsearch中有兩種方法來管理嵌套數據,你可以使用Nested Object或Inner Object,它們在場景後面是完全不同的。

嵌套類型是一種對象數據類型的專用版本,它允許對象數組相互獨立地編制索引和查詢。

  • 嵌套文檔存儲在相同的Lucene塊中,這有助於讀取/查詢性能。

    讀取嵌套文檔比等效的父/子快。

    更新嵌套文檔(父級或嵌套子級)中的單個字段會強制ES重新索引整個嵌套文檔。這對於大型嵌套文檔非常昂貴 「交叉引用」嵌套的文件是不可能的 最適合於不經常變動

內部對象是嵌入在父文檔內的對象的數據。

  • 簡單,快速,高性能的只有一到一個關係 保持無需特殊查詢嵌套

請看看下面的鏈接瞭解詳細信息內部對象之間的區別適用和嵌套對象。

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