ES内部压缩方案
倒排列表 - postings list 的POR压缩(<font color="#c41230">类似跳表</font>)
Filter cache 的RBM压缩(<font color="#c41230">位图</font>)
分片策略
分片数设置
<font color="#0076b3">1. 每个分片占用的硬盘容量不超过ES的最大JVM的堆空间设置（一般设置不超过32G)</font><br>预估索引的容量设置分片数, 例如320G的索引容量则至少需要10个分片
<font color="#0076b3">2. 分片数不超过节点数的3倍</font>
<font color="#c41230">推迟副本分片分配</font>
默认情况，集群会等待一分钟来查看节点是否会重新加入<br><br>通过修改参数 delayed_timeout ，可以延长再均衡的时间<br>
索引优化
1. 尽量<font color="#c41230">避免使用nested或 parent/child Mapping</font>类型
2. 如果一定要使用nested fields，<font color="#c41230">保证nested fields字段不能过多</font>，目前ES默认限制是50
3. 控制索引的字段数量、mapping深度、索引字段的类型
4. 不需要做模糊检索的字段<font color="#c41230">使用 keyword类型代替 text 类型</font>，这样可以避免在建立索引前对这些文本进行分词
5. 对于那些不需要聚合和排序的索引字段<font color="#c41230">禁用Doc values</font>
查询效率
1. 使用<font color="#c41230">批量请求</font>，批量索引的效率肯定比单条索引的效率要高
2. query_string 或 multi_match 的查询字段越多， 查询越慢。<br>可以在 mapping 阶段，利用 <font color="#0076b3">copy_to</font> 属性将多字段的值索引到一个新字段，multi_match时，用新的字段查询。<br>
3. <font color="#c41230">日期字段的查询， 尤其是用now 的查询实际上是不存在缓存的</font>，因此， 可以从业务的角度来考虑是否一定要用now, 毕竟利用 query cache 是能够大大提高查询效率的。
4. <font color="#c41230">查询结果集的大小(分页深度)</font>不能随意设置成大得离谱的值， 如query.setSize不能设置成 Integer.MAX_VALUE， 因为ES内部需要建立一个数据结构来放指定大小的结果集数据。
5. 避免层级过深的聚合查询， 层级过深的group by , 会导致内存、CPU消耗，建议在服务层通过程序来组装业务，也可以通过pipeline 的方式来优化。
6. cache的设置+使用
filter查询(<font color="#c41230">QueryCache</font>)
1. QueryCache 是<font color="#c41230">节点级别</font>的，每个节点上的所有分片共享一份缓存
2. Query Cache只能在Filter Context中被使用
3. Query Cache实际缓存的是<font color="#c41230">Bitset（位图）</font>，<font color="#0076b3">一个Query clause对应一个Bitse</font>t
4. 缓存要生效，必须满足两个条件
查询对应的segments所持有的文档数必须<font color="#c41230">大于10000</font>
查询对应的segments所持有的文档数必须<font color="#c41230">大于整个索引size的3%</font>
5. 当新索引文档时，<font color="#c41230">Query Cache不会重新计算，而是判断索引的文档是否符合缓存对应的Query clause，满足则加入BitSet中</font>
聚类或排序(<font color="#c41230">FieldDataCache</font>)
ShardRequestCache
