mastering elasticsearch

概念：

Term: 它是搜索的基本单位，其表现形式为文本中的一个词。
Token: 它是单个Term在所属Field中文本的呈现形式，包含了Term内容、Term类型、Term在文本中的起始及偏移位置。

 

倒排索引结构（简单版）：

此 外，每个词映射着一个数值(Count)，它代表着Term在文档集中出现的频繁程度。

| Term | count | Docs |

| Cookbook | 1 | <3> |

指 Cookbook在文档3中出现一次。当然，Lucene创建的真实索引远比上文复杂和先进

每个索引被分成了多个段(Segment)，段具有一次写入，多次读取的特点。只要形成了， 段就无法被修改。例如:被删除文档的信息被存储到一个单独的文件，但是其它的段文件并 没有被修改。

文本分析工作由analyzer组件负责。analyzer由一个分词器(tokenizer)和0个或者多个过 滤器(filter)组成,也可能会有0个或者多个字符映射器(character mappers)组成。

Lucene中的tokenizer用来把文本拆分成一个个的Token。Token包含了比较多的信息， 比如Term在文本的中的位置及Term原始文本，以及Term的长度。

如果用户的Document中有title和description 两个Field，那么这两个Field可以指定不同的analyzer。

有的Query对象会被解析(analyzed)，有的不会，比如:前缀查询(prefix query)就不会被解析，精确匹配查询(match query)就会被解析。对用户来说，理解这一点至 关重要。

一个Query对象中会存在多个布尔运算符，这些布尔运算符将多个Term关联起来形成查询子 句。

ElasticSearch 把数据分发到多个存储Lucene索引的物理机上。这些Lucene索引称为分片索引，这个分发的 过程称为索引分片(Sharding)。在ElasticSearch集群中，索引分片(Sharding)是自动完成的， 而且所有分片索引(Shard)是作为一个整体呈现给用户的。需要注意的是，尽管索引分片这个 过程是自动的，但是在应用中需要事先调整好参数。因为集群中分片的数量需要在索引创建 前配置好，而且服务器启动后是无法修改的，至少目前无法修改。

在运行的过程中，ElasticSearch会收集集群的状态、索引的参数等信息。这些数据被存 储在Gateway中。

ES背后的核心理念:

自动容错。ElasticSearch通过P2P网络进行通信，这种工作方式消除了单点故障。节点 自动连接到集群中的其它机器，自动进行数据交换及以节点之间相互监控。索引分片

ElasticSearch是构建在极少数的几个概念之上的。ElasticSearch的开发团队希望它能够 快速上手，可扩展性强。而且这些核心特性体现在ElasticSearch的各个方面。从架构的角度 来看，这些主要特性是:

开箱即用。安装好ElasticSearch后，所有参数的默认值都自动进行了比较合理的设置， 基本不需要额外的调整。包括内置的发现机制(比如Field类型的自动匹配)和自动化参数配 置。

天生集群。ElasticSearch默认工作在集群模式下。节点都将视为集群的一部分，而且在 启动的过程中自动连接到集群中。

自动容错。ElasticSearch通过P2P网络进行通信，这种工作方式消除了单点故障。节点 自动连接到集群中的其它机器，自动进行数据交换及以节点之间相互监控。索引分片

扩展性强。无论是处理能力和数据容量上都可以通过一种简单的方式实现扩展，即增添 新的节点。

近实时搜索和版本控制。由于ElasticSearch天生支持分布式，所以延迟和不同节点上数 据的短暂性不一致无可避免。ElasticSearch通过版本控制(versioning)的机制尽量减少问 题的出现。

在集群中，一个节点被选举成主节点(master node)。这个节点负责管理集群的状态，当 群集的拓扑结构改变时把索引分片分派到相应的节点上。

主节点在ElasticSearch中并没有占据着重要的地位

任何节点都可以并发地把查询子句分发到其它的节点，然后合并各个节点返回的查询结果

对于每个丢失的主分片，新的主分片将从剩余的分片 副本(Replica)中选举出来

主节点向其它的节点发送Ping命令然后等待回应。如果没有得 到回应(实际上可能得不到回复的Ping命令个数取决于用户配置)，该节点就会被移出集群。

如果索引数据的请求发送到的节点没有合适的分片或者分片是副本，那 么请求会被转发到含有主分片的节点。

Lucene默认的打分机制:TF/IDF(term frequency/inverse document frequecy)算法

基本上，从前面的公式中可以提炼出以下的几个规则:

匹配到的关键词越稀有，文档的得分就越高。

文档的域越小(包含比较少的Term)，文档的得分就越高。

设置的权重(索引和搜索时设置的都可以)越大，文档得分越高。

索引分片机制用来存储超过单个节点存储容量的数据，分片副本用来应对不断攀升的吞 吐量以及确保数据的安全性

路由功能向ElasticSearch提供一种信息来决定哪些分片用于存储和 查询

一个重要的配置项：

cluster.routing.allocation.awareness.attributes:group

决定新节点加入集群后，如何将p/r shard重新分配。

在集群中使用了shard allocation awareness功能后，ElasticSearch不会把决定allocation awareness的属性(在本例中是 node.group值)相同的分片或者分片副本分配到同一个节点中。该功能典型的用例是把集群拓 扑结构部署到物理机或者虚拟机时，确保你的集群不会出现单点故障问题。

分片分配机制不会考虑分配分片到没有设 置node.group属性的节点。

index.routing.allocation.total\_shards\_per\_node属性值为1，这意味着对于每个索引， ElasticSearch只会在单个节点上分配一个分片。这应用到我们的4-节点集群的例子中就是每 个节点会平均分配所有的分片。

对于ElasticSearch来说，最核心的一种配置就是集群恢复配置

重新索引：

第二个想法是创建第二个索引，并且添加数据，然后把应用接口调转到新的索 引。方案可行，但是有个小问题，创建新的索引需要额外的空间开销。

我们已经多次提到，ElasticSearch创建的目的就是对应集群工作环境。这是跟与 ElasticSearch功能类似的其它开源解决方案(比如solr)主要的不同点。其它解决方案也许同样 能或难或易地应用于多节点的分布式环境，但是对对于ElasticSearch来说，工作在分布式环 境就是它每天的生活。由于节点发现机制，它最大程度简化了集群的 安装和配置。

该发现机制主要基于以下假设: 集群由cluster.name设置项相同的节点自动连接而成。 这就允许了同一个网段中存在多个独立的集群。自动发现机制的缺点在于:如果有人忘记改 变cluster.name的设置项，无意中连接到其它的某个集群。在这种情况下，ElasticSearch可能 出于重新平衡集群状态的考虑，将一些数据移动到了新加入的节点。当该节点被关闭，节点 所在的集群中会有部分数据像出现魔法一样凭空消失。

Zen发现机制的故障检测

ElasticSearch运行时会启动两个探测进程。一个进程用于从主节点向集群中其它节点发 送ping请求来检测节点是否正常可用。另一个进程的工作反过来了，其它的节点向主节点发送 ping请求来验证主节点是否正常且忠于职守。

数据迁移怎么做：

为了完成上述的操作，需要执行如下的步 骤:

停止发生在ElasticSearch集群中的数据索引操作(这可能意味着停止rivers或者任何向 ElasticSearch集群发送数据的应用)

用Flush API刷新所有还没有提交的数据。

为集群中的每一个分片至少创建一个拷贝，万一出现问题，也能找回数据。当然，如果希望尽可能简单地解决问题，也可以复制整个集群中每个节点的所有数据作为备用集群。