'엘라스틱서치'에 해당되는 글 17건

  1. 2016.04.14 [Kibana] document_already_exists_exception 에러 발생.
  2. 2016.04.12 [Elasticsearch] This Week in Elasticsearch and Apache Lucene - 2016-04-11
  3. 2016.03.31 [Kafka] 재미로 본 Elastic Stack과 Kafka 매칭
  4. 2016.03.30 [Lucene] TermVector 정보 중 Offset 에 대해서.
  5. 2016.03.23 [Elasticsearch] Timeout 소개.
  6. 2016.03.18 [Elasticsearch] this-week-in-elasticsearch-and-apache-lucene-2016-03-14 요약
  7. 2016.03.17 [Elasticsearch] Synonym 적용을 위한 Index Settings 설정 예시

[Kibana] document_already_exists_exception 에러 발생.

Elastic/Kibana 2016. 4. 14. 18:10

참 별것도 아닌데 이런것 가지고 삽질 하면 스트레스 받습니다.

그래서 잊지 않기 위해 기록합니다.


보통 elasticsearch 구성 시 default 값을 많이 사용하게 됩니다. 그러다 보니 에러를 자연스럽게 피해가게 됩니다.

뭔소리냐면, refresh_interval 의 경우 default 1s 로 되어 있습니다.


그렇기 때문에 create index 와 create document 를 했을 때 바로 처리가 되는데요.

저 같은 경우는 refresh_interval 을 서비스 특성에 맞춰 변경을 하였습니다. 이로 인해 kibana 설치 및 실행 시 아래와 같은 에러가 발생을 했습니다.


[error][status][plugin:elasticsearch] Status changed from green to red - [document_already_exists_exception] [config][4.5.0]: document already exists, with: {"shard":"0","index":".kibana"}


그래서 이상하다 싶어 .kibana 를 지워주기도 하고 실제 .kibana/config/4.5.0 문서도 지우기도 했는데요. 역시 해결이 안되었습니다. 원인을 refresh_interval 에 있었던 것이죠.


kibana 에서 이건 기본적으로 해당 .kibana 인덱스 생성 시 자동으로 .kibana index settings 에 refresh_interval 을 1s로 해주면 별 문제가 없을 것 같은데.. issue에도 올라와 있는 내용인데 뭐 언젠가 해결해 주겠죠.


이상 마칩니다.

:

[Elasticsearch] This Week in Elasticsearch and Apache Lucene - 2016-04-11

Elastic/Elasticsearch 2016. 4. 12. 09:59

봐야지 봐야지 하다 이제 봅니다.

제 눈에 띄는 것은 


  • Now that we have removed the percolator API, we should also remove the percolator type and use percolator fieldsinstead.

예전에 분리 되어 있던걸 합치더니 다시 분리 하는 것 같습니다.

task cancelled 기능을 테스트 해봐야 할 것 같습니다.

이제 field name 작성시 주의해야 겠내요. 좀 더 strict 해졌다고 봐야겠죠. ^^
- 아래 코드가 true에서 false로 되었습니다. (이 기능이 성능이나 기타 다른 기능적인 오류를 만들어 내는 걸까요?)
jsonFactory.configure(JsonParser.Feature.ALLOW_UNQUOTED_FIELD_NAMES, true);

percolator 기능이 fields 로 빠졌내요. 이것도 기능 확인을 해봐야 겠내요.
등록된 issue 를 보면 ㅎㅎ 직관적이고 사용이 좀 더 편해진것 같습니다.

core 2.x에 반영된 내용은 거의 v5.0.0 에 적용 될것 같습니다.

루씬은 일단 6.0.0 이 릴리즈 vote 중이였고 이미 4월 8일에 릴리즈 되었습니다. 이외 다른 내용들은 거의 geo point, locaiton 관련 내용들 입니다.

루씬 6.0.0 릴리즈 소식으로는
  • Java 8 is the minimum Java version required.

  • Dimensional points, replacing legacy numeric fields, provides fast and space-efficient support for both single- and multi-dimension range and shape filtering. This includes numeric (int, float, long, double), InetAddress, BigInteger and binary range filtering, as well as geo-spatial shape search over indexed 2D LatLonPoints. See this blog post for details. Dependent classes and modules (e.g., MemoryIndex, Spatial Strategies, Join module) have been refactored to use new point types.

  • Lucene classification module now works on Lucene Documents using a KNearestNeighborClassifier or SimpleNaiveBayesClassifier.

  • The spatial module no longer depends on third-party libraries. Previous spatial classes have been moved to a new spatial-extras module.

  • Spatial4j has been updated to a new 0.6 version hosted by locationtech.

  • TermsQuery performance boost by a more aggressive default query caching policy.

  • IndexSearcher's default Similarity is now changed to BM25Similarity.

  • Easier method of defining custom CharTokenizer instances.



원본링크)

Elasticsearch Core

Changes in 2.x:

Changes in master:

Ongoing changes:

Apache Lucene



:

[Kafka] 재미로 본 Elastic Stack과 Kafka 매칭

ITWeb/개발일반 2016. 3. 31. 18:16

그냥 재미로 한번 매칭해 봤습니다.

크게 의미는 없으니 재미로 봐주세요.


Kafka)


Elastic Stack)



 Elastic Stack

 Kafka

 logstash, beats

 producer

 elasticsearch cluster

 cluster (broker + zk)

 logstash

 consumer

 index

 topic 

 shard

 partition

 document id

 offset 

 index.number_of_replicas

 --replication-factors

 index.number_of_shards

 --partitions


저는 이해하기 쉬운데 저만 그런가요??


:

[Lucene] TermVector 정보 중 Offset 에 대해서.

ITWeb/검색일반 2016. 3. 30. 17:33

아는 것도 이제는 기억이 가물가물 합니다. 그래서 또 기록해 봅니다.

사내 교육을 하면서 lucene 기본 이론 교육을 하다, start offset 과 end offset 에 대해서 설명을 해주고 있었는데요.

end offset 이 실제 text의 offset 값 보다 1 크다는 것에 대한 질문이 있었습니다.


아는 건데 일단 가볍게라도 설명하고 넘어 가야해서 아무래도 highlight 기능을 위해서 그렇게 설정 하는것 같다고 하고 오늘 문서랑 소스 코드 좀 다시 살펴 봤습니다.


lucene in aciton 에서 퍼온 글)

The start offset is the character position in the original text where the token text begins, and the end offset is the position just after the last character of the token text.


end offset 이 실제 보다 1 큰 이유는 문서에 있습니다.

그런데 왜 이렇게 되었을까를 고민해 보면 내부 처리 방식을  확인해 봐야 합니다.


highlight 기능이기 때문에 이 작업에 필요한 class 파일과 fragment에 대한 처리 로직을 확인 하면 됩니다.

protected String makeFragment( StringBuilder buffer, int[] index, Field[] values, WeightedFragInfo fragInfo,
String[] preTags, String[] postTags, Encoder encoder ){
StringBuilder fragment = new StringBuilder();
final int s = fragInfo.getStartOffset();
int[] modifiedStartOffset = { s };
String src = getFragmentSourceMSO( buffer, index, values, s, fragInfo.getEndOffset(), modifiedStartOffset );
int srcIndex = 0;
for( SubInfo subInfo : fragInfo.getSubInfos() ){
for( Toffs to : subInfo.getTermsOffsets() ){
fragment
.append( encoder.encodeText( src.substring( srcIndex, to.getStartOffset() - modifiedStartOffset[0] ) ) )
.append( getPreTag( preTags, subInfo.getSeqnum() ) )
.append( encoder.encodeText( src.substring( to.getStartOffset() - modifiedStartOffset[0],
to.getEndOffset() - modifiedStartOffset[0] ) ) )
.append( getPostTag( postTags, subInfo.getSeqnum() ) );
srcIndex = to.getEndOffset() - modifiedStartOffset[0];
}
}
fragment.append( encoder.encodeText( src.substring( srcIndex ) ) );
return fragment.toString();
}

코드 보시면 아시겠죠.

기본적으로 String.substring( inclusive begin index, exclusive end index) 을 이용하기 때문에 end offset 값은 1 커야 하는 것입니다.

다른 의미로 보면 그냥 offset 정보와 text 의 length 정보를 한꺼번에 offsets 로 해결하기 좋은 방법으로 봐도 될 것 같습니다.


:

[Elasticsearch] Timeout 소개.

Elastic/Elasticsearch 2016. 3. 23. 11:39

Timeout 소개라기 보다 하도 예전에 봤던거라 다시 한번 살펴 봤습니다.

2013년도에 0.90 버전때 봤던 코드라 2.2.0 기반으로 정리해 봅니다.


참고링크) 


원문 Snippet)

By default, the coordinating node waits to receive a response from all shards. If one node is having trouble, it could slow down the response to all search requests.



참고 클래스)

TransportService.java

SearchService.java

SearchRequestBuilder.java


예전과 크게 달라 지지는 않았습니다.


첫번째 Timeout은 Shard 별 Search operation 에 대한 timeout 입니다. 

