轻量级elasticsearch（Elasticsearch的底层模块深入解析之node）

本文目录

• Elasticsearch的底层模块深入解析之node
• 如何读取elasticsearch的分词索引信息

Elasticsearch的底层模块深入解析之node

node module，主要是用来处理各种不同类型的节点的，es有哪些类型的node，另外就是对这些类型的node有些什么特殊的参数，对于一个较大的集群来说，如何去规划和配置各种各样的node

1、node类型

如果我们启动es的一个实例，那么就是启动了一个es node，一些es node就可以组成一个es集群。如果仅仅运行了一个es node，那么也有一个es集群，只是节点数量就是1。

***隐藏网址***

所有的node都知道集群中的其他node，并且可以将客户端的请求转发到适当的节点上去。

节点的类型包含以下几种：

（1）master-eligible node：master候选节点，将node.master设置为true（默认），代表这个node就是master的候选节点，可以被选举为master node，然后控制整个集群。

（2）data node：将node.data设置为true（默认），data node可以存储数据，同时处理这些数据相关的操作，比如CRUD操作，搜索操作，聚合操作，等等。

（3）ingest node：将node.ingest设置为true（默认），ingest node是用来对document写入索引文件之前进行预处理的。可以对每个document都执行一条ingest pipeline，在document写入索引文件之前，先对其数据进行处理和转化。但是如果要执行的ingest操作太过繁重，那么可以规划单独的一批ingest node出来，然后将node.master和node.data都设置为false即可。

（4）tribe node：tribe node可以通过tribe.*相关参数来设置，它是一种特殊的coordinate node，可以连接到多个es集群上去，然后对多个集群执行搜索等操作。

（5）默认情况下，每个node的node.master，node.data，node.ingest都是true，都是master候选节点，也可以作为data node存储和操作数据，同时也可以作为ingest node对数据进行预处理。对于小于20个节点的小集群来说，这种架构是ok的，没问题的。但是如果对于大于20个物理机的集群来说，最好是单独规划出master node、data node和ingest node来。

（6）coordinate node

搜索和bulk等请求可能会涉及到多个节点上的不同shard里的数据，比如一个search请求，就需要两个阶段执行，首先第一个阶段就是一个coordinating node接收到这个客户端的search request。接着，coordinating node会将这个请求转发给存储相关数据的node，每个data node都会在自己本地执行这个请求操作，同时返回结果给coordinating node，接着coordinating node会将返回过来的所有的请求结果进行缩减和合并，合并为一个global结果。

每个node都是一个coordinating node。这就意味着如果一个node，将node.master，node.data，node.ingest全部设置为false，那么它就是一个纯粹的coordinating node，仅仅用于接收客户端的请求，同时进行请求的转发和合并。

如果真的是大集群的话，最好也是单独规划一批node出来，就作为coordinating node，然后让es client全部往这些node上去发送请求。

如果真的是一个大于20个节点的生产集群的话，建议将4种node，master node，data node，ingest node，cooridating node，全部分离开来

集群中有30台机器

master node：3个

ingest node：视具体情况而定，具体是看你的ingest预处理操作有多么的复杂，耗费多少资源，但是一般情况下来说，es ingest node用的比较少的，ingest node也可以不用单独规划一批出来

coordinate node：视具体情况而定，但是对于大集群来说，最好是单独拆几个节点出来，用于接收客户端的请求，3个节点。主要是看你的并发访问量有多大，比如说你的最大的QPS也就是10，或者是100，那么3个节点肯定够了。如果你的QPS是1000，或者是10000，那么可能就要规划，10个coordinate node，或者100个

data node：24个data node，data node肯定是分配的是最多的，主要用来存储数据，执行各种对数据的操作么，资源耗费肯定是最多的

2、master eligible node

（1）master-eligible node的介绍以及配置

master node负责轻量级的集群管理工作，比如创建和删除索引，追踪集群中的每个node，决定如何将shards分配给各个node。对于集群来说，有一个稳定的master node，是非常关键的。然后master-eligible node都有机会被选举为一个master node，同时master node必须有权限访问path.data指定的data目录，因为master node需要在data目录中存储cluster state。

