elasticsearch基本概念
<h1>elasticsearch总结</h1>
<h2>1 查询数据</h2>
<pre><code>1.根据id检索 http://ip:port/index/type/id
2.全员搜索 http://ip:port/index/type/_search
3.根据某个字段进行查询 http://ip:port/index/type/_search?q=fieldName:fieldValue
4.查看索引状况 http://localhost:9200/_cat/indices?v</code></pre>
<h2>2 使用QueryBuilders进行查询</h2>
<pre><code>1. matchQuery：单匹配查询，与termQuery的区别是会将搜索词分词再去匹配
2. multiMatchQuery：多匹配查询
3. booleanQuery：条件组合查询
4. termQuery：精确查询，不分词，直接查询
5. idsQuery：根据id查询
6. constantScoreQuery：包裹查询，高于设定分数, 不计算相关性
7. disMaxQuery：联合查询
8. fuzzyQuery：模糊查询
9. hasChildQuery：父或子的文档查询
10. matchAllQuery：查询匹配所有文件
11. moreLikeThisQuery：多匹配模糊查询
12. prefixQuery：前缀查询
13. queryString：查询解析查询字符串
14. rangeQuery：范围查询
15. spanQuery：跨度查询
16. termsQuery：多匹配精确查询
17. wildcardQuery：支持通配符的查询
18. nestedQuery：嵌套查询
19. indicesQuery：索引查询
20. topChildrenQuery：子查询
21. existsQuery:字段是否存在查询</code></pre>
<h2>3 SearchSourceBuilder相关字段介绍</h2>
<pre><code>1. from：分页查询起始页
2. size：分页查询每页记录数
3. timeout：查询超时时间
4. query：设置查询主体
5. sort：查询结果排序
6. highlight：高亮查询
7. collapse：根据字段值折叠搜索结果
8. fetchSource：定义返回字段
9. _source：字段过滤
10. stored_fields：与_source一样，用来进行字段过滤
11. docvalue_fields：指定需要转换的字段与格式
12. post_filter: 对查询条件命中后的文档再做一次筛选
13. explain：是否解释各分数是如何计算的
14. version：是否返回每个命中文档的当前版本号
15. indices_boost：当搜索多个索引时，允许为每个索引配置不同的boost级别
16. min_score：指定返回文档的最小评分，如果文档的评分低于该值，则不返回</code></pre>
<h2>4 基本的es概念</h2>
<ul>
<li>cluster: ES集群是一个或多个节点的集合，它们共同存储了整个数据集，并提供了联合索引以及可跨所有节点的搜索能力。</li>
<li>node: 一个节点是一个逻辑上独立的服务，可以存储数据，并参与集群的索引和搜索功能, 一个节点也有唯一的名字，群集通过节点名称进行管理和通信。</li>
<li>master node: 主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。</li>
<li>data node: 持有数据和倒排索引。</li>
<li>coordinating node: 该节点可以响应用户的情况，把相关操作发送到其他节点；客户端节点会将客户端请求路由到集群中合适的分片上。对于读请求来说，协调节点每次会选择不同的分片处理请求，以实现负载均衡。</li>
<li>index: es中存储数据的基本单位，索引是具有类似特性的文档的集合，可以理解为关系型数据库的database（或者同一类型表的集合）。</li>
<li>type: type是索引内部的逻辑分区，可以理解为关系型数据库中的table。一个index下可以有多个type（不建议使用，1.同一index下的不同type的相同field会产生冲突，造成查询效率下降；2.不同类型的“记录”存储在同一个index中， 会影响lucene的压缩性能。）</li>
<li>mapping: 当一个index中有多个type时，不同的type下相同的field会冲突（数据都是存储在index下，在Lucene中，同一index的不同type的相同field处理方式是一样的），所以要用mapping映射来区分相同的field属于哪一个type。</li>
<li>document: 文档是Lucene索引和搜索的原子单位，往index写入的一条数据就叫一条document，相当于关系型数据库中的一行数据。</li>
<li>field: 每个document中包含有多个filed，相当于数据库中一条(行)数据有多个字段。</li>
<li>shard: ES的“分片(shard)”机制可将一个索引内部的数据分布地存储于多个节点，它通过将一个索引切分为多个底层物理的Lucene索引完成索引数据的分割存储功能，这每一个物理的Lucene索引称为一个分片(shard)。每个分片其内部都是一个全功能且独立的索引，因此可由集群中的任何主机存储。创建索引时，用户可指定其分片的数量，默认数量为5个。Shard有两种类型：primary和replica，即主shard及副本shard。</li>
</ul>
<p>默认情况下，node.ingest、node.master、node.data的默认值都是true；当ingest设为true，其它两个设为false，该节点可以成为协调节点；当master设为true，其它两个参数设为false，该节点可以成为主节点；当data设为true，其它两个参数设为false，该节点可以成为数据节点。</p>
<h2>5 es的分布式架构原理（es是如何实现分布式架构的？）</h2>
<p>es是一个分布式搜索引擎，底层实现是基于Lucene的。核心思想是在多台机器上启动多个es进程实例，组成一个es集群。</p>
<p>es 集群多个节点，会自动选举一个节点为 master 节点，这个 master 节点其实就是干一些管理的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举一个节点为 master 节点。
为了提高高可用，我们将一个index拆分成多个shard(片)，每个shard中存储部分数据，这就是es中的分片存储。分片存储的好处有：</p>
<pre><code>1. 支持横向扩展，扩展数据就新增一个有更多shard的索引，然后将数据导入进去；
2. 提高性能，数据分布在多个 shard，即多台服务器上，所有的操作，都会在多台机器上并行分布式执行，提高了吞吐量和性能。
3. 高可用，每个shard都有一个primary shard，负责写入数据，还有几个replica shard，primary shard 写入数据之后，会将数据同步到其他几个replica shard 上去。如果某个节点的primary shard挂掉了，master节点会让primary shard对应的replica shard(在其它机器上)切换成primary shard。机器修复后，修复后的节点也不再是primary shard，而是replica shard。
注：写请求是写入 primary shard，然后同步给所有的 replica shard；读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法。</code></pre>
<h2>6 es写入数据、读取数据的工作原理</h2>
<pre><code>1. es写入数据过程
1.1 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
1.2 coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
1.3 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
1.4 coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。
2. es读取数据过程
2.1 客户端发送请求到任意一个 node，成为 coordinate node。
2.2 coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
2.3 接收请求的 node 返回 document 给 coordinate node。
2.4 coordinate node 返回 document 给客户端。
3. es搜索数据过程
3.1 客户端发送请求到一个 coordinate node。
3.2 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard，都可以。
3.3 query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
3.4 fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。
4. 写数据底层原理
4.1 大致过程：数据先写入内存buffer、然后每隔1s，将数据refresh到os cache中(内存 buffer会被清空)，到了 os cache中的数据就能被搜索到(所以es是准实时的，从写入到能被搜索是有1s的延迟)。每隔5s，将数据从os cache写入translog文件(这样如果宕机，内存数据全没(buffer和os cache),最多会有5s的数据丢失)，translog大到一定阈值，或者默认每隔30min，会触发flush操作（1.将buffer数据refresh到os cache中，清空buffer；2.将一个commit point写入磁盘文件，里面标识着这个 commit point 对应的所有 segment file，同时将os cache中的数据强行fsync到磁盘文件中；3.清空现有translog，重启一个，commit完成。）数据写入segment file之后，同时建立好了倒排序索引。
5. 删除/更新数据底层原理
5.1 如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。
5.2 如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。
5.3 buffer 每 refresh 一次，就会产生一个 segment file，所以默认情况下是 1 秒钟一个 segment file，这样下来 segment file 会越来越多，此时会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个，同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘，这里会写一个 commit point，标识所有新的 segment file，然后打开 segment file 供搜索使用，同时删除旧的 segment file。
6.倒排索引
6.1 在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词(分词后，每个关键词都会记录它在文档中出现的次数和出现位置)的集合。
6.2 倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件（一个或多个文档），这些文件中都出现了关键词。
注：es里的写流程，有4个底层的核心概念，refresh、flush、translog、merge</code></pre>
<h2>7 底层索引控制</h2>
<pre><code>1. 什么是段segment？
1.1 Elasticsearch中的每个分片包含多个segment（段），每一个segment都是一个倒排索引；在查询的时，会把所有的segment查询结果汇总归并为最终的分片查询结果返回。
1.2 在创建索引的时候，ES会把文档信息写到内存bugffer中（为了安全，也一起写到translog），定时（可配置）把数据写到segment缓存小文件中，然后刷新查询，使刚写入的segment可查。
1.3 虽然写入的segment可查询，但是还没有持久化到磁盘上。因此，还是会存在丢失的可能性的。所以，ES会执行flush操作，把segment持久化到磁盘上并清除translog的数据（因为这个时候，数据已经写到磁盘上，不再需要了）。
2. 什么是段合并？
2.1 由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。
2.1.1 消耗资源：每一个段都会消耗文件句柄、内存和cpu运行周期；
2.1.2 搜索变慢：每个搜索请求都必须轮流检查每个段，所以段越多，搜索也就越慢。
2.2 ES通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。
3. 段合并做了什么？
3.1 段合并的时候会将那些旧的已删除文档从文件系统中清除。
3.2 被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
3.3 启动段合并不需要你做任何事。进行索引和搜索时会自动进行。
3.4 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。
3.5 合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。
4. 为什么要进行段索引？
4.1 索引段的个数越多，搜索性能越低并且消耗更多的内存；
4.2 索引段是不可变的，你并不能物理上从中删除信息。（可以逻辑上删除document，但只是做了删除标记，物理上并没有立即删除，真正的物理删除是ES在合适的时候在后台将标记为deleted的document进行删除）
4.3 当段合并时，这些被标记为删除的文档并没有被拷贝至新的索引段中，这样，减少了最终的索引段中的document数目。
5.段合并的好处？
5.1 减少索引段的数量并提高检索速度；
5.2 减少索引的容量（文档数）——段合并会移除被标记为已删除的那些文档。
6. 段合并可能带来的问题？
6.1 磁盘IO操作的代价；
6.2 速度慢的系统中，段合并会显著影响性能。</code></pre>