내용기반 검색 기술 : FTR)pds.egloos.com/pds/1/200508/01/87/search engine.pdf · 2005-08-01 · Copland 운영 체제 성과의 일부인 V-Twin 검색 엔진의 주요 개발자이고

Search Engine (내용기반 검색 기술 : FTR)

2005년 02월 17일

(Sunny Kwak)

[email protected]

sunnykwak.egloos.com.

mailto:[email protected]

Sunny’s Technical document

2 / 26

Copyrights © 2005 SunnyKwak. All rights reserved.

Other disclaimers The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Version Version 1.0 (draft)

History 2004년 12월 17일 금요일 First created.


3 / 26

Table of Contents

1. INTRODUCTION .........................................................................................................5

1.1 OBJECTIVES ................................................................................................................. 5

1.2 TARGET AUDIENCE .......................................................................................................... 5

2. 검색엔진 기술에 대한 이해 ................................................................................................5

2.1 인터넷 검색엔진 분류와 발달과정 ...................................................................................... 5

2.2 이상적인 검색엔진이 갖추어야할 기능................................................................................. 5

3. JAKARTA LUCENE .......................................................................................................6

3.1 LUCENE 소개................................................................................................................ 6

3.1.1 요약 .................................................................................................................................................... 6

3.1.2 Lucene 소개 기사............................................................................................................................... 6

3.2 LUCENE 용어 및 기술.................................................................................................... 13

3.2.1 기본적인 용어 및 설명 ..................................................................................................................... 13

3.2.2 Lucene 설치 ..................................................................................................................................... 15

3.2.3 주요 클래스 설명 (class description)................................................................................................. 15

3.2.4 검색질의 문법 (search query syntax)................................................................................................. 16

3.3 LUCENE 데모 실습 ....................................................................................................... 19

3.3.1 Lucene 데모 실행............................................................................................................................. 19

3.3.2 Lucen 데모 소스 설명 ...................................................................................................................... 20

3.3.3 요약 .................................................................................................................................................. 23

3.4 LUCENE 기사 및 자료.................................................................................................... 23

4. LUCENE 기반 웹 검색엔진 개발 ......................................................................................24

4.1 웹 로봇.................................................................................................................... 24

4.1.1 검색 대상 웹 싸이트 설정 ................................................................................................................ 24

4.1.2 검색 로봇 구성 ................................................................................................................................. 24

4.1.3 운영 방식.......................................................................................................................................... 24

4.1.4 향후 개선 사항 ................................................................................................................................. 24

4.2 웹 싸이트 검색 (COMMAND LINE) ...................................................................................... 25

4.3 웹 싸이트 검색 (JSP)................................................................................................... 25

5. LUCENE 기반 파일 검색 개발 .........................................................................................25

6. 향후 추진과제 ..............................................................................................................25

7. GLOSSARY ...............................................................................................................25


4 / 26


5 / 26

1. Introduction 1.1 Objectives

UbiFlow 내부 검색엔진을 개발을 위한 문서.

1.2 Target Audience

2. 검색엔진 기술에 대한 이해 2.1 인터넷 검색엔진 분류와 발달과정

인터넷, 특히 WWW의 검색엔진은 그 분류기준에 따라 다양하게 나눌 수 있지만 가장 일반적인 분류법은 검색방법에 따라 주제(Subject) 검색과 주제어(Keyword) 검색, 두 가지로 나누는 것이다. 주제 검색은 해당 검색엔진이 이미 설정해 놓은 주제 분류를 따라 점차 깊이를 더해 가면서 최종 자료에 접근하는 검색 방법이며, 주제어 검색은 검색엔진이 미리 설정해 놓은 주제없이 사용자에 의한 키워드 입력을 통해 최종 자료에 접근해 가는 방법이다. 인터넷 검색엔진의 두 가지 검색법은 인터넷 및 WWW의 발달과정과 깊은 관계를 갖는다. 초기 인터넷 검색엔진은 WWW 규모가 크지 않았기 때문에 많은 자료를 DB화할 필요가 없었다. 따라서 DB규모가 작은 경우 개발과 검색에 편리한 주제 검색 방법을 따랐다. 예를들어 초기메뉴를 비롯한 각 단계 메뉴들이 하위메뉴를 10개를 갖고 있고 전체 메뉴의 깊이는 총 4단계까지 지원된다고 가정 하자. 이를 나무구조 형식으로 그림을 그리면 최종 단계에서는 총 1,000(10^3)개 만큼의 자료를 보유할 수 있다. 한 단계 더 늘어난다면 10,000개까지 자료를 확보할 수 있는 것이다. 그런데 문제는 사용자가 선택해야 하는 메뉴의 개수에 있다. WWW 초기 단계처럼 1만~10만개 이하의 레코드를 보유하고 있는 검색엔진이라면 주제검색이 편리할 것이다. 초기에 야후가 이러한 검색으로 인기를 끌었다. 그러나, 인터넷 검색엔진은 보유 레코드 수가 수십~수백억개에 이른다. 이러한 대규모 데이터배이 스가 주제검색 방식으로 설계되어 있다면 사용자는 과연 몇번의 주제 선택을 통해 최종 자료에 접근할 수 있을까? 만약 100만개의 레코드를 지니고 있다면 이는 10^6이므로 총 여섯 번의 하위 주제를 선택해야 최종 자료에 접근할 수 있다. 그리고 이 여섯 번 가운데 한 번이라도 실수하게 되면 다시 상위주제로 올라가지 않는 한 하위주제에서 찾고자 하는 자료를 찾는 건 불가능하다. 이와 같이 지속적으로 인터넷, 특히 WWW의 규모가 커지면서 더이상 주제검색만으로는 원활한 검색이 불가능해졌다. 이 때부터 검색로봇(Robots, Wanderers, Spiders)라는 개념을 인터넷에 도입하기 시작했다. 검색로봇란 일종의 소프트웨어로 기존에 수작업으로 홈페이지를 찾아 다니며 색인하던 작업을 자동적으로 검색하고, 색인하여 이를 데이터베이스화하는 프로그램을 일컫는다. 이렇게 하여 많게는 하루에 수십만개의 웹 페이지를 검색, 색인할 수 있는 로봇이 개발되기에 이른 것이다. 산업혁명기에 기계가 대량생산을 이끌었듯이 인터넷의 정보혁명기에는 자동 검색 로봇가 대규모 데이터베이스를 만들고 있는 것이다.

2.2 이상적인 검색엔진이 갖추어야할 기능 검색엔진에 따라 그 사용법과 검색범주가 다양하므로 각 검색엔진에 대한 기능 파악이 필요하다. 그러면 사용자가 검색을 시도할 경우 어떠한 기능을 제공하는 검색엔진을 선정해야 할까? 아래와 같이 16가지 항목으로 선정 기준을 정할 수 있다. 일반적으로 가급적 많은 기능을 제공하는 검색엔진을 선정해야겠지만 검색하고자 하는 정보의 성격, 형태 등에 따라 아래 다양한 기준 가운데 몇몇 기능만 제공되더라도 만족한 검색을 할 수 있을 것이다. 1. 쉬운 사용법


6 / 26

