검색엔진 루씬 lucene & hadoop

루씬의 주요한 함수를 꼽으라면

데이터를 인덱싱하는 IndexWriter
데이타를 검색하는 IndexSearcher
데이타를 읽는 IndexReader

이 세개를 말할수 있습니다.

단순한 검색서비스를 제공하고자 한다면 IndexWriter와 IndexSearcher 이 두개만 있으면 됩니다.

이 세가지의 공통점을 꼽는다면
모두가 동일한 Directory를 바라보고 있다는 겁니다.

개별로 움직이는 것들이 하나의 Directory를 가지고 지지고 볶고 합니다.

그렇지만 이 세개는 아쉽게도 서로 사용시 Sync를 맞추지 못합니다.

동상이몽하는 셈이죠.
하나의 변경이 다른 것에 영향을 미치지 못하고 지가 보고 있는 허상만을 건들고 있다는 겁니다.

즉, IndexWriter가 인덱싱을 하는데 이넘의 IndexReader나 IndexSearcher는 그 사실을 알지 못합니다.
snapshot이라고 해야 하나요. 자기가 처음 인스턴스를 생성했을때 그 모습만을 바라보고 있습니다. 새로운 인덱싱이 추가되었는지 알지 못해요. 그래서, 데이터를 추가했는데 검색안된다고 아우성입니다.

그렇기 때문에 추가된 사항을 반영하려면 항상 필요할때마다 반복해서 인스턴스(Directory를 읽기위한)를 생성해야 합니다.

이러다 보니 실시간으로 처리하는 데이터 입출력 시스템에서는 별로 유효하지 않습니다.
엄청난 노가다를 해야 하는 셈이죠^^

참고로 이 루씬의 Directory는 하나의 문서를 표현하는 Document들로 구성되어 있으며
이 Document를 이루는 개별 필드인 Field로 구성되어 있습니다.
물론 데이터 관점에서 이런것이고 그 이외에 필요한 여러 파일들이 존재하고 있죠.

위의 3가지 IndexWriter, Reader, Searcher와 Document, Field의 개념만 알고 있어도 루씬을 사용하는데 아무런 지장이 없습니다.

문제는 많은 분들이 위에서 지적한 snapshot의 원리를 기억하지 못하고 헤멘다는 겁니다.^^

루씬으로 pdf, hwp, doc 파일을 검색할수 있나요?
없습니다. 불가능합니다.

루씬으로 DB검색할수 있나요?
불가능합니다.

루씬으로 웹검색을 할수 있나요?
NO..

그럼 도대체 뭘 할수 있나요?

검색을 할수 있습니다.
pdf던, hwp, doc 문서던
DB던 이것을 읽어 TEXT로 변환시킬수 있는 GATE만 만들수 있다면
루씬은 원하는 검색을 할수 있습니다.
크롤을 별도로 만들면 웹문서 검색도 할수 있습니다.

루씬은 들어오는 TEXT를 인덱싱하고 해당 인덱싱중 원하는 키워드를 포함하는 TEXT를 찾아주는 Library입니다.

이렇게 보면 별것 아니죠?
사실 별것 아녀요.^^

그렇지만 반대로 생각하면
GATE만 만들게 되면 검색에 관한 모든것을 해결해 줄수 있는 막강 검색엔진의 역할을 할수 있습니다.

하면 할수록 그 깊이가 의심(?)되는 루씬의 세계로 가봅시다.

출처 :http://www-128.ibm.com/developerworks/library/wa-lucene/indexing_architecture.gif

