[es] elasticsearch 성능개선 (elasticsearch cache)

검색 속도 조정  

• 파일 시스템 캐시에 메모리 제공
• 더 빠른 하드웨어 사용
• 문서 모델링
• 가능한 한 적은 수의 필드를 검색
• 사전 색인 데이터
• 매핑 식별자를 키워드로 고려
• 스크립트 피하기
• 반올림된 날짜 검색
• 읽기 전용 인덱스 강제 병합
• 글로벌 서수 워밍업
• 색인 정렬을 사용하여 접속사 속도를 높임
• 기본 설정을 사용하여 캐시 활용도 최적화
• 복제본은 처리량에 도움이 될 수 있지만 항상 그런 것은 아님

 

회사에서 성능 이슈를 제기했다.  elasticsearch 의 캐싱을 정리하려고 하는데 쿼리속도가 문제가 아닌걸 알지만 

우선 es 레벨에서 캐싱으로 처리할 수 있는 부분을 정리

 

우선 속도에 영향을 미치는 부분은

The more fields a query_string or multi_match query targets, the slower it is.  

1. 당연한 소리겠지만 쿼리스트링이나 멀티매치쿼리는 타겟필드가 많을 수록 쿼리가 느려진다. 

 

In particular SSD drives are known to perform better than spinning disks.

2. 회전식 디스크보다 SSD 가 성능이 좋다. (이것도 당연한 소리고)

 

Always use local storage, remote filesystems such as NFS or SMB should be avoided.

3. 항상 로컬 스토리지를 사용하고 원격파일시스템은 피해야 한다.

 

Also beware of virtualized storage such as Amazon’s Elastic Block Storage. Virtualized storage works very well with Elasticsearch, and it is appealing since it is so fast and simple to set up, but it is also unfortunately inherently slower on an ongoing basis when compared to dedicated local storage.

4. AWS EBS 가상스토리지는 Elasticsearch 와 잘맞지만 로컬스토리지 보다는 느리다. 

 

If you put an index on EBS, be sure to use provisioned IOPS otherwise operations could be quickly throttled.

5. EBS에 인덱스를 배치하는 경우 프로비저닝된 IOPS를 사용해야 합니다. 그렇지 않으면 작업이 빠르게 제한될 수 있습니다.

 

Document 모델링

In particular, joins should be avoided. nested can make queries several times slower and parent-child relations can make queries hundreds of times slower. 

6. 조인쿼리를 피하라 nasted 쿼리는 쿼리를 몇 배 느리게 하고 부모-자식 관계의 쿼리는 수백배 느리게 한다.  

 

 

 

파일 시스템 캐시에 메모리 제공

Elasticsearch는 검색 속도를 높이기 위해 파일 시스템 캐시에 크게 의존합니다. 일반적으로 Elasticsearch가 실제 메모리에서 인덱스의 핫 영역을 유지할 수 있도록 사용 가능한 메모리의 절반 이상이 파일 시스템 캐시로 이동하는지 확인해야 합니다.