2. 빠른 검색속도 3. 간단한 기초 검색 기능과 복잡한 부울린 검색기능을 동시에 지원 4. 인접 연산 5. 사용자 설정에 의한 절단 기능의 제공 6. 구(phrase) 검색 7. 사용자 설정에 의한 대소문자 구분 검색 8. 최적의 검색어 사용을 위한 시소러스 제공 9. 최대한의 검색 결과에 접근 10. 페이지 구성요소(Section) 중 일부가 아닌 전체 Full-text를 통한 검색 11. URL과 Title을 포함하는 출력형태 제공 12. 검색결과의 점수화 및 순위 제공 13. 최종 자료가 인텍싱될 때 출력 14. 이전, 또는 변경되거나 사라진 주소의 제거를 위한 정기적인 갱신 15. DB에 포함되어 있지 않은 주소를 사용자가 등록할 수 있는 기능 16. 각 검색어에 대한 가중치 적용을 통한 검색 이 가운데 대부분의 검색엔진에서 지원하는 검색기능을 제외한 중요한 기능으로는 다음 4가지를 들 수 있다. -. 간단한 기초 검색 기능과 복잡한 부울린 검색 기능을 동시에 지원 -. 인접연산 -. 사용자 설정에 의한 절단 기능의 제공 -. 구(phrase) 검색

3. Jakarta Lucene 3.1 Lucene 소개 3.1.1 요약

Lucene은 Doug Cutting이라는 사람이 오픈 소스 모델로 자바로 구현한 텍스트 검색엔진이었으며, 현재 Lucene는 아파치 자카르타 프로젝트에 포함이 되어 발전하고 있다. Jakarta Lucene은 고성능의 확장 가능한 검색 엔진 기술로서 완전히 자바로 작성되었다. Lucene API는 인덱스 구성에 관한 기능과 검색 기능으로 구성되어 있으며, 텍스트 검색 엔진을 필요로 하는 모든 어플리케이션에 적합한 기술이다. 현재 여러 프로그램에 탑재되어 사용되고 있는데, 예를 들면 Jive Forums에서 게시물 검색에 사용되거나 이메일 클라이언트 애플리케이션에서 이메일 검색에서 사용된다. Lucene에 대한 보다 자세한 정보는 아래 사이트에서 볼 수 있다. http://jakarta.apache.org/lucene/

3.1.2 Lucene 소개 기사 (강력하고 유연하며 무료인 Lucene 검색 엔진을 사용하여 검색 기능을 애플리케이션에 추가하기) 저자 : Brian Goetz 작성 : 2000년 9월 역자 : Barney Kim 원문 : http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-lucene_p.html

http://jakarta.apache.org/lucene/

http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-lucene_p.html


7 / 26

3.1.2.1 들어가며 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도 안되었다. 그리고 저자가 고려했던 어떤 다른 검색 도구보다 완벽하게 통합되었고 기능이 풍부하였다.

3.1.2.2 검색 엔진은 어떻게 동작하는가? 능률적인 키워드 검색 엔진을 개발할 때 정반대인(inverted) 색인을 생성하고 유지하는 것이 주요 문제이다. 문서를 색인하기 위해서는 먼저 포스팅 목록을 생성하기 위해 색인을 조사하여야 한다. 포스팅은 문서에서 단어가 있음을 의미한다. 그래서 포스팅은 일반적으로 단어, 문서 ID와 위치, 또는 문서에서 단어의 빈도를 포함한다. <word, document id> 형식의 한벌로써 포스팅을 생각한다면 문서의 하나의 세트는 문서 ID로 정렬된 포


8 / 26

스팅의 목록이 될 것이다. 그러나 특정한 단어를 가진 문서를 효과적으로 찾기 위해서는 단어로 (또는 여러 단어 검색을 빠르게 하기 위해서 단어와 문서를 함께 사용하여) 포스팅을 정렬하여야 한다. 이러한 관점에서 검색 색인을 만드는 것은 기본적으로 정렬 문제이다. 검색 색인은 단어에 의해 정렬된 포스팅의 목록이다.

혁신적인 구현 대부분의 검색 엔진은 색인을 관리하기 위해 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)에게 문서를 전달할 수 있고 데이터에서 추상화될 수 있는 데이터 소스를 허용한다. 그러나 이런 접근에는 데이터를 위한 올바른 리더가 제공되어야 한다.

ü 색인 관리 일부 검색 엔진은 색인하기 위해 문서를 찾으려고 자동으로 디렉토리 트리나 웹 사이트를 탐


9 / 26

색할 수 있다. 이것이 편리하긴 하지만 만약 데이터가 이미 이 방법으로 저장되었다면 크롤러(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 클래스를 통해 입력 스트림을 전처리하여 특정 언어 필터링을 실행할 수 있다.

위의 목록은 특정 프로젝트를 위한 검색 엔진을 테스트하기 위한 시작 점을 제공한다. 일부 검색 엔진은 이러한 작업에 덜 적합하다. 애플리케이션의 요구사항을 제대로 이해하는 것은 업무에 맞는 올바른 도구를 찾을 수 있게 도움이 될 것이다.


10 / 26

3.1.2.3 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++) {


11 / 26

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 객체와 각각의 문서에 대한 연관(mapping)을 적합 점수로 정렬하여 각각의 문서의 적합 점수를 리턴한다.

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));

};

}

}

내장 질의 파서는 대부분의 질의를 지원한다. 그러나 이 파서가 부족하다면 제공된 풍부한 질의-생성 세트를 다시 구성할 수 있다. 질의 파서는 다음과 같은 질의를 분석할 수 있다:

[ Table 1 ] 루슨 파서

질의 유형 설명


12 / 26

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 클래스를 간단하게 만들 수 있다. 대부분은 사용자는 일반적으로 파일 기반의 구현을 사용할 것이다. 그러나 패키지의 유연성을 높이는 색인 저장소를 처리하기 위한 애플리케이션을 지원한다.

3.1.2.4 사례 연구 Eyebrowse를 개발할 때 우리는 널리 사용되는 많은 오픈 소스 검색 도구를 테스트하였다. 처음에는 Eyebrowse의 검색 기능이 매우 수월해 보였다. 그러나 우리는 목적에 맞는 충분히 유연한 도구가 거의 없다는 것을 알고 놀랐었다. 대부분은 검색 엔진은 우리에게는 필요없는 단지 파일이나 웹 페이지를 색인하기 위해 설계되었다. 왜냐하면 메시지 메타 정보는 SQL 데이터베이스에 저장되어 있고, 많은 개인의 메시지를 가진 메시지 본문과 첨부파일은 메일박스 파일에 저장 되어있다. 메일박스 파일을 색인 목적으로 수많은 작은 파일로 분해하는 어리석고 비능률적으로 보이는 중간 단계가 필요하다. Lucene는 검색 툴킷이지 완전한 검색 프로그램이 아니기 때문에 lucene를 우리의 애플리케이션에 완벽하게 통합하고 동작을 관리하기 매우 쉬웠다. Lucene의 유연한 문서 모델 덕분에 우리는 데이터베이스에서 추출한 메타데이터와 메일박스 파일에서 추출한 메시지 본문을 합친 가상 문서를 생성하고 색인할 수 있었다. 유용한 증가하는(incremental) 색인을 지원하기 때문에 새로운 메시지를 도착했을 때 색인에 추가할 수 있었다. 내장 질의 파서는 우리가 필요한 모든 질의를 지원했고 검색 성능은 완벽했다. 결국, 우리는 우리가 할당했던 시간보다 훨신 적은 시간동안에 요구된 검색 기능을 추가했다. 더 중요


13 / 26

한 것은 우리가 결과의 질에 매우 만족하였다는 것이다.