对数据进行index和search操作，会耗费大量的cpu，内存，磁盘io，以及网络io，耗费的是每个node的资源。因此我们必须要确保master node是非常稳定的，而且是压力不大的，对于大集群来说，比较好的办法是划分出单独的master node和data node。如果不拆开的话，一个node又要是data node，要复杂存储数据，处理各种操作，同时又要负责管理集群，可能就会不稳定，出问题。

同时因为默认情况下，master node也能扮演coordinating node的角色，并且将search和index请求路由到对应的data node上去执行，最好是不要让master node来执行这些coordinate操作。因为msater node的稳定运行对于整个集群来说非常重要，比你利用master node资源来执行一些coordinate操作要重要的多。

如果要设置一个node为专门的master-eligible node，需要做如下的设置：

node.master: true
node.data: false
node.ingest: false

（2）通过minimum_master_nodes来避免脑裂问题

要预防数据的丢失，我们就必须设置discovery.zen.minimum_master_nodes参数为一个合理的值，这样的话，每个master-eligible node才知道至少需要多少个master-eligible node才能组成一个集群。

比如说，我们现在有一个集群，其中包含两个master-eligible nodes。然后一个网络故障发生了，这两个节点之间丢失了联络。每个节点都认为当前只有一个master-eligible node，就是它们自己。此时如果discovery.zen.minimum_master_nodes参数的默认值是1，那么每个node就可以让自己组成一个集群，选举自己为master node即可。结果就会导致出现了两个es集群，这就是脑裂现象。即使网络故障解决了，但是这两个master node是不可能重新组成一个集群了。除非某个master eligible node重启，然后自动加入另外一个集群，但是此时写入这个节点的数据就会彻底丢失。

那么如果现在我们有3个master-eligible node，同时将discovery.zen.minimum_master_nodes设置为2.如果网络故障发生了，此时一个网络分区有1个node，另外一个网络分区有2个node，只有一个node的那个网络分区，没法检测到足够数量的master-eligible node，那么此时它就不能选举一个master node出来组成一个新集群。但是有两个node的那个网络分区，它们会发现这里有足够数量的master-eligible node，那么就选举出一个新的master，然后组成一个集群。当网络故障解除之后，那个落单的node就会重新加入集群中。

discovery.zen.minimum_master_nodes，必须设置为master-eligible nodes的quorum，quorum的公式为：(master_eligible_nodes / 2) + 1。

换句话来说，如果有3个master-eligible nodes，那么那个参数就必须设置为(3 / 2) + 1 = 2，比如下面这样：

discovery.zen.minimum_master_nodes: 2

随着集群节点的上线和下限，这个参数都是要重新设置的，可以通过api来设置

此时将master node和data node分离的好处就出来了，一般如果单独规划一个master nodes的话，只要规划固定的3个node是master-eligible node就可以了，那么data node无论上线和下限多少个，都无所谓的。

3、data node

data node负责存储shard的数据，也就是那些document。data node可以处理各种操作，比如CRUD，搜索，聚合。这些操作全都是很耗费IO，内存和cpu资源的。因此监控这些资源的使用是很重要的，同时如果资源过载了，那么就要添加更多的data node。

如果要设置一个专门的data node，需要做出如下的设置：

node.master: false
node.data: true
node.ingest: false

4、ingest node

nigest node可以执行预处理pipeline，包含了多个ingest processors。不同的ingest processor执行的操作类型是不同的，那么对资源的需求也是不同的，不过还是最好是规划一批单独的ingest node出来，不要跟master node和data node混合在一起。

如果要配置一个单独的ingest node：

node.master: false
node.data: false
node.ingest: true
search.remote.connect: false

5、cooridnating only node

如果我们规划了一批专门的master node，data node以及ingest node，那么此时还遗留下来了一种node，那就是coordinating node，这些node专门用来接收客户端的请求，同时对请求进行路由和转发，并对请求的结果进行合并。

