4-11. Closing Thoughts

This section covered a lot of ground, and a lot of deeply technical issues. Aggregations bring a power and flexibility to Elasticsearch that is hard to overstate. The ability to nest buckets and metrics, to quickly approximate cardinality and percentiles, to find statistical anomalies in your data, all while operating on near-real-time data and in parallel to full-text search—these are game-changers to many organizations.

이 장은 많은 분야와 깊은 기술적 이슈를 포함하고 있다. aggregation은 Elasticsearch에게 놀라운 능력과 유연성을 가져온다. bucket과 metric의 중첩 능력, 빠른 approximate cardinality와 percentiles, 데이터에서 통계적 이상을 찾는 능력, 거의 실시간에 가까운 데이터 연산과 full-text 검색의 병렬 연산 등등, 이런 것들이 많은 조직에게는 결정적이다.

It is a feature that, once you start using it, you’ll find dozens of other candidate uses. Real-time reporting and analytics is central to many organizations (be it over business intelligence or server logs).

그것을 사용하기 시작하면, 수십 개의 다른 용도를 찾을 수 있는 기능들이다. 실시간 보고 및 분석은 (기업의 정보 수집이나 서버 로그에 그것을 적용하면) 많은 조직에게 아주 중요하다.

Elasticsearch has made great strides in becoming more memory friendly by defaulting to doc values for most fields, but the necessity of fielddata for string fields means you must remain vigilant.

elasticsearch는 대부분의 field에 대하여 doc values를 기본으로 하여, 메모리에 더 친화적으로 되면서 큰 발전을 했다. 그러나, string field에 대한 fielddata의 필요성은 여러분들이 주의해야 할 점이 남아있다는 것을 의미한다.

The management of this memory can take several forms, depending on your particular use-case:

이 메모리 관리는 특정 사용 사례에 따라, 다양한 형태를 취할 수 있다.

• During the planning stage, attempt to organize your data so that aggregations are run on not_analyzed strings instead of analyzed so that doc values may be leveraged.

  설계하는 동안, doc values가 활용되록 하기 위해, aggregation이 analyzed 대신 not_analyzedstring에 대해 동작하도록 데이터를 구성하자.

• While testing, verify that analysis chains are not creating high cardinality fields which are later aggregated on

  테스트를 진행하는 동안, analysis chain이, 나중에 aggregation할 경우에, 높은 cardinality field를 생성하지 않는지 확인하자.

• At search time, by utilizing approximate aggregations and data filtering

  검색 시에는, approximate aggregation과 데이터 filtering을 사용한다.

• At a node level, by setting hard memory and dynamic circuit-breaker limits

  node 수준에서, 고정적인 메모리 제한과 동적인 circuit-breaker 제한을 설정한다.

• At an operations level, by monitoring memory usage and controlling slow garbage-collection cycles, potentially by adding more nodes to the cluster

  동작 단계에서는, 메모리 사용량을 모니터링하고, 느린 garbage collection 주기를 제어한다. 잠재적으로 cluster에 더 많은 node를 추가한다.

Most deployments will use one or more of the preceding methods. The exact combination is highly dependent on your particular environment.

대부분의 배포에서, 위의 방법 중 하나 이상을 사용할 것이다. 정확한 조합은 특정 환경에 따라 다르다. 어떤 조직은 매우 빠른 응답을 필요로 하여, 단순히 더 많은 node를 추가하는 것을 선택한다. 또 다른 조직은 예산 때문에, doc values와 approximate aggregation을 선택한다.

Whatever the path you take, it is important to assess the available options and create both a short- and long-term plan. Decide how your memory situation exists today and what (if anything) needs to be done. Then decide what will happen in six months or one year as your data grows. What methods will you use to continue scaling?

어떤 쪽을 선택하든, 사용할 수 있는 옵션을 평가하고, 단기 및 장기 계획 모두를 새우는 것이 중요하다. 현재의 메모리 환경이 어떤지를, 무엇이 필요한지를 파악하자. 그 다음에, 데이터가 증가함에 따라, 6개월, 1년 동안 무슨 일이 벌어질지를 예상해 보자. 확장을 계속하기 위해, 어떤 방법을 사용할 것인가?

It is better to plan out these life cycles of your cluster ahead of time, rather than panicking at 3 a.m. because your cluster is at 90% heap utilization.

cluster가 heap의 90%를 사용하는 것 때문에, 새벽 3시에 고생하는 것보다, 미리 cluster의 라이프 사이클을 계획하는 것이 더 낫다.