문제

SQL Server와 함께 제공되는 전체 텍스트 검색을 사용하는 대신 Lucene.NET을 사용한 사람이 있습니까?

그렇다면 어떻게 구현했는지 궁금합니다.

예를 들어, 매시간 데이터베이스를 쿼리한 후 결과를 lucene.net 인덱스에 저장하는 Windows 서비스를 작성하셨나요?

도움이 되었습니까?

해결책

예, 정확히 귀하가 설명하는 용도로 사용했습니다.우리는 두 가지 서비스를 가지고 있었습니다. 하나는 읽기용이고 다른 하나는 쓰기용이었습니다. 하지만 이는 독자가 여러 명 있었기 때문이었습니다.단 하나의 서비스(작성기)만으로 이를 수행하고 웹 앱과 서비스에 리더를 내장할 수 있었을 것이라고 확신합니다.

저는 lucene.net을 일반 데이터베이스 인덱서로 사용했기 때문에 제가 돌려받은 것은 기본적으로 (인덱싱된 이메일 메시지에 대한) DB ID였으며, 또한 이를 사용하여 검색 결과를 입력하지 않고도 충분한 정보를 얻을 수 있었습니다. 데이터 베이스.두 경우 모두 훌륭하게 작동했지만 ID를 얻고 ID를 선택해야 하기 때문에 SQL이 약간 느려질 수 있습니다.임시 테이블(ID 행만 포함)을 만들고 파일(lucene의 출력)에서 대량 삽입한 다음 메시지 테이블에 조인하여 이 문제를 해결했습니다.훨씬 빨랐습니다.

Lucene은 완벽하지 않으며 관계형 데이터베이스 상자 밖에서 조금 생각해야 합니다. 완전히 하나는 아니지만 기능을 매우 훌륭하게 수행하기 때문입니다.살펴볼 가치가 있으며 MS SQL의 FTI에서 발생하는 "죄송합니다. 인덱스를 다시 다시 작성해야 합니다"라는 문제가 없다고 들었습니다.

그런데, 우리는 2천만~5천만 개의 이메일(및 약 100만 개의 고유 첨부 파일)을 처리하고 있었는데, 총 20GB의 루씬 인덱스와 250GB 이상의 SQL 데이터베이스 + 첨부 파일을 처리하고 있었습니다.

성능은 환상적이었습니다. 병합 요소(인덱스 세그먼트를 병합할 때)에 대해 생각하고 조정하십시오.두 개 이상의 세그먼트를 갖는 데는 문제가 없지만 각각 100만 개의 항목이 있는 두 개의 세그먼트를 병합하려고 시도하고 너무 오래 걸리면 프로세스를 종료하는 감시자 스레드가 있는 경우 큰 문제가 발생할 수 있습니다. ..(예, 한동안 우리를 당황하게 만들었습니다).따라서 항목당 최대 문서 수를 낮게 유지하십시오(즉, 우리가 했던 것처럼 maxint로 설정하지 마십시오!).

편집 Corey Trager는 BugTracker.NET에서 Lucene.NET을 사용하는 방법을 문서화했습니다. 여기.

다른 팁

나는 아직 데이터베이스에 대해 해본 적이 없습니다. 귀하의 질문은 다소 열려 있습니다.

DB를 검색하고 Lucene을 사용하도록 선택할 수 있다면 데이터베이스에 데이터가 삽입되는 시점을 제어할 수도 있을 것 같습니다.그렇다면 재인덱싱이 필요한지 알아보기 위해 DB를 폴링할 이유가 거의 없습니다. 삽입할 때 인덱싱하거나 lucene에 인덱싱할 항목을 알려주는 데 사용할 수 있는 대기열 테이블을 생성하면 됩니다.

무슨 일을 하는지 모르고, 매번 재색인을 하거나, 자원을 낭비하는 인덱서는 또 필요하지 않다고 생각합니다.

저는 lucene.net을 스토리지 엔진으로도 사용했습니다. 데이터베이스보다 인덱스가 있는 대체 시스템을 배포하고 설정하는 것이 더 쉽기 때문입니다. 이것은 단지 파일 시스템 복사본일 뿐이며 한 시스템에서 인덱싱을 수행하고 새 파일을 다른 시스템에 복사할 수 있습니다. 인덱스를 배포합니다.모든 검색 및 세부 정보는 lucene 색인에서 표시되며 데이터베이스는 편집에만 사용됩니다.이 설정은 우리의 요구에 맞는 매우 확장 가능한 솔루션으로 입증되었습니다.

SQL Server와 Lucene의 차이점과 관련하여 SQL Server 2005 전체 텍스트 검색의 주요 문제점은 서비스가 관계형 엔진에서 분리되어 전체 텍스트 결과와 관계형 열 간의 조인, 순서, 집계 및 필터가 매우 비싸다는 것입니다. 성능 측면에서 Microsoft는 관계형 엔진 내부에 전체 텍스트 검색을 통합하여 이 문제가 SQL Server 2008에서 해결되었다고 주장하지만 테스트하지는 않았습니다.또한 전체 텍스트 검색을 훨씬 더 투명하게 만들었습니다. 이전 버전에서는 형태소 분석기, 불용어 및 블랙박스처럼 이해하기 어려운 색인의 여러 부분이 새 버전에서는 작동 방식을 더 쉽게 확인할 수 있게 되었습니다.

내 경험에 따르면 SQL Server가 귀하의 요구 사항을 충족한다면 이것이 가장 쉬운 방법이 될 것입니다. 많은 성장, 복잡한 쿼리가 예상되거나 전체 텍스트 검색에 대한 큰 제어가 필요한 경우 처음부터 lucene을 사용하여 작업하는 것을 고려할 수 있습니다. 확장하고 개인화하는 것이 더 쉬울 것입니다.

저는 MySQL과 함께 Lucene.NET을 사용했습니다.내 접근 방식은 색인된 텍스트와 함께 Lucene 문서에 db 레코드의 기본 키를 저장하는 것이었습니다.의사 코드에서는 다음과 같습니다.

  • 매장 기록:

    테이블에 텍스트, 기타 데이터 삽입
    최근 삽입된 ID 가져오기
    루씬 문서 생성
    루센 문서에 (ID, 텍스트)를 넣어 루센 인덱스 업데이트

  • 쿼리 중
    루씬 인덱스 검색
    결과 세트의 각 lucene 문서에 대해 저장된 레코드의 ID로 DB에서 데이터를 로드합니다.

참고로 저는 Lucene에서 스핑크스 뛰어난 성능으로 인해

나는 이 기사가 좋은 출발점이라고 생각합니다.

http://www.aspfree.com/c/a/braindump/working-with-lucene-net/

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top