KR101708261B1

KR101708261B1 - 개별 액세스 가능한 데이터 유닛의 스토리지 관리

Info

Publication number: KR101708261B1
Application number: KR1020107025290A
Authority: KR
Inventors: 에프라임 메리웨더 비슈니아크; 크레이그 더블유. 스탠필
Original assignee: 아브 이니티오 테크놀로지 엘엘시
Priority date: 2008-05-14
Filing date: 2009-05-13
Publication date: 2017-02-20
Also published as: CA2723731A1; CN102027457A; EP2281242A1; KR101792168B1; KR20110014987A; AU2009246432B2; HK1202172A1; KR20160136475A; AU2009246432A1; CN104199816A; CN102027457B; KR20150042293A; JP2014197425A; JP2011521360A; CA2723731C; US20090287986A1; US20180011861A1; JP5922716B2; JP5847578B2; EP2281242B1

Abstract

본 발명의 방법은 파일의 길이를 결정하는 단계(702) 및 파일의 길이를 제1 메모리 위치에 저장하는 단계(704)를 포함한다. 파일 내의 마지막 완성 레코드의 종점(endpont)을 결정하고(706), 그 종점을 제2 메모리 위치에 저장한다(708). 제1 메모리 위치에 저장된 파일의 길이를 현재 파일의 길이를 비교하고(710), 현재 파일의 길이가 제1 메모리 위치에 저당된 파일의 길이를 초과하는 경우, 그 파일과 연관된 데이터 구조를 종점에서 시작하여 갱신한다.

Description

개별 액세스 가능한 데이터 유닛의 스토리지 관리 {MANAGING STORAGE OF INDIVIDUALLY ACCESSIBLE DATA UNITS}

본 발명은 개별적으로 액세스 가능한 데이터 유닛의 스토리지 관리에 관한 것이다.

데이터베이스 시스템은 개별 액세스 가능한 데이터의 유닛 또는 "레코드(record)"를 임의의 다양한 포맷으로 저장할 수 있다. 각 레코드는 신용 카드 트랜잭션(transaction)와 같은 로컬 엔티티(local entity)에 대응할 수 있고, 보통레코드를 유일하게 식별하기 위해 사용되는 연관된 기본키(primary key)를 가진다. 레코드는 레코드 포맷의 각각의 필드와 연관된 다수의 값을 포함할 수 있다. 레코드는 하나 이상의 파일 내에 저장될 수 있다(예컨대, 플랫 파일(flat file) 또는 XML 파일과 같은 구조화된 데이터 파일(structured data file)). 압축 데이터베이스 시스템에서, 레코드 내부의 개별 레코드 또는 값은 시스템의 스토리지 요구를 줄이기 위해 저장될 때 압축되고 액세스될 때 압축해제될 수 있다.

일반적으로, 본 발명의 일 측면에서, 방법은 파일의 길이를 결정하고 제1 메모리 위치(memory location)에 파일의 길이를 저장하는 단계를 포함한다. 상기 파일 내의 마지막 완전한 레코드(last complete record)의 종점(endpont)을 결정하고, 상기 종점을 제2 메모리 위치에 저장한다. 상기 제1 메모리 위치에 저장된 파일의 길이를 파일의 현재 길이와 비교하고, 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 파일의 길이를 초과하는 경우, 상기 파일과 연관된 데이터 구조를 상기 종점에서 시작하여 갱신한다.

본 발명의 측면들은 다음의 특징 중 하나 이상을 포함할 수 있다. 상기 데이터 구조는, 해시 테이블(hash table) 또는 이진 트리(binary tree) 등의, 연관 데이터 구조(associative data structure)일 수 있다. 상기 종점은 또한 상기 파일의 종점을 나타낼 수도 있다. 상기 종점은 상기 파일 내의 불완전한 레코드에 선행할 수 있다. 상기 파일은 에러 검사를 받을 수 있다. 파일의 에러 검사는 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 파일의 길이보다 짧은지를 결정하는 단계를 포함한다. 상기 파일은 비압축(uncompressed) 데이터 파일일 수 있다.

일반적으로, 본 발명의 다른 측면에서, 방법은 데이터 스트림으로부터의 데이터를 제1 파일 및 버퍼에 동시에 추가하는 단계를 포함할 수 있다. 상기 버퍼와 연관된 데이터는 미리 정해진 조건이 충족된 후에 압축 파일로 전환된다. 상기 버퍼로부터의 데이터를 압축 파일로 전환한 후에, 상기 데이터 스트림으로부터 데이터를 수신하기 위해 제2 파일을 생성한다.

본 발명의 측면들은 다음의 특징 중 하나 이상을 포함할 수 있다. 상기 제1 파일은 상기 버퍼로부터의 데이터가 압축 파일로 전환된 후 삭제될 수 있다. 상태 정보는 상기 제1 파일이 활성상태(active)인지를 식별할 수 있게 한다. 상기 상태 정보는 상기 버퍼와 연관된 데이터가 압축 파일로 전환되고 있는 동안에는 잠금상태(locked)일 수 있다. 상기 상태 정보는 상기 제2 파일의 생성, 상기 제1 파일의 삭제, 및 상기 버퍼와 상기 압축 파일 간의 데이터의 전환을 반영하여 갱신될 수 있다. 상기 상태 정보가 잠금상태인 동안, 상기 상태 정보는 인덱싱(indexing) 또는 검색 동작(search operation)으로 액세스 불가능할 수 있다. 상기 상태 정보가 갱신된 후에, 상기 상태 정보는 잠금해제(unlocked)될 수 있다. 상기 상태 정보가 갱신된 후 상기 제1 파일은 삭제될 수 있다. 상기 미리 정해진 조건은 시간에 기초할 수 있다. 상기 미리 정해진 조건은 상기 제1 파일의 크기에 기초할 수 있다. 상기 미리 정해진 조건은 레코드의 수에 기초할 수 있다.

일반적으로, 본 발명의 다른 측면에서, 컴퓨터로 판독 가능한 매체는 디바이스 신호로부터 값의 취득 시에 사용하는 실행 가능한 명령어를 저장하고, 상기 명령어는 컴퓨터로 하여금 파일의 길이를 결정하고 상기 파일의 길이를 제1 메모리 위치에 저장하도록 한다. 상기 파일 내의 마지막 완전한 레코드의 종점이 결정될 수 있으며, 상기 종점은 제2 메모리 위치에 저장될 수 있다. 상기 제1 메모리 위치에 저장된 파일의 길이를 상기 파일의 현재 길이와 비교할 수 있다. 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하는 경우, 상기 파일과 연관된 데이터 구조는 상기 종점에서 시작하여 갱신할 수 있다.

본 발명의 측면들은 다음의 특징 중 하나 이상을 포함할 수 있다. 상기 데이터 구조는, 해시 테이블 또는 이진 트리 등의, 연관 데이터 구조일 수 있다. 상기 종점은 또한 상기 파일의 종점을 나타낼 수도 있다. 상기 종점은 상기 파일 내의 불완전한 레코드에 선행할 수 있다. 상기 명령어는 또한 상기 컴퓨터로 하여금 상기 파일의 에러 검사를 하도록 할 수 있다. 파일의 에러 검사는 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이보다 짧은지를 결정할 수 있다. 상기 파일은 비압축 데이터 파일일 수 있다.

일반적으로, 본 발명의 다른 측면에서, 컴퓨터로 판독 가능한 매체는 디바이스 신호로부터 값의 취득 시에 사용하는 실행 가능한 명령어를 저장하고, 상기 명령어는 컴퓨터로 하여금 데이터 스트림으로부터의 데이터를 제1 파일 및 버퍼에 동시에 추가하도록 한다. 상기 버퍼와 연관된 데이터는 미리 정해진 조건이 충족된 후에 압축 파일로 전환된다. 상기 버퍼로부터의 데이터를 압축 파일로 전환한 후에, 상기 데이터 스트림으로부터 데이터를 수신하기 위해 제2 파일을 생성한다.

본 발명의 측면들은 다음의 특징 중 하나 이상을 포함할 수 있다. 상기 제1 파일은 상기 버퍼로부터의 데이터가 압축 파일로 전환된 후 삭제될 수 있다. 상태 정보는 상기 제1 파일이 활성상태인지를 식별할 수 있게 한다. 상기 상태 정보는 상기 버퍼와 연관된 데이터가 압축 파일로 전환되고 있는 동안에는 잠금상태일 수 있다. 상기 상태 정보는 제2 파일의 생성, 제1 파일의 삭제, 및 상기 버퍼와 상기 압축 파일 간의 데이터의 전환을 반영하여 갱신될 수 있다. 상기 상태 정보가 잠금상태인 동안, 상기 상태 정보는 인덱싱 또는 검색 동작으로 액세스 불가능할 수 있다. 상기 상태 정보가 갱신된 후에, 상기 상태 정보는 잠금해제될 수 있다. 상기 상태 정보가 갱신된 후 상기 제1 파일은 삭제될 수 있다. 상기 미리 정해진 조건은 시간에 기초할 수 있다. 상기 미리 정해진 조건은 상기 제1 파일의 크키에 기초할 수 있다. 상기 미리 정해진 조건은 레코드의 수에 기초할 수 있다.

일반적으로, 본 발명의 다른 측면에서, 시스템은 파일의 길이를 결정하고 상기 파일의 길이를 제1 메모리 위치에 저장하는 수단을 포함한다. 상기 시스템은 또한 상기 파일 내의 마지막 완전한 레코드의 종점을 결정하고 상기 종점을 제2 메모리 위치에 저장하는 수단을 포함한다. 상기 시스템은 또한 상기 제1 메모리 위치에 저장된 파일의 길이를 상기 파일의 현재 길이와 비교하는 수단, 및 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하는 경우, 상기 파일과 연관된 데이터 구조를 상기 종점에서 시작하여 갱신하는 수단을 포함한다.

일반적으로, 본 발명의 다른 측면에서, 시스템은 데이터 스트림으로부터의 데이터를 제1 파일 및 버퍼에 동시에 추가하는 수단을 포함한다. 상기 시스템은 또한 미리 정해진 조건이 충족된 후에, 상기 버퍼와 연관된 데이터를 압축 파일로 전환하는 수단과, 상기 버퍼로부터의 데이터를 압축 파일로 전환한 후에, 상기 데이터 스트림으로부터 데이터를 수신하기 위해 제2 파일을 생성하는 수단을 포함한다.

