不爲也 比不能也

Elasticsearch supports a wide range of use-cases across our user base, and more and more of these rely on fast indexing to quickly get large amounts of data into Elasticsearch. Even though Elasticsearch is fast and index performance is continually improved, it is still possible to overwhelm it. At that point you typically see parts of bulk requests getting rejected. In this blog post we will loo..

Engineers can resist anything except giving their processes more resources: bigger, better, faster, more of cycles, cores, RAM, disks and interconnects! When these resources are not a bottleneck, this is wasteful but harmless. For processes like Elasticsearch that run on the JVM, the luring temptation is to turn the heap up; what harm could possibly come from having more heap? Alas, the story is..

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

Use bulk requests Bulk requests will yield much better performance than single-document index requests. In order to know the optimal size of a bulk request, you should run a benchmark on a single node with a single shard. First try to index 100 documents at once, then 200, then 400, etc. doubling the number of documents in a bulk request in every benchmark run. When the indexing speed starts to ..

Rivers have been removededitElasticsearch does not support rivers anymore. While we had first planned to keep them around to ease migration, keeping support for rivers proved to be challenging as it conflicted with other important changes that we wanted to bring to 2.0 like synchronous dynamic mappings updates, so we eventually decided to remove them entirely. See Deprecating Rivers for more bac..

In the same way that mget allows us to retrieve multiple documents at once, the bulk API allows us to make multiple create, index, update, or delete requests in a single step. This is particularly useful if you need to index a data stream such as log events, which can be queued up and indexed in batches of hundreds or thousands.mget 이 다수의 document를 한번에 가져오는 것과 마찬가지로, bulk API는 다수의 create, index,..

The patterns for the mget and bulk APIs are similar to those for individual documents. The difference is that the coordinating node knows in which shard each document lives. It breaks up the multidocument request into a multidocument request per shard, and forwards these in parallel to each participating node.mget 이나 bulk API의 형태는 개별 document의 그것과 유사하다. coordinating node는 document가 어느 shard에 있는지..

Although you can add new types to an index, or add new fields to a type, you can’t add new analyzers or make changes to existing fields. If you were to do so, the data that had already been indexed would be incorrect and your searches would no longer work as expected.index에 새로운 type을 추가하거나 type에 새로운 field를 추가할 있지만, 새로운 analyzer를 추가하거나 기존 field를 변경할 수 없다. 그렇게 하면, 기존의 색인 데이터는 올바르지 않게 되고, 검색은 더 이상 ..

Big, popular forums start out as small forums. One day we will find that one shard in our shared index is doing a lot more work than the other shards, because it holds the documents for a forum that has become very popular. That forum now needs its own index.거대한 인기 있는 포럼은 작은 포럼으로 시작한다. 어느 날, 공유 index의 어떤 shard가 다른 shard보다 훨씬 더 많은 작업을 하고 있는 것을 발견했다. 왜냐하면, 해당 shard가 매우 인기 있는 포럼의 document를 가지고 있기 때..

Cluster-health is at one end of the spectrum—a very high-level overview of everything in your cluster. The node-stats API is at the other end. It provides a bewildering array of statistics about each node in your cluster.cluster-health 는 cluster의 모든 것에 대한 매우 높은 수준의 개요 부분이다. node-stats API는 또 다른 부분이다. 이것은 cluster의 각 node에 대한 복잡한 통계의 배열을 제공한다.Node-stats provides so many stats that, until you are a..