[AWS][Elasticsearch] 엘라스틱 서치 기본 개념 및 간단 실습 코드 (opensearch와 의 비교/차이/분쟁)

Elasticsearch와 Opensearch의 비교/차이/분쟁?

기존 Elastic이라는 기업에서, 오픈소스로 Elasticsearch를 제공하고 있었다.

 

1. 2018년 2월 Elastic은 Elasticsearch의 상용 확장팩인 X-Pack이 Elastic EULA 라이센스의 적용을 받는 코드로 공개한다고 발표한다. Elasticsearch의 소스코드는 Apache 2.0 이고, 사용 기능인 X-pack이 포함된 폴더는 Elastic 라이선스가 적용된다는 의미.

2. Aamazon Elasticsearch Service를 운영하는 AWS는 Elasticsearch에 오픈 소스에 상용 소스 코드가 섞이게 되었고 구분도 명확하지 않아서 문제가 된다며 Open Distro for Elasticsearch를 공개함.

3. 2021년 1월 Elastic은 다시, Elasticsearch와 Kibana의 라이센스를 Apache 2.0에서 SSPL(Server Side Public License)과 Elastic 라이센스 듀얼 라이센스로 변경하겠다고 발표하며, 동시에 오픈소스 커뮤니티에 기여하지 않고 이득만 취한다고 AWS를 비난한다.

4. AWS는 Elasticsearch는 이제 오픈소스가 아니라며 Apache 2.0 라이센스의 Elasticsearch를 포크해서 곧 공개한 후 직접 운영하겠다고 발표함.

*** 2021년 9월 8일, Amazon Elasticsearch Service 이름이 Amazon OpenSearch Service로 변경됨.

* 참고 : https://blog.outsider.ne.kr/1533

* Opensearch

- 오픈소스로, Elasticsearch에서 파생된 분산 검색, 분석 제품

* Elasticsearch 소개

-  검색 엔진인 아파치 루씬 (Apache Lucene)으로 구현한 RESTful API 기반의 검색 엔진으로, JSON 기반의 비정형 데이터 분산 검색 및 분석을 지원함.

- 엘라스틱서치 내부에 데이터를 입력하고 이를 Index로 만들고, Index 기반으로 검색을 진행하는 형식.

** 데이터 저장소가 아니며, MySQL 같은 데이터베이스를 대체할 수 없다.

---

* Elasticsearch의 아키텍처 및 용어 정리

Elasticsearch Architecture

 

1) Cluster (클러스터)

 - Elasticsearch에서 가장 큰 시스템 단위를 의미하며, 최소 하나 이상의 노드로 이루어진 노드들의 집합을 말함.

 - 서로 다른 클러스터는 데이터의 접근, 교환할 수 없는 독립적인 시스템으로 유지되며, 여러 대의 서버가 하나의 클러스터를 구성할 수 있고, 한 서버에 여러 개의 클러스터가 존재할 수 있음. 

 

2) Node (노드)

 - Elasticsearch를 구성하는 하나의 단위 프로세스를 의미함.

 - 역할에 따라, Master-eligible, Data, Ingest, Tribe 등 다양한 역할의 노드로 구분할 수 있음.

아래는 몇 가지에 대한 설명이며, 노드에 대한 상세 설명은 "Elasticsearch 공식 문서"를 참고바랍니다.

* Master-eligible Node : 클러스터를 제어하는 마스터 노드로 선출될 수 있는 역할을 가진 노드

- Master Node의 역할

1.  인덱스 생성, 삭제
2.  클러스터 노드들의 관리 및 추적
3. 데이터 입력시, 할당할 샤드 지정

* Data Node : 데이터와 관련된 CRUD 작업과 관련있는 노드. 해당 노드는 CPU, 메모리 등 자원을 많이 소모함. (Master Node와 분리되는 것이 좋음)

* Ingest Node (수집노드) : 하나 이상의 수집 프로세서로 구성된 전처리 파이프라인을 실행하는 역할. 인덱스 생성 전, 문서의 형식을 다양하게 변경할 수 있음.

* Coordinating Node : 사용자의 요청을 받아서 처리하는 Node. 클러스터 관련 요청은 마스터 노드로, 데이터 관련 요청은 데이터 노드로 전달하는 역할

 

3) Index (인덱스)

 - Elasticsearch에서 index는 RDBMS에서 "database"와 대응하는 개념.

- Index는 Document들이 어디에 위치해있는지 Tracking 하는 Virtual한 것.

 

4) shard (샤드)

- Shard는 데이터가 직접 저장되고, 검색되는 공간. 

- Elasticsearch에서 스케일 아웃을 위해 index를 여러 shard로 쪼갠 것. 기본적으로 1개가 존재하며, 검색 성능 향상을 위해 클러스터의 샤드 갯수를 조정할 수 있음.

 4-1) Segment (세그먼트)

    - 각 Shard는 다수의 세크먼트로 구성되어 있음. Elasticsearch에서 문서의 빠른 검색을 위해 설계된 자료구조.

    - Elasticsearch에서 데이터(Document)를 저장하면, Elasticsearch는 데이터를 메모리에 모으고, 새로운 세그먼트를 디스크에 기록하여 검색을 리프레쉬(refresh). 이로 인해 새로운 검색 가능한 세그먼트가 만들어지게 됨.

 

5) Replica (레플리카)

- 또 다른 형태의 shard라고 할 수 있음.

- 노드를 손실했을 경우, 데이터의 신뢰성을 위해 샤드들을 복제해둔 것. 따라서, Replica는 서로 다른 노드에 존재하도록 권장됨. (위 아키텍처 참고)

 

"Cluster는 Node들의 집합이고 노드는 shard로 구성되며, 데이터는 shard로 분산되어 저장됨"

---

* Cluster 구성 이해하기

• 최초 설치시 Cluster내에 master node만 존재
• Primary shard는 데이터를 저장할 때 나눠진 파티션을 말하며, 설치시 5개가 존재함.
• Replica shard는 고가용성을 위해 존재하는 Primary shard의 복제본이며 설치시 1개가 존재함.
• primary와 replica는 같은 노드에 존재할 수 없음.

---

* Elasticsearch의 특징

• Scale Out: 샤드를 통해 규모가 수평적으로 늘어날 수 있음
• 고가용성 : Replica를 통해 데이터의 안정성 보장
• Schema Free : JSON 문서를 통해 데이터 검색을 수행하므로, Schema 개념이 없음.
• Restful : 데이터의 CRUD작업은 HTTP Restful API를 통해 수행함.

---

* Elasticsearch 논리적 구조

RDBMS와 용어 비교

 

1) Document (도큐먼트)

- Elasticsearch 데이터 최소 단위(RDBMS의 Row를 의미함.) JSON 형식이며, 다양한 필드로 구성되어있음. 

2) Type (타입)

 - 여러개의 Document가 모여 한개의 Type을 이룸. (RDBMS의 Table를 의미함.)

 - Elasticsearch 7.0부터 Type이 완전히 사라졌으며, 현재 Index가 RDBMS의 Table과 Database 역할을 한다고 생각하면 됨.

3) Field (필드)

 - Document에 들어가는 데이터 타입을 의미함. (RDBMS의 Cloumn를 의미함.) 단, Elasticsearch의 필드는 동적임. 하나의 필드가 여러개의 데이터 타입을 가질 수 있음.

4) Mapping (매핑)

 - 매핑은 필드와 필드의 속성을 정의하고, 색인(indexing) 방법을 정의함. 여러가지 데이터 타입 지정이 가능하지만, 필드명 자체는 중복이 불가함.

5) Index (인덱스)

- 데이터의 저장공간으로, 하나의 물리노드에 여러개 논리 인덱스를 생성할 수 있음. 

- 여러개의 Type이 모여 한개의 Index를 이룸(RDBMS의 Database와 비슷). Elasticsearch 6.1부터는 하나의 Index는 하나의 Type만 가질 수 있기 때문에 Database + Table의 역할을 함.

- RDBMS는 쿼리 하나로 여러 데이터베이스의 데이터를 동시에 조회할 수 없는 반면, Elasticsearch에서는 가능함.

- Elasticsearch를 클러스터(분산환경)으로 구성했을 경우 Index는 여러 노드에 분산 저장/관리됨.

- Restful API를 통해 index에 document를 추가하는 작업을 "indexing (색인화)" 이라고 함.

---

* Elasticsearch 데이터 색인 및 검색 원리

아래와 같은 데이터를 저장(색인) 한다고 할 때, RDBMS와 Elasticsearch의 데이터 저장(색인)형태의 차이는?

RDBMS의 경우, 위 이미지와 같이 테이블 형태로 저장될 것.

이 때, "walk"가 들어간 데이터를 검색을 한다면 한 줄씩 like문을 통해 데이터를 조회하므로 데이터가 많아질 수록 검색 속도가 느려짐.

 

반면, Elasticsearch는?

"역색인(Inverted Index)"을 통해 자제적으로 데이터를 저장. RDBMS와 달리, 텍스트를 다 tokenizer를 한 다음 검색어 사전을 만들어서 테이블 형태로 저장한다고 생각하면 됨. 따라서, 검색속도가 빠르다.

** 역인덱스(Inverted Index)를 데이터가 저장되는 과정에서 만들기 때문에 Elasticsearch는 데이터를 입력할 때 저장이 아닌 색인을 한다고 표현함.

색인 과정은 아래와 같음.

1. 대문자, 소문자 상관없이 검색되어야하기 때문에 모든 영어는 소문자로 변환
2. Dogs, DOG 등을 모두 dog으로 통일 시켜서 데이터 사전에 저장
3. 문장의 불필요한 단어를 제거하고, Token으로 만듬

