# 倒排和正排索引
## 1\. 正排(doc value)與倒排
> 搜索的時候,要依靠倒排索引;排序的時候,需要依靠正排索引,看到每個document的每個field,然后進行排序,所謂的正排索引,其實就是doc values
> 在建立索引的時候,一方面會建立倒排索引,以供搜索用;一方面會建立正排索引,也就是doc values,以供排序,聚合,過濾等操作使用
> 正排索引:
>
> 1. 如果你的某個field設置為不分詞,那么在建立索引的時候(index-time),就會自動生成doc value
> 2. doc value(正排索引):
> 是被保存在磁盤上的,此時如果內存足夠,os會自動將其緩存在內存中,性能還是會很高;如果內存不足夠,os會將其寫入磁盤上
~~~
doc1: hello world you and me
doc2: hi, world, how are you
~~~
> 倒排索引:數據-文檔的二維矩陣
~~~
word doc1 doc2
hello *
world * *
you * *
and *
me *
hi *
how *
are *
~~~
> 例如搜索hello you,搜索語句會按照index中對應的field的分詞器進行分詞
> hello you --> hello, you
~~~
hello --> doc1
you --> doc1,doc2
~~~
~~~
doc1: hello world you and me
doc2: hi, world, how are you
~~~
> 正排索引
~~~
doc1: { "name": "jack", "age": 27 }
doc2: { "name": "tom", "age": 30 }
~~~
> 文檔-數據的二維矩陣
~~~
document name age
doc1 jack 27
doc2 tom 30
~~~
> 例如通過age排序,方便排序
## 2\. 對于分詞的field進行聚合
* 正常情況下,是不可以對分詞的field進行聚合的
~~~
PUT myindex/test/1
{
"name":"dailin"
}
~~~
聚合測試
~~~
GET myindex/_search
{
"size": 0,
"aggs": {
"groupby_name": {
"terms": {
"field": "name"
}
}
}
}
~~~
報錯
~~~
"reason": "Fielddata is disabled on text fields by default. Set fielddata=true on [name] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead."
~~~
Fielddata默認是關閉的,必須要打開fielddata,然后將正排索引數據加載到內存中,才可以對分詞的field執行聚合操作,而且會消耗很大的內存。
如果對分詞的field進行聚合,有以下幾種方法
1. 對應field的Fielddata設置成true
首先設置mapping
~~~
POST myindex/_mapping/test
{
"properties": {
"name":{
"type": "text",
"fielddata": true
}
}
}
~~~
再次聚合
~~~
GET myindex/_search
{
"size": 0,
"aggs": {
"groupby_name": {
"terms": {
"field": "name"
}
}
}
}
~~~
成功
~~~
"aggregations": {
"groupby_name": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "dailin",
"doc_count": 1
}
]
}
}
}
~~~
2. 使用分詞field的keyword子field
5.X版本以后,es默認會為每個textfield生成一個keyword(不分詞),我們可以利用這個field聚合
* 查看mapping
`GET myindex/_mapping`
~~~
"name": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword", # 生成一個不分詞的子field
"ignore_above": 256
}
}
~~~
* 聚合測試
~~~
GET myindex/_search
{
"size": 0,
"aggs": {
"groupby_name": {
"terms": {
"field": "name.keyword"
}
}
}
}
~~~
同樣得到一樣的結果
> 1. 如果一定要對分詞的field執行聚合,那么必須將fielddata=true,然后es就會在執行聚合操作的時候,現場將field對應的數據,建立一份fielddata正排索引,fielddata正排索引的結構跟doc value是類似的,但是只會講fielddata正排索引加載到內存中來,然后基于內存中的fielddata正排索引執行分詞field的聚合操作
> 2. fielddata加載到內存的過程是lazy加載的,對一個analzyed field執行聚合時,才會加載,而且是field-level加載的一個index的一個field,所有doc都會被加載,而不是少數doc不是index-time創建,是query-time創建
> 3. 監控fielddata內存使用
~~~
# 各個分片的fiedata內存占用情況
GET /_stats/fielddata?fields=*
# 各個node的fielddata的內存占用情況
GET /_nodes/stats/indices/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?level=indices&fields=*
~~~
> 4. circuit breaker(fielddata內存使用控制)
~~~
如果一次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%以內
~~~
### fielddata預加載
如果真的要對分詞的field執行聚合,那么每次都在query-time現場生產fielddata并加載到內存中來,速度可能會比較慢
我們是不是可以預先生成加載fielddata到內存中來???
1. fielddata預加載
~~~
POST /test_index/_mapping/test_type
{
"properties": {
"test_field": {
"type": "string",
"fielddata": {
"loading" : "eager"
}
}
}
}
~~~
query-time的fielddata生成和加載到內存,變為index-time,建立倒排索引的時候,會同步生成fielddata并且加載到內存中來,這樣的話,對分詞field的聚合性能當然會大幅度增強
2. 序號標記預加載
global ordinal原理解釋
~~~
doc1: status1
doc2: status2
doc3: status2
doc4: status1
~~~
有很多重復值的情況,會進行global ordinal標記
~~~
status1 --> 0
status2 --> 1
doc1: 0
doc2: 1
doc3: 1
doc4: 0
~~~
建立的fielddata也會是這個樣子的,這樣的好處就是減少重復字符串的出現的次數,減少內存的消耗
~~~
POST /test_index/_mapping/test_type
{
"properties": {
"test_field": {
"type": "string",
"fielddata": {
"loading" : "eager_global_ordinals"
}
}
}
}
~~~
- springcloud
- springcloud的作用
- springboot服務提供者和消費者
- Eureka
- ribbon
- Feign
- feign在微服務中的使用
- feign充當http請求工具
- Hystrix 熔斷器
- Zuul 路由網關
- Spring Cloud Config 分布式配置中心
- config介紹與配置
- Spring Cloud Config 配置實戰
- Spring Cloud Bus
- gateway
- 概念講解
- 實例
- GateWay
- 統一日志追蹤
- 分布式鎖
- 1.redis
- springcloud Alibaba
- 1. Nacos
- 1.1 安裝
- 1.2 特性
- 1.3 實例
- 1. 整合nacos服務發現
- 2. 整合nacos配置功能
- 1.4 生產部署方案
- 環境隔離
- 原理講解
- 1. 服務發現
- 2. sentinel
- 3. Seata事務
- CAP理論
- 3.1 安裝
- 分布式協議
- 4.熔斷和降級
- springcloud與alibba
- oauth
- 1. abstract
- 2. oauth2 in micro-service
- 微服務框架付費
- SkyWalking
- 介紹與相關資料
- APM系統簡單對比(zipkin,pinpoint和skywalking)
- server安裝部署
- agent安裝
- 日志清理
- 統一日志中心
- docker安裝部署
- 安裝部署
- elasticsearch 7.x
- logstash 7.x
- kibana 7.x
- ES索引管理
- 定時清理數據
- index Lifecycle Management
- 沒數據排查思路
- ELK自身組件監控
- 多租戶方案
- 慢查詢sql
- 日志審計
- 開發
- 登錄認證
- 鏈路追蹤
- elk
- Filebeat
- Filebeat基礎
- Filebeat安裝部署
- 多行消息Multiline
- how Filebeat works
- Logstash
- 安裝
- rpm安裝
- docker安裝Logstash
- grok調試
- Grok語法調試
- Grok常用表達式
- 配置中常見判斷
- filter提取器
- elasticsearch
- 安裝
- rpm安裝
- docker安裝es
- 使用
- 概念
- 基礎
- 中文分詞
- 統計
- 排序
- 倒排與正排索引
- 自定義dynamic
- 練習
- nested object
- 父子關系模型
- 高亮
- 搜索提示
- kibana
- 安裝
- docker安裝
- rpm安裝
- 整合
- 收集日志
- 慢sql
- 日志審計s
- 云
- 分布式架構
- 分布式鎖
- Redis實現
- redisson
- 熔斷和降級