2015.11.03 - 번역 - Performance Considerations for Elasticsearch 2.0 Indexing ...

A little over a year ago I described how to maximize indexing throughput with Elasticsearch, but a lot has changed since then so here I explain the changes that affect indexing performance in Elasticsearch 2.0.0.

약 1년전, Elasticsearch에서 처리량을 최대화하는 방법에 대해 설명한 적이 있다. 그런데, 그때에 비해 많은 것이 변경되어, 여기에서 Elasticsearch 2.0.0 에서 index 성능에 영향을 미치는 변경 사항에 대해 설명한다.

Store throttling is now automatic

Prior to 2.0.0, Elasticsearch throttled ongoing merges at fixed rate (20 MB/sec by default), but this was often far too low and would easily lead to merges falling behind and subsequent index throttling.

2.0.0 이전에서, Elasticsearch는 고정 속도(기본값: 20 MB/sec)로 merge를 조절했다. 그러나, 이 값은 너무 낮아서, 쉽게 merge의 지연과 그 다음 index 조절을 초래한다.

As of 2.0.0, Elasticsearch now uses adaptive merge IO throttling: when merges are starting to fall behind, the allowed IO rate is increased, and decreased when merges are keeping up. This means a sudden but rare large merge on a low-throughput indexing use case should not saturate all available IO on the node, minimizing impact to ongoing searches and indexing.

2.0.0 에서, Elasticsearch는 이제 적응형 merge IO 조절을 사용한다. merge가 지연되기 사작하면, 허용되는 IO 속도가 증가하고, merge가 유지되면 감소한다. 즉, 처리량이 낮은 index 사용 사례에서 갑작스러운 그러나 드문 대량 merge가 node의 모든 사용가능한 IO를 포화시키지 않도록하여, 진행중인 search와 index에 미치는 영향을 최소화하는 것이다.

But for heavy indexing, the allowed merge IO will increase to match the ongoing indexing.

그러나, 대량 index에 대해서는, 허용되는 merge IO가 진행중인 index와 보조를 맞추어 증가한다.

This is good news!  It means you shouldn't need to touch any throttling settings: just use the defaults.

이것은 좋은 소식이다. 즉, 조절 설정을 건드릴 필요가 없다. 그냥 기본값을 사용하자.

Multiple path.data

Using multiple IO devices (by specifying multiple path.data paths) to hold the shards on your node is useful for increasing total storage space, and improving IO performance, if that's a bottleneck for your Elasticsearch usage.

node에서 shard를 유지하기 위해 다수의 ID 장치를 사용(다수의 path.data path를 지정)하는 것은 총 저장 공간을 늘리고 IO 성능을 개선하는데 유용하다. 특히 Elasticsearch 사용에 bottleneck이 있는 경우에.

With 2.0, there is an important change in how Elasticsearch spreads the IO load across multiple paths: previously, each low-level index file was sent to the best (default: most empty) path, but now that switch is per-shard instead.  When a shard is allocated to the node, the node will pick which path will hold all files for that shard.

2.0 에서, Elasticsearch가 다수의 경로에 IO 부하를 분산하는 방법에 중요한 변경이 있다. 이전에는 각 low-level index file은 최상의 경로(기본값: 가장 많이 비어 있는 경로)로 전송되었지만, 지금은 shard별로 바뀌었다. shard가 node에 할당되면, node는 해당 shard의 모든 file을 저장할 경로를 선택한다.

The improves resiliency to IO device failures: if one of your IO devices crashes, now you'll only lose the shards that were on it, whereas before 2.0 you would lose any shard that had at least one file on the affected device (typically this means nearly all shards on that node).

IO 장치 장애시 복원력의 개선이다. IO 장치 중의 하나에 장애가 발생하면, 거기에 있는 shard만 손실되지만, 2.0 이전에는 영향을 받은 장치에 최소한 하나의 file이 있는 모든 shard가 손실된다. 일반적으로 이는 node에 있는 거의 모든 shard이다.

Note that an OS-level RAID 0 device is also a poor choice as you'll lose all shards on that node when any device fails, since files are striped at the block level, so multiple path.data is the recommended approach.

