倒排索引是我們所熟知的，正排索引是什么，es還用到這個？當我們在很多數據中查詢某些內容時，倒排索引會一個一個的去遍歷完所有的倒排索引“表”然后再分組聚合，但是也許在前面的搜索中以及找到了我們想要的結果只是倒排索引不知道，這樣顯示不是很好，為了應對這種情況，正排索引閃亮登場！
正排索引：
doc value 的數據結構，核心原理同倒排索引，寫入磁盤文件、os cache進行緩存（提升服務正排索引的性能），如果os cache不夠用了就將其中的數據寫入磁盤文件
關於性能優化問題有很多方案，這里jvm更少的內存
es基於os cache進行緩存、提升性能，不是很建議使用jvm內存進行緩存（導致gc開銷、oom問題），所以給jvm更少的內存，給os cache更大的內存，這樣可以提升正排索引和倒排索引的緩存及查詢效率。
colum壓縮
1、相同的value：合並、保留一個標識
所有的值相同，保留一個值、小於256個值，使用table encoding模式、大於256個值如有公約數即除以最大公約數並保留 沒有則用offset結合壓縮
禁用:
不需要正排索引，禁用減少磁盤空間的占用
PUT my_index { "mappings": { "my_type": { "properties": { "my_field": { "type": "keyword"
"doc_values": false } } } } }
對於分詞的field進行聚合（aggregation）操作，需要將fielddata設置為true，否則會報錯提示你打開fielddata、將正排索引加載到內存中
不分詞的field會在index-time時生成正排索引，這樣聚合時直接使用正排索引
而分詞的field在創建索引時是沒有正排索引的（doc value）直接聚合報錯，需要打開fielddata，然后es在執行聚合時現場建立正排索引，將fielddata正排索引加載到內存，基於內存的正排索引執行分詞field的聚合操作，可以看出這樣會耗費內存空間，那為什么要占用大量內存吶？分詞的字符串需要安裝term進行聚合，進而執行復雜的算法和操作，如果基於磁盤和os cache的話性能會比較差，顯然性能和內存選擇了性能。