'guide'에 해당되는 글 30건

  1. 2015.11.30 [Elasticsearch - The Definitive Guide] Sorting tips.
  2. 2015.11.30 [Elasticsearch - The Definitive Guide] Validating Queries
  3. 2015.11.30 [Elasticsearch - The Definitive Guide] Mapping
  4. 2015.11.30 [Elasticsearch - The Definitive Guide] Deep Pagination
  5. 2015.11.30 [Elasticsearch - The Definitive Guide] bulk-format
  6. 2015.11.27 [Elasticsearch - The Definitive Guide] Optimistic Concurrency Control
  7. 2015.11.27 [Elasticsearch - The Definitive Guide] Creating a New Document
  8. 2015.11.27 [Elasticsearch - The Definitive Guide] Updating a Whole Document.
  9. 2015.11.24 [Elasticsearch - The Definitive Guide] Scale Horizontally
  10. 2015.11.24 [Elasticsearch - The Definitive Guide] An Empty Cluster

[Elasticsearch - The Definitive Guide] Sorting tips.

Elastic/TheDefinitiveGuide 2015. 11. 30. 16:44

팁이라고 하기 좀 그렇지만 그냥 쉽게 놓칠수 있는 부분이 있어 기록 합니다.


[한 줄 요약]

- sorting 기능은 메모리를 많이 사용합니다.


[원문링크]


[원문 Snippet]

Sorting on a full-text analyzed field can use a lot of memory. See Fielddata for more information.

- FIelddata 는 보통 fielddata cache 기능을 이야기 합니다. 또한 circuit break 와 함께 참고 하셔야 합니다.


[팁]

- fields 사용 (전에는 multi fields 라고 불렀습니다.)

- analyzed field 에 대한 정렬은 메모리를 많이 사용하기 때문에 주의 해서 사용합니다.


:

[Elasticsearch - The Definitive Guide] Validating Queries

Elastic/TheDefinitiveGuide 2015. 11. 30. 16:23

사실 저도 많이 사용하지 않는 API이긴 합니다.

간혹 내부적으로 Query DSL 이 어떤식으로 Lucene Query로 해석 되는지 궁금할 때가 있는데요.

_validate query API를 이용하면 쉽게 번역이 가능 합니다.


아마도 query string 에 익숙하고 전문적으로 사용하시는 분들에게는 의미가 없을지도 모르겠지만 그럼에도 불구하고 유용한 API라고 생각합니다.


이유는 RDBMS 에서 Select 절 작성하고 나서 실행 전에 꼭 explain 떠 보시잖아요.

그런것과 같은 거라고 생각 하시면 되겠습니다.


[원문링크]


위 문서 보다는 references 문서가 좀 더 예제가 자세하니 링크 참고 하시면 되겠습니다.


[References]


:

[Elasticsearch - The Definitive Guide] Mapping

Elastic/TheDefinitiveGuide 2015. 11. 30. 15:26

간혹 dynamic mapping 기능으로 인한 type mismatch 오류를 경험 하시는 분들이 있습니다.

그래서 기록해 봤습니다.

The Definitive Guide 에 올라온 Note 입니다.


원문링크)


원문 Snippet)

This means that if you index a number in quotes ("123"), it will be mapped as type string, not type long. However, if the field is already mapped as type long, then Elasticsearch will try to convert the string into a long, and throw an exception if it can’t.


정리 및 작은 팁을 말씀 드리면,

- 정수형 이면 그냥 long 으로 선언 하세요.

- 실수 형이면 그냥 double 로 선언 하세요.

- ".." 로 묶으면 string 형으로 선언 됩니다.

- dynamic mapping 은 explicity 하게 사용하시는게 좋은 습관 입니다.


:

[Elasticsearch - The Definitive Guide] Deep Pagination

Elastic/TheDefinitiveGuide 2015. 11. 30. 11:55

기초적인 내용이지만 그냥 기록해 봅니다.


원문링크)

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


원문 Snippet)

[Deep Paging in Distributed Systems]

To understand why deep paging is problematic, let’s imagine that we are searching within a single index with five primary shards. When we request the first page of results (results 1 to 10), each shard produces its own top 10 results and returns them to the requesting node, which then sorts all 50 results in order to select the overall top 10.


Now imagine that we ask for page 1,000—results 10,001 to 10,010. Everything works in the same way except that each shard has to produce its top 10,010 results. The requesting node then sorts through all 50,050 results and discards 50,040 of them!


You can see that, in a distributed system, the cost of sorting results grows exponentially the deeper we page. There is a good reason that web search engines don’t return more than 1,000 results for any query.


요약하면,

- There is a good reason that web search engines don’t return more than 1,000 results for any query.

- 불필요한 자원 및 연산에 대한 낭비로 문제가 될 수 있다.


이런 문제를 해결 하기 위해서는 cache 솔루션과 잘 조합해서 사용하시면 그나마 문제를 해결 하실수는 있습니다.

그럼에도 불구하고 근본적인 해결책은 아닙니다.

