ElasticSearch基础篇

为什么要用ElasticSearch？

完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G 
节点数=1048576/96=10922个 
实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

从前面讨论我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。 
全部放在内存速度问题是解决了，但成本问题上来了。 
为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法： 
1、存储数据时按有序存储； 
2、将数据和索引分离； 
3、压缩数据； 

ElasticSearch的定义

ElasticSearch的目标就是实现搜索。在数据量少的时候，我们可以通过索引去搜索关系型数据库中的数据，但是如果数据量很大，搜索的效率就会很低，这个时候我们就需要一种分布式的搜索引擎。Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RestFul web接口。

ES主要用于全文检索、结构化搜索以及分析。ES的应用十分广泛，比如维基百科、Github等都使用ES实现搜索。

Lucene与ES关系？

• Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。
• Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

核心概念 

1. 关系型数据库中的数据库（DataBase），等价于ES中的索引（Index）。 
2. 一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type）。（在ES7.x版本中，types将慢慢被遗弃，在8.x版本中，types将会彻底弃用。）
3. 一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成。 
4. 在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。 与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等。 
5. 在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改_update、查GET。

ES既然是用来搜索的，那么它必然也需要存储数据。在Mysql等关系型数据库中，数据的存储遵循下面的逻辑：

一个数据库（database）中有多个表（tables），每个表有多行数据（rows），每一行数据由多个字段（columns）组成。

ES中的存储是这样的：

一个索引（indeces）相当于一个数据库（database），每个索引中有多个类型types（相当于表结构），每个索引中有多个documents（相当于行），每个documents由多个fields组成（相当于字段）。

ES不是高QPS的应用，写操作非常消耗CPU资源，因此写操作属于比较长的操作，聚合由于涉及数据量比较大，延迟也经常到秒级，查询一般也不密集。

索引结构

ES是面向文档的。各种文本内容以文档的形式存储到ES中。在存储结构上，由_index、_type和_id唯一标识一个文档。_index指向一个或多个物理分片的逻辑命名空间，_type类型用于区分同一个集合中的不同细分，在不同的细分中，数据的整体模式是相同或相似的，不适合完全不同类型的数据。多个_type可以在相同的索引中存在，只要它们的字段不冲突即可（对于整个索引，映射在本质上被“扁平化”成一个单一的、全局的模式）。_id文档标记符由系统自动生成或使用者提供。在ES 6.x版本中，一个索引只允许存在一个_type，未来的7.x版本将慢慢删除_type的概念。

分片（shard）

除了将数据分片以提高水平扩展能力，分布式存储中还会把数据复制成多个副本，放置到不同的机器中，这样一来可以增加系统可用性，同时数据副本还可以使读操作并发执行，分担集群压力。但是多数据副本也带来了一致性的问题：部分副本写成功，部分副本写失败。

为了应对并发更新问题，ES将数据副本分为主从两部分，即主分片（primary shard）和副分片（replica shard）。主数据作为权威数据，写过程中先写主分片，成功后再写副分片，恢复阶段以主分片为准。

分片（shard）是底层的基本读写单元，分片的目的是分割巨大索引，让读写可以并行操作，由多台机器共同完成。读写请求最终落到某个分片上，分片可以独立执行读写工作。ES利用分片将数据分发到集群内各处。分片是数据的容器，文档保存在分片内，不会跨分片存储。分片又被分配到集群内的各个节点里。当集群规模扩大或缩小时，ES 会自动在各节点中迁移分片，使数据仍然均匀分布在集群里。

一个ES索引包含很多分片，一个分片是一个Lucene的索引，它本身就是一个完整的搜索引擎，可以独立执行建立索引和搜索任务。Lucene索引又由很多分段组成，每个分段都是一个倒排索引。ES每次“refresh”都会生成一个新的分段，其中包含若干文档的数据。在每个分段内部，文档的不同字段被单独建立索引。每个字段的值由若干词（Term）组成，Term是原文本内容经过分词器处理和语言处理后的最终结果（例如，去除标点符号和转换为词根）。

在实际应用中，我们不应该向单个索引持续写数据，直到它的分片巨大无比。巨大的索引会在数据老化后难以删除，以_id 为单位删除文档不会立刻释放空间，删除的 doc 只在 Lucene分段合并时才会真正从磁盘中删除。即使手工触发分段合并，仍然会引起较高的 I/O 压力，并且可能因为分段巨大导致在合并过程中磁盘空间不足（分段大小大于磁盘可用空间的一半）。因此，我们建议周期性地创建新索引。例如，每天创建一个。假如有一个索引website，可以将它命名为website_20180319。然后创建一个名为website的索引别名来关联这些索引。这样，对于业务方来说，读取时使用的名称不变，当需要删除数据的时候，可以直接删除整个索引。

动态更新索引

为文档建立索引，使其每个字段都可以被搜索，通过关键词检索文档内容，会使用倒排索引的数据结构。倒排索引一旦被写入文件后就具有不变性，不变性具有许多好处：对文件的访问不需要加锁，读取索引时可以被文件系统缓存等。

索引如何更新，让新添加的文档可以被搜索到？

