elasticsearch_적용 및 활용_정리

적용 및 활용

로엔엔터테인먼트

플랫폼개발팀

2015.03.17송준이([email protected])

mailto:[email protected]

목차

• 개요

– about elasticsearch

• 개요

• 설치

• Marvel 설치하기

• 실행 및 종료

– elasticsearch 맛보기

• 사례 : We love our drones!

• indexing

• retrieving

• searching

– basics

– filtered search

– full-text search

– phrase search

– highlight

• 동시성 제어 : optimistic concurrency control

• 부분 업데이트(partial update)

• avoiding network overhead

목차

• distributed nature

– life inside a cluster

– distributed document store

– distributed search execution

– inside a shard

목차

• aggregation

– aggregation 맛보기

• 개요

• buckets & metrics

• 사례 : car transaction

• 기본 문법

• nested buckets

• bucket 유형

• metric 유형

• visualization : bar chart 1

• visualization : bar chart 2

• visualization : time series

• visualization : time series refined

• visualization : kibana dashboard

• scoping & filtering

– scope of aggregation

– scope of aggregation on filtered query

– filtered bucket

– post filter

– 정리

• sorting

목차

– aggregation : approximation

• real-time analytics on big data

– 한계

– ER(Exact – Real-time)

– EB(Exact – Big data)

– BR(Big data – Real-time)

• currently supported approximation

• cardinality

– when to use

– HLL algorithm

– precision 조절

– cardinality approximation 성능 향상을 위한 조언

• pecentiles

– when to use

– 사례 : 웹사이트 latency

» latency에 대한 percentiles 구하기

» zone별 latency에 대한 percentiles 구하기

» percentile ranks

– TDigest algorithm

– percentiles approximation 성능 향상을 위한 조언

목차

– aggregation : significant terms

• uncommonly common data

• 개요

– goal

– significant aggregation이란?

– 응용 분야

• 사례 : 영화 추천기

– 요구사항

– 사용할 전략 2가지

– 데이터 구조

– popularity를 기준으로 영화 추천하기

» 문제점

– statistic를 기준으로 영화 추천하기

» 추천이 예상되는 영화 목록

» significant terms aggregation

» 결과 분석

목차

• Query DSL & aggregation

– Search 101

– Query DSL 개요

– Query vs. Filter

– Query DSL vs. Aggregation DSL

목차

• partial matching

– structured search

– full-text search

– partial matching

– autocomplete

• Using Synonyms

– Using Synonyms

– Expand or Contract

목차

• discovery with zookeeper

– zen discovery

– zookeeper plugin

• performance case study

– Elasticsearch Refresh Interval vs. Indexing Performance

– Elasticsearch Performance Characteristics on Joyent and Amazon EC2

– indexing performance tips

– performance considerations for elasticsearch indexing

– 성능 향상을 위한 메모리 tip

– Check list 101

개요

about elasticsearch

개요

• 분산 환경의 문서 지향(distributed document-oriented)

– 데이터 저장소(data store)

• 수백 대의 서버로 scale out

• PB 급의 데이터 저장

• document(serialized JSON object) 기반 data structure

• partial document update 지원

– document는 근본적으로 수정이 불가능(immutable)

– update = replacement(internally)

– 검색 엔진(search engine)

• 루씬(lucene)을 내부 엔진으로 사용

• 모든 필드를 indexing하여 검색 가능

– 실시간 분석 플랫폼(real-time analytic platform)

• aggregation 지원

• approximate aggregation = (big data + real-time analysis) – precision

– 빅 데이터를 정확도를 낮춰서 실시간으로 분석

storing indexing

searching

analyzing

filtering ordering

aggregation

저장

검색

분석

개요

• 버전

– 문서 버전 : 1.4.0

– 설치 버전 : 1.4.2

• license : Apache 2

설치

• cluster 명 변경하기

– {$ELASTICSEARCH_HOME}/config/elasticsearch.yml 파일의 cluster.name 속성을변경

Marvel 설치하기

• Marvel

– management & monitoring tool for elasticsearch clusters

– 웹 UI에서 curl 명령 실행할 수 있는 Sense 도구 지원

– license

• 1000$ per year for first 5 nodes

• 250$ per year for 5 nodes

• 설치하기

실행 및 종료

• 실행하기

• 종료하기

elasticsearch 맛보기

사례 : We love our drones!

• Megacorp회사의 직원 데이터 관리하기

• 요구사항

– 데이터는 다수의 태그(tag), 숫자, full-text(전문)을 저장해야 한다

– 각 직원의 상세 정보를 조회(retrieve)할 수 있어야 한다

– structured search를 지원해야 한다

• 예) 30세 이상의 직원 목록 검색

– full-text search와 phrase search(구문 검색)을 지원해야 한다

– 검색된 문서에서 매칭된 부분(snippet)은 하이라이트(highlight) 해야 한다

– 데이터에 대한 분석 대시보드(analytic dashboard)를 만들 수 있어야 한다

indexing

• vs. RDBMS

• indexing employee document

– 직원에 대한 상세 정보를 각각의 document로 저장한다

– 각 document는 자신만의 ID를 가진다

– 각 document는 type이 employee다

– employee type은 megacorp index에 포함된다

RDBMS database table row column

elasticsearch index type document field

retrieving

• retrieving employee document

searching : basics

• 기본 문법

• string search

• query DSL search

select *from employeewhere last_name = “Smith”

sql 비교

searching : filtered search

• narrowing query target

select *from employeewhere age > 30and last_name = “Smith”

sql 비교

searching : full-text search

• sorting matched records according to relevance score

– relevance score에 따라 rock 또는 climbing을 각각 포함하거나, 아예 포함하지 않는결과도 검색될 수 있다

• indexing for full-text search

– full-text search를 지원하려면 indexing 단계에서 해당 필드를 analyze해야 한다

select *from employeewhere match(about) against(‘rock climbing’)

sql 비교

searching : phrase search

• exact match for phrase

– analyze한 필드에 대해 full-text search가 아니라, 구문 전체를 반드시 포함한document를 검색한다

select *from employeewhere match(about) against(‘”rock climbing”’ in boolean mode)

sql 비교

searching : highlight

• 검색시 매칭된 결과에서 매칭된 부분 하이라이트하기

동시성 제어 : Optimistic concurrency control

• 두 클라이언트에서 동시에 쓰기를 수행한다면

– Web-1에서 100을 읽는다

– Web-2에서 100을 읽는다

– Web-1에서 -1을 처리한 후, 99를 저장한다

– Web-2에서 -1을 처리한 후, 99를 저장한다

web-1의 처리 결과가 사라진다

• 동시성 충돌을 해결하기 위해

– elasticsearch는 version number를 사용

– version이 일치하지 않는 경우 명령은 실패

예) version을 이용한 조건적 document update

동시성 제어 : Optimistic concurrency control

• retry on conflict occurred

– 충돌 발생시, 해당 충돌을 retry해도 되는 상황(네트워크 일시 단절)이라면, 자동으로retry하여 충돌을 해결할 수 있다

부분 업데이트(partial update)

• update 기본 문법

• script 사용하기

– 기본값(params) 제공하기

부분 업데이트(partial update)

• 조건적 삭제

• upsert

avoiding network overhead

• 문서를 retrieving하거나 indexing할 때, 문서를 하나씩 주고받기 보다는대량의 문서를 한꺼번에 주고받음으로써 NIO를 줄일 수 있다

– mget for retrieving

– bulk for create / index / update / delete

• bulk size 정하기

– bulk 요청을 처리하려면 bulk 요청에 포함된 데이터를 모두 메모리로 로드해야 함

– bulk size별로 성능을 측정하여, 최적의 size를 결정

– 5~15MB부터 시작하여 성능 측정하면 좋을 것

kibana

개요

• streaming data에 대한 real-time analysis

• license : open source(apache)

설치 및 실행

references

• elasticsearch: the definitive guide: http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/index.html

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/index.html

distributed nature

life inside a cluster

node & cluster

• 0개의 index를 가진 > 1개의 node로 구성된 > 1개의 cluster

– node: 실행중인 elasticsearch instance

• master node

– 클러스터를 관리

» index 추가 / 삭제

» node 추가 / 삭제

– 투표를 통해 master node 선출

– document-level의 변화나 search는 모든 노드에서 처리 가능하므로 master node는 bottleneck이 되지는 않음

– cluster: 동일한 cluster.name을 가지는 node들의 집합

index & shard

• 3개의 primary shard로 구성된 > 1개의 index를 가진 > 1개의 node로 구성된 1개의 cluster

– index: 관련성이 있는 데이터의 저장 위치

• 물리적인 shard에 대한 논리적인 이름 공간

– shard: index의 데이터 일부를 저장하여 전체 index를 구성

• indexing된 document가 실제 저장되는 곳

• document들은 여러 shard에 분산되어 저장되므로 scale out을 지원

• primary shard

– 모든 document 단 하나의 primary shard에 위치

– primary shard의 개수는 index를 생성할 때 결정되며 바꿀 수 없음 (default: 5)

• replica shard

– primary shrad의 복사본

– 장애 발생시 recovery / searching에 대한 concurrent read 보장

1 replica

• 3개의 primary shard와 1개의 replica로 구성된 > 1개의 index를 가진 > 2개의node로 구성된 1개의 cluster

scale out – shard reallocation


– shard는 새로운 노드로 재할당되어, 새로 추가된 computing power를 완전히 활용할수 있게 된다

2 replica


