KR100834760B1 - 최적화된 인덱스 검색 방법 및 장치 - Google Patents

Abstract

최적화된 인덱스 검색 방법 및 장치를 제공한다. 최적화된 인덱스 검색 방법은 소정의 인덱스에서 제1 키 값에 대응하는 제1 필드를 검색하는 단계와 소정의 검색 요청이 입력되는 경우 검색된 제1 필드를 기준으로 하여 인덱스에서 검색 요청에 대응하는 레벨의 제2 필드를 검색하는 단계 및 검색된 제2 필드에 대응하는 식별자를 추출하는 단계를 포함한다.

인덱스, 멀티 레벨 클러스터링, B+트리

Description

최적화된 인덱스 검색 방법 및 장치{Structure of index, apparatus and method for optimized index searching}

도 1은 사진 정보를 저장하는 테이블의 스키마에 대한 예시 도면이다.

도 2는 멀티 칼럼 B+트리 인덱스의 구성을 도시한다.

도 3은 멀티 레벨 클러스터링 저장을 위한 멀티 칼럼 B+트리 인덱스들을 도시한다.

도 4는 본 발명의 일 실시예에 따른 최적화된 인덱스 검색 장치의 블록도이다.

도 5는 본 발명의 일 실시예에 따른 최적화된 인덱스 검색 방법의 순서도이다.

도 6은 본 발명의 일 실시예에 따른 인덱스의 리프 노드를 도시한다.

도 7은 본 발명의 일 실시예에 따른 인덱스의 노드 구조이다.

도 8은 본 발명의 일 실시예에 따른 인덱스의 리프 노드에서의 셀의 구조를 도시한다.

도 9는 본 발명의 일 실시예에 따른 노드 프리픽스의 셀 구조의 예를 도시한다.

도 10은 본 발명의 일 실시예에 따른 인덱스 검색을 위한 UI를 도시한다.

<도면의 주요 부분에 관한 부호의 설명>

210: 검색부

220: 추출부

본 발명은 최적화된 인덱스 검색 장치에 관한 것으로서, 더욱 상세하게는 보다 효율적인 인덱스를 통한 검색 방법 제공 및 저장 공간의 활용도를 높이고 다양한 오퍼레이션을 제공하여 인덱스를 이용한 외부 모듈 구현의 효율성을 높이는 최적화된 인덱스 검색 장치에 관한 것이다.

메타데이터 기반 사용자 인터페이스는 디지털 기기들의 컨텐츠 양이 많아지면서 대단히 인기 있는 사용자 인터페이스 방식이 되었다. 대상 컨텐츠의 수가 수천, 수만 개에 이르면 폴더 및 파일 이름만으로 원하는 컨텐츠를 검색하기가 어려운 반면, 메타데이터 기반의 UI는 검색 기준을 바꿔가면서 원하는 컨텐츠를 검색할 수 있고 사용자가 메타데이터 값을 기억하기 쉬운 장점을 가지고 있다.

특히, 메타데이터 기반의 브라우징 중에서도 멀티 레벨 클러스터링 기반 UI는 사용자가 보다 편리하게 컨텐츠들의 분포 상황을 파악할 수 있으며, 다양한 검색 기준을 적용하여 원하는 컨텐츠에 효과적으로 접근할 수 있도록 한다. 또한, 멀티 레벨 클러스터링 기반 UI는 컨텐츠들을 레벨별로 클러스터화해서 제시하며, 클러스터 간 이동을 하기 위해서 인덱스를 사용한다.

상기 멀티 레벨 클러스터링이란, N(N>=1)번째 기준에 의해서 나뉜 각 클러스터가 다시 N+1 번째 기준에 의해서 더 세부적인 클러스터들로 쪼개질 수 있는 것을 의미한다. 그리고, 상기 클러스터링이란 유사한 부류의 개체들을 그룹화하는 것을 의미한다. 그러므로, 컨텐츠 브라우저가 클러스터링 기반 UI를 채택하였다는 것은 전체 컨텐츠가 소정 기준에 의해서 복수 개의 클러스터로 구분되어 사용자에게 제시된다는 것을 의미한다. 또한 사용자가 클러스터 내부를 브라우징하거나 클러스터를 건너뛰면서 브라우징할 수 있다는 것을 의미한다.

도 1은 사진 정보를 저장하는 테이블의 스키마에 대한 예시 도면이다.

도 1에 도시된 바와 같이, 테이블의 각 레코드에 대해서 년, 월, 일에 대한 정보를 포함하는 필드(12)가 존재한다. 테이블을 통해 관리되는 사진들은 멀티 레벨 클러스터링 UI를 통해 년, 월, 일 필드(12)들을 기준으로 3개의 레벨별로 클러스터화되어 화면에 보여지며, 최하위 레벨인 ‘일’ 기준의 클러스터는 제목 순으로 정렬되어 출력된다. 이와 같이 멀티 레벨 클러스터링 UI를 구현하려면 클러스터에 속하는 사진 레코드들을 데이터베이스로부터 추출할 수 있어야 한다.

예를 들어, 최하위 클러스터들 중 하나인 2006년(1레벨) 5월(2레벨) 1일(3레벨)에 속하는 사진들을 브라우징하는 경우, 이하의 질의를 통해서 화면에 출력할 레코드들을 추출할 수 있다.

‘Select * from Table where 년=2006 and 월=5 and 일=1 order by 제목’

상기 질의와 같이 여러 필드에 대해서 소정 조건이 있는 경우, 적절한 인덱스 없이 질의를 처리하게 되면 사진 레코드의 개수가 증가함에 따라서 질의 처리시 간이 길어지게 된다. 그러므로, 상기 질의와 같이 ‘Equal(=)’ 조건들로 구성되고, 최하위 필드에 대해서 소팅(sorting) 조건이 있는 경우, 해당 필드들을 조합하여 인덱스의 키로 하는 멀티 칼럼 B+트리 인덱스를 사용하는 것이 바람직하다.

도 2는 멀티 칼럼 B+트리 인덱스의 구성을 도시한다.

