Lucene에서의 페이로드 성능

Question

Lucene의 색인 생성 및 쿼리 성능과 관련하여 웹뿐만 아니라 SO에서 여러 주제가 있음을 알고 있습니다. 그러나 아직 논란의 여지가 있는지 찾아 봅니다. ?)을 생성 페이로드

의 내가 색인 어디 100K에서 문서 (모음 싶은 말은하자 ... 여기

이 시나리오의 ... 쿼리 성능에 영향을 미칠 것입니다 -) 10M를, 각 문서는 하위 섹션을 가지고 그 별도로 검색 할 수 있기를 원합니다 (또는 해당 섹션에서 일치하는 항목이 있는지 여부에 따라 더 높은 순위를 매길 수 있기를 바랍니다).

해당 하위 섹션에 나타나는 용어에 페이로드 (색인 생성 중)를 추가하는 것이 고려되므로 쿼리 시간에 효과적으로 결정할 수 있습니다.

페이로드 사용과 관련된 성능 문제를 아는 사람이 있습니까? 또는이 항목에 대한 온라인 설명서를 알려줄 수 있습니까?

감사합니다.

편집 : 내 시나리오에 대한 대안 솔루션을 고맙게 생각하지만 향후 페이로드를 사용해야하는 경우 누구나 쿼리 성능에 대한 원래 질문에 대한 의견이 있습니까?

Answer 1

당신이 원하는 교과서 솔루션은 각 원본 문서를 두 개의 필드로 색인화합니다. 하나는 전체 문서 용이고 다른 하나는 하위 섹션 용입니다. 인덱싱 중 또는 검색 중에 하위 섹션 필드를 별도로 늘릴 수 있습니다. 그런데 Lucene 페이로드에 대한 내용은 Getting Started with Payloads입니다.

Answer 2

유스 케이스가 페이로드의 목적에 잘 맞지 않습니다. 페이로드 정보가 중복되는 것으로 보입니다.

페이로드는 문서/용어 쌍이 아닌 문서의 개별 항목에 첨부됩니다. 페이로드를 저장하고 액세스하려면 문서 내에서 용어 어커런스의 오프셋을 사용해야합니다. 귀하의 경우, 오프셋을 알고 있다면 페이로드 데이터를 사용하지 않고 용어 어휘가 어느 섹션에 있는지 계산할 수 있어야합니다.

더 중요한 질문은 성능에 페이로드가 미치는 영향입니다. 필자의 경험에 따르면 페이로드 구현을 제대로 사용하면 공간을 덜 차지하고 이전에 사용했던 모든 해결 방법보다 빠릅니다. 디스크 공간에 대한 가장 큰 영향은 현재 Field.setOmitTermFreqAndPositions (true)를 사용하여 인덱스 크기를 줄이는 것입니다. 페이로드를 사용하기위한 위치를 포함시켜야하므로 잠재적으로 색인이 훨씬 커집니다.