为了更好地理解与排版，部分文章标题可能会有修改

降序记录

• 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