3.1.2.5 무엇을 배울 수 있나? Lucene는 훌륭한 객체 지향 소프트웨어 설계와 아키텍트의 좋은 예이다. 애플리케이션과 검색 엔진 사이에 조심스럽게 만들어진 분리는 설계의 바로 밑에 놓여있다. 애플리케이션과 검색 엔진 사이의 조심스럽게 만들어진 분업은 검색 엔진의 설계에 놓여있다. 이것은 완전화 과정에서 색인하는 것과 단일의 기능을 수행하는 것과 그리고 단일의 도메인을 운용하는 것은 여러 객체의 집합으로 변경한다. 예를 들면 파일을 색인할 때 FileInputStream 클래스는 문서 데이터를 추출한다. Analyzer는 토큰의 스트림으로 문서 데이터를 변환한다. IndexWriter 클래스는 토큰을 색인한다. FSDirectory 클래스는 색인을 나중에 추출하기 위해 디스크에 저장한다. 이러한 클래스 각각은 하나의 기능을 수행하고, 각각은 다른 것에 영향을 주지 않고 쉽게 교체될 수 있다. Lucene의 팩토링은 애플리케이션이 기능을 보강할 수 있게 한다. 문서를 선택하고 추출하기, 색인 데이터를 저장하기에 대한 기능은 이미 알고 있다. 그리고 검색 엔진을 최상으로 가장 잘 동작할 수 있게 한다. 그러나 컴포넌트와 애플리케이션 도메인 사이의 훌륭한 팩토링은 단지 소프트웨어 툴키트를 쉽게 사용할 수 있게 만드는 한 부분이다. 애플리케이션 도메인 객체를 위한 기본적인 구현의 유용한 셋트는 또한 중요하다. 애플리케이션 도메인 문제를 개발자의 책임으로 넘기는 것 대신에 Lucene는 가장 일반적인 애플리케이션 도메인 문제를 해결하기 위한 도구의 세트를 제공한다. 이것은 기본적인 기능을 구현하기 위해 아키텍쳐에 대해 많이 알지 못해도, 추가적인 노력으로 더 향상된 기능을 사용할 수 있는 균형잡힌 노력의 설계 법칙을 지원한다. 결과적으로 개발자는 종종 Lucene의 검색 기능을 적은 시간 동안에 프로젝트에 통합할 수 있다. Lucene의 설계에서 중요한 점을 배울 수 있다. 많은 프로그램는 추상화의 좋은 사용을 만들지만 대부분이 새로운 사용자가 쉽고 빠르게 추상화를 만든는 것은 아니다. 사용자에게 모든 부분을 제공하고 빨리 실행할 수 있는 프로그램은 거의 없다. 소프트웨어 도구는 소프트웨어 도구에서 잇점을 어기 전에 프로그램에 대한 완벽한 이해가 요구된다. 이것이 미래의 사용자가 소프트웨어 도구를 피하는 이유이다. 소프트웨어를 만들때 사용자를 위협하기 보다 초대하게 만드는 것은 어떤가?

3.1.2.6 결론 Lucene는 저자가 사용해본 가장 유연하고 편리한 오프 소스 검색 툴킷이다. Cutting은 Lucene의 주요 목표를 "파워나 성능의 손실없는 단순함"이라고 설명한다. 이것은 결과로 분명하게 보여진다. Lucene의 설계는 매우 단순하게 보이는데 이것은 검색 툴킷을 설계하는 분명한 방법이라는 것을 알게될 것이다. 자신의 소프트웨어를 위한 이런 분명한 설계가 만들어졌다는 것은 우리 모두에게 행운이다.

ü 저자에 대하여 Brian Goetz는 15년 이상의 경력이 있는 전문 소프트웨어 개발자이다. 그는 캘리포니아의 Los Altos에 있는 소프트웨어 개발 및 자문 회사인 Quiotix 사의 핵심 컨설턴트이다.

ü 참고 Lucene를 다운로드 하거나 Lucene 메일링 리스트를 구독하고, 또는 Lucene 문서를 보기 위해서는 다음 Lucene 웹 사이트를 보라: http://jakarta.apache.org/lucene Eyebrowse에 대한 보다 자세한 정보는 아래를 보라 : http://eyebrowse.tigris.org

3.2 Lucene 용어 및 기술 3.2.1 기본적인 용어 및 설명

[ Table 2 ] 용어 및 설명

용어 설명

http://jakarta.apache.org/lucene

http://eyebrowse.tigris.org


14 / 26

indexing 인덱싱이란 인덱스(index)를 생성하는 처리 과정이다. 인덱스는 컴파일된 문서들

의 버전을 포함하고 있는 특별한 데이터베이스이며, 특정 단어들(term)들을 포함하고 있는 문서 목록을 빠르게 찾을 수 있도록 최적화 되어 있다. 대개 이러한 인

덱스들은 선택된 한 디렉토리에 Lucene이 생성한 일련의 파일들에 저장된다.

analyer Analyzer는 인덱싱 동안 문서의 내용을 어떻게 term(단어들)들로 쪼개야 할지에

대해 제어하는 클래스이다. 예를 들면, 어떤 한 analyzer는 "The ill dogs"라는 텍

스트를 소문자로 바꾸어 "the", "ill, dogs"의 형태로 쪼개는 반면, 다른 한

analyzer는 소문자로 변환하고 복수형태는 단수 형태로 정규화 하며 일반적인 단

어인 "the"는 제거한 형태인 "ill", "dog"라고 쪼갤 수도 있다. 어떤 analyzer를 사용할지 선택하는 것이 중요하다.

searching 원하는 내용을 포함하고 있는 문서의 일부나 몇몇 지정한 사항들과 일치하는 문서의 속성들을 찾는 과정(operation)이다. search 연산은 미리 컴파일된 문서들을

포함하고 있는 특수한 데이터인 '인덱스'에 대해 수행된다. 인덱스 데이터베이스는

"인덱싱" 과정 동안 생성된다.

query 일반적으로 query는 문서를 선택하기 위한 criteria를 지정하며, searching은 문

서 인덱스와 query를 비교하고 query와 일치하는 것들을 찾음으로써 이루어진다.

query의 결과로 해당 criteria와 일치하는 문서들의 목록(hits)을 얻게 된다.

document Lucene에서 사용하는 문서를 나타낸다. 문서를 나타내기 위해 Document라는 클

래스가 제공된다. 이 클래스의 인스턴스는 인덱싱 과정 동안은 인덱스에 추가될 문서들의 정보를 나타내며 검색 동안은 검색의 명중율(hits)을 나타낸다.

field 문서와 hit 정보는 Document 클래스에 필드들의 목록으로 표현된다. 각각의 필드는 이름(String)과 값(문자열이 추출될 수 있는 String이나 Reader)를 포함하고

있다. 또한 각각의 필드는 세 가지 boolean 속성을 갖는데, 이들의 조합은 인덱싱

동안 필드가 사용되는 방법을 지정한다. 이들 속성은 isIndexed, isStored,

isTokenized이다.

hit 이것은 query의 결과이며, 지정된 query와 일치하는 문서들의 목록을 말한다. hit

목록은 일반적으로 ranking이나 scoring라 불리는 몇몇 관련 정도의 단위로 정렬된다. hit 목록에는 질의와 일치하는 문서들(매우 높은 score를 가진 문서들)로 이

루어진 것들 중의 일부분만을 포함할 수도 한다.

terms 일반적으로 terms는 단어(words)라고 생각할 수 있다. 예를 들면, 문자열 "yadda

yadda yadda"는 세 개의 terms를 포함하고 있으며, 이들 각각의 terms는

"yadda"라는 값을 가지고 있다. Lucene이나 대부분의 검색 엔진에서 terms는 인

덱싱과 검색을 위한 기본적인 단위이다. terms 값들은 대소문자를 구별한다. 영어

나 라틴 언어가 아닌 다른 언어의 텍스트를 terms들로 쪼갤 필요가 있는 경우 규칙들을 커스터마이징 할 수 있다.

tokenizing 한 문자열을 terms들로 쪼개는 과정. tokenizing은 Analyzer 객체를 사용해 생성

