Elasticsearch (3) Mapping과 Field

Mapping

• Elasticsearch에서는 index에 document 형태로 데이터들을 정의한다. 
• 이때, index(DB의 테이블에 해당)에 저장될 document(DB의 각 row에 해당)의 구조와 document 내의 field(DB의 테이블 칼럼에 해당)의 속성을 정의하는 설정을 mapping이라고 한다. 
• DB의 DDL의 개념과 유사하다.
• Mapping은 기본적으로 JSON 형식을 띤다. 
• GET [index 이름]/_setting의 결과 중 mappings 부분을 통해 mapping 정보를 확인할 수 있다. 

 

동적 Mapping, 명시적 Mapping

• Elasticsearch에서는 사용자가 정의하지 않은 mapping에 대해서 정보를 추론하여 자동으로 mapping해주는 동적 Mapping을 제공한다.
• 예를 들어, DB에서는 정의되지 않은 칼럼에 Insert를 하는 경우 에러가 뜨지만, Elasticsearch에서는 데이터 값을 토대로 형추론을 하여, 새로운 Field가 만들어진다. 
• 동적 mapping은 자동으로 지정해 줘서 편리하다는 장점이 있지만, mapping 정보 중 대다수가 처음 정의된 이후 변경이 불가능하기 때문에, 사용자가 직접 mapping 정보를 정의하는 명시적 mapping 방법을 사용하는 게 좋다.

Field

• Elasticsearch에서 각 Field에 지정할 수 있는 타입은 아래와 같다. 

타입 종류		설명	예
숫자 타입	정수	- long : 64 비트 정수 - integer : 32 비트 정수 - short : 16 비트 정수 - byte : 8 비트 정수	POST /number_example/_doc { "price": 19.99 }
	소수	- double : 64 비트 소수 - float : 32 비트 소수 - half_float : 16 비트 소수
date 타입		- format을 지정하여 시간대로 변환 가능 - 내부에는 long 숫자로 색인됨	POST /date_example/_doc { "event_date": "2023-12-31" }
배열		-별도 타입 지정은 필요없지만, 배열의 각 원소들이 동일한 타입을 가져야함	POST /array_example/_doc { "tags": ["elasticsearch", "mapping", "example"] }
object 타입		- Field 안에 하위 Field 를 저장함  - 실제 저장할 때는, 평탄화시켜서 key-value 형태로 저장 - object 타입은 하위 Field 간 관계를 유지하지 않음	POST /object_example/_doc { "address": { "city": "Seoul", "postcode": 12345 } }
nested 타입		- 중첩된 배열 구조를 다룰 때, 요소 간의 관계를 유지하도록 설계된 데이터 타입 - object 타입과 달리, 하위 Field 간 관계가 유지된다.	POST /nested_example/_doc { "reviews": [ { "user": "Alice", "rating": 5, "comment": "Great product!" }, { "user": "Bob", "rating": 4, "comment": "Pretty good." } ] }
text 타입		- elasticsearch의 핵심 기능인 텍스트 검색을 위해 사용되는 타입 - text 타입에 데이터를 넣으면, analyzer(기본 값 standard analyzer)를 거쳐, 데이- 터를 역색인하여 검색이 가능하도록 함.	POST /text_example/_doc { "description": "Elasticsearch is a powerful search engine." }
keyword 타입		- 정확한 값을 검색하거나, 집계, 정렬, 필터링 등에 사용되기 위해 사용하는 타입 - text 타입과 달리 analyzer를 거치지 않고, normalizer를 거친 결과를 저장(지정 안해주면 문장 그대로 저장)	POST /keyword_example/_doc {   "status": "ACTIVE" }

 

※ object 타입과 nested 타입 비교

• object 타입과 nested 타입은 기본적으로 Field 안에 하위 Field를 저장할 수 있다는 점에서 비슷하지만, 요소 간의 관계를 유지하느냐 유지하지 않느냐에 따라 각각 nested 타입과 object 타입으로 분류된다. 
• 예를 들어, "person" : [{"name" : "minsu" , "age": 30}, {"name" : "bora" , "age": 29}]라는 데이터가 각각 object 타입과 nested 타입으로 저장되었을 때, elasticseach 검색 조건을 "name":"bora"면서, "age":30으로 찾았을 때, nested 타입에서는 실제 저장의도와 같게 검색이 되지 않지만, object 타입으로 저장하였을 때는 검색이 된다.
• 이것은 object 타입이 하위 Field 간 관계를 유지하지 않고, 각 하위 Field의 원소들을 List 형태로 평탄화 시켜 저장하기 때문이다.
• 따라서, 하위 Field에 대한 복수 조건이 많이 존재할 경우에는 nested 타입으로 저장해야한다. (상대적으로 무겁기 때문에 남용해서는 안된다.)

 

※ text 타입과 keyword 타입 비교

• 예를 들어, "나는 밥을 먹었다"라는 문장을 각각 text 타입과 keyword 타입에 넣으면, text 타입은 "나는", "밥을", "먹었다"로 역색인되어 저장될 것이고(analyzer마다 다르겠지만), keyword 타입은 "나는 밥을 먹었다"로 문장 그대로 저장될 것이다. 

특성	text 타입	keyword 타입
저장된 값	Token(analyer의 결과)	전체
검색 가능성	부분 단어 매칭, 전체 텍스트 검색 가능	정확하게 일치해야 검색 가능
검색 query	match, match_phrase	term, terms
집계/정렬	불가능(집계/정렬을 위하면 메모리 기반 fielddata 캐시 이용→ OOM 가능성 농후)	가능 (디스크 기반 doc_values 캐시 이용)
사용 사례	단어 검색	고정 데이터 ex) 도시명 등 특성 정보

 

 

_source Field

• 문서를 Elasticsearch에 저장하는 요청이 왔을 때, Elasticsearch에서는 문서의 원본 JSON 문서를 저장하는 데, 이 메타데이터 필드를 _source Filed라고 한다. 
• _source는 indexing 후에도 원본 상태(JSON 형태)를 유지하고, 쿼리 결과로 반환될 데이터를 제공한다.  예를 들어, "BaKe"라는 단어를 text 타입으로 저장하였을 때, "BAKE"로 anlyzer 처리 후 저장되겠지만, 실제 문서를 검색하면, "BaKe"라는 원본 상태로 조회된다.
• _source Field가 없으면, 데이터 자체를 조회하는 것이 불가하다.
• 만약, Indexing된 결과는 저장해야 하지만, 원본 문서를 디스크 용량상이나, 보안상(ex : 비밀번호 복호화된 것만 저장) 검색되지 원치 않는다면, _source에 저장되지 않도록 할 수 있다. (mapping - _source - enabled를 false로 PUT 호출)