[elasticsearch] 관계형 데이터 조인

엘라스틱서치는 NoSQL 구조이므로 RDBMS 방식의 관계를 지원하지 않는다.

공식 문서에 따르면 관계를 표현하기 위해 다음 방법을 쓰라고 되어 있다.

• Application 에서 Join 하기
  • 각 테이블마다 인덱스(또는 타입)을 만들고, 관계를 통한 검색을 할 때는 여러 차례의 쿼리를 거듭하는 방법. 필터 역할을 할 인덱스의 검색 결과가 적을 때 (1개일 때 가장 좋음) 효과적이다.
  • 다중쿼리 비권장
• Parent-Child
  • 하나의 문서 안에 관계 객체를 삽입하는 중첩 객체 방식과는 다르게, 관계 객체를 별도의 문서에 저장하는 방법
  • RDBMS의 1:N 관계 설정이 가능하다.
  • 한 문서가 update 되어도 연결된 다른 문서의 index를 update 하지 않는다.
  • child 의 속성으로 parent 를 검색하거나 parent 의 속성으로 child를 검색하는 것이 가능하다.
  • Nested(De-normalization) 방식에 비해 인덱스 성능은 더 좋지만, 검색 성능은 5-10배 느림
    • read보다 write가 중요할 때 사용하는 방식
  • Parent-Child 관계는 한세대 이상으로 확장될 수 있다. 이를 Grandparent-Grandchild 관계라고 한다.
  • parent와 child는 반드시 같은 샤드에 소속되어야 하기 때문에 인덱싱 할 때 제약사항이 발생하게 된다.
  • 사용방법
    • child인 타입에 parent가 어떤 타입인지 사전 정의가 되어있어야 한다.
    • child에 도큐먼트를 인덱싱 할 때 parent가 반드시 지정되어야 하며, 이때 parent 도큐먼트의 id를 입력한다.
    • parent 타입은 child가 무엇이 되는지 관여하지 않기 때문에 타입 정의시 작업은 필요없다.
    • child 도큐먼트의 parent 변경은 불가능하며 child 도큐먼트를 새로 인덱싱해야 한다.
      • parent-child는 반드시 같은 샤드에 속해야 하는데, 재지정을 할 parent 도큐먼트가 같은 샤드에 있을지 보장할 수 없기 때문
    • grandparent-granchild 관계인 경우, 모든 부모세대의 도큐먼트 id가 지정되어야 한다. 같은 샤드에 속하는 것을 보장하기 위함이다.
• Nested(De-normalization)
  • 데이터를 반정규화하여 색인하는 방법
  • 관계에 포함될 테이블의 주요 속성을 반정규화하여 넣어둔다.
  • 엘라스틱서치 본연의 방식
  • 검색 성능이 가장 좋다.
  • 중첩 객체는 필드 교차 검색을 방지하기 위해 필요하다. (what? 일단 넣어둠)

엘라스틱서치는 이해가 쉽고 성능이 좋은 Nested(De-normalization) 객체 방식으로 데이터를 저장하는 것을 권장하고 있다.

 

엘라스틱서치 공식문서 참고

 

 

 

 

파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있습니다.