OpenSearch

OpenSearch 는 쌓아 둔 문서를 낱말로 찾아 주고 모아서 분석해 주는 검색 서버입니다. Elasticsearch 의 라이선스가 바뀌자 바뀌기 전 마지막 버전을 복사해 따로 이어 온 것입니다. 검색하는 방식은 Elasticsearch 와 뿌리가 같습니다. 다른 것은 조건을 더 붙이지 않는 Apache License 2.0 으로 풀려 있다는 점입니다.

상세

OpenSearch 는 분산 검색·분석 엔진입니다. 분산이라는 말은 여러 대의 컴퓨터에 나눠 띄울 수 있다는 뜻입니다. 데이터를 넣어 두면 찾고 분석할 수 있습니다. 쓰임은 웹사이트의 검색창부터 보안 데이터를 분석해 위협을 찾는 일까지 넓습니다.

OpenSearch 는 Elasticsearch 를 포크해서 나왔습니다. Elasticsearch 는 OpenSearch 와 같은 일을 하는 검색·분석 소프트웨어입니다. 포크는 남의 소스 코드를 복사해 별개의 제품으로 따로 이어 가는 일입니다. 왜 포크했는지는 아래 「배경」이 다룹니다.

문서와 인덱스

OpenSearch 는 데이터를 문서 단위로 저장합니다. 문서는 글이나 구조가 있는 데이터를 담는 한 덩이입니다. 문서는 JSON(JavaScript Object Notation) 형식으로 적습니다. 학생 한 명을 나타내는 {"name": "John Doe", "gpa": 3.89} 같은 덩이가 문서 하나입니다.

서로 관련된 문서를 묶은 것이 인덱스입니다. 학생 문서들은 students 인덱스에 담는 식입니다. 인덱스마다 매핑을 둡니다. 매핑은 문서의 필드를 어떤 타입으로 저장하고 어떻게 색인할지 정하는 스키마입니다.

인덱스 안에서 찾는 일은 역색인이 맡습니다. 역색인은 낱말마다 그 낱말이 든 문서의 목록을 적어 둔 자료구조입니다. 검색어가 들어오면 문서를 처음부터 훑지 않고 이 목록부터 봅니다. 찾은 문서에는 BM25(Best Matching 25) 순위 알고리즘으로 관련도 점수를 매깁니다. 결과는 점수가 높은 순서로 돌려줍니다.

OpenSearch 와는 HTTP(HyperText Transfer Protocol) 요청으로 주고받습니다. 이렇게 HTTP 요청으로 부르는 인터페이스를 REST(Representational State Transfer) API(Application Programming Interface)라고 합니다. OpenSearch 의 설정 대부분을 바꾸고, 인덱스를 고치고, 클러스터 상태를 확인하고, 통계를 보는 일을 이 API 로 합니다. curl 이든 어느 프로그래밍 언어든 HTTP 요청을 보낼 수 있으면 OpenSearch 를 쓸 수 있습니다.

클러스터와 노드와 샤드

노드는 데이터를 저장하고 검색 요청을 처리하는 서버 하나입니다. 노드를 모은 것이 클러스터입니다. 클러스터에는 선출된 클러스터 매니저 노드가 하나 있습니다. 인덱스를 만드는 것처럼 클러스터 전체에 걸린 일을 이 노드가 맡습니다.

요청은 어느 노드로 들어와도 됩니다. 요청을 받은 노드가 다른 노드들에 요청을 보냅니다. 그 응답을 모아 최종 응답을 돌려줍니다. 이렇게 요청을 받아 나누고 모으는 노드를 코디네이팅 노드라고 부릅니다.

OpenSearch 는 인덱스 하나를 샤드 여러 개로 쪼갭니다. 샤드는 인덱스의 문서 일부를 담는 조각입니다. 쪼개는 까닭은 인덱스 하나를 클러스터의 여러 노드에 나눠 놓기 위해서입니다. 샤드들은 그렇게 여러 노드에 흩어져 놓입니다.

