Lucene.NET과 관계형 데이터베이스를 결합하는 모범 사례?

Question

저는 많은 데이터가있는 프로젝트에서 일하고 있습니다. SQL 쿼리로 매우 효율적으로 표현되는 여러 형식으로 검색 할 수 있지만 자연어 처리를 통해 검색해야합니다.

내 계획은 이러한 형태의 검색을 위해 Lucene을 사용하여 색인을 작성하는 것입니다.

내 질문에 내가이 일을 수행하고 검색을 수행하면, Lucene은 색인에서 일치하는 문서의 ID를 반환합니다, 그럼 나는 관계형 데이터베이스에서 이러한 엔티티를 조회해야합니다.

이

은 (내가 지금까지 생각할 수) 두 가지 방법으로 수행 할 수 있습니다 : 저장 프로 시저에 (끔찍한) 쿼리

패스의 모든 ID 년대의

• N 양을 한 번에 (아마도 같은 쉼표로 구분 된 매개 변수). 이것은 최대 매개 변수 크기로 제한되는 단점을 가지고 있으며 UDF가 문자열을 임시 테이블로 분리하는 속도가 느립니다.

필자는 모든 것을 lucenes 인덱스로 미러링하려는 유혹을 받고 있습니다. 따라서 백엔드 저장소에서 주기적으로 인덱스를 생성 할 수 있지만 프런트 엔드에만 액세스해야합니다.

조언?

Answer 1

이 문제가 발생했을 때 전체 텍스트 검색 기능이있는 관계형 데이터베이스 (필자는 PostgreSQL 8.3을 사용했으며, 형태소 분석 및 시소러스 지원이 포함 된 ft 지원이 내장되어 있음)와 함께갔습니다. 이렇게하면 데이터베이스는 SQL 및 ft 명령을 사용하여 쿼리 할 수 ​​있습니다. 단점은 전체 텍스트 검색 기능이있는 DB가 필요하며 이러한 기능은 lucene이 수행 할 수있는 것보다 열등 할 수 있습니다.

Answer 2

인덱스 자체에 데이터를 저장하여 DB 상호 작용을 피할 수 있습니다. db는 특정 레코드에 대한 추가 정보가 필요한 경우에만 쿼리됩니다.

Answer 3

결과가 그리드에 표시되고 사용자가 액세스하려고하는 정확한 문서를 선택하게하려는 경우 결과에 무엇을 할 것인지에 따라 결과가 달라질 수 있습니다. 사용자가 문서를 식별하는 데 도움이되는 충분한 색인, 예를 들어 200자를 말한 다음 회원이 문서를 선택하면 DB 전체를 검색합니다.

이것은 인덱스의 크기에 영향을 미칠 수 있으므로 유의해야 할 또 다른 고려 사항입니다. DB와 프론트 엔드간에 캐시를 두어 가장 많이 사용되는 항목이 매번 DB 액세스의 전체 비용을 초래하지 않도록합니다.

Answer 4

아마도 데이터베이스에 저장되는 항목에 따라 옵션이 달라질 수 있지만 내가 수행 한 작업은 인덱스 된 인덱스와 함께 검색 인덱스에 데이터베이스 ID를 저장하는 것입니다. 그런 다음 내 서비스 클래스에서 모든 개체 (예 : 이름, db id, 이미지 url, 설명 blurb, 소셜 미디어 정보)에 대한 검색 결과를 표시하는 데 필요한 모든 데이터를 캐시합니다. 서비스 클래스는 db id로 객체를 검색 할 수있는 Dictionary를 반환하며 Lucene.NET에서 반환 한 ID를 사용하여 메모리 내 캐시에서 데이터를 가져옵니다.

검색 색인에 검색 결과를 표시하는 데 필요한 모든 속성을 메모리에 저장하지 않고 저장할 수도 있습니다. 메모리 내 캐시가 검색 이외의 시나리오에서도 사용되기 때문에이 작업을 수행하지 않았습니다.

메모리 내 캐시는 항상 몇 시간 만에 처음이며, 데이터베이스에 도달해야하는 유일한 시간은 단일 개체에 대한 자세한 데이터를 가져와야하는 경우입니다 (사용자가 링크를 클릭하면 해당 개체에 대한 페이지로 이동하는 특정 개체).