되는 TokenStream의 인스턴스들에 의해 수행된다. 만약 한 문서의 필드가 인덱

싱 과정 동안 "tokenize하지 않도록" 지정되었다면, 필드의 전체 내용이 단일

term으로 간주된다(URL인 경우 유용).

term

query

Lucene에서의 매우 단순한 질의이며 한 단어와 비교하는 경우에 사용된다.

TermQuery 클래스로 표현되며 term과 필드 이름을 포함하고 있다.

boost

factor

query 구조와 일치하는 문서의 랭킹을 증가시키거나 감소시키는데 사용될 수 있

는 factor.

phrase

query

필드에서 연속된 일련의 terms들에 대해 일치하는지를 비교하는 query를 나타낸

다. 예를 들면, "winding road"는 "winding road"와는 일치해야 하지만 "road

winding"와는 일치하지 않는다. PhraseQuery 클래스 인스턴스로 표현된다. 이 인스턴스는 일치하는 terms들을 표현하는 정렬된 Term 객체들로 이루어진 리스트

를 포함한다.


15 / 26

boolean

query

"AND", "OR", "NOT"과 같은 규칙들을 사용한 복합 질의를 나타낸다.

BooleanQuery 클래스의 인스턴스로 표현된다. 각각의 객체는 BooleanClause라는 어댑터 클래스의 인스턴스를 사용해 연결된 하위 질의들의 목록을 포함하고

있다.

filtering hit 목록에 대해 추가적인 제한을 가해 검색 결과에 영향을 주는 것을 말한다.

3.2.2 Lucene 설치 다운로드 받은 Lucene의 압축을 적절한 디렉토리에 푼 후, lucene-1.4-final.jar를 클래스패스에 추가하면 Lucene의 설치는 끝난다.

3.2.3 주요 클래스 설명 (class description) 인덱싱 관련 클래스

[ Table 3 ] 인덱싱 관련 클래스

용어 설명

IndexWriter 인덱스를 만들고 유지한다. 생성자의 인자들은 위에서 설명한 것과 동일하

다. Document들을 추가하는 작업이 종료된 후에는 반드시 이 객체의 close

메소드를 통해 닫아주어야 한다. 만약 잠시 동안 추가될 Document들이 더 이상 없고 검색 성능을 높이기 위한 최적화를 수행하고자 할 경우, close 메

소드 호출 전에 optimize 메소드를 호출할 수도 있다.

Analyzer 텍스트를 분석하는 TokenStream들을 만들어준다. 즉, 문서를 인덱싱 하거

나 검새갈 때 핵심이 되는 요소로서, 텍스트를 파싱 할 때 사용된다.

StandardAnalyzer 추상 클래스 Analyzer를 구현한 클래스이다. 아스키 코드, 라틴권 문자와

언어 문법을 기반으로 한 analyzer이다. stop word에 대해서는 인덱싱 처리

를 하지 않는다.

WhitespaceAnalyzer 추상 클래스 Analyzer를 구현한 클래스이다. 공백 문자를 기준으로 인덱싱

작업을 한다.

SimpleAnalyzer 공백과 하이픈을 사용해 단어를 구분하여 인덱싱 작업을 한다.

Document Document는 한 문서에 대한 정보를 담고 있다. Document는 인덱싱과 검색

의 단위이며, 필드들로 이루어져 있다. 각각의 필드는 이름과 텍스트 값을

가지고 있다. 대개 Document는 하나 이상의 stored 필드들을 갖는다.

Field 필드는 Document의 일부를 구성한다. 각각의 필드는 이름과 값이라는 두

가지 부분을 갖는다. 값들은 String이나 Reader로 제공되는 형태의 텍스트

나 atomic한 keyword들일 수 있다. 필드들은 선택적으로 인덱스에 저장되어 검색된 문서와 함께 반환될 수 있다. Field에는 Keyword, UnIndexed,

UnStored, Text라는 네 가지 타입이 있다.

Field.Text 텍스트 데이터를 토큰으로 구분하여 인덱싱 작업을 수행하며, 그 값을 인덱

스에 저장한다.

Field.Keyword 텍스트 데이터를 토큰으로 나누지 않는다. 인덱싱 작업을 처리하며 텍스트

데이터 그대로 인덱스에 저장된다.

Field.UnIndexed 텍스트 데이터를 토큰으로 분리하지 않고, 인덱싱 작업도 처리하지 않는다.

텍스트 데이터는 그대로 저장한다.

Field.UnStored 텍스트 데이터를 토큰으로 분리하고 인덱싱 작업도 처리하지만, 텍스트 데

이터는 저장하지 않는다.

.


16 / 26

검색 관련 클래스 [ Table 4 ] 검색 관련 클래스

용어 설명

Searcher 검색 구현을 위한 abstract base 클래스이다. 몇몇 일반적인 유틸리티 메소드들

을 구현하고 있다.

IndexSearcher 단일 IndexReader에 대한 검색을 구현한 클래스이다. 어플리케이션에서는 상속

된 Searcher.search(Query)나 Searcher.search(Query, Filter) 메소드를 호출한

다.

QueryParser 클래스는 JavaCC에 의해 생성된다. 클라이언트에서는 parse() 메소드를 호출하

게 된다. 이 메소드는 질의 문자열을 파싱 하여 Query를 반환한다.

Query 질의를 위한 abstract base 클래스이다.

Hits 순위가 매겨진 Document들의 목록이며, 검색 결과를 저장하고 유지하는데 사용

된다.

3.2.4 검색질의 문법 (search query syntax) 3.2.4.1 Terms

질의는 명사(term)과 연산자(operator)로 나뉜다. term에는 Single terms라는 것과 Phrases라는 두 가지 타입이 term이 존재한다. Single Term은 "test"나 "hello"와 같이 한 단어로 이루어진다. Phrase는 "hello dolly"와 같이 인용 부호로 감싸여진 여러 단어로 이루어진다. 여러 term들은 보다 복잡한 질의를 나타내기 위해 Boolean 연산자와 함께 조합될 수 있다.

3.2.4.2 Fields Lucene은 필드화 된 데이터를 지원한다. 검색을 수행할 때, 필드를 지정하거나 디폴트 필드를 사용할 수 있다. 필드 이름들과 디폴트 필드는 구현에 종속적이다. 필드 이름 다음에 콜론(:)을 적고 찾으려는 term을 적어 넣음으로써 어떠한 필드라도 검색할 수 있다. 예를 들면, Lucene 인덱스가 title과 text라는 두 개의 필드를 포함하고 있다고 가정해보자. 이 때 text는 디폴트 필드라고 가정한다. 만약 "don't go this way"라는 text를 포함하며 "The Right Way"라는 title을 갖는 문서를 검색하고자 한다면, 다음 둘 중 한 방식으로 입력하면 된다. title:"The Right Way" AND text:go 또는 title:"Do it right" AND right text는 디폴트 필드이기 때문에 필드 지시어(indicator)는 반드시 입력될 필요가 없다. 필드는 바로 뒤에 따르는 term에 대해서만 유효하기 때문에, title:Do it right라고 질의를 입력하는 경우, 이는 title 필드에서 "Do"만을 찾게 된다. 나머지 "it"과 "right"는 디폴트 필드에서 찾게 된다.

3.2.4.3 Term modifiers Lucene은 보다 광범위한 검색 옵션을 제공하고 있다.

와일드카드 검색 Lucene은 단일 문자 와일드카드 검색과 다수 문자 와일드카드 검색을 지원하고 있다. 단일 문자 와일드카드 검색에서는 "?" 기호를 사용하며, 다수 문자 와일드카드 검색에서는 "*" 기호를 사용한다. 단일 문자 와일드카드 검색의 예) "text"나 "test"를 검색하려면, te?t의 형태로 검색할 수 있다.


17 / 26

다수 문자 와일드카드 검색의 예) "test", "tests", "tester"를 검색하려 한다면, test* 형태로 검색한다. 와일드카드는 te*t의 형태와 같이 term의 중간에 사용할 수도 있다. 그러나, *나 ? 기호는 검색 첫 글자의 위치에 사용할 수 없다.

Fuzzy 검색 Lucene은 Levenshtein Distance 알고리즘이나 Edit Distance 알고리즘에 기반하여 fuzzy 검색을 지원한다. fuzzy 검색을 수행하려면, Single word Term의 뒤에 틸드 기호인 "~"를 사용한다. 예를 들어, "roam"과 유사한 스펠링을 가진 term을 검색하려는 경우, roam~ 과 같은 형태를 사용한다. 이렇게 검색하게 되면 foam, roams와 같은 term들을 검색하게 된다.

Proximity 검색 Lucene supports finding words are a within a specific distance away. proximity 검색을 수행하려면 Phrase의 뒤에 "~" 기호를 사용한다. 예를 들어, 한 문서 안에서 각각 10 단어 내에서 "apache"와 "jakarta"를 검색하려 한다면 "jakarta apache"~10과 같은 형태로 검색을 수행하면 된다.

Range 검색 Range 질의를 이용하면 필드의 값이 질의에 지정된 범위 내에 있는 값들과 일치하는 문서들을 찾아낼 수 있다. Range 질의에서는 최소값과 최대값을 포함하거나 제외한 검색 결과를 얻을 수 있다. 정렬은 사전 순서로 이루어진다. mod_date:[20020101 TO 20030101] 이것은 20020101과 20030101을 포함하여, 이 범위 안에 있는 값들을 가진 mod_date 필드들을 포함하고 있는 문서를 검색하게 된다. Range 질의는 날짜 필드 검색에만 국한되지 않는다. 다음과 같이 날짜가 아닌 필드들에 대해서도 가능하다. title:{Aida TO Carmen} 이것은 Aida와 Carmen 범위 내에 있는 title을 갖는 문서들을 찾는다. 이 때, Aida와 Carmen은 포함되지 않는다. 최소값과 최대값을 포함한 Range 검색은 [?] 기호를 사용하며, 포함하지 않는 Range 검색은 ?{?}? 기호를 사용한다.

Boosting a Term Lucene은 발견된 term들을 기반으로 문서가 일치하는 정도를 판단하는 기능을 제공한다. term을 boost하려면, 검색하려는 term의 끝에 boost factor (숫자)와 함께 캐럿 기호 "^"를 사용한다. boost factor가 높을수록, term과의 관련성이 더 높아진다. Boosting을 사용하여 문서의 term을 boosting함으로써, 문서의 관련성을 제어할 수 있다. 예를 들어, jakarta apache를 검색하려 하는데, "jakarta"라는 term이 보다 더 중점을 두어 검색하려 한다면, jakarta4 apache와 같은 형태로 term 다음에 기호와 함께 boost factor를 사용하면 된다. 이는 jakarta라는 term을 가진 문서가 보다 더 연관성이 높은 것으로 만들어준다. "jakarta apache"^4 "jakarta lucene"과 같이 Phrase term에 대해서도 boost할 수 있다. default로 boost factor는 1이며, boost factor는 반드시 양수여야 하지만, 0.2와 같이 1보다 작을 수는 있다.

3.2.4.4 Boolean operator Boolean 연산자를 사용하면 논리 연산자를 통해 term들을 조합할 수 있다. Lucene은 AND, "+", OR, NOT, "-"을 Boolean 연산자로 지원한다. Boolean 연산자들은 반드시 대문자여야 한다.


18 / 26

OR OR 연산자는 디폴트 결합 연산자이다. 즉, 두 term 사이에 어떠한 Boolean 연산자도 존재하지 않는다면, OR 연산자가 사용된다. OR 연산자는 두 term들을 연결하여, 이 term들 중 하나라도 문서에 존재하는지에 대해 검색한다. 이는 합집합 연산과 동일하다. OR라는 단어 대신 기호 ||를 사용할 수도 있다. "jakarta apache"나 "jakarta"만을 포함하고 있는 문서들을 검색하려면, "jakarta apache" jakarta나 "jakarta apache" OR jakarta와 같은 형태의 질의를 사용하면 된다.

AND AND 연산자는 두 term을 모두 갖는 문서들을 검색한다. 이는 교집합 연산과 동일하다. AND라는 단어 대신 기호 &&를 사용할 수도 있다. "jakarta apache"와 "jakarta lucene"을 포함하고 있는 문서들을 검색하려면, "jakarta apache" AND "jakarta lucene"과 같은 형태의 질의를 사용하면 된다.

+ "+"가 표시된 요소는 반드시 포함되어 있어야 한다는 것을 의미한다. "jakarta"는 반드시 포함해야 하며 "lucene"은 포함될 수도 있는 문서들을 검색하려면, +jakarta apache와 같은 형태의 질의를 사용하면 된다.

NOT NOT 연산자는 NOT 다음에 나온 term을 포함한 문서들은 배제한다. 이는 차집합 연산과 동일하다. NOT 단어 대신 ! 기호를 사용할 수 있다. "jakarta apache"는 포함하고 있지만 "jakarta lucene"은 포함하지 않는 문서들을 검색하려면, "jakarta apache" NOT "jakarta lucene"과 같은 형태의 질의를 사용하면 된다. NOT 연산자는 한 term에만 사용될 수 없다. 예를 들면, NOT "jakarta apache"와 같이 사용할 수 없으며, 이는 어떠한 결과도 반환하지 않을 것이다.

- "-" 연산자는 "-" 기호 다음에 있는 term을 포함하고 있는 문서들은 제외한다. "jakarta apache"는 포함하지만 "jakarta lucene"은 포함하지 않는 문서들을 검색하려면 "jakarta apache" -"jakarta lucene"과 같은 형태의 질의를 사용하면 된다.

3.2.4.5 Grouping Lucene에서는 서브 질의를 형성하기 위해 괄호를 사용하여 절들을 묶을 수 있다. 이는 boolean 로직을 제어하려는 경우 유용할 수 있다. "jakarta" OR "apache" AND "website"를 검색하려면 (jakarta OR apache) AND website라는 형태의 질의를 사용하면 된다.

3.2.4.6 Field grouping Lucene에서는 여러 절들을 하나의 필드로 묶는데 괄호를 사용할 수 있다. "return"이라는 단어와 "pink panther"이라는 phrase를 모두 포함하고 있는 title을 찾으려면, title:(+return +"pink panther")와 같은 질의를 사용하면 된다.

3.2.4.7 Escape Special Characters Lucene에서는 질의에 특수 문자를 escaping하는 기능을 지원해준다. 이들 특수 문자들은 다음과 같다.


19 / 26

+ - && || ! ( ) { } [ ] ^ " ~ * ? : 이들 특수 문자들을 escape 하려면, 문자 앞에 를 붙인다. 예를 들면, (1+1):2를 검색하려면 (1+1):2와 같은 질의를 사용하면 된다.

3.3 Lucene 데모 실습 3.3.1 Lucene 데모 실행

Lucene 배포본을 다운로드 받으면 그 안에 데모가 들어 있다. Lucene 데모 프로그램을 실행하는 방법에 대해 살펴보도록 하겠다.

