KR20140058542A - 범위-기반 검색을 위한 데이터 저장 관리 - Google Patents

범위-기반 검색을 위한 데이터 저장 관리 Download PDF

Info

Publication number
KR20140058542A
KR20140058542A KR1020147002955A KR20147002955A KR20140058542A KR 20140058542 A KR20140058542 A KR 20140058542A KR 1020147002955 A KR1020147002955 A KR 1020147002955A KR 20147002955 A KR20147002955 A KR 20147002955A KR 20140058542 A KR20140058542 A KR 20140058542A
Authority
KR
South Korea
Prior art keywords
record
file
value
time
numerical
Prior art date
Application number
KR1020147002955A
Other languages
English (en)
Other versions
KR102005831B1 (ko
Inventor
크레이그 더블유. 스탠필
Original Assignee
아브 이니티오 테크놀로지 엘엘시
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아브 이니티오 테크놀로지 엘엘시 filed Critical 아브 이니티오 테크놀로지 엘엘시
Publication of KR20140058542A publication Critical patent/KR20140058542A/ko
Application granted granted Critical
Publication of KR102005831B1 publication Critical patent/KR102005831B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2458Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2477Temporal data queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/211Schema design and management
    • G06F16/213Schema design and management with details for schema evolution support
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2315Optimistic concurrency control
    • G06F16/2322Optimistic concurrency control using timestamps
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2458Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2474Sequence data queries, e.g. querying versioned data

Abstract

일반적으로 데이터 구조에 저장된 레코드의 수치 속성의 값이 수신된다. 수치 속성의 값을 포함하는 수치 범위가 생성된다. 데이터 구조 내의 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리가 데이터 구조와 연관된 인덱스에 저장된다. 제1 인덱스 키는 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 제2 인덱스 키는 생성된 수치 범위에 대응한다.

Description

범위-기반 검색을 위한 데이터 저장 관리 {MANAGING STORAGE OF DATA FOR RANGE-BASED SEARCHING}
본원은 2011년 7월 8일자로 출원된 미국출원번호 제61/505,760호에 대한 우선권을 주장하는 바이며, 출원에 개시된 내용은 그 전체로 원용에 의해 본원에 포함된다.
본 발명은 범위-기반 검색을 위한 데이터 저장 관리에 관한 것이다.
데이터베이스 시스템은 임의의 다양한 포맷으로 데이터 또는 "레코드"의 접근가능한 유닛을 개별적으로 저장할 수 있다. 각 레코드는 신용 카드 거래와 같은 논리적 독립체에 대응할 수 있고, 레코드를 고유하게 식별하도록 허용되는 연관 주요 키를 가질 수도 있다.
레코드는 레코드 포맷의 각 분야와 연관된 다수의 값을 포함할 수 있다. 레코드는 하나 이상의 파일(예컨대, 플랫 파일 또는 XML 파일과 같은 구조적 데이터 파일) 내에 저장될 수 있다. 압축된 데이터베이스 시스템 내에서, 개별의 레코드 또는 레코드 내의 값은, 저장되는 경우 압축될 수 있고 시스템의 저장 요건을 감소시키도록 접근하는 경우 압축 해제될 수 있다.
일 양상에서, 일반적으로, 데이터 구조에 저장된 레코드의 수치 속성(numerical attribute)의 값이 수신된다. 수치 범위는 수치 속성의 값을 포함하는 것으로 생성된다. 엔트리가, 데이터 구조 내에 레코드의 위치를 특정하고 제1 인덱스 키 및 제2 인덱스 키를 포함하는, 데이터 구조와 연관된 인덱스에 저장된다. 제1 인덱스 키는 수치 속성과 상이한 레코드의 속성의 값에 대응하며, 제2 인덱스 키는 생성된 수치 범위에 대응한다.
하나 이상의 다음의 특징을 포함하는 양상이 존재한다.
수치 속성의 값이 타임 스탬프(time stamp)에 의해 표현되고, 수치 범위는 시간의 범위를 정의한다.
수치 범위를 생성하는 단계는 미리결정된 포인트로부터 시간 내에 타임 스탬프에 대응하는 시간을 분리시키는 시간 유닛에 제1 값을 결정하는 단계를 포함한다.
수치 범위는 미리결정된 시간 기간의 시간 범위이며, 수치 범위를 생성하는 단계는 미리결정된 시간 기간으로 제1 값을 나누어서 수치 범위를 나타내는 몫(quotient)을 제공하는 단계를 포함한다.
엔트리는, 데이터 구조 내에서,제1 인덱스 키와 제2 인덱스 키에 연관되는 제2 레코드의 위치를 더 특정한다.
제1 레코드 및 제2 레코드는 상이한 시간 스탬프에 의해 표현되는 수치 속성의 값을 포함한다.
질의(query)가 수신되어 제1 인덱스 키와 연관되고 제1 시간과 제2 시간 사이의 시간에 연관되는 레코드의 회수(retrieval)를 요구한다.
각각의 수치 범위가 제1 시간 및 제2 시간에 대해 생성된다.
각각의 수치 범위를 생성하는 단계는 제2 미리결정된 포인트로부터 시간 내에 제1 시간을 분리시키는 시간 유닛 내에 제2 값을 결정하는 단계, 및 제2 미리결정된 포인트로부터 시간 내에 제2 시간을 분리시키는 시간 유닛에 제3 값을 결정하는 단계를 포함한다.
각각의 수치 범위를 생성하는 단계는 미리결정된 시간 기간으로 제2 값을 나누어서 제1 시간에 대한 수치 범위를 나타내는 몫을 제공하는 단계, 및 미리결정된 시간 기간으로 제3 값을 나누어서 제2 시간에 대한 수치 범위를 나타내는 몫을 제공하는 단계를 포함한다.
엔트리는 제1 인덱스 키를 포함하고 제1 시간에 대한 수치 범위 또는 제2 시간에 대한 수치 범위와 동일하거나 제1 시간과 제2 시간에 대한 각 수치 범위 사이에 있는 수치 범위에 대응하는 제2 인덱스 키를 포함하는 인덱스 내에서 식별된다.
또 다른 일반적 양상에서, 컴퓨터-판독가능 저장 매체가 컴퓨팅 시스템으로 하여금 데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하고 수치 속성의 값을 포함하는 수치 범위를 생성하도록 하는 명령어를 포함하는 컴퓨터 프로그램을 저장한다. 이 명령어는 또한 컴퓨팅 시스템으로 하여금, 데이터 구조와 연관된 인덱스에, 데이터 구조 내의 레코드의 위치를 특정하고, 제1 인덱스 키 및 제2 인덱스 키를 포함하는 엔트리를 저장하도록 하며, 제1 인덱스 키는 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 제2 인덱스 키는 생성된 수치 범위에 대응한다.
추가의 일반적 양상에서, 컴퓨팅 시스템은 데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하도록 구성된 입력 디바이스 또는 포트를 포함한다. 컴퓨팅 시스템은, 수치 속성의 값을 포함하는 수치 범위를 생성하고; 데이터 구조 내에 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리를, 데이터 구조와 연관된 인덱스에 저장하도록 구성된 하나 이상의 프로세서를 추가로 포함하며, 제1 인덱스 키는 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 제2 인덱스 키는 생성된 수치 범위에 대응한다.
또 다른 일반적 양상에서, 컴퓨팅 시스템은 데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하는 수단; 및 레코드를 인덱싱하는 수단을 포함한다. 인덱싱하는 것은 수치 속성의 값을 포함하는 수치 범위를 생성하고; 데이터 구조 내에 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리를, 데이터 구조와 연관된 인덱스에 저장하는 것을 포함하며, 제1 인덱스 키는 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 제2 인덱스 키는 생성된 수치 범위에 대응한다.
하나 이상의 다음의 장점을 포함하는 양상들이 존재한다.
데이터의 저장 및 인덱싱을 관리하는 기술은 압축해제되어야 하고(레코드가 압축된 경우에), 메모리에 로딩되어야 하고, 및/또는 주어진 질의에 부합하지 않는 경우 폐기하여야 하는 레코드의 양을 감소시킬 수 있다. 일부 실시예에서, 레코드는 수치 속성, 예컨대 시간에 따라 그룹 내에 저장된다(예를 들어, 레코드가 전화 호출(telephone call)에 대응하는 경우, 주어진 호출이 있었던 시간에 기초하여 하루 동안 호출을 나타내는 데이터 파일에 상기 레코드가 저장될 수 있음). 인덱스는 각각의 데이터 파일 내에 각 레코드의 위치를 식별하는 레코드의 각 저장된 그룹에 대해 제공될 수 있다.
일부 실시예에서, 질의에서 특정된 파라미터를 매칭하는 하나 이상의 레코드의 위치를 추적하는 것이 바람직할 수 있다. 그러나, 질의에서 특정된 파라미터 중 하나가 시간의 범위에 관련이 있다면, 시간 기간이 비교적 짧은 경우라 할지라도, 일부 시스템은 전체 하루를 나타내는 데이터 파일이 압축해제되고(데이터 파일이 압축된 경우에), 메모리에 로딩되고, 파라미터와 매칭하도록 요구할 수 있다. 따라서, 본 명세서는 수치 범위(예를 들어, 시간의 범위, 때로는 시간 할당량(time quanta)을 포함하고, 더 작은 양의 레코드를 압축해제, 로딩 및 폐기하는 동안 질의에 잠재적으로 만족하는 레코드의 위치를 추적하기 위해 효율적으로 인덱스를 검색하도록 사용될 수 있는 인덱스에 엔트리를 제공하는 기술을 제안한다. 본 명세서에 기재된 다수의 기술은 새로운 인덱스를 생성하거나 존재하는 인덱스를 업데이트하도록 사용될 수 있다.
본 발명의 다른 특징 및 장점이 다음의 상세한 설명 및 특허청구범위로부터 명백해질 것이다.
본 발명은 범위-기반 검색을 위한 데이터 저장 관리를 제공한다.
도 1은 레코드를 저장하고 회수하는 시스템의 블록 다이어그램이다.
도 2a, 2b, 2c 및 2d는 시스템에 의해 처리되고 시스템에 저장되는 데이터의 도식화된 다이아그램이다.
도 3a 및 3b는 상이한 시그니처(signature) 크기에 대한 긍정 오류(false positive) 확률을 도시하는 표이다.
도 4a 및 4b는 레코드에 대한 검색을 위한 절차의 흐름도이다.
도 5는 레코드를 질의하기 위한 절차의 흐름도이다.
도 6a 및 6b는 첨부가능한 룩업 파일의 간략화된 다이어그램이다.
도 7은 첨부가능한 룩업 파일을 질의하기 위한 절차의 흐름도이다.
도 8은 데이터를 저장하기 위한 절차의 흐름도이다.
도 9는 레코드를 저장하고 회수하는 시스템의 블록 다이어그램이다.
도 10은 일실시예인 인덱스의 다이어그램이다.
도 11은 인덱스에 정보를 제공하기 위한 절차의 흐름도이다.
도 1을 참조하여, 레코드 저장 및 회수 시스템(100)은 하나 이상의 소스, 예컨대 소스 A - 소스 C로부터 데이터를 받아들인다. 데이터는, 데이터의 개별적으로 접근 가능한 유닛으로 표현될 수 있는 정보를 포함한다. 예를 들어, 신용카드 회사는 다양한 소매 업체로부터 개별의 거래를 나타내는 데이터를 수신할 수 있다. 각 거래는 고객 이름, 날짜, 구매 금액 등과 같은 속성을 나타내는 값과 연관된다. 레코드 처리 모듈(102)은 데이터가 미리결정된 레코드 포맷에 따라 포맷되어, 거래와 연관된 값이 레코드에 저장되는 것을 보장한다. 일부 경우에 레코드 포맷에 따라 소스로부터 데이터를 변환시키는 단계를 포함할 수 있다. 다른 경우에, 하나 이상의 소스가 레코드 포맷에 따라 이미 포맷된 데이터를 제공할 수 있다.
레코드 처리 모듈(102)은 저장된 레코드에 빨리 접근하는 것이 필요한지 아닌지 여부와 같은 다양한 인자에 따라 다양한 형태의 데이터 구조에 저장하기 위한 레코드를 준비한다. 첨부가능한 룩업 테이블에 빠른 접근성을 위한 레코드를 준비하는 경우, 처리 모듈(102)은, 이하에서 더욱 자세히 기술된 것처럼 첨부가능한 룩업 파일로 도달하여 인-메모리 인덱스를 유지하는, 레코드를 첨부한다. 압축 레코드 파일에 압축된 저장을 위한 레코드를 준비하는 경우, 처리 모듈(102)은 각 레코드를 식별하는 주요 키 값(예를 들어, 단일의 레코드를 식별하는 고유의 키, 또는 다수의 업데이트된 버전의 레코드를 식별하는 키)에 의해 레코드를 분류하며(sort), 상기 레코드를 주요 키 값의 겹치지 않는 범위에 대응하는 레코드의 세트들로 구분한다. 예를 들어, 레코드의 각 세트는 미리결정된 수의 레코드(예를 들어, 100 레코드)에 대응할 수 있다.
파일 관리 모듈(104)은 첨부가능한 룩업 파일(이들이 사용되는 상황인 경우) 및 압축된 룩업 파일 둘 다 관리한다. 압축 레코드 파일을 관리하는 경우, 파일 관리 모듈(104)은 레코드의 각 세트를 데이터의 압축된 블록으로 압축한다. 이렇게 압축된 블록은 레코드 저장소(106)(예를 들어, 하나 이상의 하드 디스크 드라이브와 같은 비-휘발성 저장 매체)에 압축 레코드 파일로 저장된다.
시스템(100)은 또한 압축 레코드 파일에 각각의 블록에 대한 엔트리를 포함하는 인덱스를 제공하는 인덱싱 및 검색 모듈(108)을 포함한다. 이하에서 더욱 자세히 기술되는 것처럼, 인덱스는 주어진 레코드를 포함할 수 있는 블록의 위치를 추적하도록 사용된다. 인덱스는 인덱스 저장소(110)에 있는 인덱스 파일에 저장될 수 있다. 예를 들어, 인덱스 파일이 압축 레코드 파일로서 동일한 저장 매체에 저장될 수 있는 반면, 인덱스 파일이 전형적으로 압축 레코드 파일보다 훨씬 더 작기 때문에, 바람직하게는 비교적 더 빠른 메모리(예를 들어, 동적 랜덤 액세스 메모리와 같은 휘발성 저장 매체)에 저장될 수 있다. 인덱스는 또한 인-메모리 데이터 구조로서 유지되는 동적 인덱스(114)일 수 있다. 동적 인덱스(114)의 일부 실시예는 해시 테이블, 이진 트리 및 b-트리이다. 이하에서 더욱 자세히 기술되는 것처럼, 인덱싱 및 검색 모듈(108)은 또한 첨부가능한 룩업 파일을 검색하기 위한 인터페이스를 제공한다.
상기 시스템(100)의 대안의 구현예에서, 레코드의 세트들이 일부 방법에서 레코드들을 결합하는 압축에 추가하여, 또는 압축 대신에 다른 기능을 사용하는 블록을 생성하도록 처리될 수 있다(즉, 블록이 단지 연결된 레코드의 세트가 아니도록). 예를 들어, 일부 시스템은 암호화 데이터의 블록을 생성하도록 레코드의 세트를 처리할 수 있다.
인터페이스 모듈(112)은 저장된 레코드로의 접근을 인간 및/또는 컴퓨터 에이전트, 예컨대 에이전트 A - 에이전트 D에게 제공한다. 예를 들어, 인터페이스 모듈(112)은 신용카드 고객이 그들의 거래를 모니터링하기 위해 온라인 계정 시스템을 구현할 수 있다. 다양한 기준을 만족하는 거래 정보에 대한 요구가 시스템(100)에 의해 처리될 수 있고, 대응하는 레코드가 레코드 저장소(106)에 저장된 압축된 블록 내로부터 회수될 수 있다.
하나 이상의 소스로부터 들어오는 레코드의 스트림이 압축 레코드 파일을 생성하도록 처리되기 전에 일시적으로 저장될 수 있다.
도 2a-2d, 3a-3b, 및 4a-4b는 압축 레코드 파일에서의 레코드 관리의 실시예를 도시하고 있다. 도 2a를 참조하면, 시스템(100)은 압축 레코드 파일(202)에 저장되는 레코드의 세트(200)를 수신하고, 주요 키의 값에 따라 레코드를 분류한다.
주요 키 값은 하나 이상의 레코드에 의해 나타날 수 있는 데이터베이스의 주어진 아이템을 고유하게 식별할 수 있다(예를 들어, 주어진 주요 키 값을 가진 각 레코드는 아이템의 상이한 업데이트 버전에 대응할 수 있음). 주요 키는 하나 이상의 존재하는 레코드의 필드에 대응하는 "자연 키(natural key)"일 수 있다. 각 아이템에 대해 고유하다고 보장되는 필드가 존재하지 않다면, 주요 키는 각 아이템에 대해 고유하다고 보장되거나 고유할 가능성이 높다는 레코드의 다수의 필드를 포함하는 복합 키(compound key)일 수 있다. 대안으로, 주요 키는 수신된 후에 각 레코드에 할당될 수 있는 "합성 키(synthetic key)"일 수 있다. 예를 들어, 시스템(100)은 연속하여 증가되는 정수와 같은 고유한 주요 키 값, 또는 일부 다른 순서로 단조적으로 진행되는 값(예를 들어, 타임 스탬프)을 할당할 수 있다. 이 경우에, 동일한 아이템의 상이한 버전을 나타내는 레코드가 상이한 합성 키 값으로 할당될 수 있다. 정수가 사용되는 경우, 가능한 주요 키 값의 범위(예를 들어, 사용되는 비트 수에 의해 결정되는 것처럼)가 충분히 커서 주요 키가 나가 떨어지는(roll over) 경우, 주어진 주요 키 값을 할당했던 임의의 이전 레코드가 압축 레코드 파일로부터 제거되어 진다. 예를 들어, 오래된 거래는 제거되어 보관되거나(archived) 폐기된다.
도 2a에 도시된 실시예에서, 레코드(200)가 알파벳순으로 분류된 주요 키 값: A, AB, CZ에 의해 식별된다. 시스템(100)은 주요 키 값 A - DD를 갖는 제1 세트의 N개 레코드를 압축하여, 블록 1로 표시된 대응하는 압축된 블록을 생성한다. 다음 세트의 레코드는 주요 키 값 DX - GF를 갖는 다음 N개의 분류된 레코드를 포함한다. 파일 관리 모듈(104)는 임의의 다양한 무손실 데이터 압축 알고리즘(예를 들어, 렘펠-지프 유형 알고리즘(Lempel-Ziv type algorithms))을 사용할 수 있다. 각각의 일련의 압축된 블록이 결합하여 압축 레코드 파일(202)을 형성한다.
압축된 블록을 생성하도록 사용되는 N개의 레코드가, 압축 효율성과 압축 해제 속도 사이의 트레이드 오프를 위해 선택될 수 있다. 압축은 압축되는 데이터의 본질(nature)과 압축되는 데이터의 크기에 따라 다른 주어진 인자 R에 의해 평균으로 데이터의 크기를 감소시킬 수 있다. 압축은 또한 평균 크기 O의 연관된 오버헤드(overhead)(예를 들어, 압축 관련 데이터)를 가질 수 있다. 각각 크기 XM개의 레코드로부터 생성되어 발생된 압축 레코드 파일의 평균 크기는 [M/N](RNX + O)로 표현될 수 있으며, 큰 수의 블록에 대해서는 RNX + OM/N에 근사할 수 있다. 그러므로, 더 큰 값의 N은 일부 경우에 R을 감소시킴으로써, 그리고 파일 크기에 대한 오버헤드의 부담을 감소시킴으로써 더 큰 압축을 제공한다. 더 작은 값의 N은 블록에 포함될 수 있는 레코드에 접근하기 위해 주어진 압축된 블록을 압축해제하는데 필요로 하는 시간을 감소시킨다.
다른 구현예에서, 상이한 압축된 블록들이 상이한 수의 레코드를 포함할 수 있다. 각 블록은 미리결정된 범위에 따라 다수의 레코드를 가질 수 있다. 예를 들어, 제1 블록은 주요 키 값 1 - 1000을 가진 레코드를 포함하며, 제2 블록은 주요 키 값 1001 - 2000를 가진 레코드를 포함하는 등이다. 이 실시예에서, 모든 주요 키 값이 필연적으로 존재하지는 않기 때문에(예를 들어, 자연 키로 사용된 존재하는 수치 필드의 경우), 압축된 블록 내의 레코드의 수는 상이할 수 있다.
일부 구현예에서, 일부 경우에 상이한 압축된 블록들이 타겟 수의 레코드를 포함할 수 있고, 예외 경우에 더 많은 또는 더 적은 수의 레코드를 포함할 수 있다. 예를 들어, 레코드의 세트가, 분류된 순서에서 다음의 레코드의 주요 키 값과 상이한 주요 키 값의 레코드로 끝난다면, 이 레코드는 압축된 블록을 생성하기 위해 사용된다. 레코드의 세트가, 분류된 순서에서 다음의 레코드의 주요 키 값과 동일한 주요 키 값의 레코드로 끝난다면, 그 주요 키 값을 가진 모든 추가의 레코드들이 그 세트에 추가된다. 이러한 방법으로, 동일한 주요 키 값이 하나의 압축된 블록으로부터 다음의 압축된 블록으로 교차되지(cross over) 않는다.
인덱싱 및 검색 모듈(108)이 압축된 블록의 각각을 위해 인덱스 파일(204) 내에 엔트리를 생성한다. 인덱스 엔트리는, 예를 들어, 대응하는 압축해제된 레코드의 세트 내의 제1 레코드의 주요 키에 의해, 각각의 압축된 블록을 식별하는 키 필드(206)을 포함한다. 엔트리는 또한 압축 레코드 파일(202) 내에서 식별된 압축된 블록의 저장 위치를 식별하는 위치 필드(208)를 포함한다. 예를 들어, 위치 필드는 레코드 저장소(106) 내의 절대 주소의 형태, 또는 레코드 저장소(106) 내의 압축 레코드 파일(202)의 시작의 주소로부터 오프셋의 형태인 포인터를 포함할 수 있다.
압축 레코드 파일(202) 내의 주어진 레코드를 검색하기 위해, 모듈(108)이 키 필드(206)를 기초로 하여 인덱스 파일(204)의 검색(예를 들어, 이진 검색)을 수행할 수 있다. 제공되는 키 값(예를 들어, 에이전트 중 하나에 의해 제공됨)을 위하여, 모듈(108)은 제공된 키 값을 포함하는 키 값의 범위에 대응하는 레코드를 포함하는 블록의 위치를 추적한다. 제공되는 키 값을 가진 레코드는 위치된 블록을 생성하도록 사용되는 레코드의 세트 내에 포함될 수도 있고 아닐 수도 있으나, 상기 레코드가 레코드들(200) 내에 존재한다면, 레코드들(200)이 주요 키 값에 의해 분류되었기 때문에 그 레코드는 포함될 것이다. 모듈(108)이 그 후 위치된 블록을 압축해제하고, 제공된 키 값을 가진 레코드를 검색한다. 주요 키 값이 각 레코드에 대해 고유하지 않은 경우에, 모듈(108)은 압축된 블록 내의 제공된 키 값을 가진 다수의 레코드를 찾을 수 있다. 키 필드(206)가 세트 내의 제1 레코드의 주요 키를 포함하는 실시예에서, 모듈(108)은 제공된 키 값보다 각각 더 빠르거나 더 느린 키 값을 가진 두 개의 연속의 인덱스 엔트리를 검색하며, 더 빠른 키 값을 가진 엔트리에 대응하는 블록을 돌려준다. 일부 경우에, 제공된 키 값은, 모듈(108)이 상기 엔트리에 대응하는 블록을 돌려주는 경우에 인덱스 엔트리의 키 값과 동일할 수 있다.
상이한 구현예에서, 인덱스 파일(204) 내의 엔트리가 대응하는 블록이 생성된 레코드에 대응하는 키 값의 범위를 식별하기 위한 상이한 방법이 존재한다. 도 2a에 도시된 구현예에서, 키 값의 범위가 블록을 생성하기 위해 사용되는 레코드의 키 값의 두 극값(extremum)(예를 들어, 알파벳순으로 분류된 일련의 주요 키 값에서 처음 및 마지막 값, 또는 수치적으로 분류된 일련의 주요 키 값에서 최소 및 최대값) 사이의 범위일 수 있다. 인덱스 엔트리는 상기 범위를 정의하는 극값 중 하나 또는 둘 다를 포함할 수 있다. 일부 구현예에서, 인덱스 엔트리가 주어진 블록에 대한 범위를 정의하는 최소 키 값을 포함한다면, 압축 레코드 파일 내의 마지막 블록과 연관된 마지막 인덱스 엔트리 역시 그 블록을 위한 범위를 정의하는 최대 키 값을 포함할 수 있다. 그 후 이 최대 키 값은 주어진 키 값이 범위 밖에 있을 때를 결정하기 위해 압축 레코드 파일을 검색하는 경우에 사용될 수 있다.
대안으로, 키 값의 범위는 블록을 생성하도록 사용되는 레코드의 키 값을 넘어 확대되는 범위일 수 있다. 예를 들어, 1 내지 1000의 수치적인 주요 키 값을 가진 레코드로부터 생성되는 블록의 경우에, 레코드에서 표현되는 가장 작은 키 값이 1보다 더 클 수도 있고, 레코드에서 표현되는 가장 큰 키 값이 1000보다 더 작을 수도 있다. 인덱스 엔트리는 범위를 정의하는 극값 1 및 1000 중 하나 또는 둘 다를 포함할 수 있다.
레코드의 초기 그룹이 압축 레코드 파일을 생성하기 위해 처리된 후에 추가 레코드가 도달하는 경우, 이 레코드는 버퍼에 저장될 수 있고, 압축해제된 형태로 검색될 수 있다. 대안으로, 레코드의 추가 그룹이 점증적으로 처리될 수 있고, 추가 인덱스 파일에 의해 접근 가능한 추가의 압축 레코드 파일로서 저장될 수 있다. 일부 경우에, 심지어 작은 수의 추가 레코드를 압축하는 단계가 저장 크기의 큰 감소를 제공할 수 없는 경우에, 레코드에 접근하기 위해 균일한 절차를 유지하도록 추가 레코드를 압축시키는 것이 여전히 유리할 것이다. 추가 레코드는 정기적인 간격의 시간(예를 들어, 매 30초 또는 매 5분)으로, 또는 미리결정된 수의 추가 레코드(매 1000 레코드들 또는 매 10,000 레코드)가 수신된 이후에, 반복하여 처리될 수 있다. 들어오는 레코드가 시간 간격에 기초하여 처리된다면, 일부 간격에서 단일의 압축된 블록으로 모두 압축되는 작은 수의 레코드 또는 들어오는 레코드가 존재하지 않을 수 있다.
도 2b를 참조하면, 초기의 압축 레코드 파일(202)이 생성되고 난 후에 추가 레코드가 시스템(100)에 의해 수신되었던 시스템에서, 추가의 압축 레코드 파일(210)이 복합(compound) 압축 레코드 파일(211)을 형성하기 위해 초기의 압축 레코드 파일(202)에 첨부될 수 있다. 시스템(100)은 주요 키 값에 의해 추가 레코드를 분류하고, 압축 레코드 파일(210)의 압축된 블록을 생성하기 위해 N개의 레코드의 세트를 압축한다. 블록 91이라고 하는 첨부된 파일(210)의 제1 압축 블록은 주요 키 값 BA - FF를 포함한다. 모듈(108)은 첨부된 파일(210) 내에 표현되는 추가 레코드를 검색하도록 사용될 수 있는 엔트리를 포함하는 추가 인덱스 파일(212)을 생성한다. 새로운 인덱스 파일(212)이 이전 인덱스 파일(204)에 첨부될 수 있다.
임의의 수의 압축 레코드 파일이 복합 압축 레코드 파일을 형성하도록 첨부될 수 있다. 인덱싱 및 검색 모듈(108)이 복합 압축 레코드 파일 내의 주어진 키 값을 가진 레코드를 검색하며, 상기 모듈(108)은 대응하는 인덱스 파일을 사용하여 첨부된 압축 레코드 파일의 각각 내에서 레코드를 검색한다. 대안으로, 주어진 레코드를 요청하는 에이전트가 검색되는 복합 압축 레코드 파일을 가진 압축 레코드 파일들의 일부의 수를 특정할 수 있다 (예를 들어, 가장 최근에 생성된 10개, 또는 마지막 시간에 생성된 임의의 수).
주어진 시간(예를 들어, 매 24 시간) 이후에, 또는 압축 레코드 파일의 주어진 수가 첨부되고 난 이후에, 시스템(100)은 복합 압축 레코드 파일로부터 단일 압축 레코드 파일 및 신규의 대응하는 인덱스 파일을 생성하기 위해 파일들을 통합할 수 있다. 통합 후에, 단일 인덱스가 주어진 레코드를 포함할 수 있는 압축 블록의 위치를 추적하도록 검색되어서 더 효율적인 레코드 접근을 가능하게 할 것이다. 통합 시간에서, 시스템(100)은 대응하는 분류된 레코드의 세트를 회복시키고, 주요 키 값에 의해 상기 레코드를 분류하고, 신규의 압축 레코드 파일 및 인덱스를 생성하기 위해 압축 레코드 파일을 압축해제한다. 회복된 레코드의 세트들의 각각이 이미 분류되기 때문에, 레코드는 분류된 레코드의 하나의 세트를 생성하기 위해 주요 키 값에 따라 이전에 분류된 리스트들을 병합함으로써 효율적으로 분류될 수 있다.
도 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개 레코드의 세트들로 나누어지는 새로 분류된 레코드의 세트를 형성하도록 간단히 연결될 수 있다.
연속의 정수 합성 주요 키 값을 사용하는 또 다른 장점은 레코드가 주요 키 값에 기초하여 분할될 경우에, 키 값들의 갭이 존재하지 않으므로 분할이 자동으로 균형 잡힐 수 있다는 것이다.
레코드를 업데이트하고 압축 레코드 파일에 존재할 수 있는 레코드의 임의의 이전 버전을 무효로 하도록 임의의 다양한 기술이 사용될 수 있다. 일부 경우에, 레코드는 제거되거나 개별적으로 업데이트될(예를 들어, 로그, 거래, 전화 호출) 필요가 없다. 이 경우에, 오래된 레코드는 제거되고 폐기되거나, 예컨대 압축 레코드 파일의 초기에서부터 미리결정된 수의 압축된 블록의 그룹에 보관된다. 일부 경우에, 전체의 압축 레코드 파일이 제거될 수 있다.
일부 경우에, 압축된 블록에 저장하기 위한 신규의 업데이트된 레코드를 추가함으로써 레코드의 하나 이상의 값이 업데이트되며, 이전에 수신된 버전의 레코드(동일한 주요 키 값을 가짐)는 상이한 압축된 블록에 저장되어 남겨진다. 그 후에 다수의 버전의 레코드가 존재할 것이며, 일부 기술은 유효한 버전의 레코드인지를 결정하기 위해 사용된다. 예를 들어, 임의의 압축 레코드 파일에 나타나는 마지막 버전(가장 최근에 수신된)은 유효한 버전으로 암시적으로 또는 명백하게 표시될 수 있고, 임의의 다른 버전은 무효이다. 이 경우에 주어진 주요 키를 가진 레코드에 대한 검색은 출현(appearance)의 순서로 주요 키에 의해 식별된 마지막 레코드의 발견을 포함할 수 있다. 대안으로, 임의의 이전 버전의 레코드가 유효하지 않다는 것을 나타내는 "무효화 레코드"를 기록함으로써 신규 버전의 레코드를 필연적으로 추가하지 않고 레코드가 무효화될 수 있다.
시스템(100)은 상이한 처리에 의해 레코드 저장소(106)에 저장된 압축 레코드 파일로의 접근을 중재한다. 임의의 다양한 동기화 기술이 하나 이상의 압축 레코드 파일 내의 압축된 블록으로의 접근을 중재하도록 사용될 수 있다. 시스템(100)은 파일을 변경하는 임의의 처리(예를 들어, 데이터를 첨부하거나 통합함으로써)가 서로 간섭하지 않을 것을 보장한다. 예를 들어, 통합이 일어나는 동안 신규의 레코드가 도달하는 경우, 시스템(100)은 통합 처리가 종료될 때까지 기다리거나, 압축된 블록을 생성하고 존재하는 압축 레코드 파일 그들을 첨부하기 전에 일시적으로 그들을 저장할 수 있다. 압축 레코드 파일로부터 판독되는 처리는 완전한 파일의 부분을 로딩할 수 있고, 변경 중일 수 있는 임의의 불완전한 부분을 무시할 수 있다.
시스템(100)은 주요 키를 제외하고 레코드의 속성에 기초하여 레코드에 대한 검색을 가능하게 하는 추가 데이터를 저장한다. 압축 레코드 파일에 대한 부수적 인덱스가 부수적 키로 지정되는 속성의 값에 기초하여 하나 이상의 주요 키 값을 제공하는 정보를 포함한다. 부수적 키로 지정된 각각의 속성은 대응하는 부수적 인덱스와 연관될 수 있다. 예를 들어, 각각의 부수적 인덱스는 연관된 부수적 키에 의해 분류된 로우(row)를 갖는 테이블로서 정리될(organized) 수 있다. 각 로우는 부수적 키 값 및 상기 부수적 키 값을 포함하는 레코드의 하나 이상의 주요 키 값을 포함한다. 따라서, 에이전트가 주어진 부수적 키 값을 포함하는 임의의 레코드에 대한 검색을 시작하는 경우, 시스템(100)은 레코드를 포함하는 압축된 블록에 대한 압축 레코드 파일의 인덱스를 검색하기 위해 사용되는 주요 키를 찾는다. 부수적 인덱스가 클 수 있으며(예를 들어, 레코드의 개수에 따라), 일부 경우에 압축 레코드 파일을 저장하는 저장 매체에 저장될 수 있다.
일부 경우에, 부수적 키로 지정된 속성의 값이 각 레코드에 대해 고유할 수 있다. 그러한 경우에, 부수적 키와 주요 키 사이의 일대일 대응이 존재하고, 간섭 모듈(112)은 마치 에이전트에 대한 주요 키인 것처럼 그 부수적 키 속성을 제시할 수 있다.
각 부수적 인덱스가 신규의 압축 레코드 파일이 복합 압축 레코드 파일에 첨부되는 식으로 업데이트될 수 있다. 대안으로, 부수적 키가 각 압축 레코드 파일에 대해 상이한 부수적 인덱스와 연관될 수 있고, 부수적 인덱스는 압축 레코드 파일이 통합될 때 단일의 부수적 인덱스로 통합될 수 있다.
스크리닝 데이터 구조가, 주어진 속성 값을 포함하는 레코드가 파일의 압축된 블록 내에 포함될 확률을 결정하기 위해 압축 레코드 파일과 연관될 수 있다. 예를 들어, 오버랩 암호화 서명(Overlap Encoded Signature, OES)을 스크리닝 데이터 구조로서 사용하는 것은 시스템(100)이 주어진 키 값(주요 키 또는 부수적 키)을 가진 레코드가 분명히 존재하지 않는다는 것("부정적" 결과), 또는 주어진 키 값을 가진 레코드가 존재할 확률이 있다는 것("긍정적" 결과)을 결정하는 것을 가능하게 한다. 긍정적 결과에 대하여, 시스템은 레코드를 회수하거나("확고하게 긍정적(confirmed positive)" 결과), 레코드가 존재하지 않는다고 결정하기("오류 긍정적(false positive)" 결과) 위해 적절한 압축된 블록에 접근한다. 부정적 결과에 대하여, 시스템은 존재하지 않는 레코드에 대한 압축된 블록을 압축해제하고 검색하는데 시간을 보내는 것을 필요로 하지 않고 에이전트에 부정적 결과를 줄 수 있다. 상기 OES의 크기는 긍정적 결과가 얼마나 자주 오류 긍정적인지에 영향을 주는데, OES의 크기가 클수록 일반적으로 적은 오류 긍정적 결과가 나타난다. 주어진 OES의 크기에 대하여, 개별의 가능한 키 값들이 적을수록 일반적으로 적은 오류 긍정적 결과가 나타난다.
스크리닝 데이터 구조의 다른 유형이 가능하다. 주어진 주요 또는 부수적 키에 대한 스크리닝 데이터 구조가 각각의 압축 레코드 파일을 위해 제공될 수 있다. 대안으로, 키에 대한 스크리닝 데이터 구조가 각각의 압축된 블록에 대해 제공될 수 있다.
도 3a 및 3b는 압축 레코드 파일에 표시된 다양한 수의 개별적 키 값(로우) 및 일실시예인 OES 스크리닝 데이터 구조의 다양한 크기(컬럼)를 위한 키 값에 대한 오류 긍정적 결과를 획득하기 위해 확률 값을 제공하는 테이블을 도시하고 있다. OES에 대하여, OES의 크기 및 개별적 키 값의 수에 따라서, 하나 이상의 키 값의 존재가 OES의 동일한 부분에 지시될 수 있어서, 상기 키 값들 중 다른 하나가 존재하는 경우, 상기 키 값들 중 하나에 대한 오류 긍정적 결과를 잠재적으로 초래한다. 이 실시예의 OES의 크기는 210 = 1024 비트(도 3a의 테이블)로부터 228 = 256 메가비트(도 3b의 테이블)까지 다양하다. 개별적 키 값의 개수는 100(도 3a의 테이블)부터 100,000,000(도 3b의 테이블)까지 다양하다. 두 테이블에서, 오른쪽 상단의 비어있는 셀은 0%에 대응하고, 왼쪽 상단의 비어있는 셀은 100%에 대응한다. 오류 긍정적 확률이 낮은 셀(예를 들어, 0에 가까움)에 있어서, 스크리닝 데이터 구조는 충분한 스크리닝을 제공하기 위해 필요한 것보다 더 클 수 있다. 오류 긍정적 확률이 상당한 셀(예를 들어, > 50%)에 있어서, 스크리닝 데이터 구조는 너무 작아서 충분한 스크리닝을 제공할 수 없을 수도 있다. 이 실시예는 키 값 당 4개의 해시 코드를 사용하여 OES를 생성하는 기술과 대응한다. OES 스크리닝 데이터 구조의 다른 실시예는 주어진 수의 개별적 키에 대한 오류 긍정적 확률들의 상이한 테이블을 야기할 수 있다.
압축 레코드 파일에 제시되는 개별적 키 값의 수가 알려져 있지 않기 때문에, 시스템(100)은 파일이 생성되는 레코드의 수에 기초하여 압축 레코드 파일을 위한 스크리닝 데이터 구조의 크기를 선택할 수 있다. 크기를 선택하는데 있어서, 오류 긍정적 확률을 줄이는 것과 스크리닝 데이터 구조를 저장하는데 필요로 하는 메모리 공간 사이의 균형(trade-off)이 존재한다. 이 균형에서 하나의 인자는 존재하지 않는 키 값을 검색할 가능성이다. 찾아볼 키 값의 대부분이 압축해제된 레코드에 존재할 개연성이 있다면, 스크리닝 데이터 구조가 전혀 필요하지 않을 것이다. 키 값이 발견되지 않을 상당한 확률이 존재한다면, 비교적 큰 스크리닝 데이터 구조에 대한 저장 공간을 할당하는 것은 상당한 시간을 아낄 것이다.
압축 레코드 파일과 연관된 스크리닝 데이터 구조의 크기는 상기 파일이 초기의 또는 통합된 대규모의 레코드 데이터베이스, 또는 더 큰 데이터베이스로 더 작은 업데이트에 대응하는지 여부에 달려 있을 수 있다. 각 업데이트에서 일반적으로 더 적은 개별적 키 값들이 존재하기 때문에, 비교적 작은 스크리닝 데이터 구조 크기가 규칙적인 업데이트 간격 동안 첨부되는 압축 레코드 파일을 위해 사용될 수 있다. 또한, 작은 크기는, 여러번 업데이트 한 후에 압축 레코드 파일의 수가 커지는 만큼 요구되는 저장 공간을 감소시킬 수 있다. 스크리닝 데이터 구조의 크기는 업데이트시 개별적 키 값 및/또는 레코드의 예상되는 수에 기초할 수 있고, 업데이트의 예상되는 수에 기초할 수 있다. 예를 들어, 업데이트된 파일이 24 시간 기간을 통해 매 오분마다 첨부된다면, 결국에는 288 압축 레코드 파일이 될 것이다. 하나 이상의 오류 긍정적 결과의 확률이 도 3a 및 3b의 테이블로부터의 적절한 값의 288배가 될 것이다(상이한 업데이트에 대한 결과가 독립적이라고 가정한다면). 통합 이후, 개별적 키 값의 수가 상당히 증가할 수 있으므로, 더 큰 스크리닝 데이터 구조가 통합된 압축 레코드 파일에 대해 적절할 것이다.
압축 레코드 파일은 주요 키에 대한, 그리고 각각의 부수적 키에 대한, 또는 상기 키의 일부 서브세트에 대한 스크리닝 데이터 구조를 가질 수 있다. 예를 들어, 시스템(100)은 주요 키에 대한 스크리닝 데이터 구조, 및 레코드를 검색하는데 가장 자주 사용되도록 기대되는 오직 부수적 키에 대한 스크리닝 데이터 구조를 제공할 수 있다.
도 4a는 주어진 주요 키 값으로 하나 이상의 레코드를 검색하기 위한 절차(400)에 대한 흐름도를 도시하고 있다. 절차(400)는 제1 압축 레코드 파일과 연관된 스크리닝 데이터 구조가 존재하는지 여부를 결정한다(402). 존재하는 경우에, 스크리닝 데이터 구조가 긍정적 결과 또는 부정적 결과를 획득하도록 상기 절차(400)가 처리된다(404). 주요 키 값이 스크리닝을 통과하지 않으면(부정적 결과), 그 후 절차(400)는 다음의 압축 레코드 파일에 대해 검사하고(406) 만약 존재한다면 그 파일 상에서 반복한다. 주어진 주요 키 값이 스크리닝을 통과한다면(긍정적 결과), 그 후 절차(400)는 주어진 주요 키 값으로 레코드를 포함할 수 있는 블록에 대한 인덱스를 검색한다(408). 스크리닝 데이터 구조가 압축 레코드 파일과 연관되지 않는다면, 그 후 절차(400)는 스크리닝을 수행하지 않고 인덱스를 검색한다(408).
인덱스를 검색(408)한 후에, 주어진 주요 키 값을 포함하는 키 값의 범위와 연관된 압축된 블록이 발견되면(410), 그 후 절차(400)는 인덱스 엔트리에 의해 식별된 위치에 있는 블록을 압축해제하고(412) 주어진 주요 키 값으로 하나 이상의 레코드에 대한 결과적인 레코드를 검색한다(414). 그 후 절차는 다음의 압축 레코드 파일에 대해 검사하고(416) 만약 존재한다면 그 파일 상에서 반복한다. 압축된 블록이 발견되지 않는다면(예를 들어, 주어진 주요 키 값이 첫 번째 블록에 있는 최대 키 값보다 작거나 마지막 블록에 있는 최대 키 값보다 크다면), 그 후 절차(400)는 다음의 압축 레코드 파일에 대해 검사하고(416) 만약 존재한다면 그 파일 상에서 반복한다.
도 4b는 주어진 부수적 키 값으로 하나 이상의 레코드를 검색하기 위한 절차(450)에 대한 흐름도를 도시하고 있다. 절차(450)는 제1 압축 레코드 파일과 연관된 스크리닝 데이터 구조가 존재하는지 여부를 결정한다(452). 존재하는 경우에, 스크리닝 데이터 구조가 긍정적 결과 또는 부정적 결과를 획득하도록 상기 절차(450)가 처리된다(454). 주어진 부수적 키 값이 스크리닝을 통과하지 않으면(부정적 결과), 그 후 절차(450)는 다음의 압축 레코드 파일에 대해 검사하고(456) 만약 존재한다면 그 파일 상에서 반복한다. 주어진 부수적 키 값이 스크리닝을 통과한다면(긍정적 결과), 그 후 절차(450)는 주어진 부수적 키 값을 포함하는 레코드에 대응하는 주요 키를 찾는다(458). 스크리닝 데이터 구조가 압축 레코드 파일과 연관되지 않는다면, 그 후 절차(450)는 스크리닝을 수행하지 않고 주요 키를 찾는다(458).
발견되는 각각의 주요 키에 대하여, 상기 절차(450)는 주어진 주요 키 값으로 레코드를 포함할 수 있는 블록에 대한 인덱스를 검색한다(460). 인덱스를 검색(460)한 후에, 주요 키 값을 포함하는 키 값의 범위와 연관된 압축된 블록이 발견되면(462), 그 후 절차(450)는 인덱스 엔트리에 의해 식별된 위치에 있는 블록을 압축해제하고(464) 주어진 주요 키 값으로 하나 이상의 레코드에 대한 결과적인 레코드를 검색한다(466). 그 후 절차는 다음의 압축 레코드 파일에 대해 검사하고(468) 만약 존재한다면 그 파일 상에서 반복한다. 압축된 블록이 발견되지 않는다면, 그 후 절차(450)는 다음의 압축 레코드 파일에 대해 검사하고(468) 만약 존재한다면 그 파일 상에서 반복한다.
주어진 주요 또는 부수적 키로 발견된 다수의 레코드는 출현 순서대로 절차(400) 또는 절차(450)에 의해 돌려 보내지거나, 일부 경우에는 레코드의 마지막 버전만이 돌려 보내진다.
파일 관리 모듈(104)은 또한 첨부가능한 룩업 파일을 사용하여 레코드의 저장 및 접근을 관리한다. 첨부가능한 룩업 파일을 사용하는 일 실시예에서, 시스템(100)은 대규모의 주요 데이터 세트(예를 들어, 수백 테라바이트의 주요 데이터를 포함)를 관리한다. 이 주요 데이터 세트는 하나의 또는 일련의 다수의 압축 레코드 파일(복합 압축 레코드 파일로 연결된)에 일반적으로 저장될 것이다. 그러나, 데이터가 도달한 후에 곧(1분 이내에) 알아볼 수 있도록 하는 것이 필요하다면, 압축 레코드 파일을 첨부가능한 룩업 파일로 보충하는 것이 유용할 수 있다. 첨부가능한 룩업 파일은 신규의 데이터가 도달하는 시간과 상기 데이터가 다양한 질의 처리를 할 수 있게 되는 시간 간의 잠복기를 줄일 수 있다. 예를 들어, 신규의 데이터는 파일에 데이터를 능동적으로 기록하는 또 다른 처리가 원인이 된다. 시스템(100)은 불완전할 수 있는 부분적인 첨부가능한 룩업 파일에의 접근을 관리할 수 있다. 일부 시스템에서, 질의 프로세스가 부분적인 파일과 마주친다면, 프로그램 오류가 야기될 수 있다. 이 프로그램 오류를 피하기 위하여, 일부의 시스템은 파일이 질의될 때마다 파일과 연관된 인덱스를 재로딩한다. 인덱스를 매 질의마다 재로딩하는 것이 일부 상황에서 비효율적일 수 있고, 주목할만한 양의 시스템 자원을 소비할 수도 있다.
일반적으로, 첨부가능한 룩업 파일은 파일의 말단에 부가된 부분적인 레코드에 잘 견디는 압축해제된 데이터 파일이다. 첨부가능한 룩업 파일은 불완전한 레코드를 인식할 수 있고, 질의된 파일이 불완전한 레코드를 포함하는 경우라도 질의 요청을 처리할 수 있다. 첨부가능한 룩업 파일은 압축 레코드 파일에 대해 위에서 기재한 것처럼 인덱스 파일의 유형을 가지지 않으나, 대신에 첨부가능한 룩업 파일은 비교적 빠른 작업 메모리(working memory)(예, 동적 랜덤 엑세스 메모리와 같은 휘발성 저장 매체)에 저장된 데이터 구조의 각 레코드의 위치를 매핑하는 "동적 인덱스"를 갖는다. 예를 들어, 이러한 동적 인덱스는 해시 테이블, 이진 트리, b-트리, 또는 또다른 유형의 연상 데이터 구조(associative data structure)일 수 있다.
도 5, 및 6a-6b는 첨부가능한 룩업 파일을 사용하여 레코드를 관리하는 실시예를 도시한다. 도 5는 첨부가능한 룩업 파일이 질의되는 프로세스의 일실시예이다. 첨부가능한 룩업 파일의 작동에 대한 프로세스의 흐름도(500)는 로드 프로세스(502) 및 질의 프로세스(504)를 포함한다. 파일이 로딩된(506)(예컨대 파일이 질의된 경우) 후에, 파일의 길이가 결정된다(508). 파일의 길이가 결정된(508) 후에, 결정된 길이가 메모리 위치, 예컨대 작업 메모리에 저장된다(510).
그 후 시스템은 파일 내에 마지막 완전한 레코드의 말미를 나타내는 위치인 "엔드포인트"를 결정한다(512). 일부 경우, 예컨대 신규의 데이터가 파일에 기록되지 않는 경우에, 엔드포인트는 파일의 말미를 간단히 나타낼 수 있다. 엔드포인트는 또한 신규의 데이터의 제1 세그먼트를 즉시 선행하는 위치를 나타낸다(도 6 참조). 엔드포인트가 결정되고(512) 난 후에, 그것은 메모리 위치, 예컨대 메인 메모리에 저장된다(514).
질의 프로세스(504) 동안, 시스템(100)은 질의를 처리할지(522) 또는 질의된 파일과 연관된 연상 데이터 구조를 업데이트할지(518) 결정한다. 이러한 결정을 위하여 시스템은 이전에 결정되어 메모리에 저장된 파일의 길이에 현재의 파일의 길이를 비교한다(516). 이 결정은 다수의 방법으로 이루어질 수 있다. 예를 들어, 시스템은 파일 메타데이터, 파일 헤더를 검사할 수 있고, 또는 신규의 라인 캐릭터에 대한 파일을 검색할 수 있다. 파일의 길이가 이전에-저장된 파일 길이를 초과하지 않는다면, 신규의 데이터가 데이터 파일의 말미에 추가되지 않으며, 질의가 처리된다(522). 현재의 파일 길이가 이전에-저장된 파일 길이를 초과한다면, 이전에-저장된 엔드포인트에서 시작하여 연상 데이터 구조가 업데이트된다(518). 이런 방식으로, 연상 데이터 구조는 재로딩하지 않고 업데이트될 수 있고, 또는 완전히 재건될 수 있다. 대신에, 메모리에 이미 로딩된 데이터는 로딩된 채로 남아있고, 신규의 데이터가 이전에-저장된 엔드포인트에 시작하여 첨부된다. 질의를 처리하기 전에, 파일 길이 및 엔드포인트가 또한 업데이트 된다(520). 오류 검사와 같은 다른 단계가 이 프로세스에서 수행될 수 있다. 예를 들어, 시스템이 현재의 파일 길이가 이전에-저장된 파일 길이보다 작다고 결정한다면, 오류가 표시될 수 있다.
도 6a 및 6b는 도 5의 단계 512에 의해 결정된 바와 같이 파일 내의 엔드포인트의 위치의 실시예이다. 도 6a에서, 첨부가능한 룩업 파일(600)은 완전한 레코드(602) 및 불완전한 레코드(604)를 포함한다. 이 경우에, 엔드포인트(606)는 첨부가능한 룩업 파일(600) 내의 마지막 완전한 레코드의 말미를 나타내는 위치이며, 불완전한 레코드(604)의 시작을 즉시 선행한다.
도 6b의 실시예에서, 첨부가능한 룩업 파일(650)은 전부 완전한 레코드(652)로 이루어진다. 이 경우에, 엔드포인트(654)는 첨부가능한 룩업 파일(650) 내의 마지막 완전한 레코드의 말미를 다시 나타낸다; 그러나, 엔드포인트(654)는 또한 파일의 말미를 표현한다.
데이터는 차례로 계속적으로 업데이트되는 첨부가능한 룩업 파일에 계속적으로 첨부될 수 있다. 결과적으로, 첨부가능한 룩업 파일은 점점 더 커지며, 부응하여 첨부가능한 룩업 파일을 로딩하는데 걸리는 시간도 커진다. 첨부가능한 룩업 파일이 다른 형태의 동적으로 로딩가능한 인덱스 파일과 결합되어, 첨부가능한 룩업 파일이 너무 커져서 원하는 기간의 시간동안 로딩될 수 없도록 할 수 있다.
일부 응용예에서, 질의가능 데이터 구조로 로딩되는 계속되는 스트림의 데이터는 고속의 속도로 도달하고, 도달한 후에 곧 데이터로의 접근이 요구될 수 있다. 데이터가 도달할때, 듀얼 프로세스에 의해 처리된다. 첫째로, 데이터가 복제되고, 첨부가능한 룩업 파일(파일 시스템에 즉시 보일 수 있고 접근가능함)과 제2 파일 또는 "버퍼"의 둘 다에 동시에 추가된다. 데이터는 미리정의된 조건이 만족될 때까지 첨부가능한 룩업 파일 및 버퍼의 둘 다에 계속하여 축척된다. 미리정의된 조건은 다수의 기준일 수 있다. 예를 들어, 미리정의된 기준은 시간 길이, 파일 크기, 데이터 양, 또는 데이터 내의 다수의 레코드일 수 있다.
미리정의된 조건이 만족된 후에, 버퍼에 축척되었던 데이터의 블록이 더 긴 장기저장(longer term storage)에 대한 압축 레코드 파일에 추가된다. 데이터가 압축 레코드 파일에 추가된 후에, 신규의 첨부가능한 룩업 파일이 생성되고 데이터 스트림으로부터 데이터를 수집하기 시작한다. 오래된 첨부가능한 룩업 파일은 완결되고, 압축 레코드 파일이 대응하는 데이터의 전부를 포함한 이후에, 제거된다.
데이터가 버퍼 및 첨부가능한 룩업 파일의 둘 다에 의해 수신되고, 버퍼 내의 데이터가 저장될 수 있다. 데이터의 분류가 상당한 양의 시간과 시스템 자원을 소비하기 때문에, 데이터가 더 빨리 압축 레코드 파일로 이동되도록 하기 위하여 가능한 일찍 분류 프로세스를 시작하는 것이 유리하다.
대안으로, 첨부가능한 룩업 파일이 버퍼로서 사용될 수 있다. 이 구현예에서, 데이터는 미리정의된 조건이 만족될 때까지 첨부가능한 룩업 파일에 축척된다. 그 후 첨부가능한 룩업 파일의 컨텐츠가 압축 레코드 파일에 추가되며, 동시에 오래된 첨부가능한 룩업 파일이 완결되고 신규의 첨부가능한 룩업 파일이 생성되어 데이터 스트림으로부터 데이터를 수집하기 시작한다. 또 다시, 압축 레코드 파일이 대응하는 데이터의 전부를 포함한 후에 오래된 첨부가능한 룩업 파일이 제거된다.
이 프로세스의 각 사이클 동안에, 압축 레코드 파일에 데이터를 동시에 추가하고, 첨부가능한 룩업 파일에 모든 데이터를 제어하는 것이 바람직하다. 그러나, 두 업데이트가 경합 조건(race condition)을 야기할 수 있기 때문에, 오래된 첨부가능한 룩업 파일은 삭제되었으나 압축 레코드 파일은 아직 그것의 데이트로 업데이트되지 않았던 중대한 윈도우가 존재할 수 있다. 이는 데이터의 일시적인 손실을 초래할 수 있다. 이를 방지하기 위하여, 오래된 첨부가능한 룩업 파일이 이 프로세스의 추가 사이클에 대해 유지될 수 있다. 인덱싱 및 검색 모듈(108)은 복제 데이터가 첨부가능한 룩업 파일 및 압축 레코드 파일 둘다에 존재할 수 있는 조건을 검출하도록 구성되고, 인덱싱 및 검색 모듈(108)은 이 조건 동안 질의가 완성된다면 상기 복제 데이터를 걸러낸다(filter out).
대안으로, 파일 관리 모듈(104)은 상태 정보를, 예컨대 상태 정보 파일(107)에 유지하여, 데이터 버퍼가 압축 룩업 파일에 기록되었거나 첨부가능한 룩업 파일의 콘텐츠가 압축 레코드 파일에 추가되었던 이후에 첨부가능한 룩업 파일의 은퇴를 조정할 수 있다. 상태 정보 파일(107)은 현재의 능동적 레코드 관련 데이터 구조를 식별한다. 예를 들어, 상태 정보 파일(107)은 현재 능동적인 모든 첨부가능한 룩업 파일을 함께 포함하는 다수의 블록 및 압축 데이터 파일의 전부를 식별한다. 인덱싱 및 검색 모듈(108)은 임의의 첨부가능한 룩업 파일, 압축 데이터 파일, 및 상태 정보 파일에 출현하지 않는 압축 데이터 파일 내의 블록을 무시할 수 있다. 신규의 첨부가능한 룩업 파일이 생성될 때, 그 다음은 파일 관리 모듈(104)에 의해 준수되는 프로토콜의 일실시예이다. 파일 관리 모듈(104)은 압축 데이터 파일에 신규의 데이터를 추가하고 신규의 첨부가능한 룩업 파일을 생성하며; 파일 관리 모듈(104)은 인덱싱 및 검색 모듈(108)에 의해 접근되는 것을 방지하기 위해 상태 정보 파일을 로킹하고(lock); 파일 관리 모듈은 압축 데이터 파일에 신규 데이터의 추가, 오래된 첨부가능한 룩업 파일의 제거 및 신규의 첨부가능한 룩업 파일의 생성을 반영하기 위해 상태 정보 파일을 업데이트하며; 파일 관리 모듈은 상태 정보 파일을 언로킹하여(unlock), 인덱싱 및 검색 모듈(108)에 의해 한번더 접근되도록 하며; 파일 관리 모듈(104)는 오래된 첨부가능한 룩업 파일을 제거한다.
인덱싱 및 검색 모듈(108)은 다음의 일실시예의 프로토콜을 따른다. 프로토콜은 파일 검색 모듈(104)이 상태 정보 파일을 업데이트하는 것을 방지하기 위하여 상태 정보 파일을 로킹하며; 상태 정보 파일에 식별된 압축 데이터 파일 및 첨부가능한 룩업 파일과 연관된 질의를 수행하며; 파일 관리 모듈(104)가 상태 정보 파일을 업데이트 하는 것을 한번 더 허용하도록 상태 정보 파일을 언로킹한다.
상태 정보 파일(107)은 디스크 또는 메모리에 저장될 수 있다. 이 프로토콜은 검색 모듈이, 오래된 첨부가능한 룩업 파일로부터 데이터의 통합 이전에 오래된 첨부가능한 룩업 파일과 압축 데이터 파일, 또는 신규의 첨부가능한 룩업 파일과 업데이트된 압축 데이터 파일을 볼 수 있을 것을 보장한다.
신규의 첨부가능한 룩업 파일과 오래된 첨부가능한 룩업 파일의 둘 다 동시에 존재할 때 질의가 완성되는 경우, 일 구현예에서, 시스템은 첨부가능한 룩업 파일이 현재 능동적임을 보기 위해 디렉토리에서 찾는다(예컨대, 신규의 첨부가능한 룩업 파일은 그것이 생성되고난 후에 어느 정도 지연될 때까지 능동적으로 될 수 없을 수도 있으므로, 신규의 첨부가능한 룩업 파일, 또는 오래된 첨부가능한 룩업 파일이 능동적일 수 있음). 대안으로, 시스템이 질의를 처리할 때, 먼저 가장 최근의 첨부가능한 룩업 파일에서 찾고, 그 후 오래된 첨부가능한 룩업 파일에서 찾는다. 질의된 데이터가 여전히 추적되지 않은 경우, 시스템은 압축 레코드 파일에서 찾는다.
도 7에서, 시스템(100)에 의해 수행된 절차(700)가 파일의 길이를 결정하고(702) 제1 메모리 위치의 파일의 길이를 저장한다(704). 절차(700)는 파일 내의 마지막 완전한 레코드의 엔드포인트를 결정하고(706) 제2 메모리 위치에 있는 엔드포인트를 저장한다(708). 상기 절차는 제1 메모리 위치에 저장된 파일의 길이를 파일의 현재 길이와 비교하고(710), 파일의 현재 길이가 제1 메모리 위치에 저장된 파일의 길이를 초과한다면 엔드포인트에서 시작되는 파일과 연관된 데이터 구조를 업데이트한다(712).
도 8에서, 시스템(100)에 의해 수행되는 절차(800)는 데이터 스트림으로부터 제1 파일로, 그리고 버퍼로 데이터를 동시에 추가하고(802), 미리정의된 조건이 만족된 후에, 버퍼와 연관된 데이터를 압축 파일로 이동시킨다(804). 절차(800)는 버퍼로부터의 데이터가 압축 파일로 이동되고 난 후에 데이터 스트림으로부터 데이터를 수신하기 위해 제2 파일을 생성한다(806).
도 9는 인터페이스(112), 레코드 처리 모듈(102), 파일 관리 모듈(104), 레코드 저장 모듈(106), 인덱싱 및 검색 모듈(108), 및 인덱스 저장 모듈(110)을 포함하는 레코드 저장 및 회수 시스템(902)을 포함하는 시스템(900)을 도시하고 있다. 일부 실시예에서, 레코드 저장 모듈(106)은 위에서 기재한 것 처럼 하나 이상의 압축 기술을 사용하여 다수의 레코드를 저장한다. 예를 들어, 레코드는 레코드의 수치 속성에 따라 그룹화될 수 있다(예를 들어, 각각의 레코드와 연관된 타임 스탬프를 기초로 한 발생의 동일한 날짜와 연관되는 레코드). 위에서 기재한 것처럼, 레코드의 각 그룹은 레코드를(예를 들어, 압축 레코드처럼) 저장하는 하나 이상의 데이터 파일, 및 데이터 파일 내의 각 레코드의 위치와 레코드의 속성(예를 들어, 레코드에 대한 주요 또는 부수적 키를 나타내는 속성)에 대응할 수 있는 하나 이상의 인덱스 키의 둘 다를 저장하는 인덱스의 둘 다와 연관될 수 있다. 레코드의 주어진 그룹에 대하여, 데이터 파일 및 데이터 파일과 연관된 하나 이상의 인덱스는 분리하여 저장될 수 있다. 예를 들어, 하나 이상의 인덱스는 인덱스 저장 모듈(110)에 저장될 수 있고, 데이터 파일은 레코드 저장 모듈(106)에 저장될 수 있다.
인덱싱 및 검색 모듈(108)에 있는 질의 처리 엔진(910)은 검색 질의(예를 들어, 인터페이스(112)를 통해 사용자로부터 수신받은 질의)를 처리하도록 구성된다. 일부 실시예에서, 질의 처리 엔진(910)에 의해 수신된 질의에 특정된 하나 이상의 레코드를 회수하기 위하여, 질의를 만족하는 레코드를 최대한 포함하는 임의의 데이터 파일이 압축해제되고, 메모리로 로딩된 그것의 레코드를 가지고, 질의의 명세에 대항하여 매칭되는 그것의 레코드를 가질 수 있다. 매칭하는 레코드는 추가의 처리 또는 (예를 들어, 인터페이스(112)로) 출력을 위해 식별될 수 있으나, 질의의 명세에 매칭하지 않는 레코드는 메모리로부터 간단히 제거될 수 있다. 상기의 실시예를 사용하여, 압축 레코드가 특정한 발생일에 대응하는 데이터 파일에 저장된다면, 레코드 저장 및 회수 시스템(902)은 하루의 한 시간과 연관된 모든 레코드(예를 들어, 2011년 6월 1일 1:00AM에서 2:00AM의 시간과 연관된 모든 레코드)의 회수를 요청하는 질의를 수신할 수 있다. 이 간략화된 실시예에서, 2011년 6월 1일의 날짜와 연관된 데이터 파일만이 검색될 수 있다; 그러나, 모든 데이터 파일이 압축해제되고, 메모리로 로딩되고, 1:00AM 내지 2:00AM의 시간 기간의 질의 명세에 대해 매칭되고 난 후에, 이 제한에 매칭되지 않도록 데이터 파일 내의 다수의 레코드가 결정될 수 있다. 그 결과로, 비-매칭 레코드를 압축해제, 로딩 및 검색하는 것이 낭비적인 작동으로 여겨질 것이다. 동일한 실시예인 데이터 파일 구조를 사용하는 것은, 예를 들어, 질의가 전체 년도에 대한 동일한 시간 기간과 연관된 모든 레코드의 회수를 요청하는 경우에, 한 시간 내의 레코드만 질의 용어와 관련있다 할지라도 365개 데이터 파일이 압축해제되고, 로딩되고, 검색되기 때문에, 문제가 발생할 수 있다.
일부 실시예에서, 시스템(900)은 레코드 저장 모듈(106) 내에 저장된 레코드가 위에서 기재한 기술보다 더 정확한 기술로 그 위치가 추적되고, 식별되고, 회수되도록 할 수 있다. 예를 들어, 인덱싱 및 검색 모듈(108)은 주어진 레코드와 연관된 수치 속성보다 범위가 더 조악하나(coarser), 전체 데이터 파일과 연관된 수치 속성 값의 기간(span)보다 범위가 정교한(finer), 수치 범위(예, 시간 기간)와의 연관을 포함하는 엔트리를 포함하는 (또는 엔트리를 포함하는 존재하는 인덱스를 업데이트하는) 인덱스를 구성할 수 있다. 위의 실시예를 다시 참조하면, 레코드는 타임 스탬프를 각각 포함할 수 있다. 예를 들어, 레코드가 들어오는 전화 호출을 나타낸다면, 레코드는 호출된 전화 번호, 호출이 있는 곳의 전화 번호, 및 다른 정보 뿐만 아니라 호출이 수신된 때를 지시하는 타임 스탬프를 포함할 수 있다. 일부 실시예에서, 타임 스탬프는 시간, 분 및 초의 형태(예를 들어, HH:MM:SS 포맷)일 수 있다. 따라서, 주어진 데이터 파일이 하루(예, 2011년 6월 1일) 내의 타임 스탬프와 연관된 레코드를 포함할 수 있고, 데이터 파일과 연관된 인덱스는 레코드의 하나 이상의 속성(예, 호출된 전화 번호) 뿐만 아니라, 데이터 파일 내의 각각의 레코드의 위치를 제공하는 엔트리를 포함할 수 있다. 인덱스 내의 엔트리는 또한 대응하는 레코드의 타임 스탬프가 속하는 수치 범위를 서술하는 정보(수치 속성이 시간인 경우 때때로 "시간 할당량"으로 지칭됨)를 각각 포함할 수 있다.
예를 들어, 타임 스탬프를 포함하는 레코드에 대한 수치 범위를 계산하기 위하여, 인덱싱 및 검색 모듈(108)과 연관된 수치 범위 처리 모듈(912)이 수치 범위를 제공하기 위해 타임 스탬프를 처리할 수 있다. 수치 범위는 원하는 수치 범위의 크기를 특정하는 수치 그래뉼(granule)(913)에 부분적으로 기초한다(예, 수치 속성이 시간인 경우 시간 듀레이션). 예를 들어, 수치 그래뉼(913)은 각 타임 스탬프에 제공되는 수치 범위가 하루의 10분을 포함할 것을 특정할 수 있다. 예를 들어, 레코드가 1:00:00 AM의 타임 스탬프를 포함하고, 수치 그래뉼(913)이 10분(600초)의 값을 특정한다면, 수치 범위가 계산될 수 있다. 일부 실시예에서, 타임 스탬프(1:00:00AM)가 계산의 일부로서 상이한 유닛으로 변환될 수 있다. 예를 들어, 특정 날짜의 1:00:00AM은 이전 날짜의 자정 이래로 지나갔던 다수의 타임 유닛에 의해 표현될 수 있다(예,1시간 또는 3600초).
일부 실시예에서, 타임 스탬프를 수치 범위가 시간 그래뉼과 연관된 동일한 시간 유닛으로 변환시킴으로서 수치 범위가 계산될 수 있다(예, 초). 수치 범위가 그 후, 예를 들어 아래와 같이 변환된 시간 스탬프(3600초)를 시간 그래뉼(600초)에 의해 나눔으로서 결정될 수 있다:
Figure pct00001
따라서, 위의 실시예에 있어서, 수치 키 처리 모듈(912)이 수치 그래뉼(913)에 기초하여 1:00:00AM 시간 스탬프를 갖는 레코드와의 연관에 대한 수치 범위를 결정할 수 있다. 일부 실시예에서, 수치 키 처리 모듈(912)은 나눗셈의 결과인 몫만 사용하고, 해결되지 않는 수치 범위 계산에서부터 정수 값까지의 나머지를 반올림 하거나(round off) 뺄 수 있다.
수치 범위가 주어진 레코드에 대해 수치 키 처리 모듈(912)에 의해 계산되고 난 이후에, 인덱싱 및 검색 모듈(108)이 수치 범위(916)를 포함하는 인덱스 저장소(110)로 엔트리(914)(또는 엔트리로의 업데이트)를 제공할 수 있다. 인덱스 저장소(110)는 그 후 하나 이상의 레코드 어드레스(918)에 의해 표현되는 레코드를 저장하는 데이터 파일과 연관된 하나 이상의 인덱스에 있는 엔트리(914)를 저장할 수 있다. 엔트리(914)는 또한 하나 이상의 레코드 어드레스(918) 뿐만 아니라 제1 키(906)(예컨대, 엔트리가 신규의 엔트리인 경우)를 포함할 수 있다. 일부 실시예에서, 하나 이상의 레코드 어드레스(918)는 수치 범위(916) 및 제1 키(906)와 연관되는 레코드를 포함하는 하나 이상의 위치(예를 들어, 레코드 저장 모듈(106)에 저장된 데이터 파일 내)를 식별한다
위에서 언급한 것처럼, 엔트리(914)는 하나 이상의 레코드 어드레스(918)를 포함할 수 있다. 예를 들어, 3개의 레코드(각각은 데이터 파일에 고유하게 저장됨)가 수치 범위(916)(예, 위에서 계산된 것처럼 수치 범위 6) 뿐만 아니라 제1 키(906)(예, 일반 전화 번호)와 연관되면, 레코드 어드레스(918)(예, 포인터일 수 있음)는 엔트리(914)에 합쳐지고 함께 저장될 수 있다. 단일 엔트리, 예컨대 엔트리(914)에 다수의 레코드 어드레스를 함께 저장하는 것은, 인덱스가 더 적은 엔트리를 저장하도록 함으로써 저장 공간을 보존할 수 있다.
도 10은 4개의 엔트리: 제1 엔트리(1002), 제2 엔트리(1003), 제3 엔트리(1004), 및 제4 엔트리(1005)를 포함하는 인덱스(1000)의 일실시예를 도시한다. 각각의 엔트리(1002-1005)는 제1 컬럼(1006)에 의해 표현되는 제1 키("값 키"라 함), 및 제2 컬럼(1008)에 의해 표현되는 제2 키("범위 키"라 함)를 포함한다. 이 실시예에서, 값 키는 전화 번호이고, 범위 키는 위에서 기재된 요형의 수치 범위이다; 즉, 이 실시예에서, 각 엔트리(1002-1005)는 호출되었던 전화 번호의 레코드, 및 호출의 시간과 연관되는 수치 범위를 표현한다. 인덱스(1000)는 값 키(1006)에 의해 먼저 분류되고 범위 키(1008)에 의해 두번째로 분류된다. 대안으로, 다른 실시예에서, 값 키는 범위 키를 통합하도록 수정될 수 있다(예를 들어, 범위 키의 값을 값 키의 값과 연결시킴으로써).
엔트리(1003)는 "전화 번호 1"의 값 키의 값, 및 2의 범위 키의 값(몫 2에 대응하는 수치 범위를 나타냄)을 포함한다. 이 경우에, 2의 수치 범위는 수치 그래뉼(예, 수치 그래뉼(913)) 및 하나 이상의 레코드와 연관된 타임 스탬프를 사용하여 위에서 도시된 방식으로 계산되는 시간 할당량(time quantum)을 표현한다.
엔트리(1003)는 또한 하나 이상의 레코드 어드레스와 연관되는 엔트리의 실시예이다. 예를 들어, 엔트리(1003)는 3 개의 어드레스(어드레스 1(1012), 어드레스 4(1013), 및 어드레스 5(1014))와 연관된다. 각각의 어드레스(1012-1014)는 레코드 저장 모듈(106)에 저장된 하나 이상의 데이터 파일(1010) 내의 위치를 가리킨다. 인덱스 내의 키처럼 시간 할당량과 같은 수치 범위를 저장하는 것은 단일 엔트리 내의 레코드 어드레스의 집합 또는 그룹화를 용이하게 한다. 예를 들어, 타임 스탬프가 32 비트 캐릭터 스트링에 의해 표현될 수 있는 반면에, 수치 범위 예컨대 시간 할당량은 8 비트 스트링에 의해 표현될 수 있는데, 이는 시간 할당량이, 타임 스탬프의 해결에 따라서, 시, 분, 초 및 초의 분할의 조합 대신에 하나의 정수에 의해 표현될 수 있기 때문이다. 게다가, 수치 범위 예컨대 시간 할당량은 예를 들어 타임 스탬프보다 조악한 입상도(granularity)를 가질 수 있기 때문에, 주어진 수치 범위가 다수의 레코드를 포함할 개연성이 높을 것이다. 예를 들어, 수치 범위가 두 시간의 시간 기간을 나타낸다면, 타임 스탬프는 더 정교할 수 있기 때문에(따라서, 더 고유할 개연성이 높음), 더 많은 레코드가 일반 타임 스탬프보다 일반 두 시간 기간과 연관될 개연성이 있다. 어드레스(1012-1014)는 인덱스(1000)에 있는 대응하는 엔트리에 의해 역시 표현될 수 있는데, 단일의 엔트리 아래에 그들을 합칠 필요가 없기 때문이다. 각각의 엔트리(1002-1005)와 연관된 레코드 어드레스는, 예를 들어, 각 컬럼이 엔트리와 연관된 하나 이상의 레코드 어드레스를 포함할 수 있는 인덱스(1000)와 연관된 하나 이상의 추가 컬럼 내에 저장될 수 있다.
이러한 기술을 사용하여 레코드를 저장하고 인덱싱하는 것은 특정 기준에 부합하는 레코드에 대한 질의가 더욱 효율적으로 처리되도록 할 수 있다. 예를 들어, 도 9를 다시 참조하면, 인덱싱 및 검색 모듈(108)은 인터페이스(112)로부터의 질의를 수신할 수 있다. 위의 실시예에서처럼, 질의는 하루의 1 시간과 연관된 모든 레코드(예, 2011년 6월 1일, 1:00AM 내지 2:00AM의 시간과 연관된 모든 레코드)의 회수를 요청할 수 있다. 질의는 매칭되는 제1 속성(값 키에 대응하는 속성)의 특정 값 및 매칭되는 제2 속성(범위 키에 대응되는 속성)의 범위 값을 특정하는 형태일 수 있다. 이 실시예에서, 제1 속성의 값은 호출된 전화 번호를 나타낼 수 있고, 제2 속성의 범위 값은 최소 시간 1:00AM 및 최대 시간 2:00AM으로 표현되는 시간 기간을 나타낼 수 있다.
레코드가 각각의 날짜에 의해 데이터 파일에 그룹화된다고 가정하면(예, 각 데이터 파일이 하루로부터 레코드를 저장함), 2011년 6월 1일의 날짜와 연관된 데이터 파일은 질의를 만족하는 모든 레코드 (뿐만 아니라 상기 질의를 만족하지 않을 수 있는 다수의 레코드)를 포함할 것이다. 그러나, 메모리로 전체 데이터 파일을 로딩하는 대신에, 인덱싱 및 검색 모듈(108)의 질의 처리 모듈(910)은 시간 할당량과 같은 수치 범위에 대하여 매칭될 수 있는 형태로 시간 기간을 변환할 수 있다. 예를 들어, 시간 기간을 표현하는 최소 시간 및 최대 시간 둘다 위에서 기재한 방식으로 각각의 수치 범위로 변환될 수 있다. 600초의 동일한 수치 그래뉼(913)이 사용된다고 가정하는 변환의 예는 아래처럼 표현된다:
Figure pct00002
따라서, 질의에 의해 특정되는 1:00AM 내지 2:00AM의 시간 기간은 각각 6과 12의 대응되는 수치 범위로 변환될 수 있다. 그 후 수정된 질의가 인덱스 저장소(110)의 레코드 상에서 수행될 수 있고, 따라서 인덱스(예, 인덱스(1000))는 제1 속성(예, 질의에서 특정되는 전화 번호)에 대응하는 키 값 및 제2 속성(예, 질의에서 특정되는 시간 기간으로부터 생성되는 수치 범위 6-12)에 대응하는 범위 키에 기초하여 검색될 수 있다. 주어진 데이터 파일과 연관된 인덱스는 각각의 시간 할당량에 대응하는 범위 키를 포함하기 때문에, 인덱싱 및 검색 모듈(108)은 주어진 데이터 내의 서브 세트의 레코드가 6 내지 12 사이의 시간 할당량과 연관되는 것을 결정할 수 있다(예컨대, 하나의 극값과 동일한 값을 넓게 포함하는 용어 "사이(between)"를 사용함). 그 결과로, 전체의 데이터 파일이 메모리로 로딩되고, 압축해제되고(데이터 파일이 압축 데이터 파일인 경우), 검색되는 것을 필요로 하지 않는다; 대신에, 6 내지 12 시간 할당량으로 연관된 것과 같은 인덱스 내의 식별된 레코드들만 압축해제되고(데이터 파일이 압축 데이터 파일인 경우), 메모리로 로딩되고, 검색된다. 각 시간 할당량이 원래의 질의로 특정된 시간 기간 밖이나 매칭되는 시간 할당량 내인 레코드를 포함할 수 있기 때문에, 질의를 만족하는 레코드가 압축해제되고 및/또는 메모리로 로딩되고 난 이후에, 인덱싱 및 검색 모듈(108)은 원래의 질의를 만족하지 않는 임의의 레코드를 식별하고 배제하기 위하여, 로딩된 레코드를 원래의 질의에 대하여 검사할 수 있다. 검사가 수행된 후에, 남아있는 레코드는 인터페이스(112)로부터 수신된 질의를 만족해야 하며, 그 결과의 레코드(또는 레코드의 리스트)는 예를 들어 인터페이스(112)를 통해 사용자에게 돌려보내질 수 있다.
도 11은 인덱스의 수치 범위를 저장하기 위한 프로세스(1100)을 도시한다. 프로세스(1100)는 신규의 인덱스를 형성하거나, 존재하는 인덱스에 신규의 엔트리를 형성하거나, 존재하는 인덱스 내의 엔트리를 업데이트 하도록 사용될 수 있다.
데이터 구조에 저장된 레코드와 연관된 수치 속성이 수신된다(1102). 예를 들어, 데이터 파일은 연관된 수치 속성, 예컨대 타임 스탬프를 갖는 레코드를 포함할 수 있고, 인덱싱 및 검색 모듈(108)은 타임 스탬프를 추출하기 위해 데이터 파일 및/또는 데이터 파일과 연관된 인덱스에 접근할 수 있다. 타임 스탬프는 수치 속성의 예시일 뿐이며, 수치 순서(ordering)(예, 하나 이상의 아이템의 선형 순서)를 포함할 수 있다.
수치 속성을 포함하는 수치 범위가 생성된다(1104). 예를 들어, 수치 범위는 위에서 기재된 방식으로 계산될 수 있다. 예를 들어, 시간의 미리결정된 포인트(예, 주어진 날의 자정)로부터 타임 스탬프에 의해 나타내는 시간을 분리시키는 시간 유닛으로 표현되는 값이, 타임 스탬프를 수치 범위의 결정을 위해 사용될 수 있는 다량의 시간 유닛으로 변환하기 위하여 결정될 수 있다. 시간 유닛은 그 후 수치 그래뉼(예, 시간 그래뉼)로 나누어져서 수치 범위를 제공할 수 있다. 일부 실시예에서, 시간 그래뉼과 같은 수치 그래뉼이 사용자에 의해 특정되고, 임의의 크기(예, 10분 또는 6개월)가 될 수 있다.
데이터 구조 내의 레코드의 위치를 특정하고 값 인덱스 키와 범위 인덱스 키를 포함하는 엔트리가 데이터 구조와 연관된 인덱스에 저장되며, 범위 인덱스 키 값은 수치 범위(1106)와 연관된다. 예를 들어, 엔트리가 값 키와 범위 키의 둘 다를 포함하는 인덱스(예, 도 10의 인덱스(1000))에 제공될 수 있다. 일부 실시예에서, 범위 키와 연관된 수치 범위는 시간 할당량이다.
상기 시스템의 모듈과 상기 시스템에 의해 수행되는 절차를 포함하는, 위에서 기재된 레코드 저장 및 회수 접근법은 컴퓨터에서 실행하기 위한 소프트웨어를 사용하여 구현될 수 있다. 예를 들어, 소프트웨어는 하나 이상의 프로그램되거나 프로그램형 컴퓨터 시스템(분배, 클라이언트/서버, 또는 그리드와 같은 다양한 아키텍처일 수 있음) 상에서 실행되는 하나 이상의 컴퓨터 프로그램의 절차를 형성하며, 각 컴퓨터 시스템은 하나 이상의 프로세서, 하나 이상의 데이터 저장 시스템(휘발성 및 비-휘발성 메모리 및/또는 저장 요소를 포함함), 하나 이상의 입력 디바이스 또는 포트, 및 하나 이상의 출력 디바이스 또는 포트를 포함한다. 소프트웨어는 더욱 대규모 프로그램, 예를 들어 산출 그래프의 설계 및 구성과 관련된 다른 서비스를 제공하는 프로그램의 하나 이상의 모듈을 형성할 수 있다. 그래프의 노드와 요소는 컴퓨터 판독가능 매체에 저장된 데이터 구조 또는 데이터 리포지터리(data repository)에 저장된 데이터 모델에 따르는 다른 조직화 데이터로서 구현될 수 있다.
소프트웨어는 CD-ROM과 같은 일반적 또는 특정 목적 프로그램형 컴퓨터에 의해 판독가능사거나 실행되는 경우 네트워크의 통신 매체를 통해 컴퓨터에 전달하는(전파 신호로 인코딩되는) 저장 매체로 제공될 수 있다. 모든 기능이 특정 목적 컴퓨터 상에서, 또는 코프로세서와 같은 특정-목적 하드웨어를 사용하여 수행될 수 있다. 소프트웨어는, 소프트웨어에 의해 특정된 계산의 상이한 부분이 상이한 컴퓨터에 의해 수행되는 분배 방식으로 구현될 수 있다. 바람직하게는, 그러한 각 컴퓨터 프로그램은, 본 명세서에 기재된 절차를 수행하도록 저장 매체 또는 디바이스가 컴퓨터 시스템에 의해 판독되는 경우 컴퓨터를 구성하고 작동하기 위하여, 저장 매체 또는 일반적 또는 특정 목적 프로그램형 컴퓨터에 의해 판독가능한 디바이스(예, 고체형 메모리 또는 매체, 또는 자기 또는 광 매체) 상에 저장되거나 다운로드될 수 있다. 이러한 독창적인 시스템은 또한, 컴퓨터 프로그램으로 구성되는, 컴퓨터-판독가능 저장 매체로서 구현될 수 있다고 간주될 수 있을 것이며, 상기 저장 매체는 본 명세서에 기재된 기능을 수행하는 특정하고 미리정의된 방식으로 컴퓨터 시스템을 작동시키도록 구성된다.
본 발명의 다수의 실시예가 기재되었다. 그럼에도 불구하고, 본 발명의 의미 및 범위를 벗어나지 않고 다양한 변경이 가능함을 이해해야 할 것이다. 예를 들어, 위에서 기재된 단계 중 일부가 독자적으로 순서화될 수 있고, 따라서, 기재된 바와 상이한 순서로 수행될 수 있다.
기재된 상세한 설명은 본 발명의 범위를 도시하나, 본 발명의 범위를 제한하려는 의도는 아니며, 본 발명은 첨부된 청구항의 범위에 의해 정의됨을 이해해야 할 것이다. 예를 들어, 위에서 기재된 다수의 기능 단계는 전체 프로세스에 실질적으로 영향을 주지 않고 상이한 순서로 수행될 수 있다. 다른 구현예가 다음의 청구항의 범위 내에 있다.

Claims (14)

  1. 데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하는 단계;
    상기 수치 속성의 값을 포함하는 수치 범위를 생성하는 단계; 및
    상기 데이터 구조 내의 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리를 상기 데이터 구조와 연관된 인덱스에 저장하는 단계를 포함하며,
    상기 제1 인덱스 키는 상기 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 상기 제2 인덱스 키는 생성된 수치 범위에 대응하는, 방법.
  2. 제1항에 있어서,
    상기 수치 속성의 값은 타임 스탬프에 의해 표현되고, 상기 수치 범위는 시간의 범위를 정의하는, 방법.
  3. 제2항에 있어서,
    상기 수치 범위를 생성하는 단계는, 시간의 미리결정된 포인트로부터 상기 타임 스탬프에 대응하는 시간을 분리하는 시간 유닛의 제1 값을 결정하는 단계를 포함하는, 방법.
  4. 제3항에 있어서,
    상기 수치 범위는 미리결정된 시간 듀레이션의 시간 범위이고, 상기 수치 범위를 생성하는 단계는 상기 제1 값을 상기 미리결정된 시간 듀레이션으로 나누어서 상기 수치 범위를 표현하는 몫을 제공하는 단계를 포함하는, 방법.
  5. 제1항에 있어서,
    상기 엔트리는, 상기 데이터 구조 내에서, 상기 제1 인덱스 키와 상기 제2 인덱스 키와 연관되는 제2 레코드의 위치를 더 특정하는, 방법.
  6. 제5항에 있어서,
    상기 제1 레코드 및 상기 제2 레코드는 상이한 타임 스탬프에 의해 표현된 수치 속성의 값을 포함하는, 방법.
  7. 제5항에 있어서,
    상기 제1 인덱스 키와 연관되고 제1 시간과 제2 시간 사이의 시간과 연관되는 레코드들의 회수(retrieval)를 요청하는 질의를 수신하는 단계를 더 포함하는, 방법.
  8. 제7항에 있어서,
    상기 제1 시간과 상기 제2 시간에 대한 각각의 수치 범위를 생성하는 단계를 더 포함하는, 방법.
  9. 제8항에 있어서,
    상기 각각의 수치 범위를 생성하는 단계는,
    시간의 제2 미리결정된 포인트로부터 상기 제1 시간을 분리하는 시간 유닛의 제2 값을 결정하는 단계; 및
    시간의 제2 미리결정된 포인트로부터 상기 제2 시간을 분리하는 시간 유닛의 제3 값을 결정하는 단계를 포함하는, 방법.
  10. 제9항에 있어서,
    상기 각각의 수치 범위를 생성하는 단계는,
    상기 제2 값을 상기 미리결정된 시간 듀레이션으로 나누어서 상기 제1 시간에 대한 수치 범위를 표현하는 몫을 제공하는 단계; 및
    상기 제3 값을 상기 미리결정된 시간 듀레이션으로 나누어서 상기 제2 시간에 대한 수치 범위를 표현하는 몫을 제공하는 단계를 포함하는, 방법.
  11. 제10항에 있어서,
    상기 제1 인덱스 키를 포함하고, 제1 시간에 대한 수치 범위 또는 제2 시간에 대한 수치 범위와 동일하거나 상기 제1 시간과 상기 제2 시간에 대한 각각의 수치 범위 사이인 수치 범위에 대응하는 제2 인덱스 키를 포함하는 인덱스 내의 엔트리를 식별하는 단계를 더 포함하는, 방법.
  12. 컴퓨터 프로그램을 저장하는 컴퓨터-판독가능 저장 매체로서,
    상기 컴퓨터 프로그램은, 컴퓨팅 시스템으로 하여금,
    데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하고;
    상기 수치 속성의 값을 포함하는 수치 범위를 생성하고;
    상기 데이터 구조 내의 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리를 상기 데이터 구조와 연관된 인덱스에 저장하도록 하는 명령어를 포함하며,
    상기 제1 인덱스 키는 상기 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 상기 제2 인덱스 키는 생성된 수치 범위에 대응하는, 컴퓨터-판독가능 저장 매체.
  13. 컴퓨팅 시스템으로서,
    데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하도록 구성된 입력 디바이스 또는 포트; 및
    상기 수치 속성의 값을 포함하는 수치 범위를 생성하고,
    상기 데이터 구조 내의 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리를 상기 데이터 구조와 연관된 인덱스에 저장하도록 구성된 하나 이상의 프로세서
    를 포함하고,
    상기 제1 인덱스 키는 상기 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 상기 제2 인덱스 키는 생성된 수치 범위에 대응하는, 컴퓨팅 시스템.
  14. 컴퓨팅 시스템으로서,
    데이터 구조에 저장된 레코드의 수치 속성의 값을 수신하는 수단; 및
    상기 레코드를 인덱싱하는 수단
    을 포함하며,
    상기 인덱싱하는 것은, 상기 수치 속성의 값을 포함하는 수치 범위를 생성하고, 상기 데이터 구조 내의 레코드의 위치를 특정하고 제1 인덱스 키와 제2 인덱스 키를 포함하는 엔트리를 상기 데이터 구조와 연관된 인덱스에 저장하는 것을 포함하고,
    상기 제1 인덱스 키는 상기 수치 속성과 상이한 레코드의 속성의 값에 대응하고, 상기 제2 인덱스 키는 생성된 수치 범위에 대응하는, 컴퓨팅 시스템.
KR1020147002955A 2011-07-08 2012-07-06 범위-기반 검색을 위한 데이터 저장 관리 KR102005831B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201161505760P 2011-07-08 2011-07-08
US61/505,760 2011-07-08
PCT/US2012/045759 WO2013009622A1 (en) 2011-07-08 2012-07-06 Managing storage of data for range-based searching

Publications (2)

Publication Number Publication Date
KR20140058542A true KR20140058542A (ko) 2014-05-14
KR102005831B1 KR102005831B1 (ko) 2019-07-31

Family

ID=46583013

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147002955A KR102005831B1 (ko) 2011-07-08 2012-07-06 범위-기반 검색을 위한 데이터 저장 관리

Country Status (9)

Country Link
US (2) US20130013605A1 (ko)
EP (1) EP2729884B1 (ko)
JP (1) JP6088506B2 (ko)
KR (1) KR102005831B1 (ko)
CN (1) CN103733195B (ko)
AU (1) AU2012282870B2 (ko)
CA (1) CA2841084C (ko)
SG (1) SG10201608435SA (ko)
WO (1) WO2013009622A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170308561A1 (en) * 2016-04-21 2017-10-26 Linkedin Corporation Indexing and sequentially storing variable-length data to facilitate reverse reading

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7885932B2 (en) 2006-11-01 2011-02-08 Ab Initio Technology Llc Managing storage of individually accessible data units
CN102859517B (zh) * 2010-05-14 2016-07-06 株式会社日立制作所 时序数据管理装置、系统以及方法
US10671585B2 (en) * 2012-01-31 2020-06-02 Pure Storage, Inc. Storing indexed data to a dispersed storage network
AU2013366088B2 (en) * 2012-12-20 2019-06-06 Bae Systems Plc Searchable data archive
US20140236648A1 (en) * 2013-02-21 2014-08-21 Bank Of America Corporation Data Communication and Analytics Platform
US10097315B2 (en) * 2013-04-19 2018-10-09 Qualcomm Incorporated Group scheduling and acknowledgement for wireless transmission
US9710792B2 (en) * 2013-11-12 2017-07-18 International Business Machines Corporation Retrospective management of previously sent electronic messages
US10108649B2 (en) 2014-02-25 2018-10-23 Internatonal Business Machines Corporation Early exit from table scans of loosely ordered and/or grouped relations using nearly ordered maps
CN105205062B (zh) * 2014-06-13 2019-07-12 腾讯科技(北京)有限公司 数据存储方法、数据读取方法和装置
US9258117B1 (en) 2014-06-26 2016-02-09 Amazon Technologies, Inc. Mutual authentication with symmetric secrets and signatures
CN105335857A (zh) * 2014-08-08 2016-02-17 国家电网公司 数据查找方法及装置
US10142301B1 (en) * 2014-09-17 2018-11-27 Amazon Technologies, Inc. Encrypted data delivery without intervening decryption
CN104574222A (zh) * 2015-01-30 2015-04-29 国家电网公司 一种存储分布式光伏电站运行数据的方法
US10169395B2 (en) * 2015-02-12 2019-01-01 International Business Machines Corporation Database identifier generation in transaction processing systems
US9928281B2 (en) * 2015-03-20 2018-03-27 International Business Machines Corporation Lightweight table comparison
JP6241449B2 (ja) * 2015-05-21 2017-12-06 横河電機株式会社 データ管理システム及びデータ管理方法
EP3304954A4 (en) 2015-05-29 2018-08-08 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for client side encoding in a data processing system
US10122689B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Load balancing with handshake offload
US10122692B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Handshake offload
US20170147393A1 (en) * 2015-11-20 2017-05-25 Sap Se Cache-efficient system for two-phase processing
US10210236B2 (en) * 2015-11-23 2019-02-19 Ab Initio Technology Llc Storing and retrieving data of a data cube
KR101656750B1 (ko) * 2016-02-26 2016-09-23 주식회사 아미크 인덱스정보를 생성하는 데이터베이스의 아카이빙 방법 및 장치, 인덱스정보를 포함하는 아카이빙된 데이터베이스의 검색 방법 및 장치
US10437780B2 (en) * 2016-07-14 2019-10-08 Snowflake Inc. Data pruning based on metadata
US10936559B1 (en) * 2016-09-28 2021-03-02 Amazon Technologies, Inc. Strongly-consistent secondary index for a distributed data set
JP6781373B2 (ja) * 2016-10-05 2020-11-04 富士通株式会社 検索プログラム、検索方法、および検索装置
JP6717153B2 (ja) 2016-10-06 2020-07-01 富士通株式会社 インデックス生成プログラム、インデックス生成装置、インデックス生成方法、検索プログラム、検索装置および検索方法
US10180891B2 (en) 2016-11-02 2019-01-15 Sap Se Monitoring processes running on a platform as a service architecture
US10268566B2 (en) 2016-11-04 2019-04-23 Sap Se Debugging in a private cloud environment
CN108268503B (zh) * 2016-12-30 2020-06-16 华为技术有限公司 一种数据库的存储、查询方法及装置
US20200387498A1 (en) * 2017-04-24 2020-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for multi-version updating of data stored in a data storage system
US11940990B1 (en) 2017-06-16 2024-03-26 Amazon Technologies, Inc. Global clock values for consistent queries to replicated data
CN110019932A (zh) * 2017-10-31 2019-07-16 北京国双科技有限公司 数据处理的方法及装置
CN108829880B (zh) * 2018-06-27 2020-12-01 烽火通信科技股份有限公司 一种光网络终端设备的配置管理的方法
CN109345264B (zh) * 2018-08-21 2021-08-24 太原理工大学 一种基于区块链的酒类产品溯源防伪系统和方法
CN109783321B (zh) * 2019-01-24 2022-09-23 深圳市景阳信息技术有限公司 监控数据管理方法、装置、终端设备
US11188511B2 (en) * 2019-06-04 2021-11-30 Western Digital Technologies, Inc. Offloading file-indexing to memory card firmware
KR102529704B1 (ko) * 2020-08-27 2023-05-09 주식회사 아미크 인 메모리 데이터베이스의 데이터를 처리하는 방법 및 장치
US11250022B1 (en) 2020-09-29 2022-02-15 Amazon Technologies, Inc. Offline index builds for database tables
US11880385B1 (en) 2020-09-29 2024-01-23 Amazon Technologies, Inc. Ordering updates to secondary indexes using conditional operations
CN112965724A (zh) * 2021-03-22 2021-06-15 中国信息安全测评中心 一种固件的装载基址范围的确定方法及系统
US11914587B2 (en) * 2021-10-13 2024-02-27 Western Digital Technologies, Inc. Systems and methods for key-based indexing in storage devices
US11892992B2 (en) * 2022-01-31 2024-02-06 Salesforce, Inc. Unique identification management
CN116561073B (zh) * 2023-04-14 2023-12-19 云和恩墨(北京)信息技术有限公司 基于数据库的文件合并方法及系统、设备、存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040216091A1 (en) * 2003-04-24 2004-10-28 International Business Machines Corporation Method and apparatus for resolving memory allocation trace data in a computer system
US20060184563A1 (en) * 2005-02-14 2006-08-17 Potter David H Method and apparatus for temporal database
US20080235377A1 (en) * 2003-11-10 2008-09-25 Eath Co., Ltd. Aggregation system
US20090248645A1 (en) * 2008-03-28 2009-10-01 Brother Kogyo Kabushiki Kaisha Device, method and computer readable medium for management of time-series data

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4775932A (en) 1984-07-31 1988-10-04 Texas Instruments Incorporated Computer memory system with parallel garbage collection independent from an associated user processor
JPH0752450B2 (ja) 1986-08-01 1995-06-05 株式会社日立製作所 辞書デ−タ検索装置
JPH0823865B2 (ja) 1987-08-28 1996-03-06 株式会社日立製作所 デ−タ検索方法および装置
JPH05257774A (ja) 1992-03-10 1993-10-08 Fujitsu Ltd インデックス・レコード番号を圧縮・格納した情報検索装置
US5444853A (en) 1992-03-31 1995-08-22 Seiko Epson Corporation System and method for transferring data between a plurality of virtual FIFO's and a peripheral via a hardware FIFO and selectively updating control information associated with the virtual FIFO's
JPH07160557A (ja) 1993-12-13 1995-06-23 Hitachi Ltd データベースアクセス処理方法
JPH07287716A (ja) 1994-02-22 1995-10-31 Ricoh Co Ltd 辞書検索装置
JP3013221B2 (ja) 1994-07-11 2000-02-28 日本製粉マネジメントサービス株式会社 製麺用捏ね水の連続製造装置並びに連続製造の捏ね水を用いた製麺方法
JP3515810B2 (ja) 1994-08-16 2004-04-05 富士通株式会社 ソート処理方法および装置
JPH08255170A (ja) 1995-03-15 1996-10-01 Oki Electric Ind Co Ltd ソート付き検索処理装置
US5737593A (en) 1995-06-02 1998-04-07 International Business Machines Corporation System and method for defining shapes with which to mine time sequences in computerized databases
US6278992B1 (en) 1997-03-19 2001-08-21 John Andrew Curtis Search engine using indexing method for storing and retrieving data
US6389534B1 (en) 1997-06-30 2002-05-14 Taher Elgamal Cryptographic policy filters and policy control method and apparatus
JPH1196170A (ja) 1997-09-17 1999-04-09 Toshiba Corp データベース作成方法および情報検索方法および情報検索装置および記録媒体
CA2319177A1 (en) * 1998-01-22 1999-07-29 Ori Software Development Ltd. Database apparatus
JP3692764B2 (ja) 1998-02-25 2005-09-07 株式会社日立製作所 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体
CA2244626A1 (en) 1998-07-31 2000-01-31 Kom Inc. A hardware and software system
US6195024B1 (en) 1998-12-11 2001-02-27 Realtime Data, Llc Content independent data compression method and system
US7788222B2 (en) 1999-12-20 2010-08-31 Planetid, Inc. Information exchange engine providing a critical infrastructure layer and methods of use thereof
US6658405B1 (en) 2000-01-06 2003-12-02 Oracle International Corporation Indexing key ranges
JP2001357048A (ja) * 2000-06-13 2001-12-26 Hitachi Ltd ブロックソート圧縮データの検索方法、および検索に適したブロックソート圧縮法の符号化方法
GB0015233D0 (en) 2000-06-21 2000-08-16 Canon Kk Indexing method and apparatus
FI20010110A0 (fi) 2001-01-18 2001-01-18 Stonesoft Oy Pakettien lajittelu gateway-verkkoelementissä
CA2465379C (en) 2001-11-09 2014-04-29 British Telecommunications Public Limited Company Data integration
US6925463B2 (en) 2002-04-15 2005-08-02 International Business Machines Corporation Method and system for query processing by combining indexes of multilevel granularity or composition
US6970866B1 (en) 2002-05-31 2005-11-29 Adobe Systems Incorporated Filter file system
DE10228128B4 (de) 2002-06-24 2004-09-23 Infineon Technologies Ag Verfahren zur Speicherung von Daten, Verfahren zum Lesen von Daten, Vorrichtung zur Komprimierung von Daten und Vorrichtung zur Dekomprimierung von Daten
US8239343B2 (en) 2003-05-23 2012-08-07 Bmc Software, Inc. Database reorganization technique
US7310721B2 (en) 2003-10-30 2007-12-18 Microsoft Corporation Shadow page tables for address translation control
JP4782490B2 (ja) 2005-06-29 2011-09-28 富士通株式会社 データ集合分割プログラム、データ集合分割装置、およびデータ集合分割方法
US20080015945A1 (en) 2006-07-12 2008-01-17 Michael Goldstein System and Method for Processing Subscriptions and Periodically-Billed Services
WO2008043082A2 (en) 2006-10-05 2008-04-10 Splunk Inc. Time series search engine
US8229902B2 (en) * 2006-11-01 2012-07-24 Ab Initio Technology Llc Managing storage of individually accessible data units
US7885932B2 (en) 2006-11-01 2011-02-08 Ab Initio Technology Llc Managing storage of individually accessible data units
KR100902601B1 (ko) * 2007-05-17 2009-06-12 한양네비콤주식회사 무선 시각송수신시스템 및 무선 시각동기방법
US8189912B2 (en) * 2007-11-24 2012-05-29 International Business Machines Corporation Efficient histogram storage
US20090287986A1 (en) 2008-05-14 2009-11-19 Ab Initio Software Corporation Managing storage of individually accessible data units
US7868789B1 (en) * 2009-06-28 2011-01-11 Sap Ag Dictionary-based order-preserving string compression for main memory column stores

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040216091A1 (en) * 2003-04-24 2004-10-28 International Business Machines Corporation Method and apparatus for resolving memory allocation trace data in a computer system
US20080235377A1 (en) * 2003-11-10 2008-09-25 Eath Co., Ltd. Aggregation system
US20060184563A1 (en) * 2005-02-14 2006-08-17 Potter David H Method and apparatus for temporal database
US20090248645A1 (en) * 2008-03-28 2009-10-01 Brother Kogyo Kabushiki Kaisha Device, method and computer readable medium for management of time-series data

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170308561A1 (en) * 2016-04-21 2017-10-26 Linkedin Corporation Indexing and sequentially storing variable-length data to facilitate reverse reading

Also Published As

Publication number Publication date
CA2841084C (en) 2019-11-05
SG10201608435SA (en) 2016-12-29
CN103733195B (zh) 2018-06-29
US9811570B2 (en) 2017-11-07
EP2729884B1 (en) 2019-09-04
AU2012282870A1 (en) 2014-01-09
CN103733195A (zh) 2014-04-16
JP6088506B2 (ja) 2017-03-01
CA2841084A1 (en) 2013-01-17
US20130013605A1 (en) 2013-01-10
KR102005831B1 (ko) 2019-07-31
JP2014524090A (ja) 2014-09-18
US20130013606A1 (en) 2013-01-10
AU2012282870B2 (en) 2017-08-31
WO2013009622A1 (en) 2013-01-17
EP2729884A1 (en) 2014-05-14

Similar Documents

Publication Publication Date Title
KR102005831B1 (ko) 범위-기반 검색을 위한 데이터 저장 관리
US20180011861A1 (en) Managing storage of individually accessible data units
CA2910840C (en) Managing storage of individually accessible data units
US7885932B2 (en) Managing storage of individually accessible data units
AU2015258326B2 (en) Managing storage of individually accessible data units
AU2014202186B2 (en) Managing storage of individually accessible data units

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant