elasticsearch를 가지고 한 샤드로 데이터를 모아 메모리로 올리니 성능이 많이 좋아졌다.

그러나 너무 큰 용량을 쓰면 성능이 생각보다 좋지 않았다. 


그래서 인터넷을 확인해보니. 10G 이상일 때는 쪼개는 것이 좋다는 얘기가 존재했다.

(HEAD 플러그인으로 보면 클러스터 크기를 확인가능)


아.. 쪼개야겠다 ㅜ



출처:

http://gibrown.com/2014/02/06/scaling-elasticsearch-part-2-indexing/

http://elasticsearch-users.115913.n3.nabble.com/increasing-shards-and-then-nodes-td2288848.html

elasticsearch cookbook 2nd edition 1장


'Elasticsearch' 카테고리의 다른 글

[elasticsearch] mget  (0) 2015.09.09
[elasticsearch] 로그 설정  (0) 2015.09.08
elasticsearch 2.0 출시 (2015.8.26)  (0) 2015.08.27
[elasticsearch] optimize api  (0) 2015.08.26
[elaseticsearch] 플러그인 개발 및 python 좋은 자료  (0) 2015.08.25
Posted by '김용환'
,



2015.8.26 일래스틱서치 2.0 (베타)이 출시되었다.  안정화되려면 시간이 걸리겠지만, 굉장히 공격적이다.


https://www.elastic.co/blog/elasticsearch-2-0-0-beta1-released

https://www.elastic.co/guide/en/elasticsearch/reference/2.0/breaking-changes-2.0.html



많이 바뀐 터라, 문서도 많고, 

https://www.elastic.co/downloads/past-releases/elasticsearch-2-0-0-beta1


마이그레이션 소스까지도 제공한다.

https://github.com/elastic/elasticsearch-migration


2.0 관련 이슈들은 여기서 볼 수 있으며, 여전히 해야할 일이 있어 보인다.

https://github.com/elastic/elasticsearch/labels/v2.0.0




그리고, 문서에서도 2.0을 지원하고 있다. (현재 기본 값은 1.7이지만..)

https://www.elastic.co/guide/en/elasticsearch/reference/2.0/docs-index_.html



새로 생긴 기타 프로젝트도 2.0기반에서 동작되도록 개발하고 있다.

https://github.com/elastic/elasticsearch-hadoop/tree/master/repository-hdfs




https://jaxenter.com/elasticsearch-2-0-0-to-bring-numerous-features-120227.html 에 따르면.


- Apache Lucene 5.2.1을 사용

- pipeline aggregation 기능 추가

- merging시 메모리 소비를 최대한 적게 하고 데이터 압축을 사용 (1.x에서는 merge이 가장 큰 성능 저하 원인이었음)

- 최적화, 필터 자동 캐시 (1.x에서는 임의로 캐쉬 여부를 설정해야 했음)

- 필터는 사라진다. 필터와 질의를 하나로 묶어 질의(query)만 사용하게 함  

- 다양한 일래스틱서치 core 플러그인 지원 (요즘 나오는 일래스틱서치 플러그인이 전부 2.x 기반임)

- 3차원을 추후 지원 예정 (Lucene 5.3.0부터는 3차원, spatical3d 모듈)


흘..일래스틱서치 너무 빨리 변해..

Posted by '김용환'
,




optimize API는 하나 이상의 색인(멀티 지원)을 최적화하는 API로서, 강제로 호출하는 형태이다. 최적화 과정은 일반적으로 빠른 검색 동작을 위해 색인을 최적화한다. optimize API는 완료될 때까지 블럭하며(비동기 아님), http 연결이 손실되면, 해당 요청은 백그라운드로 실행된다.

새로운 optimize 요청이 들어면 최적화 작업이 완료 될 때까지 블럭한다. 만약 검색 요청이나 삭제 요청이 들어오면 일래스틱서치가 받는다.

$ curl -XPOST 'http://localhost:9200/poi/_optimize'

요청 매개변수 
* max_num_segments : 최적화할 세그먼트 개수이며, 기본 값은 -1이다. 색인을 충분히 최적화하려면 1로 설정한다. 1로 설정하는 의미는 세그먼트 1개로 검색할 수 있게 (searchable) 하겠다는 의미가 있다. 

