2011-01-19 4 views
3

텍스트의 각 숫자에 대한 용어를 만드는 것이 좋습니까? 예 텍스트 :Lucene에서 많은 수의 텍스트 색인 생성

I got 2295910 unique terms. 

숫자는 타임 스탬프, 포트 번호, 무엇이든 할 수있다. 고유 번호는 매우 많은 수의 고유 용어로 이어집니다. 문서와 동일한 수의 고유 용어를 사용하는 것이 옳다고 생각하지 않습니다. Lucene memory usage grows with the number of unique terms.

숫자가있는 텍스트의 경우 특수 분석기 또는 트릭이 있습니까? StandardAnalyzer는 각 고유 번호에 대한 용어를 만듭니다.

필요 사항은 :

번호는 검색이 남아 있어야한다. 문서에 여러 개의 숫자가있을 수 있습니다. 메모리 사용이 문제입니다. 나는 다수 색인 전화 번호부에있는 800M 문서가있다. 메모리 사용량에 따라 가장 최근에 사용하지 않은 IndexSearchers가 닫힙니다.

테스트되지 않은 아이디어 :

  • 특별한 분석기를 사용합니다. 숫자를 덩어리로 나눕니다. 123456은 "123 456"이됩니다. 쿼리 구문 분석기는 구 검색을 사용하여 숫자를 찾습니다.
  • 숫자 용어를 볼 때 더 큰 termInfosIndexDivisor를 사용하도록 Lucene 코드를 변경하십시오.

어쩌면 나는 바퀴를 재발 명하고있다. 이미 누군가에 의해 해결 되었습니까?

답변

3

현재 메모리에 문제가 있습니까? Lucene의 메모리 사용량은 고유 한 용어의 수가 늘어남에 따라 커지지 만 용어가 많은 인덱스의 경우에도 여전히 비교적 적은 양의 메모리입니다.

메모리가 문제이고 실제로 문제가되는 Lucene인지 확인하기 위해 코드를 프로파일 한 경우 숫자 용어를 버리는 다른 분석기를 만들 수 있습니다. 그렇게하면 분명히 숫자를 사용하여 문서를 검색 할 수 없습니다.

+0

확인. 색인에 많은 고유 용어가있는 것이 좋다고 생각합니다. 더 큰 termInfosIndexDivisor는 메모리 사용을 줄이는 데 도움이됩니다. –

1

Bajafresh는 다음과 같이 말합니다. 조숙 한 최적화는 모든 악의 근원입니다. 그러나 이것이 실제로 문제라고 가정하면 :

하나의 옵션은 필드를 복제하고 숫자를 던지면서 분석하고, 다른 하나는 숫자 이외의 모든 것을 버리고 숫자 필드로 인덱싱하는 것입니다. 숫자 필드에는 special storage 메커니즘이 있습니다. 즉, 매우 적은 수의 고유 용어 만 저장됩니다 (일반적으로 256 미만, 일부 정밀도의 비용으로).

물론 이것은 문구 쿼리가 작동하지 않지만 다른 종류는 여전히 괜찮을 것입니다 (이 작업을 수행하기에 충분할 정도로 쿼리 파서가 있다고 가정).

1

답변은 필요에 따라 다릅니다.

이 용어를 검색해야합니까? 이 조건에 따라 검색해야하는 경우 검색 색인의 성격 일뿐입니다. 정확한 값 (예 : 범위 검색)을 검색 할 필요가 없다면 할 수있는 몇 가지 트릭이 있습니다.하지만 정확히 일치하는 것이 필요한 경우이 문제가 있습니다.

이러한 용어를 검색 할 필요가없는 경우 왜 색인을 생성합니까?