샤드는 인덱스의 한 조각이지만 그 자체로 온전한 Lucene 인덱스입니다. Lucene 은 OpenSearch 가 색인과 검색에 쓰는 기반 라이브러리입니다. 샤드 하나가 곧 Lucene 인덱스 하나입니다.

Lucene 인덱스 하나하나는 CPU(Central Processing Unit)와 메모리를 쓰며 도는 실행 단위입니다. 샤드를 늘리면 나눠 놓을 곳은 늘어나지만 이 실행 단위도 같이 늘어납니다. 샤드 수를 늘린다고 꼭 이득이 아닌 까닭입니다. 400기가바이트 인덱스를 샤드 1,000개로 쪼개면 클러스터에 쓸데없는 부담을 줍니다. 대략적인 기준은 샤드 하나를 10~50기가바이트로 맞추는 것입니다.

샤드는 프라이머리 샤드와 레플리카 샤드로 나뉩니다. 프라이머리는 데이터의 원본입니다. 레플리카는 프라이머리의 복사본입니다. 기본 설정에서는 프라이머리마다 레플리카를 하나씩 만듭니다. 레플리카는 짝이 되는 프라이머리와 다른 노드에 놓습니다.

flowchart TD
    subgraph C["클러스터"]
        subgraph N1["노드 1"]
            P0["샤드 0 · 프라이머리"]
            R1["샤드 1 · 레플리카"]
        end
        subgraph N2["노드 2"]
            P1["샤드 1 · 프라이머리"]
            R0["샤드 0 · 레플리카"]
        end
    end
    P0 -.->|복사| R0
    P1 -.->|복사| R1

인덱스 하나를 샤드 둘로 쪼개고 레플리카를 하나씩 둔 모양입니다. 노드 1 이 죽어도 샤드 0 의 복사본이 노드 2 에 남습니다. 레플리카는 이렇게 노드 장애 때의 예비본 노릇을 합니다. 클러스터가 검색 요청을 처리하는 속도도 올립니다.

라이선스와 관리 주체

OpenSearch 프로젝트의 소프트웨어는 전부 Apache License 2.0 으로 풀려 있습니다. 이 라이선스로는 OpenSearch 를 쓰고, 고치고, 확장하고, 자기 제품에 넣고, 돈을 받고 되팔고, 자기 서비스의 일부로 제공할 수 있습니다.

OpenSearch 안에는 Apache 라이선스로 풀렸던 Elasticsearch 코드가 들어 있습니다. 코드는 물려받았어도 이름은 따로입니다. Elasticsearch 라는 이름은 Elasticsearch 를 만드는 회사 Elastic 의 등록 상표입니다. OpenSearch 라는 이름은 리눅스 재단 아래 법인인 LF Projects, LLC 의 등록 상표입니다.

프로젝트는 2021년에 만들어져 처음에는 AWS(Amazon Web Services)가 맡았습니다. 2024년 9월에 AWS 가 OpenSearch 를 리눅스 재단으로 넘겼습니다. 지금은 리눅스 재단 아래의 OpenSearch Software Foundation 이 프로젝트를 뒷받침합니다. 이 재단은 기반 시설과 자원을 댑니다. 기술 방향에는 관여하지 않습니다. 기술 방향은 기술 운영 위원회가 감독합니다.

배경

Elasticsearch 와 그 화면 도구인 Kibana 는 원래 Apache License 2.0 으로 풀려 있었습니다. 누구나 받아서 남에게 서비스로 제공할 수 있었습니다. Elastic 은 클라우드 사업자들이 이 소프트웨어를 서비스로 팔면서 되돌려 기여하지 않는다고 보았습니다.

그래서 7.11 버전부터 라이선스를 SSPL(Server Side Public License)과 Elastic License 가운데 하나를 고르는 이중 라이선스로 바꿨습니다. SSPL 은 소스를 볼 수 있게 공개하는 라이선스입니다. 이 소프트웨어를 서비스로 제공하면 고친 부분과 그 서비스를 관리하는 코드까지 SSPL 로 공개해야 합니다. Elastic License 는 쓰는 방식 자체를 제한합니다.