도 2에 도시된 바와 같이 년, 월, 일, 제목을 조합하여 인덱스 키로 하는 멀티 칼럼 B+트리 인덱스(20)를 사용하게 되면, 년, 월, 일이 특정한 값으로 결정되었을 때 소정 조건을 만족하는 인덱스의 엔트리들이 제목 순서대로 이미 정렬되어 인접해 있기 때문에 별도의 정렬 비용이 들지 않는다. 그리고, 상기 정렬 비용의 제거는 질의 응답시간을 크게 개선한다. 또한, 최하위인 3레벨(일단위) 클러스터가 아닌 2레벨(월단위) 또는 1레벨(년단위)로 클러스터들을 브라우징할 경우, 멀티 칼럼 B+트리 인덱스를 사용할 수 있다.

그러나, 후술될 도 3에 도시된 바와 같이 추가적인 인덱스들이 필요하다. 그 이유는 상기 멀티 칼럼 B+트리 인덱스(20)만으로는 상위 레벨들이 각각 보여주어야 할 클러스터 이름들을 구하는 시간이 오래 걸리기 때문이다. 만약, 상기 멀티 칼럼 B+트리 인덱스(20)만으로 첫번째 레벨에서 보여주어야 할 클러스터들의 이름을 얻기 위해서는 인덱스의 엔트리 모두를 읽어야 하며, 이와 같은 방식의 질의처리는 인터랙티브(interactive)한 화면구성에 필요한 응답시간을 만족시킬 수 없다.

도 3은 멀티 레벨 클러스터링 저장을 위한 멀티 칼럼 B+트리 인덱스들을 도시한다.

상술한 바와 같이 상기 응답시간을 줄이기 위해서는, 첫번째 레벨(‘년’)에 해당하는 필드에 어떤 값들이 존재하는 지 빠른 시간내에 검색할 수 있도록 추가적인 인덱스가 필요하다(30). 첫번째 레벨을 구성하는 클러스터들을 화면에 출력하고 싶을 때는 첫번째 레벨의 클러스터 이름들을 인덱스로 사용한다. 만일, 소정 클러스터(예를 들어 2005년에 해당하는 클러스터)에 속하는 레코드들을 화면에 출력 싶은 경우, 멀티 칼럼 B+트리 인덱스에서 2005년도(‘년=2005’)인 레코드들을 순차적으로 읽어들인다.

또한, 두번째 레벨에서 클러스터들을 브라우징할 때 응답시간을 줄이기 위해서는 ‘년, 월’의 멀티 칼럼 B+트리 인덱스가 필요하고, 세번째 레벨에서 클러스터들을 브라우징하기 위해서는 ‘년, 월, 일’의 멀티 칼럼 B+트리 인덱스가 필요하다(40, 50). 따라서, 전체 레벨을 구성하는 필드의 수가 N라면 필요한 멀티 칼럼 B+트리 인덱스의 총 수는 N개이다. 그리고, 그에 따라서 첫번째 레벨의 키 값은 N개의 인덱스에 중복해서 저장되며, 두번째 레벨의 키 값은 N-1개의 인덱스에 저장되는 등 저장 공간의 낭비 요인이 된다.

본 발명은 최적화된 인덱스 검색 방법 및 장치를 제공하여, 보다 효율적인 인덱스를 통한 검색 방법 제공 및 저장 공간의 활용도를 높이고 다양한 오퍼레이션을 제공하여 인덱스를 이용한 외부 모듈 구현의 효율성을 높이는데 그 목적이 있다.

본 발명의 목적들은 이상에서 언급한 목적들로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해되어질 수 있 을 것이다.

상기 목적을 달성하기 위하여, 본 발명의 실시예에 따른 최적화된 인덱스 검색 방법은 소정의 인덱스에서 제1 키 값에 대응하는 제1 필드를 검색하는 단계와 소정의 검색 요청이 입력되는 경우 검색된 제1 필드를 기준으로 하여 인덱스에서 검색 요청에 대응하는 레벨의 제2 필드를 검색하는 단계 및 검색된 제2 필드에 대응하는 식별자를 추출하는 단계를 포함한다.

본 발명의 실시예에 따른 최적화된 인덱스 검색 장치는 소정의 인덱스에서 제1 키 값에 대응하는 제1 필드를 검색하는 단계와 소정의 검색 요청이 입력되는 경우 검색된 제1 필드를 기준으로 하여 인덱스에서 검색 요청에 대응하는 레벨의 제2 필드를 검색하는 검색부 및 검색된 제2 필드에 대응하는 식별자를 추출하는 추출부를 포함한다.

기타 실시예들의 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명하기로 한다.

도 4는 본 발명의 일 실시예에 따른 최적화된 인덱스 검색 장치의 블록도이다.

최적화된 인덱스 검색 장치(200)는 저장부(205), 관리부(207), 검색부(210), UI 제공부(215), 추출부(220), 컨텐츠 제공부(230)을 포함한다.

저장부(205)는 인덱스에 키 값 및 식별자 등을 저장한다. 이때, 필드 단위로 키 값을 저장할 수 있으며, 식별자는 RID(Record ID)일 수 있다. 그리고, 인덱스의 필드는 선행 키 값 및 후행 키 값이 저장된 노드를 가리키는 포인터 중 적어도 하나를 저장한다. 이때, 상기 선행 키 값 또는 상기 후행 키 값이 동일한 노드에 존재하면 상기 포인터의 저장이 생략될 수 있다. 본 발명에서 제안하는 인덱스 구조는 이하 도 6 내지 도 9에서 설명하기로 한다.

관리부(207)는 상기 저장부(205)에 저장된 값들을 관리한다. 예를 들어 관리부(207)는 저장된 값들에 대해서 정렬, 추가, 삭제, 업데이트 등을 수행한다.

검색부(210)는 소정 인덱스에서 소정 키 값에 대응하는 필드를 검색한다. 그리고, 소정의 검색 요청이 입력되는 경우 상기 검색된 필드를 기준으로 하여 상기 인덱스에서 상기 검색 요청에 대응하는 레벨의 필드를 검색한다. 이때, 검색부(210)는 UI 제공부(215)를 포함할 수 있다.