도 1은 레코드를 저장 및 검색하는 시스템의 블록도이다.
도 2a, 도 2b, 도 2c, 및 도 2d는 시스템에 의해 처리, 저장된 데이터의 개략도이다.
도 3a 및 도 3b는 상이한 서명 크기에 대한 거짓 긍정의 확률(false positive probability)을 나타낸 표이다.
도 4a 및 도 4b는 레코드 검색 절차의 흐름도이다.
도 5는 레코드를 질의하는 절차의 흐름도이다.
도 6a 및 도 6b는 부가 가능한 룩업 파일(appendable lookup file)의 개략도이다.
도 7은 부가 가능한 룩업 파일을 질의하는 절차의 흐름도이다.
도 8은 데이터를 저장하는 절차의 흐름도이다.

도 1을 참조하면, 레코드 스토리지 및 검색 시스템(record strorage and retrieval)(간략하게 시스템이라고도 함)(100)은, 소스 A ∼ 소스 C 등의, 하나 이상의 소스로부터 데이터를 받아들인다. 이 데이터는 개별적으로 액세스 가능한 데이터의 유닛으로 표현될 수 있는 정보를 포함할 수 있다. 예를 들면, 신용카드 회사는 각종 소매회사로부터 개별적인 트랜잭션을 나타내는 데이터를 수신할 수 있다. 각 트랜잭션은 고객 성명, 날짜, 구매 금액 등의 속성을 나타내는 값과 연관되어 있다. 레코드 처리 모듈(102)은, 데이터가 미리 정해진 레코드 포맷에 따라 포맷팅되어 트랜잭션과 연관된 값들이 레코드에 저장되도록 보장한다. 어떤 경우에, 이것은 레코드 포맷에 따라 소스로부터의 데이터를 전환하는 것을 포함할 수 있다. 다른 경우에, 하나 이상의 소스가 레코드 포맷에 따라 이미 포맷팅된 데이터를 제공할 수 있다.

레코드 처리 모듈(102)은 저장된 레코드를 신속하게 액세스할 필요 여부 등의, 각종 인자에 따라 여러 타입의 데이터 구조로 스토리지용의 레코드를 준비한다. 부가 가능한 룩업 파일로 고속 접근성(fast accessibility)의 레코드를 준비할 때, 레코드 처리 모듈(102)은 레코드들이 도착할 때 부가 가능한 룩업 파일에 부가하고, 이하에 더욱 자세하게 설명하는 바와 같이, 메모리내 인덱스(in-memory index)를 유지한다. 압축 레코드 파일로 압축 스토리지용의 레코드를 준비할 때, 레코드 처리 모듈(102)은 각 레코드를 식별하는 기본키(예, 단일의 레코드를 식별하는 유일키나 다수의 갱신된 버전의 데이터를 식별하는 키) 값으로 레코드를 정렬하고, 레코드들을 기본키 값이 중첩되지 않는 범위에 대응하는 레코드의 세트로 나눈다. 예를 들면, 레코드의 세트 각각은 미리 정해진 수의 레코드(예컨대, 100개의 레코드)에 대응할 수 있다.

파일 관리 모듈(104)은 부가 가능한 룩업 파일(사용되는 상황에서)과 압축 룩업 파일 양자를 모두 관리한다. 압축 레코드 파일을 관리할 때, 파일 관리 모듈(104)은 각 레코드의 세트를 압축된 데이터의 블록으로 압축한다. 이들 압축 블록은 레코드 스토리지(106)(예컨대, 하나 이상의 하드 디스크 드라이브 등의 비휘발성 저장 매체)에 압축 레코드 파일로 저장된다.

시스템(100)은 또한 압축 레코드 파일 내의 블록 각각에 대한 엔트리를 포함하는 인덱스를 제공하는 인덱싱 및 검색 모듈(indexing and search module)(108)을 포함한다. 인덱스는, 이하에 더욱 자세하게 설명하는 바와 같이, 일정한(given) 레코드를 포함할 수 있는 블록의 정확한 위치를 찾아내는 데 사용된다. 인덱스는 인덱스 스토리지(110)에 인덱스 파일로 저장될 수 있다. 예를 들면, 인덱스 파일은 압축 레코드 파일과 동일한 저장 매체에 저장될 수 있지만, 인덱스 파일은 보통 압축 레코드 파일보다 훨씬 더 작기 때문에, 비교적 고속의 메모리(예컨대, DRAM(Dynamic Random Access Memory) 등의 휘발성 저장 매체)에 저장되는 것이 바람직할 수 있다. 인덱스는 또한 메모리 내 데이터 구조로서 유지되는 동적 인덱스(dynamic index)일 수 있다. 동적 인덱스(114)의 몇몇 예는 해시 테이블, 이진 트리와 b-트리(b-tree)이다. 인덱싱 및 검색 모듈(108)은 또한, 이하에 더욱 자세하게 설명하는 바와 같이, 부가 가능한 룩업 파일을 검색하기 위한 인터페이스도 제공한다.

시스템(100)의 다른 구현예에서, 레코드의 세트는 압축에 더하거나 대신하여 다른 기능을 사용하여 블록을 생성하고 일정한 방식으로 레코드를 결합하도록 처리될 수 있다(즉, 그래서 블록은 단지 레코드의 연쇄된 세트가 아니다). 예를 들면, 어떤 시스템은 레코드의 세트를 처리하여 암호화된 데이터의 블록을 생성할 수 있다.

인터페이스 모듈(112)은, 에이전트 A ∼ 에이전트 D 등의, 인간 및/또는 컴퓨터 에이전트에게 저장된 레코드에의 액세스를 제공한다. 예를 들면, 인터페이스 모듈(112)는 신용카드 고객이 자신의 트랙잰션을 모니터링하도록 온라인 회계 시스템(online account system)을 구현할 수 있다. 각종 기준을 충족시키는 트랜잭션 정보의 요청은 시스템(100)에 의해 처리될 수 있으며, 대응하는 레코드는 레코드 스토리지(106)에 저장된 압축 블록 내에서 검색될 수 있다.

하나 이상의 소스로부터 들어오는 레코드의 스트림은 처리되어 압축 레코드 파일을 생성하기 전에 일시적으로 저장될 수 있다.

도 2a ∼ 도 2d, 도 3a ∼ 도 3b, 그리고 도 4a ∼ 도 4b는, 압축 레코드 파일 내의 레코드를 관리하는 예를 나타낸다. 도 5 및 도 6a ∼ 도 6b는 부가 가능한 룩업 파일을 사용하는 레코드를 관리하는 예를 나타낸다. 도 2a를 참조하면, 시스템(100)은 압축 레코드 파일로 저장될 레코드의 세트(200)를 수신하고, 레코드를 기본키의 값에 따라 정렬한다.

기본키의 값은 하나 이상의 레코드로 표현될 수 있는 데이터베이스 내의 일정한 항목(given item)을 유일하게 식별할 수 있게 한다(예컨대, 일정한 기본키 값을 갖는 레코드 각각은 항목의 상이한 갱신된 버전에 대응할 수 있다). 기본키는 레코드의 하나 이상의 기존 필드에 대응하는 "자연키(natural key)"일 수 있다. 항목 각각에 대해 유일한 것으로 보장되는 필드가 존재하지 않으면, 기본키는 함께 항목 각각에 대해 유일한 것으로 보장되거나 그럴 가능성이 높은 레코드의 다수의 필드를 포함하는 복합키(compound key)일 수 있다. 다르게는, 기본키는 수신된 후 각 레코드에 할당될 수 있는 "합성키(synthetic key)"일 수 있다. 예를 들면, 시스템(100)은 유일한 기본키 값을 순차 증분되는 정수, 또는 단조적으로(monotonically) 처리하는 값(예, 시간 스탬프)의 어떤 다른 시퀀스로서 할당할 수 있다. 이 경우, 동일한 항목에 대한 상이한 버전을 나타내는 레코드는 상이한합성키 값을 할당받을 수 있다. 정수를 사용하는 경우, 가능한 기본키 값의 범위(예컨대, 사용된 비트수에 의해 결정됨)는 충분히 클 수 있기 때문에, 기본키가 롤오버(roll over)하는 경우, 일정한 기본키 값이 이전에 할당된 임의의 레코드는 압축 레코드 파일로부터 삭제되었다. 예를 들면, 이전(old)의 트랜잭션은 이동되어 보관되거나 폐기될 수 있다.

도 2a에 나타낸 예에서, 레코드(200)들은 알파벳순으로 정렬된 기본키 값: A, AB, CZ, ..., 에 의해 식별된다. 시스템(100)은 기본키 값 A ∼ DD를 갖는 N개의 레코드로 이루어진 제1 세트를 포함하여 대응하는 블록 1의 라벨을 붙인 대응하는 압축 블록을 생성한다. 레코드의 다음 세트는 기본키 값 DX ∼ GF를 갖는 다음의 N개의 정렬된 레코드를 포함한다. 파일 관리 모듈(104)은 각종 무손실 데이터 압축 알고리즘 중 어느 것(예, Lempel-Ziv 타입 알고리즘)을 사용할 수 있다. 연속적인 압축 블록 각각은 결합되어 압축 레코드 파일(202)을 구성한다. 압축 블록을 생성하기 위해 사용된 N개의 레코드는 압축 효율과 압축해제 속도 사이에 트래드 오프(trade off)로 선택될 수 있다. 압축은 압축되는 데이터의 성질(nature)과 압축되는 데이터의 크기에 의존하는 일정한 인자 R에 의해 평균하여 데이터의 크기를 줄일 수 있다(예컨대, R은 보통 더 많은 데이터가 압축될 때 더 작다). 압축은 또한 평균 사이즈 O의 관련 오버헤드(associated overhead)(예컨대, 압축 관련 데이터)를 가질 수 있다. 각각 크기 X인 N개의 레코드로부터 생성된 결과 압축 레코드 파일의 평균 크기는

