想想我们漏了什么
这篇文章已经是第四篇了,前面很多都只是讲了基础的使用,没有讲到内层的原理,所以这里就要补一下原理知识了。
回顾
先回顾一下我们前面学过了什么,再想想我们漏了什么。
第一篇我们认识了ElasticSearch,大概知道了ElasticSearch的作用--搜索,也了解了一些倒排索引和分词器的知识(需要补充),然后学习了如何搭建环境(需要补充一下关于基础的集群知识),然后讲了一些基础的ElasticSearch概念(重新讲述,加深了解)。
第二篇讲了索引和文档的CRUD,讲创建索引的时候,没有讲mapping,讲文档的时候没有讲文档的数据类型和元数据,这些都需要补充。
第三篇讲了文档的搜索,主要是语法方面的问题,但相关度分数是怎么计算出来的,我们并没有讲。
补回
所以下面将对前面漏了的基础知识进行补充:
- Json文档的数据格式?【我们之前只会弄一个简单的json,而不知道里面有什么区别】
- 集群的基础认识?【我们之前说了ElasticSearch是一个分布式的系统,但我们之前只讲了如何启动,如何使用kibana操作ElasticSearch,并没有讲ElasticSearch的集群式怎么建立的】
- 节点是怎么提供服务的?【我们之前只知道直接发请求,这个请求ElasticSearch是怎么处理的,我们并不知道】
- 索引的mapping?【之前创建索引的时候,没有说清楚mapping,mapping受文档的数据类型影响,mapping影响查询方式和分词方式】
- 相关度分数score是怎么算出来的?【我们知道score是相关度分数,但我们并不知道这个是怎么算出来的】
- 分词器的原理【第一篇讲了一点,现在加深】
集群的建立
我们说了,ElasticSearch是分布式的,但我们之前只说了如何启动ElasticSearch,然后使用Kibana操作ElasticSearch,并没有讲ElasticSearch的集群式如何建立的,所以下面将会讲一下集群的知识。但如何管理集群会单独做成一篇来讲。
集群发现机制
首先,每一个ElasticSearch服务端就是一个集群节点,当我们启动一个elasticsearch时,就相当于启动了一个集群节点。
那么,多个节点之间如何建立联系呢?当我们启动一个节点的时候,这个节点会自动创建一个集群,集群的名称默认为elasticsearch,当我们再次启动一个节点的时候,它首先会尝试寻找名称为elasticsearch的集群,然后加入其中,(所有的都是先尝试寻找,没有再自己创建)。【集群名称可以自行配置,下面讲】
当节点加入到集群中后,这个集群就算是建立起来了。
配置文件
上面讲了集群名称可以自行配置,下面讲一下怎么配置。
ElasticSearch的配置文件是config/elasticsearch.yml,里面有以下几个配置项:
【左边是配置项,右边是值,修改配置也就是修改右边的值】
- 集群名称:
cluster.name: my-application
- 索引存储位置:
path.data: /path/to/data
- 日志存储位置:
path.logs: /path/to/logs
- 绑定的IP地址:
network.host: 192.168.0.1
- 绑定的http端口:
http.port: 9200
- 是否允许使用通配符来标识索引:
action.destructive_requires_name
,true为禁止。
健康状态
当集群建立后,我们可以使用命令来查看集群状态:
GET /_cluster/health
:以json方式显示集群状态
GET /_cat/health?v
:行列式显示集群状态
返回结果解析:- epoch:时间戳
- timestamp:时间
- cluster:集群名
- status:状态
- 集群状态解析看下面。
- node.total:集群中的节点数
- node.data:集群中的数据节点数
- shards:集群中总的分片数量
- pri:主分片数量
- relo:副本分片数量
- init:初始化中的分片数?【不确定,英文是这样的:number of initializing nodes 】
- unassign:没有被分配的分片的数量
- pending_tasks:待处理的任务数
- max_task_wait_time:最大任务等待时间
- activeds_percent:active的分片数量
集群状态解析:
集群状态受当前的primary shared和replica shared的数量影响。
当每个索引的primary shared和replica shared都是active的时候,状态为green;【什么是active?shard是位于节点上的,一个shard被分配到了运行的节点上,那么此时就是active的,如果shard没有分配到节点上,那么就是inactive】
当每个索引的primary shared都是active的,但replica shared不完全是active的时候,状态为yellow;
当每个索引的primary shared不完全是active的时候,此时发生了数据丢失,状态为red。
为什么现在是yellow?
当我们第一次启动的时候,kibana会默认为我们创建一个名为kibana的索引,这个索引的primary shard和replica shard都为1,由于此时只有一个节点,所以会优先分配primary shard,而忽略replica shard(不要忘了基于备份的安全性的shard排斥考虑:主分片和副本分片不能位于同一个节点上),所以此时就符合了“每个索引的primary shared都是active的,但replica shared不全是active的”,所以此时是yellow.
你可以尝试启动多一个elasticsearch节点来调整状态。【当然,我觉得你学到这里了,此时replica shard的数量可能已经变了,所以这里只启动多一个可能已经不够了,具体的下面“分片的管理”讲】
补充:
- 集群的知识还有很多,这里讲集群只是讲了个开头,对于深层的集群管理并没有涉及,将留到后面集群管理篇讲。
小节总结
上面讲了当启动了一个elasticsearch之后,这个节点先