3.3.1.1 환경 설정 우선 Lucene의 데모를 실행하기 위해서는 압축이 풀린 디렉토리에 있는 lucene-1.4-final.jar 파일과 lucene-demos-1.4-final.jar 파일이 클래스패스에 잡혀 있어야 한다.

3.3.1.2 인덱스 생성 인덱스를 생성한다. 데모의 인덱스를 구성하는 어플리케이션의 이름은 IndexFiles로서, 이는 org.apache.lucene.demo 패키지에 들어 있다. 다음 명령을 실행하게 되면 Lucene 배포본의 src라는 하위 디렉토리에 있는 Lucene에 대한 모든 소스 코드를 대상으로 인덱스를 구성하게 된다. 첫 번째 인자는 <Lucene 배포본의 압축을 푼 위치>src의 형태를 취한다.

java org.apache.lucene.demo.IndexFiles C:\lucene-1.4-final\src

다음은 명령 프롬프트에서 클래스패스를 잡고 위 명령어를 실행한 결과 화면이다.

위 과정이 성공적으로 이루어졌다면 인덱스 생성은 끝나게 된다.

3.3.1.3 인덱스 검색 데모에서 생성된 인덱스를 검색하는 클래스는 SearchFiles로, org.apache.lucene.demo 패키지에 들어 있다.

java org.apache.lucene.demo.SearchFiles


20 / 26

위 명령을 실행하게 되면 질의를 입력하도록 요청 받을 것이다. 여기에서 찾으려는 단어를 입력하고 엔터키를 누르면 검색된 결과를 보여준다. 결과 화면은 10개 단위로 보여주며, 결과를 보여준 후 다음 10개 항목을 볼 것인지 아닌지를 선택할 수 있다. 다음은 java와 vector에 대한 질의 실행 결과를 나타낸 화면이다.

3.3.2 Lucen 데모 소스 설명 3.3.2.1 소스 코드의 위치

Lucene의 압축을 풀어 생성된 디렉토리에서 "src"라는 디렉토리에 "demo"라는 디렉토리가 있다. 이 디렉토리는 모든 Lucene 데모에 대한 루트 디렉토리이다. 모든 자바 소스는 이 디렉토리 아래의 org/apache/lucene/demo에 위치해 있다.

3.3.2.2 Indexing Files 앞에서 말한 디렉토리에 보면 인덱스를 생성하는데 사용된 IndexFiles.java를 볼 수 있을 것이다. 이것이 어떻게 동작하는지 살펴보도록 하자. 소스 코드에 있는 main 함수는 가장 먼저 IndexWriter의 인스턴스를 생성한다. 이 인스턴스는 "index"라는 문자열과 "StandardAnalyzer"라는 클래스의 새로운 인스턴스를 넘겨 받는다. "index"는 모든 인덱스 정보가 저장될 디렉토리 이름이다. 이 예제에서는 어떠한 경로 정보도 지정하지 않고 있기 때문에, 현재 디렉토리의 하위 디렉토리에 생성하는 것을 가정하고 있다. IndexWriter는 인덱스들을 생성하는 역할을 담당하는 클래스이다. 이를 사용하려면, 이 클래스의 인스턴스를 생성할 때, 인덱스를 작성할 수 있는 경로 정보를 넘겨주어야한다. 이 예제의 경우, 이 경로에 인덱스가 존재하지 않는다면, 이를 생성하게 된다. 만약 해당 경로에 인덱스가 존재한다면, 그 인덱스를 갱신하게 된다. 또한, IndexWriter의 인스턴스를 생성할 때 org.apache.analysis.Analyzer의 인스턴스도 넘겨주어야 한다. 다음 코드는 이러한 작업을 수행한다.

IndexWriter writer

= new IndexWriter("index", new StandardAnalyzer(), true);


21 / 26

이 예제에서 사용한 Analyzer인 Stop Analyzer는 모든 문자열들을 소문자로 만들고 인덱스로부터 쓸모 없는(useless) 단어들을 걸러낸다. 여기에서 쓸모 없는 단어란, a, an, the와 같은 관사들과 검색에 필요없는 일반적인 단어들을 의미한다. 각각의 언어마다 서로 다른 규칙들이 존재하고 있다는 사실에 주의하며, 이들 각각의 언어에 적절한 analyzer를 사용해야 한다. Lucene는 현재 영어와 독일어를 위한 Analyzer들을 지원하고 있다. (한국어, 중국어, 일본어와 같은 아시아권 언어에 대한 analyzer의 경우, Jakarta Lucene의 Sandbox에서 제공되는 analyzer를 사용하면 된다고 한다) IndexFiles 소스 파일의 아래에 보면 indexDocs()라는 메소드가 있다. 이 메소드는 재귀적인 함수로, 지정한 하위 디렉토리를 돌아다니면서 FileDocument를 사용하여 Document 객체들을 생성한다. Document는 파일의 생성 일자, 위치 및 그 내용을 표현해주는 간단한 데이터 객체이다. 이들 Document의 인스턴스들은 IndexWriter에 추가된다. 다음은 indexDocs() 메소드에 대한 소스 코드이다.

public static void indexDocs(IndexWriter writer, File file) throws

IOException {

if (file.canRead()) {

if (file.isDirectory()) {

String[] files = file.list();

if (files != null) {

for (int i = 0; i < files.length; i++) {

indexDocs(writer, new File(file, files[i]));

}

}

} else {

System.out.println("adding " + file);

try {

writer.addDocument(FileDocument.Document(file));

} catch (FileNotFoundException fnfe) {

}

}

}

}

indexDocs()는 인자로 받은 File을 읽을 수 있는지 판별하고, 이것이 디렉토리인지 파일인지 검사한다. 만약 디렉토리라면 그 하위 디렉토리를 재귀적으로 검사해 나가며, 파일인 경우 IndexWriter의 addDocument() 메소드를 통해 인덱스에 Document를 추가한다. 이 때, addDocument() 메소드는 인자로 Document를 받는데, 이 예제에서는 FileDocument라는 유틸리티 클래스를 사용하고 있다. 이 유틸리티 클래스는 File로부터 Lucene Document 객체를 만들어준다. FileDocument는 File 객체에 들어 있는 정보를 바탕으로 Document 객체를 만들어준다. Document 객체는 세 개의 필드로 File에 대한 정보를 표현한다. 이들 필드들은 다음과 같다.

ü path 파일에 대한 경로명. 텍스트 값 저장(Stored), 토큰 처리(Tokenized) 필드이다.

ü modified 파일의 최종 수정일. org.apache.jakarta.lucene.DateField에 의해 인코딩 된 Keyword 필드이다.

ü contents 파일의 내용. Reader 필드이다.


22 / 26

3.3.2.3 Searching Files SearchFiles는 검색을 수행한다. 이 클래스는 IndexSearcher, StandardAnalyzer, QueryParser와 상호 작용한다. 이 클래스의 main() 메소드에서는 먼저 검색을 수행하는 Searcher의 객체를 생성하고 질의를 분석하는데 사용될 Analyzer 객체를 생성한다. 다음은 이를 수행하는 코드이다.

Searcher searcher = new IndexSearcher("index");

Analyzer analyzer = new StandardAnalyzer();

query parser는 Index를 해석할 때 사용했던 analyzer와 동일한 analyzer를 사용한다. 다음 코드는 이러한 작업을 수행한다.

Query query = QueryParser.parse(line, "contents", analyzer);

Query 객체는 QueryParser로부터의 결과를 포함하고 있는데, 이 Query 객체는 searcher로 넘겨진다. searcher의 결과들은 "Hits"라 불리는 Document들의 컬렉션에 담겨져 반환된다. Query를 지정하기 위한 syntax는 매우 다양하다. 이들에 대한 내용은 앞장에서 서술하였다.

