'Index'에 해당되는 글 15건

  1. 2022.07.14 [Elasticsearch] Index Template 사용 시 Mapping 정보 오류
  2. 2020.04.03 [Elasticsearch] Index 생성 시 Name Pattern
  3. 2017.11.14 [Lucene] Inverted index file - 역인덱스 파일
  4. 2016.03.02 [Elasticsearch] Create Index Settings & Mappings 템플릿.
  5. 2015.12.11 [Elasticsearch] Merge Throttle 설정 튜닝
  6. 2015.12.09 [Elasticsearch - The Definitive Guide] Dynamically Updatable Indices
  7. 2015.12.03 [Elasticsearch - The Definitive Guide] Index Settings
  8. 2015.11.24 [Elasticsearch - The Definitive Guide] Indexing Employee Documents
  9. 2015.06.30 [Elasticsearch] Multi types into Index.
  10. 2015.03.18 [Elasticsearch] index vs. indice vs. indices ????

[Elasticsearch] Index Template 사용 시 Mapping 정보 오류

Elastic/Elasticsearch 2022. 7. 14. 19:30

사용하다 보면 정말 별거 아닌 건데 눈에 잘 안보일 때가 있습니다.

 

에러 메시지)

"reason"=>"failed to parse field [message] of type [text] in document with id '3UI29IEBerapX-zaQi4L'. 
Preview of field's value: 
...중략...
"caused_by"=>{"type"=>"illegal_state_exception", "reason"=>"Can't get text on a 
START_OBJECT at 1:529"}

 

이런 에러메시지를 접하게 되면 두 눈 크게 뜨고 Template 에서 정의한 type 정보와 실제 들어 오는 값이 잘 매핑이 되어 있는지 확인을 해보시기 바랍니다.

 

모니터는 큰걸로 글자 크기는 크게 해서 보세요. 

:

[Elasticsearch] Index 생성 시 Name Pattern

Elastic/Elasticsearch 2020. 4. 3. 11:22

Elastic Stack 을 사용하다 보면 Index 를 자동으로 생성 시켜 주는 설정들을 사용 하게 됩니다.

 

beats 에서는 output elasticsearch 사용 시 설정을 하게 되고,

logstash 에서도 output elasticsearch 사용 시 설정을 하게 됩니다.

 

보통 이 설정을 아래와 같이 하는데요.

 

Logstash)

index

- Value type is string
- Default value is "logstash-%{+YYYY.MM.dd}"

 

Beats)

index

The index name to write events to when you’re using daily indices. 
The default is "beat-%{[agent.version]}-%{+yyyy.MM.dd}" 
(for example, "beat-7.6.2-2020-04-02"). 
If you change this setting, you also need to configure the setup.
template.name and setup.template.pattern options (see Elasticsearch index template).

output.elasticsearch:
  hosts: ["https://localhost:9200"]
  index: "beats-%{[agent.version]}-%{+yyyy.MM.dd}"

- filebeat, metricbeat ...

 

보시면 아시겠지만, Daily rolling 으로 많이 사용하게 됩니다.

무조건 하루 단위로 생성이 되기 때문에 규모가 너무 작거나 너무 크거나 할 경우 효율이 떨어 질 수 밖에 없습니다.

그래서 Index Lifecycle Management 라는 기능을 Elasticsearch 에서 제공하고 있으니 활용 하시기 바랍니다.

 

여기서 문제)

그럼 output.elasticsearch.index 설정과 ilm 설정이 동시에 사용 중일 때 어떤 설정에 맞춰서 index 가 생성이 될까요?

 

정답)

ilm 설정이 우선 합니다. 

 

Elastic 의 공식 메시지는 이렇습니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html

 

You can configure index lifecycle management (ILM) policies to automatically manage indices according to your performance, resiliency, and retention requirements.

 

:

[Lucene] Inverted index file - 역인덱스 파일

ITWeb/검색일반 2017. 11. 14. 23:15

루씬에서 검색을 하기 위해 필요한 파일을 살짝 알아보겠습니다.

파일 구조와 목록은 아래 문서를 참고 하시기 바랍니다.

Lucene Index File Formats)

https://lucene.apache.org/core/7_1_0/core/org/apache/lucene/codecs/lucene70/package-summary.html#package.description


그럼 실제 검색을 위해 보셔야 하는 기본이 되는 클래스는 

  • IndexSearcher
  • IndexReader
  • CollectionStatistics
  • TermStatistics

이렇게 4개 정도 보시면 될 것 같습니다.


