2. 목차
• 개요
– 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
3. 목차
• distributed nature
– life inside a cluster
– distributed document store
– distributed search execution
– inside a shard
4. 목차
• 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
5. 목차
– 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 성능 향상을 위한 조언
6. 목차
– aggregation : significant terms
• uncommonly common data
• 개요
– goal
– significant aggregation이란?
– 응용 분야
• 사례 : 영화 추천기
– 요구사항
– 사용할 전략 2가지
– 데이터 구조
– popularity를 기준으로 영화 추천하기
» 문제점
– statistic를 기준으로 영화 추천하기
» 추천이 예상되는 영화 목록
» significant terms aggregation
» 결과 분석
8. 목차
• partial matching
– structured search
– full-text search
– partial matching
– autocomplete
• Using Synonyms
– Using Synonyms
– Expand or Contract
9. 목차
• 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
12. 개요
• 분산 환경의 문서 지향(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
저장
검색
분석
13. 개요
• 버전
– 문서 버전 : 1.4.0
– 설치 버전 : 1.4.2
• license : Apache 2
14. 설치
• cluster 명 변경하기
– {$ELASTICSEARCH_HOME}/config/elasticsearch.yml 파일의 cluster.name 속성을
변경
15. 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
• 설치하기
18. 사례 : We love our drones!
• Megacorp회사의 직원 데이터 관리하기
• 요구사항
– 데이터는 다수의 태그(tag), 숫자, full-text(전문)을 저장해야 한다
– 각 직원의 상세 정보를 조회(retrieve)할 수 있어야 한다
– structured search를 지원해야 한다
• 예) 30세 이상의 직원 목록 검색
– full-text search와 phrase search(구문 검색)을 지원해야 한다
– 검색된 문서에서 매칭된 부분(snippet)은 하이라이트(highlight) 해야 한다
– 데이터에 대한 분석 대시보드(analytic dashboard)를 만들 수 있어야 한다
19. 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
21. searching : basics
• 기본 문법
• string search
• query DSL search
select *
from employee
where last_name = “Smith”
sql 비교
22. searching : filtered search
• narrowing query target
select *
from employee
where age > 30
and last_name = “Smith”
sql 비교
23. 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 employee
where match(about) against(‘rock
climbing’)
sql 비교
24. searching : phrase search
• exact match for phrase
– analyze한 필드에 대해 full-text search가 아니라, 구문 전체를 반드시 포함한
document를 검색한다
select *
from employee
where match(about) against(‘”rock
climbing”’ in boolean mode)
sql 비교
26. 동시성 제어 : 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
27. 동시성 제어 : Optimistic concurrency control
• retry on conflict occurred
– 충돌 발생시, 해당 충돌을 retry해도 되는 상황(네트워크 일시 단절)이라면, 자동으로
retry하여 충돌을 해결할 수 있다
30. avoiding network overhead
• 문서를 retrieving하거나 indexing할 때, 문서를 하나씩 주고받기 보다는
대량의 문서를 한꺼번에 주고받음으로써 NIO를 줄일 수 있다
– mget for retrieving
– bulk for create / index / update / delete
• bulk size 정하기
– bulk 요청을 처리하려면 bulk 요청에 포함된 데이터를 모두 메모리로 로드해야 함
– bulk size별로 성능을 측정하여, 최적의 size를 결정
– 5~15MB부터 시작하여 성능 측정하면 좋을 것
37. 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들의 집합
38. 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 보장
39. 1 replica
• 3개의 primary shard와 1개의 replica로 구성된 > 1개의 index를 가진 > 2개의
node로 구성된 1개의 cluster
40. scale out – shard reallocation
• 3개의 primary shard와 1개의 replica로 구성된 > 1개의 index를 가진 > 3개의
node로 구성된 1개의 cluster
– shard는 새로운 노드로 재할당되어, 새로 추가된 computing power를 완전히 활용할
수 있게 된다
41. 2 replica
• 3개의 primary shard와 2개의 replica로 구성된 > 1개의 index를 가진 > 3개의
node로 구성된 1개의 cluster
42. recovery on failure
• 3개의 primary shard와 2개의 replica로 구성된 > 1개의 index를 가진 > 2개의
node로 구성된 1개의 cluster
– master node 1이 shutdown된 경우,
• primary node selection
– node 2가 새로운 primary node가 된다
• recovering primary shard
– node 1에 위치한 primary shard 1, 2가 사라짐
– replica node를 새로운 primary shard로 지정
44. • 라우팅(routing)
– 문서를 인덱스에 저장할 때 인덱스의 어느 primary shard에 저장할지 결정해야 함
– 이때 라우팅(routing) 값을 이용한다.
– default: 문서의 _id
• 임의의 문자열을 설정 가능
– 저장할 primary shard 번호는 아래의 규칙에 따라 결정된다.
shard = hash(routing) % number_of_primary_shards
* number_of_primary_shads: 해당 인덱스의 primary shard 개수
routing: 문서를 저장할 샤드 정하기
45. searching
• 2개의 primary shard와 2개의 replica로 구성된 > 1개의 index를 가진 > 3개의
node로 구성된 1개의 cluster
– client node에서는 모든 노드에게 검색 요청을 할 수 있으며, 요청을 받은 노드
(requesting node)는 요청을 자체적으로 처리할 수 있다
client node
46. 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 응답을 보낸다
47. retrieving a document
• shard 0에 대한 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를 리턴한다
48. partial update to 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에서 reindex가 완료된 후 처리 success 응답을 node 3으로 보내면,
node 3은 requesting node(node 1)로 success 응답을 보낸다.
– 5. node 1은 클라이언트에게 success 응답을 보낸다
49. [노트] document 기반 replication
• replication은 document 기반으로 동작한다
– 새로운 문서를 추가시
• primary shard에서 index가 끝나면, replica shard로 index된 문서가 아닌 새로운 document
를 index 요청을 전송한다.
– 문서를 수정시
• primary shard에서 index가 끝나면, replica shard로 수정 요청이 아닌 새로운 document를
reindex 요청을 전송한다.
50. 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은 결과를 취합하여 클라이
언트로 전송한다
51. 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 응답을 보낸다
53. 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를 가져와서
클라이언트로 리턴한다
54. 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를 만든다
55. fetch phase
• fetch
– 1. coordinating node(node 3)는 전역 sorted list로부터 가져올 document를 식별한
후, mget 요청을 관련된 shard로 전달한다.
– 2. 각 shard는 mget을 요청에 대한 document를 coordination node로 전달한다.
– 3. 모든 document가 전달되면, coordinating node는 document를 클라이언트로 전
달한다.
56. [주의] deep pagination
• deep pagination
– size가 너무 크거나 from이 너무 큰 경우 문제가 될 수 있다
– 예를 들어 총 검색 요청과 관련된 shard가 총 5개이고, 검색 결과는 10개만 가져오는
경우를 보자. 이 중 1페이지를 가져오는 경우,
• 각 shard가 있는 노드에서 문서를 scoring한 후 정렬하여 각각 10개의 문서를 리턴한다.
• coordinating node는 반환된 총 50개의 문서를 재정렬한 후 10개의 문서를 리턴한다
57. [주의] 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 페이지 이상은
제공하지 않는다.
59. flush, refresh, optimize
• elasticsearch에서
– search는 near real-time: indexing한 document를 기본적으로 1s 이후 search 가능
– CRUD는 real-time
– data persistence를 보장
– delete operation을 하더라도 disk가 바로 해제되지 않음
• Why?
– refresh
– flush
– optimize
60. 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가 가능하게 되는 주기가 길다
61. 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
64. dynamically updatable indices
• 새로운 document가 들어오면
– 2. 주기적으로, buffer는 commit된다
• 새로운 segment가 생성된 후 disk에 write된다.
• 새로운 commit point가 disk에 기록된다.
이 목록에 새로운 segment 이름이 추가된다
• disk가 fsync된다.
– 파일시스템 캐시에 있는 모든 데이터가 물리적으로 disk에 flush된다
– 새로운 document는 search가 가능해진다
65. dynamically updatable indices
• delete / update a document
– document를 삭제하거나 수정할 경우, index를 수정하지 않는다(immutable)
– 대신, .del 파일에 삭제/수정된 파일을 “deleted”로 표시한다.
– 검색시, 매칭은 되지만 클라이언트로 리턴되지는 않는다
– purge a document
• segment가 merge될 때, “deleted”로 표시된 파일을 disk에서 영구적으로 삭제한다
66. 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) 되지 않은 상태
67. near real-time search
• refresh
– full commit(fsync를 포함하는)이 아니라, 새로운 segment를 열고 search만 가능하
도록 만드는 operation
– elasticsearch는 주기적으로(default: 1s) refresh를 실행
• 1s마다 새로운 segment가 생성됨
– refresh_interval 속성으로 설정 가능
• 기본적으로 1s 이내에는 새로운 document가 search가 가능해짐
– 직접 refresh를 실행하려면
68. making changes persistent
• fsync가 실패한다면?
– 파일시스템 캐시에 저장된 새로운 segment는 commit point에 기록되지 않고,
physical 디스크에 저장되지 않았으므로 데이터가 사라진다
translog를 사용하여 indexing operation을 기록하자
• document가 indexing되면 in-memory buffer와 translog 모두에 기록된다
69. making changes persistent
• translog를 사용하여 indexing operation을 기록하자
• 주기적으로 refresh가 발생하면
– in-memory buffer에 기록된 새로운 document는 새로운 segment로 만들어지고 search가 가능
(fsync는 발생하지 않음)
– in-memory buffer는 비워진다
70. making changes persistent
• translog를 사용하여 indexing operation을 기록하자
• 또다시 새로운 문서가 들어오고 indexing이 되면
– in-memory buffer와 translog에 기록된다
(translog는 이전의 기록을 함께 유지한 상태)
71. making changes persistent
• translog를 사용하여 indexing operation을 기록하자
• translog가 충분히 커지면 주기적으로 flush가 발생하여
– in-memory buffer에 기록된 새로운 document는 새로운 segment로 만들어지고 search가 가능하며,
in-memory buffer는 비워진다
– 새로운 commit point가 기록된다
– 파일 시스템 캐시는 fsync를 통해 physical 디스크로 flush된다
– translog는 비워진다.
72. • 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 분량의 데이터는 소실될 가능성은 있다
making changes persistent
73. • refresh를 통해
– near real-time search는 가능하지만
– 1s 단위로 새로운 segment가 생성되며, segment는 시간이 지나면서 기하급수적으로
증가
백그라운드에서 segment를 병합하자
• indexing이 되면, refresh 프로세스에서는 새로운 segment를 열고 search가 가능하게 한다
• merge 프로세스에서 비슷한 크기의 segment를 병합하여 좀 더 큰 새로운 segment를 생성
한다
(이때 “deleted”로 표시된 document는 새로운 segment를 병합할 때 포함되지 않고 완전히
삭제된다)
segment merging
74. • segment merging이 끝나면
– 새로운 segment가 disk로 flush된다.
– 새로운 commit point가 기록된다. 이때 병합된 이전의 segment는 지워지고, 새로운
segment가 기록된다
– 새로운 segment가 open되어 search가 가능해진다
– 이전의 segment는 삭제된다
segment merging
75. • 성능 이슈
– 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
76. references
• elasticsearch the definitive guide
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/index.ht
ml
79. aggregation 개요
• 개요
– near-real time analytic 도구
– 리포팅 및 대시보드 생성에 적합
– 실시간 데이터 visualization
• 분류
aggregation basics min
max
avg
etc
approximation cardinality
percentile
significant terms
80. buckets & metrics
• buckets
– criteria를 만족하는 document 집합
– partitioning(grouping) documents based on criteria
• metrics
– 우리가 알고 싶은 정보
– bucket에 포함된 document에 대한 statistics(min, max, avg, var, …)
81. 사례 : Car Transaction
• sample data를 bulk indexing하기
– transactions
• price : 자동차 가격
• color : 자동차 색상
• make : 자동차 제조사
• sold : 팔린 날짜(yyyy-mm-dd)
82. 기본 문법
• aggregation 기본 문법 : terms bucket
select color, count(*) as colors
from cars
group by color
sql 비교
83. 기본 문법
• bucket의 metric 구하기
select color,
avg(price) as avg_price
from cars
group by color
sql 비교
84. nested buckets
select color,
avg(price) as avg_price
from cars
group by color
and
select color, make, count(*)
from cars
group by color, make
sql 비교
• nested buckets
85. nested buckets
• nested buckets and metrics
select color,
avg(price) as avg_price
from cars
group by color
and
select color, make,
min_price(price) as min_price,
max_price(price) as max_price
from cars
group by color, make
sql 비교
88. visualization : bar chart 1
• histogram bucket을 사용하여 bar chart 만들기
– goal : 가격 구간대별 가장 많이 팔린 제조사 찾기
– bucket : “price” 필드에 대해, 20,000 interval을 기준으로 histogram bucket
– metric : 가장 많이 팔린(size = 1) “make” 찾기
90. visualization : bar chart 2
• terms bucket을 사용하여 bar chart 만들기
– goal : 자동차 제조사별 평균가격 구하기
– bucket : terms bucket on “make”
– metric : extended_stats on “price”
92. visualization : time series
• date_histogram bucket을 사용하여 time series 만들기
– goal : 월별 팔린 자동차 대수 구하기
– bucket : “sort” 필드에 대해, “month” interval을 기준으로 date-histogram bucket
94. • date_histogram bucket을 사용하여 time series 만들기
– goal : 월별 팔린 자동차 대수 구하기
(단, 날짜 구간을 설정하고, 결과가 0인 월의 데이터도 생성)
– bucket : “sort” 필드에 대해, “month” interval을 기준으로 date-histogram bucket
visualization : time series refined
99. • scope of aggregation on filtered query
– filtered query인 경우에도, filtered query scope를 기반으로 aggregation이 실행
scoping & filtering
* kibana 4beta3 does not support filter yet
100. • filtered bucket
– search scope는 그대로 둔 채, aggregation scope에 대해서만 filtering
scoping & filtering
101. • query scope인 경우
• filtered query scope인 경우
scoping & filtering
query aggregation
*
docs
matched
docs
metrics
per buckets
filtered
query
aggregation
filtered
docs
matched
docs
metrics
per buckets
102. • filtered bucket인 경우
scoping & filtering
query
filtered
aggregation
*
docs
matched docs
metrics
per buckets
filtered
docs
103. • post filter
– when to use
• 예를 들어, ford 제조사의 월별 판매량과 판매 목록을 보여주는 화면이 있고
• 사용자에게 ford의 색상별로 자동차 판매 목록(subset)을 볼 수 있는 기능을 제공해야 하는
경우
• 즉 상위 subset에 대한 목록과 aggregation을 보여준 채로, 하위 subset에 대한 목록을 선택
적으로 보여줘야 하는 경우
• 동일한 scope에서 상위 목록과 aggregation을 실행한 후,
• 해당 scope에 대해 post filter를 적용하여 하위 목록을 조회한다
scoping & filtering
query aggregation
*
docs
matched
docs
metrics
per buckets
filtered
docs
post filter
105. – 성능 고려 사항
• 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
106. • default sort : doc_count desc
• intrinsic sort : according to buckets’ nature
sorting
select color, count(*) as colors
from cars
group by color
order by colors asc
sql 비교
107. • sorting by metrics
sorting
select color,
avg(price) as avg_price
from cars
group by color
order by avg_price asc
sql 비교
108. • sorting by deep metrics on nested buckets
sorting
110. • 한계
– 결과의 정확성(exactness), big data 처리, real-time 응답을 모두 만족할 수는 없다
– 빅데이터 환경에서 실시간 응답성을 만족해야 한다면, 정확성은 어느 정도 희생해야
한다
real-time analytics on big data
Exact
Big
Data
Real
Time
111. • ER(Exact – Real-time)
– 단일 머신에서 알고리즘을 실행 가능한 경우
• 예) RDBMS
– aggregation 결과는 100% 정확하며, 실시간 응답성을 보장한다
real-time analytics on big data
Exact
Big
Data
Real
Time
112. • EB(Exact – Big data)
– 단일 머신에서 알고리즘을 실행할 수 없을 정도로 데이터가 큰 경우, 실시간 응답성을
희생
• 예) Hadoop M/R
– PB급 데이터에 대해 정확한 aggregation 결과를 낼 수 있으나, 응답이 느리다
real-time analytics on big data
Exact
Big
Data
Real
Time
113. • BR(Big data – Real-time)
– 단일 머신에서 알고리즘을 실행할 수 없을 정도로 데이터가 큰 경우
– 실시간 응답성을 만족하기 위해 정확도를 어느정도 희생
• 예) elasticsearch approximation aggregation
– aggregation 결과는 accurate, but not exact
real-time analytics on big data
Exact
Big
Data
Real
Time
115. cardinality
• when to use
– finding distinct or unique values
• to answer following questions
• 웹사이트 UV가 얼마인가?
• 얼마나 많은 unique 자동차가 팔렸나?
• 매달 구매자 중 unique buyers는 몇 명인가
– 예) 팔린 자동차 중, unique한 색상은 몇 가지인가?
117. HLL algorithm
• HyperLogLog++(HLL) algorithm
– elasticserach의 cardinality approximation은 HyperLogLog++(HLL) algorithm을 기
반
– HyperLogLog++(HLL) algorithm의 특징
• 정확도(precision) 설정 가능
단, 정확도를 올릴 수록, 메모리 사용량이 증가
• cardinality가 낮은 집합일 수록 정확도가 높아진다
• 메모리 사용량이 고정적
• 메모리 사용량은 정확도에만 비례
118. 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)
119. cardinality approximation 성능 향상을 위한 조언
• HLL은 hash field의 hash값을 이용한다
• HLL은 충분히 빠르나, 더 빠르게 만들고자 한다면, query time이 아닌 index
time에 hash를 미리 만들어 둔다
– 단 numeric value나 string이 짧은 경우는 무의미
– cardinality가 크거나 string이 긴 경우만, hash 값을 미리 만드는 게 효과적
120. percentiles
• when to use
– finding outliers
• 웹페이지 latency 속도 데이터 중, 상위 10%(가장 오래 걸린)는 어느 정도의 시간이 걸렸나?
– outliers에 의한 insight 왜곡
: 전체 데이터에 대해 평균(mean) 또는 중앙값(median만을 보는 경우
: 아래와 같이 별다른 insight를 도출이 불가능
121. percentiles
• when to use
– 99th percentiles의 데이터에 대해 평균(mean) 또는 중앙값(median)을 보는 경우
– 4:48분경, 9:36분경 2차례에 걸쳐
“1%의 사용자가 300ms, 950ms에 달하는 latency를 경험했다”
는 사실을 발견할 수 있다
122. 사례 : 웹사이트 latency
• sample data bulk indexing
– logs
• latency : 응답시간(ms)
• zon : 서버 존
• timestamp : 발생날짜(yyyy-mm-dd)
123. 사례 : 웹사이트 latency
• latency에 대한 percentiles 구하기
– 75th percentile = 289.75 > 전체 평균 = 200
최소 25% 이상의 사용자가 평균보다 높은 latency를 경험하고 있다
124. 사례 : 웹사이트 latency
• zone별 latency에 대한 percentiles 구하기
125. 사례 : 웹사이트 latency
• zone별 latency에 대한 percentiles 구하기
– US zone
• 50th percentile과 99th percentile이 크게 차이가 나지 않으며, 평균(90)에 가깝다
– EU zone
• 50th percentile과 99th percentile이 크게 차이가 날뿐더러, 50th percentile은 이미 300ms
에 근접한다
• 전체 latency를 늦추는 문제는 EU zone에서 발생하고 있다
126. 사례 : 웹사이트 latency
• percentile ranks
– n’th percentile = 전체 데이터 중 N% 이하가 넘지 않는 최소값 M
– percentile rank of M = M이 속하는 percentile N
– percentile ranks 구하기
127. 사례 : 웹사이트 latency
– US zone
• 210은 100th percentile에 속한다.
• 즉 latency가 210을 넘지 않는다
– EU zone
• 210은 32th percentile에 속한다
만약 SLA 체결시 latency를 210ms을 보장할 것을 약속했다면,
이는 EU의 latency에 대해 32% 시간만을 충족한다고 이야기할 수 있다.
128. TDigest algorithm
• TDigest algorithm
– elasticserach의 percentiles approximation은 TDigest algorithm을 기반
– TDigest algorithm의 특징
• percentile 정확도는 percentile의 값이 아주 크거나, 또는 아주 작을수록 높아진다.
• 어차피 outlier를 포착하기 위한 목적이니 문제가 아니다
• data set이 작을수록 정확도가 높다.
충분히 작다면 100%에 가까워진다
• bucket의 data size가 커질수록 정확도가 낮아진다.
inaccuracy는 정확히 수식화할 순 없다.
• 정확도를 낮추면 메모리 사용량도 적어진다.
129. percentiles approximation 성능 향상을 위한 조언
• TDigest algorithm은 approximation을 할 때 node 구조를 사용한다.
더 많은 node를 사용할 수록,
– 정확도는 높아진다
– 메모리 사용량은 높아진다.
– 처리 속도는 느려진다.
• compression 속성을 이용해서 memory-to-accuracy 비율 설정 가능
– 최대 사용 가능 node 개수 = 20 * compression
– 기본값 : 100
– 대략 한 노드당 32바이트 메모리
– 기본 설정시, 최대 20 * 100 * 32 = 64KB 메모리 사용
131. 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
132. 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 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 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 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 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 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 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
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 A A AA 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
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
AA A A AA A A AA A A AA A A AA A A AA A A AA A A AA A A
A
X X
A 회사의 정상 트랜잭션
D 회사의 정상 트랜잭션
X 회사의 정상 트랜잭션 X 회사의 비정상 트랜잭션
A A 회사의 비정상 트랜잭션
133. uncommonly common data
• 회사별 트랜잭션 비교
– 비정상 트랜잭션이 발생한 빈도(frequency, popularity)만을 기준으로 순위를 매기면
• 회사 A가 카드 사기꾼일 가능성이 가장 높고
• 회사 X는 그 다음이며
• 회사 D는 카드 사기꾼은 전혀 아니다
– 문제는
• 회사 A는 대다수의 트랜잭션이 발생하는 회사로, 굳이 분석하지 않더라도 쉽게 발견 가능
commonly common data
• 회사 D는 트랜잭션이 희박하게 발생하지만, 비정상 트랜잭션은 발생하지 않는다. 이들 회사
가 우리 은행을 사용할 거라고 생각해 본적은 없으나, 카드 사기꾼은 아니다
commonly uncommon data
• 회사 X는 소수의 트랜잭션이 발생하나, 비정상 트랜잭션도 발생하며, 회사 X의 전체 트랜잭
션 대비 그 빈도가 높음
uncommonly common data, 찾으려는 대상
회사 전체 트랜잭션 비정상 트랜잭션 비율 순위
A 528 4
0.735%
(4 / 544)
1
X 13 3
0.551%
(3 / 544)
2
D 3 0 0% 3
134. uncommonly common data
• background vs. foreground
– background : 모집단 데이터(전체 트랜잭션)
• A’s background rate = (A 집단의 개수) / (모집단 데이터)
= (A 집단의 트랜잭션) / (전체 트랜잭션)
– foreground : 관심 데이터(비정상 트랜잭션)
• A’s foreground rate = (관심 데이터 개수) / (관심 집단)
= (A 집단의 비정상 트랜잭션) / (전체 비정상 트랜잭션)
전체 트랜잭션(background)
A 집단
관심 집단
모집단
A집단의 트랜잭션
전체 비정상 트랜잭션(foreground)
A 집단의 비정상 트랜잭션
135. uncommonly common data
• 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
absolute
change
relative
change
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
136. uncommonly common data
• JLH Heuristics 구현부분
foreground rate
background rate
absolute change
relative change
score
137. 개요
• 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
138. 사례 : 영화 추천기
• 요구사항
– goal
• 사용자가 추천한 영화 목록 데이터를 바탕으로 영화 추천하기
– input : 1개의 영화
• Talladega Nights
– Will Ferrell이 주연한 코메디 영화
– output : 추천된 영화 목록 Top 5
• 유사한 스타일의 코메디 영화
(기왕이면 윌 페럴이 주연한 영화가 추천되었으면 좋겠다)
• 사용할 전략 2가지
– recommending based on popularity
: 통계적인 방법을 사용하지 않음
– recommending based on statistics
: SigTerms(significant terms aggregation)을 적용
139. 데이터 구조
• 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
141. popularity를 기준으로 영화 추천하기
• 방법
– 주어진 영화를 추천한 사용자들을 찾는다.
– 이들 사용자들이 추천한 영화들 중에서, 가장 빈도가 높은 다른 영화 top 5를 찾는다
• 순서
– Talladega Nights의 document ID 찾기
– 이 ID를 포함하는 mlrating의 document에 대해 aggregation 수행하여 top 5 영화
document의 ID 목록 찾기
– 영화 ID로, 영화 정보 가져오기
145. popularity를 기준으로 영화 추천하기
• 영화별 비율
– 총 69,796개의 mlrating에서 “Matrix, The”가 추천된 document는 18,361 개다
– 입력인 “Talladega Nights”와 “Matrix, The”가 함께 추천된 document는 197개다
– popularity의 경우, 두 영화가 함께 추천된 document의 개수를 기준으로 정렬된다
영화
mlrating
문서 개수
Talladega Nights
를 함께 포함하는
mlrating
문서 개수
비율 순위
Matrix, The 18361 197
0.282
(197 / 69796)
1
Shawshank
Redemption
27563 196
0.281
(196 / 69796)
2
Pulp Fiction 26862 183
0.262
(183 / 69796)
3
Fight Club 12896 183
0.262
(183 / 69796)
4
Star Wars 22652 178
0.255
(183 / 69796)
5
146. popularity를 기준으로 영화 추천하기
• 문제점
– 대다수의 사용자가 추천된 영화를 좋아한다
– 추천된 영화
= universally well-liked recommendation
= commonly common data
– 입력 데이터(영화)인 Talladega Nights와 관련성이 낮다
– 입력과 관계 없이 전체 사용자가 추천한 Top 5 영화를 추출하면,
[Universally Top 5 영화 목록]
[추천된 영화 목록]
Talladega Nights의 추천 목록과 크게 차이가 없다
147. statistic를 기준으로 영화 추천하기
• 방법
– find the foreground group
Talladega Nights을 추천한 사용자 그룹을 분석하여, 가장 popular한 영화 목록을 찾
는다
– find the background group
모든 사용자 그룹에 대해 가장 popular한 영화 목록을 찾는다
– 이 둘을 비교하여 statistical anomaly를 찾는다
• statistical anomaly : foreground group과 background group에 비교할 때,
bg에 비해 fg에서 더 빈번하게 발생하는 영화들
• 추천이 예상되는 영화 목록
– 추천된 영화는 comedy 영화여야 한다
fg(Tallageda Nights 영화 즉, comdey 영화를 추천한 그룹)은 comedy 영화에 대한
선호도가 전체 bg에 비해 높을 것으로 유추 가능하기 때문
148. statistic를 기준으로 영화 추천하기
• significant terms aggregation
fg(bucket) count
bg count
149. statistic를 기준으로 영화 추천하기
• 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”를
모두 추천한 데이터
150. statistic를 기준으로 영화 추천하기
• 결과 분석
• “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
Anchorma
n
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
151. references
• significant terms aggregation:
http://www.elasticsearch.org/blog/significant-terms-aggregation/
• [yet] Revealing the Uncommonly Common with Elasticsearch
http://www.infoq.com/presentations/elasticsearch-revealing-uncommonly-
common
• [yet] significant terms aggregation
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/sear
ch-aggregations-bucket-significantterms-aggregation.html
176. 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
177. term filter
• indexing sample data
• finding exact value SELECT document
FROM products
WHERE price = 20
filtered
query
term
filter
term filter는 scoring을
하지 않음
178. term filter
• term filter on text
– by default, text 타입은 term 단위로 토큰화하여 analyzed 된다
SELECT product
FROM products
WHERE productID = "XHDK-A-1293-#fJ3"
179. term filter
• not_analyzed
– text 타입에 대해 exact matching을 하려면, indexing time에 해당 field가 analzyed
되지 않도록 한다
* 인덱스 이름 끝에 반드시 슬래시(/)를 추가한다.
그렇지 않을 경우 ElasticsearchParseException이 발생한다.
185. 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*"
186. When to use partial matching
• 언제?
– 우편번호, 상품 번호를 매칭할 때
– not_analyzed 필드에 대해
• 접두어 매칭(prefix match)을 할 때
• 와일드카드 매칭을 할 때
• 정규 표현식으로 매칭을 할 때
– 검색어 자동 완성이 필요할 때
187. prefix matching on 우편번호
• indexing sample data
prefix matching할 필드는
not_analyzed 함
188. prefix matching on 우편번호
• prefix query
• 주의할 점
– analysis를 하지 않으므로, prefix로 시작하는 모든 term을 순회한다
– term 개수가 급격히 증가하는 상황에서는 검색시 scale out이 어렵다
– 가능하면 prefix의 글자수의 최소값을 가능한 한 크도록 제한한다
no scoring
189. • wildcard query
• 주의할 점
– analysis를 하지 않으므로, prefix로 시작하는 모든 term을 순회한다
– term 개수가 급격히 증가하는 상황에서는 검색시 scale out이 어렵다
– 가능하면 prefix의 글자수의 최소값을 가능한 한 크도록 제한한다
– *foo 와 같이 패턴으로 시작하지 않도록 한다
wildcard matching on 우편번호
no scoring
190. • regexp query
• 주의할 점
– analysis를 하지 않으므로, prefix로 시작하는 모든 term을 순회한다
– term 개수가 급격히 증가하는 상황에서는 검색시 scale out이 어렵다
– 가능하면 prefix의 글자수의 최소값을 가능한 한 크도록 제한한다
– .*foo와 같이 패턴으로 시작하지 않도록 한다
정규식 matching on 우편번호
no scoring
192. autocomplete on query-time
• prefix query
– 사용자가 W1, W1V를 순서대로 입력할 때마다 검색을 수행하여 매칭 결과를 리턴
– prefix query 등은 resource 소모가 큰 쿼리이므로, 사용자 입력시 매번 검색을 수행
하는 것은 클러스터에 부하를 주게 됨
193. autocomplete on index-time
• n-gram
– partial matching을 위한 데이터를 indexing time에 준비하여 검색 성능을 향상
• 전체 term에 대해 검색시 매칭을 하는 것보다, 단일 term을 lookup하는 것이 더 빠르다
– term이 quick인 경우
– 단일 term에 대해, 부분 매칭이 필요한 경우 유용하나, autocomplete은 불가능
• edge n-gram
– term이 quick인 경우,
200. synonym token filter
• analyzer 등록하기
synonym
token filter
synonym
inline 등록
analyzer
정의
201. synonym token filter
• analyzer 테스트하기
원본 토큰과 동일한 offset에
“SYNONYM” 타입을 가지는
동의어까지 토큰으로 생성됨
아래 질의문은 모두 위의 문장을
가지는 문서에 매칭된다
• English queen
• British queen
• English monarch
• British monarch
202. Synonym 등록 포맷
• 확장(expansion): 리스트 방식
“jump,leap,hop”
• 축약(contraction): 매핑 방식
• 추가 규칙
– 동일한 동의어에 대한 규칙은 하나로 병합됨
– 동일한 동의어에 대한 규칙이 충돌 나는 경우, 가장 긴 규칙이 적용
Unite States of America => (usa), (of), (america)가 아닌 (usa)로 분석됨
203. 동의어 파일
• 동의어 파일 사용
– synonym 등록 포맷에 맞게 동의어 파일을 생성
– synonym_path 변수에 동의어 파일 경로 지정
절대 경로 또는 ${ES_HOME}/config를 기준으로 상대 경로로 지정
– 동의어 파일은 클러스터 내의 모든 노드에 배포해야 함.
204. 동의어 파일
• 동의어 갱신하기
– 동의어는 analyzer 객체에서 사용하며, analyzer 객체는 아래 경우에 생성된다.
• 인덱스가 생성될 때
• 노드가 재기동할 때
• 인덱스가 close된 후 open될 때
– 따라서 동의어를 갱신하려면,
• 동의어 파일 수정 후,
• 인덱스 close, then open
또는 클러스터의 모든 노드 재기동
– 동의어를 갱신하더라도,
• 색인 시점에 동의어를 사용했다면, 기존에 생성된 인덱스는 갱신된 동의어를 반영하지 못한
다.
• 갱신된 동의어에 따라, 인덱스를 재성성해야 한다.
• 동의어 갱신이 빈번하게 발생하고 검색 시간이 덜 중요하다면, 검색 시점에 동의어를 사용한
다
206. 단순 확장(Simple Expansion)
각 단어는, 나열된 모든 단어로 동의어 확장된다
단순 확장은
색인 시점 또는 검색 시점에 확장할 수 있다
항목 색인 시점 동의어 확장 검색 시점 동의어 확장
인덱스
크기
커진다 변함 없다
Relevance
모든 동의어가 동일한 IDF를 가진다
DF(Document Frequency)가 높은 단어와 낮은
단어가 동의어라면, 모두 같은 weight를 가진다
변한 없다
각 동의어는 자신만의 IDF를 가진다
검색
성능
쿼리 문자열에 기술된 단일 term만을 찾는다
쿼리 문자열에 기술된 term의 모든 동의어를 찾는다
검색 성능 감소
유연성
동의어를 갱신하더라도, 기존에 색인된 문서는 변
경도지 않는다.
갱신된 동의어를 적용하려면, 기존 문서를 다시
색인해야 한다
기존 문서를 다시 색인하지 않고도, 동의어를 갱신하
고 바로 반영된다
207. 단순 축약(Simple Contraction)
각 단어는, 동일한 동의어로 축약된다
따라서 축약 규칙을 사용할 경우에는,
색인 시점과 검색 시점 양쪽에 동의어 필터를 적용해야 한다
항목 단순 축약
인덱스
크기
변함 없다
Relevance
모든 동의어가 동일한 IDF를 가진다
DF(Document Frequency)가 높은 단어와 낮은
단어가 동의어라면, 모두 같은 weight를 가진다
검색
성능
쿼리 문자열에 기술된 단일 term만을 찾는다
유연성
기존 문서를 다시 색인하지 않고도, 동의어를 갱신
하고 바로 반영된다
– 동의어 갱신하기
• bound 동의어가 추가된 경우, 규칙 좌측에 추가 후 검색 시점에 동의어 필터 적용
• 기존에 색인된 문서에 새로운 동의어를 반영하려면, 규칙 우측에도 동의어를 추가
또는 규칙 좌측에 동의어 추가한 후 기존 문서를 새로 색인
211. zen discovery
• 목적
– 노드 바인딩 / 해제
• 데이터 통신을 위한 9300 포트가 열려 있다면, elasticsearch 노드를 기동하면 자동으로 클
러스터에 바인딩 된다
• 마스터 노드에서 나머지 노드로 ping을 보내서 상태를 체크
– 마스터 노드 선출
• 마스터 노드에 장애가 생기는 경우 마스터 노드 선출
• 나머지 노드에서 마스터 노드로 ping을 보내 마스터 노드 상태를 체크
• ping 방식
– multicast
• 클러스터 내의 모든 노드로 멀티캐스트 전송
• multicast 방식이 사용 불가능하거나 제한을 하려면 unicast 방식을 사용
– unicast
• 각 노드간 discovery.zen.ping.unicast.hosts에 등록된 노드를 통해 1대1 ping
212. 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을 설정
214. zookeeper discovery
• zookeeper를 discovery 프로토콜로 사용
– discovery.type
com.sonian.elasticsearch.zookeeper.discovery.ZooKeeperDiscoveryModule
– sonian.elasticsearch.zookeeper.settings.enabled
true
– sonian.elasticsearch.zookeeper.client.host
zookeeper 노드를 콤마(,)를 구분자로 등록
– sonian.elasticsearch.zookeeper.discovery.state_publishing.enabled
true
true로 설정하면, 마스터에서 나머지 노드로 클러스터 상태를 전송하는 대신,
zookeper에 상태 변화가 있는 경우에 노드에서 상태정보를 read 한다
• 주요 내용
– 마스터 선출
하나의 마스터만이 선출되어 실행
215. 참고자료
• 9 Tips on ElasticSearch Configuration for High Performance
https://www.loggly.com/blog/nine-tips-configuring-elasticsearch-for-
high-performance/
• grmblfrz/elasticsearch-zookeeper github
https://github.com/grmblfrz/elasticsearch-zookeeper
• elasticsarch-zookper groups thread
https://groups.google.com/forum/#!msg/elasticsearch-
zookeeper/vJ_Uj38Q6Ng/RiDwXC3nYS0J
218. refresh?
• document를 index를 하면 바로 search가 되지는 않는다
• index를 refresh한 후에야 search가 가능하다.
• refresh는 expensive operation
• refresh 주기
– 설정: index.refresh_interval
– 기본값: 1s
• refresh 주기를 늘리면, indexing throughput을 높일 수 있다
– refresh에 쓰이는 자원을 indexing에 사용할 수 있으므로
219. 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
220. 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 개수
221. 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되는 시간이 느려진다
222. [참고] 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.
223. Elasticsearch Performance
Characteristics on Joyent and Amazon
EC2
https://www.joyent.com/content/02-public-cloud/02-benchmarks/01-elasticsearch/elasticsearch-
benchmark.pdf
date: 최근??
version: 최신??
224. 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
227. indexing performance tips
• when to use
– indexing > search
– indexing 해야 하는 데이터는 많은 대신, search는 많이 발생하지 않거나, 내부 사용자
인 경우
– search 속도를 늘리는 대신 indexing throughput을 늘리자
• how to test performance
– 과학적으로 성능을 측정하라
– bulk request를 사용하라. 그리고 최적의 bulk size를 찾아라
– storage
– segment & merging
– 나머지 것들
228. 과학적으로 성능을 측정하라
• 단일 노드, 단일 shard, replica 없이 성능을 측정한다
• 100% default 설정에서 성능을 측정한 후, 비교할 baseline으로 삼는다
• 60분 이상 측정하라
– segment merging, GC, shard movement, OS IO caching은 단시간에는 발생하지
않을 수도 있다
• baseline 설정에서 단일 속성만을 변경한다
– 단일 속성을 조금씩 변경하면서 성능을 측정한다.
– 최적값을 찾은 후 다음 속성을 변경한다.
229. 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를 요청한
다는 뜻이다
230. storage
• SSD를 사용하자
• striping을 사용하자(replica에서 데이터 복구 능력을 제공한다
– RAID 0(striping)를 사용하자
– 또는 다수의 디스크 드라이브를 사용하자
• 다수의 path.data 설정을 통해 elasticsearch 자체적으로 striping을 하도록 하자
• remote-mounted 스토리지(NFS, SMB/CIFS 등)를 사용하지 말고, 로컬 스토리
지를 사용하라
• 가상 스토리지(virtual storage) 사용을 주의하라
– AWS EC2를 사용한다면, EBS를 주의하라. SSD 기반의 EBS라 하더라도 로컬 인스턴
스 스토리지보다 느릴 때가 많다.
231. 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가 실행
232. 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가 더 드물게 발생핟나.
233. 나머지 것들
• 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이 발생하지 않는다
234. 나머지 것들
• 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가 할당될 수 있다
236. virtual memory
• 가상 메모리의 mmap count를 충분히 늘린다
– 리눅스에서 elasticsearch는 인덱스를 기본적으로 hybrid mmapfs / niofs 파일 시스
템을 이용하여 저장한다.
– OS의 기본적으로 mmap count가 낮아, momory가 부족할 수 있다.
– vm.max_map_count를 충분히 늘린다
– 예) sysctl -w vm.max_map_count=262144
237. 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할 수도
있다
238. memory settings
• Java Heap size를 RAM의 50%를 넘지 마라
– OS에서 IO caching을 할 수 있도록 RAM을 충분히 남겨 둘 것
239. [참고] 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
memory
Lucene: RamIndexStore
- 주 메모리 사용
240. [참고] 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
241. [참고] mapping’s _source
• _source
– default: true
– indexing한 원본 JSON 문자열을 document에 자동으로 _source 필드에 저장
– retrieve & search시 리턴되는 document에 포함됨
– 검색 결과에서 원본 데이터를 보고자 한다면 enable 해야 함
– 성능을 향상하고 storage를 줄이고자 한다면 disable 할 수 있으나 큰 성능 향상은 없
음
– _source에 포함/제외하려는 필드를 지정할 수 있음
242. [참고] mapping’s _all
• _all
– default: true
– indexing한 document의 모든(또는 지정한 일부) 필드에 대한 텍스트를 포함하고 있
으며 search가 가능
– 검색시 필드를 지정하지 않고 검색하는 경우 _all 필드에 대해 검색이 수행됨
– 사용하지 않는 다면 disable(또는 꼭 필요한 필드만 enable)하여 indexing 성능을 향
상시키고, 사용되는 storage를 줄일 수 있다
– disable한 경우라면, 디폴트 검색 필드를 재설정한다
• index.query.default_field: default는 _alll
243. [참고] 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