UI 제공부(215)는 사용자에게 UI(User Interface)를 제공하여, 사용자가 제 공된 UI를 통해서 소정의 키 값에 대응되는 필드를 검색할 수 있도록 한다. 즉, UI 제공부(215)를 통해 사용자가 소정의 키 값을 선택하면 그에 대응하는 필드가 검색부(210)를 통해 검색된다. 이에 대한 실시예로써, 도 10을 참조하기 바란다.

추출부(220)는 상기 검색부(210)에서 검색된 필드에 대응하는 식별자를 추출한다. 이때, 식별자는 RID(Record ID)값일 수 있으며, 키 값과 대응되는 RID값이 추출된다.

컨텐츠 제공부는 사용자에게 상기 RID값에 따라 컨텐츠의 메타 데이터 또는 컨텐츠를 제공한다. 최적화된 인덱스 검색 장치(200)내에 포함된 다양한 오퍼레이션들의 예는 이하 도 10을 참조하기 바란다.

도 4에서 도시된 각각의 구성요소는 일종의 '모듈'로 구성될 수 있다. 상기 '모듈'은 소프트웨어 또는 Field Programmable Gate Array(FPGA) 또는 주문형 반도체(Application Specific Integrated Circuit, ASIC)과 같은 하드웨어 구성요소를 의미하며, 모듈은 어떤 역할들을 수행한다. 그렇지만 모듈은 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. 모듈은 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 실행시키도록 구성될 수도 있다. 따라서, 일 예로서 모듈은 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 모듈들에서 제공되는 기능은 더 작은 수의 구성요소들 및 모듈들로 결합되거나 추가적인 구성요소들과 모듈들로 더 분리될 수 있다.

도 5는 본 발명의 일 실시예에 따른 최적화된 인덱스 검색 방법의 순서도이다.

먼저, 검색부(210)는 소정 인덱스에서 소정 키 값에 대응하는 필드를 검색한다(S501). 이때, 종래 기술과 달리 멀티 칼럼으로 인덱스를 구성한 경우 검색할 키(값)의 레벨을 지정할 수 있다. 즉, 사용자에게 소정의 UI가 제공될 경우, UI를 통해 검색할 키 값의 레벨을 지정할 수 있으며, 상기 키 값에 대응되는 필드가 검색부(210)를 통해 검색되게 된다. 상기 레벨을 지정한다는 것은 바람직하게는 UI를 통해 검색하고자 하는 필드로 이동하여 검색 요청을 입력한다는 의미이다. 이때, 검색부(210)는 소정의 검색 요청이 UI를 통해 입력되는 경우 상기 검색된 필드를 기준으로 하여 상기 인덱스에서 상기 검색 요청에 대응하는 레벨의 필드를 검색한다. 보다 구체적인 예는 이하 도 10을 참조하기 바란다.

다음 단계에서, 추출부(220)는 검색된 필드에 대응하는 식별자를 추출한다 (S511).

따라서 컨텐츠 제고부(230)는 사용자에게 상기 식별자(RID)에 따라 컨텐츠의 메타 데이터 또는 컨텐츠를 제공하게 된다(S521).

도 6은 본 발명의 일 실시예에 따른 인덱스의 리프 노드를 도시한다.

도 6에 도시된 바와 같이, 인덱스의 리프 노드에서 첫번째 레벨의 필드는 숫자 값을 갖고, 두번째 레벨의 필드는 영문자, 세번째 레벨의 필드는 한글로 키가 구성되는 것을 가정한다. 이때, 키와 RID(Record ID)로 구성되는 엔트리는 셀(Cell)(600) 구조로 저장될 수 있다.

종래에는 키 전체를 바이너리 스트링으로 인식하고 프리픽스(prefix)를 구분해 내는 반면, 본 실시예에서의 인덱스는 필드별로 키를 구분할 수 있다. 예를 들어, ‘2005, 10’ 과 ‘2005, 12’ 에서 종래의 프리픽스는 ‘2005, 1*’ 이 되지만 본 실시예에서는 ‘2005’ 가 된다. 따라서, 도 6에 도시된 바와 같이 각 셀(cell)의 ‘1, a, 가’(602)와 ‘b, 가’(604)에서 본래는 ‘1, a, 가’와 ‘1, b, 가’이지만 첫번째 레벨의 필드값이 동일하므로, 이를 생략하고 저장되었음을 알 수 있다.

먼저, #100번(노드의 페이지 번호) 노드에 저장된 ‘3, a, 나’(606)에서 첫번째 레벨의 키인 ‘3’은 선행 키가 동일한 노드(#100번)에 저장된 ‘2’이고 후행 키가 #300번 노드에 저장된 ‘4’이다. 따라서 첫번째 레벨의 키인 ‘3’은 선행 키가 저장된 노드인 자신이 속한 노드(#100번)를 가리키고, 후행 키가 저장된 노드로서 #300번 노드를 가리키고 있다.

이와 같이 인덱스의 각 필드들은 선행 키 및 후행 키가 저장된 노드를 가리키는 포인터를 가지고 있어, 빠르게 선후행 키를 검색할 수 있다.

또한, #200번 노드에서 ‘3, a, 라’를 저장할 때에는 ‘3, a’(608)를 ‘라’(610)와 분리하여 저장한다. 즉, ‘3, a, 다’(607)에서 ‘3, a, 라’와 서로 다른 키를 갖는 키 필드는 세번째 레벨의 필드이므로 ‘라’(610)만 저장하는 것이고, ‘3, a’(608)는 노드 프리픽스로서 따로 저장한다. 노드 프리픽스를 저장해 두는 이유는 리프 노드들을 따라서 키를 검색할 때, 다른 노드를 참조하지 않고도 상위 레벨의 키 값을 알 수 있도록 하기 위함이다.

예를 들어, #300번 노드의 ‘4, a, 나’(612) 위치에서 세번째 레벨의 키인 ‘나’의 선행 키를 찾을 때, 다른 노드를 참조하지 않고도 선행 키 값이 ‘3, d, 라’(614) 임을 알 수 있다. 이하 도 6에서 구체적인 인덱스의 노드 구조에 대해서 설명하기로 한다.

도 7은 본 발명의 일 실시예에 따른 인덱스의 노드 구조를 도시한다.

