때때로 전체 데이터베이스를 다시 색인합니다. 대개 몇 시간이 걸립니다. 그러나 최신 페이지 만 첫 페이지에 표시됩니다. 그래서 나는 데이터베이스를 거꾸로 다시 색인하면 'id desc'순서로 레코드를 다시 색인하면 서버 다운 시간을 많이 줄일 수 있다고 생각합니다.가장 최근의 레코드를 다시 색인 할 수 있습니까?
그러나 성능 측면에서 보면 괜찮습니까? 검색 시간에 부정적인 영향을 미칠 수 있습니까?
왜 가동 중단 시간이 있습니까?
마지막 커밋 만하면 커밋을 할 때 끝 부분에만 레코드가 표시되며 순서는 중요하지 않습니다.
maxDocs/maxTime (Solr 4+) 세트를 사용하여 소프트 커밋을하고 최신 레코드에서 다시 색인하면 즉시 해당 레코드가 표시되고 다른 레코드는 결국 표시됩니다.
커밋 의미에 대해 조금 읽는 것이 좋을지를 확인하는 것이 좋습니다.
다운 타임으로 나는 아무것도 표시 할 수 없을 때를 의미했습니다. 따라서 다시 색인을 생성 할 때 성능 문제가 발생하지 않는다고 말하는 것입니까? – lulalala
언제 '아무것도'표시 되나요? 내가 당신의 시나리오를 이해한다면, 커밋 될 때까지 * 오래된 레코드를 표시하게 될 것입니다. '아무것도'아닙니다. 어쨌든 소프트 커밋을 철저히 검토하십시오. 그것은 당신의 필요에 매우 근접해야합니다. –
만료 된 오래된 항목이 내 웹 사이트 논리의 색인 페이지에 숨겨져 있기 때문에 아무 것도 표시되지 않습니다. solf-commit은 중요하지 않으므로 주요 업데이트 중에 전체 색인 다시 생성이 수행됩니다. 나중에 쿼리에 성능상의 영향이 없을 것이라고 말하기 때문에 이것을 답으로 표시 할 것입니다. – lulalala
전체 색인을 다시 작성한다고 말하면서 다른 핵심 색인을 작성하고 교환하는 것이 좋습니다. This answer은 이러한 문제를 해결하는 방법에 대한 참고 자료를 제공합니다.
우리는 마스터/슬레이브 설정을 사용합니다. 여기서 인덱스는 마스터에서 발생하고 인덱스는 슬레이브로 복제됩니다. 슬레이브가 검색 요청을 처리합니다. 이것은 성능 관점에서 잘 작동합니다.
고려해야 할 또 다른 사항은 인덱싱 시간이 몇 시간으로 실행되는지 확인해보십시오. 이 경우 DataImportHandler의 중첩 된 쿼리가 n + 1 jdbc 연결을 시작하는 범인이라는 것을 깨달았습니다. 조회수를 최적화하여 색인 생성 시간을 3 시간에서 2 분 미만으로 단축했습니다.
마스터/슬레이브가 실제로이를 처리하는 올바른 방법이지만, 현재 우리에게는 불가능합니다. – lulalala
엄격하게 마스터/슬레이브가 필요하지 않습니다. 코어 스왑은 단일 인스턴스에서도 수행 될 수 있습니다. [문서] (http://wiki.apache.org/solr/CoreAdmin#SWAP)에서이 작업을 수행 할 수있는 명령을 제공합니다. –
전체 색인 생성 또는 델타 색인 생성을 수행하고 있습니까? –
우리는 전체 다시 색인을 수행합니다 – lulalala