KR20070096094A

KR20070096094A - 검색엔진에서 사용하는 색인어 정보를 검색속도를유지하면서 데이터베이스에 저장하는 저장구조 및 저장기법

Info

Publication number: KR20070096094A
Application number: KR1020050124854A
Authority: KR
Inventors: 최순우; 이병구
Original assignee: 주식회사 온더아이티
Priority date: 2005-12-16
Filing date: 2005-12-16
Publication date: 2007-10-02

Abstract

검색엔진은 다양한 형식과 내용의 문서를 다량으로 색인하여 관리를 하는 시스템으로 관리자의 손이 많이 필요하나 기존 시스템 관리자의 이해부족과 신규 관리자 채용에 따른 비용문제가 나타나고 있는데, 그 원인은 색인어를 저장하는 장소로 검색엔진 나름대로의 파일 시스템을 사용하고 있기 때문이다. 파일 시스템은 이진형식의 데이터로 이루어져 검색엔진에서 제공하는 라이브러리가 없으면 접근할 수 없어 관리자의 이해도가 많이 떨어지고, 트랜잭션(Transaction)이 많은 시스템의 경우 저장소의 안정성 또한 떨어져 다시 색인하는 일이 반복적으로 발생하고 있다.

위의 문제를 해결하고자 관리와 안정성이 뛰어난 DB(Database)를 저장소로 사용하는 것이 고려되었으나 검색속도가 느려지는 문제점을 해결할 방법이 없어 DB가 저장소로 인정받지 못하였다.

본 발명은 검색엔진의 색인어 정보를 저장하는 저장소로 DB를 사용하고도 검색속도를 유지하는 방법을 제공함으로써 별도의 관리자 없이 기존 시스템 관리자가 쉽게 유지보수를 수행할 수 있게 되어 유지비용의 절감과 색인어 정보의 안정적인 저장소 제공으로 자동화된 패키지 검색엔진 제공을 보다 쉽게 할 수 있을 것으로 기대한다.

검색, 색인어, 역파일, 데이터베이스, 테이블, 질의어, 적합성, 검색엔진

Description

검색엔진에서 사용하는 색인어 정보를 검색속도를 유지하면서 데이터베이스에 저장하는 저장구조 및 저장기법 {Techniques on Storage Structure and Storing Method for Indexed Keyword Information using Database from Search Engine with maintaining its Search Speed}

제1도는 본 발명에 데이터베이스(DB)에 색인어를 저장하는 테이블 구조도이다.

제2도는 제1도 중 “역파일 테이블”의 구성필드인 “역파일 필드”의 데이터 구조도로 색인어 정보의 역파일의 단위를 이루는 block구조를 보여준다.

제3도는 제1도 중 “역파일 테이블”에 실제로 등록된 데이터의 예시를 보여준다.

현재 검색엔진 기술은 보편화된 기술로 네이버, 다음, 야후 등 대형 포탈(Portal) 사이트(Site)로부터 군소 작은 사이트에 적용되어 서비스 중이다. 그러나 사이트에 적용된 기술은 사이트에 적합하게 수정된 것으로 이를 다른 사이트에 적용하기 힘들며 검색엔진을 운영하기 위한 별도의 관리자가 필요하다. 또한 지식관 리, 문서관리, 그룹웨어 등 각종 비정형계 솔루션에서 자동화되고 운영이 간편한 검색엔진(패키지)이 필요한 실정이고, 이를 위해 많은 검색엔진이 검토되고 적용되었으나 안정적인 측면과 운영적인 측면에서 많은 문제점을 나타내고 있는 실정이다.

검색엔진은 색인어 정보를 저장하기 위한 구조로 “역파일(Inverted File)” 이라는 기술적 구조를 사용하고 있다. 역파일의 구조상 수정(Update)과 삭제(Delete)가 어려우며 더욱이 파일 시스템에 저장되면 빈번한 수정과 삭제는 저장소의 불안, 최악의 경우에는 깨지는 경우가 종종 발생한다. 또한, 역파일의 구조를 분석하여 데이터베이스화 할 경우 대량의 데이터에 대해 검색속도가 떨어지거나 색인을 구성하는 시간이 아주 오래 걸리는 일이 발생한다. 역파일의 구조를 검색속도와 색인속도를 보장하도록 데이터베이스에 알맞게 적용함으로써 검색엔진의 저장소의 안정을 제공하고자 다음의 아이디어 및 데이터베이스 설계방식을 발명으로 제시한다.

검색 및 색인속도를 유지하는 데이터베이스의 테이블 구조와 테이블 내의 역파일을 유지하는 프로그래밍 기법을 제공하고자 한다.