바뀐 조건을 받아들일 수 없는 쪽에는 예전 조건으로 쓸 수 있는 버전이 필요했습니다. Elasticsearch 를 관리형 서비스로 팔던 AWS 가 그런 경우였습니다. 관리형 서비스는 남이 만든 소프트웨어를 대신 띄우고 돌봐 주면서 사용료를 받는 서비스입니다.

AWS 와 OpenSearch 프로젝트는 SSPL 과 Elastic License 를 오픈소스 라이선스가 아니라고 보았습니다. 그래서 Apache 2.0 으로 나온 마지막 버전인 Elasticsearch 7.10.2 와 Kibana 7.10.2 를 포크했습니다. 그 결과가 OpenSearch 와 OpenSearch Dashboards 입니다. 둘 다 Apache 2.0 으로 이어 갑니다.

갈라진 뒤 Elastic 의 조건이 한 번 더 바뀌었습니다. 2024년 9월에 Elastic 은 AGPLv3(GNU Affero General Public License 버전 3)을 SSPL 과 Elastic License 옆에 세 번째 선택지로 더했습니다. AGPLv3 은 오픈소스 라이선스를 인증하는 단체인 OSI(Open Source Initiative)가 승인한 라이선스입니다.

여기서 소스 코드와 배포판이 갈립니다. 소스 코드는 저장소에서 받아 쓰는 코드입니다. 배포판은 Elastic 이 빌드해 내놓는 설치물입니다. 지금 Elasticsearch 저장소의 소스 코드는 기본으로 셋 가운데 하나를 골라 쓰게 되어 있습니다. Elastic 이 내는 배포판은 계속 Elastic License 로 나옵니다.

두 제품은 지금 이렇게 갈립니다. OpenSearch 는 소스도 배포판도 Apache License 2.0 하나입니다. Elasticsearch 는 소스를 받을 때 셋 가운데 고릅니다. Elastic 이 내는 배포판을 받을 때는 Elastic License 입니다.

flowchart TD
    A["Elasticsearch · Kibana 7.10.2 까지 · Apache 2.0"]
    A --> B["Elasticsearch · Kibana 7.11 부터 · SSPL 또는 Elastic License"]
    A --> C["OpenSearch · OpenSearch Dashboards · Apache 2.0"]
    B --> D["2024년 · AGPLv3 을 선택지로 더함"]

포크 시점의 갈림과 2024년에 더해진 선택지가 함께 보입니다.

포기한 것

OpenSearch 가 안 하기로 한 것은 갈래가 둘입니다. 하나는 포크한 뒤에 정한 것으로, 갈라진 Elasticsearch 를 따라가지 않기로 한 결정입니다. 나머지 셋은 색인과 검색을 하는 방식에서 따라오는 제약입니다.

갈라진 뒤의 Elasticsearch 와 맞추기

포크 직후의 OpenSearch 1.x 는 갈라지기 전까지의 Elasticsearch 와 맞췄습니다. Elasticsearch 와 Kibana 에는 Apache 2.0 으로 나오던 OSS(Open Source Software) 배포판이 있었습니다. 맞추는 상대는 그 배포판이었습니다. 범위는 이렇습니다.

이 범위는 모두 OpenSearch 1.0 과 1.x 때의 것입니다. 지금 버전에서도 같은지는 자료에 없습니다(미확인). 그때도 클라이언트나 도구 안에 버전 번호를 확인하는 코드가 있으면 OpenSearch 에서 안 돌 수 있었습니다.

갈라진 뒤의 Elasticsearch 와는 맞추지 않습니다. OpenSearch 의 로드맵은 Elasticsearch 와 따로 봐야 합니다. 로드맵은 커뮤니티가 필요로 하는 것을 따라 정합니다. 새 기능이 Elasticsearch 의 기능과 비슷하면 할 수 있는 한 API 를 비슷하게 만들려고 합니다. 그래도 두 프로젝트는 별개입니다.