* only_expunge_deletes :  최적화 작업은 일래스틱서치에서 삭제하면서 생긴 세그먼트를 제거할지 명세한다. 기본값은 false이다. 루씬에서는 다큐먼트는 세그먼트에서 바로 삭제되지 않고 지워짐(deleted)라고 표시하기만 한다. 
일반적으로 세그먼트 병합 과정시, 새로운 세그먼트는 지워짐(deleted)이라 표시된 세그먼트에서 생성되지 않는다. 즉  새 것은 새 부대에 담는다. 따라서, 해당 옵션은 지원 세그먼트에서 병합을 할 때 사용할 수 있는 옵션이다. 
index.merge.policy.expunge_deletes_allowed를 값을 오버라이드 하지 않는다. 따라서 설정쪽과 달리 최적화 api 에만 적용된다.

* flush : 최적화 작업 후, flush가 수행될지를 알린다. 기본값은 true이다.


세그먼트 병합은 검색 성능을 높이기 위해 다큐먼트를 삭제할 것은 삭제하고 남아있는 다큐먼트를 더 큰 세그먼트로 병합하는 것을 의미한다. 병합 과정이 끝나면 병합된 세그먼트는 더 이상 쓰지 않기 때문에 삭제한다.이러한 병합 작업은 프로세스와 메모리를 많이 사용한다. 따라서 다큐먼트 삭제가 많은 서비스에는 일래스틱서치에 맞지 않을 수 있다.
또한 동적이 아닌 정적으로 동작한다. 그래서, 색인이 백그라운드로 세그먼트 병합 중일 때, 강제로 optimize API를 호출할 때는 좋지 않을 수 있다. 



출처
https://www.elastic.co/guide/en/elasticsearch/guide/current/merge-process.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-optimize.html
+  경험



소스로 좀 더 추가설명하면 해당 optimize 호출을 깊게 파면, InternalEngine.forceMerge()를 호출하도록 되어 있다. 이를 통해 관련 내용을 잘 이해할 수 있다. 

https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/index/engine/InternalEngine.java


@Override
public void forceMerge(final boolean flush, int maxNumSegments, boolean onlyExpungeDeletes,
final boolean upgrade, final boolean upgradeOnlyAncientSegments) throws EngineException {
/*
* We do NOT acquire the readlock here since we are waiting on the merges to finish
* that's fine since the IW.rollback should stop all the threads and trigger an IOException
* causing us to fail the forceMerge
*
* The way we implement upgrades is a bit hackish in the sense that we set an instance
* variable and that this setting will thus apply to the next forced merge that will be run.
* This is ok because (1) this is the only place we call forceMerge, (2) we have a single
* thread for optimize, and the 'optimizeLock' guarding this code, and (3) ConcurrentMergeScheduler
* syncs calls to findForcedMerges.
*/
assert indexWriter.getConfig().getMergePolicy() instanceof ElasticsearchMergePolicy : "MergePolicy is " + indexWriter.getConfig().getMergePolicy().getClass().getName();
ElasticsearchMergePolicy mp = (ElasticsearchMergePolicy) indexWriter.getConfig().getMergePolicy();
optimizeLock.lock();
try {
ensureOpen();
if (upgrade) {
logger.info("starting segment upgrade upgradeOnlyAncientSegments={}", upgradeOnlyAncientSegments);
mp.setUpgradeInProgress(true, upgradeOnlyAncientSegments);
}
store.incRef(); // increment the ref just to ensure nobody closes the store while we optimize
try {
if (onlyExpungeDeletes) {
assert upgrade == false;
indexWriter.forceMergeDeletes(true /* blocks and waits for merges*/);
} else if (maxNumSegments <= 0) {
assert upgrade == false;
indexWriter.maybeMerge();
} else {
indexWriter.forceMerge(maxNumSegments, true /* blocks and waits for merges*/);
}
if (flush) {
flush(true, true);
}
if (upgrade) {
logger.info("finished segment upgrade");
}
} finally {
store.decRef();
}
} catch (Throwable t) {
ForceMergeFailedEngineException ex = new ForceMergeFailedEngineException(shardId, t);
maybeFailEngine("force merge", ex);
throw ex;
} finally {
try {
mp.setUpgradeInProgress(false, false); // reset it just to make sure we reset it in a case of an error
} finally {
optimizeLock.unlock();
}
}
}




