|
원문 : http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-lucene_p.html
Jakarta Lucene
Lucene는 2000년 Jive Forums의 소스 분석을 하면서 접하게 되었다. Lucene는 당시 Doug Cutting이라는 사람이 오픈 소스 모델로 자바로 구현한 텍스트 검색엔진이었다. 현재 Lucene는 아파치 자카르타 프로젝트에 포함이 되어 발전하고 있다.
Lucene는 텍스트 검색 엔진으로 대부분의 기능을 지원한다. 현재 여러 프로그램에 탑재되어 사용되고 있는데, 예를 들면 Jive Forums에서 게시물 검색에 사용되거나 이메일 클라이언트 애플리케이션에서 이메일 검색에서 사용된다. 역자의 경우에도 Lucene를 사용하여 커뮤니티 시스템에서 검색 기능과 웹 사이트 검색 기능을 구현해보기도 하였다.
Lucene에 대한 이해를 돕기 위해 조금 오래된 문서이기는 하지만 예전에 번역 했던 문서를 아래에 싣는다. Lucene가 자카르타 프로젝트에 포함되기 전에 작성된 문서이기 때문에 현재 버전의 Lucene와 다를 수 있다. 예를 들면 현재 사용되는 패키지명은 에전과 다르다. 공부 목적으로 번역된 기사인 만큼 매끄럽게 번역되지 못했으며 오역이 있을 수 있음을 밝힌다.
Lucene에 대한 보다 자세한 정보는 아래 사이트에서 볼 수 있다:
http://jakarta.apache.org/lucene/
낮은 버전 (2000년 8월 0.04 버전) 을 사용하지 마라. 이건 바보같은 짓이다. (역자: 2003년 3월 현재 Lucene 버전은 1.2 이다). Lucene 검색 엔진은 가장 일반적인 검색 문제를 해결할 수 있는 탄탄하고 강력하며 유연한 검색 툴킷이다. 이것은 현재 보다 유연한 LGPL 오픈 소스 라이센스에서 사용할 수 있다. 가격 역시 그러하다. (무료다!)
텍스트 검색의 경험많은 개발자인 Doug Cutting이 Lucene를 만들었다. Cutting은 Apple의 Copland 운영 체제 성과의 일부인 V-Twin 검색 엔진의 주요 개발자이고 현재 Exite에서 수석 아키텍트로 일하고 있다. 그는 색인화 및 검색 기능을 아래와 같은 다양한 범위의 애플리케이션에 쉽게 추가하기 위해 Lucene를 설계했다:
- 이메일 검색: 저장된 메시지를 검색할 수 있고 새로 도착한 메시지를 새인에 추가할 수 있는 이메일 애플리케이션.
- 온라인 문서 검색: 온라인 문서 또는 저장된 출판물을 검색할 수 있는 CD 기반이나 웹 기반 또는 애플리케이션에 포함된 문서 판독기(reader).
- 웹 페이지 검색: 사용자가 방문한 모든 웹 페이지를 색인화하기 위해 개인 검색 엔진을 만들 수 있는 웹 브라우저 또는 프록시 서버. 이것을 사용하여 쉽게 페이지를 다시 방문할 수 있다.
- 웹 사이트 검색: 웹 사이트를 검색할 수 있는 CGI 프로그램
- 내용 검색: 저장된 문서에서 특정 내용을 검색할 수 있는 애플리케이션. 내용 검색 기능은 문서 열기 대화상자에 통합될 수 있을 것이다.
- 버전 관리 및 컨텐트 관리: 문서나 문서 버전을 색인화해서 쉽게 검색할 수 있는 문서 관리 시스템.
- 뉴스 및 유선(wire) 서비스: 뉴스가 도착했을 때 기사를 색인할 수 있는 뉴스 서버나 릴레이 서버.
물론 많은 검색 엔진이 이러한 기능의 대부분을 지원한다. Lucene과 같은 쉬운 사용, 빠른 구현, 유연성을 제공하는 오픈 소스 검색 도구는 거의 없다.
저자는 메일링 리스트를 작성하고 찾아보기 위한 자바 기반의 오픈 소스 툴인 Eyebrowse(아래 참고를 보라.)를 개발할 때 처음 Lucene를 사용했다. Eyebrowse의 핵심적인 요구사항은 유연한 메시지 검색 기능이었다. Eyebrowse는 새로운 메시지가 도착하였을 때 색인을 효과적으로 변경할 수 있는 색인 및 검색 컴포넌트가 필요하였다. 색인 및 검색 컴포넌트는 여러명이 동시에 색인을 변경하고 검색할 수 있고 수백만의 메시지를 저장할 수 있어야 했다.
저자는 Swish-E, Glimpse, iSearch, 그리고 libibex와 같은 모든 오픈 소스 검색 엔진을 테스트하였다. 이들 검색 엔진은 어떤 면에서 Eyebrowse의 요구사항에 알맞지 못하였다. 그리고 통합이 어렵고 시간이 너무 소요되었다. Lucene를 사용하여 저자는 색인 및 검색 기능을 Eyebrowse에 추가하는데 다운로드하는 것에서 부터 완벽하게 동작하는 코드를 만드는데 고작 한나절 조금 더 걸렸다. 이것은 저자가 할당했던 개발 시간의 10분의 1도 안되었다. 그리고 저자가 고려했던 어떤 다른 검색 도구보다 완벽하게 통합되었고 기능이 풍부하였다.
검색 엔진은 어떻게 동작하는가?
능률적인 키워드 검색 엔진을 개발할 때 정반대인(inverted) 색인을 생성하고 유지하는 것이 주요 문제이다. 문서를 색인하기 위해서는 먼저 포스팅 목록을 생성하기 위해 색인을 조사하여야 한다. 포스팅은 문서에서 단어가 있음을 의미한다. 그래서 포스팅은 일반적으로 단어, 문서 ID와 위치, 또는 문서에서 단어의 빈도를 포함한다.
<word, document id> 형식의 한벌로써 포스팅을 생각한다면 문서의 하나의 세트는 문서 ID로 정렬된 포스팅의 목록이 될 것이다. 그러진나 특정한 단어를 가진 문서를 효과적으로 찾기 위해서는 단어로 (또는 여러 단어 검색을 빠르게 하기 위해서 단어와 문서를 함께 사용하여) 포스팅을 정렬하여야 한다. 이러한 관점에서 검색 색인을 만드는 것은 기본적으로 정렬 문제이다. 검색 색인은 단어에 의해 정렬된 포스팅의 목록이다.
혁신적인 구현
대부분의 검색 엔진은 색인을 관리하기 위해 B-트리를 사용한다. B-트리는 삽입에 관해서는 상대적으로 안정적이고 잘 동작하는 I/O 특징(검색과 삽입은 O(log n) 연산이다.)을 가지고 있다. Lucene는 조금 다른 접근을 시도하였다. 바로 하나의 색인을 관리하는 것인데, 이것은 여러 색인 조각을 만들고 주기적으로 여러 색인 조각을 하나로 합치는 것이다. 각각의 새로운 문서가 색인되는 것을 위해 Lucene는 하나의 새로운 색인 조각을 만든다. 그러나 Lucene는 이 작은 색인 조각을 빠르게 큰 색인으로 합친다. 이것은 전체 조각의 개수를 작게 유지하여 검색이 빠르게 한다. 빠른 검색을 위한 색인 최적화를 위하여 Lucene는 모든 조각을 하나로 합칠 수 있다. 이 방법은 덜 자주 변경되는 색인에 유용하다. 색인 리더(reader)와 작성자(writer) 사이의 충돌(또는 잠금 오버헤드)을 방지하기 위해 Lucene는 조각을 그 자리에서 변경하지 않는다. 단지 새로운 조각을 만든다. 조각을 합칠때 Lucene는 새로운 조각을 만들고 (모든 활성화된 리더가 이 조각을 닫은 후) 이전 조각을 삭제한다. 이런 접근은 검색 속도를 색인 속도로 바꾸어 높은 유연성을 제공한다. 그리고 병합과 검색을 위한 바람직한 I/O 특징을 가지고 있다.
Lucene 색인 조각은 다음과 같은 여러개의 파일로 구성된다:
- 사전(dictionary)에 각각 100개 요소를 위한 하나의 요소를 가진 사전 색인.
- 각각의 유일한 단어를 위한 하나의 요소를 가진 사전
- 각각의 포스팅을 위한 하나의 요소를 가진 포스팅 파일
Lucene가 조각을 그 자리에서 변경하지 않기 때문에 조각은 복잡한 B-트리 대신에 단순한 파일에 저장될 수 있다. 빠른 검색을 위해 사전 색인은 사전 파일에 오프셋을 가지고 있고, 사전은 포스팅 파일에 대한 오프셋을 가지고 있다. Lucene는 또한 상당한 CPU 오버헤드없이 사전과 포스팅 파일을 압축하기 위한 (그래서 디스크 I/O를 줄이는) 여러 방법을 구현한다.
검색 엔진 테스트하기
Swish-E, Glimpse, libibex, freeWAIS와 iSearch를 포함한 다른 오픈 소스 검색 엔진은 널리 사용되었다. 모든 소프트웨어 패키지와 비슷하게 각각은 특별한 환경에서 최적화되었다. 이것으로 인해 때때로 이들 도구를 정해진 부분 밖에서 적용하기가 어렵게 되는 요인이다. 검색 엔진을 테스트할 때 다음 기능을 고려한다:
- 증분(incremental) 대 배치(batch) 색인: 일부 검색 엔진은 단지 배치 색인만을 지원한다. 즉, 이들 엔진은 문서의 세트를 위한 색인을 생성할 수 있다. 따라서 모든 문서의 색인을 다시 작성하지 않고 새로운 문서를 추가하는 것은 어렵다. 증분 색인은 기존의 색인에 문서를 쉽게 추가할 수 있다. 실시간 데이터 변경을 처리하는 일부 애플리케이션에서 증분 색인은 매우 중요하다. lucene는 증분 색인과 배치 색인을 모두 지원한다.
- 데이터 소스: 많은 검색 엔진은 단지 파일이나 웹 페이지를 색인할 수 있다. 이것은 데이터베이스에서 색인된 데이터를 가져오는 애플리케이션이나 ZIP 아카이브와 같이 단일의 파일에 여러 가상 문서가 있는 애플리케이션에게 불리하다. Lucene는 String 나 IndexStream를 통해 색인자(indexer)에게 문서를 전달할 수 있고 데이터에서 추상화될 수 있는 데이터 소스를 허용한다. 그러나 이런 접근에는 데이터를 위한 올바른 리더가 제공되어야 한다.
- 색인 관리: 일부 검색 엔진은 색인하기 위해 문서를 찾으려고 자동으로 디렉토리 트리나 웹 사이트를 탐색할 수 있다. 이것이 편리하긴 하지만 만약 데이터가 이미 이 방법으로 저장되었다면 크롤러(crawler) 기반의 색인자(indexer)는 때때로 색인된 문서상에 세밀한 관리가 필요한 애플리케이션에는 유연성이 제한된다. Lucene는 주로 증분 모드에서 동작하기 때문에 애플리케이션이 문서 검색을 할 수 있다.
- 파일 형식: 일부 검색 엔진은 단지 텍스트나 HTML 문서를 색인할 수 있다. 또 어떤 검색 엔진은 워드 프레시싱 문서, SGML 문서, 그리고 다른 파일 형식을 색인하기 위해서 선택할 수 있는 필터 매카니즘을 제공한다. Lucene는 이런 매카니즘을 지원한다.
- 컨텐트 태그달기(tagging): 일부 검색 엔진은 하나의 문서를 하나의 토큰의 스트림으로 다룬다. 다른 검색 엔진은 "subject", "abstract", "author", 그리고 "body"와 같이 문서내에 여러개의 데이터 필드를 지정하는 것을 지원한다. 이것은 "작가에 Hamilton이 있고 본문에 Constibution이 있다"와 같이 의미상으로 풍부한 질의를 가능하게 한다. Lucene는 필드의 모음으로써 문서를 다루는 방법으로 컨텐트 태그달기를 지원한다. 그리고 검색할 필드를 지정하는 질의를 지원한다.
- 중지 단어(stop-word) 처리: "a", "and", "the"와 같은 일반 단어 색인을 검색하기 위해 작은 값을 추가한다. 이들 단어가 너무 일반적이기 때문에 이들을 분류하는 것은 색인 시간과 색인 크기에 상당히 투자하여야 한다. 대부분의 검색 엔진은 stop word라고 불리는 특정 단어를 색인하지 않는다. 일부는 중지 단어 목록을 사용하고, 다른 일부는 통계적으로 중지 단어를 선택한다. Lucene는 아래에서 설명할 가장 일반적인 Analyzer 매카니즘으로 중지 단어를 처리하고 입력 스트림에서 중지 단어를 제거하는 StopAnalyzer 클래스를 제공한다.
- Stemming: 가끔 사용자는 다른 비슷한 단어에 일치하는 단어를 질의하길 원한다. 예를 들면 "jump"를 질의하는 것은 "jumped", "jumper", 또는 "jumps"라는 단어에 일치할 수도 있다. 단어의 어간 형식으로 단어를 만드는 것을 steamming이라고 부른다. Lucene는 stemming을 아직 구현하고 있지 않지만 정교한 Analyzer 클래스를 통해 쉽게 stemmer를 추가할 수 있다.
- 질의 기능: 검색 엔진은 다양한 질의 기능을 지원한다. 일부 엔진은 완전한 부울(boolean) 질의를 지원하고, 일부는 단지 AND 질의를 지원한다. 일부는 각각의 히트(hit)에 "적합" 점수를 리턴한다. 일부는 "search followed by engine"이나 "Knicks near Celtics"과 같은 인접 또는 근접 질의를 처리할 수 있다. 일부는 단지 단일 키워드를 검색할 수 있다. 일부는 동시에 여러 색인을 검색하여 의미있는 적합 접수를 매기기위해 결과를 종합할 수 있다. Lucene는 위에 언급된 모든 질의 기능을 포함하는 폭넓은 질의 기능을 지원한다. Lucene는 가치있는 발음이 비슷한 단어를 검색하기 위한 질의인 사운덱스(Soundex)를 지원하지는 않는다.
- 동시성: 동시에 얼마나 많은 사용자가 색인을 검색할 수 있을까? 다른 사용자가 색인을 변경하는 동안 사용자는 색인을 검색할 수 있을까? Lucene는 심지어 다른 사용자가 동시에 색인을 변경할 때에도 색인을 검색할 수 있다.
- 비 영문 지원: 많은 검색 엔진은 암묵적으로 영어가 대상 언어라고 간주한다. 이것은 중지 단어 목록과 stemming 알고리즘, 일치하는 문구에 근접하는 질의의 사용과 같은 영역에서 명백하다. Lucene는 개발자가 만든 Analyzer 클래스를 통해 입력 스트림을 전처리하여 특정 언어 필터링을 실행할 수 있다.
위의 목록은 특정 프로젝트를 위한 검색 엔진을 테스트하기 위한 시작 점을 제공한다. 일부 검색 엔진은 이러한 작업에 덜 적합하다. 애플리케이션의 요구사항을 제대로 이해하는 것은 업무에 맞는 올바른 도구를 찾을 수 있게 도움이 될 것이다.
Lucene 사용하기
저자는 색인을 만들고 유지하고 검색하기 위해 어떻게 Lucene를 사용하는지를 설명할 것이다. 쉽게 설명하기 위해 import 문장과 예외 처리는 예제 프로그램에서 생략되었다. 예제에서 저자는 검색 색인을 파일 시스템에 저장하였다. (색인은 메모리나 데이터베이스와 같이 어디라도 저장될 수 있다). 색인될 파일은 간단한 텍스트 파일이다. Lucene로 또한 쉽게 다른 문서 형식과 파일에 저장되지 않은 문서를 색인화 할 수 있다.
색인 만들기
간단한 CreateIndex.java 프로그램은 IndexWriter 객체를 생성하는 것으로 비어있는 색인을 생성한다. 이 예에서 색인이 저장될 디렉토리 이름은 명령 줄에서 지정될 것이다.
public class CreateIndex {
// 사용법: CreateIndex 색인-디렉토리
public static void main(String[] args) throws Exception {
String indexPath = args[0];
IndexWriter writer;
// An index is created by opening an IndexWriter with the
// create argument set to true.
writer = new IndexWriter(indexPath, null, true);
writer.close();
}
}
텍스트 문서 색인
IndexFile.java는 명령 줄에 지정된 파일을 색인에 어떻게 추가하는지 보여준다. 각각의 파일을 위해 IndexFiles는 Document 객체를 생성한다. 그리고 색인이 문서를 추가하기 위해 IndexWriter.addDocument를 호출한다. Lucene의 관점에서 Document는 이름과 값이 한쌍인 필드의 모음이다. Field는 짧은 필드를 위해서는 String에서, 긴 필드에서는 InputStream에서 값을 얻을 수 있다. 필드를 사용하는 것으로 문서를 분리하여 검색하는 것과 색인할 수 있는 부분으로 구분할 수 있고, 문서의 이름, 작가, 또는 수정일과 같은 메타데이터를 연결할 수 있다. 예를 들면 메일 메시지를 저장할 때 메시지의 제목, 보낸 사람, 날짜, 본문을 분리된 필드에 넣을 수 있다. 그리고 "제목에 Java가 있고 작가는 Gosling이 있다"와 같은 의미상으로 풍부한 질의를 만들 수 있다. 아래 코드에서 각각의 Document에 2개의 필드를 저장한다. 이 필드는 나중에 꺼낼 수 있도록 원래 파일 패스를 가르키는 path와 파일의 본문을 위한 body이다.
public class IndexFiles {
// usage: IndexFiles index-path file . . .
public static void main(String[] args) throws Exception {
String indexPath = args[0];
IndexWriter writer;
writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);
for (int i=1; i<args.length; i++) {
System.out.println("Indexing file " + args[i]);
InputStream is = new FileInputStream(args[i]);
// We create a Document with two Fields, one which contains
// the file path, and one the file`s contents.
Document doc = new Document();
doc.add(Field.UnIndexed("path", args[i]));
doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
writer.addDocument(doc);
is.close();
};
writer.close();
}
}
검색
Search.java는 색인을 어떻게 검색하는지에 대한 예를 제공한다. com.lucene.Query 패키지는 정교한 질의를 만들기 위한 많은 클래스를 가지고 있다. 여기에서는 가장 일반적인 질의를 처리하고 사용하기에 덜 복잡한 내장된 쿼리 파서를 사용한다. Searcher 객체를 생성하고 Query 객체를 생성하기 위해 QueryParser를 사용한다. 그리고 질의에서 Searcher.search를 호출한다. 검색 동작은 질의에 일치하는 각각의 문서를 위한 Document 객체의 집합인 Hits 객체와 각각의 문서에 대한 연관 를 적합 점수로 정렬하여 각각의 문서의 적합 점수를 리턴한다.
public class Search {
public static void main(String[] args) throws Exception {
String indexPath = args[0], queryString = args[1];
Searcher searcher = new IndexSearcher(indexPath);
Query query = QueryParser.parse(queryString, "body", new SimpleAnalyzer());
Hits hits = searcher.search(query);
for (int i=0; i<hits.length(); i++) {
System.out.println(hits.doc(i).get("path") + "; Score: " + hits.score(i));
};
}
}
내장 질의 파서는 대부분의 질의를 지원한다. 그러나 이 파서가 부족하다면 제공된 풍부한 질의-생성 세트를 다시 구성할 수 있다. 질의 파서는 다음과 같은 질의를 분석할 수 있다:
free AND "text search" |
"free"와 "text search" 문장을 가진 문서를 검색한다. |
+text search |
"text"와 우선적으로 "search"를 가진 문서를 검색한다. |
giants -football |
"giants"를 검색하되 "football"을 가진 문서는 제외한다. |
author:gosling java |
저자 필드에 "gosling" 을 가지고 있고 본문에 "java"를 가진 문서를 검색한다. |
기본적인 텍스트 문서를 넘어서
Lucene는 텍스트 색인을 생성하는 것을 지원하기위해 Document, Analyzer, 그리고 Directory의 3가지 주요 추상을 사용한다. Document 객체는 Field 객체(이름-값 한쌍)의 모음으로 설계된 하나의 문서를 표현한다. 각각의 문서를 색인하기 위해 애플리케이션은 Document 객체를 만들고 색인 저장소에 추가한다. Analyzer는 각각의 Field의 내용을 연속된 토큰(token)으로 변환한다.
Lucene에서 색인의 기본 단위인 Token은 중지 단어 제거, stemming, 필터링, 용어 표준화, 또는 언어 번역과 같은 어떤 문서 변환이 적용된 후에 색인될 하나의 단어를 표현한다. 애플리케이션 필터는 Analyzer 클래스를 통해서 색인될 필요가 없는 중지 단어 또는 입력의 일부분과 같은 토큰은 버린다. 또한 입력에서 만나게 되는 토큰을 stemming 또는 다른 용어 표준화를 실행하기 위해 수정한다. 편리하게도 Lucene는 단어 동일화와 중지 단어 제거와 같은 일반적인 변환을 처리하기 위해 표준 Analyzer 객체의 세트를 가지고 있다. 그래서 간단한 텍스트 문서를 색인하는 것에는 추가적인 작업이 필요하지 않는다. 만약 충분하지 않다면 개발자는 보다 정밀한 분석자(analyzer)를 만들 수 있다.
애플리케이션은 문서 데이터를 Analyzer가 토큰의 스트림으로 변환한 String이나 InputStream의 형태로 제공한다. 이 이유로 인해 Lucene는 단지 파일이 아닌 어떤 데이터 소스의 데이터라도 색인할 수 있다. 만약 문서가 파일에 저장되어 있다면, IndexFile.java에 표시된 것 처럼 문서를 꺼내기 위해 FileInputStream을 사용한다. 만약 Oracle 데이터베이스에 문서가 저장되어 있다면, 문서를 꺼내기 위해 InputStreamFilterInputStream로 이 작업을 할 수 있다. FilterInputStream는 문서 스트림을 문서의 내용 텍스트만을 가진 스트림으로 변환한다. 그래서 문서를 꺼내기 위해 InputStream을 FilterInputStream에 연결할 수 있다. 데이터베이스에서 문서를 추출하기 위해 FileInputStream 대신에 애플리케이션이 제공하는 InputStream 클래스를 사용한다. 그리고 XML을 분석하고 원했던 내용을 추출하기 위해 애플리케이션에서 제공하는 FilterInputStream을 사용한다.
Lucene는 애플리케이션이 Analyzer와 InputStream 클래스를 통해 원시(raw) 문서를 처리하는 것을 관리하는 것을 지원한다. 또한 색인 저장소(Directory)를 읽고 쓰기 위해 추상 클래스를 정의한다. Lucene는 또한 RAM(RAMDirectory)이나 파일(FSDirectory)에 색인을 저장하기 위해 Directory의 실제 구현을 제공한다. 예로 색인 데이터를 문서 관리 시스템이나 데이터베이스에 저장하기 위해 (또는 색인 데이터를 압축하고 암호화하기 위해), 자신만의 Directory 클래스를 간단하게 만들 수 있다. 대부분은 사용자는 일반적으로 파일 기반의 구현을 사용할 것이다. 그러나 패키지의 유연성을 높이는 색인 저장소를 처리하기 위한 애플리케이션을 지원한다.
사례 연구
Eyebrowse를 개발할 때 우리는 널리 사용되는 많은 오픈 소스 검색 도구를 테스트하였다. 처음에는 Eyebrowse의 검색 기능이 매우 수월해 보였다. 그러나 우리는 목적에 맞는 충분히 유연한 도구가 거의 없다는 것을 알고 놀랐었다. 대부분은 검색 엔진은 우리에게는 필요없는 단지 파일이나 웹 페이지를 색인하기 위해 설계되었다. 왜냐하면 메시지 메타 정보는 SQL 데이터베이스에 저장 되어있고, 많은 개인의 메시지를 가진 메시지 본문과 첨부파일은 메일박스 파일에 저장 되어있다. 메일박스 파일을 색인 목적으로 수많은 작은 파일로 분해하는 어리석고 비능률적으로 보이는 중간 단계가 필요하다.
Lucene는 검색 툴킷이지 완전한 검색 프로그램이 아니기 때문에 lucene를 우리의 애플리케이션에 완벽하게 통합하고 동작을 관리하기 매우 쉬웠다. Lucene의 유연한 문서 모델 덕분에 우리는 데이터베이스에서 추출한 메타데이터와 메일박스 파일에서 추출한 메시지 본문을 합친 가상 문서를 생성하고 색인할 수 있었다. 유용한 증가하는(incremental) 색인을 지원하기 때문에 새로운 메시지를 도착했을 때 색인에 추가할 수 있었다. 내장 질의 파서는 우리가 필요한 모든 질의를 지원했고 검색 성능은 완벽했다. 결국, 우리는 우리가 할당했던 시간보다 훨신 적은 시간동안에 요구된 검색 기능을 추가했다. 더 중요한 것은 우리가 결과의 질에 매우 만족하였다는 것이다.
무엇을 배울 수 있나?
Lucene는 훌륭한 객체 지향 소프트웨어 설계와 아키텍트의 좋은 예이다. 애플리케이션과 검색 엔진 사이에 조심스럽게 만들어진 분리는 설계의 바로 밑에 놓여있다. 애플리케이션과 검색 엔진 사이의 조심스럽게 만들어진 분업은 검색 엔진의 설계에 놓여있다. 이것은 완전화 과정에서 색인하는 것과 단일의 기능을 수행하는 것과 그리고 단일의 도메인을 운용하는 것은 여러 객체의 집합으로 변경한다. 예를 들면 파일을 색인할 때 FileInputStream 클래스는 문서 데이터를 추출한다. Analyzer는 토큰의 스트림으로 문서 데이터를 변환한다. IndexWriter 클래스는 토큰을 색인한다. FSDirectory 클래스는 색인을 나중에 추출하기 위해 디스크에 저장한다. 이러한 클래스 각각은 하나의 기능을 수행하고, 각각은 다른 것에 영향을 주지 않고 쉽게 교체될 수 있다.
Lucene의 팩토링은 애플리케이션이 기능을 보강할 수 있게 한다. 문서를 선택하고 추출하기, 색인 데이터를 저장하기에 대한 기능은 이미 알고 있다. 그리고 검색 엔진을 최상으로 가장 잘 동작할 수 있게 한다. 그러나 컴포넌트와 애플리케이션 도메인 사이의 훌륭한 팩토링은 단지 소프트웨어 툴키트를 쉽게 사용할 수 있게 만드는 한 부분이다. 애플리케이션 도메인 객체를 위한 기본적인 구현의 유용한 셋트는 또한 중요하다. 애플리케이션 도메인 문제를 개발자의 책임으로 넘기는 것 대신에 Lucene는 가장 일반적인 애플리케이션 도메인 문제를 해결하기 위한 도구의 세트를 제공한다. 이것은 기본적인 기능을 구현하기 위해 아키텍쳐에 대해 많이 알지 못해도, 추가적인 노력으로 더 향상된 기능을 사용할 수 있는 균형잡힌 노력의 설계 법칙을 지원한다. 결과적으로 개발자는 종종 Lucene의 검색 기능을 적은 시간 동안에 프로젝트에 통합할 수 있다.
Lucene의 설계에서 중요한 점을 배울 수 있다. 많은 프로그램는 추상화의 좋은 사용을 만들지만 대부분이 새로운 사용자가 쉽고 빠르게 추상화를 만든는 것은 아니다. 사용자에게 모든 부분을 제공하고 빨리 실행할 수 있는 프로그램은 거의 없다. 소프트웨어 도구는 소프트웨어 도구에서 잇점을 어기 전에 프로그램에 대한 완벽한 이해가 요구된다. 이것이 미래의 사용자가 소프트웨어 도구를 피하는 이유이다. 소프트웨어를 만들때 사용자를 위협하기 보다 초대하게 만드는 것은 어떤가?
결론
Lucene는 저자가 사용해본 가장 유연하고 편리한 오프 소스 검색 툴킷이다. Cutting은 Lucene의 주요 목표를 "파워나 성능의 손실없는 단순함"이라고 설명한다. 이것은 결과로 분명하게 보여진다. Lucene의 설계는 매우 단순하게 보이는데 이것은 검색 툴킷을 설계하는 분명한 방법이라는 것을 알게될 것이다. 자신의 소프트웨어를 위한 이런 분명한 설계가 만들어졌다는 것은 우리 모두에게 행운이다.
저자에 대하여
Brian Goetz는 15년 이상의 경력이 있는 전문 소프트웨어 개발자이다. 그는 캘리포니아의 Los Altos에 있는 소프트웨어 개발 및 자문 회사인 Quiotix 사의 핵심 컨설턴트이다.
참고
| 
인기도 :