:

[Elasticsearch - The Definitive Guide] bulk-format

Elastic/TheDefinitiveGuide 2015. 11. 30. 11:43

Elasticsearch에서 bulk request 시 사용하는 format 에 대한 이야기 입니다.

이 이야기를 기록하는 이유는 elasticsearch 내부에서 동작하는 원리를 쉽게 이해 할 수 있기 때문 입니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/distrib-multi-doc.html#bulk-format


[Why the funny format?]

  • Parse the JSON into an array (including the document data, which can be very large)
  • Look at each request to determine which shard it should go to
  • Create an array of requests for each shard
  • Serialize these arrays into the internal transport format
  • Send the requests to each shard


정리하자면,

bulk request 를 받아서 다시 풀고 적절한 node의 shard 로 forward 되도록 생성한 후 send or request 한다 입니다.

:

[Elasticsearch - The Definitive Guide] Optimistic Concurrency Control

Elastic/TheDefinitiveGuide 2015. 11. 27. 15:35
Conflict 에 대한 내용입니다.

역시 잊어버릴 까봐 기록해 봅니다.


원문링크) 


내용요약)

- 내부적으로 같은 문서에 대한 수정이 발생 할 경우 version 정보는 계속 증가 합니다.

- 이미 갱신된 문서에 대해서 이전 version 정보를 가지고 수정 요청이 들어 오게 될 경우 conflict 오류를 발생 시킵니다.

- 원본 데이터에 대한 version 정보를 이미 사용중이라면 version_type=external 로 설정해서 사용 할 수 있습니다.


transaction 처리가 필요한 데이터에 대해서는 사용하시면 좋을 것 같습니다.


:

[Elasticsearch - The Definitive Guide] Creating a New Document

Elastic/TheDefinitiveGuide 2015. 11. 27. 15:15

색인 시 유용하게 활용 가능한 방법이라 기록해 봅니다.


원문링크)


색인 요청 시 unique 하게 한번만 생성되도록 해주는 API 입니다.

REST API로 요청 시 op_type=create 또는 _create 로 요청 하시면 됩니다.


각 비즈니스 요구사항에 따라 다르겠지만 유용하게 활용 할 수 있을것 같습니다.

:

[Elasticsearch - The Definitive Guide] Updating a Whole Document.

Elastic/TheDefinitiveGuide 2015. 11. 27. 15:07

아주 기본적인 내용이라 그냥 보고 넘어 갈까 했지만, 누군가에게는 필요한 정보 일수도 있어서 기록해 봅니다.


원문링크)


Content Snippet)

Documents in Elasticsearch are immutable; we cannot change them. Instead, if we need to update an existing document, we reindex or replace it, which we can do using the same index API that we have already discussed in Indexing a Document.


종종 elasticsearch 사용하시는 분들중에 update 에 대해서 문의를 합니다.

또는 mapping 정보 변경 시, field 수정/추가 시 등등..


immutable 즉, 불변이라는 것이죠.

수정이 안됩니다. 그렇기 때문에 reindex or replace 라고 하는 것입니다.

동일 문서 ID 로 색인 요청을 하게 되면 delete -> insert 로 동작 합니다.


사용하면서 참고 하시면 좋겠습니다.

:

[Elasticsearch - The Definitive Guide] Scale Horizontally

Elastic/TheDefinitiveGuide 2015. 11. 24. 17:46

원본링크)

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


성능 확보를 위한 가장 쉬운 방법은 scale up 또는 out 입니다.

여기서는 scale out 에 대한 재밌는(?) 글이 있어 뽑아 봤습니다.


Of course, just having more replica shards on the same number of nodes doesn’t increase our performance at all because each shard has access to a smaller fraction of its node’s resources. You need to add hardware to increase throughput.


내용은 정말 별거 없습니다.


- 같은 노드 수에 replica shard만 늘린다고 성능이 좋아 지지 않는다.

- 성능을 향상 시키고 싶으면 장비를 더 넣어라.


이상입니다.

:

[Elasticsearch - The Definitive Guide] An Empty Cluster

Elastic/TheDefinitiveGuide 2015. 11. 24. 17:04

원본링크)

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


Elasitcsearch에가 이야기 하는 master node 의 역할 과 주의 사항이랄까요?

아래는 원문에 대한 Snippet 입니다.


One node in the cluster is elected to be the master node, which is in charge of managing cluster-wide changes like creating or deleting an index, or adding or removing a node from the cluster. The master node does not need to be involved in document-level changes or searches, which means that having just one master node will not become a bottleneck as traffic grows. Any node can become the master. Our example cluster has only one node, so it performs the master role.


[마스터 노드가 하는 일?]

인덱스 생성/삭제

노드 추가/제거


[마스터 노드에서 하면 안되는 일?]

문서 레벨의 변경 작업

검색


하면 안될 일은 트래픽 증가 시 병목 현상이 마스터 노드에서 발생 하면 안되기 때문 입니다.

(장애 납니다. ^^;)

: