Elasticsearch的路由(Routing)特性

原创 2014年10月14日 16:54:50

Elasticsearch路由机制介绍

Elasticsearch的路由机制与其分片机制有着直接的关系。Elasticsearch的路由机制即是通过哈希算法,将具有相同哈希值的文档放置到同一个主分片中。这个和通过哈希算法来进行负载均衡几乎是一样的。


而Elasticsearch也有一个默认的路由算法:它会将文档的ID值作为依据将其哈希到相应的主分片上,这种算法基本上会保持所有数据在所有分片上的一个平均分布,而不会产生数据热点。


而我们为什么会需要自定义的Routing模式呢?首先默认的Routing模式在很多情况下都是能满足我们的需求的——平均的数据分布、对我们来说是透明的、多数时候性能也不是问题。但是在我们更深入地理解我们的数据的特征之后,使用自定义的Routing模式可能会给我们带来更好的性能。


假设你有一个100个分片的索引。当一个请求在集群上执行时会发生什么呢?

1. 这个搜索的请求会被发送到一个节点

2. 接收到这个请求的节点,将这个查询广播到这个索引的每个分片上(可能是主分片,也可能是复制分片)

3. 每个分片执行这个搜索查询并返回结果

4. 结果在通道节点上合并、排序并返回给用户


因为默认情况下,Elasticsearch使用文档的ID(类似于关系数据库中的自增ID,当然,如果不指定ID的话,Elasticsearch使用的是随机值)将文档平均的分布于所有的分片上,这导致了Elasticsearch不能确定文档的位置,所以它必须将这个请求广播到所有的100个分片上去执行。这同时也解释了为什么主分片的数量在索引创建的时候是固定下来的,并且永远不能改变。因为如果分片的数量改变了,所有先前的路由值就会变成非法了,文档相当于丢失了。


而自定义的Routing模式,可以使我们的查询更具目的性。我们不必盲目地去广播查询请求,取而代之的是:我们要告诉Elasticsearch我们的数据在哪个分片上。


原来的查询语句:“请告诉我,USER1的文档数量一共有多少”

使用自定义Routing(在USESR ID上)后的查询语句:“请告诉我,USER1的文档数量一共有多少,它就在第三个分片上,其它的分片就不要去扫描了”


指定个性化路由

所有的文档API(get,index,delete,update和mget)都能接收一个routing参数,可以用来形成个性化文档分片映射。一个个性化的routing值可以确保相关的文档存储到同样的分片上——比如,所有属于同一个用户的文档。


第一种方法,也是比较直观的方法就是直接在请求的URL中指定routing参数:

curl -XPOST 'http://localhost:9200/store/order?routing=user123' -d '
{
    "productName": "sample",
    "customerID": "user123"
}'

这样我们就按照用户的customerID的值将具有相同customerID的文档置于同一分片上了。


第二种方法就是直接从文档中提取到对应的路由值:

curl -XPUT 'http://localhost:9200/store/order/_mapping' -d '
{
    "order": {
        "_routing": {
            "required": true,
            "path": "customerID"
        }
    }
}'

这样的方法和第一种方法在效果上一样的,但是有一点需要注意,相比于第一种方法这种方法的效率稍低,因为第一种方法直接就在请求的参数中确定了路由的值,而第二种方法中,首先需要将文档读入之后,再从中提取到对应的路由值。


利用路由机制的查询

利用路由机制的查询也是非常简单明了的,只需要在查询中指定对应的路由值即可:

curl -XGET 'http://localhost:9200/store/order/_search?routing=user123' -d '
{
    "query": {
        "filtered": {
            "query": {
                "match_all": {}
            },
            "filter": {
                "term": {
                    "userID": "user123"
                }
            }
        }
    }
}'

通过指定的路由值,我们就可以直接定位到user123的文档所在的分片,而不用一股脑的向索引的所有节点都发送请求。这样的话,会大大减少系统资源的浪费。


当然,也可以同时指定多个路由值,方法也是显而易见的,只需要在查询参数中指定多个路由值即可:

curl -XGET 'http://localhost:9200/forum/posts/?routing=Admin,Moderator' -d '{}'


路由机制的总结

实际上,如果不明确指明使用路由机制,实际上路由机制也是在发挥作用的,只是默认的路由值是文档的id而已。而个性化路由的需求主要是和业务相关的。默认的路由(如果是自动的生成的id)直观上会把所有的文档随机分配到一个分片上,而个性化的路由值就是和业务相关的了。这也会造成一些潜在的问题,比如user123本身的文档就非常多,有数十万个,而其他大多数的用户只有几个文档,这样的话就会导致user123所在的分片较大,出现数据偏移的情况,特别是多个这样的用户处于同一分片的时候,现象会更明显。具体的使用还是要结合实际的应用场景来选择的。

版权声明:本文为博主原创文章,转载请注明出处,Thanks~

相关文章推荐

Golang适合高并发场景的原因分析

典型的两个现实案例: 我们先看两个用Go做消息推送的案例实际处理能力。 360消息推送的数据: 16台机器,标配:24个硬件线程,64GB内存 Linux Kernel 2.6.32 x8...

ElasticSearch里面的路由功能介绍

在ElaticSearch里面,路由功能算是一个高级用法,大多数时候我们用的都是系统默认的路由功能,我们知道一个es索引可以分多个shard和每个shard又可以有多个replia,那么现在思考一个问...

Elasticsearch模块功能之-路由(routing)

索引分片分配能够控制索引分片在节点上怎么分布,那对于具体的文档能否控制具体节点的分布呢?答案是可以,根据路由公式shard = hash(routing) % number_of_primary_sh...

ElasticSearch路由哈希算法的实现

当收到一个建立索引请求时,ElasticSearch首先要做的事就是决定在哪一个shard上对其进行索引。ElasticSearch使用djb2哈希算法对指定或者默认的key进行哈希,然后mod索引中...

elasticsearch 自定义hash function (routing)

本次研究基于elastic search verison 2.1.1 为何想要自定义hash function? 本意是想提高elasticsearch的indexing速度。 具体思路就是: 1.将...

elasticsearch文档-字段的mapping

原文链接

Elasticsearch Java API总汇

三、Elasticsearch Java API 3.1 集群的连接 3.1.1 作为Elasticsearch节点 代码:          import static org.elasti...

Elasticsearch笔记九之优化

elasticsearch优化,极速查询

Elasticsearch中setting,mapping,分片查询方式

原文地址:http://blog.csdn.net/ty4315/article/details/52477559?utm_source=itdadao&utm_medium=referral s...

Elasticsearch 分片交互过程分析

http://my.oschina.net/galenz/blog/422189 一、Elasticseach如何将数据存储到分片中 问题:当我们要在ES中存储数据的时候,数据应该...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)