为什么使用ES？
在百万级别的数据库中，如果有全表扫描或者接近全表扫描的语句，用MySQL时间会非常长，有时候还会查不出来（创意投放管理页面，你要用id或者创意名称查，根本查不出来）。
ES对模糊查询和聚合查询的支持比MySQL更好，大数据量是比MySQL更快。
同一个索引Index（table）中，可以插入任意类型的文档document（记录）。扩展性比MySQL好很多。
ES的主要术语如下：
- Index：Elasticsearch的Index相当于数据库的Table
- Type：这个在新的Elasticsearch版本已经废除（在以前的Elasticsearch版本，一个Index下支持多个Type--有点类似于消息队列一个topic下多个group的概念）
- Document：Document相当于数据库的一行记录
- Field：相当于数据库的Column的概念
- Mapping：相当于数据库的Schema的概念
- DSL：相当于数据库的SQL（给我们读取Elasticsearch数据的API）
ES调优知道怎么调吗？
- 写入调优
1、写入前副本数设置为 0；
2、写入前关闭 refresh_interval 设置为-1， 禁用刷新机制；
3、写入过程中： 采取 bulk 批量写入；
4、写入后恢复副本数和刷新间隔；
5、尽量使用自动生成的 id。
- 查询调优
1、禁用 wildcard；
2、禁用批量 terms（ 成百上千的场景）；
3、充分利用倒排索引机制， 能 keyword 类型尽量 keyword；
4、数据量大时候， 可以先基于时间敲定索引再检索；
5、设置合理的路由机制。
倒排索引
在写入数据时ES会进行分词，使用ik分词器。ES中根据某个词来查找对应的记录，这种结构称为倒排索引。
分词器的介绍：
倒排索引的结构： 通过分词，形成了词和文档的映射关系，这种字典term dict + 映射表（文档id数组）的机构即倒排索引。
Term index 词前缀，存在内存中—Term Dict 存放所用词—PostingList 存放记录的文档id。
Term index是一颗tire树
ElasticSearch中的text和keyword的区别：
Master如何选举
集群-索引-分片
ES 路由机制
ES检索（查询）过程
1、搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
2、在初始查询阶段时，查询会被广播到索引中每一个分片拷贝（主分片或者副本分 片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的 优先队列。 PS：在搜索的时候是会查询 Filesystem Cache 的，但是有部分数据还在 Memory Buffer，所以搜索是近实时的。
3、每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并 这些值到自己的优先队列中来产生一个全局排序后的结果列表。
4、接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片 提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回 文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
5、补充：Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分 片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch 增 加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更准确， 但是性能会变差。
（二）match过程，底层是多个上述term过程？？
相关性：www.elastic.co/guide/cn/el…
ES增删改过程
我们向Elasticsearch写入数据的时候，是写到主分片上的。客户端写入一条数据，到Elasticsearch集群里边就是由节点来处理这次请求。
集群上的每个节点都是coordinating node（协调节点），协调节点表明这个节点可以做路由。比如节点1接收到了请求，但发现这个请求的数据应该是由节点2处理（因为主分片在节点2上），所以会把请求转发到节点2上。
路由到对应的节点以及对应的主分片时，会做以下的事：
1、兵分两路，一路写内存缓冲区，1s后同步到文件系统缓冲区。 2、另一路写translog日志缓冲区，每5s同步到磁盘中的translog中。 3、日志要满或者超过了30分钟，就会协同文件系统缓冲区，一起写道磁盘中。
解释一下这个过程，会有持久化，以及会涉及数据丢失：
ES中删除和更新的过程，是一致的：
ES并发问题
ES亿级数据聚合查询
ES聚合有多种类型，其中皓月用到的是两种：指标聚合和桶聚合。
真的看这一篇就可以了 www.cnblogs.com/leeSmall/p/…