로 표현될 수 있으며, 블록의 수가 많으면

로 근사될 수 있다. 따라서, 어떤 경우에는 N의 값이 클수록 R을 줄임으로써, 또 파일의 사이즈에 대한 오버헤드의 기여를 줄임으로써 더 큰 압축을 제공할 수 있다. N의 값이 작을 수록 블록 내에 포함될 수 있는 레코드에 액세스하기 위해 일정한 압축 블록을 압축해제하는 데 필요한 시간이 줄어든다.

다른 구현예에서, 상이한 압축 블록은 상이한 개수의 레코드를 포함할 수 있다. 각 블록은 미리 정해진 범위에 따라 다수의 레코드를 가질 수 있다. 예를 들면, 제1 블록은 기본키 값 1 ∼ 1000을 갖는 레코드들을 포함하고, 제2 블록은 기본 키 값 1001 ∼ 2000을 갖는 레코드를 포함하는 등이다. 본 예에서 압축 블록 내의 레코드의 수는, 모든 기본키 값이 반드시 존재하는 것은 아니기 때문에 상이할 수 있다(예컨대, 자연키로 사용된 수치 필드(numerical field)가 존재하는 경우).

어떤 구현예에서, 상이한 압축 블록들은 어떤 경우에 목표 개수(target number)의 레코드를 포함할 수 있고, 예외적인 경우에 더 많거나 더 적은 레코드를 포함할 수 있다. 예를 들면, 레코드의 세트가 정렬된 순서상 다음 레코드의 기본키 값과는 상이한 기본키 값을 갖는 레코드로 끝나는 경우, 이러한 레코드들은 압축 블록을 생성하는 데 사용된다. 레코드의 세트가 정렬된 순서상 다음 레코드의 기본키 값과 동일한 기본키 값을 갖는 레코드로 끝나는 경우, 그 기본키 값을 갖는 모든 추가적인 레코드들이 그 세트에 추가된다. 이렇게 하여, 동일한 기본키 값은 하나의 압축 블록에서 다음 압축 블록으로 넘어가지 않는다.

인덱싱 및 검색 모듈(108)는 각각의 압축 블록의 인덱스 파일(204)의 엔트리를 생성한다. 인덱스 엔트리는, 예를 들면 대응하는 비압축 레코드의 세트 내의 제1 레코드의 기본키에 의해, 각 압축 블록을 식별하게 해주는 키 필드(206)를 포함한다. 엔트리는 또한 압축 레코드 파일(202) 내의 식별된 압축 블록의 스토리지 위치를 식별하게 해주는 위치 필드(208)를 포함한다. 예를 들면, 위치 필드(208)는 레코드 스토리지(106) 내의 절대 어드레스 형태, 또는 레코드 스토리지(106) 내의 압축 레코드 파일(202)의 시작 어드레스로부터의 오프셋(offset) 형태로 포인터(pointer)를 포함할 수 있다.

압축 레코드 파일(202) 내의 일정한 레코드를 검색하기 위해, 인덱싱 및 검색 모듈(108)은 키 필드(206)에 기초하여 인덱스 파일(204)의 검색(예컨대, 이진 검색)을 수행한다. 키 값이 제공되면(예컨대, 에이전트 중 하나에 의해 제공됨), 인덱싱 및 검색 모듈(108)은 제공된 키 값을 포함하는 키 값의 범위에 대응하는 레코드들을 포함하는 블록의 위치를 찾아낸다. 제공된 키 값을 갖는 레코드는 위치를 찾아낸 블록을 생성하는 데 사용된 레코드의 세트에 포함되거나 포함되지 않을 수 있지만, 그 레코드가 레코드(200)들 중에 존재하면, 레코드(200)들은 기본키 값으로 정렬되었기 때문에, 그 레코드는 포함될 것이다. 인덱싱 및 검색 모듈(108)은 그후 위치를 찾아낸 블록을 압축해제하고 제공된 키 값을 갖는 레코드를 검색한다. 각 레코드마다 기본키 값이 유일하지 않는 경우, 인덱싱 및 검색 모듈(108)은 압축 블록 내에서 제공된 키 값을 갖는 다수의 레코드를 발견할 수 있다. 키 필드(206)가 세트의 제1(첫 번째) 레코드의 기본키를 포함하는 이 예에서, 인덱싱 및 검색 모듈(108)은 제공된 키 값보다 앞선(earlier) 키 값과 뒤의(later) 키 값을 각각 갖는 두 개의 연속하는 인덱스 엔터리를 검색하고, 앞선 키 값을 갖는 엔트리에 대응하는 블록을 돌려준다(return). 어떤 경우에, 제공된 키 값은 인덱스 엔트리 내의 키 값과 동일할 수 있으며, 이 경우 인덱싱 및 검색 모듈(108)은 그 엔트리에 대응하는 블록을 돌려준다.

다른 구현예에서는, 인덱스 파일(204) 내의 엔터리가 대응하는 블록을 생성하였던 레코드에 대응하는 키 값의 범위를 식별하는 다른 방법이 있다. 도 2a의 구현예에서 나타낸 바와 같이, 키 값의 범위는 블록을 생성하는 데 사용된 레코드들의 두 극값(extremum)의 키 값 사이의 범위일 수 있다(예컨대, 알파벳 기본키 값의 정렬된 시퀀스에서 최초값과 최종값, 또는 수치 기본키 값의 정렬된 시퀀스에서 최소값과 최대값). 인덱스 엔트리는 범위를 정하는 극값들 중 하나 또는 둘 다를 포함할 수 있다. 어떤 구현예에서, 인덱스 엔트리가 일정한 블록의 범위를 정하는 최소 키 값을 포함하는 경우, 압축 레코드 파일 내의 최종 블록과 연관된 최종 인덱스 엔트리는 또한 그 블록의 범위를 정하는 최대 키 값을 포함할 수 있다. 이 최대 키 값은 그후, 일정한 키 값이 범위를 벗어나는 때를 결정하기 위해 압축 레코드 파일을 검색할 때 사용될 수 있다.

다르게는, 키 값의 범위는 블록을 생성하는 데 사용된 레코드의 키 값을 넘어 확장되는 범위일 수 있다. 예를 들면, 레코드로부터 생성된 블록이 1에서 1000 사이의 수치 기본키 값을 갖는 경우, 레코드에 나타낸 최소 키 값은 1보다 클 수 있고, 레코드에 나타낸 최대 키 값은 1000보다 작을 수 있다. 인덱스 엔트리는 범위를 정하는 극값 1과 1000 중 하나 또는 둘 다를 포함할 수 있다.

초기의 레코드 그룹이 처리되어 압축 레코드 파일이 생성된 후에 추가적인 레코드가 도착한 경우, 그러한 레코드는 비압축 형태로 버퍼에 저장되고 검색될 수 있다. 다르게는, 추가적인 레코드의 그룹은 증분적으로(incrementallY) 처리되어 추가적인 인덱스 파일에 의해 액세스 가능한 추가적인 압축 레코드 파일로서 저장된다. 어떤 경우에는, 적은 수의 추가 레코드를 압축할 때 스토리지 크기를 크게 감소시키기 못할 수 있고, 레코드 액세스에 대해 획일적인 절차를 유지하기 위해 추가적인 레코드를 압축하는 것이 여전히 유리할 수 있다. 추가적인 레코드는 규칙적인 시간 간격(예컨대, 30초마다 또는 5분마다), 또는 미리 정해진 개수(예컨대, 1000개의 레코드마다 또는 10,000개의 레코드 마다)의 추가적인 레코드가 수신된 후에 반복적으로 처리될 수 있다. 들어오는 레코드를 시간 간격에 기초하여 처리하는 경우, 들어오는 레코드가 없거나 레코드의 수가 작은 어떤 간격에서는 모두가 하나의 압축 블록으로 압축된다.

도 2b를 참조하면, 초기의 압축 레코드 파일(202)이 생성된 후에 시스템(100)이 추가적인 레코드를 수신한 예에서는, 추가의 압축 레코드 파일(210)을 초기의 압축 레코드 파일(202)에 부가하여 복합 압축 레코드 파일(211)을 형성할 수 있다. 시스템(100)은 추가적인 레코드를 기본키 값으로 정렬하고 N개의 레코드의 세트들을 압축하여 압축 레코드 파일(210)의 압축 블록을 생성한다.

부가된 파일(210)에서 블록 91의 라벨이 붙은 제1 압축 블록은 기본키 값 BA ∼ FF를 가진다. 인덱싱 및 검색 모듈(108)은 부가된 파일(210) 내에 나타난 추가적인 레코드를 검색하는 데 사용될 수 있는 추가의 인덱스 파일(212)를 생성한다. 이 새로운 인덱스 파일(212)은 이전의 인덱스 파일(204)에 부가될 수 있다.

임의의 개수의 압축 레코드 파일이 부가되어 복합 압축 레코드 파일을 형성할 수 있다. 인덱싱 및 검색 모듈(108)이 복합 압축 레코드 파일 내의 일정한 키 값을 갖는 레코드를 검색하는 경우, 인덱싱 및 검색 모듈(108)은 대응하는 인덱스 파일을 사용하는 각각의 부가된 압축 레코드 파일 내의 레코드를 검색한다. 다르게는, 일정한 레코드를 요청하는 에이전트는 검색될 복합 압축 레코드 파일과 함께 일정한 수의 압축 레코드 파일을 명시할 수 있다(예컨대, 가장 최근에 생성된 10개, 또는 마지막 시간 내에 생성된 것).

일정량의 시간 후(예컨대, 24시간마다) 또는 일정한 개수의 압축 레코드 파일이 부가된 후, 시스템(100)은 복합 압축 레코드 파일과 새로운 대응하는 인덱스 파일로부터 단일의 압축 레코드 파일를 생성하기 위하여 파일들을 통합할 수 있다. 통합 후에, 일정한 레코드를 포함할 수 있는 압축 블록의 위치를 찾아내기 위해 단일의 인덱스를 검색하여, 결과적으로 더욱 효율적인 레코드 액세스를 얻을 수 있다. 통합시, 시스템(100)은 압축 레코드 파일을 압축해제하여 정렬된 레코드의 대응하는 세트를 복원하고, 그 레코드들을 기본키 값으로 정렬하며, 새로운 압축 레코드 파일 및 인덱스를 생성한다. 각각의 복원된 레코드의 세트가 이미 정렬되어 있기 때문에, 기본키 값에 따라 이전의 정렬된 리스트를 병합(merging)함으로써 레코드들을 효율적으로 정렬하여 단일의 정렬된 레코드의 세트를 생성할 수 있다.