검색엔진은 사용자가 던진 질의어를 분석하여 검색엔진 나름의 질의형식을 만들어 색인어 저장소에서 맞는 문서를 찾아내며 찾아진 문서를 질의형식과 비교하여 문서와 질의형식의 적합성을 수치로 계산하여 적합성이 높은 문서를 상위로 하여 결과를 전달한다. 여기서 적합성을 계산하는 방식과 검색결과로 내어준 결과가 어떠한 형태인지에 따라 검색속도에 영향을 주게 된다. 적합성은 사용자가 질의한 질의어에 따라 다르게 계산되기 때문에 runtime시 계산이 되어야 하며, 검색결과는 일반적으로 문서의 아이디와 제목, 등록자, 등록일 등 일반적인 게시판의 목록형태를 이루게 되어 결과를 내어주기 위한 정보도 보관되어야 한다. 상기의 검색조건을 고려하여 다음에서는 첨부된 도면을 참조하면서 검색속도를 유지하는 데이터베이스 내의 역파일구조 및 저장방식에 대하여 상세하게 설명한다.

도1은 역파일을 구성하기 위한 데이터베이스 내 테이블 구조도 이다. 도1에 도시된 바와 같이 적합성을 계산하기 위한 “문서통합정보를 테이블”¹; 검색결과를 게시판 형태로 내어주기 위한 “문서정보 테이블”²; 사용자 질의어에 대한 문서를 직접적으로 검색하고 적합성 계산에 알맞은 “역파일 테이블” ³; 총 3개의 테이블로 구성되어있다.

문서통합정보 테이블 ¹ 은 입력된 총 문서의 수와 입력된 문서에 발생된 총 단어의 수(이를 검색엔진에서는 문서의 길이라고도 한다.)가 기록된다. 총 문서의 수와 총 단어의 수는 적합성 계산에 중요한 인자로 반영되며, 이는 runtime시에 계산을 하게 되면 계산속도가 검색속도에 반영되어 속도저하를 가져오고 검색 순간에는 고정 값이기 때문에 문서 색인(입력)시 계산된 값을 업데이트(Update)하여 주게 된다.

문서정보 테이블 ² 은 검색결과를 사용자에게 내어주기 위해 필요한 테이블이다. 즉 목록의 구성형태에 따라 그 구조가 변할 수 있는데, 도식에는 반드시 필요한 필드만을 표현하였다. 문서의 아이디는 “내부적인 아이디”와 “외부적인 아이디”가 존재하는데, 내부적인 아이디는 역파일 구성요소 중 하나이므로 반드시 정수형인 integer가 되어야 하며 외부적인 아이디는 검색결과를 활용하기 위해 문서를 구분하기 위해 필요한 아이디로 Unique하기만 하다면 문자열 형식도 아무런 문제가 없다. “제목”은 일반적으로 목록을 구성하는데 필수요소이며, “연결 URL”은 검색결과 목록에서 원본 문서를 찾아가기 위한 경로명이 된다. “요약(Summary)”는 검색결과에 문서에 대한 요약내용을 보여주기 위해서 필요한 것으로 검색 시 문서요약을 하면 문서요약을 하기 위한 많은 정보가 필요하고 속도저하를 가져와 색인 시 미리 요약하여 넣는 형태를 취하고 있다. “Term"은 문서 내에 존재하는 단어들을 구분자로 연결하여 놓은 것으로 그 길이를 짐작할 수 없기 때문에 text라는 blob형태의 필드로 구성되었다. 이 필드는 해당문서를 삭제할 때 역파일에서도 같이 삭제하기 위해 삭제영역을 구분하는 인자가 되는 단어들을 저장하고 있는 것이다. 이와 같이 문서정보 테이블은 검색 시 결과를 내어주기 위한 테이블일 뿐 검색결과의 질적 성능에는 영향을 주지 않으며 검색결과를 빠르게 내기 위해 제목 등 목록 구성에 필요한 정보를 보관하고 있다. 검색결과 화면에는 많은 검색 결과가 표시될 필요가 없다. 일반적으로 10건 ~ 100건 사이의 문서를 보여주기 때문에 내부 문서 아이디에 index를 설정하여 현 검색결과 화면에 보여줄 문서들(10건 ~ 100건)을 빠르게 가져(Select)올 수 있게 한 것이 특징이다.

역파일 테이블 ³은 사용자가 입력한 질의어를 가지고 구성된 질의형식에 맞는 문서들을 찾는 테이블이다. ID는 레코드(Record)를 구분하기 위한 키 필드이며, Term은 입력한 문서들을 분석하여 나온 단어를 기록하는 필드이다. DF필드는 term이 존재하는 문서의 수를 의미하는 필드로 역파일의 Block의 개수를 의미하기도 한다. contents필드는 해당 레코드를 이루는 term의 역파일이다. 일반적으로 검색엔진에서 사용하는 파일 시스템의 역파일을 그대로 term필드로 옮겨놓은 형태로 그 구조는 도2에서 볼 수 있다. 도2에서 보여진 구조가 term을 가지고 있는 하나의 문서 block이 되고, 레코드(Record)를 이루는 term이 10개의 문서에 속하면 10개의 block을 가지게 된다. 하나의 문서정보를 나타내는 역파일 block의 구성요소를 살펴보면 다음과 같다.

DocID : 문서를 구분하는 아이디로 문서정보 테이블 2 의 내부적인 아이디와 같은 값을 가진다. TF : term이 문서아이디를 가지는 문서에 몇 개나 존재하는지에 대한 빈도수를 의미한다. DL : 문서아이디를 가지는 문서의 총 단어의 수(일반적으로 문서의 길이라 칭한다.)를 의미한다. MaxTF : 문서아이디를 가지는 문서에 존재 하는 단어 중 가장 많이 나온 단어의 빈도수를 의미한다. Flag : 문서아이디를 가지는 문서에 term이 어느 곳에 존재하는 가에 대한 정보이다. 본문에 존재할 수도 있으며, 제목에 존재할 수도 있으며, 첨부문서 등에도 존재할 수 있으며, 모든 곳에 다 존재할 수도 있다. 존재하는 위치에 따라 값이 달라진다. 이와 같은 정보는 주어진 문서가 사용자 질의어에 얼마나 적합한지 값을 결정하는 인자로 사용된다. 조건으로 비교되는 필드들은 설계에 따라 다를 수 있는데, 등록일, 등록자와 같은 조건으로 검색결과를 필터링(Filtering)해야 하는 경우에 사용된다. block의 특징상 고정길이를 사용해야 하면 필드의 개수와 길이가 길수록 검색속도를 느려지게 한다.

상기와 같은 역파일 block은 파일 시스템에서 이진(binary)파일 형태로 기록되는데 데이터베이스(DB)에서 이진(binary)형식의 데이터를 저장할 수 있는 형식은 blob형식이다. blob형식으로 역파일 block을 유지하게 되면 문서를 삭제할 때 DB의 blob에서 해당 block을 찾아 지울 방법이 없어 메모리상에 올려 삭제 후 update해야 한다. blob의 크기가 일정크기를 넘어서면 read와 update에 많은 시간이 소요되며, 지우고자 하는 문서에 많은 단어들이 존재하면 그 시간이 더욱 많은 시간이 소요되어 색인시간이 오래 걸리게 되며 문서의 건수가 10만 이상이 되면 한건의 문서를 지우는데 1시간 이상이 소요되는 문제점이 발생하게 된다. 또한 문서 입력 시에도 신규로 만들어진 역파일 block을 이미 존재하는 term(단어)의 역파일에 추가(append)할 수가 없어 메모리상에서 추가하여 update해야 하는데 이 또한 많은 시 간을 요구한다. 그래서 blob 형식의 필드를 사용할 수가 없다. 본 발명에서는 이것을 해결하고자 문자열 필드인 varchar와 char를 필드를 고려하였다. block의 크기가 이미 고정되어 있으며, 일정크기를 미리 디스크 할당을 받을 경우 색인의 속도가 좋아지는 char필드로 결정하였으며 문서의 삭제와 추가가 빈번히 발생할 경우 char은 디스크의 크기가 이미 할당되어있어 디스크에 저장된 block이 여기저기 조각나지 않아 검색 시에 우월한 성능을 보임을 확인했으며 문서삭제 시 char필드 중간에 있는 block을 SQL문을 바로 삭제할 수 있으며, 신규 문서입력 시 추가되는 block을 SQL문으로 추가(append)할 수 있어 색인속도를 최상의 상태로 유지시킴을 확인하였다.

char필드의 크기는 DB마다 최대 크기가 정해져 있다.(예, 오라클 : 2000byte, SQL : 8000byte) block의 개수가 많아 역파일의 크기가 커지면 하나의 레코드로 구성할 수 없는 문제가 발생하게 된다. 본 발명에서는 이를 해결하고자 레코드를 늘려 이를 해결하였다. 즉, “파일” 이라는 단어는 대부분의 문서에 존재하여 block의 크기가 커지면 “파일”을 term값으로 가지는 레코드를 여러 개 가지게 하였다는 것이다. 한 단어의 레코드 수가 많으면 검색 시 레코드를 읽는(Select)하는 시간이 오래 걸리게 된다. 이를 최소화하기 위해서 같은 데이터를 한 물리적 위치에 놓을 수 있도록 term 필드를 clustered index 설정을 하였다. 본 발명에서는 상기와 같이 역파일 테이블 ³ 을 구성한 결과 100만 건 이상에서도 검색속도 0.5 ~ 1초를 유지함을 확인하였다.

도3은 실제 역파일 테이블에 데이터가 저장된 형태를 보여준다. 역파일 테이블 ³ 의 역파일 block을 보관하는 contents필드를 char로 형태로 문자열을 저장하는 필드이다. 그런데, 역파일 block은 이진데이터(binary data)로 문자열로 변환하여 char에 저장해야 한다. 이진데이타를 그대로 문자열화하면 데이터가 저장은 되나 읽을 시 원형을 복원할 수 없는 문제가 발생한다. 본 발명에서는 이러한 문제를 해결하고자 다음의 방식을 사용하여 문자열로 전환하여 데이터의 복원이나 검색속도에 영향을 주지 않음을 확인하였다.

이진데이터(binary data)는 byte로 이루어져 있으며 byte는 8bit데이터로 4bit씩을 16진수 문자인 Hex Code로 표현할 수 있다. 이진 데이터를 byte로 전환하고 이를 다시 16진수 문자인 hex code로 전환하여 char필드에 저장을 하였으며 검색 시에는 반대의 절차로 복원하였다.

이상과 같이 검색의 속도와 검색질의와 문서 간 적합성을 계산하기 위한 역파일을 데이터베이스에 구성하는 방법을 설명하였다. 이렇게 구성된 저장소를 사용하는 검색엔진은 파일 시스템을 사용하는 검색엔진과 비교하여 검색속도가 떨어지지 않으며, 또한 문서 간의 적합성을 계산하는 정밀도에서도 떨어지지 않는다. 그러면서 저장소의 안정성을 가져와 관리와 유지보수의 비용을 절감시키며 색인어 저장소를 SQL문에 의해 OPEN함에 따라 누구나 쉽게 접근할 수 있어 검색엔진 기술의 대중화를 이끌 것으로 기대한다.

데이터베이스에 색인어 저장소를 생성하여 관리하므로 기존 시스템 관리자가 쉽게 유지보수를 수행할 수 있게 되어 검색엔진을 위한 별도의 관리자를 두지 않아도 된다. 또한 데이터베이스의 관리 기술은 아주 일반화된 기술로 쉽게 관리자를 구할 수 있다는 장점을 가지며 별도의 교육 없이 관리를 할 수 있게 되어 검색엔진의 유지보수 비용 및 초기 구축비용을 감소시킬 것으로 기대한다. 또한, 색인저장 구조 및 저장된 색인어가 관리자에게 OPEN되므로 검색엔진의 작동원리를 전파하게 되어 향후에는 데이터베이스처럼 일반화된 기술로 정착하는데 도움을 줄 것이며, 더 나아가 색인저장구조를 표준 SQL문으로 관리할 수 있어 별도의 프로그램 없이(별도의 기술지원 없이) 온 사이트에서 색인된 결과를 다른 목적(자동요약, 자동분류 등)으로 사용가능해져 사용자에게 좀 더 다양한 서비스를 제공하게 될 것으로 기대한다.

Claims

역파일 정보를 유지하며 색인어 정보를 데이터베이스(DB)에 저장하는 “문서통합정보 테이블”, “문서정보테이블”, “역파일 테이블” 3개의 테이블로 구성된 저장구조

상기한 “문서통합정보 테이블”은 “컬렉션 아이디”, “컬렉션 이름”, “등록된 총 문서의 수”, “등록된 총 문서의 길이(또는 단어 수)”로 구성된다.

상기한 “문서정보테이블”은 “내부문서 아이디”, “외부문서 아이디”, “제목”, “요약”, “연결URL", ”분석된 단어들의 집합 문자열“, ”기타 검색결과를 목록을 이루는 필드들“ 로 구성된다.

상기한 “역파일 테이블”은 “단어 아이디“ ”분석된 단어“, ”문서 내 빈도“, ”역파일“ 로 구성되며, 역파일 필드는 char필드로 데이터베이스(DBMS)에서 지원하는 최대의 길이를 가진다.
1항에 있어서 “역파일 테이블”의 “역파일 필드”에 역파일 블록(이진데이터)을 “프로그램 상에서는 저장하는 방식“

상기한 “프로그램 상에서 저장하는 방식“은 이진데이타를 byte구조체로 전환하고 이를 다시 16진수인 Hex Code로 전환하여 저장하는 방식