1. General recommendations

Don’t return large result sets

Elasticsearch is designed as a search engine, which makes it very good at getting back the top documents that match a query. However, it is not as good for workloads that fall into the database domain, such as retrieving all documents that match a particular query. If you need to do this, make sure to use the  Scroll API.

Elasticsearch는 search 엔진으로 설계되어, query에 일치하는 최장위 document를 가져오는데 매우 효과적이다. 그러나, 특정 query에 일치하는 모든 document를 가져오는 것 같은 database 영역에 포함되는 작업에는 적절하지 않다. 이런 작업이 필요하다면  Scroll API를 사용하자.

Avoid large documents

Given that the default  http.max_content_length is set to 100MB, Elasticsearch will refuse to index any document that is larger than that. You might decide to increase that particular setting, but Lucene still has a limit of about 2GB.

http.max_content_length의 기본값은 100MB인데, Elasticsearch는 이보다 큰 document의 index를 거부한다. 해당 설정을 늘릴수도 있지만, Lucene은 약 2GB의 제한을 가진다.

Even without considering hard limits, large documents are usually not practical. Large documents put more stress on network, memory usage and disk, even for search requests that do not request the _source since Elasticsearch needs to fetch the _id of the document in all cases, and the cost of getting this field is bigger for large documents due to how the filesystem cache works. Indexing this document can use an amount of memory that is a multiplier of the original size of the document. Proximity search (phrase queries for instance) and  highlighting also become more expensive since their cost directly depends on the size of the original document.

엄격한 제한을 고려하지 않더라도, 큰 document는 실용적이지 않다. Elasticsearch는 모든 경우에 대해 document의 _id를 가져와야 하기 때문에, 큰 document는 _source를 request하지 않는 search request에 대해서도 network, memory 사용량, disk에 더 많은 부담을 준다. 그리고 filesystem cache가 동작하는 방법 때문에, 이 field를 가져오는 비용은  큰 document에서 더 크다. 이 dicument를 index하면 document 원래 크기의 배에 해당하는 memory를 사용할 수 있다. proximity search(예를 들자면, phrase query)와  highlighting 또한, 원래 document의 크기에 따라 달라지기 때문에 더 많은 비용이 소모된다.

It is sometimes useful to reconsider what the unit of information should be. For instance, the fact you want to make books searchable doesn’t necesarily mean that a document should consist of a whole book. It might be a better idea to use chapters or even paragraphs as documents, and then have a property in these documents that identifies which book they belong to. This does not only avoid the issues with large documents, it also makes the search experience better. For instance if a user searches for two words foo and bar, a match across different chapters is probably very poor, while a match within the same paragraph is likely good.

때로는 정보 단위가 되어야 하는 것을 재검토하는 것이 유용하다. 예를 들어, 책을 검색 가능하게 만들고 싶다는 사실이 document가 전체 책으로 구성되어야 한다는 것을 의미하지는 않는다. 장이나 단락을 document로 하는 것이 더 나은 생각일수도 있고, 그 다음에 그들이 속한 책을 식별할 수 있는 속성을 document에 가지고 잇어야 한다. 이렇게 하면 큰 document가 가지는 문제를 피할 수 있을뿐 아니라 search도 더 나아진다. 예를 들어, 사용자가 2개의 단어 foo와 bar를 search한다면, 서로 다른 장에 걸친 match의 결과는 매우 빈약할 수 있지만, 동일한 단락 내의 match는 좋을 수 있다.

원문: General recommendations