도 2c를 참조하면, 복합 압축 레코드 파일(211)은 얼마나 많은 추가적인 레코드들이 도착하였는지, 얼마나 자주 레코드들을 압축하였는지에 따라 초기의 압축 레코드 파일(202), 추가적인 압축 레코드 파일(210), 및 다수의 추가적인 압축 레코드 파일(220, 221, ...)를 포함한다. 각 압축 레코드 파일(220)은 단일의 압축 블록(블록 95)을 가질 정도로 작고, 따라서 연관된 인덱스 파일을 반드시 필요로 하지는 않지만, 블록 내의 기본키 값들의 범위 및 그것의 스토지리 내의 위치를 나타내는 연관 데이터를 가질 수 있다. 통합 후에, 상이한 부가된 압축 레코드 파일로부터 복원된 레코드를 처리하여 단일의 압축 레코드 파일(230)을 생성한다.

기본키를 단조적으로 할당하는 경우, 레코드들은 압축 레코드 파일 내에서 뿐 아니라 한 파일에서 다른 파일로 자동 정렬되어, 단일의 인덱스 검색으로 레코드를 검색하기 위해 파일을 통합할 필요가 없다.

도 2d를 참조하면, 시스템(100)은 레코드의 기본키로서 도착 순서대로 할당된 연속하는 정수에 의해 식별되는 레코드(250)들의 세트를 수신한다. 따라서, 레코드(250)들은 기본키에 의해 자동 정렬된다. 초기의 압축 레코드 파일(252)은 이 예에서 각각 100개의 레코드를 포함하는 압축 블록을 포함하고, 인덱스 파일(254)은 압축 블록 내의 제1(첫 번째) 레코드의 기본키 값을 위한 키 필드(256)와 대응하는 스토리지 위치를 식별하게 해주는 위치 필드(258)를 포함한다. 초기의 압축 레코드 파일(252)이 생성된 후에 도착하는 레코드들은 정렬된 순서에서 그 뒤의 기본키 값을 자동으로 가질 것이기 때문에, 부가된 압축 레코드 파일(260) 및 대응하는 인덱스 파일(262)은 단일의 인덱스 검색에 기초한 효율적인 레코드 액세스를 가능하게 하기 위해 통합될 필요는 없다. 예를 들면, 인덱스 파일(262)은 인덱스 파일(254)에 간단히 부가될 수 있고, 이들 모두는 압축 레코드 파일(252) 또는 압축 레코드 파일(260)에서 압축 블록의 위치를 찾기 위해 함께 검색될 수 있다(예컨대, 단일의 이진 검색)

복합 압축 레코드 파일(261)은 압축 레코드 파일(252)의 끝에 삽입되었을 수 있는 불완전한 블록을 제거하기 위해 선택적으로 통합될 수 있다. 이러한 통합 시에, 제1(첫 번째) 파일(252)의 마지막 압축 블록만이 압축해제될 필요가 있을 것이고, 그 압축해제된 레코드의 세트를 병합하는 대신에, 그 레코드의 세트를 연쇄시켜, 나중에 다시 압축되어 새로운 압축 레코드 파일을 형성할 100개의 레코드의 세트로 분할될 새로운 정렬된 레코드의 세트를 형성할 수 있다.

연속적인 정수 합성 기본키 값을 사용하는 다른 이점은, 레코드들을 기본키 값에 기초하여 분할할 경우, 키 값에 갭(gap)이 없기 때문에 분할은 자동적으로 균형이 유지될 수 있다.

다양한 기술 중 임의의 기술을 사용하여 레코드를 갱신할 수 있고 압축 레코드 파일에 존재할 수 있는 임의의 이전 버전의 레코드를 무효화(invalidate)할 수 있다. 어떤 경우에, 레코드들은 개별적으로 제거 또는 갱신될 필요가 없다(예컨대, 로그, 트랜잭션, 전화 통화). 이 경우들에는, 이전의 레코드는 제거, 폐기되거나, 예를 들면 압축 레코드 파일의 시작점(beginning)으로부터 미리 정해진 개수의 압축 블록의 그룹으로 보관된다. 어떤 경우에, 압축 레코드 파일 전체가 제거될 수 있다.

어떤 경우에는, 새로운 갱신된 레코드를 압축 블록으로 스토리지에 추가함으로써 레코드의 하나 이상의 값이 갱신될 수 있고, 레코드의 이전에 수신된 버전(동일한 기본키 값을 가짐)은 다른 압축 블록 내에 저장된 채 남아 있을 수 있다. 그러면 레코드의 여러 버전이 존재할 수 있고, 어떤 기술을 사용하여 레코드의 유효한 버전을 결정한다. 예를 들면, 임의의 압축 레코드 파일에 나타나는 마지막 버전(가장 최근에 수신된 것)을 묵시적으로 또는 명시적으로 유효한 버전으로 나타낼 수 있고, 기타 버전들은 무효이다. 이 경우에, 일정한 기본키를 갖는 레코드의 검색은, 나타난 순서로 그 기본키에 의해 식별된 마지막 레코드를 찾는 것을 포함할 수 있다. 다르게는, 레코드의 임의의 이전 버전들이 무효라는 것을 나타내는 "무효 레코드(invalidate record)"를 기록함으로써 레코드의 새로운 버전을 추가할 필요없이 무효화될 수 있다.

시스템(100)은 다른 프로세스에 의해 레코드 스토리지(106)에 저장된 압축 레코드 파일에 대한 액세스를 중재한다(mediate). 다양한 동기화 기술 중 어느 것을 사용하여 하나 이상의 압축 레코드 파일 내의 압축 블록에 대한 액세스를 중재할 수 있다. 시스템(100)은 (예컨대, 데이터를 부가 또는 통합함으로써) 파일을 변경하는 임의의 프로세스가 서로 간섭하지 않도록 보장한다. 예를 들면, 통합이 이루어지고 있는 동안에 새로운 레코드들이 도착하는 경우, 시스템(100)은 그 통합 프로세스가 끝날 때까지 대기할 수 있거나, 또는 그들을 기존의 압축 레코드 파일에 부가하기 이전에 압축 블록을 생성하여 일시적으로 저장할 수 있다. 압축 레코드 파일로부터 판독하는 프로세스는 완전한 파일의 일부를 로드(load)할 수 있고, 변경이 진행되고 있을 수 있는 임의의 불완전한 부분을 무시할 수 있다.

시스템(100)은 기본키 외에 레코드의 속성에 기초하여 레코드 검색을 가능하게 하는 추가적인 데이터를 저장한다. 압축 레코드 파일의 보조 인덱스(secondary index)는 보조키(secondary key)로서 지정된 속성의 값에 기초한 하나 이상의 기본키 값을 제공하는 정보를 포함한다. 보조키로서 지정된 각 속성은 대응하는 보조 인덱스와 연관될 수 있다. 예를 들면, 각 보조 인덱스는 연관된 보조키에 의해 정렬된 가로열(row)들을 갖는 표로 구성될 수 있다. 각 가로열은 보조키 값과 보조키 값을 포함하는 레코드들의 하나 이상의 기본키 값을 포함한다. 따라서, 에이전트가 일정한 보조키 값을 포함하는 임의의 레코드에 대한 검색을 개시하는 경우, 시스템(100)은 레코드(들)를 포함하는 압축 블록(들)에 대해 압축 레코드 파일의 인덱스를 검색에 사용하기 위한 기본키(들)을 찾는다. 보조 인덱스는 대규모(예컨대, 레코드의 수와 비슷한 정도)일 수 있고 어떤 경우에는 압축 레코드 파일을 저장하는 저장 매체에 저장될 수 있다.

어떤 경우에, 보조키로서 지정된 속성의 값은 레코드마다 유일할 수 있다. 이러한 경우에, 그 보조키와 기본키 사이에는 일대일 대응관계가 존재하고, 인터페이스 모듈(112)은 보조키 속성을 기본키인 것처럼 에이전트에 대해 나타낼 수 있다.

각 보조 인덱스는, 복합 압축 레코드 파일에 새로운 압축 레코드 파일이 부가될 때, 갱신될 수 있다. 다르게는, 보조키는 압축 레코드 파일 각각의 상이한 보조 인덱스와 연관될 수 있고, 압축 레코드 파일들이 통합될 때 보조 인덱스들은 단일의 보조 인덱스로 통합될 수 있다.

스크리닝 데이터 구조(screening data structure)는, 일정한 속성을 포함하는 레코드가 파일의 압축 블록에 포함되어 있을 확률을 결정하는 압축 레코드 파일에 연관될 수 있다. 예를 들면, 스크리닝 데이터 구조로서 중첩 부호화 서명(overlap encoded signature, OES)을 사용함으로써 시스템(100)이 일정한 키 값(기본키 또는 보조키)을 가지는 레코드가 확실히 존재하지 않거나("부정(negative)의" 결과), 아니면 일정한 키 값을 가지는 레코드가 존재할 확률이 있는지("긍정(positive)의" 결과)를 결정할 수 있게 한다. 긍정의 결과인 경우, 시스템(100)은 적절한 압축 블록을 액세스하여 해당 레코드를 검색하거나("확인된 긍정적인(confirmed positive)" 결과), 해당 레코드가 존재하지 않는 것으로 결정한다("거짓 긍정적인(false positive)" 결과). 부정의 결과인 경우, 시스템(100)은 존재하지 않는 레코드에 대한 검색 및 압축해제에 시간을 소비할 필요없이 에이전트에 부정의 결과를 제공할 수 있다. OES의 크기는, 긍정의 결과들이 거짓 긍정의 결과일 빈도에 영향을 미치며, 일반적으로 OES의 크기가 클수록 더 적은 거짓 긍정의 결과를 가져온다. 일정한 OES 크기에 대해, 구별 가능한 키 값이 적을 수록 일반적은 더 적은 거짓 긍정의 결과를 가져온다.