본 발명에서 제안하는 인덱스 구조의 특성은 B+-트리일 수 있다. 1970년대에 소개된 B-트리는 B+-트리, B*-트리, 프리픽스 B-트리 등 몇 가지 변형된 B-트리 버전이 존재하는데, 본 발명에서 제안하는 인덱스는 멀티 레벨 클러스터링 키들도 효과적으로 저장할 수 있는 변형된 B+-트리 형태라고 할 수 있다. 또한, 본 발명에서 제안하는 인덱스는 B+-트리와 같이 밸런스트(Balanced) 트리일 수 있다. 따라서 어떤 키를 검색하던지 리프 노드에서 해당 키를 검색할 수 있기 때문에 루트 노드로부터 임의의 키를 탐색하는 시간은 동일할 수 있다.

한편, 키와 RID(Record ID)로 구성되는 엔트리는 셀(Cell) 구조로 저장될 수 있다. 그리고, 전체 키의 길이가 가변적이기 때문에 가변 길이 키를 저장하기 위해서 셀의 저장 방식을 실제 데이터를 저장하는 영역(704)과 데이터의 오프셋(offset)을 저장하는 영역(702)(각 데이터의 길이를 저장하는 영역)으로 구분하고 가변적으로 저장 공간을 활용할 수 있다. 즉, 오프셋을 저장하는 영역(702)은 앞에서 뒤로, 데이터가 저장되는 영역(704)은 뒤에서 앞으로 데이터를 유동적으로 저장함으로써 저장 공간의 활용도를 높일 수 있다.

만약, 상기 두 영역(702, 704)의 크기를 일정 크기로 고정시키면, 실제 데이터의 길이가 길면 데이터가 저장되는 영역(704)은 금방 풀(full)이 될 수 있고, 실제 데이터의 길이가 상대적으로 매우 짧으면 오프셋을 저장하는 영역(702)은 풀(full)이 된 상태이지만, 데이터가 저장되는 영역(704)은 아직 비어 있을 수 있어 저장 공간을 효율적으로 이용할 수 없다.

그리고, 상기 노드 프리픽스를 저장하는 경우를 위해 노드 프리픽스의 오프셋을 저장하는 영역(706)이 필요하다. 만일 노드 프리픽스가 필요 없는 노드인 경우에는 노드 프리픽스 오프셋 영역(706)이 0(zero)값으로 초기화될 수 있다.

또한, 각 필드들은 선행 키가 저장된 노드와 후행 키가 저장된 노드를 가리키는 포인터를 저장할 수 있다. 이때, 바람직하게는 포인터 하나당 4바이트를 사용할 경우 모든 키들에 대해서 포인터를 항상 두 개씩 유지하게 되면 그만큼 실제 데이터를 저장할 수 있는 공간이 줄어들 수 있다.

따라서, 상기 인덱스의 각 필드들은 현재 검색된 키를 기준으로 선행 키 또는 후행 키가 현재 노드와 동일한 노드에 있으면 선행 키 또는 후행 키가 저장된 노드를 가리키는 포인터의 저장을 생략함으로써, 실제 데이터를 저장할 수 있는 공간을 보다 더 확보할 수 있다.

이를 위해, i 번째 레벨의 선행/후행 키가 현재 노드 내에 존재하면, i+1번째 레벨의 선행/후행 키도 현재 노드 내에 존재하고, i 번째 레벨의 선행/후행 키가 다른 노드에 존재하면, i-1 번째 레벨의 선행/후행 키도 다른 노드에 존재하는 원리를 이용할 수 있다. 이때, 1번째 레벨이 최상위 레벨이라 가정한다.

이와 같이, 상위 레벨에 대한 하위 레벨의 종속성을 이용하여 현재 검색된 키를 기준으로 선행 키 또는 후행 키가 저장된 노드를 가리키는 포인터의 저장을 생략할 수 있다. 그리고, 상위 레벨의 키 및 하위 레벨의 키가 하나의 엔트리 내에 저장되므로 검색할 레벨을 조절할 때 추가적인 노드의 접근이 발생하지 않는다.

상기 상위 레벨과 하위 레벨간의 종속성에 대해서 구체적으로 예를 들면, 제1 노드 즉, [(2000년, 8월, 16일)　(20일) (9월, 1일) (2일) (4일)]과 제2노드 즉, [(2001년, 1월, 4일), ...]에서 2000년 9월 1일이 현재 검색된 키 값일 때, 월단위 레벨의 선행 키 (2000년 8월)가 현재 노드에 존재하기 때문에, 그보다 더 세분화된 클러스터링 레벨인 일단위의 선행 키가 현재 노드에 존재한다. 즉, 월단위 값이 변경되었다는 것은 일단위의 클러스터링에서도 값이 변경되었다는 것을 의미한다. 마찬가지로 2000년 8월 16일이 현재 검색된 키 값일 때, 월단위 레벨의 후행 키가 현재 노드에 있기 때문에, 일단위의 후행 키도 현재 노드에 있다는 것이 보장된다.

이하, 도 8 및 도 9에서 인덱스의 셀 구조에 대해서 설명하기로 하며, 이때 각 필드에 입력되는 값의 단위는 비트(bit) 또는 바이트(byte) 단위일 수 있다. 단위는 도면에 도시되어 있으며 이하의 설명에서는 단위를 생략한 채 소정 값이라고 표시한다.

도 8은 본 발명의 일 실시예에 따른 인덱스의 리프 노드에서의 셀의 구조를 도시한다.

도 8에 도시된 바와 같이, 카운트 정보 영역(810)에서 필드 카운트(Field Cnt) 필드(801)는 현재 검색된 키가 존재하는 셀이 몇 개의 필드로 구성되어있는지를 나타낸다. 셀의 필드 카운트 필드(801)을 통해 인덱스에서 각 레별의 경계 지점을 찾을 수 있다. 즉, 동일한 노드 내에서는 소정 레벨의 경계 지점을 셀의 필드 카운트 값으로 검색하고, 소정 레벨의 경계 지점이 동일한 노드 내에 없는 경우에는 노드 프리픽스 값을 이용하여 검색하면 경계 지점을 빠르게 검색할 수 있다. 이를 통해, 각 레벨 별로 동일한 키 값을 가진 엔트리들의 처음과 끝을 빠르게 검색할 수 있다.

