반응형
elasticsearch는 인덱스 하나의 여러 type을 제공했다. 예를 들면 twitter라는 인덱스에 user와 tweet 두개의 타입을 가질 수도 있고 그 안에 Document들이 저장된다.
각각의 타입에 들어있는 properties에는 서로 다른 타입의 것과 독립적으로 보이기 때문에 각 타입에 같은 이름의 properties를 사용할 수 있다.
예를 들면 user type 필드에도 user_name을 만들고, tweet 필드에도 user_name을 만들 수있다.
그리고 각 type에 들어있는 document에는 _id 속성이 있는데 이는 각 타입별로 만들어지기 때문에 서로 다른 타입에 _id는 같은 값을 가질 수도 있다.
위의 내용까지는 얼추 알던내용인데 왜 7.0부터는 이 편한 multi type을 제거하려고 하는걸까? 우리는 공부할 때 엘라스틱 서치와 RDBMS와의 관계를 다음과 같이 정의 했었다.
하지만 어쩌면 이는 잘못된 설명이었다. 왜냐하면 Type과 매칭되는 Table은 각 table끼리 완전 개별적인 관계이기 때문에 각 테이블에 이름이 같은 컬럼이 있어도 상관이 없다. 하지만 사실 elasticsearch에서 서로다른 type간에 같은 이름이 존재하는 것은 이와 다른다.
왜냐하면 서로 다른 mapping type에 field는 내부적으로 같은 Lucene 필드를 사용한다. 다시 말하자면 위에서 예로들었던 user 타입의 user_name 필드는 tweet 유형의 user_name 필드와 정확히 동일한 필드에 저장되며 두 user_name 필드는 두 유형 모두에서 동일한 매핑 (정의)을 가져야한다.
즉 그렇기 때문에 서로 다른 타입의 동일한 이름을 가진 필드는 서로 관련이 있다는 뜻이다. 이런 문제로 필드를 지우거나 문서를 압축하거나 하는 등등에서 문제가 발생할 수 있다고 한다. 그래서 이를 제거하기로 하였고 6버전부터 차츰 기능을 빼고 있으면 7버전부터는 완전하게 제거한다고 한다.
대안
이렇게 multi type이 제거되고 index하나에 one type만 제공된다면 어떻게 기존의 방식을 처리하라는 뜻인가?
간단하게 하나의 인덱스에 하나의 타입만 사용해서 이 문제를 만들지 말자는 것 같다. 만약 위의 예에서 user와 tweet 타입을 별도의 인덱스를 사용해서 지정하는 것이다. 그러면 위와 같은 multi type 문제가 발생하지 않고 완전 개별적인 공간이라서 Data의 밀집도가 높아져서 루신에서 압축과 검색기능이 더 효율적으로 동작할거라는 설명이다.
이렇게 multi type이 제거되고 index하나에 one type만 제공된다면 어떻게 기존의 방식을 처리하라는 뜻인가?
간단하게 하나의 인덱스에 하나의 타입만 사용해서 이 문제를 만들지 말자는 것 같다. 만약 위의 예에서 user와 tweet 타입을 별도의 인덱스를 사용해서 지정하는 것이다. 그러면 위와 같은 multi type 문제가 발생하지 않고 완전 개별적인 공간이라서 Data의 밀집도가 높아져서 루신에서 압축과 검색기능이 더 효율적으로 동작할거라는 설명이다.
나도 아직 엘라스틱 서치를 사용해본지 일주일밖에 되지 않아서 자세히는 모르지만 대강 무슨뜻인지는 알 것 같다. 자세한 내용은 아래 링크를 들어가서 확인해보면 더 쉽게 이해할 수 있다.
참고자료
https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html
반응형
'데이터베이스 > Elasticsearch' 카테고리의 다른 글
elasticsearch session timeout 이슈 (0) | 2018.10.06 |
---|---|
Elasticsearch 한글 형태소 설치 및 사용 (0) | 2018.10.06 |
Elasticsearch 질의 DSL 정리 (0) | 2018.10.06 |
인덱스 생성 및 데이터 삽입 (0) | 2018.10.05 |
Docker Container에 Elasticsearch와 데이터 시각화 kibana 설치 및 연동 (0) | 2018.10.05 |