{
“user” : “kimchy”,
“post_date” : “2009-11-15T14:12:12”,
“message” : “trying out Elasticsearch”
}
’
在type后面有一个1表示文档的id,这个id也可以不写,不写默认会自动生成id,请求如下:
curl -X POST “localhost:9200/twitter/_doc?pretty” -H ‘Content-Type: application/json’ -d’
{
“user” : “kimchy”,
“post_date” : “2009-11-15T14:12:12”,
“message” : “trying out Elasticsearch”
}
’
在这个请求中,op_type会被自动设置为create,执行结果如下:
可以看到,此时生成的id是一个字符串。
路由机制
====
Elasticsearch是一个分布式系统,当一个文档要被索引时,该文档会被索引到系统中的某一个分片上,那么到底是哪一个分片呢?在elasticsearch文档读写模型一文中,我们简单介绍过这个话题,但是没有深入探究,这里,就和读者一起来探讨下Elasticsearch中的路由机制。
分片位置的计算公式如下:
position=hash(routing) % numberofprimary_shards
在这里,routing是一个任意字符串,Elasticsearch默认是将文档的id作为routing值,通过hash函数计算后,生成一个数字,这个数字再和主分片的总数取余,得到一个处于 [0,number_of_primary_shards-1]
区间内的数,该数字就是该文档所在的分片。基于这样的映射模式,Elasticsearch不支持索引创建成功后,修改分片数量,即分片数量要一开始就确定好,以后不能修改,否则会导致之前计算出来的position失效(即查找时找不到之前的文档,因此numberofprimary_shards已经变了)。
默认情况下,这种路由机制会通过id将文档平均分配在所有的分片上,这也导致了Elasticsearch无法确定一个文档的具体位置,当有查询请求时,它需要将查询请求广播到所有分片上去执行,这无疑降低的查询的效率,对于这个问题,读者可以使用自定义路由模式去解决,如下请求:
curl -X POST “localhost:9200/twitter/_doc/1?pretty&routing=sang” -H ‘Content-Type: application/json’ -d’
{
“user” : “kimchy”,
“post_date” : “2009-11-15T14:12:12”,
“message” : “trying out Elasticsearch”
}
’
开发者在添加文档时指定路由,在查询的时候也指定路由,这样就可以避免Elasticsearch向所有的分片发送查询请求,减少系统资源的消耗,查询请求如下:
curl -X GET “localhost:9200/twitter/_search?pretty&routing=sang”
不过这种方式又会带来另外一个问题,即路由相同的文档总是被分在同一个分片上,无法做到将文档平均分配在不同的分片上,因此,两种不同的方式,需要读者在开发中根据实际需求进行取舍。
分布式
===
小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
最后
分享一些资料给大家,我觉得这些都是很有用的东西,大家也可以跟着来学习,查漏补缺。
《Java高级面试》
《Java高级架构知识》
《算法知识》
(img-s1ic6qxV-1710690114937)]
《Java高级架构知识》
[外链图片转存中…(img-MQvf2Sna-1710690114937)]
《算法知识》
[外链图片转存中…(img-paGJrL7e-1710690114937)]