Elasticsearch的路由(Routing)特性

标签: elasticsearch 路由 routing | 发表时间:2017-09-28 08:52 | 作者:weitao1026
出处:http://www.iteye.com

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参数:

[plain] view plain copy
 
print ?
  1. curl -XPOST 'http://localhost:9200/store/order?routing=user123' -d '  
  2. {  
  3.     "productName": "sample",  
  4.     "customerID": "user123"  
  5. }'  
curl -XPOST 'http://localhost:9200/store/order?routing=user123' -d '
{
    "productName": "sample",
    "customerID": "user123"
}'


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

 

 

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

[plain] view plain copy
 
print ?
  1. curl -XPUT 'http://localhost:9200/store/order/_mapping' -d '  
  2. {  
  3.     "order": {  
  4.         "_routing": {  
  5.             "required": true,  
  6.             "path": "customerID"  
  7.         }  
  8.     }  
  9. }'  
curl -XPUT 'http://localhost:9200/store/order/_mapping' -d '
{
    "order": {
        "_routing": {
            "required": true,
            "path": "customerID"
        }
    }
}'


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

 

 

利用路由机制的查询

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

[plain] view plain copy
 
print ?
  1. curl -XGET 'http://localhost:9200/store/order/_search?routing=user123' -d '  
  2. {  
  3.     "query": {  
  4.         "filtered": {  
  5.             "query": {  
  6.                 "match_all": {}  
  7.             },  
  8.             "filter": {  
  9.                 "term": {  
  10.                     "userID": "user123"  
  11.                 }  
  12.             }  
  13.         }  
  14.     }  
  15. }'  
curl -XGET 'http://localhost:9200/store/order/_search?routing=user123' -d '
{
    "query": {
        "filtered": {
            "query": {
                "match_all": {}
            },
            "filter": {
                "term": {
                    "userID": "user123"
                }
            }
        }
    }
}'


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

 

 

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

[plain] view plain copy
 
print ?
  1. curl -XGET 'http://localhost:9200/forum/posts/?routing=Admin,Moderator' -d '{}'  
curl -XGET 'http://localhost:9200/forum/posts/?routing=Admin,Moderator' -d '{}'



 

路由机制的总结

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



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [elasticsearch 路由 routing] 推荐:

Elasticsearch的路由(Routing)特性

- - 企业架构 - ITeye博客
Elasticsearch路由机制介绍. Elasticsearch的路由机制与其分片机制有着直接的关系. Elasticsearch的路由机制即是通过哈希算法,将具有相同哈希值的文档放置到同一个主分片中. 这个和通过哈希算法来进行负载均衡几乎是一样的. 而Elasticsearch也有一个默认的路由算法:它会将文档的ID值作为依据将其哈希到相应的主分片上,这种算法基本上会保持所有数据在所有分片上的一个平均分布,而不会产生数据热点.

[译]elasticsearch mapping

- - an74520的专栏
es的mapping设置很关键,mapping设置不到位可能导致索引重建. 请看下面各个类型介绍^_^. 每一个JSON字段可以被映射到一个特定的核心类型. JSON本身已经为我们提供了一些输入,支持 string,  integer/ long,  float/ double,  boolean, and  null..

Elasticsearch as Database - taowen - SegmentFault

- -
【北京上地】滴滴出行基础平台部招聘 Elasticsearch 与 Mysql binlog databus 开发工程师. 内推简历投递给: taowen@didichuxing.com. 推销Elasticsearch. 时间序列数据库的秘密(1)—— 介绍. 时间序列数据库的秘密(2)——索引.

ElasticSearch 2 的节点调优(ElasticSearch性能)

- - 行业应用 - ITeye博客
一个ElasticSearch集群需要多少个节点很难用一种明确的方式回答,但是,我们可以将问题细化成一下几个,以便帮助我们更好的了解,如何去设计ElasticSearch节点的数目:. 打算建立多少索引,支持多少应用. elasticsearch版本: elasticsearch-2.x. 需要回答的问题远不止以上这些,但是第五个问题往往是容易被我们忽视的,因为单个ElasticSearch集群有能力支持多索引,也就能支持多个不同应用的使用.

elasticsearch的javaAPI之query

- - CSDN博客云计算推荐文章
elasticsearch的javaAPI之query API. the Search API允许执行一个搜索查询,返回一个与查询匹配的结果(hits). 它可以在跨一个或多个index上执行, 或者一个或多个types. 查询可以使用提供的 query Java API 或filter Java API.

Elasticsearch基础教程

- - 开源软件 - ITeye博客
转自:http://blog.csdn.net/cnweike/article/details/33736429.     Elasticsearch有几个核心概念. 从一开始理解这些概念会对整个学习过程有莫大的帮助.     接近实时(NRT).         Elasticsearch是一个接近实时的搜索平台.

ElasticSearch索引优化

- - 行业应用 - ITeye博客
ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡. 所以从上我可以通过索引的settings进行第一优化:. 这两个参数第一是到tranlog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的. 所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行tranlog平衡.

elasticsearch集群搭建

- - zzm
之前对于CDN的日志处理模型是从 . logstash agent==>>redis==>>logstash index==>>elasticsearch==>>kibana3,对于elasticsearch集群搭建,可以把索引进行分片存储,一个索引可以分成若干个片,分别存储到集群里面,而对于集群里面的负载均衡,副本分配,索引动态均衡(根据节点的增加或者减少)都是elasticsearch自己内部完成的,一有情况就会重新进行分配.

Elasticsearch集群入门

- - 编程语言 - ITeye博客
欢迎来到Elasticsearch的奇妙世界,它是优秀的全文检索和分析引擎. 不管你对Elasticsearch和全文检索有没有经验,都不要紧. 我们希望你可以通过这本书,学习并扩展Elasticsearch的知识. 由于这本书也是为初学者准备的,我们决定先简单介绍一般性的全文检索概念,接着再简要概述Elasticsearch.

Elasticsearch 学习笔记

- - 研发管理 - ITeye博客
安装  Elasticsearch. 1:解压下载的安装包 elasticsearch-1.7.2.zip. 修改  node.name: es(集群状态名字一致). 2:在https://github.com/elasticsearch/elasticsearch-servicewrapper下载该插件后,解压缩.