recovery on failure


– master node 1이 shutdown된 경우,

• primary node selection

– node 2가 새로운 primary node가 된다

• recovering primary shard

– node 1에 위치한 primary shard 1, 2가 사라짐

– replica node를 새로운 primary shard로 지정

distributed document store

• 라우팅(routing)

– 문서를 인덱스에 저장할 때 인덱스의 어느 primary shard에 저장할지 결정해야 함

– 이때 라우팅(routing) 값을 이용한다.

– default: 문서의 _id

• 임의의 문자열을 설정 가능

– 저장할 primary shard 번호는 아래의 규칙에 따라 결정된다.shard = hash(routing) % number_of_primary_shards* number_of_primary_shads: 해당 인덱스의 primary shard 개수

routing: 문서를 저장할 샤드 정하기

searching


– client node에서는 모든 노드에게 검색 요청을 할 수 있으며, 요청을 받은 노드(requesting node)는 요청을 자체적으로 처리할 수 있다

client node

creating / indexing / deleting a document

• shard 0에 대한 document인 경우 처리 순서

– 1. 클라이언트에서 node 1에게 document에 대한 생성/인덱싱/삭제 요청을 한다

– 2. node 1(requesting node)은 document의 _id 값으로 라우팅을 계산하여 shard 0에 대한 document임을 인식한 후, primary shard 0가 위치한 node 3으로 요청을 포워드한다

– 3. node 3에서 primary shard에 대한 처리가 끝나면, replica가 위치한 node 1과node 2로 새로운 document와 함께 reindex 요청을 동시에 포워드한다.

– 4. 모든 replica에서 처리 success 응답을 node 3으로 보내면, node 3은 requesting node(node 1)로 success 응답을 보낸다.

– 5. node 1은 클라이언트에게 success 응답을 보낸다

retrieving a document


– 1. 클라이언트에서 node 1에게 요청을 보낸다

– 2. node 1(requesting node)은 document의 _id 값으로 라우팅을 계산하여 shard 0에 대한 document임을 인식한다. 해당 shard는 모든 노드에 저장되어 있다. 이 경우, 요청을 node 2로 포워드한다.

– 3. node 2는 document를 node 1로 리턴하고, node 1은 클라이언트로 document를리턴한다

– * 동시 요청인 경우

• document가 저장된 replica가 위치한 노드로 요청을 라운드로빈한다.

– * primary node에서 document가 indexing되었지만 replica에는 없는 경우

• node 2는 해당 document가 없음을 알리고, primary node에서 document를 리턴한다

partial update to a document


– 1. 클라이언트에서 node 1에게 document에 대한 생성/인덱싱/삭제 요청을 한다

– 2. node 1(requesting node)은 document의 _id 값으로 라우팅을 계산하여 shard 0에 대한 document임을 인식한 후, primary shard 0가 위치한 node 3으로 요청을 포워드한다

– 3. node 3에서 primary shard에 대한 처리가 끝나면, replica가 위치한 node 1과node 2로 새로운 document와 함께 reindex 요청을 동시에 포워드한다.

– 4. 모든 replica에서 reindex가 완료된 후 처리 success 응답을 node 3으로 보내면, node 3은 requesting node(node 1)로 success 응답을 보낸다.

– 5. node 1은 클라이언트에게 success 응답을 보낸다

[노트] document 기반 replication

• replication은 document 기반으로 동작한다

– 새로운 문서를 추가시

• primary shard에서 index가 끝나면, replica shard로 index된 문서가 아닌 새로운 document를 index 요청을 전송한다.

– 문서를 수정시

• primary shard에서 index가 끝나면, replica shard로 수정 요청이 아닌 새로운 document를reindex 요청을 전송한다.

multi document 처리: mget & bulk

• multi document 처리

– index에 대한 multi document 요청을 shard에 대한 multi document 요청으로 분류한후, 각 shard가 위치한 노드로 multi document 요청을 전송한다.

– 각 node로부터 결과 문서가 전송되면, requesting node에서는 결과를 취합하여 클라이언트로 전송한다

• mget

– 1. 클라이언트가 node 1로 mget 요청을 한다

– 2. node 1에서 index에 대한 mget 요청을 shard에 대한 mget 요청으로 분류한 후, 각 shard가 위치한 node로 mget 요청을 한다.

– 3. 각 node에서 결과 문서를 node 1로 전송하면, node 1은 결과를 취합하여 클라이언트로 전송한다

multi document 처리: mget & bulk

• bulk

– 1. 클라이언트가 node 1로 bulk 요청을 한다

– 2. node 1에서 index에 대한 bulk 요청을 shard에 대한 bulk 요청으로 분류한 후, 각primary shard가 위치한 node로 bulk 요청을 한다.

– 3. 각 node에서는 bulk 요청 각각을 순서대로 실행한다. bulk 요청의 첫 번째 요청을처리한 후, replica가 위치한 node로 새로운 document와 함께 index 요청을 동시에포워드한다. replica에서 처리 success 응답을 보내면, 다음 요청을 처리한다.

– 4. shard별 bulk 요청이 끝나고, 모든 shard가 완료되면 node 1은 클라이언트에게success 응답을 보낸다

distributed search execution

search: 2 step phases

• search

– search = query + fetch

– query phase

• 검색이 시작되면, index의 모든 shard에게 질의문(query)가 broadcast된다(round-robin)

• 각 shard는 로컬에서 검색을 실행한 후, 매칭된 document에 대한 priority queue를 만든다.

• 각 shard는 coordinating node(검색 요청을 받은)로 결과 리스트를 반환한다. 이 리스트에는document 자체는 포함되지 않고, document를 sort할 수 있는 정보(_score 등)가 포함된다.

• coordinating node는 이들 결과 리스트를 병합하여 전역 sorted list를 만든다.

– fetch phase

• query phase에서 만든 전역 sorted list를 바탕으로, shard에서 실제 document를 가져와서클라이언트로 리턴한다

query phase

• query

– 1. 클라이언트가 node 3으로 search를 요청하면, node 3은 from + size 크기의 비어있는 priority queue를 만든다.

– 2. node 3은 search request를 index의 모든 node로 포워드한다. 각 shard가 위치한node는 로컬에서 검색을 실행한 후, 매칭된 document에 대한 로컬 priority queue를만든다

– 3. 각 shard는 로컬 priority queue에 포함된 문서의 doc ID와 sort 값(_score 등)을포함한 리스트를 coordinating node(node 3)로 전달한다. node 3은 이들 리스트를병합하여 전역 sorted list를 만든다

fetch phase

• fetch

– 1. coordinating node(node 3)는 전역 sorted list로부터 가져올 document를 식별한후, mget 요청을 관련된 shard로 전달한다.

– 2. 각 shard는 mget을 요청에 대한 document를 coordination node로 전달한다.

– 3. 모든 document가 전달되면, coordinating node는 document를 클라이언트로 전달한다.

[주의] deep pagination

• deep pagination

– size가 너무 크거나 from이 너무 큰 경우 문제가 될 수 있다

– 예를 들어 총 검색 요청과 관련된 shard가 총 5개이고, 검색 결과는 10개만 가져오는경우를 보자. 이 중 1페이지를 가져오는 경우,

• 각 shard가 있는 노드에서 문서를 scoring한 후 정렬하여 각각 10개의 문서를 리턴한다.

• coordinating node는 반환된 총 50개의 문서를 재정렬한 후 10개의 문서를 리턴한다

[주의] deep pagination

• deep pagination

– 만약 1000페이지를 가져오는 경우라면(from = 1000, size = 10), 정렬된 문서에서10,001에서 10,010번째까지의 문서를 리턴해야 한다.

• 이 경우에는 각 노드에서 scoring한 문서 중 10,010개의 문서를 request node에 반환해야한다.

• coordinating node에서는 총 50,050개의문서를 정렬하여 10개는 리턴하고, 나머지 50,040개의 문서는 버리게 된다.

• 이와 같은 이유로 검색 엔진 웹에서는일반적으로 1000 페이지 이상은제공하지 않는다.

inside a shard

flush, refresh, optimize

• elasticsearch에서

– search는 near real-time: indexing한 document를 기본적으로 1s 이후 search 가능

– CRUD는 real-time

– data persistence를 보장

– delete operation을 하더라도 disk가 바로 해제되지 않음

• Why?

– refresh

– flush

– optimize

Historically, index is immutable

• inverted index data structure

– 검색엔진은 inverted index 데이터 구조를 이용해 full-text search가 가능하도록 했다

– inverted index는 전체 document를 통해 만들어지며 수정이 불가능했다(immutable)

• Why immutable?

– update가 불가능하므로 concurrency 제어를 위한 locking 등이 필요 없다

– 전체 index가 파일 시스템 캐시에 로드할 수 있다면, 변경이 없으므로 항상 로드된 상태이며, 검색은 File I/O가 아닌 메모리를 통해 이루어지므로 성능이 향상된다.

– 커다란 단일 index이라면, 압축을 하여 DISK I/O를 줄이고, 캐싱에 필요한 RAM 용량을 줄일 수 있다.

• How to update?

– 새로운 document가 있고 search가 가능하도록 하려면, 전체 index를 새로 rebuild해야만 한다. 문제점 1. 단일 index size의 한계 문제점 2. search frequency의 한계

• 새로운 document가 search가 가능하게 되는 주기가 길다

dynamically updatable indices

• index의 immutable한 장점은 그대로 유지한 채, index를 수정 가능하게 하기

