ElasticSearch
Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。 它能很方便的使大量数据具有搜索、分析和探索的能力。
应用场景
- 日志记录和分析
- 采集和组合公共数据
- 全文检索
- 数据可视化
倒排索引
倒排索引：以关键词作为key，包含关键词的文档作为Value
假设我们有两个文档，都有一个content字段
doc_1：The quick brown fox jumped over the lazy dog
doc_2：Quick brown foxes jump over lazy dogs in summer
首先在es底层分词器会对doc进行分词，得到一个个term（单词），然后建立一个映射关系，记录存在各个单词的文档。首先我们分析一下各个单词存在的文档。
因为每个doc都是id唯一标识的，所以会简历一个映射关系。
当es建立了这种映射关系，当我们搜索一个单词的时候，就不需要遍历每个文档了。而且es的倒排索引进行term优化，比如说大小写转换、近义词转换、时态转换、单复数转换等等。
1 | 1 大小写转换：Quick --> quick |
当es进行了term优化后，上面的倒排索引就变成了
每一个文档都对应一个ID。倒排索引会按照指定语法对每一个文档进行分词，然后维护一张表，列举所有文档中出现的terms以及它们出现的文档ID和出现频率。搜索时同样会对关键词进行同样的分词分析，然后查表得到结果。
假设有下列几条数据：
ID Name Age Sex
1 Kate 24 Female
2 John 24 Male
3 Bill 29 Male
ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下：
Name:
Term Posting List
Kate 1
John 2
Bill 3
Age:
Term Posting List
24 [1,2]
29 3
Sex:
Term Posting List
Female 1
Male [2,3]
Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而 [1,2] 就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。通过posting list这种索引方式可以很快进行查找，比如要找age=24的人。
Term Dictionary
Elasticsearch为了能快速找到某个term，将所有的term排序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。类似于传统数据库的B-Tree的，但是Term Dictionary较B-Tree的查询快。
Term Index
B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些，term，分别在哪页，term index其实是一颗 (trie) 前缀树
这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。
所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。
假设我们现在要将mop, moth, pop, star, stop, top (term index里的term前缀) 映射到序号：0，1，2，3，4，5 (term dictionary的block位置)。最简单的做法就是定义个Map，大家找到自己的位置取值即可，但从内存占用少的角度考虑，FST更节省空间。
基本概念
集群：es是分布式的，由多个节点构成集群
节点：一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。
ES集群中的节点有三种不同的类型：
- 主节点：负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 主节点并不需要涉及到文档级别的变更和搜索等操作。可以通过属性node.master进行设置。
- 数据节点：存储数据和其对应的倒排索引。默认每一个节点都是数据节点（包括主节点），可以通过node.data属性进行设置。
- 协调节点：如果node.master和node.data属性均为false，则此节点称为协调节点，用来响应客户请求，均衡每个节点的负载。
一个节点不等于一台服务器
索引：ES将数据存储在一个或者多个索引中，索引相当于SQL中的一个数据库。索引由其名称(必须为全小写字符)进行标识，并通过引用此名称完成文档的创建、搜索、更新及删除操作。一个ES集群中可以按需创建任意数目的索引。
类型：类型是索引内部的逻辑分区(category/partition)，其意义完全取决于用户需求。因此，一个索引内部可定义一个或多个类型(type)。例如，在索引中，可以定义一个用于存储用户数据的类型，一个存储日志数据的类型，以及一个存储评论数据的类型。类比传统的关系型数据库领域来说，类型相当于 “表” 。
Elasticsearch：index –> type –> doc –> field
MySQL: 数据库 –> 数据表 –> 行 –> 列
为什么在ES 7.X中去除了类型这个概念？
原因
因为 Elasticsearch 设计初期，是直接查考了关系型数据库的设计模式，存在了 type（数据表）的概念。但是，其搜索引擎是基于 Lucene 的，这种 “基因” 决定了 type 是多余的。 Lucene 的全文检索功能之所以快，是因为 倒排索引 的存在。而这种倒排索引的生成是基于 index 的，而并非 type。多个type 反而会减慢搜索的速度。为了保持 Elasticsearch “一切为了搜索” 的宗旨，适当的做些改变（去除 type）也是无可厚非的，也是值得的。
为何不是在 6.X 版本开始就直接去除 type，而是要逐步去除type？
因为历史原因，前期 Elasticsearch 支持一个 index 下存在多个 type的，而且，有很多项目在使用 Elasticsearch 作为数据库。如果直接去除 type 的概念，不仅是很多应用 Elasticsearch 的项目将面临 业务、功能和代码的大改，而且对于 Elasticsearch 官方来说，也是一个巨大的挑战（这个是伤筋动骨的大手术，很多涉及到 type 源码是要修改的）。所以，权衡利弊，采取逐步过渡的方式，最终，推迟到 7.X 版本才完成 “去除 type” 这个 革命性的变革。
文档（Document）
文档是索引和搜索的原子单位，它是包含了一个或多个域（Field，列字段）的容器，基于JSON格式进行表示。文档由一个或多个域组成，每个域拥有一个名字及一个或多个值，有多个值的域通常称为 “多值域” 。每个文档可以存储不同的域集，但同一类型下的文档至应该有某种程度上的相似之处。
document路由原理（一个index会分为多个分片，因此涉及到document存到哪个分片上的问题）
①路由算法：shard = hash(routing) % number_of_primary_shards
②决定一个document在哪个shard上，最重要的一个值就是routing值，默认是_id，也可手动指定，相同的routing值，每次过来，从hash函数中，产出的hash值一定是相同的
例：手动指定一个routing value，比如 put /index/type/id?routing=user_id
③这就是primary shard数量不可变的原因（通过路由算法存放一个数据后，假设有3个primary_shards，然后hash(routing)=21，那么shard=0，所以数据被存放到P0，如果此时添加一个primary_shards，我们想要获取刚才加入的这个数据，此时再使用路由算法，算出来shard=21%4=1，但在P1找不到这个数据，间接的导致数据丢失）。分片：
一个索引中的数据保存在多个分片中，相当于水平分表。一个分片便是一个Lucene 的实例，它本身就是一个完整的搜索引擎。我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。
ES实际上就是利用分片来实现分布式。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当你的集群规模扩大或者缩小时， ES会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。
一个分片可以是主分片或者副本分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。
如果当前插入大量数据，那么会对es集群造成一定的压力，所以在插入大量数据前，也就是在建立索引的时候，我们最好把副本数设置为0；等数据建立完索引之后，在手动的将副本数更改到2，这样可以提高数据的索引效率
在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。默认情况下，一个索引会有5个主分片，而其副本可以有任意数量。
主分片和副本分片的状态决定了集群的健康状态。每一个节点上都只会保存主分片或者其对应的一个副本分片，相同的副本分片不会存在于同一个节点中。如果集群中只有一个节点，则副本分片将不会被分配，此时集群健康状态为yellow，存在丢失数据的风险。
a. es处理的最小单元，它只是保存了索引中所有数据的一部分。
b. 一个分片是一个Lucene索引
c.一个包含倒排索引的文件记录
d.分片越多搜索越慢
分片：扩展和容灾（和kafka的分区很像）
索引和搜索数据：
索引文档（相当于写）请求到一个节点，文档会通过hash随机到一个主分片，然后从主分片同步到副本分片。副本分片越多，索引数据越慢，因为所有的数据都完成才算完成
搜索请求到一个节点，节点请求到本节点的一个分片，到其他节点的另一个分片，所有分片都返回结果到发起节点，发起节点返回搜索结果到请求方。不同节点上的主分片+副本分片的总数越多，请求被分摊的越均匀，并发搜索性能越好。如果节点数很少，分片都集中到少数节点上，搜索速度会变慢，因为增加了开销，实际没有分摊负载。单个搜索无法通过分片加速，因为分片搜索是有额外的开销的，所以尽管把搜索均衡到了不同节点上一定程度上提高了搜索性能，但是还是不能提高单个搜索的速度。
分段
a. lucene索引再分割成小单元
b. 分段越多搜索越慢
c. 分段不会被修改
d. 索引新的文档会创建新的分段
e. 分段会持续地被合并
f. 删除文档的时候不会真的删除
写数据
当用户向一个节点提交了索引一个新文档的请求，该节点会根据路由选择确定新文档所在的分区，而每个节点都会保存每个分区所在节点的信息，协调节点会将请求发送给对应的节点，注意这个请求会发送给主分片，等主分片完成索引，会并行将请求发送到其所有副本分片，保证每个分片都持有最新数据。
协调节点默认使用文档 ID 参与计算（也支持通过 routing），以便为路由提供合适的分片：shard = hash(document_id) % (num_of_primary_shards)
当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 Memory Buffer，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache，这个从 Memory Buffer 到 Filesystem Cache 的过程就叫做 refresh；
当然在某些情况下，存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失， ES 是通过 translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystemcache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；
在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。
flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M）时；
读数据
可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。
- 客户端发送请求到任意一个 node，成为
coordinate node。 coordinate node对doc id进行哈希路由，将请求转发到对应的 node，此时会使用round-robin随机轮询算法，在primary shard以及其所有 replica 中随机选择一个，让读请求负载均衡（保证读请求能够分摊到不同的shard上）。- 接收请求的 node 返回 document 给
coordinate node。 coordinate node返回 document 给客户端。
更新和删除数据
- 删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更；
- 磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。
- 在新的文档被创建时， Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
搜索数据
es 最强大的是做全文检索，就是比如你有三条数据：
1 | java真好玩儿啊 |
你根据 java 关键词来搜索，将包含 java 的 document 给搜索出来。es 就会给你返回：java真好玩儿啊，java好难学啊。
客户端发送请求到一个
coordinate node。协调节点将搜索请求转发到所有的 shard 对应的
primary shard或replica shard，都可以。如果并行搜索的话，如果有比较多的副本shard，这样搜索请求就会被分摊到多个shard上，提高效率query phase：每个 shard 将自己的搜索结果（其实就是一些
doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。fetch phase：接着由协调节点根据
doc id去各个节点上拉取实际的document数据，最终返回给客户端。
Elasticsearch 的 master 选举流程？
1 | conf/elasticsearch.yml: |
一个ElasticSearch集群是由多个节点构成的，节点又可以根据上述两个参数分为四种类型。
当node.master=true时，表示该接待你是一个master的候选节点，可以参与选举，在ES的文档中常被称作master-eligible node。ES在正常运行时只能有一个master，多于一个就发生了脑裂。当node.data为true时，这个节点作为一个数据节点，会存储分配在该node上的shard的数据并负责这些shard的写入、查询等。任何一个集群内的node都可以执行任何请求，其会负责将请求转发给对应的node进行处理，所以当node.master和node.data都为false时，这个节点可以作为一个类似proxy的节点，接受请求并进行转发、结果聚合等。
节点发现
ZenDiscovery是ES自己实现的一套用于节点发现和选主等功能的模块，没有依赖Zookeeper等工具。
简单来说，节点发现依赖以下配置：
1 | conf/elasticsearch.yml: |
这个配置可以看作是，在本节点到每个hosts中的节点建立一条边，当整个集群所有的node形成一个联通图时，所有节点都可以知道集群中有哪些节点，不会形成孤岛。
Master选举
上面提到，集群中可能会有多个master-eligible node，此时就要进行master选举，保证只有一个当选master。如果有多个node当选为master，则集群会出现脑裂，脑裂会破坏数据的一致性，导致集群行为不可控，产生各种非预期的影响。
为了避免产生脑裂，ES采用了常见的分布式系统思路，保证选举出的master被多数派(quorum)的master-eligible node认可，以此来保证只有一个master。这个quorum通过以下配置进行配置：
1 | conf/elasticsearch.yml: |
master选举谁发起，什么时候发起？
master选举当然是由master-eligible节点发起，当一个master-eligible节点发现满足以下条件时发起选举：
- 该master-eligible节点的当前状态不是master。
- 该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点，没有任何节点连接到master。
- 包括本节点在内，当前已有超过minimum_master_nodes个节点没有连接到master。
总结一句话，即当一个节点发现包括自己在内的多数派的master-eligible节点认为集群没有master时，就可以发起master选举。
当需要选举master时，选举谁？
根据源码来进行分析
首先是选举谁的问题，如下面源码所示，选举的是排序后的第一个MasterCandidate（即master-eligible node）。
1 | public MasterCandidate electMaster(Collection<MasterCandidate> candidates) { |
那么是按照什么排序的？
1 | public static int compare(MasterCandidate c1, MasterCandidate c2) { |
如上面源码所示，先根据节点的clusterStateVersion比较，clusterStateVersion越大，优先级越高。clusterStateVersion相同时，进入compareNodes，其内部按照节点的Id比较(Id为节点第一次启动时随机生成)。
总结一下：
当clusterStateVersion越大，优先级越高。这是为了保证新Master拥有最新的clusterState(即集群的meta)，避免已经commit的meta变更丢失。因为Master当选后，就会以这个版本的clusterState为基础进行更新。(一个例外是集群全部重启，所有节点都没有meta，需要先选出一个master，然后master再通过持久化的数据进行meta恢复，再进行meta同步)。
clusterstateversion是集群状态数字版本号，每次更新version+1。
当clusterStateVersion相同时，节点的Id越小，优先级越高。即总是倾向于选择Id小的Node，这个Id是节点第一次启动时生成的一个随机字符串。之所以这么设计，应该是为了让选举结果尽可能稳定，不要出现都想当master而选不出来的情况。
什么时候选举成功？
当一个master-eligible node(我们假设为Node_A)发起一次选举时，它会按照上述排序策略选出一个它认为的master。
- 假设Node_A选Node_B当Master：
Node_A会向Node_B发送join请求，那么此时：
(1) 如果Node_B已经成为Master，Node_B就会把Node_A加入到集群中，然后发布最新的cluster_state, 最新的cluster_state就会包含Node_A的信息。相当于一次正常情况的新节点加入。对于Node_A，等新的cluster_state发布到Node_A的时候，Node_A也就完成join了。
(2) 如果Node_B在竞选Master，那么Node_B会把这次join当作一张选票。对于这种情况，Node_A会等待一段时间，看Node_B是否能成为真正的Master，直到超时或者有别的Master选成功。
(3) 如果Node_B认为自己不是Master(现在不是，将来也选不上)，那么Node_B会拒绝这次join。对于这种情况，Node_A会开启下一轮选举。
- 假设Node_A选自己当Master：
此时NodeA会等别的node来join，即等待别的node的选票，当收集到超过半数的选票时，认为自己成为master，然后变更cluster_state中的master node为自己，并向集群发布这一消息。
按照上述流程，我们描述一个简单的场景来帮助大家理解：
假如集群中有3个master-eligible node，分别为Node_A、Node_B、Node_C，选举优先级也分别为Node_A、Node_B、Node_C。三个node都认为当前没有master，于是都各自发起选举，选举结果都为Node_A(因为选举时按照优先级排序，如上文所述)。于是Node_A开始等join(选票)，Node_B、Node_C都向Node_A发送join，当Node_A接收到一次join时，加上它自己的一票，就获得了两票了(超过半数)，于是Node_A成为Master。此时cluster_state(集群状态)中包含两个节点，当Node_A再收到另一个节点的join时，cluster_state包含全部三个节点。
- Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含-一个主机列表以控制哪些节点需要ping通）这两部分。
- 对所有可以成为master的节点（node master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
- 如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
- master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。
Elasticsearch 集群脑裂问题？
脑裂问题，就是同一个集群中的不同节点，对于集群的状态，有了不一样的理解。
由于并发访问量的提高，导致了我们两个节点的集群（分片数默认为5，副本为1，没有固定的master，都是集群中的节点，又做data又做master）状态变成了red，出现了大量的坏片，并且坏掉的都是主分片及其副本。分析发现，是ES集群出现了脑裂问题（俗称精神分裂），即集群中不同的节点对于master的选择出现了分歧，出现了多个master竞争，导致主分片和副本的识别也发生了分歧，对一些分歧中的分片标识为了坏片。
- “脑裂”问题可能的成因：
网络问题：集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片。
节点负载：主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
内存回收：data 节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。
- 脑裂问题解决方案：
减少误判：discovery.zen ping_timeout 节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。
选举触发：discovery.zen.minimum.master_nodes：1，该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个數大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为(n / 2) +1，n为主节点个数（即有资格成为主节点的节点个数）。
角色分离：即master节点与data节点分离，限制角色
主节点配置为：node master: true，node data: false
从节点配置为：node master: false，node data: true
ES 调优
设计阶段调优
（1）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；（(31条消息) 高效管理 Elasticsearch 中基于时间的索引_weixin_33941350的博客-CSDN博客）
基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索引的模板格式为：blog_index_时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的32 次幂-1，索引存储达到了 TB+甚至更大。一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。
（2）使用别名进行索引管理；
（3）每天凌晨定时对索引做 force_merge 操作，以释放空间；
（4）采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink操作，以缩减存储；
冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索效率。
（5）采取 curator 进行索引的生命周期管理；
（6）仅针对需要分词的字段，合理的设置分词器；
（7）Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。……..
知识点—冷热分离（冷热数据是按照时间推移来区分的）
冷数据（考虑低成本存储）：
- 不允许更新，偶尔被查询
- 对访问的响应时间要求不高，通常在1~10秒内都可以接受
热数据（考虑读写性能）：
被频繁查询或更新
对访问的响应时间要求很高，通常在10毫秒以内
因为通常情况下，为了支持热数据的操作特性，需要有较好的硬件配置，比如高性能CPU、大内存、SSD硬盘等等。随着时间的推移，系统里会积累越来越多的历史数据，如果依然采用高配置机器来存放这些使用频率非常低的数据，势必会带来非常高的成本。当然，如果数据量很小或者不计成本，那完全不需要考虑冷热区分，采用一个单体系统就可以应对所有事情了，比如MySQL。
写入调优
（1）写入前副本数设置为 0；
（2）写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
执行刷新操作的频率，这会使索引的最近更改对搜索可见，默认为1s，可以设置-1为禁用刷新，对于写入速率要求较高的场景，可以适当的加大对应的时长，减小磁盘io和segment的生成；
（3）写入过程中：采取 bulk 批量写入；
批量请求显然会大大提升写入速率，且这个速率是可以量化的，官方建议每次批量的数据物理字节数5-15MB是一个比较不错的起点，注意这里说的是物理字节数大小。文档计数对批量大小来说不是一个好指标。比如说，如果你每次批量索引 1000 个文档，记住下面的事实： 1000 个 1 KB 大小的文档加起来是 1 MB 大。 1000 个 100 KB 大小的文档加起来是 100 MB 大。 这可是完完全全不一样的批量大小了。批量请求需要在协调节点上加载进内存，所以批量请求的物理大小比文档计数重要得多。 从 5–15 MB 开始测试批量请求大小，缓慢增加这个数字，直到你看不到性能提升为止。然后开始增加你的批量写入的并发度（多线程等等办法）。 用iostat 、 top 和 ps 等工具监控你的节点，观察资源什么时候达到瓶颈。如果你开始收到 EsRejectedExecutionException ，你的集群没办法再继续了：至少有一种资源到瓶颈了。或者减少并发数，或者提供更多的受限资源（比如从机械磁盘换成 SSD），或者添加更多节点。
（4）写入后恢复副本数和刷新间隔；
（5）尽量使用自动生成的 id。
当写入端使用特定的id将数据写入es时，es会去检查对应的index下是否存在相同的id，这个操作会随着文档数量的增加而消耗越来越大，所以如果业务上没有强需求，建议使用es自动生成的id，加快写入速率
查询调优
（1）禁用 wildcard；
（2）禁用批量 terms（成百上千的场景）；
（3）充分利用倒排索引机制，能 keyword 类型尽量 keyword；
（4）数据量大时候，可以先基于时间敲定索引再检索；
（5）设置合理的路由机制
其他调优
部署调优，业务调优等。
对于 GC 方面，在使用 Elasticsearch 时要注意什么？
（1）倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segmentmemory 增长趋势。
（2）各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache等“自欺欺人”的方式来释放内存。
（3）避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api 来实现。
（4）cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。
（5）想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做持续的监控。
（6）根据监控数据理解内存需求，合理配置各类circuit breaker，将内存溢出风险降低到最低
在并发情况下，Elasticsearch 如果保证读写一致？
（1）可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
（2）另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
（3）对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。