웹에서 hit는 웹 싸이트 분석에서 사용되는 통계이다. hits와 visits는 때때로 상호 교환 할 수 있는 용어로 사용되지만, 서로 다르다. 사용자가 웹 페이지를 방문하면 방문이 기록된다. hit는 웹 서버로부터 다운로드된 각각의 로컬 파일 자원 참조 개수를 의미한다.  따라서, 1 page 내에 파일 리소스가 10개이면 (html, css, javascript 등등), 1 vistit에 10개의 hit라 표현할 수 있다.

검색에서 hit는 주어진 검색 질의에 대한 검색 결과의 개수를 의미한다. 1,000,000 개의 구글 검색을 생성하면 질의에 의한 1,000,000 개의 hit 라 표현할 수 있다.

elasticsearch의 hit도 검색의 포함된 용어이기 때문에 '검색 결과' 또는 '검색 결과 개수'로 해석하면 좋은 것 같다. 

일래스틱서치의 문서를 보면 내부에서 낙관적 동시 제어를 지원한다고 얘기를 한다.

실제 versioning도 지원되는 것도 그 배경이다.

동시성 충돌 때문에 레코드를 잠그는 비관적 동시 제어(select for update) 하는 DB와 다르다. 

한 트랙잭션이 다른 트랙잭션과 충돌할 가능성이 적은 곳에서 사용된다. 

그렇지만, 충돌이 되더라도 반영을 안하는 것은 아니다. 원 데이터가 수정이 되었나 체크해서 수정된 것이 판별되면 이미 실행된 트랙잭션이 롤백이 일어나고 다시 시작한다. 따라서 일래스틱서치에서는 수정된 데이터를 읽을 수 있도록 처리 되어 있다.

일래스틱서치에서 트랙잭션이 동시에 일어나 데이터가 변경되면 version이 증가된다. GET 요청에 대해서 확인할 수 있다.

원래 요청했던 version이 1인데, 응답의 body에는 2가 리턴된다.  (다큐먼트를 색인할 때 version의 디폴트 값은 1이다) 

PUT /website/blog/1?version=1 

.. "_version" : 2 ..

그러나 처리 중간에 트랜잭션에 의해서 값이 변경될 수 있다. 그 때는 409 conflict 응답을 받는다.

(REST API는 확실히 지원하나, 언어별 클라이언트에서는 의도하지 않는 응답이 올 수 있다고 한다.)

일래스틱서치는 변경 또는 삭제 요청에만 version 파라미터를 사용할 수 있는 낙관적 동시 제어를 지원한다.

스크립트 실행 동안 변경이 일어나면, 스크립트가 변경된 데이터로 재실행된 결과를 얻는다.

출처 : 

https://www.elastic.co/guide/en/elasticsearch/guide/master/version-control.html

https://www.elastic.co/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html

https://www.elastic.co/blog/elasticsearch-versioning-support

http://en.wikipedia.org/wiki/Optimistic_concurrency_control

색인 앨리어스는 색인에 대한 앨리어스(별명) 치고는 유용한 기능이 있다.

출처 : 

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html

elasticsearch에서 failed to put mappings on indices (NPE) 가 발생하면 용도에 맞는 json 요청이라는 뜻이다.

elasticsearch가 친절하게 에러 메시지를 전달해주는 것이 없어서(결과적으로 실패했다는 로그) 조금 혼란을 줄 수 있긴 한데..

몸으로 때우는 수밖에 없는 것 같다. 

클라이언트에서는 아래와 같은 에러가 발행한다.

해결을 위해서는 setting와 mapping 관련 url이 맞는지 확인한다.

* /_setting url 에 mapping json을 요청했는지, 

* /_mapping url에 setting json을 요청했는지.

* /_mapping url에 setting, mapping json을 요청했는지.

* /{index_name} 에 setting, mapping 을 잘 입력해서 정상적으로 요청했는지 (<-- 이거 정상)

test.json에 setting와 mapping 을 포함한 json 파일일 때, 아래와 같은 url 요청시에 failed to put mappings on indices (NPE)  에러 발생한다.

$ curl -s -XPUT http://localhost:9200/suggest_test/type/_mapping -d test.json

test.json에 setting와 mapping 을 포함한 json 파일일 때, 아래와 같은 url 요청시에 문제가 없다.

$ curl -s -XPUT http://localhost:9200/suggest_test -d test.json

1. flush 

elasticsearch의 flush는 메모리와 트랜잭션 로그를 디스크로 저장한다.

elasticsearch는 lucene을 의존한다. lucene의 색인(index) 작업은 fsync를 사용하는데, fsync가 비싼 비용이 있어서 lucene은 여러 세그먼트로 색인을 관리하고 있다. 

in memory buffer를 이용하여 sync 작업이 발생하면 fsync를 통해서 디스크에 저장한다.

2. refresh