넣자마자 검색되기

문서를 넣는 요청은 문서를 트랜스로그에 적고 그 트랜스로그를 디스크에 기록한 뒤에 응답합니다. 트랜스로그는 들어온 쓰기를 차례로 적어 두는 기록입니다. 응답을 받은 쓰기는 잃지 않습니다. 하지만 이 문서는 리프레시를 거치기 전까지 검색에 안 보입니다.

리프레시는 메모리에 덧붙여 쌓아 둔 데이터를 정렬된 검색용 구조로 바꿔 세그먼트 파일로 쓰는 일입니다. 세그먼트는 샤드 안에서 데이터를 담는 단위입니다. 한 번 쓰면 고치지 않습니다. 넣은 문서는 트랜스로그에 적히는 것과 함께 이 메모리 구조에도 쌓입니다. 리프레시가 그것을 세그먼트 파일로 옮겨야 검색에 보입니다.

sequenceDiagram
    participant C as 클라이언트
    participant S as 샤드
    participant T as 트랜스로그
    participant G as 세그먼트
    C->>S: 문서 넣기
    S->>T: 적고 디스크에 기록한다
    S-->>C: 응답
    Note over S: 아직 검색에 안 보인다
    Note over S,G: 기본 1초마다 리프레시
    S->>G: 검색용 구조로 쓴다
    Note over G: 이제 검색된다

쓰기를 잃지 않게 되는 때와 검색에 보이는 때가 이렇게 갈립니다.

OpenSearch 는 리프레시를 문서마다 하지 않고 주기적으로 합니다. 주기는 index.refresh_interval 이 정합니다. 기본은 1초입니다. -1 로 두면 리프레시를 끕니다.

이 값을 직접 정했는지가 또 하나의 갈림입니다. 따로 정하지 않으면 한동안 검색 요청을 안 받은 샤드는 다음 검색 요청이 올 때까지 백그라운드 리프레시를 멈춥니다. 검색하지 않는 인덱스에 대량으로 넣을 때 빨라지게 하려는 동작입니다. 검색량과 상관없이 정해진 간격으로 리프레시하려면 index.refresh_interval 을 1s 로 직접 정합니다.

깊은 페이지로 넘기기

검색 결과를 from(몇 번째부터)과 size(몇 건) 로 넘기는 방식은 1만 건까지만 됩니다. 결과 깊숙한 페이지를 조회하면 성능에 큰 영향을 줄 수 있어서 이렇게 막아 둡니다. 상한은 index.max_result_window 이고 기본값은 10000 입니다. 이 방식은 상태를 들고 있지 않아서, 넘기는 사이에 데이터가 바뀌면 페이지가 어긋날 수 있습니다.

1만 건 너머로 가는 길은 셋입니다. 둘째에 나오는 검색 문맥은 결과를 이어서 돌려주려고 서버가 열어 두는 상태입니다. 셋째에 나오는 PIT(Point in Time)는 어느 한 시점의 데이터를 얼려 둔 것입니다.

데이터가 든 필드의 타입 바꾸기

색인된 데이터가 이미 든 필드는 매핑이나 타입을 바꿀 수 없습니다. 바꾸면 앞서 색인한 데이터가 새 매핑과 안 맞을 위험이 있기 때문입니다. 필드를 매핑에서 빼는 것과 프라이머리 샤드 수를 바꾸는 것도 인덱스를 다시 짓지 않고는 못 합니다.

대신 새 필드를 더하는 것은 인덱스를 처음부터 다시 만들지 않고 됩니다. 없는 인덱스에 문서를 넣으면 인덱스가 생깁니다. 필드마다 타입은 넣은 값을 보고 짐작해 정합니다. 그래서 필드를 정의하지 않고도 데이터를 넣기 시작할 수 있습니다. 타입을 직접 정하고 싶으면 인덱스를 만들 때 매핑을 함께 줍니다.

