2012-02-17 2 views
3

각기 다른 언어로 여러 이름을 가질 수있는 데이터베이스가 있습니다. 이것은 현재 일에 표준화되어있다-많은 이름을 스키마 :이 사용 SOLR를 인덱싱하고 있어요Solr 언어 감지 업데이트 프로세서 (비정규 화 된 혼합 언어 문서 용)

things 
------ 
id 
... 

names 
----- 
id 
thing_id 
language 
name 

루씬 스키마에이를 비정규 화하는 가장 좋은 방법을 알아 내려고 노력하고 있습니다.

<fields> 
    <field name="id" type="uuid" indexed="true" stored="true" required="true" /> 
    ... 
    <field name="name_eng" type="text_eng" indexed="true" stored="true" /> 
    <field name="name_jpn" type="text_cjk" indexed="true" stored="true" /> 
    <field name="name_kor" type="text_cjk" indexed="true" stored="true" /> 
</fields> 

문제는 내가 개별적으로 지원되는 각 언어에 대한 필드와 필드 유형을 지정해야한다는 것입니다, 그리고 많이있을 수 있습니다 :이 하나는 괜찮 작동합니다. 또한 SQL DataImportHandler를 사용하기 때문에 데이터베이스에서이 스키마로 가져올 SQL 쿼리를 지정하기 위해 많은 코드를 복제해야한다는 것을 의미합니다. 또한 이름의 language 필드는 사용자 입력을 기반으로하기 때문에 항상 올바르지 않습니다.

나는 매우 좋은 표정 인 language detection capabilities Solr 제안을 보았습니다. 하지만 그들은 문서 전체에서 작동하는 것 같아요.이 경우에는 많이 추측 할 수 없습니다. 이름을 저장할 수있는 스키마에 하나의 multiValued 필드를 지정하는 방법이 있습니까? 그 언어는 자동으로 검색되고 그에 따라 색인이 생성됩니까? 또는 언어 탐지 설비가 내 인생을 더 쉽게 만들 수있는 다른 방법?

답변

0

아마도 인덱스 측에서이를 수행 할 수있는 변환기를 작성할 수는 있지만 쿼리 측에서는 동일한 분석 체인을 사용하지 않으므로 작동하지 않습니다.

"물건"의 텍스트는 어떻게 생겼습니까?

약 200 자 미만이면 언어 ID가 제대로 작동하지 않습니다. 그것을 통계적 접근 방식으로 "언어 추측"이라고 생각하십시오. 소량의 데이터로 인해 추측은 좋지 않습니다. "모바일"영어 또는 덴마크어입니까? 둘 다. "죽어라"는 영어와 독일어 등입니다. 좋은 추측을 위해, 천자가 도움이 될 것입니다.

텍스트의 상표 등록 된 이름이 있습니까? "LaserJet"과 "Linux"는 모든 언어에서 동일하며 거의 사용되지 않으므로 언어 ​​처리는 아무 것도하지 않습니다. 어쩌면 언어 별 형태소 분석없이 얻을 수 있습니다.

마지막으로 언어 처리 대신 n-gram을 고려할 수 있습니다. 언어에 민감한 검색과 완전히 다른 모델이지만이 경우 더 효과적 일 수 있습니다. 어떤면에서는 언어 ID와 동일한 종류의 통계 패턴 일치를 수행하지만 인덱스 시간 대신 쿼리 시간에 수행합니다. 쿼리에서 짧은 패턴의 시퀀스를 취하여 텍스트의 패턴을 찾습니다. 더 많은 시간과 공간이 필요하지만 시도해 볼 가치가 있습니다.