많은 사람들이 가지고 있는 장서들중 하나는 세익스피어전집이다. "Brutus AND Ceasar AND NOT Calpurnia" 라는 단어들을 찾기위해 이들을 포함하는 세익스피어의 작품을 찾는다고 가정해보자. 그중 한가지 방법은 처음부터 끝까지 모든 텍스트들을 읽는것인데 이경우 "Brutus" 와 "Caesar"를 포함하거나 "Calpurnia"를 포함하지 않는지를 고려하지 않고 모든 작품을 읽어야 한다. 문서검색을 하는 심플한 형태는 컴퓨터가 모든 문서를 선형적으로 스캔하게 하는 것이다. 이러한 프로세스는 텍스트를 "grepping"하는 것으로 주로 알려진, Unix 명령어인 grep같은 것이 이것을 수행한다. 문서를 grepping하는 것은 특히 현대컴퓨터들의 빠른 속도하에서 매우 효과적인 프로세스가 될수 있고, "정규표현식"을 사용하는 와이들카드 패턴매칭을 위한 유용한 도구를 제공한다. 현대 컴퓨터에게는 단순한 쿼리들에 대해서는 grep 외에는 필요하지 않을 수 있다.(세익스피어의 전집에서 사용되는 것은 기껏해야 100만단어 미만이다.)

그러나 많은 목적을 위해서는 더 많은 것들이 필요하다:
1.많은 수의 문서콜렉션들을 빨리 처리하기 위해서: 온라인 데이터의 수는 컴퓨터의 속도만큼이나 빨리 증가하고 있고 현재 우리는 수십억에서 수백억의 단어들을 처리해야 한다.

2.좀더 유연한 매칭처리를 허용해야 한다. :예를 들어 "5단어들 이내에" 혹은 "동일 문단에서"라는 조건으로 "Romans NEAR countrymen"이란 쿼리를 grep 처리하는 것은 비현실적이다.

3. 랭킹된 검색을 허용하기 위해서 필요하다.: 많은 경우에 있어 특정단어를 포함하는 수많은 문서들 중에서  좀더 나의 답을 제공하는 결과를 원할수 있다.

미리말하자면 각 쿼리에 대해 문서를 선형적으로 스캐닝하는 것을 피하는 방법은 문서들을 "인덱스"하는 것이다. 세익스피어 전집으로 돌아가서 Boolean 검색모델을 설명해보자. 각 문서들에 대하여 - 여기서는 세익스피어 작품- 세익스피어가 사용한 모든 단어들 가운데(세익스피어는 약 32,000정도의 단어를 사용했다.) 각 문서가 사용했던 안했던 간에 그 문서들을 기록한다고 가정해보자. 도 1.1에서 보듯이 그 결과는 쌍으로 이루어진 term-document "출현 매트릭스"로 된다. 여기서 "term"은 "단어"를 의미하는데 정보검색연구에서는 "term"이란 단어를 주로 선호한다. 이 매트릭스의 행이나 열을 살펴보면 각 텀에 대해 벡터값을 가질수 수있는데 이것은 해당 텀이 나타나는 문서들을 보여주는 것이고, 각 문서에 대한 벡터값을 가질수도 있는데 이것은 해당 문서에서 출현하는 텀들을 보여준다.

도 1-1. 텀-문서 출현 매트릭스. (i,j)의 값은 해당 칼럼으로 표현되는 작품 j가 행으로 표현되는 단어 i를 포함하면 "1"이 되고 그렇지 않으면 "0"이 된다.


"Brutus AND Casesar AND NOT Calpurnia"라는 쿼리에 답하기 위해 Brutus, Caesar와 ㅡCalpurnia에 대한 벡터값들을 취할수 있는데 이때 AND에 대한 비트연산을 수행한다.
 110100 AND 110111 AND 101111 = 100100
따라서 이 쿼리에 대한 답은 "Anthony and Cleopatra and Hamlet"이 되게 된다(도1-2)

도1-2."Brutus AND Casesar AND NOT Calpurnia"에 대한 세익스피어 작품 검색결과

Boolean 검색모델은 텀에 대한 Boolean으로 표현되는 형식의 쿼리로 언급하면 쉽다. 즉 텀들은 AND, OR, 그리고 NOT 연산으로 조합되어진다. 이러한 쿼리들은 단어의 집합으로서 각 문서들을 바라보게된다.