'Elastic/TheDefinitiveGuide'에 해당되는 글 33건

  1. 2015.11.24 [Elasticsearch - The Definitive Guide] Scale Horizontally
  2. 2015.11.24 [Elasticsearch - The Definitive Guide] An Empty Cluster
  3. 2015.11.24 [Elasticsearch - The Definitive Guide] Indexing Employee Documents

[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.


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

인덱스 생성/삭제

노드 추가/제거


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

문서 레벨의 변경 작업

검색


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

(장애 납니다. ^^;)

:

[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 정보가 있어야 검색이 가능 합니다.)

: