业务模块中基本上都是聚合查询操作，不需要过滤的都用上字段折叠，性能能跟上
而频繁过车，昼伏夜出，多区域碰撞，要用到聚合和having pipeline Aggs 性能一直起不来。
三百万的数据聚合要3到4秒，一亿的数据聚合要15到30秒的时间，完全达不到性能要求。
强制合并段后，执行_forcemerge 线程跑完后，段并未完全合并成功，一段时间后（可能一到两天比较诡异），段合并后，搜索性能明显提升。三百万的数据聚合只需要700ms左右，1亿的数据也就2-3秒左右。
http://192.168.102.200:9200/_nodes/192.168.102.200/hot_threads
http://192.168.102.200:9200/_cat/segments/?v&h=shard,segment,size,size.memory
curl -XPOST "http://192.168.102.202:9200/*/_forcemerge?max_num_segments=1"
实时搜索的实现
https://www.elastic.co/guide/cn/elasticsearch/guide/current/inside-a-shard.html
持久化变更
https://www.elastic.co/guide/cn/elasticsearch/guide/current/near-real-time.html
段合并
https://www.elastic.co/guide/cn/elasticsearch/guide/current/merge-process.html
Elasticsearch 基于 Lucene, 这个 java 库引入了 按段搜索 的概念。 每一 段 本身都是一个倒排索引， 但 索引 在 Lucene 中除表示所有 段 的集合外， 还增加了 提交点 的概念 — 一个列出了所有已知段的文件，就像在 图 1 “一个 Lucene 索引包含一个提交点和三个段” 中描绘的那样。 如 图 2 “一个在内存缓存中包含新文档的 Lucene 索引” 所示，新的文档首先被添加到内存索引缓存中，然后写入到一个基于磁盘的段，如 图 4 “在一次提交后，一个新的段被添加到提交点而且缓存被清空。”
图 1. 一个 Lucene 索引包含一个提交点和三个段
图 2. 一个在内存缓存中包含新文档的 Lucene 索引
图 3. 缓冲区的内容已经被写入一个可被搜索的段中，但还没有进行提交
图 4.一次提交后，一个新的段被添加到提交点而且缓存被清空
图 5. 新的文档被添加到内存缓冲区并且被追加到了事务日志
图 6.刷新（refresh）完成后, 缓存被清空但是事务日志不会
图 7.事务日志不断积累文档
图 8. 在刷新（flush）之后，段被全量提交，并且事务日志被清空
图 9. 两个提交了的段和一个未提交的段正在被合并到一个更大的段
图 10. 一旦合并结束，老的段被删除
