Elasticsearch之源码分析（shard分片规则）

　　前期博客是

Elasticsearch之源码编译

　　（1）elasticsearch在建立索引时，根据id或(id,类型)进行hash，得到hash值之后再与该索引的分片数量取模，取模的值即为存入的分片编号。
源码：org.elasticsearch.cluster.routing.OperationRouting类中的generateShardId方法
　　（2）可以指定把数据存储到某一个分片中，通过routing参数
　　　　　　curl -XPOST ‘192.168.80.10:9200/zhouls/emp?routing=rout_param‘ -d ‘{"name":"zs","age":20}‘
　　　　　　routing(路由参数)
　　（3）注意：显著提高查询性能，routing，routing，还是 routing

后续更新

时间： 2024-10-06 20:10:39

Elasticsearch之源码分析（shard分片规则）的相关文章

Dubbo 源码分析 - 集群容错之 Router

1. 简介 上一篇文章分析了集群容错的第一部分 – 服务目录 Directory.服务目录在刷新 Invoker 列表的过程中,会通过 Router 进行服务路由.上一篇文章关于服务路由相关逻辑没有细致分析,一笔带过了,本篇文章将对此进行详细的分析.首先,先来介绍一下服务目录是什么.服务路由包含一条路由规则,路由规则决定了服务消费者的调用目标,即规定了服务消费者可调用哪些服务提供者.Dubbo 目前提供了三种服务路由实现,分别为条件路由 ConditionRouter.脚本路由 ScriptRo

elasticsearch源码分析之search模块(client端)

elasticsearch源码分析之search模块(client端) 注意,我这里所说的都是通过rest api来做的搜索,所以对于接收到请求的节点,我姑且将之称之为client端,其主要的功能我们可以简单地概括为将的数据请求发送到node,然后在对返回的结果做处理并返回给调用方,话虽如此,但是过程并非那么简单. 请求初始化 1.api的注册,上一篇已经提到了,所以的api都是通过Guice框架注册进来的,在注册的时候会在controller上将不同的url绑定到不同的handler中: co

ElasticSearch 启动时加载 Analyzer 源码分析

ElasticSearch 启动时加载 Analyzer 源码分析 本文介绍 ElasticSearch启动时如何创建.加载Analyzer,主要的参考资料是Lucene中关于Analyzer官方文档介绍.ElasticSearch6.3.2源码中相关类:AnalysisModule.AnalysisPlugin.AnalyzerProvider.各种Tokenizer类和它们对应的TokenizerFactory.另外还参考了一个具体的基于ElasticSearch采用HanLP进行中文分词的

Kafka 自定义指定消息partition策略规则及DefaultPartitioner源码分析

Kafka 自定义指定消息partition策略规则及DefaultPartitioner源码分析 一.概述 kafka默认使用DefaultPartitioner类作为默认的partition策略规则,具体默认设置是在ProducerConfig类中(如下图) 二.DefaultPartitioner.class 源码分析 1.类关系图 2.源码分析 public class DefaultPartitioner implements Partitioner { //缓存map key->to

sharding-jdbc-core 源码分析

目录 Sharding-Jdbc 源码分析 1. Sharding-Jdbc 包结构 2. JDBC 四大对象 2.1 DataSource 2.2 Connection 2.3 Statement 2.4 ResultSet 3. Sharding-Jdbc 执行流程分析 4. sharding-jdbc-core 任务执行分析 4.1 ShardingStatement 4.2 StatementExecutor Sharding-Jdbc 源码分析 Apache Sharding-Sphe

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三)

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三) 本文是SolrCloud的Recovery策略系列的第三篇文章,前面两篇主要介绍了Recovery的总体流程,以及PeerSync策略.本文以及后续的文章将重点介绍Replication策略.Replication策略不但可以在SolrCloud中起到leader到replica的数据同步,也可以在用多个单独的Solr来实现主从同步.本文先介绍在SolrCloud的leader到replica的数据同步,下一篇

solr源码分析之solrclound

一.简介 SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案.SolrCloud是Solr的基于Zookeeper一种部署方式.Solr可以以多种方式部署,例如单机方式,多机Master-Slaver方式. 二.特色功能 SolrCloud有几个特色功能: 集中式的配置信息使用ZK进行集中配置.启动时可以指定把Solr的相关配置文件上传Zookeeper,多机器共用.这些ZK中的配置不会再拿到本地缓存,Solr直接读取ZK中的配置信息.配置文件的变动,所有

Solr4.8.0源码分析(21)之SolrCloud的Recovery策略(二)

Solr4.8.0源码分析(21)之SolrCloud的Recovery策略(二) 题记:  前文<Solr4.8.0源码分析(20)之SolrCloud的Recovery策略(一)>中提到Recovery有两种策略,一是PeerSync和Replication.本节将具体介绍下PeerSync策略. PeeySync是Solr的优先选择策略,每当需要进行recovery了,Solr总是会先去判断是否需要进入PeerSync,只有当PeerSync被设置为跳过或者PeerSync时候发现没符合

Solr4.8.0源码分析(20)之SolrCloud的Recovery策略(一)

Solr4.8.0源码分析(20)之SolrCloud的Recovery策略(一) 题记: 我们在使用SolrCloud中会经常发现会有备份的shard出现状态Recoverying,这就表明SolrCloud的数据存在着不一致性,需要进行Recovery,这个时候的SolrCloud建索引是不会写入索引文件中的(每个shard接受到update后写入自己的ulog中).关于Recovery的内容包含三篇,本文是第一篇介绍Recovery的原因以及总体流程. 1. Recovery的起因 Rec