Elasticsearch 7.7.0 高阶篇-聚合技术
前言
本篇內容是es的最后一篇，主要講解聚合技術，以及與其相關的算法和原理，最后結合實際應用，簡單說明了一些常用的數據建模。
一 聚合分析之 bucket(分組)&meteric(統計)
這一節內容主要是介紹下 bucket(分組)的概念 以及 meteric(聚合統計)概念，其實我們做過開發寫過sql的就很容易理解了。然后我們結合案例進行練習和體會不同的bucket，以及不同的meteric，強化我們對分組和聚合統計的理解和記憶。
1.1 原理 bucket(分組)與metric(聚合統計)概念理解
bucket 它是指對一組數據進行分組
假設一組數據為：
city name
北京 小李
北京 小王
上海 小張
上海 小麗
上海 小陳
那么基于city劃分buckets，劃分出來兩個bucket，一個是北京bucket，一個是上海bucket
則：
北京bucket：包含了2個人，小李，小王
上海bucket：包含了3個人，小張，小麗，小陳
其實 sql中的分組，就是我們這里的bucket。
?
metric：對一個數據分組執行的統計
當我們有了一堆bucket之后，就可以對每個bucket中的數據進行聚合分詞了，比如說計算一個bucket內所有數據的數量，或者計算一個bucket內所有數據的平均值，最大值，最小值
metric，就是對一個bucket執行的某種聚合分析的操作，比如說求平均值，求最大值，求最小值
1.2 實戰 各種bucket(分組)與各種metric(聚合統計）
以一個家電賣場中的電視銷售數據為背景，來對各種品牌，各種顏色的電視的銷量和銷售額，進行各種各樣角度的分析
1.2.1 準備初始化數據
PUT /tvs {"mappings": {"properties": {"price": {"type": "long"},"color": {"type": "keyword"},"brand": {"type": "keyword"},"sold_date": {"type": "date"}}} } POST /tvs/_bulk {"index":{}} {"price":1000,"color":"紅色","brand":"長虹","sold_date":"2016-10-28"} {"index":{}} {"price":2000,"color":"紅色","brand":"長虹","sold_date":"2016-11-05"} {"index":{}} {"price":3000,"color":"綠色","brand":"小米","sold_date":"2016-05-18"} {"index":{}} {"price":1500,"color":"藍色","brand":"TCL","sold_date":"2016-07-02"} {"index":{}} {"price":1200,"color":"綠色","brand":"TCL","sold_date":"2016-08-19"} {"index":{}} {"price":2000,"color":"紅色","brand":"長虹","sold_date":"2016-11-05"} {"index":{}} {"price":8000,"color":"紅色","brand":"三星","sold_date":"2017-01-01"} {"index":{}} {"price":2500,"color":"藍色","brand":"小米","sold_date":"2017-02-12"}1.2.2 按顏色分組統計電視銷量
size：=0只獲取聚合結果，而不要執行聚合的原始數據
aggs：固定語法，要對一份數據執行分組聚合操作
popular_colors：就是對每個aggs，都要起一個名字，這個名字是隨機的，你隨便取什么都ok
terms：根據字段的值進行分組
field：根據指定的字段的值進行分組
GET /tvs/_search {"size": 0,"aggs": {"popular_colors": {"terms": {"field": "color"}}} }獲取結果
{"took" : 142,"timed_out" : false,"_shards" : {"total" : 1,"successful" : 1,"skipped" : 0,"failed" : 0},"hits" : {"total" : {"value" : 8,"relation" : "eq"},"max_score" : null,"hits" : [ ]},"aggregations" : {"popular_colors" : {"doc_count_error_upper_bound" : 0,"sum_other_doc_count" : 0,"buckets" : [{"key" : "紅色","doc_count" : 4},{"key" : "綠色","doc_count" : 2},{"key" : "藍色","doc_count" : 2}]}} }1.2.3 按顏色分組metric（統計）平均(avg)價格
除了bucket操作，分組，還要對每個bucket執行一個metric聚合統計操作
在一個aggs執行的bucket操作（terms），平級的json結構下，再加一個aggs，這個第二個aggs內部，同樣取個名字，執行一個metric操作，avg，對之前的每個bucket中的數據的指定的field，price field，求一個平均值
GET /tvs/_search {"size": 0,"aggs": {"colors": {"terms": {"field": "color"},"aggs": {"avg_price": {"avg": {"field": "price"}}}}} }buckets，除了key和doc_count
avg_price：我們自己取的metric aggs的名字
value：我們的metric計算的結果，每個bucket中的數據的price字段求平均值后的結果
1.2.4 按顏色分組metric（統計）最大(max) 最小（min）價格
max：求一個bucket內，指定field值最大的那個數據
min：求一個bucket內，指定field值最小的那個數據
sum：求一個bucket內，指定field值的總和
一般來說，90%的常見的數據分析的操作，metric，無非就是count，avg，max，min，sum
求總和，就可以拿到一個顏色下的所有電視的銷售總額
GET /tvs/_search {"size": 0,"aggs": {"colors": {"terms": {"field": "color"},"aggs": {"avg_price": {"avg": {"field": "price"}},"min_price": {"min": {"field": "price"}},"max_price": {"max": {"field": "price"}},"sum_price": {"sum": {"field": "price"}}}}} }1.2.5 按價格區間(histogram&interval) 統計銷售量和銷售額
histogram 也是bucket ，他按照某個值指定的interval(步長)，劃分一個一個的bucket
interval：2000，劃分范圍，0~2000，2000~4000，4000~6000，6000~8000，8000~10000，buckets
去根據price的值，比如2500，看落在哪個區間內，比如2000~4000，此時就會將這條數據放入2000~4000對應的那個bucket中。
GET /tvs/_search {"size": 0,"aggs": {"price": {"histogram": {"field": "price","interval": 2000},"aggs": {"revenue": {"sum": {"field": "price"}}}}} }1.2.6 按日期區間（histogram&calendar_interval） 統計電視銷量
date histogram，按照我們指定的某個date類型的日期field，以及日期calendar_interval，按照一定的日期間隔，去劃分bucket。
假設：
calendar_interval = 1m，
則：
2017-01-01~2017-01-31，就是一個bucket
2017-02-01~2017-02-28，就是一個bucket
然后會去掃描每個數據的date field，判斷date落在哪個bucket中，就將其放入那個bucket，2017-01-05，就將其放入2017-01-01~2017-01-31，就是一個bucket。
min_doc_count：即使某個日期interval，2017-01-01~2017-01-31中，一條數據都沒有，那么這個區間也是要返回的，不然默認是會過濾掉這個區間的
extended_bounds，min，max：劃分bucket的時候，會限定在這個起始日期，和截止日期內
GET /tvs/_search {"size": 0,"aggs": {"price": {"histogram": {"field": "price","interval": 2000},"aggs": {"revenue": {"sum": {"field": "price"}}}}} }1.2.7 按顏色+生產商多層分組(bucket)嵌套下鉆分析
下鉆分析，就要對bucket進行多層嵌套，多次分組。
舉例理解：
比如說，現在紅色的電視有4臺，同時這4臺電視中，有3臺是屬于長虹的，1臺是屬于小米的
紅色電視中的3臺長虹的平均價格是多少？
紅色電視中的1臺小米的平均價格是多少？
下鉆的意思是，已經分了一個組，比如說顏色的分組，然后還要繼續對這個分組內的數據，再分組，比如一 ? ? ? ? ?個顏色內，還可以分成多個不同的品牌的組，最后對每個最小粒度的分組執行聚合分析操作，這就叫做下鉆 ? ? ? ? ? ?分析
按照多個維度（顏色+品牌）多層下鉆分析，都可以對每個維度分別執行一次metric聚合操作
GET /tvs/_search {"size": 0,"aggs": {"group_by_color": {"terms": {"field": "color"},"aggs": {"color_avg_price": {"avg": {"field": "price"}},"group_by_brand": {"terms": {"field": "brand"},"aggs": {"brand_avg_price": {"avg": {"field": "price"}}}}}}} }1.2.8 按季度+品牌多層分組下鉆分析售額
GET /tvs/_search {"size": 0,"aggs": {"group_by_sold_date": {"date_histogram": {"field": "sold_date","calendar_interval": "quarter","format": "yyyy-MM-dd","min_doc_count": 0,"extended_bounds": {"min": "2016-01-01","max": "2017-12-31"}},"aggs": {"group_by_brand": {"terms": {"field": "brand"},"aggs": {"sum_price": {"sum": {"field": "price"}}}},"total_sum_price": {"sum": {"field": "price"}}}}} }二 聚合分析之縮小數據范圍&數據排序
2.1 先縮小數據范圍再聚合分析
2.1.1 按小米品牌搜索 統計銷售額
先查詢 品牌為小米的數據 后聚合
GET /tvs/_search {"size": 0,"query": {"term": {"brand": {"value": "小米"}}},"aggs": {"group_by_color": {"terms": {"field": "color"}}} }2.1.2 單品牌長虹與所有品牌(global bucket)銷量對比
global就是global bucket，就是將所有數據納入聚合的scope，他不關心過濾的范圍，他是統計所有的數據
GET /tvs/_search {"size": 0,"query": {"term": {"brand": {"value": "長虹"}}},"aggs": {"single_brand_avg_price": {"avg": {"field": "price"}},"all": {"global": {},"aggs": {"all_brand_avg_price": {"avg": {"field": "price"}}}}} }single_brand_avg_price：就是針對query搜索結果，執行的，拿到的，就是長虹品牌的平均價格
all.all_brand_avg_price：拿到所有品牌的平均價格
2.1.3 按價格大于1200過濾(filter) 計算平均價格
先搜索過濾出價格大于1200 的數據，然后再計算avg價格
GET /tvs/_search {"size": 0,"query": {"constant_score": {"filter": {"range": {"price": {"gte": 1200}}}}},"aggs": {"avg_price": {"avg": {"field": "price"}}} }2.1.4 按時間段+品牌過濾統計銷售額
GET /tvs/_search {"size": 0,"query": {"term": {"brand": {"value": "長虹"}}},"aggs": {"recent_150d": {"filter": {"range": {"sold_date": {"gte": "now-150d"}}},"aggs": {"recent_150d_avg_price": {"avg": {"field": "price"}}}},"recent_140d": {"filter": {"range": {"sold_date": {"gte": "now-140d"}}},"aggs": {"recent_140d_avg_price": {"avg": {"field": "price"}}}},"recent_130d": {"filter": {"range": {"sold_date": {"gte": "now-130d"}}},"aggs": {"recent_130d_avg_price": {"avg": {"field": "price"}}}}} }bucket filter：對不同的bucket下的aggs，進行filter
2.2 對分組數據進行排序
2.2.1 按顏色分組對銷售額排序
每個顏色的電視的銷售額，需要按照銷售額降序排序
GET /tvs/_search {"size": 0,"aggs": {"group_by_color": {"terms": {"field": "color","order": {"avg_price": "asc"}},"aggs": {"avg_price": {"avg": {"field": "price"}}}}} }2.2.2 按顏色+品牌多層分組下鉆排序
就是先顏色分組 ?然后品牌里分組且排序(平均價格降序)
GET /tvs/_search {"size": 0,"aggs": {"group_by_color": {"terms": {"field": "color"},"aggs": {"group_by_brand": {"terms": {"field": "brand","order": {"avg_price": "desc"}},"aggs": {"avg_price": {"avg": {"field": "price"}}}}}}} }三 聚合分析之百分比統計
3.1 percentiles百分比統計
需求：比如有一個網站，記錄下了每次請求的訪問的耗時，需要統計tp50，tp90，tp99
tp50：50%的請求的耗時最長在多長時間
tp90：90%的請求的耗時最長在多長時間
tp99：99%的請求的耗時最長在多長時間
3.1.1 初始化數據
DELETE website PUT /website {"mappings": {"properties": {"latency": {"type": "long"},"province": {"type": "keyword"},"timestamp": {"type": "date"}}} }POST /website/_bulk {"index":{}} {"latency":105,"province":"江蘇","timestamp":"2016-10-28"} {"index":{}} {"latency":83,"province":"江蘇","timestamp":"2016-10-29"} {"index":{}} {"latency":92,"province":"江蘇","timestamp":"2016-10-29"} {"index":{}} {"latency":112,"province":"江蘇","timestamp":"2016-10-28"} {"index":{}} {"latency":68,"province":"江蘇","timestamp":"2016-10-28"} {"index":{}} {"latency":76,"province":"江蘇","timestamp":"2016-10-29"} {"index":{}} {"latency":101,"province":"新疆","timestamp":"2016-10-28"} {"index":{}} {"latency":275,"province":"新疆","timestamp":"2016-10-29"} {"index":{}} {"latency":166,"province":"新疆","timestamp":"2016-10-29"} {"index":{}} {"latency":654,"province":"新疆","timestamp":"2016-10-28"} {"index":{}} {"latency":389,"province":"新疆","timestamp":"2016-10-28"} {"index":{}} {"latency":302,"province":"新疆","timestamp":"2016-10-29"}3.1.2 百分比統計
GET /website/_search {"size": 0,"aggs": {"latency_percentiles": {"percentiles": {"field": "latency","percents": [50,95,99]}},"latency_avg": {"avg": {"field": "latency"}}} }50%的請求，數值的最大的值是多少，不是完全準確的
3.1.3 按照省份分組 算百分比
GET /website/_search {"size": 0,"aggs": {"group_by_province": {"terms": {"field": "province"},"aggs": {"latency_percentiles": {"percentiles": {"field": "latency","percents": [50,95,99]}},"latency_avg": {"avg": {"field": "latency"}}}}} }3.2 ?percentile rank&SLA統計
SLA：就是你提供的服務的標準
我們的網站的提供的訪問延時的SLA，確保所有的請求100%，都必須在200ms以內，大公司內，一般都是要求100%在200ms以內，如果超過1s，則需要升級到A級故障，代表網站的訪問性能和用戶體驗急劇下降。
需求：在200ms以內的，有百分之多少，在1000毫秒以內的有百分之多少，percentile ranks metric
GET /website/_search {"size": 0,"aggs": {"group_by_province": {"terms": {"field": "province"},"aggs": {"latency_percentile_ranks": {"percentile_ranks": {"field": "latency","values": [200,1000]}}}}} }percentile的優化
如果你想要percentile算法越精準，compression可以設置的越大
四 聚合分析相關算法原理及優化
4.1 易并行&不易并行算法
易并行：max
不易并行：count(distinct)，并不是說，在每個node上，直接就出一些count(distinct) value，就可以的，因為數據可能會很多。
es會采取近似聚合算法，就是采用在每個node上進行近估計的方式，得到最終的結論。
?
如果采取近似估計的算法：延時在100ms左右（一般會達到完全精準的算法的性能的數十倍），0.5%錯誤
如果采取100%精準的算法：延時一般在5s~幾十s，甚至幾十分鐘，幾小時， 0%錯誤
4.2 精準+實時+大數據三角選擇原則
4.3 cartinality(去重)算法
cartinality metric，對每個bucket中的指定的field進行去重，取去重后的count，類似于count(distcint)
GET /tvs/_search {"size": 0,"aggs": {"months": {"date_histogram": {"field": "sold_date","calendar_interval": "month"},"aggs": {"distinct_colors": {"cardinality": {"field": "brand"}}}}} }4.4 cardinality&precision_threshold優化準確率和內存開銷
GET /tvs/_search {"size": 0,"aggs": {"distinct_brand": {"cardinality": {"field": "brand","precision_threshold": 100}}} }brand去重，如果brand的unique value，precision_threshold=100 ,即 在100個以內，小米，長虹，三星，TCL，HTL......則cardinality，幾乎保證100%準確。
precision_threshold：
- 會占用precision_threshold * 8 byte 內存消耗，100 * 8 = 800個字節（占用內存很小）
- 而且unique value如果的確在值以內，那么可以確保100%準確
precision_threshold，值設置的越大，占用內存越大，1000 * 8 = 8000 / 1000 = 8KB，可以確保更多unique value的場景下，100%的準確。
4.5 HyperLogLog++ (HLL)算法index-time性能優化
cardinality底層算法：HLL算法會對所有的uqniue value取hash值，通過hash值近似去求distcint count。
默認情況下，發送一個cardinality請求的時候，會動態地對所有的field value 取hash值;
優化方法：將取hash值的操作，前移到建立索引的時候，即我們灌入數據的時候建好hash值，但是提升性能不大，了解即可
PUT /tvs {"mappings": {"properties": {"brand": {"type": "text","fields": {"hash": {"type": "murmur3"}}}}} }GET /tvs/_search {"size": 0,"aggs": {"distinct_brand": {"cardinality": {"field": "brand.hash","precision_threshold": 100}}} }五 聚合分析的內部原理
5.1 doc value 正排原理
聚合分析的內部原理是什么？aggs，term，metric avg max，執行一個聚合操作的時候，內部原理是怎樣的呢？用了什么樣的數據結構去執行聚合？是不是用的倒排索引？
GET /test_index/_search {"query": {"match": {"search_field": "test"}},"aggs": {"group_by_agg_field": {"terms": {"field": "agg_field"}}} }模擬解釋
查詢操作
doc1: hello world test1, test2 、doc2: hello test、doc3: world test
創建倒排索引
| word? | doc1 | doc2 | doc3 |
| hello | * | * | ? |
| world | * | ? | * |
| test1 | * | ? | ? |
| test2 | * | ? | ? |
| test | ? | * | * |
執行全文檢索
"query": {"match": {"search_field": "test"} }結果為 doc2,doc3
聚合操作
doc2: agg1 hello world
doc3: agg2 test hello
正排索引
5.2 doc value 核心原理
正排索引，也會寫入磁盤文件中，然后os cache先進行緩存，以提升訪問doc value正排索引的性能
如果os cache內存大小不足夠放得下整個正排索引，doc value，就會將doc value的數據寫入磁盤文件中。
es官方是建議，es大量是基于os cache來進行緩存和提升性能的，不建議用jvm內存來進行緩存，那樣會導致一定的gc開銷和oom問題。即給jvm更少的內存，給os cache更大的內存。
64g服務器，給jvm最多16g，幾十個g的內存給os cache，os cache可以提升doc value和倒排索引的緩存和查詢效率。
?
提升 doc value 性能之 column壓縮 合并相同值
doc1: 550
doc2: 550
doc3: 500
doc1和doc2都保留一個550的標識即可
disable doc value
如果的確不需要doc value，比如聚合等操作，那么可以禁用，減少磁盤空間占用
PUT my_index12 {"mappings": {"properties": {"my_field": {"type": "keyword","doc_values": false}}} }5.3 ?fielddata 原理
5.3.1 對分詞的field 如何聚合操作
對于分詞的field執行aggregation（聚合操作），發現報錯。。。
GET /test_index/_search {"aggs": {"group_by_test_field": {"terms": {"field": "test_field"}}} }對分詞的field，直接執行聚合操作會報錯，提示說必須要打開fielddata，然后將正排索引數據加載到內存中，才可以對分詞的field執行聚合操作，而且會消耗很大的內存。
給分詞的field，設置fielddata=true
POST /test_index/_mapping {"properties": {"test_field": {"type": "text","fielddata": true}} }測試聚合操作
GET /test_index/_search {"size": 0,"aggs": {"group_by_test_field": {"terms": {"field": "test_field"}}} }如果要對分詞的field執行聚合操作，必須將fielddata設置為true
5.3.2 使用內置field不分詞進行聚合
GET /test_index/_search {"size": 0,"aggs": {"group_by_test_field": {"terms": {"field": "test_field.keyword"}}} }如果對不分詞的field執行聚合操作，直接就可以執行，不需要設置fieldata=true
5.3.3 分詞field+fielddata的工作原理
不分詞的field，可以執行聚合操作 ， 如果你的某個field不分詞，那么在index-time，就會自動生成doc value ，針對這些不分詞的field執行聚合操作的時候，自動就會用doc value來執行。
分詞field，是沒有doc value的。在index-time 是不會給它建立doc value正排索引的，因為分詞后，占用的空間過于大，所以默認是不支持分詞field進行聚合的。所以直接對分詞field執行聚合操作，是會報錯的。
如果一定要對分詞的field執行聚合，那么必須將fielddata=true，然后es就會在執行聚合操作的時候，現場將field對應的數據，建立一份fielddata正排索引，fielddata正排索引的結構跟doc value是類似的，但是只會將fielddata正排索引加載到內存中來，然后基于內存中的fielddata正排索引執行分詞field的聚合操作。
5.4 fielddata 內存控制 & circuit breajer 斷路器
fielddata加載到內存的過程是lazy加載的，對一個analzyed field執行聚合時，才會加載，而且是field-level加載的。它不是index-time創建，是query-time創建。
5.4.1 fielddata內存限制
在配置文件中配置
indices.fielddata.cache.size: 20%，超出限制，清除內存已有fielddata數據
fielddata占用的內存超出了這個比例的限制，那么就清除掉內存中已有的fielddata數據
默認無限制，限制內存使用，但是會導致頻繁evict和reload，大量IO性能損耗，以及內存碎片和gc
5.4.2 監控fielddata內存使用
GET /_stats/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?level=indices&fields=*
5.4.3 circuit breaker
如果一次query load的feilddata超過總內存，就會oom內存溢出
circuit breaker會估算query要加載的fielddata大小，如果超出總內存，就短路，query直接失敗
indices.breaker.fielddata.limit：fielddata的內存限制，默認60%
indices.breaker.request.limit：執行聚合的內存限制，默認40%
indices.breaker.total.limit：綜合上面兩個，限制在70%以內
5.5 原理 fielddata預加載 全局標記
如果真的要對分詞的field執行聚合，那么每次都在query-time現場生產fielddata并加載到內存中來，速度可能會比較慢，我們是不是可以預先生成加載fielddata到內存中來？？？
global ordinal
PUT my_index/_mapping {"properties": {"tags": {"type": "keyword","eager_global_ordinals": false}} }原理解釋
假設：
doc1: status1
doc2: status2
doc3: status2
doc4: status1
有很多重復值的情況，會進行global ordinal標記
status1 --> 0
status2 --> 1
doc1: 0
doc2: 1
doc3: 1
doc4: 0
建立的fielddata也會是這個樣子的，這樣的好處就是減少重復字符串的出現的次數，減少內存的消耗
5.6 原理 bucket 深度優先到廣度優先
我們的數據：
根據演員分桶： ? ? ? ? ? ? 每個演員的評論的數量
根據每個演員電影分桶： 每個演員的每個電影的評論的數量
評論數量排名前10個的演員,每個演員的電影取到評論數量排名前5的電影
{"aggs" : {"actors" : {"terms" : {"field" : "actors","size" : 10,},"aggs" : {"costars" : {"terms" : {"field" : "films","size" : 5}}}}} }默認是 深度優先的方式去執行聚合操作的。它是把所有人的所有電影都查詢出來數據量很大。因此我們要考慮廣度優先，即我們先過濾出評論前10的演員，然后再去查詢他下面的電影，這樣數據少很多。我們要使用一個參數
collect_mode=breadth_first
{"aggs" : {"actors" : {"terms" : {"field" : "actors","size" : 10,"collect_mode" : "breadth_first"},"aggs" : {"costars" : {"terms" : {"field" : "films","size" : 5}}}}} }六 數據建模實戰
6.1 用戶+博客數據建模 應用層join關聯
我們在構造數據模型的時候，還是將有關聯關系的數據，然后分割為不同的實體，類似于關系型數據庫中的模型。
6.1.1 用戶+博客建模
案例背景：博客網站，我們會模擬各種用戶發表各種博客，然后針對用戶和博客之間的關系進行數據建模，同時針對建模好的數據執行各種搜索/聚合的操作
一個用戶對應多個博客，一對多的關系，做了建模
POST website_users/_doc/1 {"name": "小魚兒","email": "xiaoyuer@sina.com","birthday": "1980-01-01" } POST website_blogs/_doc/1 {"title": "我的第一篇博客","content": "這是我的第一篇博客，開通啦！！！","userId": 1 }6.1.2 搜索小魚兒發表的所有博客
GET /website_users/_search {"query": {"term": {"name.keyword": {"value": "小魚兒"}}} }我們一般在java程序里查詢出 userIds 集合 然后再去查詢blog
GET /website_blogs/_search {"query": {"constant_score": {"filter": {"terms": {"userId": [1]}}}} }上面的操作，就屬于應用層的join，在應用層先查出一份數據，然后再查出一份數據，進行關聯
優點：數據不冗余，維護方便
缺點：應用層join，如果關聯數據過多，導致查詢過大，性能很差
6.2 用戶+博客數據建模 冗余數據
用冗余數據，采用文檔數據模型，進行數據建模，實現用戶和博客的關聯
6.2.1 準備數據
冗余數據，就是說，將可能會進行搜索的條件和要搜索的數據，放在一個doc中
POST /website_users/_doc/1 {"name": "小魚兒","email": "xiaoyuer@sina.com","birthday": "1980-01-01" } POST /website_blogs/_doc/1 {"title": "小魚兒的第一篇博客","content": "大家好，我是小魚兒。。。","userInfo": {"userId": 1,"username": "小魚兒"} }6.2.2 冗余用戶數據搜索博客
不需要走應用層的join，先搜一個數據，找到id，再去搜另一份數據
GET /website_blogs/_search {"query": {"term": {"userInfo.username.keyword": {"value": "小魚兒"}}} }優點：性能高，不需要執行兩次搜索
缺點：數據冗余，維護成本高 --> 每次如果你的username變化了，同時要更新user type和blog type
一般來說，對于es這種NoSQL類型的數據存儲來講，都是冗余模式....
6.3 nested object 博客+評論嵌套
冗余數據方式的來建模，其實用的就是object類型，我們這里又要引入一種新的object類型，nested object類型
博客，評論，做的這種數據模型
6.3.1 準備數據
POST website_blogs/_doc/6 {"title": "花無缺發表的一篇帖子","content": "我是花無缺，大家要不要考慮一下投資房產和買股票的事情啊。。。","tags": ["投資","理財"],"comments": [{"name": "小魚兒","comment": "什么股票啊？推薦一下唄","age": 28,"stars": 4,"date": "2016-09-01"},{"name": "黃藥師","comment": "我喜歡投資房產，風，險大收益也大","age": 31,"stars": 5,"date": "2016-10-22"}] }年齡是28歲的黃藥師評論過的博客，搜索
GET website_blogs/_search {"query": {"bool": {"must": [{"match": {"comments.name": "黃藥師"}},{"match": {"comments.age": 28}}]}} }結果顯然是不對的，應該不能查詢到數據才對。
分析 object類型數據結構的底層存儲
{"title": [ "花無缺", "發表", "一篇", "帖子" ],"content": [ "我", "是", "花無缺", "大家", "要不要", "考慮", "一下", "投資", "房產", "買", "股票", "事情" ],"tags": [ "投資", "理財" ],"comments.name": [ "小魚兒", "黃藥師" ],"comments.comment": [ "什么", "股票", "推薦", "我", "喜歡", "投資", "房產", "風險", "收益", "大" ],"comments.age": [ 28, 31 ],"comments.stars": [ 4, 5 ],"comments.date": [ 2016-09-01, 2016-10-22 ] }object類型底層數據結構，會將一個json數組中的數據，進行扁平化
所以，直接命中了這個document，name=黃藥師，age=28，正好符合
6.3.2 nested object 按對象拆分扁平化數據
修改mapping，將comments的類型從object設置為nested
DELETE website_blogs PUT /website_blogs {"mappings": {"properties": {"comments": {"type": "nested","properties": {"name": {"type": "text"},"comment": {"type": "text"},"age": {"type": "short"},"stars": {"type": "short"},"date": {"type": "date"}}}}} }插入數據
POST website_blogs/_doc/6 {"title": "花無缺發表的一篇帖子","content": "我是花無缺，大家要不要考慮一下投資房產和買股票的事情啊。。。","tags": ["投資","理財"],"comments": [{"name": "小魚兒","comment": "什么股票啊？推薦一下唄","age": 28,"stars": 4,"date": "2016-09-01"},{"name": "黃藥師","comment": "我喜歡投資房產，風，險大收益也大","age": 31,"stars": 5,"date": "2016-10-22"}] }他的數據結構，就不是那么扁平化了
{"comments.name": [ "小魚兒" ],"comments.comment": [ "什么", "股票", "推薦" ],"comments.age": [ 28 ],"comments.stars": [ 4 ],"comments.date": [ 2014-09-01 ] } {"comments.name": [ "黃藥師" ],"comments.comment": [ "我", "喜歡", "投資", "房產", "風險", "收益", "大" ],"comments.age": [ 31 ],"comments.stars": [ 5 ],"comments.date": [ 2014-10-22 ] } {"title": [ "花無缺", "發表", "一篇", "帖子" ],"body": [ "我", "是", "花無缺", "大家", "要不要", "考慮", "一下", "投資", "房產", "買", "股票", "事情" ],"tags": [ "投資", "理財" ] }再次搜索，成功了
GET website_blogs/_search {"query": {"bool": {"must": [{"match": {"title": "花無缺"}},{"nested": {"path": "comments","query": {"bool": {"must": [{"match": {"comments.name": "黃藥師"}},{"match": {"comments.age": 31}}]}}}}]}} }6.3.3 nested object的聚合分析
聚合數據分析的需求1：按照評論日期進行bucket劃分，然后拿到每個月的評論的評分的平均值
GET website_blogs/_search {"size": 0,"aggs": {"comments_path": {"nested": {"path": "comments"},"aggs": {"group_by_comments_date": {"date_histogram": {"field": "comments.date","calendar_interval": "month","format": "yyyy-MM"},"aggs": {"avg_stars": {"avg": {"field": "comments.stars"}}}}}}} }根據年齡和tag 劃分
GET website_blogs/_search {"size": 0,"aggs": {"comments_path": {"nested": {"path": "comments"},"aggs": {"group_by_comments_age": {"histogram": {"field": "comments.age","interval": 10},"aggs": {"reverse_path": {"reverse_nested": {},"aggs": {"group_by_tags": {"terms": {"field": "tags.keyword"}}}}}}}}} }6.4 ?parent child join
nested object的建模，有個不好的地方，就是采取的是類似冗余數據的方式，將多個數據都放在一起了，維護成本就比較高
parent child建模方式，采取的是類似于關系型數據庫的三范式類的建模，多個實體都分割開來，每個實體之間都通過一些關聯方式，進行了父子關系的關聯，各種數據不需要都放在一起，父doc和子doc分別在進行更新的時候，都不會影響對方。
一對多關系的建模，維護起來比較方便，而且我們之前說過，類似關系型數據庫的建模方式，應用層join的方式，會導致性能比較差，因為做多次搜索。父子關系的數據模型，不會，性能很好。因為雖然數據實體之間分割開來，但是我們在搜索的時候，由es自動為我們處理底層的關聯關系，并且通過一些手段保證搜索性能。
父子關系數據模型，相對于nested數據模型來說，優點是父doc和子doc互相之間不會影響
要點：父子關系元數據映射，用于確保查詢時候的高性能，但是有一個限制，就是父子數據必須存在于一個shard中
父子關系數據存在一個shard中，而且還有映射其關聯關系的元數據，那么搜索父子關系數據的時候，不用跨分片，一個分片本地自己就搞定了，性能當然高咯
案例背景：研發中心員工管理案例，一個IT公司有多個研發中心，每個研發中心有多個員工
6.5 ?類似文件系統多層級關系數據建模
path_hierarchy tokenizer 也就是：/a/b/c/d --> path_hierarchy -> /a/b/c/d, /a/b/c, /a/b, /a
6.5.1 準備數據
創建分詞器
PUT /fs {"settings": {"analysis": {"analyzer": {"paths": {"tokenizer": "path_hierarchy"}}}} }設置mapping
PUT /fs/_mapping {"properties": {"name": {"type": "keyword"},"path": {"type": "keyword","fields": {"tree": {"type": "text","analyzer": "paths"}}}} }插入數據
POST /fs/_doc/1 {"name": "README.txt","path": "/workspace/projects/helloworld","contents": "這是我的第一個elasticsearch程序" }6.5.2 對文件系統執行搜索
文件搜索需求：查找一份，內容包括elasticsearch，在/workspace/projects/hellworld這個目錄下的文件
GET /fs/_search {"query": {"bool": {"must": [{"match": {"contents": "elasticsearch"}},{"constant_score": {"filter": {"term": {"path": "/workspace/projects/helloworld"}}}}]}} }搜索需求2：搜索/workspace目錄下，內容包含elasticsearch的所有的文件
GET /fs/_search {"query": {"bool": {"must": [{"match": {"contents": "elasticsearch"}},{"constant_score": {"filter": {"term": {"path.tree": "/workspace"}}}}]}} }6.6 全局鎖+悲觀鎖 并發控制
第一種鎖：全局鎖，直接鎖掉整個fs index,此時就只有你能執行各種各樣的操作了，其他人不能執行操作
PUT /fs/_doc/global/_create {}fs: 你要上鎖的那個index
lock: 就是你指定的一個對這個index上全局鎖的一個type
global: 就是你上的全局鎖對應的這個doc的id
_create：強制必須是創建，如果/fs/lock/global這個doc已經存在，那么創建失敗，報錯
POST fs/_update/1 {"doc": {"name": "README1.txt"} }刪除鎖? ?DELETE /fs/_doc/global
優點：操作非常簡單，非常容易使用，成本低
缺點：你直接就把整個index給上鎖了，這個時候對index中所有的doc的操作，都會被block住，導致整個系統的并發能力很低
6.7 ?document+ 悲觀鎖
document鎖，顧名思義，每次就鎖你要操作的，你要執行增刪改的那些doc，doc鎖了，其他線程就不能對這些doc執行增刪改操作了，但是你只是鎖了部分doc，其他線程對其他的doc還是可以上鎖和執行增刪改操作的。
document鎖，是用腳本進行上鎖
POST _scripts/document-lock {"script": {"lang": "painless","source": "if ( ctx._source.process_id != params.process_id ) { Debug.explain('already locked by other thread'); } ctx.op = 'noop';"} }POST /fs/_update/1 {"upsert": {"process_id": "123"},"script": {"id": "document-lock","params": {"process_id": "123"}} }DELETE /fs/_doc/1PUT /fs/_doc/_bulk { "delete": { "_id": 1}}update+upsert操作，如果該記錄沒加鎖（此時document為空），執行upsert操作，設置process_id，如果已加鎖，執行script
script內的邏輯是：判斷傳入參數與當前doc的process_id，如果不相等，說明有別的線程嘗試對有鎖的doc進行加鎖操作，Debug.explain表示拋出一個異常。
process_id可以由Java應用系統里生成，如UUID。
如果兩個process_id相同，說明當前執行的線程與加鎖的線程是同一個，ctx.op = 'noop'表示什么都不做，返回成功的響應，Java客戶端拿到成功響應的報文，就可以繼續下一步的操作，一般這里的下一步就是執行事務方法。
POST /fs/_update/1 {"doc": {"name": "README1.txt"} }6.8 共享鎖&排它鎖 并發控制
共享鎖：這份數據是共享的，然后多個線程過來，都可以獲取同一個數據的共享鎖，然后對這個數據執行讀操作
排他鎖：是排他的操作，只能一個線程獲取排他鎖，然后執行增刪改操作
如果只是要讀取數據的話，那么任意個線程都可以同時進來然后讀取數據，每個線程都可以上一個共享鎖
但是這個時候，如果有線程要過來修改數據，那么會嘗試加上排他鎖，排他鎖會跟共享鎖互斥，也就是說，如果有人已經上了共享鎖了，那么排他鎖就不能上。即 如果有人在讀數據，就不允許別人來修改數據。反之，也是一樣的。
6.8.1 共享鎖
POST _scripts/shared-lock {"script": {"lang": "painless","source": "if (ctx._source.lock_type == 'exclusive') { Debug.explain('already locked'); } ctx._source.lock_count++"} }POST /fs/_update/1 {"upsert": {"lock_type": "shared","lock_count": 1},"script": {"id": "shared-lock"} }GET /fs/_doc/1上共享鎖，你還是要上共享鎖，直接上就行了，沒問題，只是lock_count加1。
6.8.2 排他鎖
排他鎖用的不是upsert語法，create語法，要求lock必須不能存在，直接自己是第一個上鎖的人，上的是排他鎖
PUT /fs/_create/1 { "lock_type": "exclusive" }如果已經有人上了共享鎖，create語法去上排他鎖，肯定會報錯
6.9.3 對共享鎖進行解鎖
POST _scripts/unlock-shared {"script": {"lang": "painless","source": "if (--ctx._source.lock_count == 0) {ctx.op='delete'}" } }POST /fs/_update/1 {"script": {"id": "unlock-shared"} }每次解鎖一個共享鎖，就對lock_count先減1，如果減了1之后，是0，那么說明所有的共享鎖都解鎖完了，此時就就將/fs/_doc/1刪除，就徹底解鎖所有的共享鎖
總結
以上是生活随笔為你收集整理的Elasticsearch 7.7.0 高阶篇-聚合技术的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 太原计算机短期培训,计算机短期培训课计划
- 下一篇： 人民币大写的正确写法（开票据事项）