答案是使用更多的索引，新增内容并写到一个新的倒排索引中，查询时，每个倒排索引都被轮流查询，查询完再对结果进行合并。

近实时搜索

在写操作中，一般会先在内存中缓冲一段数据，再将这些数据写入硬盘，每次写入硬盘的这批数据称为一个分段，如同任何写操作一样。一般情况下（direct方式除外），通过操作系统write接口写到磁盘的数据先到达系统缓存（内存）,write函数返回成功时，数据未必被刷到磁盘。通过手工调用flush，或者操作系统通过一定策略将系统缓存刷到磁盘。这种策略大幅提升了写入效率。从write函数返回成功开始，无论数据有没有被刷到磁盘，该数据已经对读取可见。

ES正是利用这种特性实现了近实时搜索。每秒产生一个新分段，新段先写入文件系统缓存，但稍后再执行flush刷盘操作，写操作很快会执行完，一旦写成功，就可以像其他文件一样被打开和读取了。

由于系统先缓冲一段数据才写，且新段不会立即刷入磁盘，这两个过程中如果出现某些意外情况（如主机断电），则会存在丢失数据的风险。通用的做法是记录事务日志，每次对ES进行操作时均记录事务日志，当ES启动的时候，重放translog中所有在最后一次提交后发生的变更操作。比如HBase等都有自己的事务日志。

段合并

在ES中，每秒清空一次写缓冲，将这些数据写入文件，这个过程称为refresh，每次refresh会创建一个新的Lucene 段。但是分段数量太多会带来较大的麻烦，每个段都会消耗文件句柄、内存。每个搜索请求都需要轮流检查每个段，查询完再对结果进行合并；所以段越多，搜索也就越慢。因此需要通过一定的策略将这些较小的段合并为大的段，常用的方案是选择大小相似的分段进行合并。在合并过程中，标记为删除的数据不会写入新分段，当合并过程结束，旧的分段数据被删除，标记删除的数据才从磁盘删除。

集群内部原理

从集群节点角色的角度划分，至少存在主节点和数据节点，另外还有协调节点、预处理节点和部落节点。

集群节点角色

1. 主节点（Master node）主节点负责集群层面的相关操作，管理集群变更。
2. 数据节点（Data node）负责保存数据、执行数据相关操作：CRUD、搜索、聚合等。数据节点对CPU、内存、I/O要求较高。一般情况下（有一些例外，后续章节会给出），数据读写流程只和数据节点交互，不会和主节点打交道（异常情况除外）。
3. 预处理节点（Ingest node）这是从5.0版本开始引入的概念。预处理操作允许在索引文档之前，即写入数据之前，通过事先定义好的一系列的processors（处理器）和pipeline（管道），对数据进行某种转换、富化。processors和pipeline拦截bulk和index请求，在应用相关操作后将文档传回给index或bulk API。
4. 协调节点（Coordinating node）客户端请求可以发送到集群的任何节点，每个节点都知道任意文档所处的位置，然后转发这些请求，收集数据并返回给客户端，处理客户端请求的节点称为协调节点。协调节点将请求转发给保存数据的数据节点。每个数据节点在本地执行请求，并将结果返回协调节点。协调节点收集完数据后，将每个数据节点的结果合并为单个全局结果。对结果收集和排序的过程可能需要很多CPU和内存资源。
5. 部落节点（Tribe node）tribes（部落）功能允许部落节点在多个集群之间充当联合客户端。（它不做主节点，也不做数据节点，仅用于路由请求，本质上是一个智能负载均衡器（从负载均衡器的定义来说，智能和非智能的区别在于是否知道访问的内容存在于哪个节点），从5.0版本开始，这个角色被协调节点（Coordinating only node）取代。）

集群健康状态

从数据完整性的角度划分，集群健康状态分为三种：·

• Green，所有的主分片和副分片都正常运行。
• Yellow，所有的主分片都正常运行，但不是所有的副分片都正常运行。这意味着存在单点故障风险。
• Red，有主分片没能正常运行。

每个索引也有上述三种状态，假设丢失了一个副分片，该分片所属的索引和整个集群变为Yellow状态，其他索引仍为Green。

集群状态

集群状态元数据是全局信息，元数据包括内容路由信息、配置信息等，其中最重要的是内容路由信息，它描述了“哪个分片位于哪个节点”这种信息。

集群状态由主节点负责维护，如果主节点从数据节点接收更新，则将这些更新广播到集群的其他节点，让每个节点上的集群状态保持最新。

集群扩容

当扩容集群、添加节点时，分片会均衡地分配到集群的各个节点，从而对索引和搜索过程进行负载均衡，这些都是系统自动完成的。

分片副本实现了数据冗余，从而防止硬件故障导致的数据丢失。

分片分配过程中除了让节点间均匀存储，还要保证不把主分片和副分片分配到同一节点，避免单个节点故障引起数据丢失。

分布式系统中难免出现故障，当节点异常时，ES会自动处理节点异常。当主节点异常时，集群会重新选举主节点。当某个主分片异常时，会将副分片提升为主分片。