[21.9.1]엘라스틱서치 기본 구조

http://www.yes24.com/Product/Goods/103030516

엘라스틱 스택 개발부터 운영까지 - YES24

 

해당 서적을 통해 글을 작성하였습니다. 

 

엘라스틱서치는 요청과 응답을 REST API 형태로 제공한다. REST(Representational State Transfer)란 웹상의 모든 리소스에 URI를 부여하고 활용하는 아키텍처이다. 

 

REST API는 총 4개의 메소드와 경로가 합쳐진 형태이다. 메소드는 다음과 같이 구성된다. 

 

POST : 해당 리소스를 추가한다. 

GET : 해당 리소스를 조회한다. 

PUT : 해당 리소스를 수정한다. 

DELETE : 해당 리소스를 삭제한다. 

 

이러한 4가지 메소드를 기반으로 CRUD(생성/읽기/수정/삭제) 작업을 한다. 

 

URI(Uniform Resource Identifier), 경로는 리소스를 명시하는 방법이며 URI로 리소스를 정의하고 메소드와 함께 서버에 요청하고 응답을 받는 구조다. 

 

예시) 

POST es_index/_doc/1

{

"name" : "kim",

"age" : 20

} 

es_index 라는 인덱스를 만들고 1번 도큐먼트를 생성한다는 뜻이다. 1번 도큐먼트 안에 있는 필드는 name과 age이며, 이에 대한 값은 kim과 20이다. 

 

 

GET es_index

es_index를 조회한다.

 

 

GET es_index/_doc/1

es_index 내부의 1번 도큐먼트만 조회한다. 

 

DELETE es_index

es_index를 삭제한다. 

 

즉 REST API는 메소드 + 경로로 나타내며 메소드는 리소스의 CRUD를 나타내고, URI는 정보를 나타낸다. 

 

 

 

 

 

엘라스틱서치 쿼리 방법은 다양한 방법이 있지만 가장 쉬운 방법은 키바나 콘솔을 사용하여 쿼리를 진행하는 방법이 있다. 

 

키바나 콘솔을 이용하면 복잡한 앱 개발이나 프로그램 설치 없이 엘라스틱 서치와 REST API로 통신할 수 있다. 

 

 

왼쪽 입력창은 REST API를 타이핑하며, 초록색 세모 버튼을 누르거나 CTRL + ENTER를 누르면 HTTP 요청문을 보낸다. 우측 출력창은 요청한 HTTP 응답을 확인할 수있다. 

 

또한 시스템의 전체적인 상태 확인을 위해 _cat API를 사용한다. 위의 이미지와 같이 좌측에 GET _cat 을 요청하면 _cat API가 지원하는 목록들을 볼 수 있다.

 

 위와 같이 GET _cat/indices?v를 치면 다음과 같이 이제까지 등록한 index의 목록들을 볼 수 있다. .kibana_1과 같이 dot으로 시작하는 인덱스는 default 인덱스이며, game과 index2는 사용자가 등록한 인덱스이다.  또한 ?v 파라미터는 데이터에 대한 필드들을 보여준다.

 

?v 이외에도 ?s(정렬), ?h(헤더) 등의 파라미터를 사용할 수 있다. 

 

 

엘라스틱서치를 이해하기 위해서 인덱스와 도큐먼트가 매우 중요하다. 인덱스는 도큐먼트를 저장하는 논리적 구분자이며, 도큐먼트는 실제 데이터를 저장하는 단위이다. 

 

엘라스틱서치는 결국 다음과 같은 구조를 갖게 된다. 

 

클러스터 : 엘라스틱서치에서 가장 큰 시스템 단위를 의미하며, 서로 다른 클러스터는 데이터의 접근, 교환을 할 수 없는 독립적인 시스템이다. 여러 대의 서버가 하나의 클러스터를 구성할 수 있으며, 한 서버에 다수의 클러스터가 존재 할 수 있다. (아래 블로그에서 발췌)

 

https://victorydntmd.tistory.com/308

[Elasticsearch] 기본 개념잡기

 

 

도큐먼트 : 엘라스틱서치에서 데이터가 저장되는 기본 단위로 JSON 형태이며, 하나의 도큐먼트 안에 여러 개의 "필드" : "값"을 가진다. 

 

ex ) 

{

 "name" : "nouu",

 "age" : 25,

 "gender" : "male"

}

 

인덱스 : 도큐먼트를 저장하는 논리적 단위이며, mysql과 같은 관계형 데이터베이스의 테이블과 유사한 개념이다. 하나의 인덱스에 다수의 다큐먼트가 포함되어 있는 구조이며, 동일한 인덱스에 있는 도큐먼트는 동일한 스키마를 갖는다.

모든 도큐먼트는 반드시 최소 하나의 인덱스에 포함되어야 한다.

 

 

인덱스는 스키마에 따른 그룹핑을 해주어야 한다. 회원 정보 도큐먼트와 장바구니 도큐먼트는 성격이 다르기 때문에 데이터의 스키마(데이터 타입이나 종류)도 다르다. 회원 정보는 회원의 이름이나 회원의 나이 같은 필드들이 들어가며, 장바구니 도큐먼트에는 상품명이나 날짜 같은 필드들이 들어간다. 

 

이렇듯 서로 다른 스키마를 가진 도큐먼트는 하나의 인덱스에 저장하는 방식은 옳지 않으며, 스키마에 따라서 인덱스를 구분해야한다.