다른 타입의 스크리닝 데이터 구조도 가능하다. 일정한 기본키 또는 보조키의 스크리닝 데이터 구조는 압축 레코드 파일 각각에 대해 제공될 수 있다. 다르게는, 키에 대한 스크리닝 데이터 구조는 압축 블록 각각에 대해 제공될 수 있다.

도 3a 및 도 3b는 다양한 크기의 예시적인 OES 스크리닝 데이터 구조(세로열, column)와 압축 레코드 파일(가로열, row)로 나타낸 다양한 개수의 구별키(distinct key) 값에 대해, 키 값에 대해 거짓 긍정의 결과를 취득하는 확률값을 제공하는 표를 나타낸다. 어떤 OES에 대해, OES의 크기 및 구별키 값의 개수에 따라서는, 하나 이상의 키 값의 존재를 OES의 동일한 부분에 나타낼 수 있어, 다른 것이 존재하는 경우 그 키 값들 중 하나에 대해 거짓 긍정의 결과를 초래할 가능성이 있다. 이 예시적인 OES의 크기는 2¹⁰ = 1024 bit(도 3a의 표) 내지 2²⁸ = 256 Mbit(도 3b의 표)이다. 구별키 값의 개수는 100개(도 3a의 표) 내지 100,000,000개(도 3b의 표)로 변화한다. 두 표에서, 오른쪽 위의 빈 셀(blank cell)은 0%에 대응하고 왼쪽 아래의 빈 셀은 100%에 대응한다. 거짓 긍정의 확률이 낮은(예컨대, 영(zero)에 가까운) 셀의 경우, 스크리닝 데이터 구조는 적절한 스크리닝의 제공에 필요한 것보다 더 클 수 있다. 거짓 긍정의 확률이 상당한(예컨대, > 50%) 셀의 경우, 적절한 스크리닝의 제공하기에 너무 작을 수 있다. 이 예는 키 값마다 4개의 해시 코드를 사용하여 OES를 생성하는 기술에 대응한다. OES 스크리닝 데이터 구조의 다른 예는 일정한 개수의 구별키에 대해 거짓 긍정의 확률에 대한 상이한 표를 산출할 수 있다.

압축 레코드 파일에 표시된 구별키 값의 개수는 알려져 있지 않을 수 있으므로, 시스템(100)은 파일을 생성하였던 레코드의 개수에 기초하여 압축 레코드 파일의 스크리닝 데이터 구조의 크기를 선택할 수 있다. 크기를 선택할 때, 거짓 긍정의 확률과 스크리닝 데이터 구조의 저장에 필요한 메모리 공간 사이에는 트래드오프가 존재한다. 이 트래드오프에 있어 한 가지 인자는 없는 키 값(absent key value)을 검색할 가능성이다. 검색될 대부분의 키 값들은 압축해제된 레코드들에 존재할 가능성이 높은 경우, 스크리닝 데이터 구조는 전혀 필요 없을 수 있다. 키 값이 발견되지 않을 확률이 상당한 경우, 비교적 큰 스크리닝 데이터 구조를 위한 스토리지 공간의 할당은 시간을 상당히 절약할 수 있다.

압축 레코드 파일과 연관된 스크리닝 데이터 구조의 크기는, 파일이 레코드의 초기의 또는 통합된 대규모 데이터베이스에 대응하는지, 또는 더 큰 규모의 데이터베이스에 대한 더 작은 규모의 갱신에 대응하는지에 의존할 수 있다. 비교적 작은 스크리닝 데이터 구조 크기는, 일반적으로 각각의 갱신에 있어 더 적은 구별키 값이 존재하기 때문에, 정기적인 갱신 간격 동안에 부가되는 압축 레코드 파일에 사용될 수 있다. 또한, 작은 크기는 여러번의 갱신 후에 압축 레코드 파일의 개수가 증가함에 따른 필요한 스토리지 공간을 줄일 수 있다. 스크리닝 데이터 구조의 크기는 갱신 시에 예상되는 레코드 및/또는 구별키 값의 개수에 기초할 수 있고, 또 예상되는 갱신의 회수에 기초할 수 있다. 예를 들면, 갱신된 파일들이 24시간 주기 내내 5분마다 부가되는 경우, 그날의 마지막에는 288개의 압축 레코드 파일이 있게 될 것이다. 적어도 하나가 거짓 긍정의 결과일 확률은 도 3a 및 도 3b의 표에서의 적절한 값의 288배가 될 것이다(상이한 갱신들의 결과는 독립적이라고 가정함). 통합 후에는, 구별키의 개수가 상당히 증가할 수 있기 때문에 더 큰 스크리닝 데이터 구조가 통합된 압축 레코드 파일에 적절할 수 있다.

압축 레코드 파일은 기본키 및 보조키 각각에 대한, 또는 상기 키들의 어떤 하위세트(subset)에 대한 스크리닝 데이터 구조를 가질 수 있다. 예를 들면, 시스템(100)은 기본키에 대해, 그리고 레코드를 검색할 때 가장 자주 사용될 것으로 예상되는 보조키들에 대해서만 스크리닝 데이터 구조를 제공할 수 있다.

도 4a는 일정한 기본키 값을 가지는 하나 이상의 레코드를 검색하는 절차(400)의 흐름도를 나타낸다. 절차(400)는, 제1 압축 레코드 파일과 연관된 스크리닝 데이터 구조가 존재하는지를 판단한다(402). 존재한다면, 절차(400)는 스크리닝 데이터 구조를 처리하여(404) 긍정 또는 부정의 결과를 얻는다. 일정한 기본키 값이 스크리닝을 통과하지 못하면(부정의 결과), 절차(400)는 다음의 압축 레코드 파일을 조사(406)하고 존재하는 경우 그 파일에 대해 반복한다. 일정한 기본키 값이 스크리닝을 통과하면(긍정의 결과), 절차(400)는 그 일정한 기본키 값을 가지는 레코드를 포함할 수 있는 블록에 대한 인덱스를 검색한다(408). 압축 레코드 파일과 연관된 스크리닝 데이터 구조가 없으면, 절차(400)는 스크리닝을 수행하지 않고 인덱스를 검색한다(408).

인덱스를 검색(408)한 후, 일정한 기본키 값을 포함하는 키 값의 범위와 연관된 압축 블록을 발견하면(410), 절차(400)는 인덱스 엔트리에 의해 식별된 위치에 있는 블록을 압축해제하고(412) 일정한 기본값을 가지는 하나 이상의 레코드가 있는지 결과 레코드들을 검색한다(414). 그후 절차(400)는 다음의 압축 레코드 파일을 조사(416)하고 파일이 존재하면 그 파일에 대해 반복한다. 압축 블록이 발견되지 않으면(예컨대, 일정한 기본키 값이 제1 블록 내의 최소 키 값보다 작거나 또는 마지막 블록 내의 최대 키 값보다 큰 경우), 절차(400)는 다음의 압축 레코드 파일을 조사(416)하고 파일이 존재하면 그 파일에 대해 반복한다.

도 4b는 일정한 보조키 값을 가지는 하나 이상의 레코드를 검색하는 절차(450)의 흐름도를 나타낸다. 절차(450)는, 제1 압축 레코드 파일과 연관된 스크리닝 데이터 구조가 존재하는지를 판단한다(452). 존재한다면, 절차(450)는 스크리닝 데이터 구조를 처리하여(454) 긍정 또는 부정의 결과를 얻는다. 일정한 보조키 값이 스크리닝을 통과하지 못하면(부정의 결과), 절차(450)는 다음의 압축 레코드 파일을 조사(456)하고 존재하는 경우 그 파일에 대해 반복한다. 일정한 보조키 값이 스크리닝을 통과하면(긍정의 결과), 절차(450)는 그 일정한 보조키 값을 가지는 레코드를 포함하는 블록에 대한 기본키를 검색한다(458). 압축 레코드 파일과 연관된 스크리닝 데이터 구조가 없으면, 절차(450)는 스크리닝을 수행하지 않고 기본키를 검색한다(458).

발견된 기본키 각각에 대해, 절차(450)는 일정한 기본키 값을 가지는 레코드를 포함할 수 있는 블록에 대한 인덱스를 검색한다(460). 인덱스를 검색(460)한 후, 일정한 기본키 값을 포함하는 키 값의 범위와 연관된 압축 블록을 발견하면(462), 절차(450)는 인덱스 엔트리에 의해 식별된 위치에 있는 블록을 압축해제하고(464) 일정한 기본값을 가지는 하나 이상의 레코드가 있는지 결과 레코드들을 겸색한다(466). 그후 절차(450)는 다음의 압축 레코드 파일을 조사(416)하고 파일이 존재하면 그 파일에 대해 반복한다. 압축 블록이 발견되지 않으면, 절차(450)는 다음의 압축 레코드 파일을 조사(468)하고 파일이 존재하면 그 파일에 대해 반복한다.

일정한 기본키 또는 보조키를 가지는, 발견된 다수의 레코드는 절차(400) 또는 절차(450)에 의해 출현 순서대로 반환될 수 있거나, 또는 어떤 경우에는 그 레코드의 최종 버전만이 반환된다.

