SQL 서버로 Lucene.Net 구성

Question

누가 SQL 서버와 함께 제공되는 전체 텍스트 검색을 사용하는 대신 Lucene.NET을 사용 했습니까?

그렇다면 어떻게 구현했는지 알고 싶습니다.

예를 들어 매시간 데이터베이스를 쿼리 한 결과를 lucene.net 인덱스에 저장 한 Windows 서비스를 작성 했습니까?

Answer 1

예, 설명하신 내용대로 사용했습니다. 우리에게는 두 가지 서비스가있었습니다. 하나는 읽기 용이고 다른 하나는 쓰기 용이었습니다. 나는 우리가 단지 하나의 서비스 (작가)로 그것을 할 수 있었고 웹 앱과 서비스에 독자를 포함 시켰을 것이라고 확신한다.

저는 일반적인 데이터베이스 인덱서로 lucene.net을 사용 했으므로 기본적으로 DB id (인덱싱 된 전자 메일 메시지)로 되돌아 왔고 검색 결과를 채우기에 충분한 정보를 얻거나 데이터베이스를 건드리지 않아도됩니다. 두 경우 모두 훌륭하게 작동합니다. SQL은 조금 느려질 수 있습니다. ID를 얻고 ID 등을 선택해야합니다. 임시 테이블 (ID 행이있는)을 만들어이 문제를 해결했습니다. 파일 (lucene의 출력)에서 대량 삽입 한 다음 메시지 테이블에 결합합니다. 훨씬 빨랐어 요.

Lucene은 완벽하지 않으며, 관계형 데이터베이스 상자 외부에서 생각하면됩니다. 왜냐하면 전체적으로 하나가 아니기 때문에 Lucene이하는 일은 매우 훌륭합니다. 가치가있어, 나는 "죄송합니다, MS SQL의 FTI가하는 인덱스를 다시 작성해야합니다."라는 메시지가 표시되지 않습니다.

BTW, 우리는 내가 생각하기에 약 20GB의 루씬 인덱스와 SQL 데이터베이스 + 첨부 파일 250GB를 합쳐 20 ~ 50 백만 건의 전자 메일 (약 1 백만 개의 고유 첨부 파일)을 처리했습니다.

성능은 환상적이었습니다. 최소로 말해서, 인덱스 세그먼트를 병합 할 때 병합 요소를 생각하고 조정해야합니다. 하나 이상의 세그먼트가있는 데는 문제가 없지만 각각에 1 백만 개의 항목이있는 두 세그먼트를 병합하려고하면 큰 문제가 발생할 수 있으며 너무 오래 걸리면 프로세스를 종료시키는 감시자 스레드가 있습니다. .. (그래, 우리 엉덩이를 잠시 걷어 찼다.) 그래서 물건 당 최대 문서 수를 낮게 유지하십시오 (즉, 우리가 한 것과 같이 maxint로 설정하지 마십시오!)

EDIT Corey Trager는 BugTracker.NET here에서 Lucene.NET 사용 방법을 문서화했습니다.

Answer 2

나는이 문서가 좋은 출발점이라고 생각 : 나는 아직 데이터베이스에 대해이를 수행하지 않은

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

Answer 3

, 귀하의 질문에 좀 열려 있습니다.

db를 검색하고 Lucene을 사용하도록 선택할 수 있다면 데이터가 데이터베이스에 삽입되는 시점을 제어 할 수 있다고 생각합니다. 그렇다면 db를 폴링하여 다시 색인해야하는지, 삽입 할 때 색인을 생성할지, 색인 생성 대상을 lucene에 알리는 데 사용할 수있는 대기열 테이블을 만들지는 거의 없습니다.

나는 우리가하고있는 일에 대해 무지하고 매번 인덱스를 다시 작성하거나 리소스를 낭비하는 인덱서가 필요 없다고 생각합니다.

Answer 4

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

• 스토어 기록 : 의사 코드에서는 같이 보입니다

  삽입 텍스트, 기타 데이터 테이블에
  최신 삽입 된 ID
  는 루씬 문서를 루씬에
  풋 (ID, 텍스트를) 만들 수 문서 업데이트 루씬 지수

• 이
  검색 루씬 색인
  쿼리

그냥 참고로 저장된 레코드의 ID로 DB에서 결과 세트 데이터를로드의 각 루씬의 문서에 대한 6,, 나는 그것으로 인해에 Sphinx에 루씬에서 뛰어난 성능

Answer 5

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

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

내 경험에 비추어 볼 때 SQL Server가 요구 사항을 충족한다면 가장 쉬운 방법이 될 것입니다. 복잡한 쿼리가 필요하거나 전체 텍스트 검색을 크게 제어해야하는 경우 lucene을 사용하는 것이 좋습니다. 확장은 쉽게 할 수 있기 때문에 시작하십시오.