검색엔진 루씬 lucene & hadoop

Searcher Sample

gruter — Tue, 03 Mar 2009 15:29:21 +0900

package com.gruter.lia.meetlucene;

import java.io.File;
import java.util.Date;

import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.queryParser.QueryParser;
import org.apache.lucene.search.Hits;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.ScoreDoc;
import org.apache.lucene.search.TopDocs;
import org.apache.lucene.store.Directory;
import org.apache.lucene.store.FSDirectory;

/**
* Lucene version 2.4
* Lucene In Action 1.4.2 색인 내의 검색 코드에 대한 버전 수정본
**/
public class Searcher {
    public static void main(String[] args) throws Exception {
            if (args.length != 2) {
              throw new Exception("Usage: java " + Searcher.class.getName()
                + " <index dir> <query>");
            }

            File indexDir = new File(args[0]);
            String q = args[1];

            if (!indexDir.exists() || !indexDir.isDirectory()) {
              throw new Exception(indexDir +
                " does not exist or is not a directory.");
            }

            search(indexDir, q);
        }

        public static void search(File indexDir, String q)
            throws Exception {
//            Directory fsDir = FSDirectory.getDirectory(indexDir, false);
            Directory fsDir = FSDirectory.getDirectory(indexDir);
            IndexSearcher is = new IndexSearcher(fsDir);

//            Query query = QueryParser.parse(q, "contents",
//              new StandardAnalyzer());
            QueryParser parser = new QueryParser("contents", new StandardAnalyzer());
            Query query = parser.parse(q);
            long start = new Date().getTime();
//            Hits hits = is.search(query);
            TopDocs docs = is.search(query, 100);
            long end = new Date().getTime();

//            System.err.println("Found " + hits.length() +
//              " document(s) (in " + (end - start) +
//              " milliseconds) that matched query '" +
//                q + "':");
//
//            for (int i = 0; i < hits.length(); i++) {
//              Document doc = hits.doc(i);
//              System.out.println(doc.get("filename"));
//            }

            System.err.println("Found " + docs.totalHits +
              " document(s) (in " + (end - start) +
              " milliseconds) that matched query '" +
                q + "':");
            ScoreDoc[] scores = docs.scoreDocs;
            float maxScore = docs.getMaxScore();
            for (int i=0 ;i<docs.scoreDocs.length;i++){
                Document doc = is.doc(docs.scoreDocs[i].doc);
                  System.out.println(doc.get("filename"));
            }
        }
}

Indexer Sample

gruter — Tue, 03 Mar 2009 15:08:41 +0900

package com.gruter.lia.meetlucene;

import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.util.Date;

import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.index.IndexWriter;

/**
* Lucene version 2.4
* Lucene In Action 1.4.1 색인만들기 코드에 대한 버전 수정본
**/

public class Indexer {

   public static void main(String[] args) throws Exception {
      if (args.length != 2) {
      throw new Exception("Usage: java " + Indexer.class.getName()
      + " <index dir> <data dir>");
      }
      File indexDir = new File(args[0]);
      File dataDir = new File(args[1]);

      long start = new Date().getTime();
      int numIndexed = index(indexDir, dataDir);
      long end = new Date().getTime();

      System.out.println("Indexing " + numIndexed + " files took "
      + (end - start) + " milliseconds");
      }

      public static int index(File indexDir, File dataDir)
      throws IOException {

      if (!dataDir.exists() || !dataDir.isDirectory()) {
      throw new IOException(dataDir
      + " does not exist or is not a directory");
      }

//    IndexWriter writer = new IndexWriter(indexDir,
//    new StandardAnalyzer(), true);

   IndexWriter writer = new IndexWriter(indexDir, new StandardAnalyzer(), true, IndexWriter.MaxFieldLength.UNLIMITED);

      writer.setUseCompoundFile(false);

      indexDirectory(writer, dataDir);

//    int numIndexed = writer.docCount();
      int numIndexed = writer.numDocs();
      writer.optimize();
      writer.close();
      return numIndexed;
      }

      private static void indexDirectory(IndexWriter writer, File dir)
      throws IOException {

      File[] files = dir.listFiles();

      for (int i = 0; i < files.length; i++) {
      File f = files[i];
      if (f.isDirectory()) {
      indexDirectory(writer, f); // recurse
      } else if (f.getName().endsWith(".txt")) {
      indexFile(writer, f);
      }
      }
      }

