es表结构如下:PUT demo/
{
"mappings": {
"demo": {
"_all": {
"enabled": false
},
"properties": {
"aId": {
"type": "keyword"
},
"cId": {
"type": "keyword"
}
}
}
}
}
插入:按照如上单独aId和cId存储为一个doc
查询:每次传入一个aId和1000个cId的列表,返回es中匹配的aId+cId的列表。
使用如下filter+terms查询:
GET demo/_search?routing=11147489
{
"size":1000,
"query": {
"bool": {
"filter": {
"term": {
"aId": "11147489"
}
},
"must": [
{
"terms": {
"cId": [
"11147494",
"11147498",
....(1000个)
]
}
}
]
}
}
}
对于es中aId下cId数量小于100的情况性能比较理想大概在7ms左右,
但是对于aId下cId数量几千几万的情况下,响应时间达到40ms以上,但如果size设置为100,则有时候能降到10多ms。
以上插入和查询的时候使用了路由,返回结果_source也置为过false,使用过ids查询,用should里面套用1000个term替换terms,但效果都不理想。
请问下论坛里面的大神:
1. 为什么size=100和size=1000响应时间差距这么大,理论上查询条件带有aId和路由相同,只在一个分片上查询,协调节点只需要从一个分片上直接获取数据并返回即可,并没有分片之间结果合并,是因为fetch的过程比较耗时吗?我用profile去查看的时候几个耗时都不超过1ms。
2. 有没有其他方法优化aId下cId较大的情况,上述查询的响应时间。
谢谢。
{
"mappings": {
"demo": {
"_all": {
"enabled": false
},
"properties": {
"aId": {
"type": "keyword"
},
"cId": {
"type": "keyword"
}
}
}
}
}
插入:按照如上单独aId和cId存储为一个doc
查询:每次传入一个aId和1000个cId的列表,返回es中匹配的aId+cId的列表。
使用如下filter+terms查询:
GET demo/_search?routing=11147489
{
"size":1000,
"query": {
"bool": {
"filter": {
"term": {
"aId": "11147489"
}
},
"must": [
{
"terms": {
"cId": [
"11147494",
"11147498",
....(1000个)
]
}
}
]
}
}
}
对于es中aId下cId数量小于100的情况性能比较理想大概在7ms左右,
但是对于aId下cId数量几千几万的情况下,响应时间达到40ms以上,但如果size设置为100,则有时候能降到10多ms。
以上插入和查询的时候使用了路由,返回结果_source也置为过false,使用过ids查询,用should里面套用1000个term替换terms,但效果都不理想。
请问下论坛里面的大神:
1. 为什么size=100和size=1000响应时间差距这么大,理论上查询条件带有aId和路由相同,只在一个分片上查询,协调节点只需要从一个分片上直接获取数据并返回即可,并没有分片之间结果合并,是因为fetch的过程比较耗时吗?我用profile去查看的时候几个耗时都不超过1ms。
2. 有没有其他方法优化aId下cId较大的情况,上述查询的响应时间。
谢谢。
3 个回复
rochy - rochy_he
赞同来自:
2. 如果 ID 是确定的,可以使用 multiGet 直接获取结果即可;
3. mapping 设置 eager_global_ordinals: true
the_best
赞同来自:
laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net
赞同来自: