Elasticsearch 란?

본 문서는 공식 홈페이지 를 보며 정리한 문서이다.

 

Elasticsearch는 Elastic Stack의 중심에서 분산 검색 및 분석을 담당하는 엔진이다. Logstash와 Beats는 데이터를 수집, 집계하고 Elastcsearch에 저장하는 것을 용이하게 한다. Kibana를 사용하면 데이터를 탐색, 시각화 및 공유하고 스택을 관리 및 모니터링 가능하다.

 

Elastcsearch는 모든 유형의 데이터에 대해 거의 실시간 검색 및 분석을 제공한다. 구조화되었거나 구조화되지 않은 텍스트, 숫자 데이터 또는 지리 공간 데이터가 있든 관계없이 빠른 검색을 지원하는 방식으로 효율적으로 저장하고 색인을 생성할 수 있다. 단순한 데이터 검색 및 집계 정보를 뛰어 넘어 데이터의 추세와 패턴을 찾아낼 수도 있으며, 데이터 및 쿼리 볼륨이 증가함에 따라 Elasticsearch의 분산 특성으로 인해 배포가 원활하게 확장 될 수도 있다.

 

특징으로는 다음과 같다.

• 앱 또는 웹 사이트에 검색 창
• 로그, 지표 및 보안 이벤트 데이터 저장 및 분석
• 머신러닝을 사용해 데이터 동작을 실시간으로 자동 모델링
• Elasticsearch를 스토리지 엔진으로 사용하여 비즈니스 워크플로우 자동화
• 지리 정보 시스템(GIS)으로 사용하여 공간 정보를 관리, 통합 및 분석
• 생물 정보학 연구 도구로 사용하여 유전 데이터 저장 및 처리

데이터 : 문서(JSON) 및 색인(index)

Elasticsearch는 분산 문서 저장소이며, 데이터를 테이블 형식으로 저장하는 대신 JSON 문서로 비교적 복잡한 데이터 구조로 저장한다. 만약 클러스터에 여러 Elasticsearch 노드들이 있는 경우, 저장된 문서가 클러스터 전체에 분산되어 다시 저장된다.

 

문서(JSON)가 저장되면 인덱스(Index)가 생성되고 1초 이내에 거의 실시간으로 전체 검색이 가능하다. Elasticsearch는 역 인덱스(Inverted Index)라는 데이터 구조를 사용하여 빠른 전체 텍스트 검색이 가능하다. 역 인덱스는 문서에 나타나는 모든 고유 단어를 나열하고 각 단어가 나오는 모든 문서를 식별한다.

 

인덱스는 최적화 된 문서의 모음으로 생각될 수 있으며 각 문서는 데이터를 포함하는 키-값(key-value) 쌍인 필드의 모음이다. 기본적으로 Elasticsearch는 모든 필드의 모든 데이터를 인덱싱하고 각 인덱싱 된 필드에는 최적화 된 전용 데이터 구조가 존재한다.

 

예를 들어, 텍스트 필드는 반전 된 인덱스로 저장되고 숫자 및 필드는 BKD 트리라고 불리는 곳에 저장된다. 필드 별 데이터 구조를 사용하여 검색 결과를 조합하고 반환하므로 Elasticsearch가 매우 빠른 이유이다.

 

Elasticsearch에는 스키마가 없는(데이터 모델링 되지 않은) 기능도 존재한다. 문서에서 발생할 수 있는 각기 다른 필드를 처리하는 방법을 명시적으로 지정하지 않고도 문서를 인덱싱할 수 있다. 동적 매핑되면 자동으로 새 필드를 감지하고 인덱스를 생성한다. 이 동작을 통해 데이터를 쉽게 인덱싱하고 탐색 할 수 있다. 문서 인덱싱을 시작하면 Elasticsearch가 bool, 부동 소수점, 정수, 날짜, 문자열을 감지하고 적절한 데이터 유형에 매핑한다.

 

동적 매핑을 제어하는 규칙을 정의하고 명시 적으로 매핑을 정의하여 필드가 저장되고 인덱싱되는 방식을 완전히 제어 할 수 있다.

고유한 매핑을 정의하면 다음과 같다.

• 전체 텍스트 문자열 필드와 정확한 값 문자열 필드 구분
• 언어 별 텍스트 분석 수행
• 부분 일치를위한 필드 최적화
• 사용자 지정 날짜 형식 사용
• 자동으로 감지 할 수 없는 geo_point , geo_shape 와 같은 데이터는 데이터 유형을 사용

정보 출력 : 검색 및 분석

Elasticsearch를 문서 저장소로 사용하고 문서와 해당 메타 데이터를 검색 할 수 있지만, Apache Lucene 검색 엔진 라이브러리를 사용하여 전체 검색 기능에 쉽게 액세스 할 수 있다.

Elasticsearch는 클러스터를 관리하고 데이터를 인덱싱 및 검색하기위한 간단하고 일관된 REST API를 제공한다. 테스트 목적으로 명령 줄에서 직접 요청하거나 Kibana의 개발자 콘솔을 통해 쉽게 요청할 수 있다. 다양한 언어 (Java, JavaScript, Go, .NET, PHP, Perl, Python 또는 Ruby)로 Elasticsearch 클라이언트 를 사용할 수 있다 .

데이터 검색

Elasticsearch REST API는 구조화된 쿼리, 전체 텍스트 쿼리, 두 가지를 결합하는 복잡한 쿼리를 지원한다. 구조화된 쿼리는 SQL에서 생성 할 수있는 쿼리 유형과 유사하다.

예를 들어,

select gender, age
from person
group by employee
order by hire_date;

위 구문과 같이, 구조화된 쿼리는 색인에서 gender, age 필드를 검색 하고 필드 employee별로 일치 항목을 hire_date로 정렬 할 수 있다. 전체 텍스트 쿼리는 쿼리 문자열과 일치하는 모든 문서를 찾아 관련성 ( 검색어와 얼마나 일치하는지) 별로 정렬하여 반환한다 .

개별 용어를 검색하는 것 외에도 구문 검색, 유사성 검색 및 접두사 검색을 수행하고 자동 완성 제안을 받을 수 있다.

검색하고자 하는 데이터가 지리, 숫자 데이터일 경우, Elasticsear는 고성능 지리, 수치 쿼리를 지원하는 최적화된 데이터 구조에서 비 텍스트 데이터를 인색싱해 검색한다.

Elasticsearch는 JSON스타일 쿼리언어(Query DSL)을 사용하여 모든 검색 기능에 엑세스 할 수 있다. 또 SQL 스타일 쿼리를 구성해 Elasticsearch내 기본적으로 데이터를 검색하고 집계할 수 있어 JDBC, ODBC 드라이버를 사용하면 SQL을 통해 검색 가능하다.

데이터 분석

Elasticsearch의 집계(Aggregation)는 검색에 사용되는 것과 동일한 데이터 구조를 활용하므로 빠르다. 이를 통해 실시간으로 데이터를 분석하고 시각화 할 수 있다.

집계는 검색 요청과 함계 동작한다. 단일 요청으로 동일한 데이터에 대해 문서를 검색하고 결과를 필터링하며 동시에 분석을 수행할 수 있다.

확장성, 복원성 (클러스터, 노드, 샤드)

Elasticsearch는 항상 사용 가능하고 필요에 따라 확장 할 수 있도록 구축되었다. 용량을 늘리기 위해 클러스터에 서버 (노드)를 추가 할 수 있으며 Elasticsearch는 사용 가능한 모든 노드에 데이터와 쿼리로드를 자동으로 분산합니다. Elasticsearch는 확장성과 고가용성을 제공하기 위해 다중 노드 클러스터의 균형을 맞춘다.

 

내부적으로 Elasticsearch 인덱스는 실제로 하나 이상의 물리적 샤드의 논리적 그룹이며 각 샤드는 실제로 자체 포함 된 인덱스이다. 인덱스의 문서를 여러 샤드에 분산하고 이러한 샤드를 여러 노드에 분산함으로써 Elasticsearch는 중복성을 보장 할 수 있다. 이 두 가지 모두 하드웨어 장애로부터 보호하고 노드가 클러스터에 추가 될 때 쿼리 용량을 증가시킨다. 클러스터가 확장 (또는 축소)되면 Elasticsearch는 자동으로 샤드를 마이그레이션하여 클러스터를 재조정한다.

 

샤드에는 기본 및 복제본의 두 가지 유형이 있다. 인덱스의 각 문서는 하나의 기본 샤드에 속한다. 복제본 샤드는 기본 샤드의 복사본이다. 복제본은 데이터의 중복을 제공하여 하드웨어 오류로부터 보호하고 문서 검색 또는 검색과 같은 읽기 요청을 처리하는 용량을 증가시킨다.

인덱스의 기본 샤드 수는 인덱스가 생성 될 때 고정되지만 복제본 샤드 수는 인덱싱 또는 쿼리 작업을 중단하지 않고 언제든지 변경할 수 있다.

 

샤드 크기, 인덱스에 대해 구성된 기본 샤드 수와 관련하여 여러 가지 성능 고려 사항이 있다. 샤드가 많을수록 해당 인덱스를 유지하는 데 더 많은 오버 헤드가 발생한다. 샤드 크기가 클수록 Elasticsearch가 클러스터를 재조정해야 할 때 샤드를 이동하는 데 더 오래 걸린다.

작은 샤드를 많이 쿼리하면 샤드 당 처리 속도가 빨라지지만 쿼리가 많을수록 오버 헤드가 증가하므로 더 적은 수의 큰 샤드를 쿼리하는 것이 더 빠를 수 있다.

• 평균 샤드 크기를 몇 GB에서 수십 GB 사이로 유지하는 것을 목표로 한다. 시간 기반 데이터가있는 사용 사례의 경우 20GB ~ 40GB 범위의 샤드를 보는 것이 일반적이다.
• 무수히 많은 샤드를 피해야 한다. 노드가 보유 할 수있는 샤드 수는 사용 가능한 힙 공간에 비례한다. 일반적으로 힙 공간 GB 당 샤드 수는 20 개 미만이어야 한다.

사용 사례에 대한 최적의 구성을 결정하는 가장 좋은 방법은 자체 데이터 및 쿼리로 테스트하는 것 이다. 성능상의 이유로 클러스터 내의 노드는 동일한 네트워크에 있어야 한다. 그렇지 않으면 여러 데이터 센터의 노드간에 클러스터의 샤드 균형을 맞추는 데 너무 오래 걸릴수 있다. 그러나 고 가용성 아키텍처에서는 모든 노드를 한 네트워크에 묶지 않아야 한다. 한 위치에서 중단이 발생하는 경우 다른 위치에있는 서버가 대신 원활하게 동작할 수 있어야 한다. 이를 CCR (클러스터 간 복제)을 통해 해결한다.

 

CCR은 기본 클러스터의 인덱스를 핫 백업으로 사용할 수있는 보조 원격 클러스터로 자동으로 동기화하는 방법을 제공한다. 기본 클러스터가 실패하면 보조 클러스터가 동작한다. CCR을 사용하여 보조 클러스터를 생성하여 사용자에게 읽기 요청을 제공 할 수도 있다.

 

클러스터 간 복제는 활성-수동 이다. 기본 클러스터의 인덱스는 활성 리더 인덱스이며 모든 쓰기 요청을 처리한다. 보조 클러스터에 복제 된 인덱스는 읽기 전용 이다.

모든 엔터프라이즈 시스템과 마찬가지로 Elasticsearch 클러스터를 보호, 관리 및 모니터링하기위한 도구가 필요하다. Elasticsearch에 통합 된 보안, 모니터링 및 관리 기능을 통해 Kibana 를 클러스터 관리를 위한 제어 센터로 사용할 수 있다 . 데이터 롤업 및 인덱스 수명주기 관리 와 같은 기능을 사용 하면 시간이 지남에 따라 데이터를 관리 할 수 있다.