不爲也 比不能也

Elasticsearch is used by some companies to index and search petabytes of data every day, but most of us start out with something a little more humble in size. Even if we aspire to be the next Facebook, it is unlikely that our bank balance matches our aspirations. We need to build for what we have today, but in a way that will allow us to scale out flexibly and rapidly.Elasticsearch는 일부 기업에서 매일 수..

In Dynamically Updatable Indices, we explained that a shard is a Lucene index and that an Elasticsearch index is a collection of shards. Your application talks to an index, and Elasticsearch routes your requests to the appropriate shards.Dynamically Updatable Indices에서, shard는 Lucene의 index 이고, Elasticsearch의 index는 shard의 집합이라고 설명했었다. 응용프로그램이 index에 request하면, Elasticsearch는 적절한 shard에 해당 reque..

A shard lives on a single node, but a node can hold multiple shards. Imagine that we created our index with two primary shards instead of one:shard는 단일 node에 존재하지만, node는 여러 개의 shard를 가질 수 있다. 하나가 아닌 두 개의 primary shard를 가진, index를 생성했다고 가정해 보자.PUT /my_index { "settings": { "number_of_shards": 2, "number_of_replicas": 0 } }replica shard 없이, 두 개의 primary shard를 가진 index를 생성With a single node, both..

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를 할당..

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

Up until now we have spoken only about primary shards, but we have another tool in our belt: replica shards. The main purpose of replicas is for failover, as discussed in Life Inside a Cluster: if the node holding a primary shard dies, a replica is promoted to the role of primary.지금까지는 primary shard에 대해서만 이야기했다. 그러나 replica shard라는 또 다른 도구를 가지고 있다. Life Inside a Cluster에서 언급했지만, replica shard의 주..

Finally, remember that there is no rule that limits your application to using only a single index. When we issue a search request, it is forwarded to a copy (a primary or a replica) of all the shards in an index. If we issue the same search request on multiple indices, the exact same thing happens—there are just more shards involved.마지막으로, 응용프로그램이 단일 index만을 사용하도록 제한하는 규칙은 없다는 점을 기억하자. 어떤 검색 req..

One of the most common use cases for Elasticsearch is for logging, so common in fact that Elasticsearch provides an integrated logging platform called the ELK stack—Elasticsearch, Logstash, and Kibana—to make the process easy.Elasticsearch에 대한 가장 일반적인 사용 사례는 logging이다. Elasticsearch는, 프로세스를 쉽게 만들기 위해, ELK stack(Elasticsearch, Logstash, Kibana)라 불리는 통합 로깅(logging) 플랫폼을 제공한다.Logstash collects, par..

Elasticsearch doesn’t require you to create an index before using it. With logging, it is often more convenient to rely on index autocreation than to have to create indices manually.Elasticsearch는 index를 사용하기 전에, index를 생성할 필요가 없다. 로깅에서는, index 자동 생성이, 수동으로 생성하는 것보다, 더 편리하다.Logstash uses the timestamp from an event to derive the index name. By default, it indexes into a different index every day..

As time-based data ages, it becomes less relevant. It’s possible that we will want to see what happened last week, last month, or even last year, but for the most part, we’re interested in only the here and now.시간 기반의 데이터는 오래 될수록, 관련성이 적어진다. 지난 주, 지난 달, 심지어 지난해에 무슨 일이 있었는지 알고 싶을 수도 있지만, 대부분의 경우, 지금, 여기에만 관심이 있다.The nice thing about an index per time frame is that it enables us to easily delete o..