타입을 바꿔야 하면 원하는 매핑으로 새 인덱스를 만들고 재색인합니다. 재색인은 원래 인덱스의 문서를 새 인덱스로 복사하는 일입니다. 큰 인덱스를 재색인하면 디스크 입출력이 많이 들고 클러스터의 검색이 느려질 수 있습니다.

옮기는 동안 서비스가 멈추지 않게 하는 데는 별칭을 쓸 수 있습니다. 별칭은 인덱스에 붙이는 또 하나의 이름입니다. 애플리케이션이 인덱스 이름 대신 별칭을 부르게 해 두면, 다 옮긴 뒤 별칭이 가리키는 인덱스만 바꿔 끼우면 됩니다. 부르는 쪽 코드는 고치지 않습니다.

문서 하나를 고칠 때도 같은 원리가 걸립니다. 저장된 문서는 고쳐 쓰지 않습니다. 고치면 OpenSearch 가 지금 문서를 꺼내 바뀐 내용을 얹습니다. 그 결과를 새 버전으로 색인합니다.

예시

학생 문서 하나를 넣고 찾기

아래는 students 인덱스에 학생 문서 하나를 넣는 요청입니다. 문서 ID 는 1 입니다.

PUT /students/_doc/1
{
  "name": "John Doe",
  "gpa": 3.89,
  "grad_year": 2022
}

students 인덱스가 아직 없으면 이 요청이 인덱스를 만들고 문서를 담습니다. 필드 타입은 넣은 값을 보고 짐작해 정합니다. ID 를 안 주면 OpenSearch 가 ID 를 만들어 붙입니다.

이제 이름에 john 이 든 학생을 찾습니다.

GET /students/_search
{
  "query": {
    "match": {
      "name": "john"
    }
  }
}

돌아오는 응답입니다.

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.44583148,
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_score": 0.44583148,
        "_source": {
          "name": "John Doe",
          "gpa": 3.89,
          "grad_year": 2022
        }
      }
    ]
  }
}

took 은 질의에 걸린 시간입니다. 단위는 밀리초입니다. hits.total.value 는 맞은 문서의 수입니다. hits.hits 배열에 그 문서들이 담깁니다. 문서마다 _index 와 _id 가 붙습니다. _source 에는 처음 넣은 문서가 전부 들어 있습니다. _score 는 이 문서의 관련도 점수입니다.

검색어는 소문자 john 입니다. 필드의 값은 John Doe 입니다. 대소문자가 달라도 문서가 찾아졌습니다.

Amazon OpenSearch Service

Amazon OpenSearch Service 는 AWS 클라우드에서 OpenSearch 클러스터를 띄우고 굴리고 늘리는 일을 대신 해 주는 관리형 서비스입니다. 이 서비스에서는 클러스터를 도메인이라고 부릅니다. 설정·인스턴스 종류·인스턴스 수·저장 공간을 정하면 그만큼의 자원을 마련해 클러스터를 띄웁니다. 실패한 노드를 스스로 찾아 바꿔 끼우기도 합니다.

도메인을 만들 때 검색 엔진을 고릅니다. OpenSearch 와 함께 옛 Elasticsearch OSS 도 고를 수 있습니다. 고를 수 있는 Elasticsearch OSS 는 마지막 오픈소스 버전인 7.10 까지입니다.

이 서비스는 인프라를 손수 관리하고 감시하고 유지하고 싶지 않을 때 고르는 선택지의 하나입니다. 포크를 알릴 때 AWS 는 자사의 Elasticsearch 관리형 서비스를 앞으로 새 포크로 돌리겠다고 했습니다. 쓰는 쪽이 클라이언트나 애플리케이션 코드를 고칠 필요가 없게 호환을 지키겠다고도 했습니다. 그 Elasticsearch 관리형 서비스가 이름을 바꿔 지금의 Amazon OpenSearch Service 가 된 것인지는 자료에 없습니다(미확인).

맞물림