– “여러 개의 index를 사용하자”

• 기존의 커다란 inverted index는 그대로 유지

• 새로운 document는 주기적으로 새로운 index로 생성

• search 요청 발생시, 여러 개의 index를 차례대로 검색한 후 결과를 병합하여 리턴

– segment: 이러한 여러 개의 index들 중 하나

• 용어 정리

– index = segements + commit point

– commit point= 현재 segment 목록

index

shard

segment


• commit point와 3개의 segment로 구성된 index

– index는 3개의 segment로 구성되며, 모두 search가 가능한 상태


• 새로운 document가 들어오면

– 1. in-memory indexing buffer에 저장된다(현재는 search는 불가능)


• 새로운 document가 들어오면

– 2. 주기적으로, buffer는 commit된다

• 새로운 segment가 생성된 후 disk에 write된다.

• 새로운 commit point가 disk에 기록된다. 이 목록에 새로운 segment 이름이 추가된다

• disk가 fsync된다.

– 파일시스템 캐시에 있는 모든 데이터가 물리적으로 disk에 flush된다

– 새로운 document는 search가 가능해진다


• delete / update a document

– document를 삭제하거나 수정할 경우, index를 수정하지 않는다(immutable)

– 대신, .del 파일에 삭제/수정된 파일을 “deleted”로 표시한다.

– 검색시, 매칭은 되지만 클라이언트로 리턴되지는 않는다

– purge a document

• segment가 merge될 때, “deleted”로 표시된 파일을 disk에서 영구적으로 삭제한다

near real-time search

• delay in making searchable

– in-memory indexing buffer를 사용하여, 전체 index는 immutable하게 유지한 채로새로운 document를 추가할 수 있도록 했다

– 하지만 새로운 document가 search가 가능 하려면, 새로운 segment를 파일시스템캐시에 만든 후, disk를 fsync 해야 한다.

– 그리고 fsync는 DISK I/O를 발생시키며, 이는 느리며 비용이 많이 들므로 자주 실행할 수는 없다.

파일 시스템 캐시까지만 segment가 만들어지면 search가 가능하도록 하자(fsync는 나중에 주기적으로 하자)

새로운 segment는 검색은 가능하지만 commit point는 없는(fsync) 되지 않은 상태

near real-time search

• refresh

– full commit(fsync를 포함하는)이 아니라, 새로운 segment를 열고 search만 가능하도록 만드는 operation

– elasticsearch는 주기적으로(default: 1s) refresh를 실행

• 1s마다 새로운 segment가 생성됨

– refresh_interval 속성으로 설정 가능

• 기본적으로 1s 이내에는 새로운 document가 search가 가능해짐

– 직접 refresh를 실행하려면

making changes persistent

• fsync가 실패한다면?

– 파일시스템 캐시에 저장된 새로운 segment는 commit point에 기록되지 않고, physical 디스크에 저장되지 않았으므로 데이터가 사라진다 translog를 사용하여 indexing operation을 기록하자

• document가 indexing되면 in-memory buffer와 translog 모두에 기록된다


• translog를 사용하여 indexing operation을 기록하자

• 주기적으로 refresh가 발생하면

– in-memory buffer에 기록된 새로운 document는 새로운 segment로 만들어지고 search가 가능(fsync는 발생하지 않음)

– in-memory buffer는 비워진다



• 또다시 새로운 문서가 들어오고 indexing이 되면

– in-memory buffer와 translog에 기록된다(translog는 이전의 기록을 함께 유지한 상태)



• translog가 충분히 커지면 주기적으로 flush가 발생하여

– in-memory buffer에 기록된 새로운 document는 새로운 segment로 만들어지고 search가 가능하며, in-memory buffer는 비워진다

– 새로운 commit point가 기록된다

– 파일 시스템 캐시는 fsync를 통해 physical 디스크로 flush된다

– translog는 비워진다.

• translog를 사용하므로

– CRUD는 real-time 처리가 가능

– RUD의 경우, document _id로 translog를 먼저 조사하므로 실시간으로 document의최신 버전을 찾을 수 있음

• flush

– flush = commit + translog 비우기

– 주기적으로 실행

• default: 30min

– index.translog.flush_threshold_period 속성 등으로 설정 가능(좌표: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-translog.html)

– node를 restart할 때는 직접 flush하는 게 좋다

• translog의 fsync

– translog 자체는 5s 주기로 physical 디스크에 flush를 한다(index.translog.interval로설정 가능)

– 최악의 경우 5s 분량의 데이터는 소실될 가능성은 있다


http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-translog.html

• refresh를 통해

– near real-time search는 가능하지만

– 1s 단위로 새로운 segment가 생성되며, segment는 시간이 지나면서 기하급수적으로증가

백그라운드에서 segment를 병합하자

• indexing이 되면, refresh 프로세스에서는 새로운 segment를 열고 search가 가능하게 한다

• merge 프로세스에서 비슷한 크기의 segment를 병합하여 좀 더 큰 새로운 segment를 생성한다(이때 “deleted”로 표시된 document는 새로운 segment를 병합할 때 포함되지 않고 완전히삭제된다)

segment merging

• segment merging이 끝나면

– 새로운 segment가 disk로 flush된다.

– 새로운 commit point가 기록된다. 이때 병합된 이전의 segment는 지워지고, 새로운segment가 기록된다

– 새로운 segment가 open되어 search가 가능해진다

– 이전의 segment는 삭제된다

segment merging

• 성능 이슈

– segment merging 프로세스는 Disk I/O와 CPU를 과도하게 소모하여, merging이 진행 중이라면 search 성능이 저하될 수 있다

• merge throttling 기능을 통해 merging을 제약한다

• merging 직접 실행

– optimize API

• shard에 대해 segment가 max_num_segments 개수만큼 되도록 강제적으로 merge를 한다

• 실시간으로 데이터를 수집하여 indexing을 하는 시스템이라면 optimize API를 사용하면search 성능이 저하되므로 사용하지 말 것

• 로그와 같이 날짜 단위로 인덱스를 생성하는 구조라면, 이전 날짜의 인덱스에는 새로운 데이터가 추가되지 않으므로 직접 optimize API를 사용하면 효율적일 것

• optimize API를 직접 사용하게 되면 throttling이 되지 않고 노드의 모든 I/O와 CPU를 사용하게 된다.

– 이러한 경우라면 optimize할 index는 shard allocation을 통해 search가 드물게 일어나는 node로 이동해야 한다.

– 참고) http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/retiring-data.html#migrate-indices

segment merging

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/retiring-data.html#migrate-indices

references

• elasticsearch the definitive guidehttp://www.elasticsearch.org/guide/en/elasticsearch/guide/current/index.html

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/index.html

aggregation

aggregation 맛보기

aggregation 개요

• 개요

– near-real time analytic 도구

– 리포팅 및 대시보드 생성에 적합

– 실시간 데이터 visualization

• 분류

aggregation basics min

max

avg

etc

approximation cardinality

percentile

significant terms

buckets & metrics

• buckets

– criteria를 만족하는 document 집합

– partitioning(grouping) documents based on criteria

• metrics

– 우리가 알고 싶은 정보

– bucket에 포함된 document에 대한 statistics(min, max, avg, var, …)

사례 : Car Transaction

• sample data를 bulk indexing하기

– transactions

• price : 자동차 가격

• color : 자동차 색상

• make : 자동차 제조사

• sold : 팔린 날짜(yyyy-mm-dd)

기본 문법

• aggregation 기본 문법 : terms bucket

select color, count(*) as colorsfrom carsgroup by color

sql 비교

기본 문법

• bucket의 metric 구하기

select color, avg(price) as avg_pricefrom carsgroup by color

sql 비교

nested buckets


and

select color, make, count(*)from carsgroup by color, make

sql 비교

• nested buckets

nested buckets

• nested buckets and metrics


and

select color, make,min_price(price) as min_price,max_price(price) as max_pricefrom carsgroup by color, make

sql 비교

bucket 유형

• 좌표

– http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_available_buckets_and_metrics.html

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_available_buckets_and_metrics.html

metric 유형

visualization : bar chart 1

• histogram bucket을 사용하여 bar chart 만들기

– goal : 가격 구간대별 가장 많이 팔린 제조사 찾기

– bucket : “price” 필드에 대해, 20,000 interval을 기준으로 histogram bucket

– metric : 가장 많이 팔린(size = 1) “make” 찾기


• visualization using kibana


• terms bucket을 사용하여 bar chart 만들기

– goal : 자동차 제조사별 평균가격 구하기

– bucket : terms bucket on “make”

– metric : extended_stats on “price”

visualization : time series

• date_histogram bucket을 사용하여 time series 만들기

– goal : 월별 팔린 자동차 대수 구하기

– bucket : “sort” 필드에 대해, “month” interval을 기준으로 date-histogram bucket

visualization : time series

• date_histogram bucket을 사용하여 time series 만들기

– goal : 월별 팔린 자동차 대수 구하기(단, 날짜 구간을 설정하고, 결과가 0인 월의 데이터도 생성)

– bucket : “sort” 필드에 대해, “month” interval을 기준으로 date-histogram bucket

visualization : time series refined

visualization : time series refined

visualization : kibana dashboard

http://localhost:5601

• scope of aggregation

– aggregation은 query scope를 기반으로 분석한다

scoping & filtering

scoping & filtering

• scope of aggregation on filtered query

– filtered query인 경우에도, filtered query scope를 기반으로 aggregation이 실행

scoping & filtering

* kibana 4beta3 does not support filter yet

• filtered bucket

– search scope는 그대로 둔 채, aggregation scope에 대해서만 filtering

scoping & filtering

• query scope인 경우

• filtered query scope인 경우

scoping & filtering

query aggregation

*docs

matched docs

metricsper buckets

filteredquery

aggregation

filtereddocs

matched docs

metricsper buckets

• filtered bucket인 경우

scoping & filtering

queryfiltered

aggregation

*docs

matched docsmetrics

per buckets

filtereddocs

• post filter

– when to use

• 예를 들어, ford 제조사의 월별 판매량과 판매 목록을 보여주는 화면이 있고

• 사용자에게 ford의 색상별로 자동차 판매 목록(subset)을 볼 수 있는 기능을 제공해야 하는경우

• 즉 상위 subset에 대한 목록과 aggregation을 보여준 채로, 하위 subset에 대한 목록을 선택적으로 보여줘야 하는 경우

• 동일한 scope에서 상위 목록과 aggregation을 실행한 후,

• 해당 scope에 대해 post filter를 적용하여 하위 목록을 조회한다

scoping & filtering

query aggregation

*docs

matched docs

metricsper buckets

filtereddocs

post filter

• post filter

scoping & filtering

– 성능 고려 사항

• post filter는 query가 실행된 이후에 적용

– filtered query와는 달리 속도 저하가 발생한다.

• SQL로 보면 where 조건절이 없이 document full scan을 실행 한 후, 결과를 filtering하는 것과 같다

scoping & filtering

• 정리

– 사용 구문에 따라 아래와 같이 scope에 영향을 미친다

사용 구문 search scope aggregation scope

(filtered) query O O

filtered bucket X O

post filter O X

• default sort : doc_count desc

• intrinsic sort : according to buckets’ nature

sorting

select color, count(*) as colorsfrom carsgroup by colororder by colors asc

sql 비교

• sorting by metrics

sorting

select color, avg(price) as avg_pricefrom carsgroup by colororder by avg_price asc

sql 비교

• sorting by deep metrics on nested buckets

sorting

aggregationapproximation

• 한계

– 결과의 정확성(exactness), big data 처리, real-time 응답을 모두 만족할 수는 없다

– 빅데이터 환경에서 실시간 응답성을 만족해야 한다면, 정확성은 어느 정도 희생해야한다

real-time analytics on big data

Exact

Big Data

RealTime

• ER(Exact – Real-time)

– 단일 머신에서 알고리즘을 실행 가능한 경우

• 예) RDBMS

– aggregation 결과는 100% 정확하며, 실시간 응답성을 보장한다


Exact

Big Data

RealTime

• EB(Exact – Big data)

– 단일 머신에서 알고리즘을 실행할 수 없을 정도로 데이터가 큰 경우, 실시간 응답성을희생

• 예) Hadoop M/R

– PB급 데이터에 대해 정확한 aggregation 결과를 낼 수 있으나, 응답이 느리다


Exact

Big Data

RealTime

• BR(Big data – Real-time)

– 단일 머신에서 알고리즘을 실행할 수 없을 정도로 데이터가 큰 경우

– 실시간 응답성을 만족하기 위해 정확도를 어느정도 희생

• 예) elasticsearch approximation aggregation

– aggregation 결과는 accurate, but not exact


Exact

Big Data

RealTime

currently supported approximation

• 현재(1.4.0) 기준 지원하는 approximation aggregation

– cardinality

– percentiles

cardinality

• when to use

– finding distinct or unique values

• to answer following questions

• 웹사이트 UV가 얼마인가?

• 얼마나 많은 unique 자동차가 팔렸나?

• 매달 구매자 중 unique buyers는 몇 명인가

– 예) 팔린 자동차 중, unique한 색상은 몇 가지인가?

cardinality

• when to use

– 예) 팔린 자동차 중, 월별 unique한 색상은 몇 가지인가?

HLL algorithm

• HyperLogLog++(HLL) algorithm

– elasticserach의 cardinality approximation은 HyperLogLog++(HLL) algorithm을 기반

– HyperLogLog++(HLL) algorithm의 특징

• 정확도(precision) 설정 가능단, 정확도를 올릴 수록, 메모리 사용량이 증가

• cardinality가 낮은 집합일 수록 정확도가 높아진다

• 메모리 사용량이 고정적

• 메모리 사용량은 정확도에만 비례

precision 조절

• 일반적으로 cardinality가 precision보다 적다면 거의 항상 100% 정확

• memory usage of HLL data structure = (대략) precision_threshold * 8 bytes

• practically,

– precision_threshold가 100이고, unique한 값이 수백만인 경우, 정확도는 대략 95% 정도 된다

정확도 설정

: precision_threshold(0 ~ 40,000)

cardinality approximation 성능 향상을 위한 조언

• HLL은 hash field의 hash값을 이용한다

• HLL은 충분히 빠르나, 더 빠르게 만들고자 한다면, query time이 아닌 index time에 hash를 미리 만들어 둔다

– 단 numeric value나 string이 짧은 경우는 무의미

– cardinality가 크거나 string이 긴 경우만, hash 값을 미리 만드는 게 효과적

percentiles

• when to use

– finding outliers

• 웹페이지 latency 속도 데이터 중, 상위 10%(가장 오래 걸린)는 어느 정도의 시간이 걸렸나?

– outliers에 의한 insight 왜곡: 전체 데이터에 대해 평균(mean) 또는 중앙값(median만을 보는 경우: 아래와 같이 별다른 insight를 도출이 불가능

percentiles

• when to use

– 99th percentiles의 데이터에 대해 평균(mean) 또는 중앙값(median)을 보는 경우

– 4:48분경, 9:36분경 2차례에 걸쳐“1%의 사용자가 300ms, 950ms에 달하는 latency를 경험했다”는 사실을 발견할 수 있다

사례 : 웹사이트 latency

• sample data bulk indexing

– logs

• latency : 응답시간(ms)

• zon : 서버 존

• timestamp : 발생날짜(yyyy-mm-dd)


• latency에 대한 percentiles 구하기

– 75th percentile = 289.75 > 전체 평균 = 200 최소 25% 이상의 사용자가 평균보다 높은 latency를 경험하고 있다


• zone별 latency에 대한 percentiles 구하기


• zone별 latency에 대한 percentiles 구하기

– US zone

• 50th percentile과 99th percentile이 크게 차이가 나지 않으며, 평균(90)에 가깝다

– EU zone

• 50th percentile과 99th percentile이 크게 차이가 날뿐더러, 50th percentile은 이미 300ms에 근접한다

• 전체 latency를 늦추는 문제는 EU zone에서 발생하고 있다


• percentile ranks

– n’th percentile = 전체 데이터 중 N% 이하가 넘지 않는 최소값 M

– percentile rank of M = M이 속하는 percentile N

– percentile ranks 구하기


– US zone

• 210은 100th percentile에 속한다.

• 즉 latency가 210을 넘지 않는다

– EU zone

• 210은 32th percentile에 속한다

만약 SLA 체결시 latency를 210ms을 보장할 것을 약속했다면, 이는 EU의 latency에 대해 32% 시간만을 충족한다고 이야기할 수 있다.

TDigest algorithm

• TDigest algorithm

– elasticserach의 percentiles approximation은 TDigest algorithm을 기반

– TDigest algorithm의 특징

• percentile 정확도는 percentile의 값이 아주 크거나, 또는 아주 작을수록 높아진다.

• 어차피 outlier를 포착하기 위한 목적이니 문제가 아니다

• data set이 작을수록 정확도가 높다. 충분히 작다면 100%에 가까워진다

• bucket의 data size가 커질수록 정확도가 낮아진다.inaccuracy는 정확히 수식화할 순 없다.

• 정확도를 낮추면 메모리 사용량도 적어진다.

percentiles approximation 성능 향상을 위한 조언

• TDigest algorithm은 approximation을 할 때 node 구조를 사용한다. 더 많은 node를 사용할 수록,

– 정확도는 높아진다

– 메모리 사용량은 높아진다.

– 처리 속도는 느려진다.

• compression 속성을 이용해서 memory-to-accuracy 비율 설정 가능

– 최대 사용 가능 node 개수 = 20 * compression

– 기본값 : 100

– 대략 한 노드당 32바이트 메모리

– 기본 설정시, 최대 20 * 100 * 32 = 64KB 메모리 사용

aggregationsignificant terms

uncommonly common data

• 은행에서 신용카드 사기꾼(credit card fraud)을 찾는 경우, 가맹점이

– Aamazon.com과 같이

• 대다수의 카드 트랜잭션이 이들 업체에서 발생

• 하지만 정상적인 카드 트랜잭션이 다수 포함됨

• 분석 대상에서 제외

– 마약 판매 사이트와 같이

• 극히 일부에서 소수의 카드 트랜잭션이 이들 업체에서 발생

• 하지만 비인가된 카드 트랜잭션은 없음

– 우리가 찾고자 하는 곳

• 비인가된 카드 트랜잭션 이들 업체에서 발생

• 전체 데이터 기준 대비 이들 데이터에서 비정상적 트랜잭션이 더 많이 발생함

• 하지만 대다수의 정상적인 카드 트랜잭션이 잡음(noise)이 되어 드러나지 않음

• uncommonly common data= statistically unusual data= data that appears more frequently than the background rate would suggest= statistical anomalies = interesting data

commonly common

commonly uncommon

uncommonly common

uncommonly common data전체 데이터셋(트랜잭션) : 544개

AA A A AA A A AA A A AA A A AA A A AA A A AA A A AA A A





AA A A AA A A AA A D AA A A AA A A XA A A AA A A AA A A




AA A A AA A A AA A A AA A A AA A A AA A A XA A A AA A A

AA A A AD A A AA A A AA A A AA A A AA A A AA A A AA A A

AA A A AA A A AA A A AA A A AA A A AA A A AA X A AA A A



AD A A AA A A AA A A AA A A AA A A AA A A AA A A AA A A

D

AA A A AA A A AA A A AA A A AA A A AA X X XX X X XX X X


A

X X

A 회사의 정상 트랜잭션

D 회사의 정상 트랜잭션

X 회사의 정상 트랜잭션 X 회사의 비정상 트랜잭션

A A 회사의 비정상 트랜잭션


• 회사별 트랜잭션 비교

– 비정상 트랜잭션이 발생한 빈도(frequency, popularity)만을 기준으로 순위를 매기면

• 회사 A가 카드 사기꾼일 가능성이 가장 높고

• 회사 X는 그 다음이며

• 회사 D는 카드 사기꾼은 전혀 아니다

– 문제는

• 회사 A는 대다수의 트랜잭션이 발생하는 회사로, 굳이 분석하지 않더라도 쉽게 발견 가능 commonly common data

• 회사 D는 트랜잭션이 희박하게 발생하지만, 비정상 트랜잭션은 발생하지 않는다. 이들 회사가 우리 은행을 사용할 거라고 생각해 본적은 없으나, 카드 사기꾼은 아니다 commonly uncommon data

• 회사 X는 소수의 트랜잭션이 발생하나, 비정상 트랜잭션도 발생하며, 회사 X의 전체 트랜잭션 대비 그 빈도가 높음 uncommonly common data, 찾으려는 대상

회사 전체 트랜잭션 비정상 트랜잭션 비율 순위

A 528 40.735%(4 / 544)

1

X 13 30.551%(3 / 544)

2

D 3 0 0% 3


• background vs. foreground

– background : 모집단 데이터(전체 트랜잭션)

• A’s background rate = (A 집단의 개수) / (모집단 데이터)= (A 집단의 트랜잭션) / (전체 트랜잭션)

– foreground : 관심 데이터(비정상 트랜잭션)

• A’s foreground rate = (관심 데이터 개수) / (관심 집단)= (A 집단의 비정상 트랜잭션) / (전체 비정상 트랜잭션)

전체 트랜잭션(background)

A 집단

관심 집단

모집단

A집단의 트랜잭션

전체 비정상 트랜잭션(foreground)

A 집단의 비정상 트랜잭션


• scoring 방법

– foreground rate이 background rate에 비교해볼 때 비정상적으로 높은 데이터가 더많은 socre를 가진다예) JLH Heuristics

• 차이의 절대값(absoulte change) = |foreground rate – background rate|(차이가 음인 경우, 0 값을 가진다)

• 차이의 상대값(relative change) = foreground rate / background rate

JLH score = absolute change * relative change

(background rate, 즉 popularity가 높은 집단은 score가 일반적으로 낮아진다)

• scoring에 따른 순위

– popularity와는 달리,

• 가장 많은 비정상 트랜잭션이 발생한 A 회사는 추천되지 않는다(commonly common)

• 반면 popularity는 낮지만, X 회사가 가장 많은 score를 획득한다(commonly uncommon)

회사전체

트랜잭션비정상

트랜잭션BR FR

absolutechange

relativechange

score 순위

A 528 4 0.971 0.571 0 0.588 0 2

X 13 3 0.0239 0.429 0.405 17.93 7.257 1

D 3 0 0.0052 0 0 0 0 3


• JLH Heuristics 구현부분

foreground ratebackground rate

absolute change

relative change

score

개요

• goal

– 데이터 셋에서 uncommonly common terms를 찾기 위해

• significant aggregation이란?

– 데이터를 분석하여 background data에 비교해 볼 때 통계적인 이상치(statistical anomaly)에 해당하는 빈도(frequency)를 가지는 term을 찾는 방법

• 응용 분야

– detecting geographic anomaly

– root cause analysis in fault reports

– training classifiers

– revealing badly categorized content

– detecting credit card fraud

– making product recommendations

사례 : 영화 추천기

• 요구사항

– goal

• 사용자가 추천한 영화 목록 데이터를 바탕으로 영화 추천하기

– input : 1개의 영화

• Talladega Nights

– Will Ferrell이 주연한 코메디 영화

– output : 추천된 영화 목록 Top 5

• 유사한 스타일의 코메디 영화(기왕이면 윌 페럴이 주연한 영화가 추천되었으면 좋겠다)

• 사용할 전략 2가지

– recommending based on popularity: 통계적인 방법을 사용하지 않음

– recommending based on statistics: SigTerms(significant terms aggregation)을 적용

데이터 구조

• mlmovies : 영화 정보

– bytes

– offset

– title : 영화 타이틀

• mlratings : 영화 추천 정보

– bytes

– movie : 영화 document ID 목록

– offset

– user : 추천한 사용자 ID

mlmovies

bytes long

offset long

title string

mlratings

bytes long

movie integer

offset long

user integer

데이터 구조

• 샘플 데이터 restore하기

popularity를 기준으로 영화 추천하기

• 방법

– 주어진 영화를 추천한 사용자들을 찾는다.

– 이들 사용자들이 추천한 영화들 중에서, 가장 빈도가 높은 다른 영화 top 5를 찾는다

• 순서

– Talladega Nights의 document ID 찾기

– 이 ID를 포함하는 mlrating의 document에 대해 aggregation 수행하여 top 5 영화document의 ID 목록 찾기

– 영화 ID로, 영화 정보 가져오기


• Talladega Nights의 document ID 찾기


• 이 ID를 포함하는 mlrating의 document에 대해 aggregation 수행하여 top 5 영화 document의 ID 목록 찾기


• 영화 ID로, 영화 정보 가져오기

[추천된 영화 목록]


• 영화별 비율

– 총 69,796개의 mlrating에서 “Matrix, The”가 추천된 document는 18,361 개다

– 입력인 “Talladega Nights”와 “Matrix, The”가 함께 추천된 document는 197개다

– popularity의 경우, 두 영화가 함께 추천된 document의 개수를 기준으로 정렬된다

영화mlrating문서 개수

Talladega Nights를 함께 포함하는

mlrating문서 개수

비율 순위

Matrix, The 18361 1970.282

(197 / 69796)1

ShawshankRedemption

27563 1960.281

(196 / 69796)2

Pulp Fiction 26862 1830.262

(183 / 69796)3

Fight Club 12896 1830.262

(183 / 69796)4

Star Wars 22652 1780.255

(183 / 69796)5


• 문제점

– 대다수의 사용자가 추천된 영화를 좋아한다

– 추천된 영화= universally well-liked recommendation = commonly common data

– 입력 데이터(영화)인 Talladega Nights와 관련성이 낮다

– 입력과 관계 없이 전체 사용자가 추천한 Top 5 영화를 추출하면,

[Universally Top 5 영화 목록]

[추천된 영화 목록]

Talladega Nights의 추천 목록과 크게 차이가 없다

statistic를 기준으로 영화 추천하기

• 방법

– find the foreground groupTalladega Nights을 추천한 사용자 그룹을 분석하여, 가장 popular한 영화 목록을 찾는다

– find the background group모든 사용자 그룹에 대해 가장 popular한 영화 목록을 찾는다

– 이 둘을 비교하여 statistical anomaly를 찾는다

• statistical anomaly : foreground group과 background group에 비교할 때, bg에 비해 fg에서 더 빈번하게 발생하는 영화들

• 추천이 예상되는 영화 목록

– 추천된 영화는 comedy 영화여야 한다fg(Tallageda Nights 영화 즉, comdey 영화를 추천한 그룹)은 comedy 영화에 대한선호도가 전체 bg에 비해 높을 것으로 유추 가능하기 때문


• significant terms aggregation

fg(bucket) count

bg count


• background vs. foreground

– ID가 52245인 “Blades of Glory” 영화의 경우

• background rate = (Blades of Glory 추천) / (전체 추천) = 185 / 69796 = 0.0027

• foreground rate = (Talladega Nights와 Blades of Glory 모두 추천) / (Talladega Night 추천)= 59 / 271 = 0.218

• score = (absolute change) * ( relative change)= |0.218 – 0.0027| * (0.218 / 0.0027)= 17.665

전체 추천 데이터(background) = mlratings

52245

관심 집단

모집단

“Blades of Glory”에 대한 추천 데이터

“Talladega Nights”에 대한 추천 데이터(foreground)

“Talladega Nights”와 “Blades of Glory”를모두 추천한 데이터


• 결과 분석

• “Blades of Glory”는 전체 추천 대비 빈도(frequency) 또는 선호도(popularity)는 낮다

• 그러나 foreground rate, 즉 Talladega Nights를 함께 추천한 집단에 대해서는 빈도가 높아가장 높은 score를 가지며 우선 추천된다

• 반면 앞서 선호도가 가장 높았던 “Matrix, The”의 경우 background rate, 즉 전체 추천 대비“Matrix, The”가 추천된 빈도가 높으므로 낮은 score를 획득한다

영화mlrating문서 개수

Talladega Nights를함께 포함하는

mlrating문서 개수

BR FR score 순위

Blades of Glory

185 59 0.0027 0.218 17.665 1

Anchorman

762 107 0.011 0.395 13.884 2

Semi-Pro 28 17 0.0004 0.063 9.746 3

Knocked Up

857 95 0.0123 0.351 9.658 4

40-Year-Old Virgin

1610 128 0.0231 0.472 9.199 5

Matrix, The 18361 197 0.2631 0.727 1.282 441

references

• significant terms aggregation:http://www.elasticsearch.org/blog/significant-terms-aggregation/

• [yet] Revealing the Uncommonly Common with Elasticsearchhttp://www.infoq.com/presentations/elasticsearch-revealing-uncommonly-common

• [yet] significant terms aggregationhttp://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html

http://www.elasticsearch.org/blog/significant-terms-aggregation/

http://www.infoq.com/presentations/elasticsearch-revealing-uncommonly-common

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html

Query DSL & aggregation

Search 101

검색 모드

검색 명령어 구조

라우팅

Query DSL 개요

파라미터

search type

search type

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-scroll.html#scroll-scan

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-scroll.html#scroll-scan

Query vs. Filter

Query DSL

Filter DSL

Query DSL vs. Aggregation DSL

Query DSL 기본 구조

Aggregation DSL 기본 구조

partial matching

structured search

structured search for structured data

• structured data

– 날짜, 시간, 숫자

– discrete set of text예) 색상(red, green, blue, …)예) 코드(상품 코드, …)

• structured search

– structured data set에 대해, 각 아이템이 조건에 매칭되는지 아닌지 여부(yes or no)에 따라 결과 set이 결정

– exact matching

term filter

• indexing sample data

• finding exact value SELECT documentFROM productsWHERE price = 20

filteredquery

termfilter

term filter는 scoring을하지 않음

term filter

• term filter on text

– by default, text 타입은 term 단위로 토큰화하여 analyzed 된다

SELECT productFROM productsWHERE productID = "XHDK-A-1293-#fJ3"

term filter

• not_analyzed

– text 타입에 대해 exact matching을 하려면, indexing time에 해당 field가 analzyed되지 않도록 한다

* 인덱스 이름 끝에 반드시 슬래시(/)를 추가한다. 그렇지 않을 경우 ElasticsearchParseException이 발생한다.

full-text search

full-text search 주요 개념

• relevance

– query에 매칭되는 정도

– TF/IDF 알고리즘을 통해 계산

• analysis

– index time: document를 analyze

– query time: query문을 analyze

query 유형

• term-based query

– analysis phase를 거치지 않는다예) term query, fuzzy query, …

– “foo” != “Foo”

• full-text query based on relevance(score)

– analysis phase를 거친다예) match query, query_string query

– “foo” == “Foo”, “fox” = “foxes”

match query


• matching value

match query는scoring을 한 후, score에 따라 정렬함

partial matching

requirement

• LIKE search

– Why?

• fox뿐만 아니라, foxes를 포함하는 문서를 함께 검색하기 위해

– Don’t

• analysis를 거치면, match query 실행시 fox뿐만 아니라, foxes까지 검색되므로, 일반적으로검색 엔진에서는 LIKE search가 불필요

WHERE text LIKE "*quick*"AND text LIKE "*brown*"AND text LIKE "*fox*"

When to use partial matching

• 언제?

– 우편번호, 상품 번호를 매칭할 때

– not_analyzed 필드에 대해

• 접두어 매칭(prefix match)을 할 때

• 와일드카드 매칭을 할 때

• 정규 표현식으로 매칭을 할 때

– 검색어 자동 완성이 필요할 때

prefix matching on 우편번호


prefix matching할 필드는not_analyzed 함

prefix matching on 우편번호

• prefix query

• 주의할 점

– analysis를 하지 않으므로, prefix로 시작하는 모든 term을 순회한다

– term 개수가 급격히 증가하는 상황에서는 검색시 scale out이 어렵다

– 가능하면 prefix의 글자수의 최소값을 가능한 한 크도록 제한한다

no scoring

• wildcard query

• 주의할 점




– *foo 와 같이 패턴으로 시작하지 않도록 한다

wildcard matching on 우편번호

no scoring

• regexp query

• 주의할 점




– .*foo와 같이 패턴으로 시작하지 않도록 한다

정규식 matching on 우편번호

no scoring

autocomplete

autocomplete on query-time

• prefix query

– 사용자가 W1, W1V를 순서대로 입력할 때마다 검색을 수행하여 매칭 결과를 리턴

– prefix query 등은 resource 소모가 큰 쿼리이므로, 사용자 입력시 매번 검색을 수행하는 것은 클러스터에 부하를 주게 됨

autocomplete on index-time

• n-gram

– partial matching을 위한 데이터를 indexing time에 준비하여 검색 성능을 향상

• 전체 term에 대해 검색시 매칭을 하는 것보다, 단일 term을 lookup하는 것이 더 빠르다

– term이 quick인 경우

– 단일 term에 대해, 부분 매칭이 필요한 경우 유용하나, autocomplete은 불가능

• edge n-gram

– term이 quick인 경우,


• index settings

• autocomplete analyzer 테스트


• index mappings

– index-time에만 autocomplete analyzer를 적용



• query for autocomplete

references

• search in depthhttp://www.elasticsearch.org/guide/en/elasticsearch/guide/current/search-in-depth.html

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/search-in-depth.html

Using Synonyms

synonym token filter

• analyzer 등록하기

synonymtoken filter

synonyminline 등록

analyzer정의

synonym token filter

• analyzer 테스트하기

원본 토큰과 동일한 offset에“SYNONYM” 타입을 가지는동의어까지 토큰으로 생성됨

아래 질의문은 모두 위의 문장을가지는 문서에 매칭된다• English queen• British queen• English monarch• British monarch

Synonym 등록 포맷

• 확장(expansion): 리스트 방식“jump,leap,hop”

• 축약(contraction): 매핑 방식

• 추가 규칙

– 동일한 동의어에 대한 규칙은 하나로 병합됨

– 동일한 동의어에 대한 규칙이 충돌 나는 경우, 가장 긴 규칙이 적용

Unite States of America => (usa), (of), (america)가 아닌 (usa)로 분석됨

동의어 파일

• 동의어 파일 사용

– synonym 등록 포맷에 맞게 동의어 파일을 생성

– synonym_path 변수에 동의어 파일 경로 지정절대 경로 또는 ${ES_HOME}/config를 기준으로 상대 경로로 지정

– 동의어 파일은 클러스터 내의 모든 노드에 배포해야 함.

동의어 파일

• 동의어 갱신하기

– 동의어는 analyzer 객체에서 사용하며, analyzer 객체는 아래 경우에 생성된다.

• 인덱스가 생성될 때

• 노드가 재기동할 때

• 인덱스가 close된 후 open될 때

– 따라서 동의어를 갱신하려면,

• 동의어 파일 수정 후,

• 인덱스 close, then open또는 클러스터의 모든 노드 재기동

– 동의어를 갱신하더라도,

• 색인 시점에 동의어를 사용했다면, 기존에 생성된 인덱스는 갱신된 동의어를 반영하지 못한다.

• 갱신된 동의어에 따라, 인덱스를 재성성해야 한다.

• 동의어 갱신이 빈번하게 발생하고 검색 시간이 덜 중요하다면, 검색 시점에 동의어를 사용한다

Expand or Contract색인 시점 vs. 검색 시점

단순 확장(Simple Expansion)

각 단어는, 나열된 모든 단어로 동의어 확장된다

단순 확장은색인 시점 또는 검색 시점에 확장할 수 있다

항목 색인 시점 동의어 확장 검색 시점 동의어 확장

인덱스크기

커진다 변함 없다

Relevance모든 동의어가 동일한 IDF를 가진다 DF(Document Frequency)가 높은 단어와 낮은단어가 동의어라면, 모두 같은 weight를 가진다

변한 없다 각 동의어는 자신만의 IDF를 가진다

검색성능

쿼리 문자열에 기술된 단일 term만을 찾는다쿼리 문자열에 기술된 term의 모든 동의어를 찾는다 검색 성능 감소

유연성

동의어를 갱신하더라도, 기존에 색인된 문서는 변경도지 않는다. 갱신된 동의어를 적용하려면, 기존 문서를 다시색인해야 한다

기존 문서를 다시 색인하지 않고도, 동의어를 갱신하고 바로 반영된다

단순 축약(Simple Contraction)

각 단어는, 동일한 동의어로 축약된다

따라서 축약 규칙을 사용할 경우에는,색인 시점과 검색 시점 양쪽에 동의어 필터를 적용해야 한다

항목 단순 축약

인덱스크기

변함 없다

Relevance모든 동의어가 동일한 IDF를 가진다 DF(Document Frequency)가 높은 단어와 낮은단어가 동의어라면, 모두 같은 weight를 가진다

검색성능

쿼리 문자열에 기술된 단일 term만을 찾는다

유연성기존 문서를 다시 색인하지 않고도, 동의어를 갱신하고 바로 반영된다

– 동의어 갱신하기

• bound 동의어가 추가된 경우, 규칙 좌측에 추가 후 검색 시점에 동의어 필터 적용

• 기존에 색인된 문서에 새로운 동의어를 반영하려면, 규칙 우측에도 동의어를 추가

또는 규칙 좌측에 동의어 추가한 후 기존 문서를 새로 색인

references

• Synonymshttp://www.elastic.co/guide/en/elasticsearch/guide/current/synonyms.html

• Using Stopwods# updating stopwardshttp://www.elastic.co/guide/en/elasticsearch/guide/current/using-stopwords.html#updating-stopwords

http://www.elastic.co/guide/en/elasticsearch/guide/current/synonyms.html

http://www.elastic.co/guide/en/elasticsearch/guide/current/using-stopwords.html#updating-stopwords

discoverywith zookeeper

Zen discovery

zen discovery

• 목적

– 노드 바인딩 / 해제

• 데이터 통신을 위한 9300 포트가 열려 있다면, elasticsearch 노드를 기동하면 자동으로 클러스터에 바인딩 된다

• 마스터 노드에서 나머지 노드로 ping을 보내서 상태를 체크

– 마스터 노드 선출

• 마스터 노드에 장애가 생기는 경우 마스터 노드 선출

• 나머지 노드에서 마스터 노드로 ping을 보내 마스터 노드 상태를 체크

• ping 방식

– multicast

• 클러스터 내의 모든 노드로 멀티캐스트 전송

• multicast 방식이 사용 불가능하거나 제한을 하려면 unicast 방식을 사용

– unicast

• 각 노드간 discovery.zen.ping.unicast.hosts에 등록된 노드를 통해 1대1 ping

configuration

• discovery.zen.fd.ping_timeout

– ping을 전송 후 장애 여부 판단한 시간(초)

– 기본 값: 3s

• discovery.zen.minimum_master_nodes

– 실행중인 최소 마스터 노드 개수

– node.master를 true로 설정한 노드 개수 대비 quorum으로 설정

• discovery.zen.ping.multicast.enabled

– unicast를 사용할 경우 false로 설정

• discovery.zen.ping.unicast.hosts

– unicast를 호스팅할 노드를 지정

– 마스터 노드 IP 또는 hostname을 설정

zookeeper plugin

zookeeper discovery

• zookeeper를 discovery 프로토콜로 사용

– discovery.typecom.sonian.elasticsearch.zookeeper.discovery.ZooKeeperDiscoveryModule

– sonian.elasticsearch.zookeeper.settings.enabledtrue

– sonian.elasticsearch.zookeeper.client.hostzookeeper 노드를 콤마(,)를 구분자로 등록

– sonian.elasticsearch.zookeeper.discovery.state_publishing.enabledtruetrue로 설정하면, 마스터에서 나머지 노드로 클러스터 상태를 전송하는 대신, zookeper에 상태 변화가 있는 경우에 노드에서 상태정보를 read 한다

• 주요 내용

– 마스터 선출하나의 마스터만이 선출되어 실행

참고자료

• 9 Tips on ElasticSearch Configuration for High Performancehttps://www.loggly.com/blog/nine-tips-configuring-elasticsearch-for-high-performance/

• grmblfrz/elasticsearch-zookeeper githubhttps://github.com/grmblfrz/elasticsearch-zookeeper

• elasticsarch-zookper groups threadhttps://groups.google.com/forum/#!msg/elasticsearch-zookeeper/vJ_Uj38Q6Ng/RiDwXC3nYS0J

https://www.loggly.com/blog/nine-tips-configuring-elasticsearch-for-high-performance/

https://github.com/grmblfrz/elasticsearch-zookeeper

https://groups.google.com/forum/#!msg/elasticsearch-zookeeper/vJ_Uj38Q6Ng/RiDwXC3nYS0J

performance

- case study -

Elasticsearch Refresh Interval vs. Indexing Performance

http://blog.sematext.com/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/

date: 2013. 7. 8version: 0.90.0

http://blog.sematext.com/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/

refresh?

• document를 index를 하면 바로 search가 되지는 않는다

• index를 refresh한 후에야 search가 가능하다.

• refresh는 expensive operation

• refresh 주기

– 설정: index.refresh_interval

– 기본값: 1s

• refresh 주기를 늘리면, indexing throughput을 높일 수 있다

– refresh에 쓰이는 자원을 indexing에 사용할 수 있으므로

Test Condition

• hardware

– m1.small Amazon EC2 instance X 3대

• data

– source: apache logs

• index

– 1 index

– 3 shards

– 1 replica

– bulk size: 3,000 X 2 threads

Test Condition

• performance tuning

– index.store.type: mmapfs

– indices.memory.index_buffer_size: 30% (default: 10%)

– index.translog.flush_threshold_ops: 50,000 (defauult: 5,000)

• 측정 값

– 30분간 indexing 후 indexing한 document 개수

Test Result

refresh_interval # of index docs / 30min docs / sec Performance lift(%)

1s 3.6M 2.0K 0%

5s 4.5M 2.5K 25%

30s 6.1M 3.4K 70%

• 기타 측정치

– refresh_interval을 높이더라도, CPU, Disk I/O, 메모리, JVM GC는 크게 변하지 않음

• 결과 분석: indexing 성능 vs. real-time search

– refresh_interval을 늘리면, indexing 성능이 좋아진다

– refresh_interval을 늘리면, search 결과에 refresh되는 시간이 느려진다

[참고] translog

• 좌표

– http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-translog.html

– 각 shard는 index / delete request가 발생하면, 해당 요청을 translog(write ahead log)에 기록한다.

– translog는 여러 파라미터에 따라 주기적으로 내부 Lucence index에 flush(commit)된다

• 파라미터

– index.translog.flush_threshold_ops

• 몇 개의 request가 온 후 flush 할 것인가? (default: unlimited)

– index.translog.flush_threshold_size

• size가 얼마나 되면 flush 할 것인가? (default: 200mb)

– index.translog.flush_threshold_period

• flush가 얼마 동안 일어나지 않으면 flush 할 것인가? (default: 30m)

– index.translog.interval

• flush 필요 여부를 얼마나 자주 체크할 것인가? (default: 5s)

• interval과 interval X 2 시간을 주기로 체크한다

– index.gateway.local.sync

• How often the translog is fsynced to disk? Defaults to 5s.

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-translog.html

Elasticsearch Performance Characteristics on Joyent and Amazon

EC2https://www.joyent.com/content/02-public-cloud/02-benchmarks/01-elasticsearch/elasticsearch-

benchmark.pdf

date: 최근??version: 최신??

https://www.joyent.com/content/02-public-cloud/02-benchmarks/01-elasticsearch/elasticsearch-benchmark.pdf

Search Performance

• Joyent사에서 elasticsearch를 실행할 때 자사의 clouding platform이 AWS보다뛰어나다는 것을 보여주기 위해 만든 자료

• hardware

– Joyent

– AWS

• Data

– indexed 위키피디아 웹 페이지: 14,039,804개

Node CPU Memory

3 2core 8GB

Node CPU Memory

3 2core 7.5GB

Search Performance

• 측정 결과

indexing performance tips

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/indexing-performance.html

date: recentversion: 1.3+

performance considerations for elasticsearch indexing

http://www.elasticsearch.org/blog/performance-considerations-elasticsearch-indexing/

http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/indexing-performance.html

http://www.elasticsearch.org/blog/performance-considerations-elasticsearch-indexing/

indexing performance tips

• when to use

– indexing > search

– indexing 해야 하는 데이터는 많은 대신, search는 많이 발생하지 않거나, 내부 사용자인 경우

– search 속도를 늘리는 대신 indexing throughput을 늘리자

• how to test performance

– 과학적으로 성능을 측정하라

– bulk request를 사용하라. 그리고 최적의 bulk size를 찾아라

– storage

– segment & merging

– 나머지 것들

과학적으로 성능을 측정하라

• 단일 노드, 단일 shard, replica 없이 성능을 측정한다

• 100% default 설정에서 성능을 측정한 후, 비교할 baseline으로 삼는다

• 60분 이상 측정하라

– segment merging, GC, shard movement, OS IO caching은 단시간에는 발생하지않을 수도 있다

• baseline 설정에서 단일 속성만을 변경한다

– 단일 속성을 조금씩 변경하면서 성능을 측정한다.

– 최적값을 찾은 후 다음 속성을 변경한다.

bulk request를 사용하라. 그리고 최적의 bulk size를 찾아라

• bulk index request를 사용한다. 중요한 일은 bulk size를 찾는 일!

– bulk request는 coordinating node의 메모리에 모두 로드 되어야 한다

– 5 ~ 15MB를 시작점으로 잡고, 성능이 높아지지 않을 때까지 bulk size를 높여 나간다

– EsRejectedExecutionException(java clinet의 경우), TOO_MANY_REQUESTS (429) HTTP response(rest API의 경우)가 발생하면 너무 많은 cocurrent request를 요청한다는 뜻이다

storage

• SSD를 사용하자

