社区日报 第736期 (2019-09-22)
1.在ElasticSearch使用Machine Learning。
http://tinyurl.com/y5rtu9ej
2.(自备梯子)使用Elasticsearch和Kibana分析Ethereum。
http://tinyurl.com/y6fapn4z
3.(自备梯子)你的隐私值多少钱?
http://tinyurl.com/y5lk24vz
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://tinyurl.com/y5rtu9ej
2.(自备梯子)使用Elasticsearch和Kibana分析Ethereum。
http://tinyurl.com/y6fapn4z
3.(自备梯子)你的隐私值多少钱?
http://tinyurl.com/y5lk24vz
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1.在ElasticSearch使用Machine Learning。
http://tinyurl.com/y5rtu9ej
2.(自备梯子)使用Elasticsearch和Kibana分析Ethereum。
http://tinyurl.com/y6fapn4z
3.(自备梯子)你的隐私值多少钱?
http://tinyurl.com/y5lk24vz
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://tinyurl.com/y5rtu9ej
2.(自备梯子)使用Elasticsearch和Kibana分析Ethereum。
http://tinyurl.com/y6fapn4z
3.(自备梯子)你的隐私值多少钱?
http://tinyurl.com/y5lk24vz
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
Lucene doc_value的理解复盘
之前看过很多doc_Value相关的文章,也看过elasticsearch官方的描述,但是总是感觉对doc_value如何提升聚合排序性能这块说的很简单(也许是我个人理解力的问题),总是不能深刻理解没有doc_Value的话会牺牲多大性能,再加上每次研究一半就搁置了,所以一直没能很好理解这块知识点,今天来重点复盘下。 本文不是科普文,不一定是完全正确的,大家可以讨论。
首先从elasticsearch入手,我们建立一个索引结构如下:
假设我们的需求是查询time=10的各个age包含的info有多少。这是一个搜索兼聚合的需求,首先要搜出来time:[1 , 10]的结果,然后在这些doc结果里统计,他们的age各自分别占了多少个doc。语句如下:
假设我们的数据是这样的:
docId time age
1 10 20
2 8 21
3 9 24
4 2 23
5 10 22
6 10 22
结果也很明显了,返回doc为1,5,6的内容,聚合结果, age=20的doc_count=1, age=22的doc_coutn=2。
demo介绍完了,说下假设没有doc_value,只有倒排索引我们要怎么实现这个效果。
首先搜索不用说了,走time字段的倒排索引,下表:
2:4
8:2
9:3
10:1,5,6
一目了然,一下就能把post_list结果拿到。
那么聚合是在1,5,6这个结果之上做的,因为聚合字段和排序字段不一样,time倒排索引中不包含age的信息,所以要想对age做聚合,就需要做类似回表的操作想办法取回每个doc对应的age值,然后在内存中遍历下算出来每个age对应的doc有几个(当然这个例子最多只有3个doc_count, 返回值只有3个doc)。
取回的方式,可以走age的倒排索引,遍历age索引的term_dictionary(不了解的同学可以理解为这就是一个排序的term列表),遍历要做的事情是什么呢:取出每个term后面的postling_list,看下list中有没有对应我搜索结果的doc_id,有的话记录下有几个,给这个term做下标记记录term的doc_count。 这个过程就比较狗了,假设term非常多,遍历一次的代价就非常高,所以在没有doc_value的情况下,遍历倒排索引就显得很差劲,倒排索引的价值本来就是避免数据遍历提升搜索性能,到了这种聚合需求上反而要用我做这么高代价的事儿,所以才需要一个出路避免这个问题。
这时候有人会说了,一个info对应一个age,那么当我遍历的时候,记录下这个doc有没有遍历过,当所有doc_id都遍历过一遍后就不遍历了,能提升一些性能吧。 首先如果运气不好,碰上你的doc要聚合的term出现在term_dictionary最后一个的时候,时间开销还是最坏情况的,其次,我这里用的是单个数值,如果一个field是多值的呢,换句话说,如果是分词的字符串呢,多值和分词其实一样,这种情况下当你遍历到一个term包含结果的某个doc_id时你不能说这个doc不会再后续的其他term中出现了,你还是要继续遍历完,所以为了满足这个需求,遍历全部term_dictionary是没跑的。
排序其实也差不多的,如果你要根据非搜索结果进行排序,一样要取出结果doc,对应排序字段的值,然后内存排序,所以内存排序聚合我觉得不是开销大的点,开销大的地方在于遍历倒排索引。
其实讲到这里我的疑惑基本就解决了。接下来再说下doc_value
doc_value通俗的讲就是正排索引(这个词儿基本上所有文章都会这么说,说的也对,就是看多了有点想吐。。),其实正排索引就是我上面列举出来的那个值列表,只不过是一个字段一个doc_value,跟倒排索引一样,不是放在一起的(这点区别mysql聚集索引的叶子节点,聚集索引叶子节点是保存了全部的值,用主键绑定的,这里也说明了Lucene是索引和数据分离的,而MySQL是索引即数据,我是这么理解)。
time的doc_value
docId time
1 10
2 8
3 9
4 2
5 10
6 10
age的doc_value
docId age
1 20
2 21
3 24
4 23
5 22
6 22
现在我们有了这样的一个结构可就厉害了,回到刚才的场景,搜索完结果是1,5,6,如果想按age进行聚合或者排序,那么只需要我们来到doc_value中,根据我们的id列表和doc_value的列表做交集拿出来结果对应的age就可以了,然后内存排序一下,实际上doc_value完全可以按照value先排好序,然后我们交集的结果就是排序结果了,都不用内存再排一次(暂时还不知道doc_value是不是根据value排过序)。
最后再说下我觉得其实可以优化的地方,之前我在问答也提问过,就是当搜索和排序/聚合使用相同字段的时候,还要不要走doc_value的问题。
因为如果是同一个字段那么完全没必要回表了,倒排索引本来就是field有序的所以排序问题解决。
其次聚合,刚才的例子中是单值的,如果是多值的话也不要紧,因为我们都知道查询条件的值了,单值的话 doc_count就等于total,多值的话 doc_count就等于其posting_list的length,多简单,省的走一次doc_value的操作。
不过那个问答回答的人太少,回答我的人的答复也蛮精彩的但是我仍然觉得这个操作是可以分开的。
求各路大神们对本文的观点做出指点和评论,或者我理解不对的地方提出指正。 对于想了解doc_value的同学希望这篇文章能解决你们的疑惑。
继续阅读 »
首先从elasticsearch入手,我们建立一个索引结构如下:
{
"info": {
"mappings": {
"info": {
"_all": {
"enabled": false
},
"properties": {
"age": {
"type": "int"
},
"time": {
"type": "long"
}
}
}
}
}
}
我这里特地拿非字符串类型的值做举例,大家在用MySQL的时候大多是用值精准匹配等条件,没有涉及到分词和多值,所以一开始很多用分词举例的时候我就糊涂了,这里我用数字举例说明下。假设我们的需求是查询time=10的各个age包含的info有多少。这是一个搜索兼聚合的需求,首先要搜出来time:[1 , 10]的结果,然后在这些doc结果里统计,他们的age各自分别占了多少个doc。语句如下:
{
"query": {
"term": {
"time": 10
}
},
"aggs": {
"age_terms": {
"terms": {
"field": "age"
}
}
}
}
假设我们的数据是这样的:
docId time age
1 10 20
2 8 21
3 9 24
4 2 23
5 10 22
6 10 22
结果也很明显了,返回doc为1,5,6的内容,聚合结果, age=20的doc_count=1, age=22的doc_coutn=2。
demo介绍完了,说下假设没有doc_value,只有倒排索引我们要怎么实现这个效果。
首先搜索不用说了,走time字段的倒排索引,下表:
2:4
8:2
9:3
10:1,5,6
一目了然,一下就能把post_list结果拿到。
那么聚合是在1,5,6这个结果之上做的,因为聚合字段和排序字段不一样,time倒排索引中不包含age的信息,所以要想对age做聚合,就需要做类似回表的操作想办法取回每个doc对应的age值,然后在内存中遍历下算出来每个age对应的doc有几个(当然这个例子最多只有3个doc_count, 返回值只有3个doc)。
取回的方式,可以走age的倒排索引,遍历age索引的term_dictionary(不了解的同学可以理解为这就是一个排序的term列表),遍历要做的事情是什么呢:取出每个term后面的postling_list,看下list中有没有对应我搜索结果的doc_id,有的话记录下有几个,给这个term做下标记记录term的doc_count。 这个过程就比较狗了,假设term非常多,遍历一次的代价就非常高,所以在没有doc_value的情况下,遍历倒排索引就显得很差劲,倒排索引的价值本来就是避免数据遍历提升搜索性能,到了这种聚合需求上反而要用我做这么高代价的事儿,所以才需要一个出路避免这个问题。
这时候有人会说了,一个info对应一个age,那么当我遍历的时候,记录下这个doc有没有遍历过,当所有doc_id都遍历过一遍后就不遍历了,能提升一些性能吧。 首先如果运气不好,碰上你的doc要聚合的term出现在term_dictionary最后一个的时候,时间开销还是最坏情况的,其次,我这里用的是单个数值,如果一个field是多值的呢,换句话说,如果是分词的字符串呢,多值和分词其实一样,这种情况下当你遍历到一个term包含结果的某个doc_id时你不能说这个doc不会再后续的其他term中出现了,你还是要继续遍历完,所以为了满足这个需求,遍历全部term_dictionary是没跑的。
排序其实也差不多的,如果你要根据非搜索结果进行排序,一样要取出结果doc,对应排序字段的值,然后内存排序,所以内存排序聚合我觉得不是开销大的点,开销大的地方在于遍历倒排索引。
其实讲到这里我的疑惑基本就解决了。接下来再说下doc_value
doc_value通俗的讲就是正排索引(这个词儿基本上所有文章都会这么说,说的也对,就是看多了有点想吐。。),其实正排索引就是我上面列举出来的那个值列表,只不过是一个字段一个doc_value,跟倒排索引一样,不是放在一起的(这点区别mysql聚集索引的叶子节点,聚集索引叶子节点是保存了全部的值,用主键绑定的,这里也说明了Lucene是索引和数据分离的,而MySQL是索引即数据,我是这么理解)。
time的doc_value
docId time
1 10
2 8
3 9
4 2
5 10
6 10
age的doc_value
docId age
1 20
2 21
3 24
4 23
5 22
6 22
现在我们有了这样的一个结构可就厉害了,回到刚才的场景,搜索完结果是1,5,6,如果想按age进行聚合或者排序,那么只需要我们来到doc_value中,根据我们的id列表和doc_value的列表做交集拿出来结果对应的age就可以了,然后内存排序一下,实际上doc_value完全可以按照value先排好序,然后我们交集的结果就是排序结果了,都不用内存再排一次(暂时还不知道doc_value是不是根据value排过序)。
最后再说下我觉得其实可以优化的地方,之前我在问答也提问过,就是当搜索和排序/聚合使用相同字段的时候,还要不要走doc_value的问题。
因为如果是同一个字段那么完全没必要回表了,倒排索引本来就是field有序的所以排序问题解决。
其次聚合,刚才的例子中是单值的,如果是多值的话也不要紧,因为我们都知道查询条件的值了,单值的话 doc_count就等于total,多值的话 doc_count就等于其posting_list的length,多简单,省的走一次doc_value的操作。
不过那个问答回答的人太少,回答我的人的答复也蛮精彩的但是我仍然觉得这个操作是可以分开的。
求各路大神们对本文的观点做出指点和评论,或者我理解不对的地方提出指正。 对于想了解doc_value的同学希望这篇文章能解决你们的疑惑。
之前看过很多doc_Value相关的文章,也看过elasticsearch官方的描述,但是总是感觉对doc_value如何提升聚合排序性能这块说的很简单(也许是我个人理解力的问题),总是不能深刻理解没有doc_Value的话会牺牲多大性能,再加上每次研究一半就搁置了,所以一直没能很好理解这块知识点,今天来重点复盘下。 本文不是科普文,不一定是完全正确的,大家可以讨论。
首先从elasticsearch入手,我们建立一个索引结构如下:
假设我们的需求是查询time=10的各个age包含的info有多少。这是一个搜索兼聚合的需求,首先要搜出来time:[1 , 10]的结果,然后在这些doc结果里统计,他们的age各自分别占了多少个doc。语句如下:
假设我们的数据是这样的:
docId time age
1 10 20
2 8 21
3 9 24
4 2 23
5 10 22
6 10 22
结果也很明显了,返回doc为1,5,6的内容,聚合结果, age=20的doc_count=1, age=22的doc_coutn=2。
demo介绍完了,说下假设没有doc_value,只有倒排索引我们要怎么实现这个效果。
首先搜索不用说了,走time字段的倒排索引,下表:
2:4
8:2
9:3
10:1,5,6
一目了然,一下就能把post_list结果拿到。
那么聚合是在1,5,6这个结果之上做的,因为聚合字段和排序字段不一样,time倒排索引中不包含age的信息,所以要想对age做聚合,就需要做类似回表的操作想办法取回每个doc对应的age值,然后在内存中遍历下算出来每个age对应的doc有几个(当然这个例子最多只有3个doc_count, 返回值只有3个doc)。
取回的方式,可以走age的倒排索引,遍历age索引的term_dictionary(不了解的同学可以理解为这就是一个排序的term列表),遍历要做的事情是什么呢:取出每个term后面的postling_list,看下list中有没有对应我搜索结果的doc_id,有的话记录下有几个,给这个term做下标记记录term的doc_count。 这个过程就比较狗了,假设term非常多,遍历一次的代价就非常高,所以在没有doc_value的情况下,遍历倒排索引就显得很差劲,倒排索引的价值本来就是避免数据遍历提升搜索性能,到了这种聚合需求上反而要用我做这么高代价的事儿,所以才需要一个出路避免这个问题。
这时候有人会说了,一个info对应一个age,那么当我遍历的时候,记录下这个doc有没有遍历过,当所有doc_id都遍历过一遍后就不遍历了,能提升一些性能吧。 首先如果运气不好,碰上你的doc要聚合的term出现在term_dictionary最后一个的时候,时间开销还是最坏情况的,其次,我这里用的是单个数值,如果一个field是多值的呢,换句话说,如果是分词的字符串呢,多值和分词其实一样,这种情况下当你遍历到一个term包含结果的某个doc_id时你不能说这个doc不会再后续的其他term中出现了,你还是要继续遍历完,所以为了满足这个需求,遍历全部term_dictionary是没跑的。
排序其实也差不多的,如果你要根据非搜索结果进行排序,一样要取出结果doc,对应排序字段的值,然后内存排序,所以内存排序聚合我觉得不是开销大的点,开销大的地方在于遍历倒排索引。
其实讲到这里我的疑惑基本就解决了。接下来再说下doc_value
doc_value通俗的讲就是正排索引(这个词儿基本上所有文章都会这么说,说的也对,就是看多了有点想吐。。),其实正排索引就是我上面列举出来的那个值列表,只不过是一个字段一个doc_value,跟倒排索引一样,不是放在一起的(这点区别mysql聚集索引的叶子节点,聚集索引叶子节点是保存了全部的值,用主键绑定的,这里也说明了Lucene是索引和数据分离的,而MySQL是索引即数据,我是这么理解)。
time的doc_value
docId time
1 10
2 8
3 9
4 2
5 10
6 10
age的doc_value
docId age
1 20
2 21
3 24
4 23
5 22
6 22
现在我们有了这样的一个结构可就厉害了,回到刚才的场景,搜索完结果是1,5,6,如果想按age进行聚合或者排序,那么只需要我们来到doc_value中,根据我们的id列表和doc_value的列表做交集拿出来结果对应的age就可以了,然后内存排序一下,实际上doc_value完全可以按照value先排好序,然后我们交集的结果就是排序结果了,都不用内存再排一次(暂时还不知道doc_value是不是根据value排过序)。
最后再说下我觉得其实可以优化的地方,之前我在问答也提问过,就是当搜索和排序/聚合使用相同字段的时候,还要不要走doc_value的问题。
因为如果是同一个字段那么完全没必要回表了,倒排索引本来就是field有序的所以排序问题解决。
其次聚合,刚才的例子中是单值的,如果是多值的话也不要紧,因为我们都知道查询条件的值了,单值的话 doc_count就等于total,多值的话 doc_count就等于其posting_list的length,多简单,省的走一次doc_value的操作。
不过那个问答回答的人太少,回答我的人的答复也蛮精彩的但是我仍然觉得这个操作是可以分开的。
求各路大神们对本文的观点做出指点和评论,或者我理解不对的地方提出指正。 对于想了解doc_value的同学希望这篇文章能解决你们的疑惑。
收起阅读 »
首先从elasticsearch入手,我们建立一个索引结构如下:
{
"info": {
"mappings": {
"info": {
"_all": {
"enabled": false
},
"properties": {
"age": {
"type": "int"
},
"time": {
"type": "long"
}
}
}
}
}
}
我这里特地拿非字符串类型的值做举例,大家在用MySQL的时候大多是用值精准匹配等条件,没有涉及到分词和多值,所以一开始很多用分词举例的时候我就糊涂了,这里我用数字举例说明下。假设我们的需求是查询time=10的各个age包含的info有多少。这是一个搜索兼聚合的需求,首先要搜出来time:[1 , 10]的结果,然后在这些doc结果里统计,他们的age各自分别占了多少个doc。语句如下:
{
"query": {
"term": {
"time": 10
}
},
"aggs": {
"age_terms": {
"terms": {
"field": "age"
}
}
}
}
假设我们的数据是这样的:
docId time age
1 10 20
2 8 21
3 9 24
4 2 23
5 10 22
6 10 22
结果也很明显了,返回doc为1,5,6的内容,聚合结果, age=20的doc_count=1, age=22的doc_coutn=2。
demo介绍完了,说下假设没有doc_value,只有倒排索引我们要怎么实现这个效果。
首先搜索不用说了,走time字段的倒排索引,下表:
2:4
8:2
9:3
10:1,5,6
一目了然,一下就能把post_list结果拿到。
那么聚合是在1,5,6这个结果之上做的,因为聚合字段和排序字段不一样,time倒排索引中不包含age的信息,所以要想对age做聚合,就需要做类似回表的操作想办法取回每个doc对应的age值,然后在内存中遍历下算出来每个age对应的doc有几个(当然这个例子最多只有3个doc_count, 返回值只有3个doc)。
取回的方式,可以走age的倒排索引,遍历age索引的term_dictionary(不了解的同学可以理解为这就是一个排序的term列表),遍历要做的事情是什么呢:取出每个term后面的postling_list,看下list中有没有对应我搜索结果的doc_id,有的话记录下有几个,给这个term做下标记记录term的doc_count。 这个过程就比较狗了,假设term非常多,遍历一次的代价就非常高,所以在没有doc_value的情况下,遍历倒排索引就显得很差劲,倒排索引的价值本来就是避免数据遍历提升搜索性能,到了这种聚合需求上反而要用我做这么高代价的事儿,所以才需要一个出路避免这个问题。
这时候有人会说了,一个info对应一个age,那么当我遍历的时候,记录下这个doc有没有遍历过,当所有doc_id都遍历过一遍后就不遍历了,能提升一些性能吧。 首先如果运气不好,碰上你的doc要聚合的term出现在term_dictionary最后一个的时候,时间开销还是最坏情况的,其次,我这里用的是单个数值,如果一个field是多值的呢,换句话说,如果是分词的字符串呢,多值和分词其实一样,这种情况下当你遍历到一个term包含结果的某个doc_id时你不能说这个doc不会再后续的其他term中出现了,你还是要继续遍历完,所以为了满足这个需求,遍历全部term_dictionary是没跑的。
排序其实也差不多的,如果你要根据非搜索结果进行排序,一样要取出结果doc,对应排序字段的值,然后内存排序,所以内存排序聚合我觉得不是开销大的点,开销大的地方在于遍历倒排索引。
其实讲到这里我的疑惑基本就解决了。接下来再说下doc_value
doc_value通俗的讲就是正排索引(这个词儿基本上所有文章都会这么说,说的也对,就是看多了有点想吐。。),其实正排索引就是我上面列举出来的那个值列表,只不过是一个字段一个doc_value,跟倒排索引一样,不是放在一起的(这点区别mysql聚集索引的叶子节点,聚集索引叶子节点是保存了全部的值,用主键绑定的,这里也说明了Lucene是索引和数据分离的,而MySQL是索引即数据,我是这么理解)。
time的doc_value
docId time
1 10
2 8
3 9
4 2
5 10
6 10
age的doc_value
docId age
1 20
2 21
3 24
4 23
5 22
6 22
现在我们有了这样的一个结构可就厉害了,回到刚才的场景,搜索完结果是1,5,6,如果想按age进行聚合或者排序,那么只需要我们来到doc_value中,根据我们的id列表和doc_value的列表做交集拿出来结果对应的age就可以了,然后内存排序一下,实际上doc_value完全可以按照value先排好序,然后我们交集的结果就是排序结果了,都不用内存再排一次(暂时还不知道doc_value是不是根据value排过序)。
最后再说下我觉得其实可以优化的地方,之前我在问答也提问过,就是当搜索和排序/聚合使用相同字段的时候,还要不要走doc_value的问题。
因为如果是同一个字段那么完全没必要回表了,倒排索引本来就是field有序的所以排序问题解决。
其次聚合,刚才的例子中是单值的,如果是多值的话也不要紧,因为我们都知道查询条件的值了,单值的话 doc_count就等于total,多值的话 doc_count就等于其posting_list的length,多简单,省的走一次doc_value的操作。
不过那个问答回答的人太少,回答我的人的答复也蛮精彩的但是我仍然觉得这个操作是可以分开的。
求各路大神们对本文的观点做出指点和评论,或者我理解不对的地方提出指正。 对于想了解doc_value的同学希望这篇文章能解决你们的疑惑。
收起阅读 »
Elastic日报 第735期 (2019-09-21)
社区日报 第734期 (2019-09-20)
1、开源:基于React的Elasticsearch UI组件库
https://tinyurl.com/y4js6mf7
2、如何将edis缓存层添加到Elasticsearch查询?(梯子)
https://tinyurl.com/yyg5wue3
3、基于vector字段的文本相似度搜索
https://tinyurl.com/y3k2kfsd
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
https://tinyurl.com/y4js6mf7
2、如何将edis缓存层添加到Elasticsearch查询?(梯子)
https://tinyurl.com/yyg5wue3
3、基于vector字段的文本相似度搜索
https://tinyurl.com/y3k2kfsd
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、开源:基于React的Elasticsearch UI组件库
https://tinyurl.com/y4js6mf7
2、如何将edis缓存层添加到Elasticsearch查询?(梯子)
https://tinyurl.com/yyg5wue3
3、基于vector字段的文本相似度搜索
https://tinyurl.com/y3k2kfsd
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
https://tinyurl.com/y4js6mf7
2、如何将edis缓存层添加到Elasticsearch查询?(梯子)
https://tinyurl.com/yyg5wue3
3、基于vector字段的文本相似度搜索
https://tinyurl.com/y3k2kfsd
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第733期 (2019-09-19)
1、ES时间序列的聚合与查询
http://tinyurl.com/yxvtl866
2、k8s日志收集指南
http://tinyurl.com/yyv373ss
3、elastic stack的告警
http://tinyurl.com/y4cnmdo3
编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://tinyurl.com/yxvtl866
2、k8s日志收集指南
http://tinyurl.com/yyv373ss
3、elastic stack的告警
http://tinyurl.com/y4cnmdo3
编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、ES时间序列的聚合与查询
http://tinyurl.com/yxvtl866
2、k8s日志收集指南
http://tinyurl.com/yyv373ss
3、elastic stack的告警
http://tinyurl.com/y4cnmdo3
编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://tinyurl.com/yxvtl866
2、k8s日志收集指南
http://tinyurl.com/yyv373ss
3、elastic stack的告警
http://tinyurl.com/y4cnmdo3
编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
关于sum bucket 与Filter Aggregation 结合的写法分享
我们可以用ES的桶来实现这样的需求,找出汽车厂商每个颜色的车辆数量
当如果需求是,找出汽车厂商里的车一共有多少种颜色呢?
我们可以使用sum bucket ,默认情况下,可以参考官方文档
https://www.elastic.co/guide/e ... ml%23
但如果我们想找到售价大于100W的车,有多少种颜色呢?
这就需要Filter Aggregation 和 上文的sum bucket结合
这里有个需要注意的地方,sum_bucket的位置不要跟 Filter Aggregation 同级,而是应该在其下一级:
如果将member_count 与valid_sales_people放到同一级,会报一个错:sum_bucket的第一个聚合必须是多桶聚合。究其原因,应该是加上filter aggregation后,valid_sales_people已不具有多桶聚合属性(因为附带了filter过滤条件),而其下的render_people则具有了多桶聚合属性。所以member_count应该与render_people放在同级,对应的buckets_path也自然改为render_people>unique_people
继续阅读 »
当如果需求是,找出汽车厂商里的车一共有多少种颜色呢?
我们可以使用sum bucket ,默认情况下,可以参考官方文档
https://www.elastic.co/guide/e ... ml%23
但如果我们想找到售价大于100W的车,有多少种颜色呢?
这就需要Filter Aggregation 和 上文的sum bucket结合
这里有个需要注意的地方,sum_bucket的位置不要跟 Filter Aggregation 同级,而是应该在其下一级:
"query": {
"query": {
"bool": {
"filter": {
"bool": {
"must": [
{
"term": {
"delflag": 0
}
},
{
"term": {
"is_child": 1
}
}
],
"must_not":
}
}
}
},
"aggs": {
"valid_sales_people": {
"filter": {
"bool": {
"must_not": {
"terms": {
"status": [
0,
1,
7
]
}
}
}
},
"aggs": {
"render_people": {
"terms": {
"field": "uid",
"size": 2147483647
},
"aggs": {
"unique_people": {
"cardinality": {
"field": "uid"
}
}
}
},
"member_count": {
"sum_bucket": {
"buckets_path": "render_people>unique_people"
}
}
}
}
}
},
如代码所示,我希望对status not in (0,1,7)的uid(用户)进行聚合,并想得到uid桶种类的求和,那么member_count就应该与render_people同级,而不是把member_count放到和与valid_sales_people同一级。如果将member_count 与valid_sales_people放到同一级,会报一个错:sum_bucket的第一个聚合必须是多桶聚合。究其原因,应该是加上filter aggregation后,valid_sales_people已不具有多桶聚合属性(因为附带了filter过滤条件),而其下的render_people则具有了多桶聚合属性。所以member_count应该与render_people放在同级,对应的buckets_path也自然改为render_people>unique_people
我们可以用ES的桶来实现这样的需求,找出汽车厂商每个颜色的车辆数量
当如果需求是,找出汽车厂商里的车一共有多少种颜色呢?
我们可以使用sum bucket ,默认情况下,可以参考官方文档
https://www.elastic.co/guide/e ... ml%23
但如果我们想找到售价大于100W的车,有多少种颜色呢?
这就需要Filter Aggregation 和 上文的sum bucket结合
这里有个需要注意的地方,sum_bucket的位置不要跟 Filter Aggregation 同级,而是应该在其下一级:
如果将member_count 与valid_sales_people放到同一级,会报一个错:sum_bucket的第一个聚合必须是多桶聚合。究其原因,应该是加上filter aggregation后,valid_sales_people已不具有多桶聚合属性(因为附带了filter过滤条件),而其下的render_people则具有了多桶聚合属性。所以member_count应该与render_people放在同级,对应的buckets_path也自然改为render_people>unique_people
收起阅读 »
当如果需求是,找出汽车厂商里的车一共有多少种颜色呢?
我们可以使用sum bucket ,默认情况下,可以参考官方文档
https://www.elastic.co/guide/e ... ml%23
但如果我们想找到售价大于100W的车,有多少种颜色呢?
这就需要Filter Aggregation 和 上文的sum bucket结合
这里有个需要注意的地方,sum_bucket的位置不要跟 Filter Aggregation 同级,而是应该在其下一级:
"query": {
"query": {
"bool": {
"filter": {
"bool": {
"must": [
{
"term": {
"delflag": 0
}
},
{
"term": {
"is_child": 1
}
}
],
"must_not":
}
}
}
},
"aggs": {
"valid_sales_people": {
"filter": {
"bool": {
"must_not": {
"terms": {
"status": [
0,
1,
7
]
}
}
}
},
"aggs": {
"render_people": {
"terms": {
"field": "uid",
"size": 2147483647
},
"aggs": {
"unique_people": {
"cardinality": {
"field": "uid"
}
}
}
},
"member_count": {
"sum_bucket": {
"buckets_path": "render_people>unique_people"
}
}
}
}
}
},
如代码所示,我希望对status not in (0,1,7)的uid(用户)进行聚合,并想得到uid桶种类的求和,那么member_count就应该与render_people同级,而不是把member_count放到和与valid_sales_people同一级。如果将member_count 与valid_sales_people放到同一级,会报一个错:sum_bucket的第一个聚合必须是多桶聚合。究其原因,应该是加上filter aggregation后,valid_sales_people已不具有多桶聚合属性(因为附带了filter过滤条件),而其下的render_people则具有了多桶聚合属性。所以member_count应该与render_people放在同级,对应的buckets_path也自然改为render_people>unique_people
收起阅读 »
cq1988114 发表于 : 2019-09-19 00:14
评论 (0)
社区日报 第732期 (2019-09-18)
1、开源日志系统比较 scribe、chukwa、kafka、flume
http://1t.click/aqcR
2、集中式日志分析平台
http://1t.click/aqcW
3、Airbnb 的核心日志系统
http://1t.click/aqda
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://1t.click/aqcR
2、集中式日志分析平台
http://1t.click/aqcW
3、Airbnb 的核心日志系统
http://1t.click/aqda
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、开源日志系统比较 scribe、chukwa、kafka、flume
http://1t.click/aqcR
2、集中式日志分析平台
http://1t.click/aqcW
3、Airbnb 的核心日志系统
http://1t.click/aqda
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://1t.click/aqcR
2、集中式日志分析平台
http://1t.click/aqcW
3、Airbnb 的核心日志系统
http://1t.click/aqda
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第731期 (2019-09-17)
1、管理分片索引的最佳实践。
http://tinyurl.com/y3tx7eoo
2、在docker上使用nodejs和Elasticsearch进行全文搜索。
http://tinyurl.com/y32jdpbs
3、构建一个档案搜索索引。
http://tinyurl.com/yxnpobms
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://tinyurl.com/y3tx7eoo
2、在docker上使用nodejs和Elasticsearch进行全文搜索。
http://tinyurl.com/y32jdpbs
3、构建一个档案搜索索引。
http://tinyurl.com/yxnpobms
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、管理分片索引的最佳实践。
http://tinyurl.com/y3tx7eoo
2、在docker上使用nodejs和Elasticsearch进行全文搜索。
http://tinyurl.com/y32jdpbs
3、构建一个档案搜索索引。
http://tinyurl.com/yxnpobms
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://tinyurl.com/y3tx7eoo
2、在docker上使用nodejs和Elasticsearch进行全文搜索。
http://tinyurl.com/y32jdpbs
3、构建一个档案搜索索引。
http://tinyurl.com/yxnpobms
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第730期 (2019-09-16)
1、如何提升ElasticSearch 写入性能(自备梯子)
http://t.cn/AiE82VO8
2、解决ElasticSearch重启之后shard未分配问题
http://t.cn/AiE82usZ
3、如何打造完美的elasticSearch集群
http://t.cn/AiE8LxvV
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://t.cn/AiE82VO8
2、解决ElasticSearch重启之后shard未分配问题
http://t.cn/AiE82usZ
3、如何打造完美的elasticSearch集群
http://t.cn/AiE8LxvV
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、如何提升ElasticSearch 写入性能(自备梯子)
http://t.cn/AiE82VO8
2、解决ElasticSearch重启之后shard未分配问题
http://t.cn/AiE82usZ
3、如何打造完美的elasticSearch集群
http://t.cn/AiE8LxvV
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
收起阅读 »
http://t.cn/AiE82VO8
2、解决ElasticSearch重启之后shard未分配问题
http://t.cn/AiE82usZ
3、如何打造完美的elasticSearch集群
http://t.cn/AiE8LxvV
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
收起阅读 »
社区日报 第729期 (2019-09-12)
1.如何提取数据到ES
http://dwz1.cc/AdW7rFD5
2.Elasticsearch 数据建模的一些建议
http://dwz1.cc/vZux5ZCS
3.ElasticSearch跨集群搜索
http://dwz1.cc/6vsGpxm5
编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://dwz1.cc/AdW7rFD5
2.Elasticsearch 数据建模的一些建议
http://dwz1.cc/vZux5ZCS
3.ElasticSearch跨集群搜索
http://dwz1.cc/6vsGpxm5
编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1.如何提取数据到ES
http://dwz1.cc/AdW7rFD5
2.Elasticsearch 数据建模的一些建议
http://dwz1.cc/vZux5ZCS
3.ElasticSearch跨集群搜索
http://dwz1.cc/6vsGpxm5
编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://dwz1.cc/AdW7rFD5
2.Elasticsearch 数据建模的一些建议
http://dwz1.cc/vZux5ZCS
3.ElasticSearch跨集群搜索
http://dwz1.cc/6vsGpxm5
编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第728期 (2019-09-11)
1、全文搜索引擎 Elasticsearch 这篇文章给讲透了
http://1t.click/ahQF
2、容器日志采集利器 Filebeat 深度剖析与实践
http://1t.click/ahQK
3、倒排索引的精致结构
http://1t.click/ahQP
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://1t.click/ahQF
2、容器日志采集利器 Filebeat 深度剖析与实践
http://1t.click/ahQK
3、倒排索引的精致结构
http://1t.click/ahQP
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、全文搜索引擎 Elasticsearch 这篇文章给讲透了
http://1t.click/ahQF
2、容器日志采集利器 Filebeat 深度剖析与实践
http://1t.click/ahQK
3、倒排索引的精致结构
http://1t.click/ahQP
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://1t.click/ahQF
2、容器日志采集利器 Filebeat 深度剖析与实践
http://1t.click/ahQK
3、倒排索引的精致结构
http://1t.click/ahQP
编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第727期 (2019-09-10)
1、ElasticSearch使用优化之拙见。
http://tinyurl.com/y39o7fml
2、写速度提升20%,Elasticsearch 创始人给腾讯云发感谢信。
http://tinyurl.com/yyknwmle
3、WebCenter之Elasticsearch使用指南。
http://tinyurl.com/y3lnf3u6
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://tinyurl.com/y39o7fml
2、写速度提升20%,Elasticsearch 创始人给腾讯云发感谢信。
http://tinyurl.com/yyknwmle
3、WebCenter之Elasticsearch使用指南。
http://tinyurl.com/y3lnf3u6
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、ElasticSearch使用优化之拙见。
http://tinyurl.com/y39o7fml
2、写速度提升20%,Elasticsearch 创始人给腾讯云发感谢信。
http://tinyurl.com/yyknwmle
3、WebCenter之Elasticsearch使用指南。
http://tinyurl.com/y3lnf3u6
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://tinyurl.com/y39o7fml
2、写速度提升20%,Elasticsearch 创始人给腾讯云发感谢信。
http://tinyurl.com/yyknwmle
3、WebCenter之Elasticsearch使用指南。
http://tinyurl.com/y3lnf3u6
编辑:叮咚光军
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第726期 (2019-09-09)
1、elasticsearch离线数据迁移
http://t.cn/RrqHZmb
2、使用Stoem Topology 构建实时数据分析平台
http://t.cn/AiEVlN5v
3、elasticsearch是如何选出master的
http://t.cn/AiEVj0Aa
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://t.cn/RrqHZmb
2、使用Stoem Topology 构建实时数据分析平台
http://t.cn/AiEVlN5v
3、elasticsearch是如何选出master的
http://t.cn/AiEVj0Aa
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、elasticsearch离线数据迁移
http://t.cn/RrqHZmb
2、使用Stoem Topology 构建实时数据分析平台
http://t.cn/AiEVlN5v
3、elasticsearch是如何选出master的
http://t.cn/AiEVj0Aa
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://t.cn/RrqHZmb
2、使用Stoem Topology 构建实时数据分析平台
http://t.cn/AiEVlN5v
3、elasticsearch是如何选出master的
http://t.cn/AiEVj0Aa
编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第725期 (2019-09-08)
1.学习如何使用Java的Elasticsearch客户端Jest。
http://t.cn/AiNVKp1J
2.将操作系统数据发送到ELK。
http://t.cn/AiE247LM
3.(自备梯子)你现在可以要求Facebook删除你的面部识别数据。
http://t.cn/AiE2IhBM
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://t.cn/AiNVKp1J
2.将操作系统数据发送到ELK。
http://t.cn/AiE247LM
3.(自备梯子)你现在可以要求Facebook删除你的面部识别数据。
http://t.cn/AiE2IhBM
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1.学习如何使用Java的Elasticsearch客户端Jest。
http://t.cn/AiNVKp1J
2.将操作系统数据发送到ELK。
http://t.cn/AiE247LM
3.(自备梯子)你现在可以要求Facebook删除你的面部识别数据。
http://t.cn/AiE2IhBM
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://t.cn/AiNVKp1J
2.将操作系统数据发送到ELK。
http://t.cn/AiE247LM
3.(自备梯子)你现在可以要求Facebook删除你的面部识别数据。
http://t.cn/AiE2IhBM
编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
社区日报 第724期 (2019-09-07)
1、MySQL数据以全量和增量方式,向ES搜索引擎同步流程
http://t.cn/AiEPNrfg
2、Graphene集成ES
http://t.cn/AiEPW0zs
3、一周热点:《罗小黑战记》接棒哪吒,今日上映
http://t.cn/AiEPjvNy
编辑: bsll
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
http://t.cn/AiEPNrfg
2、Graphene集成ES
http://t.cn/AiEPW0zs
3、一周热点:《罗小黑战记》接棒哪吒,今日上映
http://t.cn/AiEPjvNy
编辑: bsll
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
1、MySQL数据以全量和增量方式,向ES搜索引擎同步流程
http://t.cn/AiEPNrfg
2、Graphene集成ES
http://t.cn/AiEPW0zs
3、一周热点:《罗小黑战记》接棒哪吒,今日上映
http://t.cn/AiEPjvNy
编辑: bsll
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »
http://t.cn/AiEPNrfg
2、Graphene集成ES
http://t.cn/AiEPW0zs
3、一周热点:《罗小黑战记》接棒哪吒,今日上映
http://t.cn/AiEPjvNy
编辑: bsll
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »