2014.09.03 - 번역 - Performance Considerations for Elasticsearch Indexing ...

Running Elasticsearch 2.0?  Check out this updated post about performance considerations for Elasticsearch 2.0 indexing.

Elasticsearch 2.0을 운영 중이라면? Elasticsearch 2.0 indexing에 대한 성능 고려 사항에서 update된 post를 확인해 보자.

Elasticsearch users have delightfully diverse use cases, ranging from appending tiny log-line documents to indexing Web-scale collections of large documents, and maximizing indexing throughput is often a common and important goal. While we try hard to set good general defaults for "typical" applications, you can quickly improve your indexing performance by following a few simple best practices, described here.

Elasticsearch 사용자는 소규모 log document를 추가하는 것부터 web 스케일의 큰 document를 index하는 것까지 매우 다양하게 사용하고 있다. 그리고 index 처리량을 극대화하는 것은 일반적이고 중요한 목표인 경우가 많다. "일반적인(typical)" 응용 프로그램에 대한 적절하고 일반적인 기본값을 설정하는 것은 어렵지만, 여기에 설명한 몇가지 간단한 모범 사례를 따를 경우 쉽게 index 성능을 개선할 수 있다.

To begin with, do not use a very large java heap if you can help it: set it only as large as is necessary (ideally no more than half of the machine's RAM) to hold the overall maximum working set size for your usage of Elasticsearch. This leaves the remaining (hopefully sizable) RAM for the OS to manage for IO caching. Make sure the OS is not swapping out the java process.

우선, 아주 큰 heap을 사용하지 말자. Elasticsearch 사용에 필요한 최대 크기를 유지하는데 필요한 만큼만 사용하자(기계에 설치된 RAM의 절반 이하). 이렇게 하면, OS에 남아 있는 RAM은 IO caching에 사용된다. OS가 java process를 swap하지 않도록 주의하자.

Upgrade to the most recent Elasticsearch release (1.3.2 at this time): numerous indexing related issues have been fixed in recent releases.

가장 최근의 Elasticsearch release(1.3.2 at this time)로 upgrade하자. 가장 최근의 release에서는 index와 관련된 많은 문제가 해결되었다.

Before delving into the details, a caveat: remember that all the information here is up-to-date as of today (1.3.2), but as Elasticsearch is a fast moving target, this information may no longer be accurate when you, future Googler, come across it. If you are unsure, just come ask on the user's list.

세부 사항을 살펴보기 전에 주의 사항: 여기에 있는 모든 정보는 현재(1.3.2)의 최신 정보이지만, Elasticsearch는 빠르게 발전하고 있으므로, 이 정보는 더 이상 정확하지 않을 수 있다. 확신할 수 없다면, 여기에 질문하자.

Marvel is especially useful when tuning your cluster for indexing throughput: as you iterate on each setting described here you can easily visualize the impact of each change on your cluster's behavior.

Marvel 은 cluster에서 index 처리량을 튜닝할 경우 특히 유용하다. 여기에서 설명한 각각의 설정을 반복하면서 cluster의 동작에 각각의 변경 사항대한 영향을 쉽게 시각화할 수 있다.

Client side

Always use the bulk api, which indexes multiple documents in one request, and experiment with the right number of documents to send with each bulk request. The optimal size depends on many factors, but try to err in the direction of too few rather than too many documents. Use concurrent bulk requests with client-side threads or separate asynchronous requests.

항상 bulk api 를 사용하자. 이것은 하나의 request에 다수의 document를 index한다. 그리고, 각각의 bulk request로 보내는 적절한 수의 document를 테스트하자. 최적의 크기는 많은 요소에 의해 결정되지만, 너무 많은 document 보다는 너무 적은 document 부터 시행착오를 거치자. client의 thread를 통한 동시 bulk request나 별개의 비동기 request를 사용하자.

Before you conclude indexing is too slow, be sure you are really making full use of your cluster's hardware: use tools like iostat, top and ps to confirm you are saturating either CPU or IO across all nodes. If you are not then you need more concurrent requests, but if you hit EsRejectedExecutionException from the java client, or TOO_MANY_REQUESTS (429) HTTP response from REST requests, then you are sending too many concurrent requests. If you are using Marvel, you can see the rejection counts under the THREAD POOLS - BULK section of the Node Statistics Dashboard. It is usually not a good idea to increase the bulk thread pool size (defaults to the number of cores) as that will likely decrease overall indexing throughput; it is better to decrease client-side concurrency or add more nodes instead.

index가 너무 느리다고 결론내리기 전에, cluster의 HW를 충분히 사용하고 있는지 확인하자. iostat, top, ps를 사용하여 모든 node가 CPU나 IO를 충분히 사용하고 있는지 확인하자. 그렇지 않다면, 더 많은 동시 request가 필요하지만, java client에서 EsRejectedExecutionException 나 REST request에서 TOO_MANY_REQUESTS (429) HTTP response가 나타난다면, 너무 많은 동시 request를 보내고 있는 것이다. ma 을 사용하고 있다면, Node Statistics Dashboard 의 THREAD POOLS - BULK section에서 rejection count를 볼 수 있다. bulk thread pool 크기(기본값: core의 수)를 증가시키면, 전반적으로 index 처리량이 감소되므로, 일반적으로 좋지 않다. 대신 client의 동시성을 감소시키거나 node를 추가하는 것이 더 낫다.

Since the settings we discuss here are focused on maximizing indexing throughput for a single shard, it is best to first test just a single node, with a single shard and no replicas, to measure what a single Lucene index is capable of on your documents, and iterate on tuning that, before scaling it out to the entire cluster. This can also give you a baseline to roughly estimate how many nodes you will need in the full cluster to meet your indexing throughput requirements.

여기에서 설명하는 설정은 단일 shard에 대한 최대 index 처리량을 극대화하는데 중점을 두고 있기 때문에, 먼저 단일 shard를 가지고 있는, replica가 없는 단일 node에 대해서만 test하여, 여러분의 document에 대한 단일 Lucene index가 할 수 있는 용량을 측정하고, 전체 cluster로 확장하기 전에 이를 튜닝하는 것을 반복하는 것이 최선이다. 이렇게 하면, index 처리량 요구 사항을 충족하기 위해 전체 cluster에서 필요한 node의 수를 대략적으로 측정할 수 있는 기준을 마련할 수 있다.

Once you have a single shard working well, you can take full advantage of Elasticsearch's scalability and multiple nodes in your cluster by increasing the shard count and replica count.

단일 shard가 잘 작동하면, shard와 replica의 수를 증가시켜, Elasticsearch의 확장성과 cluster의 여러 node를 충분히 활용할 수 있다.

Before drawing any conclusions, be sure to measure performance of the full cluster over a fairly long time (say 60 minutes), so your test covers the full lifecycle including events like large merges, GC cycles, shard movements, exceeding the OS's IO cache, possibly unexpected swapping, etc.

결론을 내리기 전에 전체 cluster의 성능을 장시간(60분 정도)에 걸쳐 측정해야 한다. 그렇게 하면, test는 대량 merge, GC 주기, shard 이동, OS의 IO cache 초과, 예기치 않은 swapping 등의 event를 포함한 전체 상황을 다룬다.

Storage devices

Unsurprisingly, the storage devices that hold the index have a huge impact on indexing performance:

당연한 말이지만, index를 가지고 있는 storage device는 index 성능에 막대한 영향을 미친다.

• Use modern solid-state disks (SSDs): they are far faster than even the fastest spinning disks. Not only do they have lower latency for random access and higher sequential IO, they are also better at the highly concurrent IO that is required for simultaneous indexing, merging and searching.
  최신 SSD를 사용하자. SSD는 가장 빠른 HDD보다 훨씬 더 빠르다. random access에 대한 더 짧은 지연시간, 더 빠른 순차 IO를 가질 뿐만 아니라 , 동시 index, merge, search에 필요한 동시 IO도 더 우수하다.
• Do not place the index on a remotely mounted filesystem (e.g. NFS or SMB/CIFS); use storage local to the machine instead.
  원격 filesystem에 index를 두지 말자. (예: NFS 나 SMB/CIFS). 대신 machine의 local storage를 사용하자.
• Beware virtualized storage, such as Amazon's Elastic Block Storage. Virtualized storage works very well with Elasticsearch, and it is appealing since it is so fast and simple to set up, but it is also unfortunately inherently slower on an ongoing basis when compared to dedicated local storage. In a recent informal test, even the highest performance provisioned IOPS SSD-backed EBS option was still substantially slower than the local instance-attached SSD, and remember that the local instance-attached SSD is still shared across all virtual machines on that physical machine so you will see otherwise inexplicable slowdowns if the other virtual machines on that physical machine suddenly become IO intensive.
  아마존의 Elastic Block Storage 같은 가상화 storage를 주의하자. 가상화 storage Elasticsearch와 매우 잘 동작하며, 설치가 매우 빠르고 쉽기 때문에 매력적이지만, 전용 local storage와 비교해 보면, 불행하게도 본질적으로 더 느리다. 최근의 비공식적인 test에서, even the 최고의 성능이 제공되는 IOPS SSD가 지원되는 EBS 조차도 local에 연결된 SSD보다 여전히 훨씬 느렸다. 그리고, local에 연결된 SSD도 물리적 machine의 모든 가상 machine에 여전히 공유되므로, 해당 물리적 machine의 다른 가상 machine이 갑자기 IO가 증가하면 막대한 속도 저하를 보게 될 것이다.
• Stripe your index across multiple SSDs by setting multiple path.data directories, or just configure a RAID 0 array. The two are similar, except instead of striping at the file block level, Elasticsearch "stripes" at the individual index files level. Just remember that either approach increases the risk of failure for a single shard (to trade off for faster IO performance) since the failure of any one SSD destroys the index. This is typically the right tradeoff to make: optimize single shards for maximum performance, and then add replicas across different nodes so there's redundancy for any node failures. You can also use snapshot and restore to backup the index for further insurance.
  여러 개의 path.data directory를 설정하거나, RAID 0 array를 구성해 여러 개의 SSD에 index를 stripe 하자. file block 수준에서 stripe한다는 점을 제외하면, 개별 index file 수준에서의 Elasticsearch의 "stripes"와 이 2가지 방법은 유사하다. 2가지 접근 방식 모두 특정 단일 SSD의 장애는 index의 손상을 가져오기 때문에, 단일 shard에 대한 장애 위험(더 빠른 IO 성능으로 상쇄)이 증가한다는 점을 기억하자. 이것은 일반적으로 적절한 절충이다. 최대 성능을 위해 단일 shard를 최적화한 다음, 다른 여러 node에 replica를 추가하여, node 장애에 대비한 이중화를 실현한다. 추가 보장을 위해, index를 backup하는 snapshot과 restore를 사용할 수도 있다.

Segments and merging

Under the hood, newly indexed documents are first held in RAM by Lucene's IndexWriter. Periodically, when the RAM buffer is full, or when Elasticsearch triggers a flush or refresh, these documents are written to new on-disk segments. Eventually there are too many segments, and they are merged according to the merge policy and scheduler. This process cascades: the merged segments produce a larger segment, and after enough small merges, those larger segments are also merged. Here is a nice visualization of how this works.

새로 index된 document는 Lucene의 IndexWriter 에 의해 RAM에 우선 저장된다. RAM buffer가 가득 차거나 Elasticsearch flush 또는 refresh를 trigger할 경우, 주기적으로, 이들 document는 disk상의 새로운 segment에 기록된다. 결국 segment가 너무 많아지게 되면, merge 정책과 scheduler 에 따라 merge된다. 이 process는 단계적이다. merge된 segment는 더 큰 segment를 생성하고, 작은 merge가 충분히 수행된 후에, 이들 더 큰 segment도 merge된다. 이것이 동작하는 방법에 대한 멋진 그림이 여기 있다.

Merges, especially large ones, can take a very long time to run. This is normally fine, because such merges are also rare, so the amortized cost remains low. But if merging cannot keep up with indexing then Elasticsearch will throttle incoming indexing requests to a single thread (as of 1.2) to prevent serious problems when there are far too many segments in the index.

merge, 특히 큰 merge는 실행하는데 매우 오랜 시간이 걸릴 수 있다. 그런 merge는 물론 드믈기 때문에, 이것은 일반적으로 문제가 되지 않아, 그 비용은 작다. 그러나 merge가 index를 따라 갈 수 없을 경우, Elasticsearch는 index에 너무 많은 segment가 존재하는 심각한 문제를 방지하기 위해, 들어오는 index request를 단일 thread를 조절(1.2 기준)한다.

If you see INFO level log messages saying now throttling indexing or you see segment counts growing and growing in Marvel then you know merges are falling behind. Marvel plots the segment count under the MANAGEMENT EXTENDED section of the Index Statistics dashboard, and it should grow at a very slow logarithmic rate, perhaps showing a saw-tooth pattern as large merges complete:

Marvel 에서, now throttling indexing 라는 INFO 수준의 log message나 segment 수가 계속 증가하는 것이 나타나면, merge가 지연되고 있다는 것을 알 수 있다. Marvel은 Index Statistics dashboard 의 MANAGEMENT EXTENDED section 아래에 segment를 표시하고, 그것은 log 지수(logarithmic)의 비율로 매우 느리게 증가해야 한다. 큰 merge이 완료되면 톱니 모양을 보일 수도 있다.

Why would merges fall behind? By default, Elasticsearch limits the allowed aggregate bytes written across all merges to a paltry 20 MB/sec. For spinning disks, this ensures that merging will not saturate the typical drive's IO capacity, allowing concurrent searching to still perform well. But if you are not searching during your indexing, search performance is less important to you than indexing throughput or your index is on SSDs, you should disable merge throttling entirely by setting index.store.throttle.type to none; see store for details. Note that prior to 1.2, there was a nasty bug that caused merge IO throttling to be far more restrictive than you asked for. Upgrade!

왜 merge가 밀렸을까? 기본적으로, Elasticsearch는 모든 병합에 사용될 허용되는 총 byte를 겨우 20 MB/sec 로 제한한다. HDD의 경우, merge가 일반적인 drive의 IO 용량을 포화되지 않도록 하여, 동시 검색은 여전히 원할하게 수행된다. 그러나, index 중에 search를 하지 않거나, search 성능이 index 처리량보다 덜 중요하거나, index가 SSD에 있다면, index.store.throttle.type 에 none 을 설정하여, merge 조절을 완전히 비활성화해야 한다. 더 자세한 사항은 store 을 참고하자. 1.2 이전에는, merge IO 조절이 요청했던 것보다 훨씬 더 제한적으로 만드는 심각한 bug가 있었다. upgrade하자.

If you are unfortunately still using spinning disks, which do not handle concurrent IO nearly as well as SSDs, then you should set index.merge.scheduler.max_thread_count to 1. Otherwise, the default value (which favors SSDs) will allow too many merges to run at once.

아직 SSD만큼 동시 IO를 처리하지 못하는 HDD를 사용하는 경우, index.merge.scheduler.max_thread_count 를 1 로 설정래야 한다. 그렇지 않고, 기본 값을 사용(SSD에 유리)하면, 한 번에 너무 많은 merge가 실행될 수 있다.

Do not call optimize on an index that is still being actively updated, since it is a very costly operation (it merges all segments). However, if you are done adding documents to a given index, it is a good idea to optimize it at that point, since that will reduce resources required during searching. For example, if you are using time-based indices where each day's worth of logs is added to a new index, once that day has passed, it is a good idea to optimize the index, especially if nodes will hold many days worth of indices.

여전히 update되고 있는 index에 optimize 를 실행하지 말자. 비용이 매우 많이 드는 연산(모든 segment를 merge한다.)이기 때문이다. 그러나, 해당 index에 document가 완료된 경우에는, 해당 시점에 optimize를 실행하는 것은 좋은 방법이다. 왜냐하면, search에 요구되는 reduce가 감소하기 때문이다. 예를 들어, 시계열 index를 사용하여, 각 날짜 분량의 log를 새로운 index에 추가되는 경우, 해당 날짜가 지나면, index를 optimize하는 것이 좋다. 많은 날짜 분량의 index를 가지고 있다면, 특히 그렇다.

Here are some further settings to tune:

다음은 몇 가지 추가로 조정해야 할 설정이다.

• Tune your mappings to turn off any fields you do not actually need, such as disabling the _all field. For fields you would like to keep, you can also tune whether and how they are indexed or stored.
  field의 비활성화처럼 실제로 필요하지 않은 field를 끄도록 mapping을 조정하자. 유지해야 하는 field는 index 또는 store로 조정할 수도 있다.
• You may be tempted to disable the _source field, but its indexing cost is likely small (just stored, not indexed), and it has substantial value for future updates or for fully re-indexing a previous index, so it is typically not worth disabling unless disk usage is a concern, which it should not be since disk is relatively cheap.
  _source field를 비활성화하려 할 수도 있겠지만, index 비용은 작고(store만 하고 index는 하지 않는), 향후 update나 이전의 index를 완전히 다시 index하는 경우 상당한 가치가 있다. 따라서, disk 사용량이 문제가 되지 않는다면, 비활성화할 가치가 없다. disk가 상대적으로 저렴하기 때문에 그렇게 하지 않아야 한다.
• If you can accept some delay in searching recently indexed documents, increase index.refresh_interval to 30s, or disable it entirely by setting it to -1. This allows larger segments to flush and decreases future merge pressure.
  최근에 index된 document를 search하는데 있어 약간의 지연을 허용할 수 있다면, index.refresh_interval 을 30s 로 증가시키거나, -1 로 설정하여 완전히 비활성화하자. 이렇게 하면, 더 큰 segment를 flush하고 향후 merge에 대한 부담이 감소한다.
• As long as you have upgraded to at least Elasticsearch 1.3.2, which fixes issues that could cause excessive RAM usage when flushes are infrequent, increase index.translog.flush_threshold_size from the default (currently 200 mb) to 1 gb, to decrease how frequently fsync is called on the index files.
  Marvel plots the flush rate under the MANAGEMENT section of the Index Statistics dashboard.
  flush가 자주 발생하지 않는 경우, 과도한 RAM 사용아 야기될 수 있는 문제를 수정한, 최소한 Elasticsearch 1.3.2 로 upgrade한 경우, index에서 fsync를 호츨하는 반도를 줄일 수 있는, index.translog.flush_threshold_size 를 기본값(현재 200 mb)에서 1gb 로 증가시키자. Marvel은 Index Statistics dashboard의 MANAGEMENT section에서 flush 속도를 나타낸다.
• Use 0 replicas while building up your initial large index, and then enable replicas later on and let them catch up. Just beware that a node failure when you have 0 replicas means you have lost data (your cluster is red) since there is no redundancy. If you plan to call optimize (because no more documents will be added), it is a good idea to do that after finishing indexing and before increasing the replica count so replication can just copy the optimized segment(s). See update index settings for details.
  초기에 대형 index를 만드는 경우, replica를 0으로 하자. 그리고, 나증에 replica를 활성화하도록 하자. 단, replica가 0이라는 것은, node 장애 시 중복이 없기 때문에, data의 손실(cluster는 red이다)로 이어진다는 것에 유의하자. optimize 를 호출할 계획(더 이상 document가 추가되지 않아서)이라면, index를 완료한 후, replica 수를 증가시키기 전에, 하는 것이 좋다. 그렇게 하면, replication은 optimize된 segment만을 복사할 수 있다. 자세한 사항은 update index settings을 참고하자

Index buffer size

If your node is doing only heavy indexing, be sure indices.memory.index_buffer_size is large enough to give at most ~512 MB indexing buffer per active shard (beyond that indexing performance does not typically improve). Elasticsearch takes that setting (a percentage of the java heap or an absolute byte-size), and divides it equally among the currently active shards on the node subject to min_index_buffer_size and max_index_buffer_size values; larger values means Lucene writes larger initial segments which reduces future merge pressure.

node가 대량 index만 수행하고 있다면, indices.memory.index_buffer_size 가 활성 shard당 최대 512 MB(이 값 이상이어도, 일반적으로 index 성능은 개선되지 않는다)의 index buffer에 제공할 수 있을만큼 충분한지 확인하자. 

The default is 10% which is often plenty: for example, if you have 5 active shards on a node, and your heap is 25 GB, then each shard gets 1/5th of 10% of 25 GB = 512 MB (already the maximum). After dedicated heavy indexing, lower this setting back to its default (currently 10%) so search-time data structures have plenty of RAM to use. Note that this is not yet a dynamic setting; there is an issue open to fix that.

기본값은 10% 이며, 대개 이 정도로 충분하다. 예를 들어, node에 5개의 active shard를 가지고 있고, heap이 25GB 라면, 각 shard는 25 GB의 10%의 1/5인 512 MB(이미 최대)를 갖는다. 대량 index 후에, 이 설정을 기본값(현재 10%)으로 다시 낮추면, search시 data 구조에 사용할 RAM은 충분하다. 이것은 아직 동적 설정이 아니라는 점에 유의하자. 수정해야 할 문제가 있다.

The number of bytes currently in use by the index buffer was added to the indices stats API in 1.3.0. You can see it by looking at the indices.segments.index_writer_memory value. This is not yet plotted in Marvel and will be added in the coming version, but you can add a chart yourself (Marvel still collects the data).

index buffer에 현재 사용되는 byte의 수가 1.3.0 의 indices stats API에 추가되었다. indices.segments.index_writer_memory 의 값을 보면 알 수 있다. 이것은 아직 Marvel에서는 표시되지 않으며, 향후 version에 추가될 것이다. 그러나 직접 chart에 추가할 수 있다. (Marvel은 현재 data를 수집하고 있다)

Coming in 1.4.0, the indices stats API also shows exactly how much RAM buffer was allocated to each active shard as indices.segments.index_writer_max_memory. To see these values per-shard for a given index, use the http://host:9200/<indexName>/_stats?level=shards; this will return the stats per shard as well as the totals across all shards.

향후 출시될 1.4.0 에서, indices stats API 는 각 활성화된 shard에 할당된 RAM buffer의 양을 indices.segments.index_writer_max_memory 에서, 정확히 보여준다. 해당 index에 대해 shard별 값을 확인하려면, http://host:9200/<indexName>/_stats?level=shards 을 사용하자. 이것은 shard 별 stats 뿐만 아니라, 모든 shard의 합을 return한다.

Use auto id or pick a good id

If you do not care what id your documents have, let Elasticsearch automatically assign them: this case is optimized (as of 1.2) to save an ID and version lookup per document, and you can see the performance difference in Elasticsearch's nightly indexing benchmarks (compare the Fast and FastUpdate lines).

document id 가 중요하지 않다면, Elasticsearch가 자동으로 할당하도록 하자. 이 경우는 document별로 ID와 version을 저장하도록 최적화되며(1.2 기준), Elasticsearch의 nightly indexing benchmarks (Fast 와 FastUpdate line을 비교하자)에서 성능 차이를 확인할 수 있다.

If you do have your own ids, try to pick one that is fast for Lucene if that is under your control, and upgrade to at least 1.3.2 since there were further optimizations to id lookup. Just remember that java's UUID.randomUUID() is the worst choice for an id because it has no predictability or pattern on how ids are assigned to segments, causing a seek per segment in the worst case.

자신의 id가 있다면, 관리가 가능한 Lucene에서 빠른 것을 고르도록 하고, id 조회에 더욱 최적화된화된, 최소한 1.3.2로 upgrade하자. java의 UUID.randomUUID()는 id를 segment에 할당하는 예측 가능성이나 pattern이 없어, id에는 최악의 선택이다. 이는 최악의 경우 segment별 검색을 발생시킨다.

You can see the difference in indexing rate as reported by Marvel when using Flake IDs:

Flake IDs 를 사용하는 경우, Marvel에서 index 속도 차이를 볼 수 있다.

versus using fully random UUIDs:

완전한 random UUIDs를 사용하는 경우

Coming in 1.4.0, we have switched Elasticsearch's auto-generated IDs from random UUIDs to Flake IDs.

향후 출시될 1.4.0에서, Elasticsearch의 자동 생성 ID를 random UUIDs에서 Flake IDs로 변경했다.

If you are curious about the low-level operations Lucene is doing on your index, try enabling lucene.iw TRACE logging (available in 1.2). This produces very verbose output but can be helpful to understand what is happening at the Lucene IndexWriter level. The output is very low-level; Marvel provides a much better real-time graphical view on what is happening to the index.

index에서 진행되고 있는 Lucene의 낮은 수준의 연산에 대해 궁금한 점이 있다면, lucene.iw TRACE logging을 활성화 (1.2에서 이용 가능)하자. 이것은 매우 자세한 출력을 생성하지만, Lucene의 IndexWriter 수준에서 발생하는 것을 이해하는데 도움이 된다. 이 출력은 매우 낮은 수준이다. Marvel은 index에서 벌어지는 것을 더욱 나아진 실시간 그래픽으로 제공한다.

Scaling out

Remember, we focused here on tuning performance for a single shard (Lucene index) but once you are happy with that, where Elasticsearch really shines is in easily scaling out your indexing and searching across a full cluster of machines. So be sure to increase your shard count again (the default is currently 5), which buys you concurrency across machines, a larger maximum index size, and lower latency when searching. Also remember to increase your replicas to at least 1 so you have redundancy to hardware failures.

여기에서는 단일 shard(Lucene Index)에 대한 성능 조정에 중점을 두었지만, 일단 그것이 만족되면, Elasticsearch가 실제로 빛나는 부분은 index와 search를 쉽게 전체 cluster 시스템으로 확장할 수 있다는 점이다. 따라서, shard 수(현재 default는 5)를 늘리면, 동시성, 더 큰 최대 index 크기, search 시의 낮은 대기 시간을 얻을 수 있다. 또한, replica를 최소한 1로 증가시키면, HW 장애에 대비한 중복성을 확보할 수 있다.

Finally, if you are still having trouble, get in touch, e.g. through the Elasticsearch user list. Maybe there is an exciting bug to fix (patches are always welcome!).

마지막으로, 여전히 문제를 가지고 있다면, Elasticsearch user list를 통해 문의하자. 아마도 수정해야 할 흥미로운 bug가 있을 것이다.

원본: Performance Considerations for Elasticsearch Indexing