OS 수준의 RAID 0 장치는, file이 block level에서 분산되므로, 특정 장치에 장애가 발생할 경우, node의 모든 shard를 잃어버리기 때문에 좋지 않은 선택이다. 따라서, 다수의 path.data가 권장되는 방식이다.

You should still have at least 1 replica for your indices so you can recover the lost shards from other nodes without any data loss.

data 손실없이 다른 node에서 손실된 shard를 복구할 수 있도록, index에 최소한 1개 이상의 replica를 가져야 한다.

The Auto-ID optimization is removed

Previously, Elasticsearch optimized the auto-id case (when you didn't provide your own id for each indexed document) to use append-only Lucene APIs under-the-hood, but this proved problematic in error cases and so we removed it.

이전에는, Elasticsearch가 추가 전용 Lucene API를 사용하기 위하여 auto-id case(index된 각 document에 대하여 자신의 id를 제공하지 않을 경우)를 최적화했다. 그런데, 오류 발생시 문제가 있어 이를 제거했다.

We also greatly improved ID lookup performance so that this optimization was no longer so important, and this allowed us to remove bloom filters entirely as they consumed non-trivial heap but didn't offer much ID lookup performance gain.

또한, ID lookup 성능이 크게 개선되어, 이 최적화는 더 이상 그렇게 중요하지 않게 되었다. 그리고, 이로 인해 bloom filters를 완전히 제거했다. bloom filter는 적지 않은 heap을 소모하지만 ID lookup 성능 향상은 크지 않다.

Finally, as of 1.4.0, Elasticsearch now uses Flake IDs to generate its IDs, for better lookup performance over the previous UUIDs.

마지막으로, 1.4.0 부터 Elasticsearch는 이전 UUID보다 나은 ID lookup 성능을 위해, ID 생성시 Flake ID를 사용한다.

All of this means you should feel free to use your own id field, with no performance penalty due to the now removed auto-id handling, but just remember that your choice of id field values does affect indexing performance.

이 모든 것은 이제 auto-id 처리가 제거되었기 때문에 성능상의 불이익 없이, 자신의 id field를 자유롭세 이용할 수 있다는 것을 의미하지만, id field 값을 선택하면 index 성능에 영향을 미친다는 점을 기억하자.

More indexing changes...

Beyond these changes there have been a great many additional 2.0 indexing changes such as: enabling doc values by default (instead of using CPU- and heap-costly field data at search time), moving the dangerous delete-by-query API from a core API to a safe plugin on top of the bulk indexing API, exposing control over increased stored fields compression while indexing, better compression of sparse doc values and norms, reducing heap required when merging and a number of improvements in resiliency such as detecting pre-existing index corruption when merging.

이러한 변경 사항외에도, 2.0 에서는 index에 다음과 같은 많은 추가 변경사항이 있다. doc values를 기본으로 활성화 by default (대신, search시에 CPU, heap에 비용이 드는 field data를 사용), 위험성이 있는 delete-by-query API를 core API에서 안전한 bulk indexing API 상의 plugin으로 이동, index하는 동안 증가된 stored field 압축에 대한 제어 노출, 드문 doc values와 norms 에 대한 향상된 압축, merge시에 필요한 heap의 감소, merge시 기존 index 손상 탐지 같은 복원력 향상.

If you are curious about the low-level Lucene actions while indexing, add index.engine.lucene.iw: TRACE to your logging.yml, but be warned: this generates impressively copious output!

index시에 Lucene의 low-level 동작에 대해 궁금하다면, logging.yml 에 index.engine.lucene.iw: TRACE 을 추가하자. 단, 이렇게 하면 엄청난 양의 출력이 생성된다.

Our nightly indexing performance charts shows that we are generally moving in the right direction with our defaults over time: the docs/sec and segment counts for the defaults (4 GB) heap has caught up to the fast performance line.

nightly indexing performance charts는 시간이 경과함에 따라, 올바른 방향으로 이동하고 있음을 보여준다. 기본(4GB) heap에서 시간당 document수(docs/sec)와 segment 수는 fast 성능 라인까지 도달했다.

원문: Performance Considerations for Elasticsearch 2.0 Indexing