封面图:《请问您今天要来点兔子吗?》
内容目录
1.搭建Kibana2.集群健康3.索引操作
1.搭建Kibana
正如《Kibana 用户手册》中所介绍,Kibana 是一款开源的数据分析和可视化平台,因此我们可以借助 Kibana 来与Elasticsearch(简称ES) 交互。
下载并解压:
cd /usr/local
wget https://artifacts.elastic.co/downloads/kibana/kibana-6.6.1-linux-x86_64.tar.gz
tar -zxvf kibana-6.6.1-linux-x86_64.tar.gz -C .
启动Kibana:
cd kibana-6.6.1-linux-x86_64/
bin/kibana
Kibana 所指向ES的地址默认为localhost,该配置在config/kibana.yml
,若需要修改,可修改该配置文件。
Kibana 启动成功,我们便可以在 Dev Tools菜单下的Console中写 ES命令了,Kibana 的其他功能我们以后再做介绍。
2.集群健康
在进行索引操作之前,我们有必要先了解一下 ES集群的健康情况,这将有助于我们看懂索引操作的命令执行之后的运行结果。
查看集群的健康情况:GET _cluster/health
结果:
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 1,
"active_shards" : 1,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
从结果中我们可以看出当前集群的健康情况为 green,active_shards_percent_as_number 为 100.0,两者什么意思呢,有没有必然的联系呢?答案当然是有的。
正常情况下,集群的健康状态分为green、yellow、red三种。
green:每个Index的primary shard (即shard)和replica shard(即replica)都是active状态,都已经分配好。集群100%可用
yellow:每个Index的primary shard均为active状态,但至少还有一个replica shard不是active状态。此时数据没有丢失,集群仍然可用
red:至少一个primary shard不是active状态,它的全部replica shard也已缺失。此时数据已经发生了丢失,搜索时只会返回部分的数据
当集群状态非green时,我们可以使用 GET _cluster/health?level=indices
命令查看各个Index的细节,进而定位具体哪一个索引出现了问题,以便解决问题。
输出中的relocating_shards为0表明当前没有分片正在从一个节点迁移至其他节点。为什么会出现分片迁移这种情况呢?因为ES是一个分布式搜索分析引擎,而分布式往往对应着海量数据,ES实现了shard负载均衡的功能,当添加新节点或者下线已有节点时,ES的集群发现机制会自动将shard进行均匀分配(由ES中的 decider 决定,它们是ES中作出分配决定的最高指挥,当使用多个decider 时,若其中一个decider通过投票不赞成重新分配一个分片,那该分片就不能移动了),以保证各个节点上的shard 数几乎相等,可以均衡的处理各种请求。所以一般情况下relocating_shards的值均为0。
那么什么情况下会出现initializing_shards不为0的情况呢?节点刚刚重启时、刚刚创建分片时等。
unassigned_shards又是一个什么状态呢?就是分片已经在集群状态中,但是在实际集群中你又找不到这个分片。例如:两个节点,一共有2个primary shard,每个primary shard又有两个replica shard,假设节点1中存在primary shard R0、replica shard R1,节点2中存在primary shard R1,replica shard R0,那么此时就会有2个replica shard未分配,因为replica shard既不能和自己的primary shard在同一个节点,又不能够和自己的primary shard的其他replica shard在同一个节点上(even_shard分片分配器决定),此时unassigned_shards就为2。一般未分配的分片都是replica shard。
此外,我们也可以借助ES的cat API查看集群的健康情况,不过cat API的输出结果并不是以json格式返回的,而是以不带表头的表格形式返回的,为了方便理解,我们可以通过添加参数v来将表头也输出出来。GET _cat/health?v
结果:
3.索引操作
查询索引:
GET _cat/indices?v
结果:
从结果中我们可以看到索引的健康情况、状态、索引名称、uuid、primary shard个数、replica shard个数、document 个数、被标记为deleted的document 的个数,索引大小、primary shard大小。
创建索引:
PUT /indexName
在创建索引时可以指定primary shard的个数,也可以指定一个primary shard配置几个replica shard。若不指定,则默认一个索引 10个shard,其中5个primary shard,5个replica shard,即使是单节点环境也会如此,这种就是典型的over allocation。如果你知道明确的要放入ES 中的数据集,最好在创建索引时指定一下所需的primary shard 个数及其replica shard个数;否则则需要根据节点数来做决定。
举例:创建索引order,并指定其包含3个primary shard,每个primary shard配置2个replica shard:
PUT /orders
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 2
}
}
一旦索引创建成功,则primary shard的个数就不能再修改了,replica shard的个数随时可以修改。因为ES是根据下面的路由算法来计算得出该document 应该存放在哪个shard 中的,为了保证在搜索document 时得出与存放时相同的路由值,故一旦索引创建成功,则primary shard的个数不能再修改。shard = hash(routing) % number_of_primary_shards
当对document 进行增删改查操作时,默认会带一个routing 值,这个值默认为document 的_id,当然也可以通过routing参数指定routing的值。
每个document 仅会存在于一个primary shard 及其 replica shard中,不同primary shard 上保存的document 都是不同的。
当数据量特别大,需要扩容时,我们一般采用水平扩容的方式,即采购更多相同配置的服务器,而非采用垂直扩容的方式,即增加容量更大、配置更高的服务器。之所以采用水平扩容,一是成本问题,二是使用更多的服务器,可以将shard分散到更多的node上,提高了系统的容错性,每个node上拥有更少的shard,那么cpu等资源也可以分配更多到shard上,三是易于以后再次扩容。
删除索引:
DELETE /indexName
如果这篇文章对你有帮助或启发,欢迎转发/点下在看(不点也行)。