검색을 위해 필요한 정보는

  • Documents
  • Fields
  • Terms
  • FieldInvertState

이렇게 4개 정도가 필요 합니다.

딱 봐도 "searchField:elasticsearch" 하면 

  • searchField 라는 field 정보가 필요하고, 
  • elasticsearch 라는 term 관련 정보도 필요하고, 
  • elasticsearch 라는 term 이 있는 document 정보도 필요하고,
  • 해당 field 에서의 term 이 추출 된 offset과 position 정보가

필요합니다.


이걸 정리한 이유는 오늘 누가 custom function score query 를 사용하여 다수의 field 에 대한 ranking term boosting 기능을 사용하고 있는데 성능적으로 개선 할 수 있는 방법이 없는지 물어봐서 간단하게 정리해봤습니다.

Query 튜닝은 한계가 반드시 존재 합니다.

서버의 구조적인 개선과 튜닝을 병행해야 하며 다수의 field 에 대한 다수의 term boosting 은 최적화를 통해 최소화 해서 사용하는걸 추천 드립니다.

그리고 inverted index file 이라는 것은 루씬에서 하나의 파일만 이야기 하는 것이 아니라 lucene 이 가지고 있는 index file 목록들이 inverted index file 을 구성 한다고 보시면 될 것 같습니다.

:

[Elasticsearch] Create Index Settings & Mappings 템플릿.

Elastic/Elasticsearch 2016. 3. 2. 12:30

그냥 복습 하는 차원에서 기록 합니다.



$ curl -XPUT "http://localhost:9200/INDEX_NAME" -d'

{

  "settings": {

  ...설정할 정보를 넣으세요...

  },

  "mapping": {

  ...설정할 정보를 넣으세요...

  }

}


별 내용 없습니다.

그냥 rest api를 이용해서 index 생성 할 때 필요한 설정 정보를 작성하는 틀 정도 입니다.

type 정보는 mappings 안에 넣으시면 됩니다.

기본적으로 해당 설정은 지정한 INDEX_NAME 에 한해서 적용되는 것입니다. 별도의 global 설정을 하고 싶으시다면 template 기능을 활용하시기 바랍니다.


참고링크)

:

[Elasticsearch] Merge Throttle 설정 튜닝

Elastic/Elasticsearch 2015. 12. 11. 15:56

bulk indexing 을 하다 보면 색인 하는 과정에서 느려지는 현상을 경험 할 수 있습니다.

여러가지 원인이 있을 수 있지만 간단하게 설정을 통해서 성능 향상을 시킬수 있는 방법을 소개해 드립니다.


기본적인 정보는 이미 Elasticsearch Reference 에서 제공하고 있기 때문에 관련 내용을 찾아 보시면 이해 하시는데 도움이 됩니다.


참고문서)


Elasticsearch 역시 lucene 기반의 검색 엔진이기 때문에 과거부터 전해져 오는 segment merge 시 발생 하는 성능 저하 문제는 피해 갈 수가 없습니다.

이를 좀 더 효율적으로 사용하기 위해 아래 설정을 활용 하시면 됩니다.


Merge throttle 은 두 가지 방법을 제공해 주고 있습니다.


1. Node level throttle

이것은 merge 동작은 shard 단위로 발생을 하기 때문에 같은 node 에 있는 shard 들은 동일한 자원을 사용하게 됩니다.

즉, disk i/o 에 대한 경합을 할 수 밖에 없는 것인데요.

이런 이유로 node level 설정을 사용하게 됩니다.


indices.store.throttle.type: “merge” ## all, none

indices.store.throttle.max_bytes_per_sec: “20mb"


 여기서 수정이 필요한 부분은 색인 데이터의 크기를 감안해서 max_bytes_per_sec 을 적합한 크기로 설정해 주시면 됩니다.


2. Index level throttle

특정 index 에 대해서 관리를 하고 싶을 때 node level throttle 설정을 무시 하고 설정을 하도록 해주는 것입니다.

설정 방법은 index update settings 를 통해서 할 수 있습니다.


index.store.throttle.type: “node"

index.store.throttle.max_bytes_per_sec: “20mb"


 여기서 수정이 필요한 부분은 색인 데이터의 크기를 감안해서 max_bytes_per_sec 을 적합한 크기로 설정해 주시면 됩니다.

 throttle type을 none 으로 할 경우  disable merge 설정이 됩니다.

:

[Elasticsearch - The Definitive Guide] Dynamically Updatable Indices

Elastic/TheDefinitiveGuide 2015. 12. 9. 16:25

Elasticsearch가 lucene 기반으로 만들어진 분산검색엔진 이라는 것은 이미 잘 알고 계실겁니다.

하지만 elasticsearch를 사용하시는 분들중 lucene을 잘 아시는 분들은 그렇게 많이 계시지는 않은것 같아 참고 할 만한 좋은 내용이 있어 올려 봅니다.


원문링크)

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


원문 Snippet)

[Deletes and Updates]

Segments are immutable, so documents cannot be removed from older segments, nor can older segments be updated to reflect a newer version of a document. Instead, every commit point includes a .del file that lists which documents in which segments have been deleted.

When a document is “deleted,” it is actually just marked as deleted in the .del file. A document that has been marked as deleted can still match a query, but it is removed from the results list before the final query results are returned.

Document updates work in a similar way: when a document is updated, the old version of the document is marked as deleted, and the new version of the document is indexed in a new segment. Perhaps both versions of the document will match a query, but the older deleted version is removed before the query results are returned.


아래는 원문에 나와 있는 per-segment search works 간단 정리 입니다.

1) write in-memory buffer

2) write new segment file from in-memory buffer

3) write commit point (Refresh API on Elasticsearch)

4) flush in-memory buffer

5) searchable


※ 이 내용과 실제 elasticsearch 에서 primary shard 와 replica shard 간 데이터가 sync 되는 것과는 다른 내용입니다.

:

[Elasticsearch - The Definitive Guide] Index Settings

Elastic/TheDefinitiveGuide 2015. 12. 3. 17:24

아주 좋은 글 귀가 보여서 이건 기록을 안할래야.. ^^


원문링크)


원문 Snippet)

Elasticsearch comes with good defaults. Don’t twiddle these knobs until you understand what they do and why you should change them.


Elasticsearch는 잘 모르겠다 싶으시면 그냥 default 로 사용하시는게 제일 좋습니다. :)

:

[Elasticsearch - The Definitive Guide] Indexing Employee Documents

Elastic/TheDefinitiveGuide 2015. 11. 24. 16:10

원문 링크)

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


예전에 비슷한 내용으로 언급한 적이 있었는데, the definitive guide 에도 잘 정리가 되어 있어서 공유해 봅니다.


Index Versus Index Versus Index


You may already have noticed that the word index is overloaded with several meanings in the context of Elasticsearch. A little clarification is necessary:


Index (noun)

As explained previously, an index is like a database in a traditional relational database. It is the place to store related documents. The plural of index is indices or indexes.


Index (verb)

To index a document is to store a document in an index (noun) so that it can be retrieved and queried. It is much like the INSERT keyword in SQL except that, if the document already

exists, the new document would replace the old.


Inverted index

Relational databases add an index, such as a B-tree index, to specific columns in order to improve the speed of data retrieval. Elasticsearch and Lucene use a structure called an inv

erted index for exactly the same purpose.


By default, every field in a document is indexed (has an inverted index) and thus is searchable. A field without an inverted index is not searchable. We discuss inverted indexes in m

ore detail in Inverted Index.


보통 우리도 이야기 할 때 그냥 인덱스 라고 합니다.

하지만 이건 앞뒤 문맥을 바탕으로 위와 같이 명사인지 동사인지 판단 해야 합니다.

간혹 루씬 기반의 검색엔진 개발이나 서비스 개발을 안해보신 분들의 경우 인덱스라는 용어에 대해서 헷갈려 하시는 분들도 있습니다.

이번에 한번 집고 넣어 가시면 좋지 않을까 생각 합니다.


Inverted index 즉, 우리는 역인덱스 라고 부릅니다.

이것은 루씬에서 사용하는 색인된 데이터베이스 파일(?) 이라고 하면 쉽게 이해가 되지 않을까 합니다. (그리고 이 inverted index 정보가 있어야 검색이 가능 합니다.)

:

[Elasticsearch] Multi types into Index.

Elastic/Elasticsearch 2015. 6. 30. 11:47

6월에 바쁘다는 핑계로 글을 하나도 못 올렸내요.

그런 의미에서 하나 올려 볼까 합니다.


오늘의 주제는 Elasticsearch에서 하나의 Index에 여러개의 Type을 생성 사용할 경우 주의할 점입니다.


Elasticsearch 와 RDB 와는 자주 비교가 됩니다.

개념을 쉽게 잡아 주기 위해서 인데요.


가볍게 다시 한번 비교해 보고 넘어 가겠습니다.


Elasticsearch 

 RDB

 Index

 Database

 Type

 Table

 Mapping

 Schema

 Document

 Row

 Field

 Column

※ 더 있지만 이 정도로 정리 하겠습니다.


이제 오늘의 주제 입니다.

Elasticsearch에서는 하나의 Index 생성 시 여러개의 Type을 생성 할 수 있습니다.

동일하게, RDB 도 하나의 Database에 여러개의 Table을 생성 할 수 있습니다.


하지만 여기서 Elasticsearch의 Type과 Database의 Table 사이에는 조금 다른 점이 있는데요.

RDB 에서 Table 간 Column은 이름이 같더라도 데이터 형이나 인덱스 유형등에 대해서 서로 독립적으로 사용이 됩니다.

하지만 Elasticsearch의 Type 간 Field는 이름이 같게 되면 데이터 형이나 인덱스 유형등도 같아야 한다는 것입니다.


이유는 내부적으로 Lucene 에서는 Type 간 같은 이름의 Field는 하나의 Field 로 사용이 되기 때문입니다.

단, Type 간 Field 이름이 다르다면 이건 문제가 되지 않습니다. (당연한 이야기 겠죠.)


예)

IndexA - Type1, Type2 가 있다고 가정하겠습니다.

Type1 에 geo 라는 field 가 있고 데이터 형이 geo_point 라고 가정 하겠습니다.

Type2 에도 geo 라는 field 가 있고 데이터 형이 string 이라고 가정을 하면 어떻게 될까요?


  "mappings": {

    "type1": {

      "properties": {

        "geo": {

          "type": "geo_point"

        }

      }

    },

    "type2": {

      "properties": {

        "geo": {

          "type": "string"

        }

      }

    }

  }


이 경우는 에러가 발생을 합니다.

같은 필드에 서로 다른 데이터 형을 선언 했기 때문인데요.

이렇게 사용 하시면 안됩니다.


정확한 사용은 서로 다른 type 에 같은 field  가 있다면 데이터 형도 동일하게 선언을 해주셔야 합니다.


  "mappings": {

    "type1": {

      "properties": {

        "geo": {

          "type": "geo_point"

        }

      }

    },

    "type2": {

      "properties": {

        "geo": {

          "type": "geo_point"

        }

      }

    }

  }


※ 데이터 형만을 가지고 설명을 드렸지만 기타 다른 옵션도 동일하게 선언하셔서 사용하시길 추천 드립니다.



:

[Elasticsearch] index vs. indice vs. indices ????

Elastic/Elasticsearch 2015. 3. 18. 12:08

뭘 중요하거나 특별한건 아니지만 용어에 대한 정리가 필요 할 수 있어 그냥 적어 봅니다.


흔히 검색엔진에서는 인덱스(index) 또는 컬렉션(collection) 이라고 합니다.

검색 대상 문서들에 대한 색인 집합(?) 이라고 보시면 될 것 같습니다.


그럼 elasticsearch에서는 어떻게 사용을 할까요?

elasticsearch 뿐만 아니라 대부분의 검색엔진에서는 개별 검색 대상 그룹을 인덱스 또는 컬렉션 이라고 부릅니다.

그렇기 때문에 elasticsearch에서도 인덱스(index)라고 부르고 있고 이런 인덱스들의 복수 묶음을 indices 라고  하고 있습니다.


indice라는 표현이 간혹 나오기도 하는데 현재는 index와 indices로 정리가 된것 같아 동일하게 맞춰 볼까 합니다.

(indice 가 딱히 틀렸다고 하기도 애매 합니다.) 


[표기]

index (O)

indice (△)

indices (O)


아래는 그냥 참고하시라고 퍼왔습니다.


Ref.

http://en.wiktionary.org/wiki/indice

http://grammarist.com/usage/indexes-indices/


Indexes vs. indices

Indexes and indices are both accepted and widely used plurals of the noun index. Both appear throughout the English-speaking world, butindices prevails in varieties of English from outside North America, while indexes is more common in American and Canadian English. Meanwhile,indices is generally preferred in mathematical, financial, and technical contexts, while indexes is relatively common in general usage.

Neither form is wrong. Both have been in English many centuries (and though indexes is now most common in American English, it predates the United States by centuries). It’s true that indices is the plural of index in Latin, but index is an English word when English speakers use it—and it is a longstanding one at that—so we can pluralize it according to the conventions of English.






: