The first thing that new users do when they learn about shard overallocation is to say to themselves:
새로운 사용자가 shard 초과 할당에 대해 배울 때, 처음 하는 일은, 다음과 같이 결정하는 것이다.
I don’t know how big this is going to be, and I can’t change the index size later on, so to be on the safe side, I’ll just give this index 1,000 shards… 이것이 앞으로 얼마나 커질지 잘 모르겠다. 나중에 index 크기를 변경할 수 없으니, 안전하게 하기 위해, 이 index에 1,000개의 shard를 할당해야겠다. |
||
-- 새로운 사용자 |
One thousand shards—really? And you don’t think that, perhaps, between now and the time you need to buy one thousand nodes, that you may need to rethink your data model once or twice and have to reindex?
1,000개의 shard라 … 진짜? 그렇다면, 아마도, 현재와 1,000개의 node 를 구매해야 할 시간 사이에, 데이터 모델을 한두 번 재고하고, 재색인해야 한다는 것을 생각하지 않은 것이다.
A shard is not free. Remember:
shard는 공짜가 아니다. 다음 사항을 기억하자.
A shard is a Lucene index under the covers, which uses file handles, memory, and CPU cycles.
shard는 file handle, 메모리, CPU를 사용하는, 내부적으로는 Lucene의 index이다.
Every search request needs to hit a copy of every shard in the index. That’s fine if every shard is sitting on a different node, but not if many shards have to compete for the same resources.
모든 검색 request는 index에 있는 모든 shard의 복사본을 액세스해야 한다. 모든 shard가 서로 다른 node에 있다면 괜찮겠지만, 많은 shard가 동일한 자원을 사용한다면, 그렇지 않다.
Term statistics, used to calculate relevance, are per shard. Having a small amount of data in many shards leads to poor relevance.
relevance를 계산하는데 사용되는, 단어 통계는 shard별이다. 많은 shard에 소량의 데이터를 가지는 것은 빈약한 relevance로 이어진다.
A little overallocation is good. A kagillion shards is bad. It is difficult to define what constitutes too many shards, as it depends on their size and how they are being used. A hundred shards that are seldom used may be fine, while two shards experiencing very heavy usage could be too many. Monitor your nodes to ensure that they have enough spare capacity to deal with exceptional conditions.
약간의 초과 할당은 좋다. 너무 많은 shard는 좋지 않다. 크기와 사용되는 방법에 따라, 어느 정도가 너무 많은 shard인지를 정의하기는 어렵다. 거의 사용하지 않는 100개의 shard는 잘 동작하겠지만, 사용량이 매우 많은 두 개의 shard는 터무니없다. 예외 상황을 처리하기에 충분한 예비 용량을 가지고 있는지를 확인하기 위하여, node를 관찰하기 바란다.
Scaling out should be done in phases. Build in enough capacity to get to the next phase. Once you get to the next phase, you have time to think about the changes you need to make to reach the phase after that.
수평 확장(Scale Out)은 단계적으로 해야 한다. 다음 단계로 가기 위한, 충분한 용량으로 만들자 일단, 다음 단계로 가게 되면, 그 이후 단계에 도달하기 위해, 필요한 변화에 대해 생각하는 시간을 가지도록 하자.
'2.X > 6. Modeling Your Data' 카테고리의 다른 글
6-4-01. The Unit of Scale (0) | 2017.09.23 |
---|---|
6-4-02. Shard Overallocation (0) | 2017.09.23 |
6-4-04. Capacity Planning (0) | 2017.09.23 |
6-4-05. Replica Shards (0) | 2017.09.23 |
6-4-06. Multiple Indices (0) | 2017.09.23 |