[Node.js] Elastic Search

🔎 ElasticSearch가 뭘까?

일래스틱 서치가 뭘까? 위키백과에 따르면 다음과 같다. ElasticSearch는 루씬 기반의 검색 엔진으로 HTTP 웹 인터페이스와 스키마에서 자유로운 JSON 문서와 함께 분산 멀티테넌트 지원 전문 검색 엔진을 제공한다고 한다.  이는 모든 종류의 문서를 검색하는데 사용할 수도 있으며 가변 검색 및 실시간에 가까운 검색을 제공하며 멀티테넌시를 지원한다고 한다.

공식문서의 간략한 소개글에서도 엿볼 수 있는 부분이 있는데 바로  분산형 RESTful 검색 및 분석 엔진이라는 것이다.

 

일래스틱 서치는 차세대 데이터 플랫폼이며 검색, 분석, 데이터 저장소 역할을 하는 ElasticSearch와 데이터 수집을 담당하는 Beats, 정제, 전처리를 수행하는 Logstash, 시각화, 관리 기능을 제공하는 Kibana로 구성된다고 한다.

 

이미지 출처 : https://s-core.co.kr/insight/view/%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98elasticsearch%EC%97%90%EC%84%9C-%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-%ED%95%98%EA%B8%B0/

 

일래스틱은 매우 빠른 속도와 확장성, 복원성 뿐 아니라 정형, 비정형 데이터를 모두 수용할 수 있는 유연성이 있다는 점에서도 강점을 보이고 있으며 단순 검색엔진으로 활용하는 단계를 이제는 넘어서서 빠른 데이터 확인이 필요한 모든 분야에서 관심을 끌고 있다고 한다. 대표적으로 마케팅 분석, 비지니스 서비스, 인프라 모니터링, 보안, 실시간 탐지 등이 있다.

 

 

🔎 ElasticSearch에서의 관계형 데이터 모델링?

일래스틱 서치에서 관계형 데이터 모델링 방법은 크게 4가지가 있다고 한다. 각각은 저마다 장단점이 뚜렷하기 때문에 상황에 맞게 적절하게 사용하여야 하는데 한번 알아보도록 하자.

 

 

1️⃣ Parent-Child 모델링

 

일래스틱 서치가 제공하는 Join data type을 바탕으로 설계하는 방법으로 하나의 인덱스에서 Parent와 Child 도큐먼트 간에 Join type으로 Parent, Child를 구분하고 Parent와 Child 도큐먼트에서 같은 라우팅 ID를 키로 제공하여 같은 샤드(Shard)에 위치하게끔 설계한다고 한다.이는 전체 도큐먼트에서 업데이트와 삭제가 빈번하고 1:N 관계의 구조일 때 고려해 볼 만 하다고 한다.단점으로는 라우팅 ID를 별도로 관리해야하는 점과 기존 쿼리에 비해 내부 연산이 많아 쿼리 자체에 부하가 있는 점과 집계 일부 쿼리 기능에 대한 제약이 있다는 점을 꼽을 수 있다고 한다.

 

2️⃣ Nested 모델링

 

일래스틱 서치의 Nested data type을 활용해 설계하는 이 방법은 하나의 인덱스에서 Nested data type을 선언하고 오브젝트 속성들을 정의하여 연속(Array)하게 배치하는 방식이다. 두 개 이상의 속성을 가진 오브젝트를 배열(Array) 구조로 표현해야 할 때 고려해 볼 수 있는데 단점으로는 쿼리, 집게, 업데이트에 유의해야하는 부분이 있다.

 

3️⃣ Application Side Join 모델링

 

기본 키(PK)를 기준으로 관계있는 Entity들을 서로 다른 도큐먼트에 배치하여, Application side에서 키를 기준으로 Join하여 처리하는 방식이다. 이 모델링은 1:1관계의 구조로 기존 쿼리와 집계를 그대로 사용해야 할 때 고려해 볼 수 있으며 일래스틱서치 쿼리를 그대로 사용 가능하다는 장점이 있으나 Application side에서 키 값을 기준으로 2회 이상 조회하여 가공해야 하기에 페이징 및 정렬 처리에 유의할 사항이 많다는 단점을 꼽을 수 있다. 일반적으로 관계가 있는 단순 조회 목적일 때 고려해 볼 만한 방법이라고 한다.

 

4️⃣ Denormalization 모델링

 

데이터 전체를 비정규화하여 인덱싱하는 방법으로 각 데이터의 중복을 허용하여 Join이 필요하지 않도록 한다. 이 기법은 Join연산 자체가 필요없으며 쿼리 시점에서 최고의 성능을 낼 수 있다는 장점으로 잘만 활용하면 최고의 모델링이 될 수 있다고 한다. 단점으로는 데이터 크기가 기하급수적으로 증가할 수 있는 구조이기에 공통 필드의 변경이 잦거나 한정된 물리 서버로 구성해야한다면 좋지 않을 수도 있을 것이다. 이 Denomalization 모델링은 일래스틱에서 어떻게 데이터를 가공하고 처리하는지에 대한 3가지 방법이 존재하는데 아래의 참조 파일을 통해 자세히 배워보도록 하자.

 

---

참조 : https://s-core.co.kr/insight/view/%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98elasticsearch%EC%97%90%EC%84%9C-%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-%ED%95%98%EA%B8%B0/

에스코어