Hits hits = searcher.search(query);

그런 후, 이들 컬렉션을 순환하면서 그 안의 내용을 사용자에게 보여준다.

for (int start = 0; start < hits.length(); start += HITS_PER_PAGE) {

int end = Math.min(hits.length(), start + HITS_PER_PAGE);

for (int i = start; i < end; i++) {

Document doc = hits.doc(i);

String path = doc.get("path");

if (path != null) {

System.out.println(i + ". " + path);

} else {

String url = doc.get("url");

if (url != null) {

System.out.println(i + ". " + url);

System.out.println(" - " + doc.get("title"));

} else {

System.out.println(

i + ". " + "No path nor URL for this document");

}

}

}

if (hits.length() > end) {

System.out.print("more (y/n) ? ");

line = in.readLine();

if (line.length() == 0 || line.charAt(0) == 'n')

break;


23 / 26

}

}

3.3.3 요약 다음은 일반적으로 Lucene을 standalone 형태의 어플리케이션에서 사용하는 절차를 간단하게 정리한 것이다.

3.3.3.1 인덱스 만들기 인덱스를 만드는 절차는 다음과 같다. IndexWriter 객체를 생성한다. 이 객체를 생성할 때는 인자로 세 개의 정보를 넘겨준다. 우선 첫 번째 인자는 인덱스를 생성할 경로를 설정한다. 두 번째 인자는 사용할 Analyzer의 인스턴스이다. Analyzer는 Lucene에서 다수 구현하여 제공하고 있다. 세 번째 인자는 기존의 인덱스가 존재한다면 갱신할 것인지, 아니면 다시 새로 만들 것인지에 대해 지정한다. 자세한 내용은 Lucene API 문서를 찾아보길 바란다. 인덱싱 작업의 대상이 되는 경로로부터 디렉토리와 파일 정보를 읽어 들여, 디렉토리인 경우는 재귀적인 호출을 통해 하위 디렉토리까지 검색하도록 하며, 파일인 경우는 필요한 정보를 추출한 후, org.apache.lucene.Document 형태로 구성하고, IndexWriter의 addDocument() 메소드를 통해 이를 추가한다.

3.3.3.2 검색하기 Searcher 객체를 생성하며, 인덱스가 생성되어 있는 경로를 인자로 받아 추후 검색을 수행한다. 분석에 사용할 Analyzer를 생성한다. 이 Analyzer는 인덱스를 생성할 때 사용했던 Analyzer의 종류와 같은 것이어야 한다. 만약 다른 것을 사용한다면 잘못된 검색 결과를 얻을 수 있다. QueryParser의 parse() 메소드를 이용하여 Query 객체를 생성한다. parse() 메소드는 검색어, 인덱스 생성 시 작성했던 필드 명과 위에서 생성한 analyzer 객체를 인자로 받아 인덱스 정보를 검색한다. QueryParser를 통해 얻어진 Query 객체로부터, 검색 결과를 담고 있는 Hits를 얻어온 후, Hits가 담고 있는 내용들을 보여준다.

3.4 Lucene 기사 및 자료 [ Table 5 ] 기사 및 자료

제목 URL

Lucene Home http://jakarta.apache.org/lucene/

Lucene FAQ http://lucene.sourceforge.net/cgi-bin/faq/faqmanager.cgi

Lucene Getting Started http://jakarta.apache.org/lucene/docs/gettingstarted.html

QueryParser Rules http://today.java.net/pub/a/today/2003/11/07/QueryParserRules.html

Give your Web site its own search engine using Lucene

http://builder.com.com/5100-6389-5054799.html

Lucene Intro http://today.java.net/pub/a/today/2003/07/30/LuceneIntro.html

Parsing, indexing, and searching XML with Digester and Lucene

http://www-106.ibm.com/developerworks/library/j-lucene/

Advanced Text Indexing with http://www.onjava.com/pub/a/onjava/2003/03/05/lucene.html

http://jakarta.apache.org/lucene/

http://lucene.sourceforge.net/cgi-bin/faq/faqmanager.cgi

http://jakarta.apache.org/lucene/docs/gettingstarted.html

http://today.java.net/pub/a/today/2003/11/07/QueryParserRules.html

http://builder.com.com/5100-6389-5054799.html

http://today.java.net/pub/a/today/2003/07/30/LuceneIntro.html

http://www-106.ibm.com/developerworks/library/j-lucene/

http://www.onjava.com/pub/a/onjava/2003/03/05/lucene.html


24 / 26

Lucene

Introduction to Text Indexing with Apache Jakarta Lucene http://www.onjava.com/pub/a/onjava/2003/01/15/lucene.html

The Lucene search engine Powerful flexible and free http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-lucene.html

4. Lucene 기반 웹 검색엔진 개발 4.1 웹 로봇 4.1.1 검색 대상 웹 싸이트 설정

ubiflow.xml 환경 설정의 업무관련 웹 사이트 (BizRefSite) 중 crawl 속성이 "Y"인 싸이트들을 스캔(scan)한다.

4.1.2 검색 로봇 구성 검색 로봇 프로그램의 구성은 다음과 같다.

ü 검색 로봇 실행 스크립트 : $UBIFLOW_HOME/shell/svc/digger/digger.xml ü 검색 로봇 메인 모듈 : svc.digger.WebSitesDigger ü 검색 로봇 핵심 모듈 : ftr.web.WebCrawler

검색 결과 인덱스(index) 혹은 색인 파일은 기본 볼륨(base volume)의 webIdx 하위 디렉토리에 생성되며, 인덱스 위치는 WebSitesDigger 소스에 정의되어 있다. (검색 로봇을 실행할 때마다, 기존에 생성된 인덱스 파일들은 삭제된다.) 또한, 검색 로봇의 테스트를 위한 프로그램을 제공한다.

ü 검색 로봇 테스트 스크립트 : $UBIFLOW_HOME/shell/tool/ftr/ftrWebCrawl.xml ü 검색 로봇 메인 모듈 : tool.ftr.FtrWebIdx

검색 로봇 테스트 프로그램을 실행하면, 검색 인덱스를 저장할 경로 및 검색 시작 페이지 경로와, 검색 범위를 입력받은 후, 스캔을 시작한다.

4.1.3 운영 방식 웹 싸이트에 대한 인덱스를 재생성할 필요가 있을 때, digger 스크립트를 수동으로 실행해야 한다.

4.1.4 향후 개선 사항 로봇을 실행할 때마다, 이전에 작성된 인덱스를 삭제하는 것은 비효율적이다. 로봇을 수동으로 실행시켜야 하는데, 관리자가 지정한 시각에 실행되도록 스케줄링하는 기법을 검토할 필요가 있다. 싱글 스레드 방식으로 동작하기 때문에 성능이 만족스럽지 못하다. 멀티 스레딩이 가능한지 검토할 필요가 있다. 웹 싸이트에 연결(link)된 파일 중에서 html 및 PDF만 색인할 수 있다. 향후, MS-Office 혹은 HWP 파일을 인덱싱할 수 있어야 한다. 웹 싸이트에 연결된 링크를 얼마나 정확히 추출하는지 검증해볼 필요가 있다.

http://www.onjava.com/pub/a/onjava/2003/01/15/lucene.html

http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-lucene.html


25 / 26

4.2 웹 싸이트 검색 (command line) 웹 로봇에서 의해 생성된 인덱스의 상태 – 정상적으로 생성된 것인지, 검색 결과는 정확한지 –를 점검하고, 다양한 검색 조건을 실행해 보기 위해 웹 싸이트 검색을 명령행에서 실행할 수 있는 도구를 제공한다.