      private static void indexFile(IndexWriter writer, File f)
      throws IOException {

      if (f.isHidden() || !f.exists() || !f.canRead()) {
      return;
      }

      System.out.println("Indexing " + f.getCanonicalPath());

      Document doc = new Document();

//    doc.add(Field.Text("contents", new FileReader(f)));
   doc.add(new Field("contents", new FileReader(f)));
       doc.add(new Field("filename", f.getCanonicalPath(), Field.Store.YES, Field.Index.ANALYZED, Field.TermVector.NO));
      writer.addDocument(doc);
      }

}

lucene scoring(ver 2.4)

gruter — Thu, 26 Feb 2009 00:28:02 +0900

how to get lucene (document) score.

TopDocs docs = searcher.search(query, null, 10, defaultSort);
ScoreDoc[] scores = docs.scoreDocs;
float maxScore = docs.getMaxScore();
for (int i=0 ;i<docs.scoreDocs.length;i++){
Document doc = searcher.doc(docs.scoreDocs[i].doc);
float docscore = scores[i].score / maxScore;
}

another sample : http://devyongsik.tistory.com/203

루씬의 기본구조

gruter — Thu, 30 Aug 2007 11:00:47 +0900

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

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

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

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

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

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

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

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

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

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

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

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

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

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

루씬으로 할수 있는것.

gruter — Mon, 20 Aug 2007 16:00:06 +0900

루씬으로 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

1.1 정보검색문제의 예 - .1

gruter — Wed, 08 Aug 2007 20:45:59 +0900

많은 사람들이 가지고 있는 장서들중 하나는 세익스피어전집이다. "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 연산으로 조합되어진다. 이러한 쿼리들은 단어의 집합으로서 각 문서들을 바라보게된다.

1. Boolean Model을 이용한 정보검색(Information Retrieval)

gruter — Tue, 07 Aug 2007 20:22:00 +0900

정보검색(Information Retrieval)이라는 용어의 의미는 상당히 광범위하다. 어쩌면 지갑에서 신용카드를 꺼내서 카드번호를 적는 그 자체도 정보검색의 일종이다. 하지만 학술적으로는 다음과 같이 정의될수 있다.

"정보검색(IR)이란 (주로 컴퓨터에 저장되어 있는) 방대한 콜렉션안에 있는 정보욕구를 해결해주는, 구조화되지 않은 자연상태(주로 text로 된)의 물질(문서같은)을 찾는 것이다"

이렇게 정의되는 정보검색은 도서관 사서, 법률 보조원과 전문 검색사들 같은 소수의 사람들만이 했던 활동으로 여겨져왔다. 지금은 세상이 변했고 수백만의 사람들이 웹검색엔진을 이용하고 자신의 이메일을 사용하면서 매일 정보검색을 하고 있다. 정보검색은 정보를 접근하는데 있어 강력한 방법으로 빠르게 변화하고 있으며 전통적인 데이터베이스방식의 검색을 추월하고 있다.

정보검색은 위에서 언급한 핵심적 정의를 넘어서 다른 종류의 데이터나 정보문제로까지 확장될수 있다. "비정형화된 데이터"라는 것은 명확하지 않고, 의미론적으로 명백하지 않으며, 컴퓨터가 이해하기 쉽지않는 구조를 가진 데이터를 말한다. 그것은 구조화된 데이터의 반대개념으로 표준적인 예로, 분류를 주업으로 하는 회사들이 상품목록이나 개인정보들을 유지하기 위해 주로 사용하는 관계형데이터베이스를 들수 있다. 현실적으로는 완전히 "비정형적인" 데이터는 존재하지 않는다. 만약 당신이 인간이 사용하는 언어들의 잠재적인 언어구조를 세어본다면 모든 텍스트 데이터에 대하여 이말이 맞다는걸 확인할수 있을것이다. 그러나 이러한 것들이 명백히 구조화되었다는 것을 인정한다면 대부부분의 텍스트는 구조를 가지고 있는것을 알수 있는데 그것은 명백히 마크업으로 표현된 문서에서 주로 나타나는 제목, 문단 각주 등의 구조를 가지고 있다. 정보검색은 또한 "자바"를 제목에서 가지고 있고 본문엔 여러가지를 단어들을 가지는 문서를 찾는것처럼 "준-구조화된" 검색을 용이하게 하는데 사용되기도 한다.

정보검색분야는 또한 문서들을 처리하거나 검색된 문서집합을 점더 깊이 처리하는 과정을 포괄하기도 한다. 문서집합이 주어진다면 클러스터링은 문서들의 내용에 기초하여 좋은 문서그룹을 만드는 일을 한다. 주제가 주어진다면 분류는 각 문서가 어디에 속해있는가를 결정하는 일을 수행한다. 대체로 처음엔 수동으로 일정 문서들을 분류한다음에 새로운 문서에 대해서는 자동으로 분류되겠끔 처리하는 것이 보통이다.

이 장에서는 정보검색에 수반되는 문제점을 시작으로 텀-문서 매트릭스 구조의 아이디어를 살펴보며, 중심적인 역인덱스데이터 구조를 살펴볼것이다. 그런다음에 Boolean 검색모델과 어떻게 쿼리들이 처리되는지를 살펴볼것이다.

application이 아닌 library로서의 루씬

gruter — Tue, 07 Aug 2007 13:52:00 +0900

루씬을 접하면서 많이들 잘못생각하는 것중의 하나가
루씬이 이미 잘 만들어진 제품(application)으로 착각하는 것입니다.

루씬은 검색엔진제품을 만들어주는 기반이 되는 Library이지 이미 만들어진 제품이 아닙니다.
제품의 영역은 개발자 자신이 얼마나 해당 Library를 잘 이해하고 접목하느냐의 능력에 달려 있습니다.

그렇기 때문에 "공짜야"하면서 달려든 루씬 사용자들은 그 검색엔진의 깊이를 감당하지 못하고 나자빠집니다.

lucene library와 search application과의 관계를 간략히 도식화 하면 다음과 같습니다.
(출처 : http://www.webreference.com/programming/lucene/fig1-5.jpg)

그렇기 때문에
동일한 제품을 만들더라도 그 제품을 만드는 모든 개발자가 좋은 제품을 만드는 것이 아니듯
루씬에 대한 이해와 활용능력에 따라 검색엔진(서비스)의 품질도 달라집니다.

그래서 루씬도 공부 많이 해야합니다.^^

검색엔진의 종류

gruter — Tue, 07 Aug 2007 12:11:39 +0900

검색한다는 것은 존재하는 무엇을 찾아준다는 것입니다.
그 존재하는 것은 여러가지의 목적물이 될수 있는데 이것은 문서, 장소 등에 구애받지 않습니다.

그 중에서 검색엔진은 자신이 해석할 수 있는 "텍스트로 표현"될수 있는 목적물을 찾아줍니다.
장소, 사람 등도 텍스트로 표현될수 있거나 이미 표현되어 있다면 그 무엇이든 검색엔진은 찾아줄수 있습니다.

"검색엔진"이란 말을 접하면 사람들은 각기 다른 도구를 생각합니다.
어떤 사람은 포털같은 웹서비스를 떠오르기도 하고
어떤 사람은 웹문서를 수집하는 크롤러를,
또 어떤 사람은 검색엔진 기술을 가진 업체를 떠올리기도 합니다.
심지어는 데이터베이스를 떠올리기도 합니다.

사실 "검색"을 구현하는 "검색엔진"은 여러가지로 표현될수 있습니다만
기술적인 의미에서 볼때 "검색서비스"와 "검색엔진"은 다른 의미입니다.

기술적인 의미에서의 좀 더 넓은 검색엔진은
- 자료를 인덱싱하고 찾아주는 순수한 의미의 검색기술인 정보검색(Information Retrieval)기술과
- 검색엔진에 자료를 가져다 주는 크롤링 기술
- 좀 더 다양하고 효과적인 방법으로 검색을 수행하고 표현하는 클러스터링 기술, 자동분류 기술
등을 들수 있습니다.

요즘처럼 시맨틱 웹이나 온톨로지, 시소러스 등의 개념이나 기술들도 검색엔진의 한 분야로 볼수 있을 정도로 검색엔진의 범위규정은 쉽지가 않습니다.

그러나 이모든 검색엔진기술이 추구하는 목적들은
"잘 찾아주기" 위한 것입니다.

이러한 광범한 기능중에
루씬은 문서를 "잘 인덱싱하고 빨리 찾아주기"위한 순수한 Information Retrieval Library중의 하나입니다.

검색엔진을 다루면서 항상 염두에 두어야 할것은
검색엔진이 해석하고 처리할 수 있는 부분만이 가능하다는 것입니다.

검색엔진은 만능이 아닙니다.
그렇기 때문에서 사용하는 검색엔진의 깊은 내막이나 사용법을 잘 이해할 필요가 있습니다.

그 이상은 불가능합니다.
"꼬우면 직접 만드세요^^"

Scale-up versus Scale-out

gruter — Tue, 31 Jul 2007 07:13:45 +0900

comparing scaling-up (using bigger boxes) to scaling-out (using more boxes)

scale-out solutions have an indisputable performance and price/performance advantage over scale-up for search workloads.

http://blog.lucene.com/2007/07/30/scale-up-versus-scale-out/