ElasticSearch가 인덱스의 데이터 양에 비례하여 어떻게 확장되는지에 대한 정보를 찾고 있으며, 해당 항목에서 찾을 수있는 방법이 거의 없다는 사실에 놀랐습니다. 어쩌면 여기서 군중의 경험이 도움이 될 것입니다.ElasticSearch의 배율
현재 CloudSearch를 사용하여 약 700 만 문서의 색인을 생성합니다. CloudSearch에서이 결과는 유형이 m2.xlarge 인 2 개의 인스턴스가됩니다. 대신 ElasticSearch로 전환하여 비용을 줄이는 방안을 고려 중입니다. 하지만 ElasticSearch의 스케일링에서 발견 한 것은 확장 성이 뛰어나고 여러 인스턴스에 분산 될 수 있다는 것입니다.
그러나 이러한 종류의 데이터에는 어떤 종류의 기계 (메모리, 디스크)가 필요합니까?
데이터 양을 12 개 (약 8 천만 문서) 증가 시키면 어떻게 바뀌겠습니까?
저는 실제로 최근에 CloudSearch를 사용하여 회사에서 ElasticSearch 호스팅 서비스로 전환했습니다. 우리의 특정 응용 프로그램에는 1 억 개가 넘는 문서가 있으며 매일 증가하고 있습니다. 지금까지 ElasticSearch에 대한 우리의 경험은 절대적으로 훌륭했습니다. 모든 정렬, 필터링 및 패싯을 사용하여 ~ 250ms의 검색 성능 평균을 제공합니다. 문서를 인덱싱하는 것은 상대적으로 빠릅니다. 몇 시간마다 대량 API를 사용하여 HTTP를 통과 시키지만 몇 시간이 걸립니다. 새로 고침 속도는 거의 즉각적으로 보입니다.
우리의 ~ 100M doc/12GB 인덱스의 경우 4 개의 노드에 걸쳐 4 개의 샤드/2 개의 복제본 (성능이 저하 될 경우 3 개의 복제본에 충돌)이 사용되었습니다. 색인을 설정하기 전에 우리 팀은 ElasticSearch 클러스터 배치/유지 보수를 연구하는 데 며칠을 보냈고 http://qbox.io을 사용하여 비용과 시간을 절약했습니다. 우리는 성능이 저하되고 Qbox와 같은 전용 클러스터에서 색인을 호스팅하도록 선택하는 문제를 마비 시켰지만 지금까지 경험은 심각하게 환상적이었습니다.
인덱스가 전용 클러스터에 있으므로 노드 레벨 구성 설정에 액세스 할 수 없기 때문에 ES 배포에 대한 기술적 전문성은 여전히 제한적입니다. 즉, 색인에서 경험 한 성능에 대해 어떤 tweeks가 필요한지 확신 할 수 없습니다. 그러나, 나는 Qbox의 클러스터가 SSD를 사용한다는 것을 알고 있습니다 ... 그래서 그것은 분명히 중대한 영향을 미칠 수 있습니다.
포인트를 입력하면 ElasticSearch가 자연스럽게 조정됩니다. 나는 고도로, 스위치를 추천한다. (단지 $$를 절약한다고하더라도, CloudSearch는 비싸다). 희망이 정보는 도움이!
잠시만 기다리십시오. qbox.io를 사용하도록 "선택"하셨습니까? 프로필 이름이 qbox.io의 수석 아키텍트라고합니다. COI 면책 조항은이 답변에 도움이 될 것입니다. – NathanAldenSr
네이선, 좋은 지적입니다. 나는 작년 초 Qbox를 통해 Elasticsearch를 사용하기 시작했을 때이를 게시했습니다. 나는 밖으로 휘젓 았던 다른 지방의 회사와 일하고 있었다. 그래서 나는 거기에서 일했던 가까운 친한 친구를 가지고 있기 때문에 Qbox에서 선상에 뛰어 다녔다. 가입 이후, 우리는 여러 명의 엔지니어를 추가하고 추가했습니다. 그리고 저는 리드 개발자로 감았습니다. 결과적으로, 위의 의견은 단단하게되었습니다 (나는 부끄럽지 않습니다 :)). –
Javanna said에 따라 다릅니다. 주로 : (1) 인덱싱 속도; (2) 서류의 크기; (3) 검색을위한 속도 및 대기 시간 요구 사항; (4) 검색 유형.
이 점을 고려하면 가장 좋은 방법은 예제를 제공하는 것입니다. our site (뉴스 모니터링)에 우리 : 분당 100 워드 프로세서보다 더
OR 개의 검색어를 사용합니다. 또한 우리는 두 개의 단일 값 필드를 패 시팅합니다. 그리고 날짜 패싯 (시간을 통한 게시 속도 표시)을 사용하여 몇 가지 실험을하십시오.우리는 4 EC2의 m1.large 인스턴스로이 모든 작업을 수행합니다. 이제 Lucene 4.0의 모든 개선점과 성능 향상을 위해 ES, just released, 0.9 version으로 이동할 계획입니다.
이제 예제를 제쳐두고 떠날 것입니다. ElasticSearch는 꽤 확장 가능합니다. N 개의 샤드와 M 개의 복제본으로 인덱스를 생성 한 다음 ES로 X 머신을 생성하는 것은 매우 간단합니다. 그에 따라 모든 샤드 및 복제본이 배포됩니다. 언제든지 (각 색인에 대해) 복제본 수를 변경할 수 있습니다.
하나의 단점은 인덱스 생성 후 샤드의 수를 변경할 수 없다는 것입니다. 그러나 필요한 경우 크기 조정을위한 공간을 미리 남겨두기 위해 미리 "과도한 관리"를 할 수 있습니다. 또는 적당한 수의 샤드로 새로운 인덱스를 만들고 모든 것을 다시 색인하십시오 (우리는 이것을합니다).
마지막으로, ElasticSearch (및 또한 Solr)은 매우 성숙하고 잘 알려진 라이브러리 인 Lucene 검색 라이브러리를 사용합니다.
몇 개의 조각을 사용하고 있습니까? 너는 10, 100, 1000을 의미합니까? – gondo
@gondo 이제 8 개의 인스턴스가 있습니다. 한 달에 한두 개의 조각이있는 날짜 분할 방식으로 이동했습니다. 이 전에 우리는 인덱스 당 16 개의 조각 (~ 60M 문서 포함)을 가지고있었습니다. oversharding에 의해 나는 doubling하고있는 무엇인가 의미한다. 그러나 설정에 따라 너무 조심해야합니다. 너무 많은 파편은 좋지 않습니다. 예를 들어, 각 쿼리가 200 개의 모든 샤드로 이동해야한다면 8 m1.large 인스턴스로 오버 헤드가 발생하지 않을 것입니다. –
CloudSearch는 최근 가격을 떨어 이제 EC2에 자신의 검색 infrastrcuture을 유지하는 것보다 싼 대안이 될 수 있습니다 - 당신은 당신은 단지 전형적인를 얻을 수 있습니다 제공하는 정보와 추측 http://aws.amazon.com/blogs/aws/cloudsearch-price-reduction-plus-features/
대답 "이 달려있다":)하지만, 여전히 ... 그것은 귀하의 문서가 어떻게 생겼는지, 그리고 그들이 무엇을하고 싶은지에 달려 있습니다. – javanna