refresh는 색인을 새로 고침의 의미가 있다. 즉, 검색이 되게 하는 (searchable)의 의미가 있다. 

refresh주기가 시간내 검색이 되느냐 안되는냐를 결정한다. (보통 1초를 사용)

참조로 elasticsearch 문서에서는 거의 실시간(near real time, NRT)라는 단어를 사용하고 있다. 

https://www.elastic.co/guide/en/elasticsearch/guide/current/near-real-time.html

만약 refresh 주기를 지정하지 않으면, 따로 호출을 주어 refresh를 임의로 호출하게 할 수 있다. 

참고로 flush와 refresh는 동시에 사용될 수 있다. 

3. 최적화(optimization)

파편화된 세그먼트를 세그먼트를 줄이고 검색 성능을 빨리 하도록 하여 색인을 통합한다. 검색 성능을 높이는데 의미를 두고 있다.

lucene이 사용하지 않는 세그먼트와 다큐먼트를 정리하는 IO 작업을 통해서 검색을 빠르게 한다. 세그먼트 수를 최소화시킨다. 최소한의 파일에만 접근하도록 한다. 

최적화의 매개변수는 3개이다. 

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-optimize.html

elasticsearch에서 myindex 인덱스를 생성한다. 

elasticsearch에서 모든 인덱스(색인)을 삭제하는 방법은 다음과 같다.

또는 

상용 서비스에서는 괜히 호출했다가 문제가 될 수 있으니, 방어 설정을 elasticsearch.yml에 둘 수 있다.

만약 전체 삭제를 시도하려 했더라면 다음과 같이 에러가 발생하게 되고 전체 삭제가 안 될 것이다.

elasticsearch 1.4.3 으로 테스트해봤던 내용 공유

1. refresh_interval 값 성능

전에, refresh_interval 값이 성능에 영향이 있다고 해서 테스트해보았다. 

refresh_inteval 로 주어진 값은 인덱싱(색인)을 얼마나 하는 주기를 의미한다. 일종의 flush 같은 개념인데, 

길면 길수록 성능은 좋아지고, 짧을 수록 성능은 좋지 않다. 

확실히 짧게 주는 것보다는 길게 주는 것이 좋다. cpu 5~15% 차이가 발생 했다.

그러나, 문제는 서비스의 영향도가 있어서 짧게 줄 수 없다.. 

로그 수집하는 정도나. refresh_interval을 길게 줄 수 있을 듯 하다.

(좋은 참고 : http://blog.sematext.com/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/ )

2. optimize 옵션 주기

optimize옵션을 주면 빠른 검색이 되도록 최적화 인덱싱을 한다. 호출 순간에서는 성능이 안좋아질 수 있으나, 장기적으로는 성능이 좋아진다.

cpu 1~3% 정도로 성능이 좋아졌다.

(좋은 참고 : http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-optimize.html#optimize-parameters)

3. 삭제시 좋은 성능이 나오도록 튜닝 요소

인덱스를 이루는 세그먼트가 삭제로 인해서 큰 세그먼트로 compatction이 일어나도록 잘 튜닝할 수 있다. 

서비스 성격에 맞게 변경해야 한다. 

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

https://groups.google.com/forum/#!topic/elasticsearch/-j7bpgNMHMQ

4. Sorting 성능 개선

Sorting 성능을 개선할 수 있다. 서비스 성격에 맞게 변경해야 한다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-fielddata.html

5. 검색 ThreadPool 설정

https://www.elastic.co/guide/en/elasticsearch/reference/1.x/modules-threadpool.html

6. (Data Node) JVM GC 알고리즘 

다양한 방식으로 여러 GC 방법 (CMS, G1)으로 테스트 해봤으나, elasticsearch에서 제공하는 디폴트의 jvm 옵션(cms)이 최강이었음. 

JVM8 최신으로 G1 알고리즘으로 Full GC 시간을 좀 줄일 수 있지만, 자주 조금 줄일 수 있었지만, CPU가 상당히 높게 나왔다. CMS는 다양한 옵션으로 했지만, 디폴트 옵션만큼의 CPU와 Full GC 시간을 이길 수 없었따. 

(참고 : http://blog.sematext.com/2013/06/24/g1-cms-java-garbage-collector/)

7. (Data Node) JVM 메모리

JVM 메모리가 많을 수록 유리할 수 있지만, Full GC 시간이 점점 길어졌다. 한 JVM의 메모리는 작은 것이 가장 성능이 좋았다.

인터넷의 여러 회사 블로그에서 대용량 트래픽을 elasticsearch 대용량 메모리로 처리했다는 내용(linked, stackoverflow)을 참조해고 해봤는데, 서비스의 성격(CRUD)에 따라 다른 것 같다. 

elasticsearch에서 매핑 따로 색인 따로 호출해도 되지만, 하나로 묶어도 된다. (사실 이 묶음 요청이 가장 elasticsearch 만의 큰 장점인듯 하다.)