【Elasticsearch】正排索引、倒排索引——笔记

倒排索引是我们所熟知的，正排索引是什么，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的话性能会比较差，显然性能和内存选择了性能。