파일 관리 모듈(104)은 또한 부가 가능한 룩업 파일을 사용하여 레코드의 스토리지 및 액세스를 관리한다. 부가 가능한 룩업 파일을 사용하는 일 예에서, 시스템(100)은 대규묘의 기본 데이터 세트(예컨대, 수백 테라바이트의 기본 데이터)를 관리한다. 이 기본 데이터 세트는 하나 또는 다수의 압축 레코드 파일의 시리즈로 저장될 것이다(어쩌면 복합 압축 레코드 파일로 연쇄됨), 그러나, 데이터가 도착한 후(예컨대, 1분 이내) 데이터를 눈에 띄게 짧게 할 필요가 있는 경우, 압축 레코드 파일을 부가 가능한 룩업 파일로 추가(supplement)하는 것이 유용할 수 있다. 부가 가능한 룩업 파일은 새로운 데이터가 도착한 시각과 그 데이터가 각종 질의 프로세스에 이용 가능해지는 시각 사이의 지연(latency)을 줄일 수 있다. 새로운 데이터는, 예를 들면, 적극적으로 파일에 데이터를 기록하는 다른 프로세스로부터 유래할 수 있다. 시스템(100)은 불완전할 수 있는 부분(partial) 부가 가능한 룩업 파일에의 액세스를 관리할 수 있다. 어떤 시스템에서, 질의 프로세스가 부분 파일을 만났을 때, 프로그램 에러가 생길 것이다. 이 프로그램 에러를 피하기 위해, 이들 시스템 중 일부는 파일이 질의될 때마다 그 파일과 연관된 인덱스를 리로드(reload)할 것이다. 모든 질의에 대해 인덱스를 리로드하는 것은 어떤 상황에서는 비효율적일 수 있고, 시스템 자원의 상당한 양을 소비할 수 있다.

일반적으로, 부가 가능한 룩업 파일은 파일의 끝에 부가된 부분 레코드에 대해 관대한 비압축 데이터 파일이다. 부가 가능한 룩업 파일은 불완전한 레코드를 인식할 수 있고, 질의된 파일이 불완전한 레코드를 포함할 때에도 질의 요청을 처리할 수 있다. 부가 가능한 룩업 파일은 압축 레코드 파일에 대해 전술한 바와 같은 타입의 인덱스 파일을 가지지 않으며; 오히려 부가 가능한 룩업 파일은 각 레코드의 위치를 상당히 빠른 작업 메모리(에컨대, DRAM 등의 휘발성 저장 매체)에 저장된 데이터 구조에 매핑시키는 "동적 인덱스"를 가진다. 예를 들면, 이들 동적 인덱스는 해시 테이블, 이진 트리, b-트리, 또는 다른 타입의 연관 데이터 구조일 수 있다. 도 5는 부가 가능한 룩업 파일을 질의하는 프로세스의 예이다. 부가 가능한 룩업 파일의 동작에 관련된 프로세스 흐름(500)은 로드 프로세스(load process)(502)와 질의 프로세스(query process)(504)를 포함한다. 파일을 로드한 후(506)(파일이 질의된 때 등), 파일의 길이를 결정한다(508). 파일의 길이를 결정한 후(508), 결정된 길이를 작업 메모리 내와 같은, 메모리 위치에 저장한다(510). 시스템(100)은 파일 내의 마지막 완전한 레코드의 끝을 나타내는 위치인 "종점"을 결정한다(512). 파일에 기록되는 새로운 데이터가 없는 때와 같은, 어떤 경우에는, 종점은 단순히 그 파일의 끝을 나타낼 것이다. 또한 종점은 새로운 데이터의 첫 번째 세그먼트에 바로 선행하는 위치를 나타낼 수 있다(도 6 참조). 종점을 결정한 후(512), 그 종점을 메인 메모리 내와 같은, 메모리 위치에 저장한다(514).

질의 프로세스(504) 동안에, 시스템(100)은 질의를 처리(522)할 것인지, 질의된 파일과 연관된 연관 데이터 구조를 갱신(518)할 것인지를 결정한다. 이 결정을 하기 위해, 시스템(100)은 파일의 현재 길이와 이전에 결정되어 메모리에 저장되어 있는 파일의 길이를 비교한다(516). 이 판단은 여러 방식으로 이루어질 수 있다. 예를 들면, 시스템(100)은 파일 메타데이터, 파일 헤더를 조사할 수 있거나, 또는 개행 문자(new line character)를 찾아 파일을 검색할 수 있다. 파일의 현재 길이가 이전에 저장된 파일의 길이를 초과하지 않으면, 데이터 파일의 끝에 새로운 데이터가 추가되지 않은 것이므로, 질의를 처리한다(522). 파일의 현재 길이가 이전에 저장된 파일의 길이를 초과하면, 이전에 저장된 종점에서 시작하여 연관 데이터 구조를 갱신한다(518), 이렇게 하여, 연관 데이터 구조를 전적으로 리로드 또는 재구축(rebuild)하지 않고 연관 데이터 구조를 갱신할 수 있다. 대신에, 이미 메모리에 로드된 데이터는 로드된 상태로 있으며, 새로운 데이터가 이전에 저장된 종점에서 시작하여 부가된다. 질의를 처리하기 전에, 파일 길이와 종점도 갱신한다(520). 에러 검사와 같은 다른 단계는 이 프로세스에서 실행될 수 있다. 예를 들면, 시스템이 파일의 현재 길이가 이전에 저장된 파일의 길이보다 짧다고 판단한 경우, 에러를 플래깅(flagging)할 수 있다.

도 6a 및 도 6b는 도 5의 단계 512에서 결정된 바와 같은, 파일 내의 종점의 위치에 대한 예이다. 도 6a에서, 부가 가능한 룩업 파일(600)은 완전한 레코드(602)와 불완전한 레코드(604)를 포함한다. 이 경우, 종점(606)은 부가 가능한 룩업 파일의 마지막 완전한 레코드를 나타내는 위치이고, 불완전한 레코드(604)의 시작점에 바로 선행한다.

도 6b의 예에서, 부가 가능한 룩업 파일(650)은 전적으로 완전한 레코드(652)로 구성되어 있다. 이 경우, 종점(654)은 또 부가 가능한 룩업 파일(650) 내의 마지막 완전한 레코드의 끝을 나타내지만; 종점(654)은 파일의 끝을 나타내기도 한다.

데이터는, 차례로 연속적으로 갱신되는 부가 가능한 룩업 파일에 연속적으로 부가될 수 있다. 그 결과, 부가 가능한 룩업 파일은 크기가 매우 커지고, 그에 상응하여 부가 가능한 룩업 파일을 로드하는 데 걸리는 시간이 증가한다. 부가 가능한 룩업 파일이 너무 커서 바람직한 시간량 내에 로드하기 어려워지는 것을 피하기 위해 부가 가능한 룩업 파일은 다른 형태의 동적으로 로드 가능한 인덱스 파일과 결합될 수 있다.

어떤 애플리케이션에서, 질의 가능한(queriable) 데이터 구조로 로드될 데이터의 연속 스트림은 고속 레이트로 도착할 수 있고, 도착한 후 바로 데이터에 대한 액세스가 요구될 수 있다. 데이터가 도착한 때, 데이터는 듀얼 프로세스(dual process)로 처리된다. 먼저, 데이터는 복제되어 제2 파일 또는 "버퍼"와 부가 가능한 룩업 파일에 동시에 부가된다(그래서 파일 시스템이 즉시 볼 수 있고 액세스 가능하다). 미리 정해진 조건이 충족될 때까지, 데이터는 계속하여 부가 가능한 룩업 파일와 버퍼 양쪽에 축적된다. 미리 정해진 조건은 다수의 기준일 수 있다. 예를 들면, 미리 정해진 기준은 시간의 길이, 파일 크기, 데이터의 양, 또는 데이터 내의 레코드의 개수일 수 있다.

미리 정해진 조건이 충족된 후, 버퍼에 축적된 데이터의 블록은 더 장기의 스토리지용의 압축 레코드 파일에 더해진다. 데이터가 압축 레코드 파일에 더해진 후에, 새로운 부가 가능한 룩업 파일이 생성되고 새로운 스트림으로부터의 데이터 수집을 시작한다. 이전(old)의 부가 가능한 룩업 파일은 완결되고, 압축 레코드 파일이 대응하는 데이터를 모두 포함한 후에 삭제된다.

버퍼와 부가 가능한 룩업 파일 양쪽에서 데이터를 수신하는 동안에, 버퍼 내의 데이터는 정렬될 수 있다. 데이터의 정렬은 시스템 자원 및 시간의 상당한 양을 소비하기 때문에, 정렬 프로세스는, 데이터가 압축 레코드 파일로 더 신속하게 전화될 수 있도록 가능한 한 일찍 시작하는 것이 유리하다.

다르게는, 부가 가능한 룩업 파일은 버퍼로서 사용될 수 있다. 이 실시예에서, 데이터는 미리 정해진 조건이 충족될 때까지 부가 가능한 룩업 파일에 축적된다. 그후 부가 가능한 룩업 파일의 컨텐츠는 압축 레코드 파일에 추가되고, 동시에 이전의 부가 가능한 룩업 파일이 완결되고 새로운 부가 가능한 룩업 파일이 생성되어 데이터 스트림으로부터의 데이터를 수집하기 시작한다. 또, 압축 레코드 파일이 대응하는 데이터를 모두 포함한 후에 이전의 부가 가능한 룩업 파일이 삭제된다.

이 프로세스의 각 사이클 동안에, 압축 레코드 파일에의 데이터 추가와 부가 가능한 룩업 파일 내의 모든 데이터의 삭제를 동시에 수행하는 것이 바람직할 것이다. 그러나, 두 가지 갱신은 경쟁 상태(race condition)를 발생시킬 수 있기 때문에, 이전의 부가 가능한 룩업 파일은 삭제되었지만 압축 레코드 파일은 아직 그 데이터를 갱신하지 않은 중요한 시간대(window)가 있을 수 있다. 이것은 데이터의 일시적인 손실을 초래할 것이다. 이를 방지하기 위해, 이전의 부가 가능한 룩업 파일은 이 프로세스의 추가의 사이클 동안에 유지될 수 있다. 인덱싱 및 검색 모듈(108)은 복제 데이터가 부가 가능한 룩업 파일과 압축 레코드 파일 양쪽에 존재할 수 있는 조건을 검출하도록 구성되고, 인덱싱 및 검색 모듈(108)은 이 조건 동안에 질의가 이루어지는 경우, 복제 데이터를 필터링한다.