Posted by '김용환'
,



팩트 출판사의 일래스틱서치 cookbook github 자료에 플러그인 자료와 python연동에 좋은 자료를 소개한다.



https://github.com/aparo/elasticsearch-cookbook-second-edition




플러그인 자료


https://github.com/aparo/elasticsearch-cookbook-second-edition/tree/master/chapter_12/simple_plugin

https://github.com/aparo/elasticsearch-cookbook-second-edition/tree/master/chapter_12



python 연동 자료


https://github.com/aparo/elasticsearch-cookbook-second-edition/tree/master/chapter_11

Posted by '김용환'
,



일래스틱서치 아키텍처에 대한 일반적인 구성과 검색 환경에서 사용할 수 있는 아키텍처가 있을 수 있다.



일래스틱서치 문서에 있는 대로 일래스틱서치는 클러스터링이 가능하다. 따라서 보통 아래 그림 1과 같이 검색노드, 데이터노드, 모니터링 노드를 나누어서 사용하는 구조를 가진다. 



<그림 1> 전통적인 일래스틱서치 아키텍처





일반적이지 않은 아키텍처이지만, 검색환경에서 사용할 수 있는 구조는 그림 2에 있다. 각 일래스틱서치는 standalone으로 실행할 수 있고, nginx에 앞단에 두어 서비스할 수 있다. HTTP 9200 포트가 아닌 HTTP 80으로 요청을 보낼 수 있으며(proxy pass), L7 health  check를 추가할 수 있다. 또한 특정 시간 내로 처리되지 못하면 요청을 timeout할 수 있다. 즉, nginx의 장점을 잘 활용할 수 있다.




일래스틱서치가 오래 걸리는 슬로우 쿼리만 볼 수 있지만, nginx을 두어 추세나 요청 건수를 확인할 수 있다. 일래스틱서치의 모니터링을 더 확보할 수 있는 장점이 있다. 클러스터링의 단점은 master->data node의 연결이 없기 때문에 조금 더 빠른 속도로 진행할 수 있다. replica 없이 샤드 한개로의 작업이 문제없었다. 그러나, 단점은 클러스터링 이슈이다. 특별히 integrity를 보장하기 위한 작업이 필요하며, snapshot/backup을 통해 서버 재시작/점검에도 데이터가 잃지 않도록 하는 작업이 특별히 필요했다. 



Posted by '김용환'
,



elasticsearch는  HTTP 프로토콜,  Thrift 프로토콜, 자바 프로토콜을 지원한다.


HTTP 프로토콜을 이용하여 9200 포트를 사용할 수 있다.

그러나 Thrift 프로토콜은 9500 포트를 사용하지만, 1.5.0에서 deprecated 되었고 2.0.0에서는 완전히 사라질 예정이다.

java 프로토콜은 9300 포트를 사용하지만, 한 node 처럼 작동되는 구조이기 때문에 클라이언트와 서버 버전이 동일해야 한다. 따라서 업그레이드가 쉽지 않을 수 있다.

또한, 멤캐쉬드(memcached) 프로토콜은 11211포트를 사용하지만, Thrift 프로토콜 처럼 1.5.0에서 deprecated되었고, 2.0.0에서 완전히 사라질 예정이다. 




출처

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

https://www.elastic.co/guide/en/elasticsearch/guide/current/_talking_to_elasticsearch.html

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

Posted by '김용환'
,




일래스틱서치에서 scroll 에서 가장 중요하고 잊지 않아야 할 요소는 3가지이다.  scroll 값, 스크롤 끝에 왔을 때이다.


curl -XGET  'localhost:9200/_search/scroll?scroll=1m' -d '${scroll_value}' 



1. scroll 값


scroll 매개변수는 _search 할 때 매개변수로 사용한다. 한번에 빅 데이터를 읽는 것보다 페이지 단위(pagination)으로 읽기 때문에 배치 처리를 쉽게 할 수 있다.  그러나 scroll 을 쓴다는 것은 메모리를 많이 쓴다는 것을 의미하기 때문에 특정 시간에 스크롤을 많이 쓰면 메모리 부족(OOM)을 발생시킬 수 있다. 


scroll 매개변수는 얼마나 오래 "search context"를 유지시키느냐를 의미한다.

잘 생각하면 scroll 값은 사실 상 타임아웃을 발생시키게 하는 값으로 쓰이는 의미를 포함하며, 유효한 scroll 값을 임시적으로 가지게 한다는 의미도 포함하며, 일래스틱서치에서 일부 메모리를 차지하겠다는 의미를 가진다. scroll 자원은 타임아웃이 발생 또는 잘 종료될 때까지 모두 일래스틱서치에서 메모리에서 관리한다. 


scroll 값이 바뀌지 않는 값이기 때문에 scroll의 유효기간을 얼마나 지속될지에 대한 timeout 값 정도로 생각하면 될 것 같다.


너무 짧은 시간을 주면 scroll 타임아웃이 발생하고 scan/scroll 중간에 exception이 발생하고 종료된다. 따라서  적당한 데이터를 넣어야 할 필요가 있다. 예를 들어 문서에 10m이라고 적혀있다고 해서 그렇게 적으면 안된다. 테스트를 충분히 해서 작성해야 한다. 


scroll의 값을 지정할 때, 10m 또는 3h 로 지정할 수 있다. y는 year, M은 month, m은 minute, h는 시간 이다. 자세한 내용은 아래 참조를 참조한다. 




2. 스크롤 마지막 이후


스크롤로 데이터를 읽으면 맨 마지막 요소이후에 결과처리를 해야 한다.

9300 포트로 붙는 Java native의 경우  Hits의 개수에 맞게 처리하면 되니까 큰 무리가 없지만, 

9200 포트로 붙는 Http REST API의 경우 404 Not Found가 발생한다. 이를 잘 처리하도록 하면 된다. 




참조


https://www.elastic.co/guide/en/elasticsearch/guide/current/scan-scroll.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#time-units

Posted by '김용환'
,



Elasticsearch는 자바로 구현되어 있어서 메모리가 부족하면 Out Of Memory가 언제든지 발생할 수 있다. 아래 로그는 bulk insert하면서 OOM이 발생한 부분이다. 



Caused by: java.lang.OutOfMemoryError: Java heap space

        at org.apache.lucene.index.FreqProxTermsWriterPerField$FreqProxPostingsArray.<init>(FreqProxTermsWriterPerField.java:214)

        at org.apache.lucene.index.FreqProxTermsWriterPerField$FreqProxPostingsArray.newInstance(FreqProxTermsWriterPerField.java:235)

        at org.apache.lucene.index.ParallelPostingsArray.grow(ParallelPostingsArray.java:48)

        at org.apache.lucene.index.TermsHashPerField$PostingsBytesStartArray.grow(TermsHashPerField.java:252)

        at org.apache.lucene.util.BytesRefHash.add(BytesRefHash.java:292)

        at org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:151)

        at org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:663)

        at org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)

        at org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)

        at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:241)

        at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:465)

        at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1526)

        at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1252)

        at org.elasticsearch.index.engine.internal.InternalEngine.innerCreateNoLock(InternalEngine.java:502)

        at org.elasticsearch.index.engine.internal.InternalEngine.innerCreate(InternalEngine.java:444)

        at org.elasti


그 이후에, cpu 튀고, 메모리가 부족한 현상으로 나타난다. 색인은 해야 하고 메모리는 부족하는 상황이라 재시작 외에는 해결할 방법이 없다. 그리고 색인 작업이 실패한 색인에서는 unassigned라 표시된다. 



이 문제를 해결하려면 색인 작업을 하기 전에 메모리 상태를 체크하는 것이 좋다. 이를 위해서는 헤드 플러그인 정보를 살펴보는 것이 좋다.  헤드 플러그인을 설치한 후, http://ip:9200/_plugin/head/ 에 접속하여 size가 얼마인지 확인하고 새 색인의 size를 미리 예상하고 색인 작업을 하는 것이 좋다.


