6-4-04. Capacity Planning

If 1 shard is too few and 1,000 shards are too many, how do I know how many shards I need? This is a question that is impossible to answer in the general case. There are just too many variables: the hardware that you use, the size and complexity of your documents, how you index and analyze those documents, the types of queries that you run, the aggregations that you perform, how you model your data, and more.

1개의 shard는 너무 적고, 1,000개의 shard는 너무 많다면, 필요한 shard의 수를 어떻게 알 수 있는가? 일반적인 경우에, 이것은 답하기가 불가능한 질문이다. 사용하는 H/W, document의 크기와 복잡성, 해당 document를 색인하고 분석하는 방법, 실행할 query의 종류, 수행할 aggregation, 데이터의 설계 방법 등의 너무나 많은 변수가 있다.

Fortunately, it is an easy question to answer in the specific case—yours:

다행히도, 특정 경우에는 답변이 가능하다.

1. Create a cluster consisting of a single server, with the hardware that you are considering using in production.

   제품에 사용을 고려중인 H/W에, 단일 서버로 구성된 cluster를 생성하자.

2. Create an index with the same settings and analyzers that you plan to use in production, but with only one primary shard and no replicas.

   제품에 사용하려는 것과 동일한 설정과 analyzer를 가진, 그러나, replica 없이 하나의 primary shard만을 가진 index를 생성하자.

3. Fill it with real documents (or as close to real as you can get).

   그것을 실제 (또는 실제에 가까운) document로 채우자.

4. Run real queries and aggregations (or as close to real as you can get).

   실제 (또는 실제에 가까운) query와 aggregation을 실행하자.

Essentially, you want to replicate real-world usage and to push this single shard until it "breaks". Even the definition of breaks depends on you: some users require that all responses return within 50ms; others are quite happy to wait for 5 seconds.

기본적으로, 실제 사용을 모방하여, 이 단일 shard에 "문제가 발생할" 때까지 그것에 부하를 주자. 문제가 발생한다 의 정의는 여러분이 판단해야 한다. 어떤 사용자는 모든 response가 50ms 안에 반환되어야 한다고 요구하고, 또 다른 이들은 5s를 기다려도 매우 행복해 한다.

Once you define the capacity of a single shard, it is easy to extrapolate that number to your whole index. Take the total amount of data that you need to index, plus some extra for future growth, and divide by the capacity of a single shard. The result is the number of primary shards that you will need.

일단 단일 shard의 용량을 정의하면, 전체 index의 shard 수를 추정하는 것은 쉽다. 색인하려는 데이터의 총량을 구하고, 미래에 추가될 여분을 더한 다음, 단일 shard의 용량으로 나눈다. 그 결과가 필요한 primary shard의 수이다.

Capacity planning should not be your first step.

용량을 계획하는 것은 첫 번째 단계가 아니다.

First look for ways to optimize how you are using Elasticsearch. Perhaps you have inefficient queries, not enough RAM, or you have left swap enabled?

Elasticsearch를 사용하는 방법을 최적화하는 방법을 먼저 살펴보자. 아마도, 비효율적인 query, 충분하지 않은 RAM을 가지고 있는지? 또는 swap을 활성화하고 있는지?

We have seen new users who, frustrated by initial performance, immediately start trying to tune the garbage collector or adjust the number of threads, instead of tackling the simple problems like removing wildcard queries.

초기에 성능 문제로 좌절하는 새로운 사용자를 살펴보면, wildcard query를 제거하는 것 같은 간단한 문제를 해결하는 대신, garbage collector를 조율하거나 thread 수를 조정하는 작업을 바로 시작하곤 한다.