0%

elasticsearch分片

elasticsearch分片

索引其实只是一个用来指向一个或多个分片shard的逻辑命名空间,文档是保存在索引的分片中,然后在分片中被索引,分配到集群中的节点上

分片又分为主分片和复制分片,复制分片是主分片的一个副本,可以防止硬件故障导致的数据丢失,当索引创建好的时候主分片的数量就已经确认好了,而复制分片可以随时调整

1
2
3
4
5
6
{
"settings":{
"number_of_shards": 5, //五个主分片
"number_of_replicas": 0 // 0个复制分片,这里是因为我使用的是单机,所以没有设置复制分片
}
}

分片设置问题

如果主分片过多会导致批量写入或查询时请求被分割成过多的子请求,导致索引写入、查询拒绝率上升;如果主分片过少,会影响写入或查询效率。

路由机制

由于elasticsearch索引中包含多个分片,那么elasticsearch在查询时如何知道文档属于哪个分片?这就是elasticsearch的路由机制。

elasticsearch的路由机制是通过哈希算法,将具有相同哈希值的文档放置到通一个主分片中

shard = hash(routing) % number_of_primary_shards

所以创建好主分片之后就不能再修改了,否则之前路由的值就无效了,找不到对应的文档了

默认是将文档id作为routing,这也导致了elasticsearch事先并不确定文档的位置,所以会将请求广播到所有的主分片上去执行,会导致部分的性能问题。当然elasticsearch也可以自定义routing值,这就使得查询更具目的性,不必盲目的广播查询请求

elasticsearch的index、get、mget、delete、update等文档操作API都可以接收一个routing参数

1
GET /index1/_search?routing=WEDXCVG

这样就避免了elasticsearch向所有的分片都发送请求了,减少了系统资源的消耗

自定义路由会有数据偏移的问题

欢迎关注我的其它发布渠道