coordinating only nodes对于大集群来说，可以使用专门的node来负载coordinate操作，而不是让coordinate操作的工作负载集中到master node和data node上去。coordinating node也会加入cluster，同时可以获取到完整的cluster state，它们主要是用cluster state中包含的node info来进行请求转发。

如果在一个集群中规划太多的coordinating node可能会加重整个集群的负担，因为被选举出来的master node必须要从所有的node上得到cluster state update的ack，如果coordinating nodes过多，那么可能会加重master node的负担。

如果要设置coordinating only node的话：

node.master: false
node.data: false
node.ingest: false
search.remote.connect: false

6、node data path设置

（1）path.data

每个data和master-eligible node都需要能够访问data目录，在那里存储了每个shard的数据，包括cluster state也存储在那里。path.data默认是指向$ES_HOME/data目录的，但是在生产环境中，肯定是不能这样设置的，因为在升级es的时候，可能会导致数据被清空或者覆盖。

此时一般需要在elasticsearch.yml中设置path.data：

path.data: /var/elasticsearch/data

（2）node.max_local_storage_nodes

data目录可以被多个node共享，即使是不同集群中的es node，也许他们在一个物理机上启动了。这个共享的方式对于我们测试failover是很有用的，以及在开发机上测试不同的配置。但是在生产环境下，绝对不用这么做，一个data目录就给一个es node使用即可。默认情况下，es被配置成阻止超过一个node共享data目录中的数据，如果要允许多个node共享一个data目录，需要设置node.max_local_storage_nodes为一个超过1的数字。

如何读取elasticsearch的分词索引信息

