Elastic Search 하드웨어에 대한 권장 사항 [닫기]


10

ElasticSearch를 지원하기위한 하드웨어 수준에 대한 유용한 안내서가 있습니까? Lucene 또는 Solr에 대한 권장 사항은 시작하기에 좋은 장소입니까? 우리는 다음으로 시작하여 배포를 시작하려고합니다.

  • 2,700 만 개의 문서, 8TB의 데이터
  • 하루에 300k 개의 문서를 추가하십시오

그런 다음 약 10 배로

  • 2 억 7 천만 개의 문서, 80TB의 데이터
  • 하루에 3 백만 건의 문서 추가

이것은 쿼리가 수천 / 일에있는 이상한 유스 케이스이지만 응답 시간은 Ajaxy webapp에 대한 좋은 경험을 위해 충분히 낮게 유지되어야합니다.


@ MarkHenderson : 이것은 실제 (장난감이 아닌) 재미있는 질문입니다. 나는 그것이 너무 현지화되었다는 당신의 평가가 목표를 벗어난 것이라고 생각합니다.
David J.

다윗은, 문제는 우리에 따라 폐쇄되었다 FAQ 우리가 질문을 쇼핑하지 않는다
마크 헨더슨

답변:


11

사용할 수있는 많은 요소가 있으므로 일반적인 지침이 많지 않다고 생각합니다.

설정에서 예상 인덱싱 및 검색로드를 던질 때 어떻게 작동하는지 확인하려면 초기 데이터 세트의 1/5로 소규모 평가를 수행해야합니다. 이를 통해 데이터가 실제로 검색 엔진에서 얼마나 많은 공간을 소비하는지 이해할 수 있습니다. elasticsearch의 경우 소스 json을 저장하는지 여부와 필드 분석 방법 및 저장 여부에 따라 다릅니다.

EC2는 큰 하드웨어 지출없이 탄력적 검색을 평가하는 합리적인 방법이 될 수 있습니다.

elasticsearch와 같은 클러스터 기반 소프트웨어의 경우 클러스터를 더 작게 유지하는 것 사이에 균형이 있습니다. 서버를 잃을 때 더 적은 데이터를 다시 할당해야하기 때문에 큰 클러스터는 좋습니다. 클러스터가 작을수록 에너지 소비가 적고 유지 관리가 더 쉽습니다.

모든 인덱스가 복제되므로 총 인덱스 크기가 약 300GB x 2 인 3,500 만 개의 문서로 클러스터를 실행합니다. 이 기능과 매우 많은 수의 검색을 지원하기 위해 raid10에는 각각 24 개의 코어, 48GB의 RAM 및 10TB의 디스크가있는 1TB의 스토리지를 갖춘 4 개의 노드가 있습니다. 최근 더 많은 헤드 룸을 확보하기 위해 디스크 크기를 늘 렸습니다.

귀하의 경우 더 많은 RAM과 더 많은 디스크를 권장합니다. 해당 검색 량으로 CPU를 절약 할 수 있습니다.

캐시 (사용 된 소프트웨어 및 OS 디스크의 내부)가 제대로 예열되지 않기 때문에 검색 량이 적 으면 실제로 성능이 저하됩니다.

이것이 도움이 되었기를 바랍니다. Paul


어떤 종류의 문서에 대해 이야기하고 있습니까? 로그? 실제 문서?
Manuel Rauber
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.