헤드 플러그인에 접속해서 색인 이름 밑의 size가 있는데. 전체 크기를 의미한다. 만약 저장 방식을 memory로 했을 때는 모두 메모리로 올라오기 때문에 메모리 상황을 계속 체크해야 한다. 




Posted by '김용환'
,






elasticsearch는 자바로 개발되었다. 그래서 9300 포트는 자바 네이티브로 API 개발이 가능하다.


자바 관점에서 API 분류

- 자바 네이티브 API - TransportClient, NodeClient

- HTTP Rest API - restTemplate/Apache HttpClient와 같은 툴로 직접 연결, Jest


NodeClient와 TransportClient로 개발이 쉽게 가능하다는 장점이 있다. 그러나 공식적으로 쓰지 않기를 권고 하고 있다. 기능이 추가되어 버전이 올라갈 때 모델이 바뀌고 있다는 점을 현재 강조하고 있으며, 9200포트를 이용하여 REST API로 개발하기를 권고하고 있다. 또한, 일래스틱서치 클러스터의 노드로 연동되기 때문에 일래스틱서치의 로그를 계속 받도록 되어 있다.

예를 들면, 아래와 같은 로그를 일래스틱서치 클라이언트도 받는 다. 


2015-08-18 15:02:22.839  INFO 27145 --- [anagement][T#2]] o.e.cluster.routing.allocation.decider   : [Unseen] high disk watermark exceeded on one or more nodes, rerouting shards

2015-08-18 15:02:52.825  WARN 27145 --- [anagement][T#2]] o.e.cluster.routing.allocation.decider   : [Unseen] high disk watermark [10%] exceeded on [5kXkv-RfQEumsEqOsTUaKA][Unseen] free: 15.2gb[6.5%], shards will be relocated away from this node 


9200 포트는 Http REST api로 접근할 수 있으며 자바를 제외한 대부분의 언어에서는 API를 이용한 lib로 구성된다.


9300포트가 아닌 9200포트로 접근하는 Http REST API를 순수 Java로 개발할 수 있다. 그러나 Java와 Json의 관계가 아름다운 편이 아니다. Map으로 객체를 감싸고 이를 Json으로 만드는 과정이 있어야 한다. 특히 POJO로 마샬링해야 하는 부분에서 귀찮고 구구절절한 코드를 작성해야 하는 부담감이 있던지라 쓸만한 것이 있나 찾아보았는데, Jest라는 자바 라이브러리를 추천하고 있었다. 


Jest(https://github.com/searchbox-io/Jest)은 JetBrain에서 개발되어 오픈소스로 나오게 되었다.  저자가 써보니 쓰기도 편하고 성능도 괜찮게 나왔다. 자바 네이티브 보다 더 빠른 성능을 가졌다. Spring sagan 프로젝트, play2 연동 모듈(https://github.com/CedricGatay/play2-elasticsearch-jest) 도 사용하고 있었다.


0.16이 현재 마지막 버전이지만, 조만간에 1.0.0이 릴리즈 된다고 한다. 


내가 본 jest의 장점은 두가지이다. 

- json 요청을 코드에 넣는다. 헤드 플러그인으로 미리 테스트해볼 수 있다.  잘 동작하면 이를 사용한다.

- 응답 결과를 POJO로 마샬링할 수 있어서 JSON을 파싱하지 않아서 편리하다.

- Spring의 @Configuration  또는 FactoryBean으로 생성할 수 있는 좋은 팩토리 구조라 재사용성이 좋다.

- 검색시 자바 네이티브 API보다 속도가 10ms 정도 더 빨랐다. (구조적인 사례일 수도)

- 다양한 환경에서도 언제든지 쓸 수 있다. (일래스틱서치 구성을 서버당 한개로 설정하고 여러 대로 L4로 구성하는 최적화한 상태에서 클러스터 이름이 달라도 쉽게 쓸 수 있다.)




간단한 psedo 코드는 다음과 같다. 동작하는 코드를 확인하라면 아래 참조 자료를 확인한다.



pom.xml 

        <dependency>

            <groupId>io.searchbox</groupId>

            <artifactId>jest</artifactId>

            <version>0.1.6</version>

        </dependency>



JestClientConfiguration.java : JestClient Bean을 생성한다.

@Configuration

public class JestClientConfiguration {


@Value("${elasticsearch.search.endpoint}")

private String address = "http://ep123.google.com:9200";


@Value("${elasticsearch.search.max_connection}")

private int maxTotalConnection = 10;


@Value("${elasticsearch.search.conn_timeout")

private int connTimeout = 1000;


@Value("${elasticsearch.search.read_timeout")

private int readTimeout = 3000;


@Bean

public JestClient jestClient(){

// Configuration

HttpClientConfig clientConfig = new HttpClientConfig.Builder(address)

.multiThreaded(true)

.maxTotalConnection(maxTotalConnection)

.connTimeout(connTimeout)

.readTimeout(readTimeout)

.build();


JestClientFactory factory = new JestClientFactory();

factory.setHttpClientConfig(clientConfig);

JestClient client = factory.getObject();

return client;

}

}



SearchService.java : 실제 JestClient를 이용하는 코드

@Service

public class SearchService {


@Inject

private JestClient jestClient;


        public List<SearchModel> search(String queryString) {


if (StringUtils.isEmpty(queryString)) {

logger.error("term object : " + queryString);

return Collections.emptyList();

}


String query = "{\n"

+ "    \"query\": {\n"

+ "        \"filtered\" : {\n"

+ "            \"query\" : {\n"

+ "                \"query_string\" : {\n"

+ "                    \"query\" : \"" + queryString + "\"\n"

+ "                }\n"

+ "            }\n"

+ "        }\n"

+ "    },\n"

+ "    \"sort\" : \n"

+ "       { \"rank\" : \n"

+ "           {\"order\" : \"desc\"} \n"

+ "    },\n"

+ "    \"size\" : 3"

+ "}";

              // query 문이 지저분하니 이를 freemarker(ftl)로 변경할 수 있다.


Search.Builder searchBuilder = new Search.Builder(query).addIndex(SEARCH_INDEX_NAME).addType(SEARCH_TYPE_NAME);

Search search = searchBuilder.build();


List<SearchModel> list = Lists.newArrayList();

try {

SearchResult result = execute(search);

if (result == null) {

return Collections.emptyList();

}

List<SearchResult.Hit<SearchModel, Void>> hits = result.getHits(SearchModel.class);


for (SearchResult.Hit<SearchModel, Void> hit: hits) {

SearchModel objectSource = hit.source;

list.add(objectSource);

}


} catch (Exception e) {

logger.error(e.getMessage(), e);

}


return list;

}


}






참조할 만한 싸이트

http://www.ibm.com/developerworks/library/j-javadev2-24/  (강추)

http://blogs.justenougharchitecture.com/?p=828

http://www.searchly.com/documentation/developer-api-guide/java-jest/

http://thysmichels.com/2014/03/02/heroku-elastic-search-example/

https://github.com/spring-io/sagan/blob/e003b6a50342629f4ca75a79a00941f572c81c73/sagan-common/src/main/java/sagan/search/support/SearchService.java

https://github.com/spring-io/sagan/blob/e003b6a50342629f4ca75a79a00941f572c81c73/sagan-common/src/main/java/sagan/search/support/SearchResultParser.java


Posted by '김용환'
,



1. elasticsearch의 자바 네이티브 클라이언트의 일부 메소드 컨벤션



- prepareCreate()와 같이 prepare로 시작하는 메소드는 execute 메소드로 실행할 수 있는 요청 Builder를 생성하고 리턴한다. 



- create()와 같은 동사 메소드는 빌드된 요청과 action listener를 받아 처리한다.





2. elasticsearch의 자바 네이티브 클라이언트의 일부 그룹 메소드


- client.*로 시작하는 메소드는 색인, 삭제, 검색, 변경과 같은 레코드 작업


- admin.indices.*로 시작하는 메소드는 색인 생성 / 삭제와 같은 색인 작업


- admin.cluster.*로 시작하는 메소든느 헬쓰 체크와 같은 클러스터 작업





Posted by '김용환'
,