一、插件准备
网上有介绍说可以直接用plugin -install medcl/elasticsearch-analysis-ik的办法，但是我执行下来的效果只是将插件的源码下载下来，elasticsearch只是将其作为一个_site插件看待。
所以只有执行maven并将打包后的jar文件拷贝到上级目录。（否则在定义mapping的analyzer的时候会提示找不到类的错误）。
由于IK是基于字典的分词，所以还要下载IK的字典文件，在medcl的elasticsearch-RTF中有，可以通过这个地址下载：
下载之后解压缩到config目录下。到这里，你可能需要重新启动下elasticsearch，好让下一部定义的分词器能立即生效。
二、分词定义
分词插件准备好之后就可以在elasticsearch里定义（声明）这个分词类型了（自带的几个类型，比如standred则不需要特别定义）。跟其他设置一样，分词的定义也可以在系统级（elasticsearch全局范围），也可以在索引级（只在当前index内部可见）。系统级的定义当然是指在conf目录下的
elasticsearch.yml文件里定义，内容大致如下：
index:
analysis:
analyzer:
ikAnalyzer:
alias:
type: org.elasticsearch.index.analysis.IkAnalyzerProvider
或者 index.analysis.analyzer.ik.type : "ik"
因为个人喜好，我并没有这么做， 而是定义在了需要使用中文分词的index中，这样定义更灵活，也不会影响其他index。
在定义analyze之前，先关闭index。其实并不需要关闭也可以生效，但是为了数据一致性考虑，还是先执行关闭。（如果是线上的系统需要三思）
curl -XPOST
(很显然，这里的application是我的一个index）
然后执行：
curl -XPUT localhost:9400/application/_settings -d ’
{
"analysis": {
"analyzer":{
"ikAnalyzer":{
"type":"org.elasticsearch.index.analysis.IkAnalyzerProvider",
"alias":"ik"
}
}
}
}
’
打开index：
curl -XPOST
到此为止一个新的类型的分词器就定义好了，接下来就是要如何使用了
或者按如下配置
curl -XPUT localhost:9200/indexname -d ’{
"settings" : {
"analysis" : {
"analyzer" : {
"ik" : {
"tokenizer" : "ik"
}
}
}
},
"mappings" : {
"article" : {
"dynamic" : true,
"properties" : {
"title" : {
"type" : "string",
"analyzer" : "ik"
}
}
}
}
}’
如果我们想返回最细粒度的分词结果，需要在elasticsearch.yml中配置如下：
index:
analysis:
analyzer:
ik:
alias:
type: org.elasticsearch.index.analysis.IkAnalyzerProvider
ik_smart:
type: ik
use_smart: true
ik_max_word:
type: ik
use_smart: false
三、使用分词器
在将分词器使用到实际数据之前，可以先测验下分词效果：
中文分词
分词结果是：
{
"tokens" : [ {
"token" : "中文",
"start_offset" : 0,
"end_offset" : 2,
"type" : "CN_WORD",
"position" : 1
}, {
"token" : "分词",
"start_offset" : 2,
"end_offset" : 4,
"type" : "CN_WORD",
"position" : 2
} ]
}
与使用standard分词器的效果更合理了：
{
"tokens" : [ {
"token" : "中",
"start_offset" : 0,
"end_offset" : 1,
"type" : "《IDEOGRAPHIC》",
"position" : 1
}, {
"token" : "文",
"start_offset" : 1,
"end_offset" : 2,
"type" : "《IDEOGRAPHIC》",
"position" : 2
}, {
"token" : "分",
"start_offset" : 2,
"end_offset" : 3,
"type" : "《IDEOGRAPHIC》",
"position" : 3
}, {
"token" : "词",
"start_offset" : 3,
"end_offset" : 4,
"type" : "《IDEOGRAPHIC》",
"position" : 4
} ]
}
新的分词器定义完成，工作正常后就可以在mapping的定义中引用了，比如我定义这样的type：
curl localhost:9400/application/article/_mapping -d ’
{
"article": {
"properties": {
"description": {
"type": "string",
"indexAnalyzer":"ikAnalyzer",
"searchAnalyzer":"ikAnalyzer"
},
"title": {
"type": "string",
"indexAnalyzer":"ik",
"searchAnalyzer":"ik"
}
}
}
}
’
很遗憾，对于已经存在的index来说，要将一个string类型的field从standard的分词器改成别的分词器通常都是失败的：
{
"error": "MergeMappingException has
different search_analyzer]}]",
"status": 400
}
而且没有办法解决冲突，唯一的办法是新建一个索引，并制定mapping使用新的分词器（注意要在数据插入之前，否则会使用elasticsearch默认的分词器）
curl -XPUT localhost:9400/application/article/_mapping -d ’
{
"article" : {
"properties" : {
"description": {
"type": "string",
"indexAnalyzer":"ikAnalyzer",
"searchAnalyzer":"ikAnalyzer"
},
"title": {
"type": "string",
"indexAnalyzer":"ik",
"searchAnalyzer":"ik"
}
}
}
}
至此，一个带中文分词的elasticsearch就算搭建完成。 想偷懒的可以下载medcl的elasticsearch-RTF直接使用，里面需要的插件和配置基本都已经设置好。
------------
标准分词（standard）配置如下：
curl -XPUT localhost:9200/local -d ’{
"settings" : {
"analysis" : {
"analyzer" : {
"stem" : {
"tokenizer" : "standard",
"filter" :
}
}
}
},
"mappings" : {
"article" : {
"dynamic" : true,
"properties" : {
"title" : {
"type" : "string",
"analyzer" : "stem"
}
}
}
}
}’
index:local
type:article
default analyzer:stem (filter:小写、停用词等)
field:title　　
测试：
# Sample Analysis
curl -XGET localhost:9200/local/_analyze?analyzer=stem -d ’{Fight for your life}’
curl -XGET localhost:9200/local/_analyze?analyzer=stem -d ’{Bruno fights Tyson tomorrow}’

# Index Data
curl -XPUT localhost:9200/local/article/1 -d’{"title": "Fight for your life"}’
curl -XPUT localhost:9200/local/article/2 -d’{"title": "Fighting for your life"}’
curl -XPUT localhost:9200/local/article/3 -d’{"title": "My dad fought a dog"}’
curl -XPUT localhost:9200/local/article/4 -d’{"title": "Bruno fights Tyson tomorrow"}’

# search on the title field, which is stemmed on index and search
curl -XGET localhost:9200/local/_search?q=title:fight