OpenSearch 프로젝트는 검색 서버 하나만 내놓지 않습니다. 화면 도구, 데이터 수집기, 동봉 플러그인, 언어별 클라이언트가 함께 나옵니다. 모두 Apache 2.0 입니다. 이들은 OpenSearch 에 붙도록 만들어졌습니다. 붙는 방향도 정해져 있습니다.

flowchart TD
    DP["Data Prepper · 받아서 다듬는다"]
    DB["OpenSearch Dashboards · 5601"]
    CL["언어별 클라이언트"]
    subgraph OS["OpenSearch · 9200"]
        CORE["색인과 검색"]
        PL["동봉 플러그인 · 보안 등"]
    end
    DP -->|"opensearch sink 로 넣는다"| OS
    DB -->|"REST API 로 묻는다"| OS
    CL -->|"REST API 로 부른다"| OS

Dashboards · Data Prepper · 클라이언트 셋은 밖에서 OpenSearch 를 부릅니다. 플러그인은 OpenSearch 안에서 돕니다. 그림의 9200 은 OpenSearch 가, 5601 은 Dashboards 가 쓰는 기본 포트입니다.

OpenSearch Dashboards

OpenSearch Dashboards 는 OpenSearch 의 웹 화면입니다. OpenSearch API 로 하는 일 대부분을 이 화면에서 할 수 있습니다. 시각화와 대시보드를 만드는 일도 여기서 합니다.

Dashboards 는 OpenSearch 에 요청을 보내는 쪽입니다. 띄울 때 OPENSEARCH_HOSTS 환경 변수로 붙을 OpenSearch 의 주소를 줍니다. Docker 로 둘을 띄우는 기본 예에서는 OpenSearch 가 9200 포트에, Dashboards 가 5601 포트에 뜹니다. Dashboards 안의 Dev Tools 콘솔에서는 HTTP 요청을 손으로 써서 OpenSearch 로 보낼 수 있습니다.

Elasticsearch 의 화면 도구인 Kibana 는 OpenSearch 1.0 위에서 돌지 않습니다. OpenSearch 로 옮기면 화면 도구도 Dashboards 로 바꿔야 합니다.

Data Prepper

Data Prepper 는 서버 쪽에서 도는 데이터 수집기입니다. 들어온 데이터를 거르고, 보강하고, 바꾸고, 형식을 맞추고, 묶어서 분석과 시각화로 넘깁니다. OpenSearch 에 데이터를 넣는 도구로 권하는 것이 Data Prepper 입니다.

Data Prepper 는 파이프라인 단위로 돕니다. 파이프라인 하나는 소스 하나와 싱크 하나 이상으로 이루어집니다. 소스는 데이터를 받는 입구입니다. 싱크는 내보내는 출구입니다.

소스와 싱크 사이에는 버퍼 하나와 프로세서 여럿을 넣을 수 있습니다. 버퍼는 받은 데이터를 잠시 담아 두는 곳입니다. 프로세서는 데이터를 거르고 바꾸는 단계입니다.

OpenSearch 로 보내는 출구가 opensearch 싱크입니다. 이 싱크는 OpenSearch 클러스터, 옛 Elasticsearch 클러스터, Amazon OpenSearch Service 도메인 가운데 하나로 데이터를 보냅니다.

Elasticsearch 와 함께 쓰던 수집 도구 Logstash 와 Beats 는 포크하지 않았습니다. 그 둘은 OpenSearch 와 맞는 버전이 따로 정해져 있습니다.

동봉 플러그인

플러그인은 OpenSearch 의 핵심 위에 기능을 더하는 부품입니다. 최소 배포판은 색인과 검색 같은 핵심 기능만 켭니다. 표준 배포판에는 플러그인이 여럿 함께 들어 있습니다. 경보(Alerting), 이상 탐지(Anomaly Detection), 인덱스 관리(Index Management), 알림(Notifications), 보안(Security), SQL(Structured Query Language) 질의 같은 것들입니다. opensearch-plugin 명령으로 플러그인을 더하거나 뺍니다.