• striping을 사용하자(replica에서 데이터 복구 능력을 제공한다

– RAID 0(striping)를 사용하자

– 또는 다수의 디스크 드라이브를 사용하자

• 다수의 path.data 설정을 통해 elasticsearch 자체적으로 striping을 하도록 하자

• remote-mounted 스토리지(NFS, SMB/CIFS 등)를 사용하지 말고, 로컬 스토리지를 사용하라

• 가상 스토리지(virtual storage) 사용을 주의하라

– AWS EC2를 사용한다면, EBS를 주의하라. SSD 기반의 EBS라 하더라도 로컬 인스턴스 스토리지보다 느릴 때가 많다.

segment merging

• segment merging throttling

– segment merging은 자원이 많이 들며, 최악의 경우 Disk I/O를 모두 소모하게 되어search가 아예 불가능할 수 있다.

– 새로운 document가 index되고 새로운 segment가 생성되는 속도에 비해, segment를 merge하는 속도가 느린 경우

• 새로운 segment가 폭발적으로 증가하며

• 이를 방지하기 위해 segment merging 프로세스는 더 많은 Disk I/O를 소모하게 된다.

• 하지만 segment merging이 발생하더라도 search 성능에는 영향을 주지 않도록, merging에서 사용할 수 있는 Disk I/O를 throttling을 통해 제약한다

• throttling은 indices.store.throttle.max_bytes_per_sec 속성을 통해 설정 가능

– default: 20MB/s

• merging을 동시에 실행할 thread 개수도 index.merge.scheduler.max_thread_count 속성을통해 설정 가능

– default: Math.min(3, Runtime.getRuntime().availableProcessors() / 2)

– 설정한 값 + 2개 만큼의 merge thread가 실행

segment merging

• HDD vs. SSD

– HDD

• indices.store.throttle.max_bytes_per_sec : 20mb/sec (default)

• index.merge.scheduler.max_thread_count : 1

– SSD

• indices.store.throttle.max_bytes_per_sec : 100 ~ 200mb/sec

• index.merge.scheduler.max_thread_count : default

• throttle type

– bulk index와 같이 search가 중요하지 않은 경우라면 indices.store.throttle.type을“none”으로 설정하여 throttling을 disable한다

• default: “merge”

• translog size

– index.translog.flush_threshold_size 속성을 통해 translog의 flush size를 1GB로 높인다 (default: 200MB)

– translog size가 크면 translog가 flush될 때 새롭게 생성되는 segment size가 커지므로 segment merge가 더 드물게 발생핟나.

나머지 것들

• index.refresh_interval

– 검색시 검색 결과에 대해 near real-time 정확도가 필요하지 않다면index.refresh_interval을 30s로 높여라 (default: 1s)

– search가 없는 상태에서 대량의 데이터를 indexing하려면, index.refresh_interval을-1로 설정하여 refresh를 disable하자

• index.number_of_replicas

– 대량의 bulk import를 하려면, index.number_of_replicas를 0으로 설정하라

– replica는 full indexing 프로세스(analyzing, indexing, merging)를 통해 만들어진다

– 따라서 index.number_of_replicas를 0으로 설정한 후 indexing이 끝났을 때 replica를 enable하게 되면(optimize한 후), recovery 프로세스에서는 단순히 indexing이 끝난 document를 네트워크를 통해 전달하게 된다

• doc ID

– document ID를 직접 unique하게 부여할 수 없다면, 자동 생성되도록 하라

– 자동 생성된 ID는 version lookup이 발생하지 않는다

나머지 것들

• mapping에서 필요 없는 부분은 disable 하라

– _all

• 검색시 필드를 반드시 지정해야 한다면 _all 필드는 불필요

– store

• _source를 사용한다면 불필요(default: false)

– index

• no: search가 불필요한 필드라면

• not_analyzed: search는 하나 필드에 대한 analyzing은 불필요한 필드라면

• analyzed: default

• 특별한 이유가 없다면 _source 필드는 enable 하라

– 단순히 원본 JSON을 저장할 뿐이므로 indexing 성능 저하는 거의 없다

– storage가 부족하다면 storage를 늘린다. 디스크는 싸다

• index.translog.flush_threshold_size를 1gb로 늘려라

• default: 200mb

– 대량의 데이터를 indexing한다면 active shard당 indices.memory.index_buffer_size가 최대 512MB가 되도록 하라

• default: 10%

• 예를 들어 JAVA_HEAP_SIZE가 25GB이고, active shard가 5대라면

– shard당 25GB X 0.1 / 5 = 512MB가 할당될 수 있다

성능 향상을 위한 메모리 tip

virtual memory

• 가상 메모리의 mmap count를 충분히 늘린다

– 리눅스에서 elasticsearch는 인덱스를 기본적으로 hybrid mmapfs / niofs 파일 시스템을 이용하여 저장한다.

– OS의 기본적으로 mmap count가 낮아, momory가 부족할 수 있다.

– vm.max_map_count를 충분히 늘린다

– 예) sysctl -w vm.max_map_count=262144

memory settings

• swap이 발생하지 않도록 한다

– linux kernel은 어플리케이션에서 오랫동안 사용하지 않는 메모리를 swap하며, 이는elasticsearch의 성능을 저하시킨다. swap이 발생하지 않도록 설정한다.

• 영구적으로 swap off

– elasticsearch의 ES_HEAP_SIZE 설정을 통해 메모리를 관리하며, 전용 머신에서는 elasticsearch 이외의 서비스는 없을 것이다.

– 따라서 swap을 아예 영구적으로 off한다.

– /etc/fstab 파일에서 swap 단어를 포함하는 라인을 모두 주석 처리한다.

• swappiness

– vm.swappiness을 0으로 설정한다.

– 예) sysctl –w vm.swappiness=0

– normal 상황에서는 swap이 발생하지 않고, emergency 조건에서의 swap 발생은 허용한다.

– 리눅스 커널 3.5-rc1 버전 이상에서는 0으로 설정한 경우, OOM(Out Of Memory) killer는 swap을 하는 대신 프로세스를 kill하게 된다. 이 경우 emergency 상황에서는 swap을 허용하도록, swappiness를 1로 설정한다

• mlockall

– 프로세스에서 사용하는 메모리에 lock을 걸도록 시도한다(실패할 수 있다)

» elasticsearch 프로세스가 lock 권한이 없는 경우ulimit -l unlimited

» temporary directory가 noexec 옵션으로 마운트 된 경우(임시 디렉토리 재설정)./bin/elasticsearch -Djna.tmpdir=/path/to/new/dir

– config/elasticsearch.yml 파일에서 bootstrap.mlockall 속성을 true로 설정한다.

– 주의) 가용 메모리보다 더 많은 메모리를 할당하려고 하는 경우 JVM 또는 shell session이 exit할 수도있다

memory settings

• Java Heap size를 RAM의 50%를 넘지 마라

– OS에서 IO caching을 할 수 있도록 RAM을 충분히 남겨 둘 것

[참고] index.store.type: file system storage types

• 좌표

– http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-store.html

종류 특성

simple fs- Lucene: SimpleFsDirectory- random access file 사용- poor concurrent performance

nio fs

- Lucene: NIOFSDirectory- NIO 사용- better performance than simple fs- SUN Java 구현체(Java NIO)의 버그로 Window에서는 사용하지 말 것

mmap fs- Lucene: MMapDirectory- meory map 사용- 가상 메모리에서 사용할 수 있는 mmap count 늘려서 사용할 것

hybrid mmap / nio fs

- mmap: Lucene term dictionary와 doc 값- nio fs: 나머지- 가상 메모리에서 사용할 수 있는 mmap count 늘려서 사용할 것- default store type on linux

memoryLucene: RamIndexStore- 주 메모리 사용

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-store.html

[참고] indexing buffer size

• 좌표

– http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-indices.html

• 속성

– indices.memory.index_buffer_size

• indexing process에 할당할 메모리 사이즈

• 비율(%) 또는 사이즈(byte) 단위로 설정 가능

• default: 10%

– indices.memory.min_index_buffer_size

• 비율(%)로 설정한 경우에만 설정 가능

• default: 48mb

– indices.memory.max_index_buffer_size

• 비율(%)로 설정한 경우에만 설정 가능

– indices.memory.min_shard_index_buffer_size

• shard별 할당 가능한 최소 메모리 설정

• default: 4mb

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-indices.html

[참고] mapping’s _source

• _source

– default: true

– indexing한 원본 JSON 문자열을 document에 자동으로 _source 필드에 저장

– retrieve & search시 리턴되는 document에 포함됨

– 검색 결과에서 원본 데이터를 보고자 한다면 enable 해야 함

– 성능을 향상하고 storage를 줄이고자 한다면 disable 할 수 있으나 큰 성능 향상은 없음

– _source에 포함/제외하려는 필드를 지정할 수 있음

[참고] mapping’s _all

• _all

– default: true

– indexing한 document의 모든(또는 지정한 일부) 필드에 대한 텍스트를 포함하고 있으며 search가 가능

– 검색시 필드를 지정하지 않고 검색하는 경우 _all 필드에 대해 검색이 수행됨

– 사용하지 않는 다면 disable(또는 꼭 필요한 필드만 enable)하여 indexing 성능을 향상시키고, 사용되는 storage를 줄일 수 있다

– disable한 경우라면, 디폴트 검색 필드를 재설정한다

• index.query.default_field: default는 _alll

[참고] mapping’s store & index

• mapping’s store & index

– store

• field의 indexing 되기 전의 원본 값 저장 여부

• default: false

• _source를 disable한 경우에만 유용

– index

• indexing할 때 field에 대한 analyze 적용 여부

• default: analyzed

• not_analyzed: searchable but not analyze

• no: not searchable

• store vs. _source

– 특정 필드에 대해서만 원본 필드를 저장하려면필드별로 store를 enable할 것인가? vs_source에 필드를 지정할 것인가?

_source를 사용하라

(store의 경우 필드별로 disk seek이 각각 발생하나, _source의 경우 단 한번만 발생)http://stackoverflow.com/questions/17103047/why-do-i-need-storeyes-in-elasticsearch

http://stackoverflow.com/questions/17103047/why-do-i-need-storeyes-in-elasticsearch

Check list 101

설정 항목

elasticsearch_적용 및 활용_정리

Technology

Transcript of elasticsearch_적용 및 활용_정리