다르게는, 파일 관리 모듈(104)은, 예를 들면, 상태 정보 파일(107) 내의 상태 정보를 유지하여, 데이터 버퍼가 압축 룩업 파일에 기록되었거나 부가 가능한 룩업 파일의 컨텐츠가 압축 룩업 파일에 추가된 후의 부가 가능한 룩업 파일의 폐기(retirement)를 조정할 수 있다. 상태 정보 파일(107)은 현재 활성상태인 데이터 구조 관련 레코드를 식별할 수 있게 한다. 예를 들면, 상태 정보 파일(107)은 모든 압축 레코드 파일 및 현재 활성상태인 모든 부가 가능한 룩업 파일과 함께 포함하는 블록의 개수를 식별할 수 있게 한다. 인덱싱 및 검색 모듈(108)은 상태 정보 파일에 나타나지 않는 임의의 부가 가능한 룩업 파일, 압축 데이터 파일, 및 압축 데이터 파일 내의 블록들을 무시할 것이다. 새로운 부가 가능한 룩업 파일이 생성될 때, 파일 관리 모듈(104)에 의해 관찰되는 프로토콜의 예는 다음과 같다: 파일 관리 모듈(104)은 새로운 데이터를 압축 데이터 파일에 추가하고 새로운 부가 가능한 룩업 파일을 생성하고; 파일 관리 모듈(104)은 상태 정보 파일이 인덱싱 및 검색 모듈(108)에 의해 액세되는 것을 방지하기 위해 상태 정보 파일을 잠금상태로 하며; 파일 관리 모듈(104)은 압축 데이터 파일에 대한 새로운 데이터의 추가를 반영하여 상태 정보 파일을 갱신하고, 이전의 부가 가능한 룩업 파일을 제거하며, 새로운 부가 가능한 룩업 파일을 생성하고; 파일 관리 모듈(104)은 상태 정보 파일을 잠금해제(unlock)하여 인덱싱 및 검색 모듈(108)에 의해 다시 액세스될 수 있도록 하며; 파일 관리 모듈(104)은 부가 가능한 룩업 파일을 제거한다.

인덱싱 및 검색 모듈(108)은 다음의 예시적인 프로토콜을 따른다: 인덱싱 및 검색 모듈(108)은 파일 관리 모듈(104)이 상태 정보 파일을 갱신하는 것을 방지하기 위해 상태 정보 파일을 잠금상태로 하고; 인덱싱 및 검색 모듈(108)은 상태 정보 파일에서 식별된 압축 데이터 파일 및 부가 가능한 룩업 파일에 따라 질의를 수행하며; 인덱싱 및 검색 모듈(108)은 상태 정보 파일을 잠금해제하여 파일 관리 모듈(104)이 상태 정보 파일을 갱신하도록 다시 허용한다.

상태 정보 파일(107)은 디스크 또는 메모리에 저장될 수 있다. 이 프로토콜은, 검색 모듈이 이전의 부가 가능한 룩업 파일로부터의 데이터를 통합하기 이전에 이전의 부가 가능한 룩업 파일 및 압축 데이터 파일이나, 새로운 부가 가능한 룩업 파일 및 갱신된 압축 데이터 파일을 참조(see)하는 것을 보장한다.

새로운 부가 가능한 룩업 파일과 이전의 부가 가능한 룩업 파일 양쪽이 동시에 존재할 때 질의가 이루어진 경우, 일 구현예에서, 시스템은 디렉토리를 찾아 어떤 부가 가능한 룩업 파일이 현재 활성상태인지를 참조한다(예컨대, 새로운 부가 가능한 룩업 파일이나, 새로운 부가 가능한 룩업 파일은 생성된 후 지연이 일정한 양이 될 때까지는 활성상태가 될 수 없기 때문에 이전의 부가 가능한 룩업 파일이 활성상태일 수 있다). 다르게는, 시스템이 질의를 처리할 때, 시스템은 먼저 최신의 부가 가능한 룩업 파일에서 찾고, 그후 이전의 부가 가능한 룩업 파일에서 찾는다. 질의된 데이터가 아직 위치되지 않은 경우, 시스템은 압축 레코드 파일에서 찾는다.

도 7에서, 시스템(100)에 의해 수행되는 절차(700)는 파일의 길이를 결정하고(702), 파일의 길이를 제1 메모리 위치에 저장한다(704). 절차(700)는 파일 내의 마지막 완전한 파일의 종점을 결정하고(706), 그 종점을 제2 메모리 위치에 저장한다(708). 절차(700)는 제1 메모리 위치에 저장된 파일의 길이와 파일의 현재 길이를 비교하고(710), 파일의 현재 길이가 제1 메모리 위치에 저장된 파일의 길이를 초과하는 경우, 그 파일과 연관된 데이터 구조를 종점에서 시작하여 갱신한다(712).

도 8에서, 시스템에 의해 수행되는 절차(800)는 데이터 스트림으로부터의 데이터를 제1 파일과 버퍼에 동시에 추가하고(802), 미리 정해진 조건이 충족된 후 버퍼와 연관된 데이터를 압축 파일로 전환한다(804). 절차(800)는 버퍼로부터의 데이터를 압축 파일로 전환한 후, 데이터 스트림으로부터 데이터를 수신하기 위해 제2 파일을 생성한다(806). 시스템(100)의 모듈들 및 시스템(100)에 의해 수행되는 절차를 포함하는, 전술한 레코드 스토리지 및 검색 접근법은, 컴퓨터에서 실행하는 소프트웨어를 사용하여 구현될 수 있다. 예를 들면, 상기 소프트웨어는 하나 이상의 프로그램된 또는 프로그램 가능한 컴퓨터 시스템들(예를 들어, 분산형, 클라이언트/서버, 또는 그리드 등의 다양한 아키텍처일 수 있음)에서 실행하는 하나 이상의 컴퓨터 프로그램 내의 절차들을 구성하고, 상기 컴퓨터 시스템 각각은 적어도 하나의 프로세서, 적어도 하나의 데이터 스토리지 시스템(휘발성 및 비휘발성 메모리 및/또는 스토리지 소자를 포함함), 적어도 하나의 입력 디바이스나 포트, 그리고 적어도 하나의 출력 디바이스나 포트를 포함한다. 상기 소프트웨어는, 예를 들면, 계산 그래프(computation graph)의 설계 및 구성과 관련된 기타 서비스를 제공하는 규모가 더 큰 프로그램의 하나 이상의 모듈을 구성할 수 있다. 상기 그래프의 노드 및 요소는 컴퓨터로 판독 가능한 매체에 저장된 데이터 구조 또는 데이터 저장소에 저장된 데이터 모델을 따르는 다른 체계화된 데이터(organized data)로서 구현될 수 있다.

상기 소프트웨어는 범용 또는 전용(general or special purpuse)의 프로그램 가능한 컴퓨터에 의해 판독 가능한, CD-ROM 등의 저장 매체로 제공되거나, 또는 네트워크의 통신 매체를 통해 실행될 컴퓨터로 배포(전파 신호로 부호화됨)될 수 있다. 모든 기능은 전용 컴퓨터에서, 또는 코프로세서(coprocessor)와 같은 전용 하드웨어를 사용하여 수행될 수 있다. 상기 소프트웨어는 소프트웨어에 의해 특정된 계산의 상이한 부분들이 상이한 컴퓨터들에 의해 수행되는 분산 방식으로 구현될 수 있다. 이러한 컴퓨터 프로그램 각각은 범용 또는 전용의 프로그램 가능한 컴퓨터에 의해 판독 가능한 저장 매체 또는 디바이스(예컨대, 고체 메모리나 매체, 또는 자기 매체나 광 매체)에 저장되거나 다운로드되는 것이 바람직하며, 컴퓨터를 구성하고 동작시키기 위해, 상기 저장 매체 또는 디바이스는 컴퓨터 시스템에 의해 판독될 때 여기에 기재한 절차들를 수행한다. 본 발명의 시스템은 또한 컴퓨터 프로그램으로 구성된, 컴퓨터로 판독 가능한 저장 매체로서 구현되는 것으로 생각될 수도 있으며, 이렇게 구성된 저장 매체는 컴퓨터 시스템으로 하여금 특정한, 미리 정해진 방식으로 동작하여 여기에 기재한 기능들을 수행하도록 한다.

이상에서는 본 발명의 여러 실시예를 설명하였다. 그럼에도 불구하고, 본 발명의 사상과 범위를 벗어나지 않는 다양한 변경이 가능하다는 것을 알아야 한다. 예를 들면, 이상에서 설명한 단계들 중 일부는 순서에 독립적일 수 있고, 따라서 설명한 것과는 다른 순서로 수행될 수 있다.

이상의 설명은 예시를 위한 것이고 첨부된 청구항들의 범위에 정해지는 본 발명의 범위를 한정하기 위한 것이 아님을 알아야 한다. 예를 들면, 이상에서 설명한 많은 기능 단계들은 실질적으로 전체 처리에 영향을 주지 않는 상이한 순서로 수행될 수 있다. 다른 실시예들은 이하의 청구항들의 범위 내에 있다.

Claims

