데이터 검색
Query대신 Filter 사용
filter는 _score를 사용하지 않기 때문에 query에 비해 속도가 빠르다.
필터는 오직 결과가 검색과 일치하는지만 관심을 가진다는 것이다. 결과적으로 다른 쿼리보다 빠르고 쉽게 캐시에 저장할 수 있다.
필터 결과는 점수에 의해 정렬되지 않는다. (모든 결과에 대한 점수가 1.0이기 때문)
_score : 문서가 지정한 조건과 얼마나 유사한지 평가
실시간 VS 준 실시간
ID로 문서를 조회하는 것은 쿼리 검색보다 훨씬 빠르다. 실시간에 준하는 검색 속도를 보장한다.
그에 반해 쿼리 검색은 준 실시간이다. 기본값으로 매초 발생하는 리프레시를 기다려야 하기 때문이다.
[리프레시 설정 값]
"index.refresh_interval": "5s"
ulimit
데이터가 많아지면 인덱스 파일 개수 또한 증가
elasticsearch가 사용하고 있는 Lucene에서 인덱스를 세그먼트 단위로 관리하기 때문이다. 경우에 따라 MAX_OPEN 파일 개수를 넘어서는 일도 발생한다.
ulimit 명령으로 최대 오픈 파일 제한을 변경해야 한다. (권장 값은 32,000~64,000)
참고 : https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html
Java Heap 사이즈
ES 전용 서버 운영 시 메모리 용량의 절반만 ES에 할당, 나머지 메모리 용량은 운영체제가 시스템 캐시 목적으로 사용할 수 있도록 하자.
운영체제가 시스템 캐시 목적으로 많은 양의 메모리가 필요한 이유는 디스크에 저장한 데이터를 빠르게 접근하기 위함이다. (디스크에 저장되는 lucene 세그먼트에서 데이터를 읽음)
elasticsearch.in.sh 파일 변경
1 2 | #!/bin/sh 이후에 다음을 추가 ES_HEAP_SIZE=500m | cs |
include_in_all 옵션
_all 필드에 저장할 것인지를 지정
언더바(_)로 시작하는 필드는 엘라스틱에서 관리하는 필드이다.
_all 필드는 검색할 때 유용한데 검색할 문자열이 어떤 필드에 매치되는지 알 필요 없을 때 사용되어 진다.
만약 개발하는 비즈니스에서 필드를 항상 지정하여 검색하는 경우 include_in_all 옵션을 false로 하도록 하자.
이와 같은 옵션 변경은 색인 전체 크기를 줄이고 더 빠르게 색인을 만든다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | { "properties": { "guid": { "index": "not_analyzed", "type": "string", "include_in_all": false }, "goodsId": { "index": "not_analyzed", "type": "integer", "include_in_all": false }, "registered": { "index": "not_analyzed", "format": "yyyy.MM.dd hh:mm:ss", "type": "date", "include_in_all": false } } } | cs |
index 매핑의 기본값은 analyzed
다음과 같이 3가지 기본 index 매핑이 있다.
guid 라는 속성을 검색할 때 정확한 값 일치를 사용한다면 not_analyzed를 지정하자.
"guid": {
"index": "not_analyzed",
"type": "string",
"include_in_all": false
},
analyzed
analyzer를 이용한 tokenized 수행 --> 색인 진행
ex) "this is my test a sentence" 라는 string이 주어졌을 때 analyzer를 통과하면 단어들이 다 쪼개져서 색인된다.
not_analyzed
검색 가능하도록 색인 (정확한 값 일치)
analyzer를 이용하지 않기 때문에 색인 속도가 빠르다.
no
색인하지 않음
검색 불가능
검색 결과에 포함되어 출력만 가능
모든 인덱스 삭제 방지
다음과 같이 한번에 모든 인덱스를 날려버릴 수 있다.
1 | curl -XDELETE localhost:9200/_all | cs |
이를 방지하기 위해서 다음의 옵션은 elasticsearch.yaml 에 추가해 준다. _all뿐만 아니라 색인 이름으로 와일드카드까지도 거부한다.
1 | action.destructive_requires_name=true | cs |
Dynamic Index 처리 방안
인덱스에 데이터가 많아지면 검색 요청에 많은 시간이 소요될 수 있다.
이를 위해 Dynamic Index를 이용하여 검색 요청 범위를 제한하고 최소화하자.
ex)
web-log_201710
web-log_201711
web-log_201712
data node 라이브 장비 스펙
메모리 : 64GB
CPU : 2~8코어
저장디스크 : SSD
'서버' 카테고리의 다른 글
윈도우에서 Docker 테스트 해보자 (0) | 2019.03.25 |
---|---|
[Elasticsearch] 클러스터 rolling restarts (0) | 2018.02.02 |
[Elasticsearch] 은전한잎 설치 (0) | 2018.01.24 |
[Elasticsearch] 샤드 (Shard) (0) | 2017.12.20 |
[Elasticsearch] filter 조회가 query 조회보다 빠르다. (0) | 2017.12.11 |
[Elasticsearch] Query 검색 결과 구조 (0) | 2017.12.06 |
[Elasticsearch] 한번 정해진 mapping 속성은 변경 불가 (0) | 2017.12.05 |
[Elasticsearch] index 매핑 (analyzed, not_analyzed, no) (0) | 2017.12.01 |