그리고, 선행 카운트(Prev Cnt) 필드(802)는 후술될 선행 포인터(Prev Ptr)의 개수를 나타내고, 후행 카운트(Next Cnt) 필드(803)는 후술될 후행 포인터(Next Ptr)의 개수를 나타낸다. 패딩(Padding) 필드(804)는 소정의 예약(reserved)된 저장 공간이다.

포인터 영역(820)는 레벨별로 선행 키 또는 후행 키가 존재하는 노드를 가리키는 포인터를 저장한다. 구체적으로 선행 포인터(Prev Ptr) 필드(822)는 i번째 레벨로 브라우징할 때, i번째 레벨을 기준으로 선행 키가 저장된 노드의 포인터를 저장하며, 이때 포인터는 노드의 페이지 번호일 수 있다. 예를 들어, 선행 포인터 1은 첫번째 레벨을 기준으로 선행 키가 저장된 노드를 가리키는 포인터를 저장한다. 그리고, 선행 포인터 2는 두번째 레벨을 기준으로 선행 저장된 노드를 가리키는 포인터를 저장한다. 또한, 선행 포인터 3은 세번째 레벨을 기준으로 선행 키가 저장된 노드를 가리키는 포인터를 저장한다.

후행 포인터(Next Ptr) 필드(824)는 i번째 레벨로 브라우징할 때, i번째 레 벨을 기준으로 후행 키가 저장된 노드를 가리키는 포인터를 저장한다. 예를 들어, 후행 포인터 1은 첫번째 레벨을 기준으로 후행 키가 저장된 노드를 가리키는 포인터를 저장한다. 그리고, 후행 포인터 2는 두번째 레벨을 기준으로 후행 키가 저장된 노드를 가리키는 포인터를 저장한다. 또한, 후행 포인터 3은 세번째 레벨을 기준으로 후행 키가 저장된 노드를 가리키는 포인터를 저장한다.

이어서 키 값을 저장하는 영역(830)에서, 키 사이즈 필드(832)는 키 i의 필드 길이를 나타낸다. 예를 들어 전체 레벨수를 x라고 하면(즉, 년, 월, 일이면 x=3), 키 사이즈는 x-N+i 번째 레벨의 필드 데이터 길이(바이트 단위)를 갖게 된다. 그리고, 키 필드(834)는 소정 레벨의 데이터를 나타내며, x-N+I 번째 레벨의 필드의 데이터를 저장한다.

예를 들어 카운트 정보 영역(810)에서 필드 카운트(Field Cnt) 필드(801)의 값이 2인 경우 키 사이즈는 상기 x-N+i에서 3-2+1로써, 키 사이즈 필드(832)는 2번째 레벨의 필드 데이터 길이 즉, 월 데이터의 길이를 나타낸다. 그리고, 키 필드(834)는 월 데이터 값을 저장한다.

상기 도 6의 데이터를 바탕으로 예를 들어 설명하면, 먼저 상기 도 6에서 첫번째 레벨을 기준으로 모든 키를 순서대로 추출할 때는 ‘1, 2, 3, 4’로 추출될 수 있고, 두번째 레벨을 기준으로 모든 키를 순서대로 추출할 때는 ‘1a, 1b, 2a, 3a, 3b, 3c, 3d, 4a, 5b’로 추출될 수 있다. 그리고, 세번째 레벨을 기준으로 모든 키를 순서대로 추출 할 때는 ‘1a가, 1b가, 2a나, 2a다, 2a라, 3a나, 3a다, 3a라, 3a마, 3b가, 3b나’로 추출될 수 있다. 따라서 3, a, 나(606)(또는 3a나)에서 필드 카운트 필드(801)는 3값, 선행 카운트 필드(802)는 0값, 후행 카운트 필드(803)은 2값을 저장한다. 후행 포인터 1 필드(824)는 첫번째 레벨(즉 3)을 기준으로 후행 키(즉 4)가 #300 노드에 저장되어 있으므로 #300이 저장된다. 선행 포인터 필드(822)는 선행 카운트 필드(802)의 값이 0(zero) 즉, 첫번째 레벨(즉 3), 두번째 레벨(즉 3a), 세번째 레벨(즉 3a나)의 이전값이 모두 현재 노드인 #100에 존재하므로 선행 포인터가 저장되지 않는다. 후행 포인터 2 필드(824)는 두번째 레벨(즉 3a)을 기준으로 후행 키(즉 3b)가 #200노드에 저장되어 있으므로 #200이 저장된다. 후행 포인터 3 필드(824)는 후행 카운트 필드(803)이 2값으로 세번째 레벨(즉 3a나)의 다음 값이 현재 노드인 #100에 존재하므로 저장되는 후행 포인터 값이 존재하지 않는다. 또한, 키 사이즈 필드(832)에서 키 사이즈 1 필드는 4값, 키 사이즈 2 필드는 1값, 키 사이즈 3 필드는 2값이 저장되고, 키 필드(834)에서 키 1 필드는 3값, 키 2 필드는 a값, 키 3 필드는 나값이 저장된다.

한편, 내부 노드에서는 연속적인 키의 검색이 이루어지지 않으므로 서로 다른 노드에 있는 키 사이에 링크를 유지할 필요가 없다. 따라서, 리프 노드의 셀 구조가 가지고 있는 선행 포인터, 및 후행 포인터는 내부 노드의 셀 구조에서는 제거될 수 있다. 내부 노드에서도 프리픽스를 분리한 구조를 가질 수도 있고, 또는 일반적인 멀티 칼럼 B+트리 인덱스처럼 전체 키 값을 항상 유지하도록 할 수도 있다.

상술한 바와 같이, 노드 프리픽스는 이미 이전 노드에 있는 인접 키에서 프리픽스로 사용된 상위 레벨 필드 값이더라도 현재 노드에서 상위 레벨 필드 값을 알기 위해 다시 한번 기록해 줄 수 있다. 노드 프리픽스는 하위 레벨 필드 값과 동 일한 셀에 저장하지 않고, 노드 프리픽스 부분만 별개의 셀로 구성할 수 있다.

도 9는 본 발명의 일 실시예에 따른 노드 프리픽스의 셀 구조의 예를 도시한다.

도 9는 상기 도 6에서 예시된 #200 노드의 노드 프리픽스 ‘3, a’(910)의 셀 구조를 상기 도 8을 참고로 하여 도시한다. 즉 #200 노드의 노드 프리픽스 ‘3, a’(910)의 셀 구조에서, 현재 키가 두개의 필드로 구성되어 있으므로, 필드 카운트 필드(801)에는 2값, 선행/후행 포인터 개수가 없으므로 선행/후행 카운터 필드(802, 803)는 0값이 저장된다. 그리고, 키 사이즈 필드(832)에는 ‘3, a’(910) 각각의 키 값의 사이즈에 대해서 1값과 2값, 그리고 키 필드(834)의 키 값으로 3과 a값이 저장된다. 각 값의 단위는 상기 도 8을 참조하기 바란다.

도 10은 본 발명의 일 실시예에 따른 인덱스 검색을 위한 UI를 도시한다.

도 10에 도시된 바와 같이, 사용자는 UI를 통한 검색 요청을 통해 원하는 컨텐츠를 검색하여 서비스를 제공받을 수 있다. 이때, 본 발명에서 제안하는 인덱스 구조를 이용한 각 오퍼레이션(함수)들(find_key, find_next_entry, find_prev_entry, find_first_key, find_last_key, find_next_key, find_prev_key, find_upper_key, find_down_key)이 이용될 수 있다. 그리고, 가장 우선 순위가 높은 클러스터링 키(또는 키)의 레벨이 1레벨이라고 가정할 때, 년단위를 1레벨, 월단위를 2레벨, 일단위를 3레벨이라 한다. 또한, 도시된 바와 같이 각 필드마다 키 값 및 식별자(RID) 정보를 포함하고 있으며, 사용자의 선택에 따라 필드간 이동이 가능하다.

즉, 사용자가 UI를 통해 필드간 이동할 때 검색 요청이 입력되게 된다. 예를 들어 UI를 통해 2005년 5월(2005, 5로 표기) 필드(1000)로 이동하면 2005, 5 값(2레벨)이 입력되어 해당 키 값과 매칭(대응)되는 식별자가 추출된다. 이때, 상기 추출된 식별자가 복수개일 경우 해당 필드(1000)의 첫번째 값이 반환될 수 있으며, 상기 필드 내의 식별자와 대응되는 컨텐츠 또는 컨텐츠의 메타 데이터가 사용자에게 제공될 수 있다. 이와 같이 UI를 통해 사용자가 검색하고자 하는 키 값의 레벨(2레벨)을 바로 지정할 수 있으며, 지정된 레벨을 기준으로 다양한 오퍼레이션들을 이용하여 필드들을 검색할 수 있게 된다.

이하 오퍼레이션들을 도 10을 참고로 하여 보다 더 구체적으로 설명하기로 한다.

먼저 find_key 오퍼레이션은, 검색하고자 하는 키 값과 매칭되는 엔트리(또는 필드)를 리프 노드에서 찾아 식별자 즉, RID(Record ID)를 반환한다. 만일, 키 값과 매칭되는 RID가 많을 경우에는 첫번째 RID를 반환한다. 이때, 종래 기술과 달리 멀티 칼럼으로 인덱스를 구성한 경우에 검색할 키의 레벨을 지정할 수 있다. 예를 들어 도 10에서, 사용자가 UI를 통해 ‘2005, 5’ 필드(1000)로 이동 하였을 경우, RID는 5711(a)이 반환된다. 즉, ‘2005, 5’ 필드(1000)는 하위 레벨로 5, 6 필드를 포함하고 있으며, 각 필드는 복수개의 RID값을 포함하고 있다. 이때, 첫번째 RID값인 5711(a)이 반환될 수 있다. 그리고, 검색된 필드(1000)내의 식별자에 대응되는 컨텐츠 또는 컨텐츠의 메타 데이터가 사용자에게 제공될 수 있다. 또한, 이후에 동작하는 오퍼레이션들은 ‘2005, 5’ 키 값(또는 필드)을 기준으로 검색을 수행할 수 있다.

다음으로 find_next_entry 오퍼레이션은, 가장 최근에 검색한 엔트리의 다음 엔트리를 검색하여 키와 RID를 반환한다. 만일, 현재 검색 중인 레벨의 키 값이 변경되면, 키를 구성하는 필드 값 중에 변화된 필드들 중 최상위 레벨 번호를 함께 반환한다. 예를 들어, 2번째 레벨을 기준으로 엔트리를 검색하는 중에, 첫번째 및 두번째 레벨의 필드 값이 변경되어 새로운 2레벨 키를 얻게 되면 레벨 번호 1을 반환한다. 예를 들어 도 11에서, ‘2005, 5’를 find_key 오퍼레이션으로 검색한 경우, find_next_entry 오퍼레이션을 수행하면 RID는 5712(b)가 반환된다.

다음으로 find_prev_entry 오퍼레이션은, 가장 최근에 검색한 엔트리의 이전 엔트리를 검색하여 키와 RID를 반환한다. 만일, 현재 검색 중인 레벨의 키 값이 변경되면, 키를 구성하는 필드 값 중에 변화된 필드들 중 최상위 레벨 번호를 함께 반환한다. 예를 들어, 2번째 레벨을 기준으로 엔트리를 검색 중에, 첫번째 및 두번째 레벨의 필드 값이 변경되어 새로운 2레벨 키를 얻게 되면 레벨 번호 1을 반환한다. 예를 들어 도 11에서, ‘2005, 5’를 find_key 오퍼레이션으로 검색한 경우, find_prev_entry 오퍼레이션을 수행하면 새로운 키 값 ‘2005, 4’ 과 RID는 5710(c)이 반환된다. 이때, 2번째 레벨을 기준으로 엔트리 검색 중에 2번째 필드 값이 5에서 4로 바뀌었으므로 레벨 번호 2가 함께 반환된다.

다음으로 find_first_key 오퍼레이션은, 리프 노드 상에서 첫번째 키와 해당 키를 가지는 첫번째 RID를 반환한다. 이때, 종래 기술과 달리 반환받을 키의 레벨 i를 입력해 줄 수 있다. 이후에 동작하는 오퍼레이션들은 i 레벨을 기준으로 키 값 을 검색한다. 예를 들어 도 11에서, 2레벨에 대해 find_first_key 오퍼레이션을 수행하면, ‘1993, 1’ 키를 찾으며 RID는 ‘0001’(d)이 반환된다.

다음으로 find_last_key 오퍼레이션은, 리프 노드 상에서 마지막 키와 해당 키를 가지는 마지막 RID를 반환한다. 만일, 상위 레벨들의 필드 값이 변경되면, 최상위 레벨 번호를 함께 반환한다. 예를 들어, 세번째 레벨을 기준으로 검색 중에, 첫번째 및 두번째 레벨의 필드 값이 변경되면 최상위 레벨 번호 1을 반환한다. 이때, 종래 기술과 달리 반환 받을 키의 레벨 i를 입력해 줄 수 있다. 이후에 동작하는 오퍼레이션들은 i 레벨을 기준으로 키 값을 검색한다. 예를 들어 도 11에서, 두번째 레벨에 대해 find_last_key 오퍼레이션을 수행하면, ‘2006, 12’ 키를 찾으며 RID는 ‘6220’(e) 이 반환된다.

다음으로 find_next_key 오퍼레이션은, 리프 노드에서 가장 최근에 검색한 키 값의 후행 키 값을 검색하여 RID와 함께 반환한다. 만일, 상위 레벨들의 필드 값이 변경되면, 최상위 레벨 번호를 함께 반환한다. 예를 들어, 세번째 레벨을 기준으로 검색 중에, 첫번째 및 두번째 레벨의 필드 값이 변경되면 최상위 레벨 번호 1을 반환한다. 이때, 종래 기술과 달리 최근에 검색한 키의 레벨이 i 번째이면, 해당 레벨 상에서의 후행 키를 반환할 수 있다. 예를 들어 도 11에서, ‘2005, 5’를 find_key 오퍼레이션으로 검색한 경우, find_next_key 오퍼레이션을 수행하면 새로운 키 값 ‘2005, 6’ 과 RID 5720(f)이 반환된다.

또한, find_next_key 오퍼레이션은 현재 검색중인 키의 레벨을 i 라고 할 때, 검색 완료 조건은 필드 카운트(Field Cnt) 값이 (최대 필드 카운트 + 1 - i)와 같거나 큰 것을 찾았거나 더 이상 검색할 노드가 없을 때이다. 그리고, 검색 방향은 후술될 read_key_header 오퍼레이션의 동작을 수행하여 후행 카운트(Next Cnt) 값 등을 얻는다. 후행 카운트(Next Cnt) 값이 i 보다 작은 경우는 후행 키가 현재 노드에 있는 경우이므로, 현재 노드 내의 셀들을 현재 셀 위치에서 뒤로 검색한다. 후행 카운트(Next Cnt) 값이 i와 같거나 큰 경우는 후행 키가 다른 노드에 있는 경우이다. 후행 포인터(Next Ptr_i)가 가리키는 노드에서 첫번째 셀에서부터 뒤로 검색한다.

다음으로 find_prev_key 오퍼레이션은, 리프 노드에서 가장 최근에 검색한 키 값의 선행 키 값을 검색하여 RID와 함께 반환한다. 만일, 상위 레벨들의 필드 값이 변경되면, 최상위 레벨 번호를 함께 반환한다. 예를 들어, 세번째 레벨을 기준으로 검색 중에, 첫번째 및 두번째 레벨의 필드 값이 변경되면 최상위 레벨 번호 1을 반환한다. 이때 종래 기술과 달리, 최근에 검색한 키의 레벨이 i 번째이면, 해당 레벨 상에서의 선행 키를 반환할 수 있다. 예를 들어 도 11에서, ‘2005, 5’를 find_key 오퍼레이션으로 검색한 경우, find_prev_key 오퍼레이션을 수행하면 새로운 키 값 ‘2005, 4’ 과 RID 5706이 반환된다.

또한, find_prev_key 오퍼레이션의 검색 완료 조건은 현재 검색중인 키의 레벨을 i 라고 할 때, 필드 카운트(Field Cnt) 값이 (최대 필드 카운트 + 1 - i )와 같거나 큰 것을 찾았거나 더 이상 검색할 노드가 없을 때이다. 그리고, 검색 방향은 후술될 read_key_header 오퍼레이션의 동작을 수행하여 선행 카운트(Prev Cnt) 값 등을 얻는다. 선행 카운트(Prev Cnt) 값이 i 보다 작은 경우는 선행 키가 현재 노드에 있는 경우이므로, 현재 노드 내의 셀들을 현재 셀 위치에서 앞으로 검색한다. 선행 카운트(Prev Cnt) 값이 i 와 같거나 큰 경우는 선행 키가 다른 노드에 있는 경우이다. 따라서 선행 포인터(Prev Ptr_i )가 가리키는 노드에서 마지막 셀에서 첫번째 셀 방향으로 검색한다.

다음으로 find_upper_key 오퍼레이션은, 현재 검색 중인 키의 레벨이 i 라면 검색 레벨을 i-1로 변경한다. 이후에 수행하는 모든 연산은 i-1 레벨 키를 기준으로 수행된다.

또한, find_upper_key 오퍼레이션은 현재 검색중인 키의 레벨을 i 라고 할 때, 검색 완료 조건은 i가 1이거나 (현재 레벨이 최상위 레벨이므로) 필드 카운트(Field Cnt)가 (최대 필드 카운트 + 1 - i) 보다 큰 경우 (현재 셀에 상위 레벨의 키가 포함되어 있음)이다. 그리고, 검색 방향은 후술될 read_key_header 오퍼레이션의 동작을 수행하여 필드 카운트(Field Cnt) 값 등을 얻는다. 현재 노드 내에서 검색하되 현재 위치에서부터 검색 완료 조건을 만족할 때까지 앞의 셀로 이동하면서 검색한다. 만일, 현재 노드의 첫번째 엔트리에서도 발견이 되지 않은 경우, 노드 프리픽스에서 상위 키를 찾는다.

다음으로 find_down_key 오퍼레이션은, 현재 검색 중인 키의 레벨이 i 라면 i+1 번째 레벨의 키를 반환한다. 이후에 수행하는 모든 연산은 i+1 레벨 키를 기준으로 수행된다.

또한, find_down_key 오퍼레이션은 현재 검색중인 키의 레벨을 i 라고 할 때, i가 최대 필드 카운트와 같으면, 현재 키 레벨이 최하위 레벨이므로 반환할 하위 키 값이 없다. 그렇지 않으면 현재 셀에서 하위 키 값을 검색하여 반환한다.

read_key_header 오퍼레이션은 현재 검색 중인 레벨의 키 값을 포함하는 셀의 헤더 값을 읽는 동작을 한다. find_next_entry 오퍼레이션, find_prev_entry 오퍼레이션 또는 find_upper_key 오퍼레이션등을 수행하였을 경우 최근 검색한 셀이 검색 중인 레벨의 키를 포함하고 있지 않을 수 있다. 즉, 현재 검색 중인 레벨을 i 라고 하고, 현재 검색 커서가 위치한 셀에서의 필드 카운트(Field Cnt) 값이 f 라고 하면, f < (최대 필드 카운트 + 1 - i) 인 경우가 발생한다. 이때, 검색 중인 키의 값은 이미 알고 있는 상태이다. 따라서, 키 값과 검색 레벨 i를 입력으로 하여 find_key 오퍼레이션을 수행하여 해당 키를 포함하는 셀을 찾을 수 있다.

또한, read_key_header 오퍼레이션은 f >= (최대 필드 카운트 + 1 - i) 인 경우는 현재 셀에서 i 번째 키에 해당하는 정보를 읽는다. 만약, f < (최대 필드 카운트 + 1 - i)인 경우는 find_key 오퍼레이션을 수행하여 찾은 셀에서 i 번째 키에 해당하는 정보를 읽는다.

이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.

상기한 바와 같은 본 발명의 최적화된 인덱스 검색 방법 및 장치에 따르면 다음과 같은 효과가 하나 또는 그 이상 있다.

첫째, 본 발명에서 제안하는 인덱스를 통해 저장 공간 활용도를 높고, 다양한 오퍼레이션들을 제공하여 외부 모듈의 구현이 간편하다는 장점이 있다.

둘째, 단일 레벨로 클러스터링된 경우, 기존의 B+트리 인덱스와 동일하게 동작할 수 있도록 설계되어 1~N 레벨로 클러스터링된 데이터에 대해 B+트리 인덱스나 멀티 칼럼 B+트리 인덱스를 대치하여 적용할 수 있는 장점도 있다.

Claims (16)

1. 필드 단위로 키 값을 저장하는 인덱스에서 제1 키 값에 대응하는 제1 필드를 검색하는 단계;

   검색 요청이 입력되는 경우 검색된 상기 제1 필드를 기준으로 하여 상기 인덱스에서 상기 검색 요청에 대응하는 레벨의 제2 필드를 검색하는 단계; 및

   검색된 상기 제2 필드에 대응하는 식별자를 추출하는 단계를 포함하며,

   상기 인덱스 필드는 선행 키 값 및 후행 키 값이 저장된 노드를 가리키는 포인터 중 적어도 하나를 저장하는 최적화된 인덱스 검색 방법.
2. 삭제
3. 삭제
4. 제 1 항에 있어서,

   상기 선행 키 값 또는 상기 후행 키 값이 동일한 노드에 존재하면 상기 포인터의 저장을 생략하는, 최적화된 인덱스 검색 방법.
5. 제 1 항에 있어서,

   상기 인덱스는 다른 노드를 참조하지 않고도 키 값의 상위 레벨의 키 값을 검색할 수 있도록 현재 노드에 상기 상위 레벨의 키 값을 따로 저장하는 최적화된 인덱스 검색 방법.
6. 제 1 항에 있어서,

   추출된 상기 식별자에 따라 컨텐츠의 메타 데이터 또는 컨텐츠를 제공하는 단계를 더 포함하는 최적화된 인덱스 검색 방법.
7. 필드 단위로 키 값을 저장하는 인덱스에서 제1 키 값에 대응하는 제1 필드를 검색하고, 검색 요청이 입력되는 경우 검색된 상기 제1 필드를 기준으로 하여 상기 인덱스에서 상기 검색 요청에 대응하는 레벨의 제2 필드를 검색하는 검색부; 및

   검색된 상기 제2 필드에 대응하는 식별자를 추출하는 추출부를 포함하며,

   상기 인덱스 필드는 선행 키 값 및 후행 키 값이 저장된 노드를 가리키는 포인터 중 적어도 하나를 저장하는 최적화된 인덱스 검색 장치.
8. 삭제
9. 삭제
10. 제 7 항에 있어서,

    상기 선행 키 값 또는 상기 후행 키 값이 동일한 노드에 존재하면 상기 포인터의 저장을 생략하는 최적화된 인덱스 검색 장치.
11. 제 7 항에 있어서,

    상기 인덱스는 다른 노드를 참조하지 않고도 키 값의 상위 레벨의 키 값을 검색할 수 있도록 현재 노드에 상기 상위 레벨의 키 값을 따로 저장하는 최적화된 인덱스 검색 장치.
12. 제 7 항에 있어서,

    추출된 상기 식별자에 따라 컨텐츠의 메타 데이터 또는 컨텐츠를 제공하는 컨텐츠 제공부를 더 포함하는 최적화된 인덱스 검색 장치.
13. 제 7항에 있어서,

    상기 검색 요청을 입력할 수 있도록 복수개의 레벨로 구성된 UI를 제공하는 UI 제공부를 더 포함하는, 최적화된 인덱스 검색 장치.
14. 제 13항에 있어서,

    상기 검색부는 상기 복수개의 레벨 중 사용자가 지정한 레벨의 키 값에 대응 되는 필드를 검색하는, 최적화된 인덱스 검색 장치.
15. 제 14항에 있어서,

    상기 검색부는 상기 지정된 레벨을 기준으로 상위 또는 하위 레벨의 키 값에 대응되는 필드를 검색하는, 최적화된 인덱스 검색 장치.
16. 제 14항에 있어서,

    상기 검색부는 상기 지정된 레벨을 기준으로 선행 또는 후행 키 값에 대응되는 필드를 검색하는, 최적화된 인덱스 검색 장치.

Images