아시는 바와 같이 search request 를 보내게 되면 각 shard 수 만큼 thread 가 action 수행을 하게 됩니다. 이때 개별 thread 에 대한 timeout 설정이라고 보시면 됩니다.


두번째 Timeout은 search coordinator node에서의 timeout 입니다. 즉, 모든 shard 에서 데이터를 받을 때 까지의 timeout 이라고 보시면 됩니다.


:

[Elasticsearch] this-week-in-elasticsearch-and-apache-lucene-2016-03-14 요약

Elastic/Elasticsearch 2016. 3. 18. 10:28

거의 매주 올려 주는 elasticsearch & lucene 소식 입니다.

그냥 학습 한다 생각하고 요점 정리만 해볼 생각 입니다.


원문링크)


원문요약) 

올라온 것 중 개인적으로 keep 할 것만 추렸습니다.


Changes in master:

  • `string` fields will be replaced by `text` and `keyword` fields in 5.0, with the following bwc layer:
    • String mappings in old indices will not be upgraded.
    • Text/Keyword mappings can be added to old and new indices.
    • String mappings on new indices will be upgraded automatically to text/keyword mappings, if possible, with deprecation logging.
    • If it is not possible to automatically upgrade, an exception will be thrown.
  • Norms can no longer be lazy loaded. This is no longer needed as they are no longer loaded into memory. The `norms` setting now take a boolean. Index time boosts are no longer stored as norms.
  • Queries deprecated in 2.0 have now been removed.
  • The generic thread pool is now bound to 4x the number of processors.

Ongoing changes:


master에 반영된 내용 중 눈에 확 들어 오는건 string field내요. 이제 text와 keyword로 맵핑을 해야 할 것 같습니다.

이미 반영된건 자동으로 업그레이드 되지 않지만 신규로 생성하는건 자동으로 되내요.

그리고 deprecated 된 query들 이제 remove 되었내요. 혹시라도 계속 사용하셨다면 에러 조심 하세요.


변경중인것 중에는 field명에 dot 지원이랑 percolator query가 눈에 들어 오내요. API 방식에서 Query 방식으로 변경되면 더 편하고 유용하게 사용할 수 있겠습니다.




:

[Elasticsearch] Synonym 적용을 위한 Index Settings 설정 예시

Elastic/Elasticsearch 2016. 3. 17. 18:34

나중에 또 잊어 버릴까봐 기록합니다.


참고문서)


예시)

"index": {
"analysis": {
"analyzer": {
"arirang_custom": {
"type": "custom",
"tokenizer": "arirang_tokenizer",
"filter": ["lowercase", "trim", "arirang_filter"]
},
"arirang_custom_searcher": {
"tokenizer": "arirang_tokenizer",
"filter": ["lowercase", "trim", "arirang_filter", "meme_synonym"]
}
},
"filter": {
"meme_synonym": {
"type": "synonym",
"synonyms": [
"henry,헨리,앙리"
]
}
}
}
}


여기서 주의할 점 몇 가지만 기록 합니다.

1. synonym analyzer 생성 시 type을 custom 으로 선언 하거나 type을 아예 선언 하지 않습니다.

2. synonym 은 filter 로 생성 해서 analyzer 에 filter 로 할당 합니다.

3. 색인 시 사용할 것인지 질의 시 사용할 것인지 장단점과 서비스 특성에 맞게 검토 합니다.

4. synonyms_path 를 이용하도록 합니다. (이건 주의라기 보다 관리적 차원)

5. match type 의 query만 사용이 가능 하며, term type 의 query를 사용하고 싶으시다면 색인 시 synonym 적용해야 합니다.


그럼 1번에서 선언 하지 않는 다는 이야기는 뭘까요?

선언 하지 않으시면 그냥 custom 으로 만들어 줍니다.

못 믿으시는 분들을 위해 아래 소스코드 투척 합니다.


[AnalysisModule.java]

String typeName = analyzerSettings.get("type");
Class<? extends AnalyzerProvider> type;
if (typeName == null) {
if (analyzerSettings.get("tokenizer") != null) {
// custom analyzer, need to add it
type = CustomAnalyzerProvider.class;
} else {
throw new IllegalArgumentException("Analyzer [" + analyzerName + "] must have a type associated with it");
}
} else if (typeName.equals("custom")) {
type = CustomAnalyzerProvider.class;
} else {
type = analyzersBindings.analyzers.get(typeName);
if (type == null) {
throw new IllegalArgumentException("Unknown Analyzer type [" + typeName + "] for [" + analyzerName + "]");
}
}


: