Lucene 인덱싱 성능

Question

데이터베이스 데이터를 디스크에 인덱싱하는 프로그램을 작성했는데 인덱스 속도가 적절한 지 확신 할 수 없습니다. 예를 들어 속도가 느리고 속도가 더 빠르거나 속도를 더 향상시킬 수 있는지 확실하지 않습니다.

속도는 새 인덱스를 만들 때 약 2600KB의 인덱스 디렉토리 크기 인 시간당 약 15000 개의 문서입니다.

Lucene 6.0.0 및 Windows 8.1 64 비트 OS, 16GB RAM 및 Intel Core i7 8 코어 시스템을 사용하고 있습니다. 로컬 컴퓨터에서 인덱싱을하고 있는데 어떤 종류의 디스크가 있는지, Windows PC와 함께 제공되는 디스크인지는 확실하지 않습니다.

스프링 배치를 사용하여 INNER JOIN 데이터베이스 테이블 두 개를 가져오고 ItemReader에서 행 매핑 된 객체를 가져오고이 객체에서 Document을 준비합니다.

Lucene 6.0.0 updateDocument은 기존 문서를 업데이트하는 것 외에도 문서가 존재하지 않는 경우 색인을 생성 할 문서를 추가하기 때문에 항상 방법 writer.updateDocument(contentDuplicateKeyTerm, doc);이 아니라 addDocument(doc)을 사용합니다.

내 프로그램을 비교할 벤치 마크를 모르겠다.

좋습니다.

편집 : 이제 시간당 약 1,800,000 문서의 성능을 얻을 수 있습니다. 각 Document을 업데이트 한 후 문제가 IndexWriter.commit()이었습니다. 이제는 일정한 간격으로 커밋하고 성능이 크게 향상되었습니다.

Answer 1

필자는 여러 번의 실수를 저지르고 있었기 때문에 쓰기 성능이 느린 이유입니다. 아래에 나열된 실수 중 일부.

1. 각 문서가 끝나면 커밋을하기 위해 Spring Batch를 사용할 때 각 청크 다음에 커밋하도록 프로그램을 변경했습니다. 커밋 간격을 늘리면 성능이 크게 향상되었습니다.

2. 작가 인스턴스를 불필요하게 닫고 다시 여는 중이었습니다 (초기 논리는 그렇게 설계되었습니다). 필자는 응용 프로그램 범위에서 단일 작성자 인스턴스를 유지하고 필요할 때마다 재사용을 유지하기 위해 프로그램 논리를 변경했습니다.

3. 원본 데이터가 DB2 데이터베이스이고 읽기가 테이블에서 느립니다. 읽기 성능을 높이기 위해 색인을 추가했습니다.

4. 루씬 작성자는 스레드로부터 안전하므로 단일 스레드 대신 멀티 스레드 방식으로 작성하기 시작했습니다.

그래서 lucene writer 커밋 간격을 늘린 후에 많은 수의 문서를 보관할 충분한 메모리가 있으면 색인 작성 자체에 시간이 많이 걸리지 않으며 읽기 및 준비에는 많은 시간이 걸리지 않습니다. Lucene은 처리의 나머지 부분이 빠르면 몇 분 안에 몇 백만 건의 문서를 색인 할 수 있습니다.