'the definitive guide'에 해당되는 글 2건

  1. 2015.11.24 [Elasticsearch - The Definitive Guide] Indexing Employee Documents
  2. 2014.08.04 [ElasticSearch] 대용량 데이터 색인 시 optimize 튜닝 관점

[Elasticsearch - The Definitive Guide] Indexing Employee Documents

Elastic/TheDefinitiveGuide 2015.11.24 16:10

원문 링크)


예전에 비슷한 내용으로 언급한 적이 있었는데, 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 정보가 있어야 검색이 가능 합니다.)

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 : Comment 0

[ElasticSearch] 대용량 데이터 색인 시 optimize 튜닝 관점

Elastic/Elasticsearch 2014.08.04 18:04

elasticsearch.org 에 the definitive guide 에 좋은 내용이 있어 공유 합니다.

최근에 제가 대용량 데이터를 색인 하면서 사용한 방법 이기도 합니다.

아래 링크가 원문 입니다.


제일 중요한 부분은 장비스펙과 데이터 크기에 따른 shard sizing 입니다.

이건 추후 공유 드리기로 하구요. ^^;

원문 대비 제가 활용한 방법에 대해서 간단하게 정리 하도록 하겠습니다.

[한 줄 정리]

- optimize 대신  refresh 와  flush 를 이용한다.

※ optimize 실행은 가급적 대용량 데이터 색인 및 실시간 색인에서는 사용을 피하는 것이 좋습니다.

- 글에도 있지만 대용량 데이터 색인 시 I/O 자원과 CPU 자원을 많이 사용합니다.

The merging of big segments can use a lot of I/O and CPU, which can hurt search performance if left unchecked. By default, Elasticsearch throttles the merge process so that search still has enough resources available to perform well.

Be aware that merges triggered by the optimize API are not throttled at all. They can consume all of the I/O on your nodes, leaving nothing for search and potentially making your cluster unresponsive. If you plan on optimizing an index, you should use shard allocation (see Appendix A, TODO) to first move the index to a node where it is safe to run.

이런 이유로 저는 대용량 데이터 색인 및 검색을 위해서 optimize 를 수행하지 않고 refresh 와 flush 를 조합해서 bulk request 를 수행 하도록 했습니다.
(거의 색인 시간 만큼 optimize 수행을 하다 보니 시스템 리소스를 효율적으로 사용하는데 제한이 있었습니다.)

[Bulk Request Flow]
Step 1. update settings
refresh_interval disable (-1)
replica disable (0)
Step 2. bulk request
Step 3. flush & refresh
Step 4. update settings
refresh_interval rollback
replica rollback
- 여기서 step 4 에서 replica rollback 부분은 서비스중에 돌리기 어려울 경우 별도 scheduling 을 통해서 rollback 해줘도 됩니다.
- 다만, 장애 발생 시 서비스에 심각한 문제가 되는 경우라면 바로 설정을 적용해 주어야 합니다.

[Bulk Request Size]

원문) http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/bulk.html

how big is too big?edit

The entire bulk request needs to be loaded into memory by the node which receives our request, so the bigger the request, the less memory available for other requests. There is an optimal size of bulk request. Above that size, performance no longer improves and may even drop off.

The optimal size, however, is not a fixed number. It depends entirely on your hardware, your document size and complexity, and your indexing and search load. Fortunately, it is easy to find this sweetspot:

Try indexing typical documents in batches of increasing size. When performance starts to drop off, your batch size is too big. A good place to start is with batches of between 1,000 and 5,000 documents or, if your documents are very large, with even smaller batches.

It is often useful to keep an eye on the physical size of your bulk requests. One thousand 1kB documents is very different than one thousand 1MB documents. A good bulk size to start playing with is around 5-15MB in size.

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 : Comment 0

티스토리 툴바