自建博客地址：https://www.bytelife.net，歡迎訪問！ 本文為博客同步發表文章，為了更好的閱讀體驗，建議您移步至我的博客??
本文作者： Jeffrey
本文鏈接： https://www.bytelife.net/articles/51440.html
著作權宣告： 本博客所有文章除特別宣告外，均采用 BY-NC-SA 許可協議，轉載請注明出處！
本文將討論如何在ElasticSearch中使用nested結構進行資料的存盤、查詢和聚合，并結合K-V場景討論ElasticSearch針對field數量限制的解決方案，
為何要使用Nested結構存盤KV（鍵值對）?
ElasticSearch對于field的數量有限制，默認情況下field的數量如果超過1000個，寫入時再創建新的fields就會報錯：
java.lang.IllegalArgumentException: Limit of total fields [1000] in index [(index_name)] has been exceeded
at org.elasticsearch.index.mapper.MapperService.checkTotalFieldsLimit(MapperService.java:630)
但有些場景的field數量并不是我們能控制的，例如在監控系統中的業務資料所攜帶的業務標簽，其中可能包含了監控系統不能預知的業務欄位，
對于這種情景，可能想到的解決方案兩個：
- 調整ElasticSearch的配置，增加field的限制數量：這種方案僅僅適用于可以預測出field數量極限的情況，治標不治本，一旦field數量再次抵達限制，又會面臨同樣的問題，
- 就是使用Pair結構來存盤
假設第2種方案的資料結構為：
{
"labels": [{
"key": "ip",
"value: "127.0.0.1"
}]
},
{
"labels": [{
"key": "ip",
"value: "127.0.0.2"
}]
}
那么es查詢就會存在一個問題，例如下面的查詢：
{
"query":{
"bool":{
"must":[
{
"match":{
"key":"ip"
}
},
{
"match":{
"value":"127.0.0.1"
}
}
]
}
}
}
這個查詢會把例子中的的資料全部查詢出來，并不符合我們的預期，這是因為es在存盤索引時，對于普通object型別的field實際上是打平來存盤的，比如這樣：
{
"labels.key":[
"ip"
],
"labels.value":[
"127.0.0.1",
"127.0.0.2"
]
}
可以看見，索引打平后，物件的關聯關系丟失了，對于這種情況，ElasticSearch提供的nested結構可以幫助我們解決類似的問題，Nested結構保留了子檔案資料中的關聯性，如果labels的資料格式被定義為nested，那么每一個nested object將會作為一個隱藏的單獨文本建立索引，如下：
{
"labels.key":"ip",
"labels.value":"127.0.0.1"
},
{
"labels.key":"ip",
"labels.value":"127.0.0.2"
}
通過分開給每個nested object建索引，object內部的欄位間的關系就能保持，當執行查詢時，只會匹配’match’同時出現在相同的nested object的結果，
定義mappings
使用nested結構非常簡單，指定欄位的type為nested即可，下面的例子中定義了一個名為labels的nested結構，其中包含兩個欄位，分別是key和value，
"mappings": {
"demoType": {
"labels": {
// 欄位型別設定為nested
"type": "nested",
"properties": {
"key": {
"type": "keyword"
},
"value": {
"type": "keyword"
}
}
}
}
}
查詢
nested結構的資料查詢和普通object略有不同，nested object作為一個獨立隱藏檔案單獨建索引，因此，不能直接查詢到它們，取而代之，我們必須使用nested查詢或者nested filter，例如：
{
"query": {
"bool": {
"must": [
{
"nested": {
"path": "labels",
"query": {
"bool": {
"must": [
{
"term": {
"labels.key": "ip"
}
},
{
"term": {
"labels.value": "127.0.0.1"
}
}
]
}
}
}
}
]
}
}
}
這個查詢可以回傳我們預期的正確結果：
[{
"labels": {
"key": "ip",
"value": "127.0.0.1"
}
}]
分桶聚合
查詢的問題解決了，聚合時問題又來了，前面我們說到，nested結構存盤在一個隱藏的單獨文本索引中，那么普通的聚合查詢自然便無法訪問到它們，因此，nested結構在聚合時，需要使用特定的nested聚合，
nested聚合
假設es中存盤如下資料：
[{
"labels": [{
"key": "ip",
"value": "127.0.0.1"
},{
"key": "os",
"value": "windows"
}]
}, {
"labels": [{
"key": "ip",
"value": "127.0.0.2"
},{
"key": "os",
"value": "linux"
}]
}]
我們要聚合所有對labels.value進行聚合，可以使用下面的方式：
{
"size": 0,
"aggs": {
"labels_nested": {
"nested": {
"path": "labels"
},
"aggs": {
"nested_value": {
"terms": {
"field": "labels.value"
}
}
}
}
}
}
這個查詢將會得到下面類似的結果：
{
"aggregations": {
"labels_nested": {
"doc_count": 2,
"nested_value": {
"buckets": [
{
"doc_count": 1,
"key": "127.0.0.1"
},
{
"doc_count": 1,
"key": "127.0.0.2"
},
{
"doc_count": 1,
"key": "windows"
},
{
"doc_count": 1,
"key": "linux"
}
]
}
}
}
}
過濾屬性值
上面的例子可以看到，其只是單純的將所有的value進行了聚合，并沒有針對k-v中的key進行過濾，因此導致labels.key為ip和os的資料均被統計到了其中，這通常不符合我們實際場景中的需求，
現在假設要對所有labels.key為ip的labels.value進行聚合，那么可以使用如下的方式：
{
"size": 0,
"aggs": {
"labels_nested": {
"nested": {
"path": "labels"
},
"aggs": {
"nested_ip": {
"filter": {
"term": {
"labels.key": "ip"
}
},
"aggs": {
"nested_value": {
"terms": {
"field": "labels.value"
}
}
}
}
}
}
}
}
通過這樣的方式就可以把labels.key不是ip的檔案過濾掉，經過這個查詢將得到類似如下的結果：
{
"aggregations": {
"labels_nested": {
"doc_count": 2,
"nested_ip": {
"doc_count": 2,
"nested_value": {
"buckets": [
{
"doc_count": 1,
"key": "127.0.0.1"
},
{
"doc_count": 1,
"key": "127.0.0.2"
}
]
}
}
}
}
}
nested多重聚合
如果想在nested聚合下嵌套聚合其它欄位，直接嵌套是不行的，這里需要使用到reverse_nested跳出當前nested聚合后，再進行嵌套聚合，
注意：無論是嵌套其它nested欄位還是普通欄位，都需要使用reverse_nested跳出當前nested聚合，
例如想對labels.key為ip聚合后，再對labels.key為os進行聚合：
{
"size": 0,
"aggs": {
"labels_nested": {
"nested": {
"path": "labels"
},
"aggs": {
"nested_ip": {
"filter": {
"term": {
"labels.key": "ip"
}
},
"aggs": {
"nested_ip_value": {
"terms": {
"field": "labels.value"
},
"aggs": {
"reverse_labels": {
"reverse_nested": {}, //注意這里
"aggs": {
"nested_os": {
"nested": {
"path": "labels"
},
"aggs": {
"labels_os": {
"filter": {
"term": {
"labels.key": "os"
}
},
"aggs": {
"labels_os_value": {
"terms": {
"field": "labels.value"
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
如此，將得到類似下面的結果：
{
"aggregations": {
"labels_nested": {
"doc_count": 2,
"nested_ip": {
"nested_ip_value": {
"buckets": [
{
"doc_count": 1,
"reverse_labels": {
"doc_count": 1,
"nested_os": {
"labels_os": {
"doc_count": 1,
"labels_os_value": {
"buckets": [
{
"doc_count": 1,
"key": "windows"
}
]
}
},
"doc_count": 1
}
},
"key": "127.0.0.1"
},
{
"doc_count": 1,
"reverse_labels": {
"doc_count": 1,
"nested_os": {
"labels_os": {
"doc_count": 1,
"labels_os_value": {
"buckets": [
{
"doc_count": 1,
"key": "linux"
}
]
}
},
"doc_count": 1
}
},
"key": "127.0.0.2"
}
]
},
"doc_count": 2
}
}
}
}
結語
至此，關于nested結構存盤K-V的用法就介紹完啦！使用nested結構可以幫助我們保持object內部的關聯性，借此解決elasticsearch對field數量的限制，nested結構不僅可以應用在K-V結構的場景，還可以應用于其它任何需要保持object內部關聯性的場景，
注意：使用nested結構也會存在一些問題：
- 增加，改變或者洗掉一個nested文本，整個文本必須重新建索引，nested文本越多，代價越大，
- 檢索請求會回傳整個文本，而不僅是匹配的nested文本，盡管有計劃正在執行以能夠支持回傳根文本的同時回傳最匹配的nested文本，但目前還未實作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/266966.html
標籤：大數據