ü 명령행 검색 스크립트 : $UBIFLOW_HOME/shell/tool/ftr/ftrWebSrch.xml ü 명령행 검색 메인 모듈 : tool.ftr. FtrWebSrch ü 검색 실행 핵심 모듈 : ftr.web.WebSearcher

4.3 웹 싸이트 검색 (JSP)

5. Lucene 기반 파일 검색 개발 전자결재, 게시판, 웹폴더 등 첨부 파일을 포함하는 문서들의 파일 내용을 검색하기 위한 목적으로 개발한다. 각 문서 유형(category)별로 인덱스를 저장하기 위한 디렉토리를 지정(혹은 설계)해야 한다.

6. 향후 추진과제 ü 한국어 처리를 위한 형태소 분석기

CJKTokenizer를 개선해야 하며, 한글 조사 처리가 필요하다. ü 불용어 및 유어 사전 구축 ü 웹 로봇 성능의 개선 ü 하이라이팅 기능 및 문서 요약 기능 ü MS Office 문서의 텍스트를 추출할 수 있는 기능

7. Glossary 1. 검색식 (search expression) 데이터베이스를 사용하게 되면 사용자는 적절한 자료를 찾기 위해 검색엔진에 "어떠한 자료를 찾아 달라"는 명령을 내리게 된다. 이 때 내리게 되는 명령은 인간이 사용하는 자연어로 표시해서는 기계가 이를 판독할 수 없다. 따라서 각 데이터베 이스에서 지정한 방법에 따라 적절한 명령을 내리게 되는데 이 때 내리게 되는 명령이 '검색식'이다. 기계는 사용자-기계간 약속 에 의해 사용자가 작성한 검색식에 적절한 자료를 출력한다.

2. 검색어 (keyword) 사용자가 검색하고자 하는, 검색식에 입력하는 단어 각각을 의미한다.

3. 검색 건수 (hits) 검색식을 통해 그 검색 결과를 얻게되면 해당 데이터베이스가 보유하고 있는 전체 레코드 가운데 몇 개가 검색되었는지를 알려준다. 이 때 말하는 '몇건'이 검색 건수이다. 하나의 레코드는 하나의 검색 건수를 말한다.

4. 부울린 연산자 (Boolean operator) 논리연산자로 칭하기도 한다. 일반적으로 데이터베이스 검색을 위해서는 주요 키워드를 상호 연산자로 조합하여 그 결과를 얻게 되는데 이때 사용되는 연산자로 부울린연산자와 인접연산자가 있다. 여기서 부울린연산자로는 'AND, OR, NOT'의 세가지가 있다. 우선 단어 위주로 살펴보면 AND는 연산자 좌우에 입력된 두 단어가 모두 나타나는 레코드를 검색하며, OR는 좌우 두 단어중 어느 하나만 나타나더라도 검색한다. 그리고 NOT연산자는 연산자 우측의 단어는 반드시 제외된 레코드를 검색하라는 연산자이다.

5. 인접연산자 (Proximity operator)


26 / 26

데이터베이스 검색에서 사용되는 연산자는 부울린연산자외 인접연산자가 있으며 이에는 NEAR와 ADJ 두가지가 있다. '인접'이라는 단어가 의미하듯이 연산자 좌우단어가 인접해 있으면 검색한다. 하지만 NEAR는 좌우 단어의 선후에 관계없이 좌우에 입력한 두 단어가 인접해 있는 모든 레코드가 검색된다. 이에 비해 ADJ는 순서를 고려한 인접연산자로 반드시 연산자 좌측에 위치한 단 어가 우측에 위치한 단어보다 먼저 나타나야 한다.

6. 유의어 사전 (thesaurus) 정보검색에 사용되는 키워드와 그 관계어와의 관련을 정리하여 명기한 일종의 사전이다. 대부분의 인터넷 검색엔진에서 해당 DB가 시소러스 사전을 가지고 있다는 것은 통제어 방식의 검색이 이루어짐을 의미하므로 사용자는 키워드의 어미변화니 동일한 어 근을 갖는 다른 품사의 단어를 동시에 여럿 나열하여 검색할 필요가 없다. 하나만 입력해도 관련 단어들이 함께 검색된다.

7. 레코드 (record) 인터넷 검색엔진은 작게는 수천만개, 많게는 수억개 이상의 인터넷 사이트 또는 웹 페이지에 대한 정보를 담고 있다. 그리고 사용자는 이러한 수많은 페이지 가운데 원하는 어느 하나를 키워드 검색을 통해 찾아낸다. 검색엔진을 데이터베이스와 동일한 개념으로 설명하듯이 각 페이지에 대한 정보들을 레코드로 이해한다. 따라서 위 문장은 "인터넷 검색엔진은 작게는 수천만개, 많게는 수억개의 레코드를 보유하고 있다"로 고쳐 말할 수 있다.

8. 필드 (field) 필드검색 : 제한검색 : 웹 홈페이지에 대한 정보를 데이터베이스로 만든다고 하자. 많은 레코드 가운데 USPTO(United States Patent and Trademark Off ice), 즉 미 특허/상표국에서 보유하고 있는 웹 홈페이지를 검색했더니 이 페이지의 Title, Head내용, Link된 주소 등이 기록되 어 있다. USPTO라는 하나의 레코드는 이 모든 내용을 포함하고 있으며 각 내용을 담고 있는 곳을 필드라 말한다. 따라서 Title이 담겨져 있는 곳이 'Title필드', Head내용이 담겨져 있는 곳을 'Head필드', Link된 내용을 지니고 있는 곳을 'Link필드'라 말한다. 데이터베이스에서 필드의 중요성은 '필드(제한)검색'에서 나타난다. 이는 '특정 필드로 제한한 검색'의 약어로 '제한검색', 또는 '필드검색' 두가지 용어를 혼용하여 사용한다. 즉 특정 키워드를 레코드 전체를 통해 검색하는 것이 아니라 Title필드로 제 한하여 검색한다든지, Head필드로 제한하여 검색하는 것을 말한다. 제한검색을 하면 전체 레코드를 대상으로 검색하는 것보다 특 정필드를 제한하므로 더 정밀한 검색이 가능하다. 본서에서 다루는 검색엔진들도 이러한 필드검색이 가능한 것이 많으므로 검색 예를 통해 익힐 수 있을 것이다.

9. 불용어 사전 (stopword dictionary) 색인어의 가치가 없는 낱말을 가지는 사전이다. 이 사전에 포함되는 낱말들은 모호성에 대한 배제를 행한 것이므로 색인어 결정에 장애가 되지 않는다. 한국어를 위하여 접속사 등이 포함되어 있으며 영어를 위하여 관사 등이 포함되어 있다. 구축 방법은 소설 등의 대량의 문서를 이용해 색인 파일을 만들고, eye-check를 통해 작성

10. 끝말 사전 (ending word) 자주 이용되는 조사나 어미 등을 제거하기 위한 사전이다. 한국어가 교착어의 특성으로 인하여 변형이 많으므로 그 원형을 판단하기 위하여 이용된다. 또한 숫자와 결합되어서 불용어를 나타내는 낱말 등도 등록되어 있다. 처리의 효율을 위하여 맞춤법 오류인 것도 포함된다. (뿐만 아니라, 됐습니다, 킬로그램, 이다, 된다, 한다, 하다, 있다, 하였다, 같다, 이며, 하며, 되며, ~는, ~은)

Documents

내용기반 검색 기술 : FTR)pds.egloos.com/pds/1/200508/01/87/search engine.pdf · 2005-08-01 · Copland 운영 체제 성과의 일부인 V-Twin 검색 엔진의 주요 개발자이고