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.