2019. 5. 11. 15:48ㆍSearch-Engine/Elasticsearch&Solr
이번 포스팅에서 다루어볼 내용은 이전 포스팅에서 다룬 한글 형태소분석기를 이용한 기타 고급검색 기법에 대해 다루어볼 것이다. 물론 해당 고급검색에는 간략한 내용만 다루어보고 집계쿼리나 기타 유사도검색 기반 검색들은 다른 포스팅에서 다루어볼 것이다. 이번에 다루어볼 내용들이다.
- 검색 결과 하이라이팅
- 스크립트를 이용한 동적필드 추가
- 검색 템플릿을 이용한 동적 쿼리 제공
- 별칭을 이용하여 항상 최신 인덱스 유지하기
- 스냅샷을 이용한 백업과 복구
위 내용들을 다루어볼 것이다. 검색의 성능을 향상시키거나 그런 내용은 아니지만 알아두면 아주 유용한 기능들이기에 다루어볼 것이다.
검색결과 하이라이팅
하이라이팅은 문서 검색 결과에 사용자가 입력한 검색어를 강조하는 기능이다. 해당 기능을 통해 사용자가 입력한 검색어가 어디에 일치되는 지는 쉽게 눈으로 확인가능하다. 즉, 사용자의 편의를 위한 기능중 한가지라고 볼 수 있을 것이다.
|
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
|
POST http://localhost:9200/movie_search/_search
{
"size":1,
"query":{
"match":{
"movieNm":"그대 장미"
}
},
"highlight":{
"fields":{
"movieNm":{}
}
}
}
result =>
{
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 49,
"max_score": 10.243236,
"hits": [
{
"_index": "movie_search",
"_type": "_doc",
"_id": "cz3KqmkBjjM-ebDbBcoO",
"_score": 10.243236,
"_source": {
"movieCd": "2009A438",
"movieNm": "장미",
"movieNmEn": "",
"prdtYear": "",
"openDt": "",
"typeNm": "",
"prdtStatNm": "기타",
"nationAlt": "",
"genreAlt": "",
"repNationNm": "",
"repGenreNm": "",
"directors": [],
"companys": []
},
"highlight": {
"movieNm": [
"<em>장미</em>"
]
}
}
]
}
}
|
cs |
크게 어렵지 않다. 위처럼 쿼리를 날리게 되면 결과로 highlight가 나오는 걸 볼 수 있다. 화면에 뿌려줄때에는 highlight부분을 검색결과 링크로 뿌려주어도 될 것 같다. 그리고 em 태그 말고 다른 태그로 하이라이팅을 하고 싶을 수도 있다. 그럴때에는 몇개의 옵션만 추가해주면된다.
|
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
|
POST http://localhost:9200/movie_search/_search
{
"size":1,
"query":{
"match":{
"movieNm":"그대 장미"
}
},
"highlight":{
"pre_tags":["<string>"],
"post_tags":["</string>"],
"fields":{
"movieNm":{}
}
}
}
result =>
{
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 49,
"max_score": 10.243236,
"hits": [
{
"_index": "movie_search",
"_type": "_doc",
"_id": "cz3KqmkBjjM-ebDbBcoO",
"_score": 10.243236,
"_source": {
"movieCd": "2009A438",
"movieNm": "장미",
"movieNmEn": "",
"prdtYear": "",
"openDt": "",
"typeNm": "",
"prdtStatNm": "기타",
"nationAlt": "",
"genreAlt": "",
"repNationNm": "",
"repGenreNm": "",
"directors": [],
"companys": []
},
"highlight": {
"movieNm": [
"<em>장미</em>"
]
}
}
]
}
}
|
cs |
위와 같이 pre_tags,post_tags 옵션을 주어 하이라이팅할 단어에 태그를 지정해줄 수도 있다.
스크립트를 이용하여 동적으로 필드 추가하기
엘라스틱서치는 스크립트를 이용해 사용자가 특정 로직을 삽입하는 것이 가능하다. 이러한 방식을 스크립팅이라고 한다. 스크립팅을 이용하면 두 개 이상의 필드 스코어를 하나로 합하거나 계산된 스코어를 특정 수식으로 재계산하는 등의 작업이 가능해진다. 사용자는 이를 활용해 검색 요청시 특정 필드를 선택적으로 반환하거나 필드의 특정 요소를 수정하는 등 광범위한 작업을 할 수 있다.
엘라스틱서치에서는 스크립팅을 지원하는 두가지 방식이 존재한다.
- config 폴더에 스크립팅을 저장하여 콜하는 방식
- 요청바디에 스크립트를 포함하는 방식
그리고 지금 엘라스틱서치에서는 스크립팅 전용 언어인 페인리스(painless)가 개발되어 사용된다. 엘라스틱서치는 기본적으로 업데이트를 허용하지 않는다. 재색인을 통해 설정한 _id의 문서를 삭제하고 다시 생성할 뿐이다. 하지만 _update API를 제공하고 있는데, 이는 내부적으로 스크립팅을 사용하여 업데이트가 이루어지는 것이다. 오늘 다루어볼 스크립트는 문서의 필드를 동적으로 추가하고 삭제하는 예제이다.
|
1
2
3
4
5
6
7
8
9
|
PUT http://localhost:9200/movie_script/_doc/1
{
"movieList":{
"Death_Wish":5.5,
"About_Time":7,
"Suits":3.5
}
}
|
cs |
인덱스 및 문서를 하나 생성해준다.
|
1
2
3
4
5
|
POST http://localhost:9200/movie_script/_doc/1/_update
{
"script":"ctx._source.movieList.Black_Panther=3.7"
}
|
cs |
위와 같이 _update API를 이용하여 내부적으로 스크립트를 작성해 존재하지 않는 필드를 하나 생성해준다. ctx._source는 스크립트에서 제공하는 특수한 문법이다. 이는 색인된 문서에 접근하기 위한 문법이라고 생각하면 된다.
|
1
2
3
4
5
|
POST http://localhost:9200/movie_script/_doc/1/_update
{
"script":"ctx._source.movieList.remove(\"Suits\")"
}
|
cs |
기존에 존재하고 있는 Suits라는 필드를 삭제한다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
GET http://localhost:9200/movie_script/_doc/1
result =>
{
"_index": "movie_script",
"_type": "_doc",
"_id": "1",
"_version": 4,
"found": true,
"_source": {
"movieList": {
"Death_Wish": 5.5,
"About_Time": 7,
"Black_Panther": 3.7
}
}
}
|
cs |
결과값으로 Suits 필드가 삭제되고 Black_Panther가 추가된 것을 볼 수 있다. 이와 같이 스크립트를 이용하면 필드를 동적으로 추가,제거할 수도 있고, 어떠한 결과값을 재정의 하는 것도 가능해진다.
검색 템플릿을 이용한 동적 쿼리 제공
검색 템플릿은 엘라스틱서치 1.1 버전에 추가된 오래된 기능이다. 하지만 이를 통해 복잡한 검색 로직을 템플릿화하여 저장하고 활용할 수 있기때문에 매우 유용하다. 검색 템플릿의 필드명과 파라미터를 사용해서 쿼리를 전송하고 템플릿에 제공한 파라미터로 실제 검색이 이뤄진다.즉, 검색 템플릿을 사용하여 클라이언트쪽 코드가 아주 간략해지는 것이다.
또한 클라이언트 프로그램을 열어 검색의 요구사항이 변경될때마다 코드를 수정하고 다시 배포하는 것이 아니라 엘라스틱서치에 저장돼 있는 템플릿의 기존 쿼리를 수정하고 새 쿼리를 작성하면 되므로 이점이 있다. 검색 템플릿은 Mustache라는 템플릿 엔진을 사용해서 표현된다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
POST http://localhost:9200/_scripts/movie_search_template
{
"script":{
"lang":"mustache",
"source":{
"query":{
"match":{
"movieNm":"{{movie_nm}}"
}
}
}
}
}
|
cs |
검색 템플릿 하나를 생성해준다. 생성이 완료되면 밑의 요청을 보내 검색템플릿이 정상적으로 생성되었는지 정보를 확인한다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
GET http://localhost:9200/_scripts/movie_search_template
result =>
{
"_id": "movie_search_template",
"found": true,
"script": {
"lang": "mustache",
"source": "{\"query\":{\"match\":{\"movieNm\":\"{{movie_nm}}\"}}}",
"options": {
"content_type": "application/json; charset=UTF-8"
}
}
}
|
cs |
이제는 해당 템플릿을 이용하여 검색을 해보자.
|
1
2
3
4
5
6
7
8
9
10
11
|
POST http://localhost:9200/movie_search/_doc/_search/template
{
"id":"movie_search_template",
"params":{
"movie_nm":"그대"
}
}
|
cs |
아이디 값으로 검색 템플릿 이름을 주고 파라미터에 정의된 파라미터 명을 쓰고 값을 넣어주면 된다. 그리고 추후에 검색 템플릿의 변경이 생긴다면 생성과 동일한 요청으로 변경된 템플릿 요청을 보내주면 수정이 완료된다. 이렇게 클라이언트 코드의 수정이 없이도 쿼리의 변경이 가능하니 아주 편리한 기능이다.
**별칭을 이용해 항상 최신 인덱스 유지하기
엘라스틱서치 클러스터를 운영하는 중에 인덱스 매핑 설정이 변경되거나 인덱스가 깨진다면 기존에 생성된 인덱스를 삭제하고 다시 생성해야 할것이다. 그런데 운영중인 클러스터라면 인덱스 변경을 위하여 인덱스가 삭제되어있는 중에 사용자의 쿼리 요청을 받게되면 인덱스가 존재하지 않는다는 에러메시지를 인덱스가 다시 생성될 때까지 사용자는 보게 될 것이다. 이것이 운영중인 클러스터 상황에 나와야하는 상황일까? 절대 아니다. 절대 나와서는 안되는 상황인 것이다. 이러한 문제를 방지하기 위하여 엘라스틱서치에는 별칭(Alias)라는 기능을 제공한다. 이러한 기능은 Apache Solr에도 거의 동일하게 존재하는 기능이 있다. 필자는 솔라를 이용할때 해당 별칭기능을 이용하여 Active/Standby 컬렉션을 운영했던 경험이 있다. 아마 엘라스틱서치도 비슷한 구성으로 운영가능하지 않을까 생각한다. 그리고 하나의 인덱스에만 별칭을 줄 수 있는 것은 아니다. 여러개의 인덱스에 동일한 별칭을 주어 여러개의 인덱스를 하나의 별칭으로 검색 할 수 있도록 할 수도 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
POST http://localhost:9200/_aliases
{
"actions":[
{
"add":{"index":"movie_search","alias":"movie_alias"}
},
{
"add":{"index":"movie_search2","alias":"movie_alias"}
}
]
}
|
cs |
위와 같이 하나 이상의 인덱스를 동일한 별칭으로 설정할 수 있다. 멀티테넌시 기능을 이용하기 보다는 해당 별칭기능을 이용하는 편이 훨씬 나을 듯하다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
POST http://localhost:9200/movie_alias/_search
{
"size":1,
"query":{
"match":{
"movieNm":"그대 장미"
}
}
}
|
cs |
별칭으로 검색하는 예제이다. 이와같이 변경이 잦은 인덱스는 별칭을 이용하는 것이 좋다. 예를 들어 매일같이 변경되는 인덱스가 있다고 생각해보자. 그러면 인덱스명을 "인덱스명_타임스탬프" 형식으로 생성하고 다음날에는 이전 인덱스의 별칭을 삭제함과 동시에 새로운 인덱스에 별칭을 주면 사용자 입장에서는 변경되는 것을 알아차리지 못하고 별칭을 이용하여 새로운 인덱스에 요청을 보내게 된다. 이렇게 실무에서는 별칭을 이용하여 항상 최신의 인덱스를 유지하여 사용할 수 있다. 그리고 위에서 잠깐 이야기했지만, Active/StandBy 인덱스를 나누어서 사용해야할 일이 있다면 항상 Active에 별칭을 주고, Switch되는 이벤트가 발생하여 StandBy 인덱스가 Active로 가야한다면 별칭만 StandBy로 추가해주고 Active의 별칭을 삭제하면 Active<->StandBy 스위치가 이러나게 되는 것이다. 이렇게 별칭을 여러가지 용도로 사용가능하다.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
POST http://localhost:9200/_aliases
{
"actions":[
{
"remove":{"index":"movie_search","alias":"movie_alias"}
}
]
}
|
cs |
마지막으로 별칭을 삭제하는 요청이다. 해당 요청에는 위와 동일하게 add,remove를 같이 배열로 요청을 보낼 수 있으므로, 인덱스 변경시에는 add와 remove를 동시에 요청을 보내면 될듯하다.
**스냅샷을 이용한 백업&복구
엘라스틱서치 클러스터를 관리하다 보면 항상 하게 되는 고민 중 하나인 데이터 백업 정책이다. 검색 서버가 항상 안정적이라는 보장은 없기때문에 항상 백업과 복구를 염려해야하는 것은 당연한 것이다. 단순히 데이터 소스를 제공하는 시스템에서 다시 데이터를 Full 색인하면 된다라는 생각을 버려야한다. 데이터가 아주 크다면 아주 오랜시간 동안 색인 작업이 이루어질 것이고, 그러면 그 시간동안 서비스는 불가능 할 것이다. 이러한 고민을 해결해주기 위해 엘라스틱서치는 _snapshot API를 제공해준다. 해당 기능을 이용하여 개별 인덱스를 백업할 수도 있고, 클러스터 전체를 스냅샷으로 만드는 것도 가능하다. 그리고 스냅 샷은 점진적으로 가져온다. 즉, 인덱스의 스냅 샷을 만들 때, Elasticsearch는 동일한 인덱스의 이전 스냅 샷의 일부로 이미 리포지토리에 저장된 데이터를 복사하지 않도록한다. 따라서 클러스터의 스냅 샷을 자주 가져 오는 것이 효율적일 수 있다.
1)백업 디렉토리 생성
스냅샷 기능을 이용하기 위해서는 스냅샷이 저장될 물리적인 디렉토리를 생성해주어야 한다.원하는 위치에 디렉토리를 하나 생성해준다.
2)백업 디렉토리 등록
엘라스틱서치가 물리적인 백업용 디렉토리를 인식할 수 있도록 elasticsearch.yml 파일에 설정해준다.
백업디렉토리는 위와 같이 배열로 여러 경로를 지정해줄 수 있다. 용도별 스냅샷 디렉토리를 구분할 필요가 있다면 여러개 설정해주어도 될듯하다. 엔진을 재시작한다.
3)레포지토리 생성
다음은 스냅샷들을 저장하는 논리적인 저장공간을 만들것이다. 이를 레포지토리라고 부른다. 레포지토리는 설정 내에 물리적인 디렉토리 내부를 저장소로 이용한다. 또한 레포지토리를 생성할 때 다양한 설정 값을 지정할 수 있다. 스냅샷을 백업&복구하는 작업은 시스템 리소스를 많이 사용하기에 몇가지 옵션을 잘 조합해서 사용하는 것이 좋다. 즉, 해당 기능은 엘라스틱서치가 파일시스템을 백업과 복구를 이용하기 위해 등록하는 과정이라고 보면된다.
| 매개변수 | 설정 |
| location | 스냅샷의 물리적인 저장 경로설정. |
| compress | 스냅샷 생성이 압축 수행여부. 이때 데이터 자체는 압축되지 않고 메타데이터만 압축 대상이 된다. |
| chunk_size | 생성되는 파일을 특정 크기로 나누어서 생성할 수 있다. 기본적으로 스냅샷은 하나의 파일로 생성된다. |
| max_restore_bytes_per_sec | 스냅샷 복원 시 속도를 설정한다. 기본적으로 초당 40MB의 속도이다. |
| max_snapshot_bytes_per_sec | 스냅샷 생성(백업)시 속도를 설정한다. 기본적으로 초당 40MB의 속도이다. |
| readonly | 레포지토리를 읽기 전용으로 생성한다. |
|
1
2
3
4
5
6
7
8
9
10
11
12
|
PUT http://localhost:9200/_snapshot/movie_data_backup
{
"type":"fs",
"settings":{
"location":"/Users/yun-yeoseong/elasticsearch-file/elasticsearch-6.4.3/backup_snapshot",
"compress":true
}
}
|
cs |
위 요청으로 레포지토리를 생성해준다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
GET http://localhost:9200/_snapshot/movie_data_backup
result=>
{
"movie_data_backup": {
"type": "fs",
"settings": {
"compress": "true",
"location": "/Users/yun-yeoseong/elasticsearch-file/elasticsearch-6.4.3/backup_snapshot"
}
}
}
|
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
|
GET http://localhost:9200/_snapshot/search*,agg*,movie*
result=>
{
"searchexam": {
"type": "fs",
"settings": {
"compress": "true",
"location": "/Users/yun-yeoseong/elasticsearch-file/book_backup/search_example"
}
},
"aggexam": {
"type": "fs",
"settings": {
"compress": "true",
"location": "/Users/yun-yeoseong/elasticsearch-file/book_backup/agg_example"
}
},
"movie_data_backup": {
"type": "fs",
"settings": {
"compress": "true",
"location": "/Users/yun-yeoseong/elasticsearch-file/elasticsearch-6.4.3/backup_snapshot"
}
}
}
|
cs |
또한 위와 같이 "*"를 이용하여 여러개의 레포지토리를 조회할 수도 있다.
4)스냅샷 생성(백업)
레포지토리가 정상적으로 생성되면 스냅샷을 생성한다. 기본적으로 스냅샷 대상이 되는 인덱스는 더 이상 변경이 없는 인덱스여야만 한다. 변경이 일어나는 도중에 스냅샷이 생성되면 문제가 발생할 수 있다. 그리고 스냅샷 이름은 클러스터 내에서 꼭 유일한 이름이여야한다. 만약 스냅샷 이름이 동일한 것이 존재한다면 에러를 내뱉을 것이다.
|
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
|
PUT http://localhost:9200/_snapshot/movie_data_backup/movie_snapshot_20190511?wait_for_completion=true
{
"indices":"movie_search",
"ignore_unavailable":true,
"include_global_state":false
}
result=>
{
"snapshot": {
"snapshot": "movie_snapshot_20190511",
"uuid": "m9glqYcyS_mNiv7ZTJmZ8Q",
"version_id": 6040399,
"version": "6.4.3",
"indices": [
"movie_search"
],
"include_global_state": false,
"state": "SUCCESS",
"start_time": "2019-05-11T06:37:08.496Z",
"start_time_in_millis": 1557556628496,
"end_time": "2019-05-11T06:37:08.880Z",
"end_time_in_millis": 1557556628880,
"duration_in_millis": 384,
"failures": [],
"shards": {
"total": 5,
"failed": 0,
"successful": 5
}
}
}
|
cs |
wait_for_completion=true 옵션을 이용하면 스냅샷 생성이 완료될 때까지 기다린다. 만약 false로 설정하면 스냅샷 초기화가 완료된 직후에 결과를 반환한다. 그리고 내부적으로 백업할 인덱스명을 옵션으로 줄 수 있다.(indices) 하지만 해당 옵션을 사용하지 않으면 기본값으로 해당 클러스터 내부의 모든 인덱스를 백업대상으로 삼는다. 인덱스명은 ","구분으로 여러개를 지정할 수 있다. 그리고 ignore_unavailable 옵션을 true로 설정하면 명시한 indices 옵션에 설정한 인덱스가 존재하지 않는다면 해당 인덱스를 무시하고 다른 인덱스들 백업을 하게 된다. 만약 false로 설정하면 백업을 지정한 인덱스가 존재하지 않으면 에러를 내뱉는다. include_global_state는 클러스터 글로벌 설정을 백업의 일부로 포함시키지 않는다. 만약 해당 설정을 true로 설정하면 모든 샤드에 대해 글로벌 설정이 맞지 않으면 백업이 실패한다. 그리고 만약 스냅샷의 이름의 일부로 날짜등의 데이터를 넣어야 한다면 날짜 표현식을 넣을 수도 있다. 날짜를 넣는다면 데일리 백업에 있어 구분하기 쉬운 방법이 될 것이다. 그리고 배치등을 이용하여 다시 복구할때 소스의 수정없이 날짜 표현식을 이용하면 된다. 해당 표현식은 반드시 URL 엔코딩이 된 문자열이여야한다.
|
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
|
# PUT /_snapshot/my_backup/<snapshot-{now/d}>
PUT http://localhost:9200/_snapshot/movie_data_backup/%3Csnapshot-%7Bnow%2Fd%7D%3E?wait_for_completion=true
{
"indices":"movie_search",
"ignore_unavailable":true,
"include_global_state":false
}
result=>
{
"snapshot": {
"snapshot": "snapshot-2019.05.11",
"uuid": "k3GeN2rrS2meMFptYPfAOA",
"version_id": 6040399,
"version": "6.4.3",
"indices": [
"movie_search"
],
"include_global_state": false,
"state": "SUCCESS",
"start_time": "2019-05-11T06:55:51.344Z",
"start_time_in_millis": 1557557751344,
"end_time": "2019-05-11T06:55:51.366Z",
"end_time_in_millis": 1557557751366,
"duration_in_millis": 22,
"failures": [],
"shards": {
"total": 5,
"failed": 0,
"successful": 5
}
}
}
|
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
|
GET http://localhost:9200/_snapshot/movie_data_backup/*
GET http://localhost:9200/_snapshot/movie_data_backup/_all
GET http://localhost:9200/_snapshot/movie_data_backup/snapshot*
result=>
{
"snapshots": [
{
"snapshot": "movie_snapshot_20190511",
"uuid": "m9glqYcyS_mNiv7ZTJmZ8Q",
"version_id": 6040399,
"version": "6.4.3",
"indices": [
"movie_search"
],
"include_global_state": false,
"state": "SUCCESS",
"start_time": "2019-05-11T06:37:08.496Z",
"start_time_in_millis": 1557556628496,
"end_time": "2019-05-11T06:37:08.880Z",
"end_time_in_millis": 1557556628880,
"duration_in_millis": 384,
"failures": [],
"shards": {
"total": 5,
"failed": 0,
"successful": 5
}
},
{
"snapshot": "snapshot-2019.05.11",
"uuid": "k3GeN2rrS2meMFptYPfAOA",
"version_id": 6040399,
"version": "6.4.3",
"indices": [
"movie_search"
],
"include_global_state": false,
"state": "SUCCESS",
"start_time": "2019-05-11T06:55:51.344Z",
"start_time_in_millis": 1557557751344,
"end_time": "2019-05-11T06:55:51.366Z",
"end_time_in_millis": 1557557751366,
"duration_in_millis": 22,
"failures": [],
"shards": {
"total": 5,
"failed": 0,
"successful": 5
}
}
]
}
|
cs |
마지막으로 결과값에 포함된 state의 값의 의미이다.
| 값 | 설명 |
| IN_PROGRESS | 스냅샷 생성중. |
| SUCCESS | 스냅샷이 정상적으로 생성됨. |
| FAILED | 스냅샷이 정상적으로 생성되지 못하였으며, 어떠한 데이터도 저장되지 않음. |
| PARTIAL | 글로벌 클러스터 상태가 저장되었지만 하나 이상의 샤드의 데이터가 성공적으로 저장되지 않음. |
| INCOMPATIBLE |
스냅 샷은 이전 버전의 Elasticsearch로 작성되었으므로 현재 버전의 클러스터와 호환되지 않음. |
공식도큐먼트 글
|
인덱스 스냅 샷을 만드는 과정에서 Elasticsearch는 이미 리포지토리에 저장된 인덱스 파일 목록을 분석하고 마지막 스냅 샷 이후에 작성되었거나 변경된 파일 만 복사합니다. 따라서 여러 스냅 샷을 압축 된 형태로 저장소에 보존 할 수 있습니다. 스냅 샷 프로세스는 비 차단 방식으로 실행됩니다. 스냅 샷을 생성하는 인덱스에 대해 모든 인덱싱 및 검색 작업을 계속 실행할 수 있습니다. 그러나 스냅 샷은 스냅 샷이 생성 된 시점의 인덱스의 특정 시점보기를 나타내므로 스냅 샷 프로세스가 시작된 후 인덱스에 추가 된 레코드는 스냅 샷에 표시되지 않습니다. 스냅 샷 프로세스는 시작되었지만 현재 재배치되지 않은 기본 샤드에 대해 즉시 시작됩니다. 버전 1.2.0 이전에는 클러스터에 스냅 샷에 참여하는 색인의 재배치 또는 초기화 기본이있는 경우 스냅 샷 작업이 실패합니다. 버전 1.2.0부터 Elasticsearch는 Shard의 재배치 또는 초기화가 스냅 샷을 만들기 전에 완료 될 때까지 대기합니다. 각 인덱스의 복사본을 만드는 것 외에도 스냅 샷 프로세스는 영구 클러스터 설정 및 템플릿을 포함하는 글로벌 클러스터 메타 데이터를 저장할 수 있습니다. 일시적 설정 및 등록 된 스냅 샷 저장소는 스냅 샷의 일부로 저장되지 않습니다. 언제든지 하나의 스냅 샷 프로세스 만 클러스터에서 실행할 수 있습니다. 특정 샤드의 스냅 샷이 생성되는 동안이 샤드는 다른 노드로 이동할 수 없으므로 균형 조정 프로세스 및 할당 필터링을 방해 할 수 있습니다. Elasticsearch는 스냅 샷이 완료되면 샤드를 다른 노드로 이동시킬 수 있습니다 (현재 할당 필터링 설정 및 재조정 알고리즘에 따라). |
스냅샷 복구
|
1
|
POST http://localhost:9200/_snapshot/movie_data_backup/movie_snapshot_20190511/_restore
|
cs |
위와 같은 요청으로 스냅샷 복구가 가능하다. 하지만 여기서 주의해야 할것은 이미 스냅샷에 저장된 인덱스가 존재할 경우에는 복구에 실패하게 된다. 이말은 즉, 동일한 인덱스가 존재한다면 삭제하고 복구해야한다는 것이다.
스냅샷 삭제
|
1
|
POST http://localhost:9200/_snapshot/movie_data_backup/movie_snapshot_20190511
|
cs |
위의 요청을 보내면 스냅샷이 삭제됨과 동시에 물리적인 디렉토리에서도 삭제되는 것을 볼 수 있다.
자세한 설명은 공식 Reference를 참고하면 될듯하다. 스냅샷의 여러 옵션등을 참고 할 수 있다.
Snapshot and Restore | Elasticsearch Reference [7.0] | Elastic
The snapshot format can change across major versions, so if you have clusters on different versions trying to write the same repository, snapshots written by one version may not be visible to the other and the repository could be corrupted. While setting t
www.elastic.co
지금까지 다양한 검색과 백업/복구 등의 예제를 다루었다. 사실 이것보다 훨씬 다양하고 많은 옵션,기능이 존재한다. 모든 것을 다 다룰 수는 없기때문에 필요한 것은 도큐먼트를 참고하거나 혹은 엘라스틱서치 커뮤니티를 이용해도 좋을 것 같다.
'Search-Engine > Elasticsearch&Solr' 카테고리의 다른 글
| Elasticsearch - High Level Rest Client API Doc (0) | 2019.05.25 |
|---|---|
| Elasticsearch - 6. Elasticsearch Java Client !(엘라스틱서치 자바 클라이언트,High-Level Rest Client) (2) | 2019.05.25 |
| Elasticsearch - 4.한글 형태소분석기(Nori Analyzer) (6) | 2019.05.09 |
| Elasticsearch - 3.부가적인 검색 API (0) | 2019.05.08 |
| Elasticsearch - 2.검색 API(Elasticsearch Query DSL) (0) | 2019.05.07 |