概念&＃xff1a;
Term: 它是搜索的基本单位&＃xff0c;其表现形式为文本中的一个词。
Token: 它是单个Term在所属Field中文本的呈现形式&＃xff0c;包含了Term内容、Term类型、Term在文本中的起始及偏移位置。
此 外&＃xff0c;每个词映射着一个数值(Count)&＃xff0c;它代表着Term在文档集中出现的频繁程度。
| Term | count | Docs |
| Cookbook | 1 | <3> |
指 Cookbook在文档3中出现一次。当然&＃xff0c;Lucene创建的真实索引远比上文复杂和先进
每个索引被分成了多个段(Segment)&＃xff0c;段具有一次写入&＃xff0c;多次读取的特点。只要形成了&＃xff0c; 段就无法被修改。例如:被删除文档的信息被存储到一个单独的文件&＃xff0c;但是其它的段文件并 没有被修改。
文本分析工作由analyzer组件负责。analyzer由一个分词器(tokenizer)和0个或者多个过 滤器(filter)组成,也可能会有0个或者多个字符映射器(character mappers)组成。
Lucene中的tokenizer用来把文本拆分成一个个的Token。Token包含了比较多的信息&＃xff0c; 比如Term在文本的中的位置及Term原始文本&＃xff0c;以及Term的长度。
如果用户的Document中有title和description 两个Field&＃xff0c;那么这两个Field可以指定不同的analyzer。
有的Query对象会被解析(analyzed)&＃xff0c;有的不会&＃xff0c;比如:前缀查询(prefix query)就不会被解析&＃xff0c;精确匹配查询(match query)就会被解析。对用户来说&＃xff0c;理解这一点至 关重要。
一个Query对象中会存在多个布尔运算符&＃xff0c;这些布尔运算符将多个Term关联起来形成查询子 句。
ElasticSearch 把数据分发到多个存储Lucene索引的物理机上。这些Lucene索引称为分片索引&＃xff0c;这个分发的 过程称为索引分片(Sharding)。在ElasticSearch集群中&＃xff0c;索引分片(Sharding)是自动完成的&＃xff0c; 而且所有分片索引(Shard)是作为一个整体呈现给用户的。需要注意的是&＃xff0c;尽管索引分片这个 过程是自动的&＃xff0c;但是在应用中需要事先调整好参数。因为集群中分片的数量需要在索引创建 前配置好&＃xff0c;而且服务器启动后是无法修改的&＃xff0c;至少目前无法修改。
在运行的过程中&＃xff0c;ElasticSearch会收集集群的状态、索引的参数等信息。这些数据被存 储在Gateway中。
ES背后的核心理念:
自动容错。ElasticSearch通过P2P网络进行通信&＃xff0c;这种工作方式消除了单点故障。节点 自动连接到集群中的其它机器&＃xff0c;自动进行数据交换及以节点之间相互监控。索引分片
ElasticSearch是构建在极少数的几个概念之上的。ElasticSearch的开发团队希望它能够 快速上手&＃xff0c;可扩展性强。而且这些核心特性体现在ElasticSearch的各个方面。从架构的角度 来看&＃xff0c;这些主要特性是:
开箱即用。安装好ElasticSearch后&＃xff0c;所有参数的默认值都自动进行了比较合理的设置&＃xff0c; 基本不需要额外的调整。包括内置的发现机制(比如Field类型的自动匹配)和自动化参数配 置。
天生集群。ElasticSearch默认工作在集群模式下。节点都将视为集群的一部分&＃xff0c;而且在 启动的过程中自动连接到集群中。
自动容错。ElasticSearch通过P2P网络进行通信&＃xff0c;这种工作方式消除了单点故障。节点 自动连接到集群中的其它机器&＃xff0c;自动进行数据交换及以节点之间相互监控。索引分片
扩展性强。无论是处理能力和数据容量上都可以通过一种简单的方式实现扩展&＃xff0c;即增添 新的节点。
近实时搜索和版本控制。由于ElasticSearch天生支持分布式&＃xff0c;所以延迟和不同节点上数 据的短暂性不一致无可避免。ElasticSearch通过版本控制(versioning)的机制尽量减少问 题的出现。
在集群中&＃xff0c;一个节点被选举成主节点(master node)。这个节点负责管理集群的状态&＃xff0c;当 群集的拓扑结构改变时把索引分片分派到相应的节点上。
主节点在ElasticSearch中并没有占据着重要的地位
任何节点都可以并发地把查询子句分发到其它的节点&＃xff0c;然后合并各个节点返回的查询结果
对于每个丢失的主分片&＃xff0c;新的主分片将从剩余的分片 副本(Replica)中选举出来
主节点向其它的节点发送Ping命令然后等待回应。如果没有得 到回应(实际上可能得不到回复的Ping命令个数取决于用户配置)&＃xff0c;该节点就会被移出集群。
如果索引数据的请求发送到的节点没有合适的分片或者分片是副本&＃xff0c;那 么请求会被转发到含有主分片的节点。
Lucene默认的打分机制:TF/IDF(term frequency/inverse document frequecy)算法
基本上&＃xff0c;从前面的公式中可以提炼出以下的几个规则:
匹配到的关键词越稀有&＃xff0c;文档的得分就越高。
文档的域越小(包含比较少的Term)&＃xff0c;文档的得分就越高。
设置的权重(索引和搜索时设置的都可以)越大&＃xff0c;文档得分越高。
索引分片机制用来存储超过单个节点存储容量的数据&＃xff0c;分片副本用来应对不断攀升的吞 吐量以及确保数据的安全性
路由功能向ElasticSearch提供一种信息来决定哪些分片用于存储和 查询
一个重要的配置项&＃xff1a;
cluster.routing.allocation.awareness.attributes:group
决定新节点加入集群后&＃xff0c;如何将p/r shard重新分配。
在集群中使用了shard allocation awareness功能后&＃xff0c;ElasticSearch不会把决定allocation awareness的属性(在本例中是 node.group值)相同的分片或者分片副本分配到同一个节点中。该功能典型的用例是把集群拓 扑结构部署到物理机或者虚拟机时&＃xff0c;确保你的集群不会出现单点故障问题。
分片分配机制不会考虑分配分片到没有设 置node.group属性的节点。
index.routing.allocation.total\_shards\_per\_node属性值为1&＃xff0c;这意味着对于每个索引&＃xff0c; ElasticSearch只会在单个节点上分配一个分片。这应用到我们的4-节点集群的例子中就是每 个节点会平均分配所有的分片。
对于ElasticSearch来说&＃xff0c;最核心的一种配置就是集群恢复配置
重新索引&＃xff1a;
第二个想法是创建第二个索引&＃xff0c;并且添加数据&＃xff0c;然后把应用接口调转到新的索 引。方案可行&＃xff0c;但是有个小问题&＃xff0c;创建新的索引需要额外的空间开销。
我们已经多次提到&＃xff0c;ElasticSearch创建的目的就是对应集群工作环境。这是跟与 ElasticSearch功能类似的其它开源解决方案(比如solr)主要的不同点。其它解决方案也许同样 能或难或易地应用于多节点的分布式环境&＃xff0c;但是对对于ElasticSearch来说&＃xff0c;工作在分布式环 境就是它每天的生活。由于节点发现机制&＃xff0c;它最大程度简化了集群的 安装和配置。
该发现机制主要基于以下假设: 集群由cluster.name设置项相同的节点自动连接而成。 这就允许了同一个网段中存在多个独立的集群。自动发现机制的缺点在于:如果有人忘记改 变cluster.name的设置项&＃xff0c;无意中连接到其它的某个集群。在这种情况下&＃xff0c;ElasticSearch可能 出于重新平衡集群状态的考虑&＃xff0c;将一些数据移动到了新加入的节点。当该节点被关闭&＃xff0c;节点 所在的集群中会有部分数据像出现魔法一样凭空消失。
Zen发现机制的故障检测
ElasticSearch运行时会启动两个探测进程。一个进程用于从主节点向集群中其它节点发 送ping请求来检测节点是否正常可用。另一个进程的工作反过来了&＃xff0c;其它的节点向主节点发送 ping请求来验证主节点是否正常且忠于职守。
数据迁移怎么做&＃xff1a;
为了完成上述的操作&＃xff0c;需要执行如下的步 骤:
停止发生在ElasticSearch集群中的数据索引操作(这可能意味着停止rivers或者任何向 ElasticSearch集群发送数据的应用)
用Flush API刷新所有还没有提交的数据。
为集群中的每一个分片至少创建一个拷贝&＃xff0c;万一出现问题&＃xff0c;也能找回数据。当然&＃xff0c;如果希望尽可能简单地解决问题&＃xff0c;也可以复制整个集群中每个节点的所有数据作为备用集群。
京公网安备 11010802041100号