보안 플러그인은 네 가지를 맡습니다. 전송 중인 데이터의 암호화, 사용자 인증, 접근 제어, 감사 로그입니다. 접근 제어는 역할마다 권한을 클러스터 단위뿐 아니라 인덱스·문서·필드 단위까지 나눠 줄 수 있습니다.

Elasticsearch 용으로 만든 플러그인은 그대로 끼울 수 없습니다. OpenSearch 는 이름공간과 클래스 이름을 바꿨습니다. Elasticsearch 의 JAR(Java ARchive) 파일에 기대는 플러그인은 OpenSearch 의 JAR 에 기대도록 코드를 고쳐야 돕니다.

언어별 클라이언트

OpenSearch 는 자바스크립트·파이썬·루비·자바·Go·러스트 등 여러 언어의 클라이언트를 냅니다. 클라이언트는 애플리케이션 안에서 OpenSearch 의 REST API 를 부르는 라이브러리입니다.

Elasticsearch OSS 7.10.2 와 맞던 클라이언트는 OpenSearch 1.x 와 돌 것으로 봅니다. 다만 그 클라이언트들의 최신 버전에는 라이선스나 버전 번호를 확인해 일부러 호환을 끊는 코드가 들어 있을 수 있습니다. OpenSearch 2.0 부터는 완전히 맞는 Elasticsearch 클라이언트가 없습니다.

클라이언트와 서버를 섞어 쓰면 오류나 예상 밖의 결과가 날 위험이 큽니다. 두 제품이 계속 갈라질수록 이 위험이 커질 수 있습니다. OpenSearch 클러스터에는 OpenSearch 클라이언트를 쓰기를 권합니다.

관련 항목

OpenSearch 가 갈라져 나온 뿌리

Elasticsearch · Kibana · 포크 · 업스트림 · Open Distro for Elasticsearch · Elasticsearch OSS

OpenSearch 와 Elasticsearch 를 쓸 조건을 정하는 라이선스

라이선스 · 오픈소스 · 오픈소스 라이선스 · Apache License 2.0 · SSPL · Elastic License · AGPL · OSI

OpenSearch 프로젝트를 맡는 단체

OpenSearch Software Foundation · 리눅스 재단 · AWS · Elastic

OpenSearch 안에서 검색을 떠받치는 구조

Lucene · 역색인 · 전문 검색 · BM25 · 관련도 점수 · 분석기 · 세그먼트

OpenSearch 클러스터를 이루는 구성 요소

클러스터 · 노드 · 클러스터 매니저 노드 · 코디네이팅 노드 · 샤드 · 프라이머리 샤드 · 레플리카 샤드 · 인덱스

OpenSearch 에 쓴 문서가 검색되기까지 거치는 처리 단계

트랜스로그 · 리프레시 · 플러시 · 머지 · fsync

OpenSearch 인덱스의 모양을 정하고 바꾸는 수단

매핑 · 동적 매핑 · 재색인 · 인덱스 별칭 · 스키마

OpenSearch 검색 결과를 넘기는 방법

페이지네이션 · search_after · 스크롤 API · Point in Time · 커서

OpenSearch 에 붙도록 함께 나오는 프로젝트

OpenSearch Dashboards · Data Prepper · OpenSearch 플러그인 · OpenSearch 클라이언트

OpenSearch 에 데이터를 실어 나르는 수집 도구

Logstash · Beats · Fluent Bit · 로그 수집

OpenSearch 보안 플러그인이 맡는 기능

암호화 · 인증 · 접근 제어 · 세분화된 접근 제어 · 감사 로그

OpenSearch 에 보내는 요청과 질의

REST · API · HTTP · JSON · Query DSL · curl

OpenSearch 를 대신 띄워 주는 관리형 서비스

관리형 서비스 · Amazon OpenSearch Service · 클라우드 · 도메인

OpenSearch 와 같은 역할을 두고 겨루는 검색 엔진

Apache Solr · Meilisearch · Typesense · Algolia · Vespa