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

降序记录

• 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