analyzer, coerce, 그리고 따로 시간을 내서 언급한 적은 없지만 properties, field, ignore_above. 이런 것들을 한데 묶어서 엘라스틱서치에서는 매핑 파라미터라고 불러요.
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-params.html
Mapping parameters | Elasticsearch Guide [7.14] | Elastic
www.elastic.co
모두 한 번씩 다 확인할 수는 없지만 몇개만 확인해볼게요.
format
포맷 파라메터는 date 타입의 필드에서 쓸 수 있어요. 그럼 그전에 date 타입에 대해서 먼저 좀 알아볼까요?
엘라스틱서치에서 date는 다음 세가지 형태로 쓸 수 있어요.
- 시간 없이 날짜만 나오게
- 시간 날짜 같이 나오게
- 밀리세컨즈 단위 epoch (long)
epoch는 1970년 1월 1일을 기준으로 특정 시점까지의 밀리초를 숫자로 쓴 거예요. 지금 이 글을 쓰는 순간의 epoch는 1631751956157이라고 나오네요.
문자열로 날짜를 저장해도 엘라스틱서치는 long타입 epoch 형식으로 시간을 저장해요. 대한민군 UTC +09:00으로 표현된 시간도 엘라스틱서치는 UTC 시간으로 변경해서 저장해요.
그럼 다시 format parameter는 입력받는 date 포맷을 정해주는 거에요. 예를 들어. 내가 설정을 변경할 수 없는 어떤 곳에서 로그를 받아오는데 그 로그에서는 시간을 2021-09-11 15:30:59.123이라고 표현을 한다고 생각을 해볼게요. 얼핏 보면 시간 날짜 같이 나오는, 엘라스틱서치에서 사용할 수 있는 date format이라고 착각할 수 있지만 엘라스틱서치에서 사용하는 date format은 ISO8601을 따라요. 그래서 이렇게 입력하게 되면 이 건 숫자가 아니라 그냥 문자열이라고 생각하고 엘라스틱서치는 에러를 뿜어내게 돼요. 한 글자만 바꿔주면 돼요. 저 빈칸을 T로 바꿔서 2021-09-11T15:30:59.123 이렇게 바꾸기만 하면 되는데 이게 안될 때 format parameter를 사용해서 ISO 8601을 따르지 않는 데이트 포맷을 엘라스틱서치가 날짜로 인식하게 할 수 있어요.
POST /books/_mapping
{
"properties": {
"pub_at": {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss.SSS"
}}}이렇게 하면 2021-09-11 15:30:59.123 이런 형식의 시간도 엘라스틱서치는 문자열이 아닌 시간으로 인식할 수 있어요.
한 가지 안타까운 건 포맷을 정하면 그 포맷대로만 시간이 들어가요. ISO 8601 형식의 시간과 yyyy-MM-dd HH:mm:ss.SSS 이런 형식을 같이 쓸 수 없어요. 이 건 방법이 있을 것 같은데 다음에 찾아볼게요.
그리고 이 y가 년도를 뜻하고 M이 월을 뜻하고 나머지 문자들이 무엇을 뜻하는지 이런 건 이쪽으로 들어가시면 볼 수 있어요.
properties
properties는 익숙한 파라미터예요. object 타입이나 nested 타입을 정의할 때 사용해요. 이미 익숙한 내용이니 조금 색다른 걸 이야기하자면 어떤 필드를 오브젝트 타입으로 만들기 위해서 하위 필드들을 properties로 묶어줬었는데 그렇게 하는 방법 외에 이런 방법도 있어요.
"author.first_name": { "type": "text" },
"author.last_name": { "type": "text" }
coerce
바로 이전에 봤던 coercion에서 썼던 coerce도 mapping parameters 중 하나에요.
coerce에서는 언급하지 않았지만 공식문서를 읽어보셨다면 특정 필드를 각각 컨트롤하는 게 아니라 인덱스 레벨에서 coerce 설정을 변경할 수도 있는 걸 보셨을 거 같아요.
PUT /books
{
"settings": {
"index.mapping.coerce": false
}}이런 구문을요.
마지막으로 하나만 더
doc_values
엘라스틱서치는 다양한 자료구조를 사용한다고 했어요. inverted index (역 색인)은 그중에 하나고요. 역 색인 구조는 어떤 term이 들어있는 도큐먼트를 찾을 때 매우 효율적인 구조이기는 하지만 다른 요청에도 항상 효과적이지는 않아요.
doc_values는 정렬과 집계에 효과적인 자료 구조를 디스크에 만들어주는데 대부분의 필드 타입을 지원해요. 기본적으로 doc_values는 활성화되어있지만 특정 필드는 "doc_values": false라고 명시적으로 비활성화할 수 있어요. 그럼 왜? 언제? 비활성화하는 게 좋을까요? 이 doc_values를 비활성화시키면 디스크 공간을 절약할 수 있어요. 데이터를 여러 가지 자료구조로 저장하는 건 특정 작업을 더 빠르게 할 수 있는 수단이 될 수 있는 반면 그만큼 디스크 공간을 더 사용하게돼요. 검색 시간을 내어주고 디스크 공간을 취하거나 디스크 공간을 내어주고 보다 빠른 검색 시간을 취할 수 있는 거예요. 그럼 언제 비활성화시키면 좋을까요? 어떤 필드 값에 대해서 정렬이나 집계, 스크립트를 통해 데이터를 얻는 등의 작업을 수행하지 않을 것이 명백한 경우에는 doc_values를 비활성화해서 디스크 공간을 절약하면 좋겠죠? 그런데 그런 상황이 잘 떠오르지는 않을 거예요. 이런 기능을 하는 파라미터가 있다. 정도만 알고 있어도 충분할 거 같아요. 엘라스틱서치를 아주 고오오 수준으로 사용할 때 즈음 사용할 일이 있지 않을까요?
외에도 많은 매핑 파라미터들이 있는데 혹시 필요할 때 또 언급하도록 할게요.
그럼 오늘도 여기까지.