为了更好地理解与排版，部分文章标题可能会有修改
降序记录
- eBay Elasticsearch 性能优化实战-中文篇
-
number?keyword?傻傻分不清楚
---- 数值类型(number)的数据结构变成Block k-d tree
---- query/filter执行顺序不是按照写入顺序，而是内部根据cost()估算每个查询的代价，选择代价最低的query/filter开始，在其圈定的docid集合上生成一个迭代器
----indexOrDocValuesQuery对rangeQuery的优化
------ Rang查询的数据集大小，以及要做的合并操作类型，决定用哪种Query。 如果Range的代价小，可以用来引领合并过程，就走PointRangeQuery，直接构造bitset来进行迭代
------ 如果range的代价高，构造bitset太慢，就使用SortedSetDocValuesRangeQuery，利用DocValues的全局docID序，并包含每个docid对应value的数据结构来做文档的匹配 -
elasticsearch 集群启动流程
---- node级别
------ 主节点选举，节点数>=N/2+1，max节点ID
------ 集群元信息选举，主节点先收集，merge之后再将metadata下发到各节点
---- shard级别
------ 主分片选举，master汇总所有节点的shard信息后，选取一个main shard
------ 副分片分配，master从汇总shard信息中选取一个
------ 主分片recovery，disk segment && replay translog
------ 副分片recovery，copy from main shard && translog && 分片完整性和版本数据一致性 -
Bulk异常引发的Elasticsearch内存泄漏
---- jvm，heap dump内存分析，Eclipse MAT，Log4j -
一例Query Cache引起的性能问题分析
---- node query cache分析过程 访问倒排->heap开始缓存bitmap->hit cached bitmap
---- term filter足够快，es去掉了term的cache
---- range filter，如果精确到秒级别，那么hit bitmap每秒都在变，hit cached一直被LRU，所以可以降低range的精度，比如精确到小时级别 -
使用es做搜索，真假柠檬排序之争
---- 有时候问题在大规模数据下不能正常运行，这回反过来在小数据集上有问题，让自己意识到这个relevance score问题，从而促使自己记录了一个关于排序分的文章 -
谈谈ES的Recovery
---- shard级别，es node重启、更新，synced flush ID，replay transLog -
记一次es性能调优
---- gc, index filter cache, refresh_interval -
关于es缓存
---- node query cache，
---- shard request cache
---- fielddata cache
---- system cache
---- global ordinals -
Elasticsearch JVM Heap Size大于32G，有什么影响？
---- es heap Zero Based Compressed OOPS -
ES内存那点事
---- lucence倒排生成过程 es heap->disk->system cache
---- segment memory(倒排索引之上的又一层索引）
---- es缓存
---- 超大规模集群的状态信息
---- 大聚合的结果集query-fetch