Elasticsearch에 저장된 형태

각 추출된 키워드는 Term(텀)이라고 부름.

즉, 위 데이터에서 "walk"를 검색한다면 Doc2번을 바로 가져올 수 있다.

---

* Elasticserach CRUD / Search 예제

1. Create

- Index 생성

#형식
PUT "Index명"

#Ex
PUT favorite_movie

- Document 생성

: POST 혹은 PUT을 사용하여 Index 생성 가능. (차이점은? POST는 ID를 자동으로 생성함.(GUID > Global UID))

# POST 형식
POST Index명/_doc
{
    "field" : "value"
}

#Ex
POST favorite_movie/_doc
{
    "name": "괴물",
    "who": "봉준호"
}

<실행 결과>

POST 형식으로 생성한 결과 _id가 자동 생성됨을 확인할 수 있음.

 

# PUT 형식
PUT Index명/_doc/DocumentID지정
{
    "field" : "value"
}

#Ex
PUT favorite_movie/_doc/1
{
    "name": "괴물",
    "who": "봉준호"
}

<실행 결과>

POST 형식으로 생성한 결과 _id가 지정한 값으로 생성됨을 확인할 수 있음.

만약, 이미 존재하는 ID 에 새로운 값을 추가하는 경우라면?

>> 해당 ID의 기존 데이터가 UPDATE 되고, version이 변경됨.

#Ex
PUT favorite_movie/_doc/1
{
    "name": "기생충",
    "who": "봉준호"
}

버전이 2로 올라감을 확인

이를 막기 위해, _create를 사용하는 것을 권장함.

_create

: 기존과 겹치는 ID의 Document는 생성하지 않도록 함.

# PUT 형식
PUT Index명/_create/DocumentID지정
{
    "field" : "value"
}

#Ex
PUT favorite_movie/_create/1
{
    "name": "탑건",
    "who": "조셉"
}

<실행 결과>

충돌이 발생했다는 오류 발생시키며, 생성안됨.

---

2. Read

#GET 형식
GET Index명/_doc/DocumentId

#Ex
GET favorite_movie/_doc/1

<실행 결과>

_search

 : 특정 Index에 있는 전체 데이터 조회하기 (Elasticseach의 읽기 가능한 Default 값은 최대 10,000개)

#형식
GET Index명/_search

#Ex (10,000개까지만 조회됨)
GET favorite_movie/_search

#10,000개가 넘는 전체 데이터를 보려면?
GET favorite_movie/_search
{
    "track_total_hits": true
}

 

Simple Match Query

: 검색 조건을 주어 원하는 데이터만 조회하는 방법. ElasticSearch 자체에서 연관도(_score : 연관도 점수) 순서대로 조회됨. 

#Ex
GET favorite_movie/_search
{
    "query": {
        "match" : {
            "(field명)": {
                "query": "(원하는 keyword)" #해당 필드에 작성한 keyword가 들어간 데이터만 조회됨.
                "operator": "and" #keyword로 입력한 모든 단어가 포함된 데이터만 조회되도록 하는 조건.
                #"operator": "or" #Defualt 값. keyword로 입력한 단어 중 1개라도 포함된 데이터를 조회되도록 하는 조건. 
            }
        }
    }
}

 

Range Query

#Ex
GET favorite_movie/_search
{
    "query": {
        "range" : {
            "(field명)": {
                "gte": "특정 값1", # 특정 값1 보다 크고,
                "lte": "특정 값2"  # 특정 값2 보다 작은 데이터를 조회
            }
        }
    }
}

---

3. UPDATE

#UPDATE 형식
POST Index명/_update/documentID
{
    "doc" : {
        "field1": "value",
        "field2": "value",
        ...
    }
}

#Ex
POST favorite_movie/_update/1
{
    "doc" : {
        "name": "기생충"
    }
}

<실행 결과>

버전업이 되면서 update된 것을 확인

---

4. DELETE

#DELETE 형식
DELETE Index명/_doc/documentID

#Ex
DELETE favorite_movie/_doc/1

<실행 결과>

버전업이 되면서, delete된 것을 확인

다시 조회해보면, "found": false가 반환되는 것을 확인할 수 있다.

GET favorite_movie/_doc/1

<실행 결과>

 

 

---

* 참고 사이트

https://victorydntmd.tistory.com/308

 

[Elasticsearch] 기본 개념잡기

https://twofootdog.tistory.com/53

Elasticsearch 개념 및 구조

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=dufwjdrkdgur&logNo=221341574967 

엘라스틱서치 - 데이터 저장 , 검색 원리

* Opensearch 설명 발표자료

https://www.slideshare.net/awskorea/t2s2pdf

Amazon OpenSearch Deep dive - 내부구조, 성능최적화 그리고 스케일링