3
매우 복잡한 쿼리가있는 인덱스가 있습니다. 주요 둔화는 각 레코드에 대해 2-5 단어를 포함하는 필드에 대해 실행되는 퍼지 쿼리입니다. 나는 주로 1-3 개의 다른 문자로 행을 찾아야합니다.거대한 서버/서버 클러스터에 대한 탄성 검색 퍼지 매칭 최적화
내 4 코어 (HT 포함) 및 8GB 램 시스템에서 내 쿼리는 약 1-2 초마다 실행됩니다. 12 코어 (HT 포함) 및 72Gb RAM이있는 서버에서 쿼리는 0.3-0.5 초 내에 실행됩니다. 이것은 제공된 하드웨어에 대한 합리적인 확장 성으로 보지 않습니다. 쿼리 성능을 조정하기 위해 조정할 수있는 숨겨진 옵션이 있어야합니다.
탄성 검색 가이드를 살펴 보았지만 CPU 또는 RAM의 수를 기반으로 성능을 튜닝하거나 퍼지 쿼리 전용으로 탄성을 조정하는 데 도움이되는 것을 찾을 수 없습니다.
다른 질문은 내가 이와 같은 다른 서버를 추가하면 어떻게 확장됩니까? 쿼리 시간은 대략 두 배 더 작을 것입니까?
이렇게하면 12 코어 (24 가상)를 가진 서버가 3 대있는 경우 나를위한 최적의 샤드 개수는 (3 * 12) * 1.5 = 54와 비슷합니다. 복제본을 사용하여 동일한 성능 향상을 달성 할 수 있습니까? btw 중복성을 위해 적어도 replica 값 1을 사용하려고합니다. –
시스템에서 단일 쿼리를 실행하면 대부분의 작업이 5 개의 스레드 (각 조각마다 하나의 스레드)로 분할됩니다. 두 번째 쿼리를 시작하면 다른 5 개의 스레드가 사용됩니다. 즉, 한 번에 하나의 쿼리를 실행하면 복제본이 도움이되지 않지만 많은 동시 쿼리를 실행하면 도움이됩니다. 그러나 병목 현상은 데이터 및 트래픽 패턴에 따라 시스템의 한 부분에서 다른 부분으로 쉽게 이동할 수 있기 때문에 이론적 인 방법으로이를 접근하는 것에 대해 경고합니다. 실제 데이터에서 실제 트래픽을 시뮬레이션하고 시스템 성능을 측정하여 병목 현상을 식별해야합니다. – imotov
ok, 많이 감사합니다) –