2019. 9. 20. 12:00ㆍSearch-Engine/Elasticsearch&Solr
이번 포스팅은 엘라스틱서치 Aggregation(집계) API 두번째 글이다. 이번 글에서는 집계중 버킷집계(Bucket)에 대해 알아볼 것이다. 우선 버킷 집계는 메트릭 집계와는 다르게 메트릭을 계산하지 않고 버킷을 생성한다. 생성되는 버킷은 쿼리와 함께 수행되어 쿼리 결과에 따른 컨텍스트 내에서 집계가 이뤄진다. 이렇게 집계된 버킷은 또 다시 하위에서 집계를 한번 더 수행해서 집계된 결과에 대해 중첩된 집계 수행이 가능하다.
버킷이 생성되는 것은 집계 결과 집합을 메모리에 저장한다는 것이기 때문에 너무 많은 중첩 집계는 메모리 사용량을 점점 높히기에 성능에 악영향을 줄 수 있다. 이러한 문제때문에 엘라스틱서치는 설정으로 최대 버킷수를 조정할 수 있다.
> search.max_buckets
버킷의 크기를 -1 혹은 10000 이상의 값을 지정할 경우 엘라스틱서치에서 경고메시지를 보낸다. 이 말은 여러가지 이유로 안정적인 집계 분석을 위해 버킷의 크기, 집계의 중첩양 등을 충분히 고려한 후에 집계 수행을 해야한다.
-범위 집계(Range Aggregations)
범위 집계는 사용자가 지정한 범위 내에서 집계를 수행하는 다중 버킷 집계이다. 집계가 수행되면 쿼리의 결과가 범위에 해당하는 지 체크하고, 범위에 해당되는 문서들에 대해서만 집계를 수행한다. from과 to 속성을 지정하고, to에 지정한 값을 결과에서 제외된다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
{
"aggs":{
"bytes_range":{
"range":{
"field":"bytes",
"ranges":[{"from":1000,"to":2000}]
}
}
}
}
->result
{
"took": 51,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"bytes_range": {
"buckets": [
{
"key": "1000.0-2000.0",
"from": 1000.0,
"to": 2000.0,
"doc_count": 754
}
]
}
}
}
|
cs |
결과값에 대해 간단히 설명하면 "key"는 집계할 범위를 뜻하고, from은 시작,to는 끝,doc_count는 범위 내의 문서수를 의미한다. 또한 집계 쿼리에서 "ranges" 필드가 배열인 것으로 보아 여러개의 범위 지정이 가능한 것을 알 수 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
{
"aggs":{
"bytes_range":{
"range":{
"field":"bytes",
"ranges":[
{"from":1000,"to":2000},
{"from":2000,"to":4000}
]
}
}
}
}
->result
{
"took": 10,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"bytes_range": {
"buckets": [
{
"key": "1000.0-2000.0",
"from": 1000.0,
"to": 2000.0,
"doc_count": 754
},
{
"key": "2000.0-4000.0",
"from": 2000.0,
"to": 4000.0,
"doc_count": 1004
}
]
}
}
}
|
cs |
그리고 키값을 더 의미있는 값으로 지정해 줄 수도 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
{
"aggs":{
"bytes_range":{
"range":{
"field":"bytes",
"ranges":[
{"key":"small","from":1000,"to":2000},
{"key":"medium","from":2000,"to":4000}
]
}
}
}
}
->result
{
"took": 3,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"bytes_range": {
"buckets": [
{
"key": "small",
"from": 1000.0,
"to": 2000.0,
"doc_count": 754
},
{
"key": "medium",
"from": 2000.0,
"to": 4000.0,
"doc_count": 1004
}
]
}
}
}
|
cs |
-날짜 범위 집계
날짜 값을 범위로 집계를 수행한다. 날짜 포맷은 엘라스틱서치가 내부적으로 이해할 수 있는 날짜 타입이 와야한다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
{
"aggs":{
"request_count_date":{
"date_range":{
"field":"timestamp",
"ranges":[
{"from":"2015-05-04T05:16:00.000Z","to":"2015-05-18T05:16:00.000Z"}
]
}
}
}
}
->result
{
"took": 6,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"request_count_date": {
"buckets": [
{
"key": "2015-05-04T05:16:00.000Z-2015-05-18T05:16:00.000Z",
"from": 1.43071656E12, //시작날짜의 밀리초값
"from_as_string": "2015-05-04T05:16:00.000Z",
"to": 1.43192616E12, //끝날짜의 밀리초값
"to_as_string": "2015-05-18T05:16:00.000Z",
"doc_count": 2345 //날짜 범위에 해당되는 문서수
}
]
}
}
}
|
cs |
-히스토그램 집계(Histogram)
지정한 범위 간격으로 집계를 낸다. 만약 10000으로 지정하였다면, 0~10000(미포함), 10000~20000 의 간격으로 집계를 낸다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
{
"aggs":{
"bytes_histogram":{
"histogram":{
"field":"bytes", //집계필드
"interval":10000, //집계 간격
"min_doc_count":1 //최소 1개 이상되어야 결과에 포함
}
}
}
}
->result
{
"took": 3,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"bytes_histogram": {
"buckets": [
{
"key": 0.0,
"doc_count": 4196
},
{
"key": 10000.0,
"doc_count": 1930
},
{
"key": 20000.0,
"doc_count": 539
},
...
{
"key": 5.43E7,
"doc_count": 24
},
{
"key": 6.525E7,
"doc_count": 2
},
{
"key": 6.919E7,
"doc_count": 2
}
]
}
}
}
|
cs |
대시보드에서 시각화할때도 아주 좋은 역할을 할듯하다.
-날짜 히스토그램 집계
날짜 히스토그램 집계는 분, 시간, 월, 연도를 구간으로 집계를 수행할 수 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
{
"aggs":{
"daily_request_count":{
"date_histogram":{
"field":"timestamp", //집계 필드
"interval":"day", //집계 간격
"format":"yyyy-MM-dd" //출력되는 날짜 포맷 변경
}
}
}
}
->result
{
"took": 4,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"daily_request_count": {
"buckets": [
{
"key_as_string": "2015-05-17",
"key": 1431820800000,
"doc_count": 1632
},
{
"key_as_string": "2015-05-18",
"key": 1431907200000,
"doc_count": 2893
},
{
"key_as_string": "2015-05-19",
"key": 1431993600000,
"doc_count": 2896
},
{
"key_as_string": "2015-05-20",
"key": 1432080000000,
"doc_count": 2578
}
]
}
}
}
|
cs |
key_as_string은 집계한 기준 날짜인데, UTC가 기본이며 "yyyy-MM-dd'T'HH:mm: ss.SSS 형식을 사용한다. 하지만 "format" 필드로 형식 포맷 변경이 가능하다. key는 집계 기준 날짜에 대한 밀리초이다.
구간 지정을 위해서 interval 속성을 사용하는데, 여기에 year, quarter, month, week, day, hour, minute, second 표현식을 사용할 수 있고, 더 세밀한 설정을 위해 30m(30분 간격), 1.5h(1시간 30분 간격) 같은 값도 사용가능하다.
지금까지 사용한 예제에서 날짜는 모두 UTC 기준으로 기록됬다. 우리나라 사용자가 사용하기 위해서는 9시간을 더해서 계산해야 현재 시간이 되기 때문에 번거로울 수 있다. 하지만 엘라스틱서치는 타임존을 지원하기 때문에 한국 시간으로 변환된 결과를 받을 수 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
{
"aggs":{
"daily_request_count":{
"date_histogram":{
"field":"timestamp",
"interval":"day",
"format":"yyyy-MM-dd-HH:mm:ss",
"time_zone":"+09:00"
}
}
}
}
->result
{
"took": 3,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"daily_request_count": {
"buckets": [
{
"key_as_string": "2015-05-17-00:00:00",
"key": 1431788400000,
"doc_count": 538
},
{
"key_as_string": "2015-05-18-00:00:00",
"key": 1431874800000,
"doc_count": 2898
},
{
"key_as_string": "2015-05-19-00:00:00",
"key": 1431961200000,
"doc_count": 2902
},
{
"key_as_string": "2015-05-20-00:00:00",
"key": 1432047600000,
"doc_count": 2862
},
{
"key_as_string": "2015-05-21-00:00:00",
"key": 1432134000000,
"doc_count": 799
}
]
}
}
}
|
cs |
타임존과는 다르게 offset을 사용해 집계 기준이 되는 날짜 값의 조정이 가능하다. 위에서 데일리로 집계했을 때, 00시 기준이었는데, 3시를 기준으로 하고 싶다면 아래와 같이 사용하면 된다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
{
"aggs":{
"daily_request_count":{
"date_histogram":{
"field":"timestamp",
"interval":"day",
"format":"yyyy-MM-dd-HH:mm:ss",
"offset":"+3h"
}
}
}
}
->result
{
"took": 4,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"daily_request_count": {
"buckets": [
{
"key_as_string": "2015-05-17-03:00:00",
"key": 1431831600000,
"doc_count": 1991
},
{
"key_as_string": "2015-05-18-03:00:00",
"key": 1431918000000,
"doc_count": 2898
},
{
"key_as_string": "2015-05-19-03:00:00",
"key": 1432004400000,
"doc_count": 2895
},
{
"key_as_string": "2015-05-20-03:00:00",
"key": 1432090800000,
"doc_count": 2215
}
]
}
}
}
|
cs |
-텀즈 집계(terms)
텀즈 집계는 버킷이 동적으로 생성되는 다중 버킷 집계이다. 집계 시 지정한 필드에 대해 빈도수가 높은 텀의 순위로 결과가 반환된다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
{
"aggs":{
"request_count_country":{
"terms":{
"field":"geoip.country_name.keyword"
}
}
}
}
->result
{
"took": 8,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 10001,
"max_score": 0.0,
"hits": []
},
"aggregations": {
"request_count_country": {
"doc_count_error_upper_bound": 48,
"sum_other_doc_count": 2334,
"buckets": [
{
"key": "United States",
"doc_count": 3974
},
{
"key": "France",
"doc_count": 855
},
{
"key": "Germany",
"doc_count": 510
},
{
"key": "Sweden",
"doc_count": 440
},
{
"key": "India",
"doc_count": 428
},
{
"key": "China",
"doc_count": 416
},
{
"key": "United Kingdom",
"doc_count": 276
},
{
"key": "Spain",
"doc_count": 227
},
{
"key": "Canada",
"doc_count": 224
},
{
"key": "Russia",
"doc_count": 214
}
]
}
}
}
|
cs |
집계 필드는 "geoip.country_name" 필드인데, 해당 필드는 text와 keyword 타입 두개를 가지는 필드이며, 집계 필드로 "*.keyword"로 지정하였다. 이유는 text 데이터 타입의 경우 형태소 분석이 들어가기에 집계할때는 형태소 분석이 없는 keyword 데이터 타입을 사용해야만 한다. 물론 text 타입이 안되는 건 아니지만, 성능은.. 최악이 될것이다.
결과 값에 대해 설명하자면 "doc_count_error_upper_bound"는 문서 수에 대한 오류 상한선이다. 오류 상한선이 있는 이유는 각 샤드별로 계산되는 집계의 성능을 고려해 근사치를 계산하기에 문서 수가 정확하지 않아 최대 오류 상한선을 보여준다. "sum_other_doc_count"는 결과에 포함되지 않은 모든 문서수를 뜻한다.(size를 늘려 결과에 더 많은 집계 데이터를 포함시키면 된다. terms 안의 field와 같은 레벨로 size 옵션을 주면 된다.) key는 집계 필드 값이고, doc_count는 같은 필드 값의 문서수이다.
여기서 "doc_count_error_upper_bound" 값에 대해 조금 더 자세히 다루어보면, 내부 집계 처리 플로우는 각 샤드에서 집계를 한후에 모든 결과를 병합해서 집계 결과를 최종으로 반환한다. 하지만 아래와 같은 상황이 있다고 해보자.
| 샤드 A | 샤드 B | 샤드 C | |
| 1 | Product A(25) | Product A(30) | Product A(45) |
| 2 | Product B(18) | Product B(25) | Product C(44) |
| 3 | Product C(25) |
청크의 분포가 위와 같다라고 가정하고 집계 시 사이즈를 2로 지정하면 아래와 같은 결과를 반환할 것이다.
| 1 | Product A(100) |
| 2 | Product B(43) |
| 3 | Product C(44) |
결과는 나왔지만, Product C의 값에 오차가 생겼다. 즉, 쿼리 작성시 적절히 size값을 정해서 오차를 줄이거나 혹은 전부 포함시켜야한다. 하지만 역시나 사이즈를 키우면 키울 수록 집계 비용은 올라갈 것이다. 즉 위에서는 doc_count_error_upper_bound 값이 25가 될것이다.
집계와 샤드 크기
텀즈 집계가 수행될 때 각 샤드에게 최상위 버킷을 제공하도록 요청한 후에 모든 샤드로부터 결과를 받을 때까지 기다린다. 결과를 기다리다가 모든 샤드로부터 결과를 받으면 설정된 size에 맞춰 하나로 병합한 후 결과를 반환한다.
각 샤드는 size에 해당되는 갯수로 집계 결과를 반환하지 않는다. 각 샤드에서는 정확성을 위해 size의 크기가 아닌 샤드 크기를 이용한 경험적인 방법(샤드 크기*1.5+10)을 사용해 내부적으로 집계를 수행하는데, 텀즈 집계 결과로 받을 텀의 개수를 정확하게 파악할 수 있는 경우에는 shard_size 속성을 사용해 각 샤드에서 집계할 크기를 직접 지정해 불필요한 연산을 줄이면서 정확도를 높힐 수 있다.
앞서 설명한 바와 같이 shard_size가 기본값 -1로 되어있다면 엘라스틱서치가 샤드 크기를 기준으로 자동으로 추정한다. 만약 shard_size를 직접 설정할 경우에는 size보다 작은 값은 설정할 수 없다.
여기까지 간단히 버킷집계를 다루어보았고, 다음 포스팅에 이어 파이프라인 집계부터 다루어볼 것이다.
Elasticsearch - Aggregation API(엘라스틱서치 집계,메트릭(Metric Aggregations) 집계) -1
이번에 다루어볼 내용은 엘라스틱서치 Aggregation API이다. 해당 기능은 SQL과 비교하면 Group by의 기능과 아주 유사하다. 즉, 문서 데이터를 그룹화해서 각종 통계 지표 만들어 낼 수 있다. 엘라스틱서치의 집..
coding-start.tistory.com
Elasticsearch - Aggregation API(엘라스틱서치 집계,파이프라인(Pipeline Aggregations) 집계) -3
파이프라인 집계(Pipeline Aggregations)는 다른 집계와 달리 쿼리 조건에 부합하는 문서에 대해 집계를 수행하는 것이 아니라, 다른 집계로 생성된 버킷을 참조해서 집계를 수행한다. 집계 또는 중첩된 집계를..
coding-start.tistory.com
'Search-Engine > Elasticsearch&Solr' 카테고리의 다른 글
| Elasticsearch - 한글 자동완성(Nori Analyzer, Ngram, Edge Ngram) (0) | 2020.04.09 |
|---|---|
| Elasticsearch - Aggregation API(엘라스틱서치 집계,파이프라인(Pipeline Aggregations) 집계) -3 (0) | 2019.09.20 |
| Elasticsearch - Aggregation API(엘라스틱서치 집계,메트릭(Metric Aggregations) 집계) -1 (0) | 2019.09.19 |
| Elasticsearch - Rest High Level Client를 이용한 Index Template 생성 (0) | 2019.06.27 |
| ELK Stack - Logstash(로그스태시)를 이용한 로그 수집 (1) | 2019.06.26 |