Elasticsearch

Elasticsearch 분산환경을 만들기 위한 설정파일 예시이다.상세 옵션 설명은 https://esbook.kimjmin.net/02-install/2.3-elasticsearch/2.3.2-elasticsearch.yml 참조

Linux 환경에서 elasticsearch를 설치하고 구동하는 법을 작성한다. ES 버전 7.9.2 기준https://velog.io/@mertyn88/ES-%EB%B6%84%EC%82%B0%ED%99%98%EA%B2%BD-%EC%84%A4%EC%A0%95%

ES 서버에 어떠한 스크립트가 적용되어 있는지, 또 그 스크립트는 어떤 코드로 작성되어 있는지 확인하고 싶을 때가 있다. 그때 확인하는 명령어는 다음과 같다

로컬에서 Docker를 통해 ES 환경을 구축해보자. 환경은 8.5.2이다. (현재 글을 작성하는 최신버전) 이전까지 테스트를 진행할때는, 직접 Elasticsearch와 Kibana의 이미지를 다운로드(Pull)하고, 두 이미지를 각각 띄울때 같은 네트워크로 연결하여

Elasticsearch의 기본적인 옵션에 대한 설명이다. 많이 다루어봤어도 실제 구동을 시키기 위한 옵션을 제대로 모르는것 같았다.설명은 옵션 주석으로 표시한다.

Git : https://github.com/mertyn88/vector-searchElasticsearch 8.5.2의 버전으로 벡터검색에 대한 예제이다. 버전차이의 문제와, 구글링을 통한 예제는 tensorflow를 사용하여 찾는 부분이 많았으며, 본 예제

이전 페이지에서 docker-compose를 통해 elasticsearch와 kibana 8.5.2버전을 설치하고 동작하는 실습을 하였다. Docker - ES, Kibana이번에는 ELK중 나머지 Logstash도 연동하고 curl을 통해서 실제 색인까지 해보도록 한

1:N관계인 Elaticsearch의 REST -> 메소드와 URL을 조합하여, 예측 가능하고 일정한 정보와 작업을 요청하는것=> 버튼마다 나오는것이 확실한 자판기처럼질의식이 들어왔을 때, 검색 속도가 오래 걸리는 이유는물리적 관계처럼 구성이 되어 있기 때문에, 부모의

역색인 구조를 사용하면 검색어를 고유한 정렬된 키워드 목록에서 검색할 수 있으며, 검색어를 목록에 즉시 접근할 수 있다.dov_values는 문서 색인 단계에서 작성된 디스크 상의 데이터 구조 이며, 이를 통해 데이터 접근 패턴을 사용할 수 있다. \_source와 동

기본적으로 필드 값은 검색 가능하도록 색인 되지만, 저장되지는 않는다.특정 상황에서는 필드를 저장하는 것이 합리적일 수 있다. 매우 큰 내용 필드를 가진 문서가 있는 경우, \_source 필드에서 원하는 필드를 추출하지 않고 store_field로 지정된 필드만 검색

\_source필드에는 색인 단계에서 전달된 원본 JSON 문서 본문이 포함되어 있다. \_source 필드 자체는 색인되지 않으므로 검색할 수는 없지만 get 또는 search와 같은 fetch요청을 실행할 때, 반환될 수 있도록 저장된다.검색 결과로 나온 원래의 J

자동완성 서비스를 구축하다가 이론적으로만 알고 있지만 실제로 발생한 이슈케이스에 대해 공유하고자 한다. Elasticsearch에서 analyzer를 설정할 때는, 다음과 같은 단계를 거치게 된다.실질적인 분석이 시작되기 전에 수행되어지는 전처리 단계로서, 특정 문자를

Elasticsearch에서 문장을 분석할 때, Token이 분리되는 시점에 따른 결과의 차이를 알아보자.해당 글은 자동완성 서비스를 구축하던 중에, Highlighting옵션이 원하는대로 표현되질 않아서 따로 예제를 정리한다.결론부터 말하자면, tokenizer에서

원문 글현재 운영중에 발생한 적은 없지만, ES를 운영하면서 알아야하는 이슈이므로 따로 정리한다. 원문 글이 더욱 자세하고 좋게 글이 작성되어 있고, 실제 내부에서 테스트할 여건이 안되므로 이 블로그에는 간략하게만 작성하도록 한다.Thread Pool은 ES의 주요 기

Elasticsearch plugin 형태로 ingest를 구성하게 되면, 운영중인 서비스를 계속 배포 및 재시작의 과정이 필요하다. 재배포의 과정을 없에기 위해 ES에서 제공하는 Script(Painless)를 직접 작성하여 처리하는 방안을 작성한다.Painless

검색서비스를 운영 중에, 다음과 같은 시나리오 케이스가 존재 하였고 검색이 이루어지지 않는 이슈가 발생하였다. 그 이슈 시나리오는 다음과 같다. 푸켓의 동의어가 뿌켓으로 운영 중이다푸켓의 동의어로 푸켕을 추가하였다사전 배포와 재색인이 수행되었다푸켓이라는 단어로 검색이

ES를 통해서 Nori로 형태소분석을 진행하여 NNP(고유명사), NNG(일반명사)를 제외한 모든 품사태그를 stoptags에 넣어 단어의 토큰을 빼오도록 하고 싶었다. 그런데 이때, 동의어를 확장해서 가지고 오려고 했을때 이슈케이스를 작성한다.PUT tempResul

Elasticsearch를 구성하고 나서, 네트워크 부하가 심하거나 특정 이유로 서버를 증설해야하는 경우가 존재한다. 이때, IDC든, 클라우드든 다음과 같은 방식으로 증설을 할 것이다.Docker image 빌드 방식운영 중인 Elasticsearch Binary를

운영을 하면서 실시간으로 색인이 되는 로그 클러스터에서 테스트를 진행하고 있었다. 그런데 테스트케이스의 도큐먼트를 상단에 노출해서 보려고 현재시간을 미래의 시간으로 지정하여 테스트를 진행했다.물론 테스트는 정상, 하지만 이제 테스트가 완료되고 실제 데이터를 봐야하는데

샤드의 데이터들을 가지고 있는 물리적인 파일을 의미하나의 인덱스는 다수의 샤드로 구성되고 하나의 샤드는 다수의 세그먼트로 구성인덱스에 저장되는 문서는 해시 알고리즘에 의해서 샤드들에 분산 저장되고 이 문서들은 셀제로는 세그먼트라는 물리적 파일에 저장된다.하지만 문서가

Elasticsearch를 설치하여 사용할때, jvm.options에 대해서는 제대로 설정한 적이 없어서 특정 옵션들에 대해 적는다.CMS라는 GC 방식을 사용한다는 설정. Elasticsearch가 기본으로 사용하는 GC 방식이며, 대부분의 경우 좋은 성능을 내기 때

Elasticsearch를 설정할 때, 공식문서에 보면 다음과 같은 권고 사항이 존재한다.32GB를 넘지 않게 설정할 것전체 메모리의 절반 정도를 힙 메모리로 설정할 것왜 이러한 설정이 필요하게 된 것인지 알아보자JVM은 연산을 위한 데이터들을 저장하기 위한 공간으로

운영중인 인덱스를 가져와서 로컬에서 테스트를 하는 경우가 있다. 그럴때 다른 인덱스를 조회하는 쿼리를 실행해서 파일로 저장하고,다시 그 파일을 읽어서 색인하는 방식을 생각할 수 있다. ( 본인이 그랬음... )원래 reindex 기능이 있는건 알고 있었지만 사용하질 않

해당 기능에 대한 문서를 살펴보면, 모두가 이렇게 적혀있다. tokenizer의 전단계로써, 문자열에 대한 전처리를 처리한다나는 그래서 이렇게 해석했다. char_filter 단계에서 전처리를 진행하고, 정제된 데이터 상태에서 색인한다.즉, 실제 색인할때는 변경이나 삭

우리가 Elasticsearch의 플러그인은 만들 수 있어도 실제 ES의 코드를 수정하고 배포할 일은 없으리라 생각이 든다. 하지만 그래도 기본적으로 ES를 코드로써 구동시킬 줄 알아야 한다는 생각이 들었다.이번에는 Intellij에서 ES를 Debug로 구동하고, N

업로드중..

최장일치법은 한 어절 내에서 분절이 가능한 여러 형태소 중에서 가장 긴 형태소를 선택하는 방법. 이 방법은 일반적으로 한국어 형태소 분석에서 사용되며, 주어진 문장을 형태소 단위로 분리할 때 가장 일반적인 방식 중 하나.최장일치법은 주어진 텍스트에서 연속된 글자들을 형

Elasticsearch를 운영하면서 검색 속도를 높일 수 있는 방안에 대해 찾아보았다.\[HowTo] 검색 속도 튜닝 : 네이버 블로그 (naver.com)해당 글이 가장 보기 좋았고, 이 글에서 필요한 부분을 작성하고자 한다. Elasticsearch 클러스터를

상호 순위 융합 | Elasticsearch 가이드 \[8.10]\[NLP]. Reciprocal rank fusion (RRF) 이해하기관련성이 다른 여러 결과 집합을 결합하는 방식. 지표를 단일 결과 집합으로 변환. RRF는 튜닝이 필요하지 않으며 다른 관련성 지표

데이터의 수명 주기를 관리하고 정의하는 기능, 이를 사용하면 데이터를 적절한 시점에 생성, 업데이트, 삭제하고, 디스크 공간을 효과적으로 활용이 가능. 주로 로그 데이터와 같이 시간이 지남에 따라 더 이상 필요하지 않는 데이터를 자동으로 삭제하는 데 사용.Hot Pha

ES의 클러스터를 설계하기 위해 적정한 샤드의 개수와 노드의 개수를 선정하는 방법에 대해 정리한다.해당 방식은 당근페이 개발자 이신 - 강진우님의 블로거를 보고 그대로 정리한다\[클러스터 설계하기 - Elasticsearch의 검색은 1 쿼리(Query) 1 샤드(Sh

Kibana에서 Visualize를 통해서 시각화를 해야하는 경우, 특정 필드값을 연산하여 처리해야하는 경우가 있는데, 이때 시각화만을 위한 필드를 따로 색인할 수 없으므로 고민하던 순간, 자체적으로 Scripted fields를 Kibana용으로 처리하여 보여줄

타팀의 ES운영중에 검색시 다음과 같은 예외가 발생한다고 문의가 왔다.구글링시에 대부분 특정 인덱스에 문제가 발생했으니 해당 인덱스를 찾으라고 한다. 이때 찾는법은 status가 red인 인덱스를 지우면 된다고 한다. GET \_cluster/health?level=

Elasticsearch를 다루면서 대략적인 이론만 알고 있다보니, 어느순간 refresh와 flush를 같은 역할을 하는 기능으로 인지하고 있었다. 시나리오 예제를 통해 명확히 두 기능에 대한 차이를 설명하고자 한다. 다음과 같은 시나리오대로 테스트를 진행해보자.

서비스를 운영 중에, 특정 상황에 대해서 검색이 안되는 이슈가 발생했고, 해당 상황을 조사하는 내용을 정리하고자 한다.검색어는 에어텔이며 에어텔이 포함된 몇몇 문서가 검색이 되질 않았다.사용자사전 미등록 상태에어텔이 포함된 모든 문서가 노출이 안되거나, 모두 노출이 되

서비스를 운영 중에, 갑자기 모든 검색이 불가능한 이슈가 발생했고, 해당 상황을 조사하는 내용을 정리하고자 한다. 검색 서비스 불가 현상 확인Kibana 접근 불가 확인 \* 라이센스 만료 오류 ( license is not available )Elasticsearc

Elasticsearch에서는 한번 생성된 Primary Shards의 개수는 변경이 불가능(Replica Shards는 가능) Shards 독립적이고 Master Node에 의해서 세그먼트가 분배Primary Shards의 개수를 변경하면 기존의 모든 데이터를 재