# searching on _all will not do anystemming, unless also configured on the mapping to be stemmed...
curl -XGET localhost:9200/local/_search?q=fight
例如：
Fight for your life
分词如下：
{"tokens":[
{"token":"fight","start_offset":1,"end_offset":6,"type":"《ALPHANUM》","position":1},《br》
{"token":"your","start_offset":11,"end_offset":15,"type":"《ALPHANUM》","position":3},《br》
{"token":"life","start_offset":16,"end_offset":20,"type":"《ALPHANUM》","position":4}
]}
-------------------另一篇--------------------
ElasticSearch安装ik分词插件
一、IK简介
IK Analyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始， IKAnalyzer已经推出了4个大版本。最初，它是以开源项目Luence为应用主体的，结合词典分词和文法分析算法的中文分词组件。从3.0版本开 始，IK发展为面向Java的公用分词组件，独立于Lucene项目，同时提供了对Lucene的默认优化实现。在2012版本中，IK实现了简单的分词 歧义排除算法，标志着IK分词器从单纯的词典分词向模拟语义分词衍化。
IK Analyzer 2012特性:
1.采用了特有的逗正向迭代最细粒度切分算法逗，支持细粒度和智能分词两种切分模式；
2.在系统环境：Core2 i7 3.4G双核，4G内存，window 7 64位， Sun JDK 1.6_29 64位 普通pc环境测试，IK2012具有160万字/秒（3000KB/S）的高速处理能力。
3.2012版本的智能分词模式支持简单的分词排歧义处理和数量词合并输出。
4.采用了多子处理器分析模式，支持：英文字母、数字、中文词汇等分词处理，兼容韩文、日文字符
5.优化的词典存储，更小的内存占用。支持用户词典扩展定义。特别的，在2012版本，词典支持中文，英文，数字混合词语。
二、安装IK分词插件
假设读者已经安装好ES，如果没有的话，请参考ElasticSearch入门 —— 集群搭建。安装IK分词需要的资源可以从这里下载，整个安装过程需要三个步骤：
1、获取分词的依赖包
通过git clone ，下载分词器源码，然后进入下载目录，执行命令：mvn clean package，打包生成elasticsearch-analysis-ik-1.2.5.jar。将这个jar拷贝到ES_HOME/plugins/analysis-ik目录下面，如果没有该目录，则先创建该目录。
2、ik目录拷贝
将下载目录中的ik目录拷贝到ES_HOME/config目录下面。
3、分词器配置
打开ES_HOME/config/elasticsearch.yml文件，在文件最后加入如下内容：
index:
analysis:
analyzer:
ik:
alias:
type: org.elasticsearch.index.analysis.IkAnalyzerProvider
ik_max_word:
type: ik
use_smart: false
ik_smart:
type: ik
use_smart: true
或
index.analysis.analyzer.default.type: ik
ok！插件安装已经完成，请重新启动ES，接下来测试ik分词效果啦！
三、ik分词测试
1、创建一个索引，名为index。
curl -XPUT
2、为索引index创建mapping。
curl -XPOST /fulltext/_mapping -d’
{
"fulltext": {
"_all": {
"analyzer": "ik"
},
"properties": {
"content": {
"type" : "string",
"boost" : 8.0,
"term_vector" : "with_positions_offsets",
"analyzer" : "ik",
"include_in_all" : true
}
}
}
}’
3、测试
curl ’/_analyze?analyzer=ik&pretty=true’ -d ’
{
"text":"世界如此之大"
}’
显示结果如下：
{
"tokens" : [ {
"token" : "text",
"start_offset" : 4,
"end_offset" : 8,
"type" : "ENGLISH",
"position" : 1
}, {
"token" : "世界",
"start_offset" : 11,
"end_offset" : 13,
"type" : "CN_WORD",
"position" : 2
}, {
"token" : "如此",
"start_offset" : 13,
"end_offset" : 15,
"type" : "CN_WORD",
"position" : 3
}, {
"token" : "之大",
"start_offset" : 15,
"end_offset" : 17,
"type" : "CN_WORD",
"position" : 4
} ]
}