복수의 레코드를 포함하는 파일에 질의하기 위한 방법으로서,
비휘발성 저장 매체에 저장되는 파일에 추가될 하나 이상의 레코드에 대한 데이터를 수신하는 단계;
상기 파일 내의 레코드에 대한 질의를 수신하는 단계; 및
수신된 상기 데이터 중 적어도 일부를 상기 파일에 추가함과 동시에 상기 파일에 질의하는 단계를 포함하되, 상기 질의하는 단계는:
상기 파일의 길이를 결정하고, 제1 메모리 위치에 상기 파일의 길이를 저장하는 단계;
상기 파일 내의 마지막 완전한 레코드의 종점의 위치를 결정하고, 상기 종점의 위치를 나타내는 데이터를 제2 메모리 위치에 저장하는 단계; 및
상기 제1 메모리 위치에 저장된 상기 파일의 길이를 상기 파일의 현재 길이와 비교하는 단계; 및
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하는 경우, 상기 파일과는 별개인 데이터 구조로서의 인덱스를 갱신하는 단계로서, 상기 인덱스는 휘발성 저장 매체에 저장되고 상기 파일과 연관되며, 상기 갱신은 상기 종점의 위치를 나타내는 데이터에 따른 상기 인덱스에서의 위치에서 시작하고, 상기 인덱스는 상기 파일 내에서 적어도 하나의 레코드의 저장 위치를 식별하는데 이용될 수 있는 데이터를 포함하는, 갱신 단계
를 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 데이터 구조는 연관 데이터 구조인, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제2항에 있어서,
상기 데이터 구조는 이진 트리 또는 해시 테이블인, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 종점은 또한 상기 파일의 종점을 나타내는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 종점은 상기 파일 내의 불완전한 레코드에 선행하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 파일을 에러 검사하는 단계를 더 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제6항에 있어서,
상기 파일을 에러 검사하는 단계는, 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이보다 짧은지를 결정하는 단계를 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 파일은 비압축 데이터 파일인, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
디바이스 신호로부터 값을 취득하고 복수의 레코드를 포함하는 파일에 질의하는데 사용되는 실행 가능한 명령어를 저장하는 컴퓨터로 판독 가능한 저장 매체로서,
상기 명령어는 컴퓨터로 하여금,
비휘발성 저장 매체에 저장되는 파일에 추가될 하나 이상의 레코드에 대한 데이터를 수신하도록 하고;
상기 파일 내의 레코드에 대한 질의를 수신하도록 하며;
수신된 상기 데이터 중 적어도 일부를 상기 파일에 추가함과 동시에 상기 파일에 질의하도록 하되, 질의하는 것은:
상기 파일의 길이를 결정하고, 제1 메모리 위치에 상기 파일의 길이를 저장하는 것;
상기 파일 내의 마지막 완전한 레코드의 종점의 위치를 결정하고, 상기 종점의 위치를 나타내는 데이터를 제2 메모리 위치에 저장하는 것; 및
상기 제1 메모리 위치에 저장된 상기 파일의 길이를 상기 파일의 현재 길이와 비교하는 것;
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하는 경우, 상기 파일과는 별개인 데이터 구조로서의 인덱스를 갱신하는 것으로서, 상기 인덱스는 휘발성 저장 매체에 저장되고 상기 파일과 연관되며, 상기 갱신은 상기 종점의 위치를 나타내는 데이터에 따른 상기 인덱스에서의 위치에서 시작하고, 상기 인덱스는 상기 파일 내에서 적어도 하나의 레코드의 저장 위치를 식별하는데 이용될 수 있는 데이터를 포함하는, 인덱스 갱신을 포함하는,
컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 데이터 구조는 연관 데이터 구조인, 컴퓨터로 판독 가능한 저장 매체.
제21항에 있어서,
상기 데이터 구조는 이진 트리 또는 해시 테이블인, 컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 종점은 또한 상기 파일의 종점을 나타내는, 컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 종점은 상기 파일 내의 불완전한 레코드에 선행하는, 컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 명령어는, 상기 컴퓨터로 하여금 상기 파일의 에러 검사를 하도록 하는, 컴퓨터로 판독 가능한 저장 매체.
제25항에 있어서,
상기 파일의 에러 검사는, 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이보다 짧은지를 결정하는 것을 포함하는, 컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 파일은 비압축 데이터 파일인, 컴퓨터로 판독 가능한 저장 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
복수의 레코드를 포함하는 파일에 질의하기 위한 시스템으로서,
비휘발성 저장 매체에 저장되는 파일에 추가될 하나 이상의 레코드에 대한 데이터, 및 상기 파일 내의 레코드에 대한 질의를 수신하기 위한 수단; 및
수신된 상기 데이터 중 적어도 일부를 상기 파일에 추가함과 동시에 상기 파일에 질의하기 위한 수단을 포함하되, 질의하는 것은:
상기 파일의 길이를 결정하고, 제1 메모리 위치에 상기 파일의 길이를 저장하는 것;
상기 파일 내의 마지막 완전한 레코드의 종점의 위치를 결정하고, 상기 종점의 위치를 나타내는 데이터를 제2 메모리 위치에 저장하는 것;
상기 제1 메모리 위치에 저장된 상기 파일의 길이를 상기 파일의 현재 길이와 비교하는 것; 및
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하는 경우, 상기 파일과는 별개인 데이터 구조로서의 인덱스를 갱신하는 것으로서, 상기 인덱스는 휘발성 저장 매체에 저장되고 상기 파일과 연관되며, 상기 갱신은 상기 종점의 위치를 나타내는 데이터에 따른 상기 인덱스에서의 위치에서 시작하고, 상기 인덱스는 상기 파일 내에서 적어도 하나의 레코드의 저장 위치를 식별하는데 이용될 수 있는 데이터를 포함하는, 인덱스 갱신을 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
삭제
제1항에 있어서,
상기 파일의 길이는 상기 파일 내의 레코드들에 대한 질의의 수신에 대한 응답으로 결정되는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제41항에 있어서,
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하지 않는 경우, 상기 질의를 처리하는 단계를 더 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제41항에 있어서,
상기 데이터 구조가 갱신된 후 상기 질의를 처리하는 단계를 더 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 종점은 상기 파일 내의 마지막 완전한 레코드와 연관된 절대 어드레스(absolute address)인, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제1항에 있어서,
상기 종점은 상기 파일의 시작과 연관된 제1 어드레스와 상기 파일 내의 마지막 완전한 레코드와 연관된 제2 어드레스 사이의 오프셋을 나타내는 어드레스인, 복수의 레코드를 포함하는 파일에 질의하기 위한 방법.
제20항에 있어서,
상기 파일의 길이는 상기 파일 내의 레코드들에 대한 질의의 수신에 대한 응답으로 결정되는, 컴퓨터로 판독 가능한 저장 매체.
제46항에 있어서,
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하지 않는 경우, 상기 컴퓨터로 하여금 상기 질의를 처리하도록 하는 명령어를 더 포함하는, 컴퓨터로 판독 가능한 저장 매체.
제46항에 있어서,
상기 데이터 구조가 갱신된 후 컴퓨터로 하여금 상기 질의를 처리하도록 하는 명령어를 더 포함하는, 컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 종점은 상기 파일 내의 마지막 완전한 레코드와 연관된 절대 어드레스인, 컴퓨터로 판독 가능한 저장 매체.
제20항에 있어서,
상기 종점은 상기 파일의 시작과 연관된 제1 어드레스와 상기 파일 내의 마지막 완전한 레코드와 연관된 제2 어드레스 사이의 오프셋을 나타내는 어드레스인, 컴퓨터로 판독 가능한 저장 매체.
제39항에 있어서,
상기 데이터 구조는 연관 데이터 구조인, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제39항에 있어서,
상기 종점은 또한 상기 파일의 종점을 나타내는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제39항에 있어서,
상기 종점은 상기 파일 내의 불완전한 레코드에 선행하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제39항에 있어서,
상기 파일의 에러를 검사하는 수단을 더 포함하며,
상기 파일의 에러 검사는 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이보다 짧은지를 결정하는 것을 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제39항에 있어서,
상기 파일의 길이는 상기 파일 내의 레코드들에 대한 질의의 수신에 대한 응답으로 결정되는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제55항에 있어서,
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하지 않는 경우, 상기 질의를 처리하는 수단을 더 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제55항에 있어서,
상기 데이터 구조가 갱신된 후 상기 질의를 처리하는 수단을 더 포함하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제39항에 있어서,
상기 종점은 상기 파일 내의 마지막 완전한 레코드와 연관된 절대 어드레스인, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
제39항에 있어서,
상기 종점은 상기 파일의 시작과 연관된 제1 어드레스와 상기 파일 내의 마지막 완전한 레코드와 연관된 제2 어드레스 사이의 오프셋을 나타내는 어드레스인, 복수의 레코드를 포함하는 파일에 질의하기 위한 시스템.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템으로서,
비휘발성 저장 매체에 저장되는 파일에 추가될 하나 이상의 레코드에 대한 데이터, 및 상기 파일 내의 레코드에 대한 질의를 수신하도록 구성되는 입력 디바이스 또는 포트; 및
수신된 상기 데이터 중 적어도 일부를 상기 파일에 추가함과 동시에 상기 파일에 질의하도록 구성되는 적어도 하나의 프로세서를 포함하되, 질의하는 것은:
상기 파일의 길이를 결정하고, 제1 메모리 위치에 상기 파일의 길이를 저장하는 것;
상기 파일 내의 마지막 완전한 레코드의 종점의 위치를 결정하고, 상기 종점의 위치를 나타내는 데이터를 제2 메모리 위치에 저장하는 것; 및
상기 제1 메모리 위치에 저장된 상기 파일의 길이를 상기 파일의 현재 길이와 비교하는 것;
상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하는 경우, 상기 파일과는 별개인 데이터 구조로서의 인덱스를 갱신하는 것으로서, 상기 인덱스는 휘발성 저장 매체에 저장되고 상기 파일과 연관되며, 상기 갱신은 상기 종점의 위치를 나타내는 데이터에 따른 상기 인덱스에서의 위치에서 시작하고, 상기 인덱스는 상기 파일 내에서 적어도 하나의 레코드의 저장 위치를 식별하는데 이용될 수 있는 데이터를 포함하는, 인덱스 갱신을 포함하는,
복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 데이터 구조는 연관 데이터 구조인, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 종점은 또한 상기 파일의 종점을 나타내는, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 종점은 상기 파일 내의 불완전한 레코드에 선행하는, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 프로세서는 또한, 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이보다 짧은지를 결정하는 것을 포함하는, 상기 파일의 에러 검사를 하도록 구성되는, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 파일의 길이는 상기 파일 내의 레코드들에 대한 질의의 수신에 대한 응답으로 결정되는, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제75항에 있어서,
상기 프로세서는 또한, 상기 파일의 현재 길이가 상기 제1 메모리 위치에 저장된 상기 파일의 길이를 초과하지 않는 경우, 상기 질의를 처리하도록 구성되는, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제75항에 있어서,
상기 프로세서는 또한, 상기 데이터 구조가 갱신된 후 상기 질의를 처리하도록 구성되는, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 종점은 상기 파일 내의 마지막 완전한 레코드와 연관된 절대 어드레스인, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
제70항에 있어서,
상기 종점은 상기 파일의 시작과 연관된 제1 어드레스와 상기 파일 내의 마지막 완전한 레코드와 연관된 제2 어드레스 사이의 오프셋을 나타내는 어드레스인, 복수의 레코드를 포함하는 파일에 질의하기 위한 컴퓨팅 시스템.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제