[OpenSearch] OpenSearch란?

출처: https://opensearch.org/docs/latest/about/#indices-and-documents

About OpenSearch

 

 

ElasticSearch랑 똑같은데 AWS를 사용한다.

즉 AWS에서 사용하는 엘라스틱서치

기능이나 개념 다 똑같은데 성능은 더 좋고 안정적이다.

 

Clusters and nodes

Each cluster is a collection of one or more nodes, servers that store your data and process search requests.

각 노드들이 모여 클러스터가 되고 각 서버(노드)는 데이터 저장 및 검색 처리를 한다.

 

Nodes with fast disks and plenty of RAM might be great at indexing and searching data, whereas a node with plenty of CPU power and a tiny disk could manage cluster state.

디스크, 램 좋은 노드는 인덱싱 및 데이터 검색하는데 사용하면 되고 CPU는 좋지만 디스크 작은 노드들은 클러스터 관리용 노드로 사용하면 된다.

 

Indices and documents

OpenSearch organizes data into indices.

오픈서치는 인디시즈로 데이터를 관리한다.

 

Each index is a collection of JSON documents

각 인덱스에는 JSON 데이터가 저장된다.

 

 

If you have a set of raw encyclopedia articles or log lines that you want to add to OpenSearch, you must first convert them to JSON.

만약 오픈서치에 데이터 넣고 싶다면 해당 데이터를 JSON으로 변환해야 한다.

 

A simple JSON document for a movie might look like this:

아래는 예시이다.

인덱스가 RDB의 테이블,

다큐먼트가 하나의 테이블 안에 있는 행이라고 생각하면 된다.

{
  "title": "The Wind Rises",
  "release_date": "2013-07-20"
}

 

When you add the document to an index, OpenSearch adds some metadata, such as the unique document ID:

데이터를 오픈서치의 익덱스에 저장하면, 오픈서치가 알아서 자동으로 메타데이터들을 넣어준다.

아래 예시에서 다큐먼트ID가 메타데이터 중에 하나이다.

{
  "_index": "<index-name>",
  "_type": "_doc",
  "_id": "<document-id>",
  "_version": 1,
  "_source": {
    "title": "The Wind Rises",
    "release_date": "2013-07-20"
  }
}

 

Indices also contain mappings and settings:

인디시즈엔 맵핑과 세팅도 포함되어 있다.

 

• A mapping is the collection of fields that documents in the index have. In this case, those fields are title and release_date.
  RDB로 치면 스키마이고 다큐먼트 필드들의 집합이다. 위 예시에서는 'title', 'release_date'가 매핑이다.
• Settings include data like the index name, creation date, and number of shards.
  세팅은 인덱스의 설정들을 의미하는데 예를 들면 인덱스 이름, 생성 일시, 샤드개수 등을 설정할 수 있다.

 

Primary and replica shards

OpenSearch splits indices into shards for even distribution across nodes in a cluster.

오픈서치는 엘라스틱서치와 똑같이 인덱스들(인디시즈)을 샤드로 쪼갠 뒤 클러스터 노드들에 저장한다.

 

For example, a 400 GB index might be too large for any single node in your cluster to handle, but split into ten shards, each one 40 GB, OpenSearch can distribute the shards across ten nodes and work with each shard individually.

예를 들어 400GB 인덱스를 한 노드에 저장하면 매우 비효율적이다. 따라서 이를 10개 샤드 40GB로 나누고 10개 노드에 분산 저장하면 효율적이게 된다.

 

By default, OpenSearch creates a replica shard for each primary shard.

기본적으로 오픈서치는 각각의 프라이머리 샤드에 대해서 하나의 레플리카 샤드가 만들어 진다.

 

If you split your index into ten shards, for example, OpenSearch also creates ten replica shards.

만약 10개의 프라이머리 샤드로 나눠지면 레플리카 샤드도 10개가 생성된다.

 

These replica shards act as backups in the event of a node failure—OpenSearch distributes replica shards to different nodes than their corresponding primary shards—but they also improve the speed and rate at which the cluster can process search requests.

이러한 레플리카 샤드들은 노드 장애와 같은 이슈발생시 백업용도로 사용된다. 따라서 프라이머리 샤드와 같은 노드에 존재하지 않게 된다. 또한 백업용도말고 검색요청시 레플리카 샤드들을 이용해서 성능도 향상되게 된다.

 

You might specify more than one replica per index for a search-heavy workload.

또한 검색량이 많은 인덱스들에 대해서는 세팅에서 레플리카 샤드 수를 수정해서 두 개 이상의 레플리카 샤드를 만들 수도 있다.

 

Despite being a piece of an OpenSearch index, each shard is actually a full Lucene index—confusing, we know.

오픈서치의 샤드는 루씬입장에서 보면 루씬의 인덱스이다.

즉, 루씬 인덱스 = 오픈 서치의 샤드 / 오픈 서치의 샤드가 여러 개 = 오픈서치 인덱스

아래 그림은 엘라스틱서치 인덱스 구조인데 오픈서치도 똑같다.

https://coding-start.tistory.com/176

 

This detail is important, though, because each instance of Lucene is a running process that consumes CPU and memory.

따라서 루씬의 인덱스가 실제로 CPU와 메모리를 사용해서 처리되는 프로세스이다.

 

More shards is not necessarily better.

샤드는 너무 많다고 좋은게 아니다.

 

Splitting a 400 GB index into 1,000 shards, for example, would place needless strain on your cluster.

만약 400 GB를 1000개의 샤드로 쪼갠다면 오히려 클러스터에 불필요한 부담을 주게 된다.

 

A good rule of thumb is to keep shard size between 10–50 GB.

가장 좋은 건 10~50GB 사이의 샤드 크기로 설정하는 것이다.

 

 

REST API

You interact with OpenSearch clusters using the REST API, which offers a lot of flexibility.

오픈서치와 클라이언트는 REST API로 통신할 수 있다.

 

You can use clients like 'curl' or any programming language that can send HTTP requests.

curl 명령어나 HTTP 요청이 가능한 프로그래밍 언어로 할 수 있다.

 

To add a JSON document to an OpenSearch index (i.e. index a document), you send an HTTP request:

오픈서치 인덱스에 JSON 도큐먼트를 추가하는 예제이다.

PUT https://<host>:<port>/<index-name>/_doc/<document-id>
{
  "title": "The Wind Rises",
  "release_date": "2013-07-20"
}

To run a search for the document:

도큐먼트 검색은 다음과 같이 한다.

GET https://<host>:<port>/<index-name>/_search?q=wind

To delete the document:

도큐먼트 지우기

DELETE https://<host>:<port>/<index-name>/_doc/<document-id>

You can change most OpenSearch settings using the REST API, modify indices, check the health of the cluster, get statistics—almost everything.

또 오픈서치 설정이나 인디시즈 수정, 클러스터 상태 점검, 통계확인 등등은 모두 REST API로 할 수 있다.