KR101785959B1 - 레코드들의 컬럼형 스토리지 표현 - Google Patents

Abstract

컴퓨터 시스템은 데이터 레코드들의 집합을 액세스한다. 상기 집합에 있는 각 레코드는 복수의 데이터 값과 상기 복수의 데이터 값으로부터 상응하는 데이터 값들의 세그멘틱을 식별하는 복수의 데이터 요소를 포함한다. 하나 이상의 데이터 레코드 각각은 동일한 데이터 요소에 대한 다수의 인스턴스를 포함하고, 상기 동일한 데이터 요소에 대한 상기 다수의 인스턴스에 상응하는 데이터 값들을 포함한다. 컴퓨터 시스템은 컬럼형 스트라이프들의 집합을 생성한다. 상기 컬럼형 스트라이프들의 집합은 상기 데이터 레코드들의 집합에 있는 각 데이터 레코드로부터의 데이터 값들을 포함한다. 상기 컬럼형 스트라이프들의 집합에 있는 컬럼형 스트라이프 각각은 상기 레코드의 집합에 있는 상기 레코드 각각으로부터의 특정 데이터 요소에 상응하는 모든 데이터 값들을 포함한다.

Description

레코드들의 컬럼형 스토리지 표현{COLUMNAR STORAGE REPRESENTATIONS OF RECORDS}

본 발명은 2010. 4. 5.자 출원된 미국 가출원 번호 61/321,106와 2010. 4. 7.자 출원된 미국 가출원 번호 61/321,688에 대해 우선권을 청구한다.

본 명세서는 전반적으로 레코드들의 컬럼형 스토리지 표현(columnar storage representations of records)을 생성하고 처리하는 기술들, 방법들, 시스템들, 및 메커니즘들을 기술한다.

본 발명은 전반적으로 대용량 분석 데이터 처리(large-scale analytical data processing)에 관한 것이다. 이러한 데이터 처리는 특히 방대한 양의 비즈니스 중요 데이터(business-critical data)를 취합하는 것을 가능하게 하는 저비용 스토리지에 기인하여 웹(web) 기업들과 산업 전반에서 널리 보급되어왔다.

인터렉티브 반응 시간(interactive response times)들이 종종 데이터 탐색, 모니터링, 온라인 고객지원, 쾌속 조형(rapid prototyping), 데이터 파이프라인(data pipeline)들의 디버깅, 및 그 밖의 다른 태스크(task)들에 있어서의 질적인 차이(qualitative difference)를 만들기 때문에, 분석자들과 엔지니어들의 손끝에서 이뤄지는 이들 데이터의 입력이 점점 더 중요해지고 있다. 스케일(scale)에서의 인터렉티브 데이터 분석(interactive data analysis)의 수행은 고도의 병렬성(parallelism)을 요구한다. 예를 들어, 최근 등장한 디스크 제품을 사용하여 1초 안에 1 테라바이트(terabyte)의 압축된 데이터를 판독하는 것은 수 만개의 디스크들을 요구할 수도 있다. 마찬가지로, CPU-집중적 쿼리들(CPU-intensive queries)은 수 초 내에 완료하기 위해서는 수 천개의 코어들(thousands of cores) 상에서 구동되어야 할 수도 있다.

본 발명은 레코드들의 컬럼형 스토리지 표현을 생성하고 처리하는 기술들, 방법들, 시스템들, 및 메커니즘들을 제공하는 것을 목적으로 한다.

확장가능한(scalable), 인터렉티브 애드-혹(ad-hoc) 쿼리 시스템이 데이터 분석을 위하여 본 명세서에서 개시되어 있다. 멀티-레벨 실행 트리(multi-level execution tree)들 및 컬럼형 데이터 레이아웃(columnar data layout)을 결합함으로써, 기재된 시스템 및 방법이 집합 쿼리(aggregation queries)들과 같은 쿼리들을 빠르고 효율적으로 운영할 수 있다. 내포된 레코드들(nested records)을 위한 컬럼형 스토리지 표현(columnar storage representation), 많은 웹-스케일 및 과학적 데이터세트(scientific datasets)에서 사용될 수 있는 일반적인 데이터 모델(prevalent data model)이 기재된다. 실시예에 따르면, 레코드는 컬럼 스트라이프(column stripe)들로 분해(decompose)되는데, 각 컬럼은 블록들의 세트로서 인코드되고, 각 블록은 필드 값들과 반복 및 정의 레벨 정보를 포함한다. 필드 라이터( field writer)의 트리를 사용하여, 레코드 스키마에 있는 필드 계층(field hierarchy)과 매치하는 구조를 갖는 레벨 정보가 생성된다. 레코드는, 각 필드에 대한 필드 값과 레벨 정보를 판독하고, 그 값들을 출력 레코드들에 연속적으로 첨부하는 유한 상태 기계(finite state machine)를 사용하여 효율적으로 컬럼형 데이터로부터 어셈블링될 수 있다. 필드들의 서브셋에 대해서만 탐색이 행해져야 한다면, 실행하기에 더 저렴한 간단한(simpler) 유한 상태 기계가 구성될 수 있다. 또한, 컬럼형 스토리지 표현들과 함께 제한 정보(constraint information)과 같은 추가 메타정보를 저장함으로써, 추가 형태의 쿼리들이 지원될 수 있다.

멀티-레벨 서빙 트리(multi-level serving tree)가 쿼리들을 실행하는데 사용된다. 일 실시예에서, 루트 서버(root server)는 인입 쿼리(incoming query)를 수신하고, 테이블들로부터 메타데이터를 판독하여, 그 쿼리들을 서빙 트리에 있는 다음 레벨로 라우팅한다. 리프 서버(leaf server)들은 스토리지 레이어와 통신하거나 로컬 스토리지에 있는 데이터에 액세스하고, 컬럼형 표현에 있는 내포된 데이터의 스트라이프들을 판독하는데, 상기 로컬 스토리지에 저장된 데이터들은 복제(replicate)될 수 있다. 각 서버는 물리적 쿼리 실행 계획(physical query execution plan)에 상응하는 내부 실행 트리(internal execution tree)를 가지고 있을 수 있는데, 상기 내부 실행 트리는 입력 컬럼들을 스캔하고 집합들과, 레벨 정보가 주석으로 달린 스칼라 함수(scalar function)에 대한 결과를 방출(emit)할 수 있는 반복기(iterators)들의 세트를 포함한다. 다른 실시예에서는, 우선 순위에 기초하여 쿼리들을 스케쥴(schedule)하고, 로드를 분산시키는 쿼리 디스패처(query dispatcher)가 제공된다. 하나의 서버가 다른 서버들보다 많이 느려지거나 복제본(replica)이 도달할 수 없게 되었을 때, 쿼리 디스패처는 또한 고장 허용한계(fault tolerance)를 제공한다. 쿼리 디스패처는 리프 서버들에서 스레드들을 실행하기 위한 처리 시간의 히스토그램을 계산하여, 처리 시간이 불균형한 양의 시간을 소요할 때, 다른 서버로 리스케쥴(reschedule)할 수 있다.

컬럼 데이터는 제 위치(in situ)에서 쿼리될 수 있다. 공통 스토리지 레이어에 컬럼형 데이터를 유지관리하고, 컬럼형 데이터로부터 레코드들을 어셈블링하기 위한 메커니즘들을 제공하는 것은 레코드 구조로 된 데이터를 분석하는 데이터 관리 툴로 조작할 수 있게 한다. 본 시스템은 많은 CPU를 조정할 수 있어, 대량의 데이터를 신속하게 판독할 수 있게 한다. 특정 경우에, 후술하는 하나 이상의 이점을 실현하기 위해, 특정 실시예들이 구현될 수 있다. 데이터베이스 관리 시스템에 의해 데이터가 로딩되지 않고, 데이터가 액세스될 수 있도록 하기 위해, 내포된 데이터가 제자리에서 동작될 수 있다. 내포된 데이터의 쿼리들은 다른 분석 프로그램들에 의해 요구된 것보다 감소된 실행 시간 내에 수행될 수 있다. 공통 스토리지 레이어상에 구현되는 컬럼형 스토리지 데이터 구조는 다수의 다른 분석 프로그램이 상기 컬럼형 스토리지 데이터 구조에 액세스할 수 있게 한다.

첨부된 청구 범위와 상기 설명 부분에 기재된 실시예들에 대한 대안예로서, 본 발명은 또한 후술하는 실시예들 중 하나에 의해 설명될 수도 있다.

실시예 1은 컴퓨터-구현 방법에 관련된다. 상기 발명은 컴퓨팅 시스템에 의해, 컴퓨터 메모리에 저장된 데이터 레코드들의 집합에 액세스하는 단계를 포함하고, 데이터 레코드들의 집합에 있는 각 레코드는 복수의 데이터 값과 상기 복수의 데이터 값으로부터의 데이터 값들에 상응하는 시멘틱스(semantics)를 식별하는 복수의 데이터 요소를 포함하고, 상기 데이터 레코드들의 집합에 있는 하나 이상의 데이터 레코드 각각은 동일 데이터 요소에 대한 다수의 인스턴스를 포함하고 상기 동일 데이터 요소에 대한 다수의 인스턴스에 상응하는 데이터 값들을 포함한다. 상기 발명은 상기 컴퓨팅 시스템에 의해, 컬럼형 스트라이프(columnar stripe)들의 집합을 생성하는 단계를 더 포함하는데, 상기 컬럼형 스트라이프들의 집합은 상기 데이터 레코드들의 집합에 있는 각 데이터 레코드로부터의 상기 데이터 값들을 포함하고, 상기 컬럼형 스트라이프들의 집합에 있는 각 컬럼형 스트라이프는 상기 데이터 레코드들의 집합에 있는 각 레코드로부터의 특정 데이터 요소에 상응하는 모든 데이터 값을 포함한다.

실시예 2는 실시예 1의 방법에 관련된다. 상기 발명은 상기 컴퓨팅 시스템에 의해, 상기 컬럼형 스트라이프들의 집합에 있는 각 컬럼형 스트라이프에 있는 각 데이터 값에 대하여, 상기 데이터 레코드들의 집합으로부터 데이터 레코드 각각에 있는 상기 데이터 값 각각의 위치를 식별하는 데이터를 생성하는 단계를 더 포함한다.

실시예 3은 실시예 2의 방법에 관련되는 것으로서, 상기 데이터는 반복값(repetition value)과 정의값(definition value)으로 구성된다.

실시예 4는 실시예 2 또는 실시예 3 중 하나의 방법에 관련된다. 상기 방법은 (ⅰ) 상기 컬럼형 스트라이프들의 집합에 있는 상기 컬럼형 스트라이프들과 (ⅱ) 상기 데이터로부터, 상기 데이터 레코드들의 집합에 있는 상기 데이터 레코드들로부터 데이터 요소들의 서브셋만을 포함하는 데이터 레코드들의 세트를 재구성(reconstruction)하는 단계를 더 포함한다.

실시예 5는 실시예 1 내지 실시예 4 중 어느 하나의 방법에 관련된 것으로서, 상기 컬럼형 스트라이프들의 집합에 상기 데이터 값들과 함께 저장하기 위하여, 상기 컬럼형 스트라이프들의 집합에 있는 특정 데이터 값 각각에 대한 반복값을 생성하는 단계를 더 포함하는데, 특정 데이터 요소 각각에 대한 경로(path)는 상기 특정 데이터 요소에 대한 하나 이상의 부모 데이터 요소(parent data element)를 포함하고; 특정 데이터 값 각각에 대한 상기 반복값은 상기 특정 데이터 값에 상응하는 상기 특정 데이터 요소의 상기 경로에서 가장 최근에 반복된 데이터 요소(a most-recently repeated data element)를 식별하며; 상기 특정 데이터 요소의 상기 경로에서 상기 가장 최근에 반복된 데이터 요소는 분석중에 제2 시간동안 접하게 되는 상기 특정 데이터 요소의 상기 경로에 있는 상기 데이터 요소로서, 상기 데이터 요소는 상기 특정 값을 포함하는 특정 데이터 레코드에 있으며, 상기 특정 데이터 레코드에 있는 상기 특정 데이터 값의 위치(position)로부터 상기 특정 데이터 레코드의 시작점을 향해서 위쪽으로 작업(work)한다.

실시예 6은 실시예 1 내지 실시예 5 중 어느 한 항의 방법에 관련된 것으로, 상기 데이터 요소들의 집합에 포함되는 상기 데이터 요소들의 특정 데이터 요소 각각은, 상기 특정 데이터 요소에 대한 상기 하나 이상의 부모 데이터 요소를 포함하는 각각의 경로와 연관된다. 상기 방법은 상기 컬럼형 스트라이프들에 있는 상기 데이터 값들과 함께 저장하기 위해, 상기 데이터 레코드들의 집합에 있는 상기 특정 경로의 일부 또는 특정 경로 각각에 대한 정의값을 생성하는 단계를 더 포함한다. 상기 특정 경로 또는 상기 특정 경로의 일부에 대한 상기 정의 레벨은 특정 경로 또는 경로의 일부에 포함된 데이터 요소들의 양을 식별한다.

실시예 7은 실시예 1 내지 실시예 6 중 어느 한 방법에 관련된다. 상기 방법은 상기 컴퓨팅 시스템에 의해서, 각각이 스키마(schema)에 따라서 비구조화된 정보를 포함하는 데이터 소스들의 집합으로부터 정보를 수신하는 단계를 더 포함한다. 상기 방법은 상기 컴퓨팅 시스템에 의해서, 상기 스키마에 따라서 각 데이터 소스에 있는 상기 정보를 구조화함으로써 상기 데이터 레코드들의 집합에서 데이터 레코드 각각을 생성하는 단계를 더 포함한다.

실시예 8은 실시예 1 내지 실시예 7 중 어느 한 방법에 관련된다. 상기 방법은 상기 컴퓨팅 시스템에 의해서, 상기 컬럼형 스트라이프들의 집합의 쿼리를 수행하는 단계를 더 포함한다. 상기 방법은 상기 컴퓨팅 시스템에 의해, 상기 쿼리의 수행에 응답하여, 상기 쿼리에 의해 식별되는 상기 컬럼형 스트라이프의 집합으로부터 컬럼형 스트라이프로부터의 상기 값들의 서브셋을 포함하는 새로운 컬럼형 스트라이프를 출력하는 단계를 더 포함한다.

실시예 9는 실시예 8의 방법에 관련된 것으로서, 상기 컬럼형 스트라이프들의 집합의 상기 쿼리는 상기 컬럼형 스트라이프들의 집합에 포함된 상기 데이터 값들을 데이터베이스에 로딩하지 않고 수행된다.

실시예 10은 실시예 1 내지 실시예 9 중 어느 한 방법에 관련된 것으로서, 상기 컬럼형 스트라이프들의 집합 중 적어도 하나의 제1 컬럼형 스트라이프는 다수의 데이터 블록을 포함하고, 상기 다수의 데이터 블럭 중 적어도 일부 각각은 각 블럭들의 값에서 발견되는 값의 종류를 정의하는 주장값(assertion value)을 포함하여, 상기 컴퓨터 시스템이 상기 제1 컬럼형 스트라이프의 쿼리를 수행할 때, 하나 이상의 데이터 블럭이 상기 쿼리에 의해 특정되는 데이터 값을 포함하지 않게 한다.

실시예 11은 실시예 1 내지 실시예 10 중 어느 한 방법에 관련된 것으로서, 상기 컬럼형 스트라이프들의 집합의 제1 컬럼형 스트라이프는 제1 데이터값으로서, 상기 데이터 레코드들의 집합에 있는 제1 데이터 요소의 인스턴스들에 상응하는 상기 데이터 레코드들의 집합에 있는 상기 데이터 레코드들로부터의 모든 데이터 값을 포함한다. 상기 제1 컬럼형 스트라이프는 메모리에 연속적으로 다수의 제1 데이터 값을 저장하는데, 상기 다수의 제1 데이터 값들이 상기 데이터 레코드들의 집합에 있는 데이터 레코드들에 저장되어 있을 경우에는, 상기 다수의 제1 데이터 값을 메모리에 연속적으로 저장하지 않는다.

실시예 12는 실시예 1 내지 실시예 11 중 어느 한 방법에 관련된 것으로서, 상기 데이터 레코드들의 집합에 있는 적어도 하나의 데이터 레코드는 데이터 요소 및 내포된 데이터 모델(nested data model)에 따라 저장되는 상응 데이터 값(corresponding data value)들을 포함한다.

실시예 13은 실시예 1 내지 실시예 12 중 어느 한 방법에 관련된 것으로서, 제1 데이터 레코드는 제2 데이터 요소에 대한 부모 데이터 요소인 제1 데이터 요소와 상기 제1 데이터 요소에 대한 자식 데이터 요소인 상기 제2 데이터 요소를 포함한다. 제1 컬럼형 스트라이프는 상기 제1 데이터 레코드에 있는 상기 제1 데이터 요소에 상응하는 데이터 값과 상기 데이터 레코드들의 집합에 있는 상기 제1 데이터 요소의 인스턴스들에 상응하는 모든 다른 데이터 값들을 포함한다. 제2 컬럼형 스트라이프는 상기 제1 데이터 레코드에 있는 상기 제2 데이터 요소에 상응하는 데이터 값과 상기 데이터 레코드들의 집합에 있는 상기 제2 데이터 요소의 인스턴스들에 상응하는 모든 다른 데이터 값들을 포함한다.

다른 실시예들은 하나 이상의 처리 디바이스(예컨대, 프로그램가능한 컴퓨터 프로세서)에 의해 실행되었을 때, 상술된 실시예 1 내지 실시예 13 중 어느 하나에 따른 동작들을 수행하는 명령어들을 저장하고 있는 상응하는 컴퓨터-판독가능 스토리지 디바이스들을 포함한다. 다른 실시예들은 하나 이상의 처리 디바이스에 의해 실행되었을 때, 상술된 실시예 1 내지 실시예 13 중 어느 하나에 따른 동작들을 수행하는 명령어들을 저장하고 있는 상술된 컴퓨터-판독가능 스토리지 디바이스들을 포함하는 시스템들 및 장치들을 포함한다.

하나 이상의 실시예에 대한 상세 설명은 첨부 도면과 후술하는 상세 설명에서 개시된다. 다른 특징들, 목적들, 및 이점들은 상세한 설명과 도면, 및 청구 범위로부터 명백해질 것이다.

본 발명에 따르면, 레코드들의 컬럼형 스토리지 표현을 생성하고 처리하는 기술들, 방법들, 시스템들, 및 메커니즘들을 제공할 수 있다.

도 1은 내포된 데이터(nested data)의 레코드 단위 v. 컬럼형 표현을 나타낸다.
도 2는 두 개의 내포된 레코드 샘플과 그 스키마(schema)를 나타낸다.
도 3은 내포된 레코드 샘플의 컬럼-스트라이프형(column-striped) 표현을 나타낸다.
도 4는 레코드(record)를 컬럼들(columns)로 해체하는 알고리즘이다.
도 5는 완전한 레코드 어셈블리를 수행하는 오토머턴(automaton)을 나타낸다.
도 6은 두 영역으로부터의 레코드들과 오토머턴(automaton)에 의해 산출된 레코드들의 어셈블리를 위한 오토머턴(automaton)을 나타낸다.
도 7은 레코드 어셈블리 오토머턴(assembly automaton)을 구성하는 알고리즘(algorithm)이다.
도 8은 컬럼형 데이터로부터 레코드를 어셈블링(assembling)하는 알고리즘이다.
도 9는 프로젝션(projection), 셀렉션(selection) 및 레코드 내 취합(within-record aggregation)을 수행하는 샘플 쿼리를 도시한다.
도 10은 서버 노드 내부의 시스템 구조와 실행을 나타낸다.
도 11은 일 실험적 연구에서 사용된 표로 나타내어진 데이터 세트(datasets)이다.
도 12는 로컬 디스크로부터 판독할 때 일어날 수 있는 브레이크다운(breakdown)의 실행을 나타내는 그래프이다.
도 13은 컬럼형 대 레코드 지향형 스토리지 상에 나타낸 시스템과 두 MapReduce의 실행을 나타내는 그래프이다.
도 14는 두 병합 쿼리들(aggregation queries)에 대한 트리 레벨(tree level) 제공기능으로서의 실행시간을 나타내는 그래프이다.
도 15는 처리시간들의 히스토그램(histograms)을 나타내는 그래프이다.
도 16은 시스템이 top-k 쿼리(query)를 이용하여 1000∼4000 노드들(nodes)로 스케일 되었을 때의 실행시간을 나타내는 그래프이다.
도 17은 시간당 태블릿(tablet) 처리 기능으로서 처리된 테이블의 퍼센트를 나타내는 그래프이다.
도 18은 월간 워크로드(monthly workload)에서의 쿼리 반응 시간 분포를 나타내는 그래프이다.
도 19는 내포된 레코드(nested records)의 컬럼형 스토리지 표현들(columnar storage representations)을 생성하고 처리하는 시스템의 블록 다이어그램이다.
도 20은 컬럼형 데이터를 생성하기 위한 처리 예시의 순서도이다.
도 21은 클라이언트나 서버, 또는 복수의 서버들로서, 본 명세서에서 설명된 시스템들 및 방법들을 구현하는데 사용될 수 있는 컴퓨팅 디바이스들의 블록 다이어그램이다.
여러 도면들에서의 동일한 참조 부호들은 동일한 구성요소들을 가리킨다.

본 명세서는 레코드들의 컬럼형 스토리지 표현들(columnar storage representations of records)을 생성하고 처리하는 기술들, 방법들, 시스템들 및 메커니즘들을 기술한다. 하나의 실례로서, 한 구성(organization)은 웹 페이지들로부터의 데이터를 내포된 정보의 레코드들 내에 저장할 수 있다. 내포된 정보는 멀티 레벨 실행 트리(multi-level execution tree)를 이용한 효율적인 데이터 쿼리를 가능케 하는 컬럼형 데이터 스토리지 포맷을 따를 수 있다. 컬럼형 데이터는 레코드 지향형 데이터 상에서 운용되는 분석 프로그램들 내부로 입력되기 위한 레코드들로 리어셈블링(re-assembled) 될 수 있다.

보다 특정적으로, 각 레코드는 해당 레코드들이 스키마(schema)에 따라 생성됨에 있어서, 레코드들의 포맷팅(formatting)을 정의하는 스키마의 인스턴스화(instantiation)일 수 있다. 예를 들면, 스키마는 웹 페이지에 관한 정보를 저장하기 위한 다양한 필드(fields)들과 레코드 및 그들의 상응하는 값 내에 필드들을 조직화하기 위한 구조를 인식할 수 있다. 웹 페이지의 특징을 설명하기 위한 레코드가 생성되었을 때, 이 레코드는 각 필드에 대한 데이터 요소(data element) 및 상응하는 값을 포함할 수 있다. 데이터 요소는 스키마 내의 정의에 따른 값의 시맨틱스(semantics)를 정의할 수 있다. 데이터 요소 및 필드의 항목은 본 명세서에서 교체되어 사용될 수 있다. 필드 또한 데이터 요소와 상응하는 값(corresponding value)의 조합에 관련될 수 있다.

특정 레코드는 스키마에 의해 정의된 모든 필드들을 포함하는 것이 필요치 않을 수 있다. 따라서 스키마는 특정 레코드에 대해 선택될 수 있는 필드들로부터의 '템플릿'(template)으로서 제공할 수 있다. 예를 들면, 스키마는 웹 페이지 내의 비디오 컨텐츠에 관한 정보를 정의하기 위한 필드를 포함할 수 있다. 만일 웹 페이지가 비디오 컨텐츠를 포함하지 않으면, 이 웹 페이지에 따른 레코드는 웹 페이지 상의 비디오에 관한 정보를 정의하는 스키마로부터의 필드를 포함하지 않을 수 있다. 따라서 일부의 필드들은 '선택적'(optional)일 수 있다.

레코드 내의 일부 필드들은 반면 '필수'(required)일 수 있다. 예를 들면, 스키마 내의 '필수' 필드는 웹 페이지에서 제공되는 문서에 대한 소스 위치(source location)의 URL(Uniform Resource Locator) 일 수 있다. 어떠한 웹 페이지 문서도 소스 위치로부터 탐색되어질 수 있으며(즉, 문서마다 유효한 URL이 있음), 필드는 웹 페이지 상의 정보의 추가적인 처리를 위해 요구될 수 있기 때문에(예컨대, 만일 컨텐츠가 변경된 경우 확정하기 위해), 필드는 필수적일 수 있다.

필드는 또한 '반복가능' 일 수 있다. 스키마 내의 필드와 반복가능으로 정의된 필드는 스키마의 인스턴스화(instantiation)에서(즉, 레코드 내에서) 스키마에 의해 반복적으로 정의된 위치에서 되풀이 될 수 있다. 예를 들면, 스키마는 웹 페이지로 링크된 문서를 정의하기 위한 필드를 포함할 수 있다. 스키마는 한번에 오직 필드만을 특정할 수 있으나, 이 필드는 반복가능함을 가리킬 수 있다.(예컨대, 몇 개의 문서가 특정 웹 페이지로 링크될 수 있기 때문에) 따라서 웹 페이지에 대한 레코드는 링크되는 웹 페이지에 대한 값을 인식하는 다중 필드를 포함할 수 있다. 반복된 필드들은 동일 레벨에 위치할 수 있으며, (이하에서 보다 자세히 논의되는 바와 같이) 레코드 내의 부모 필드(parent field)의 하위에 내포(nested)될 수 있다.

스키마의 필드들(및 레코드들에 필드들이 있게 됨)이 내포될 수 있다. 다시 말해, 일부 필드들은 부모 필드들, 조부모(grandparebt) 필드들 등으로 참조될 수 있는 다른 필드들의 자식들일 수 있다. 몇몇의 예시들에서, 자식 노드들은 부모 노드를 바로 뒤따르는 한 쌍의 열리고 닫힌 중괄호({ }) 사이에서 발견되는 스키마 내의 그들의 노드들이다. 그러나, 내포를 위한 다른 구현예들이 이용될 수 있다(예컨대, 필드에 대한 시작 태그 및 필드에 대한 끝 태그의 사용). 따라서 최상위 레벨에 있는 필드들을 제외하면(예컨대, 다른 어떤 필드들의 자식들이 아닌 필드들), 각 필드는 부모 필드를 가질 수 있다.

내포(nesting)는 개념적으로 관계되는 정보의 토막(chunks of information)으로 정보를 조직화하는 것을 도울 수 있다. 초기의 예시로 돌아오면, 스키마는 '비디오' 필드를 포함할 수 있다. '비디오' 필드는 해당 비디오의 특징(예컨대, 비디오가 어느 정도의 분량인지, 비디오의 포맷, 및 비디오의 해상도)을 인식할 수 있는 몇 개의 자식 필드들을 포함할 수 있다. 따라서 레코드가 구성되었을 때, 만일 그들의 부모 노드들이 존재하지 않으면, 자식 노드들이 레코드 내에 위치하지 않을 수 있다. 이는 다시 말해, 비디오를 포함하지 않는 웹 페이지에 대한 레코드는 해당 레코드가 '비디오' 필드(즉, '비디오길이'(VideoLength) 필드의 부모)를 포함하지 않기 때문에 '비디오길이' 필드를 포함하지 않을 수 있다. 레코드를 보면서 편집할 수 있는 애플리케이션 프로그램들은 종속된 자식들을 부모로부터 시각적으로 내포시킬 수 있다.(예컨대, 부모 필드의 오른쪽으로 자식들을 들여씀(indent))

수백만의 레코드들을 분석하는 작업은 시간이 소요될 수 있다. 일부 예시들에서, 사용자는 단일 필드로부터의 데이터에 관심을 가지만, 각각의 레코드들은 전체로서 액세스되어야만 한다. 예를 들면, 사용자는 10분을 초과하며 '고해상도'를 갖는 비디오들을 포함하는 웹 페이지들과 연계된 그들의 레코드들을 인식하기 위하여 각각 수백만의 레코드들을 체크하는 분석 프로그램을 요청할 수 있다. 각 레코드는 독립된 데이터 구조로서 저장될 수 있기 때문에, 레코드들을 쿼리하여 그 레코드가 특정한 비디오 길이 및 해상도의 특정 조합을 포함하는지의 판정을 위해, 전체 레코드 각각이 데이터베이스 관리 시스템에 로드될 필요가 있을 수 있다.

이러한 단일 레코드마다의 로딩은 해당 태스크를 수행하는데 요구되는 다량의 서버 및 그 쿼리를 수행하는데 필연적으로 소요되는 시간, 이 둘 모두에 어마어마한 비용이 들 수 있다. 상당한(significant) 시간 절약은 특정 필드-수백만의 레코드들전반으로부터 선택된-에 대한 모든 값들을 메모리의 인접한 부분(contiguous portion)에 함께 저장함으로써 획득될 수 있다. 특정 필드를 제외한 이러한 몇몇 레코드들로부터의 값들의 스토리지는 컬럼형 스토리지(columnar storage)라 불린다. 이와 대조적으로, 특정 레코드에 대한 정보가 메모리에 인접하게 저장된 예시는 레코드-지향형 스토리지(record-oriented storage)로 불린다.

그러나 내포된 레코드들에 대한 컬럼형 스토리지(columnar storage)는 독특한 어려움들을 제기한다. 레코드 내의 필드는 그 필드 및 그 부모 필드들(예컨대, 조부모.부모.자식)의 목록을 포함하는 그들의 경로(path)에 의해 식별될 수 있다. 경로 내의 하나 이상의 필드들이 반복될 수 있기 때문에, 동일한 경로 이름을 갖는 필드의 몇몇 인스턴스들(instances)이 있을 수 있다. 따라서 특정 필드에 대한 컬럼형 데이터의 연속적인 목록을 살펴볼 때, 어떤 값들이 어떤 레코드에 속하는지, 및 특정 경로에 대한 다양한 값들을 포함하는 그들 레코드들에 대하여, 무엇이 레코드에 있는 값의 개별적 위치인지를 식별하기 위한 메커니즘이 필요하다. 다시 말해, 컬럼형 구조에 있는 값들의 시퀀스를 고려해 볼 때, 그 값들로부터 레코드의 구조를 재구성하기 위한 메커니즘이 요구된다.

컬럼형 데이터로부터 레코드의 구조를 재구성하기 위한 메커니즘은 컬럼형 데이터 내부의 각 값들에 대하여 '반복' 레벨 및 '정의' 레벨을 저장하는 것을 포함한다. 각 '레벨'은 숫자를 표현하는 비트들의 시퀀스일 수 있다. 예를 들면, 레벨 3은 2비트(bit)(예컨대, '11')로 표현될 수 있다. 다른 예시에서, 레벨 5는 3 비트(예컨대, '101')로 표현될 수 있다.

특정 값에 대해 저장된 '반복' 레벨은 가장 최근에 반복된 값들의 경로 내의 필드를 가리킨다. 일례로서, '비디오.해상도.폭(Video.Resolution.Width)'의 경로를 갖는 필드에 대한 값들의 컬럼이 저장될 수 있다. 반복 레벨 '1'은 가장 최근 반복된 비디오 필드를 가리킬 수 있고, 반복 레벨 '2'는 가장 최근 반복된 '해상도' 필드를 가리킬 수 있다. 최근 반복은 경로 '비디오.해상도.폭'이 카운트 2(해당 필드가 처음에서 두 번째로 접해짐(encounter))에 가장 먼저 도달하는, 문서의 시작점을 향해 위쪽으로 작업하면서 선택된 레코드에 있는 값들의 위치에서부터 가리킬 수 있다.

예를 들면, '폭' 값의 위치로부터 위쪽으로 작업해가면서, 각 필드는 1회 접하게 된다. 각 필드의 두 번째 인스턴스(instance)를 찾는 것은 인근의 내포된 필드(및 추가 내포가 가능함)인 다음 필드까지의 깊이(depth of the next)로의 트래버스(traverse)을 요구한다. 따라서 어떤 '해상도' 자식들(예컨대, '해상도' 필드가 선택적이거나 또는 반복되는 필드이기 때문에)을 포함하지 않는 '비디오' 필드가 접하게 될 수 있다. 따라서 '비디오' 필드는 두 번째 접하게 되고, 따라서 이는 가장 최근에 반복된 필드이다. 반복 레벨 '1'이 그 값에 할당된다.

반복 레벨 '0'은 그 필드가 가장 최근에 반복된 값을 포함하지 않는다(예컨대, 하향식 스캔(top-down scan)이 실행되는 동안 레코드에서 처음 접함)는 것을 나타낼 수 있다. 다양한 예시들에서, 경로상에서 '필수' 필드는 반복 레벨을 갖지 않는다. 예를 들면, 만일 '해상도' 필드가 '비디오.해상도.폭' 경로에 대해 요구된다면, 해상도 레벨의 범위는 '0' 또는 '1' 중 하나일 것이다. '비디오' 필드가 존재하는 경우, 레코드 내에 '해상도'는 항상 존재하기 때문에, '해상도'는 레벨을 갖지 않을 수 있다. 따라서 만일 '해상도'가 레벨 '2'로 할당되었다면, 그것은 항상 '비디오' 전에 접하게 될 수 있으며, 따라서 레벨 '1'은 절대 할당되지 않을 수 있다. 따라서 필수 필드들에 대한 반복 레벨을 포함하지 않는 것은 다른 해상도 레벨의 수를 줄일 수 있게 할 수 있으며, 해상도 레벨을 표현하는 비트의 수가 줄어들 수 있다.

만일 상기의 예시에서 '폭'(Width) 필드가 '선택적' 또는 '반복적' 필드이면, 레코드는 '폭' 필드에 대한 값을 항상 포함하지 않을 수 있다. 따라서 '비디오.해상도.폭' 경로에 대한 값들의 컬럼이 비디오' 또는 '비디오.해상도' 경로가 레코드 내에서 발견되었지만, '폭' 필드가 레코드 내에서 인스턴스화되지 않았을 때를 지정하기 위하여 메커니즘을 사용할 수 있다. 이 메커니즘은 '폭' 필드가 인스턴스화 되었는지에 관계없이 '비디오.해상도.폭' 데이터 컬럼 내에, 레코드 내의 각 '비디오' 또는 '비디오.해상도' 필드에 대한 '정의(definition)' 레벨을 저장하는 것을 포함할 수 있다. '정의' 레벨은 '비디오.해상도.폭' 경로 내에 (예컨대, 필드가 선택적이거나 또는 반복가능이기 때문에) 소실(missing)될 수 있는 필드가 실제로 얼마나 많이 존재하는지를 나타낼 수 있다.

따라서 만일 '비디오' 필드가 레코드 내에 존재하지만 상응하는 '해상도' 자식 어떤 것도 인스턴스화되지 않았다면, '비디오.해상도.폭' 컬럼 내에는 정의 레벨 '1'이 기록될 수 있다. 만일 레코드 내에 '비디오.해상도' 필드가 존재하지만 상응하는 '폭' 자식 어떤 것도 인스턴스화되지 않았다면, 정의 레벨 '2'가 기록될 수 있다. 만일, '비디오.해상도.폭' 필드가 레코드 내에 존재한다면, 정의 레벨 '3'이 기록될 수 있다.

이와 같이, 레코드에서의 데이터 요소 경로 각각 또는 데이터 요소 경로의 일부에 대한 정의 레벨이 생성될 수 있다. 예를 들면, '비디오.해상도.폭' 경로는 이 '비디오.해상도.폭' 경로 내에 포함된 다량의 데이터 요소들을 식별하는 정의 레벨 '3'을 가질 수 있다. 다른 예시로서, '비디오.해상도' 경로는 '폭' 데이터 요소가 데이터 레코드 내에 인스턴스화 되지 않았더라도, '비디오.해상도' 경로 내에 포함된 다량의 데이터 요소를 식별하는 정의 레벨 '2'를 가질 수 있다.

그러므로, 정의 레벨(정의되지 않은 상태일 수 있으나 실제로는 정의되어 있는 필드의 수를 표현함)이 정의될 수 있는 필드의 수보다 적을 때는 언제든지, '폭' 필드의 소실 발생(missing occurrence)이 식별될 수 있다.

여러 예시들에서, '정의' 레벨은 정수(integer) 대신에 불값(Boolean value)이다. 정의되지 않은 객체(object)를 포함하고 있는 것이 중요하지 않았다는 것을 아는 경우, 불값이 정수 대신에 사용될 수 있다. 예를 들면, 시스템이 어느 부모 필드들이 인스턴스화 되었는지 알 필요가 없는 경우, '비디오.해상도.폭' 경로의 폭 필드에 대한 값을 위한 정의 레벨은 'NULL'일 수 있다. '반복' 레벨과 '정의' 레벨의 조합은 레코드의 구조가 재구성될 수 있게 할 수 있다.

특정 필드(예컨대, '비디오.해상도.폭' 필드)에 대한 데이터의 컬럼은 다수의 레코드, 상응하는 반복 및 정의 레벨들(일부 '소실' 값들이 반복 및 정의 레벨을 가질 수 있음을 인지함), 및 헤더 정보(header information)로부터의 필드에 대한 값들을 포함할 수 있다. 일부 예시들에서, 이 값들은 연속적이고 인접하게 저장된다. 다시 말해, 하나의 '비디오.해상도.폭' 필드에 대한 값이 '700'이었고, 다음 '비디오.해상도.폭' 필드에 대한 값이 '800'이었다면, 메모리에 저장된 것처럼 상기 컬럼의 일부는 '700800'을 판독한다. 이 예시에서, 컬럼 내의 헤더는 각각의 값이 고정된 폭(예컨대, 숫자 700과 800을 저장하기 위한 고정된 이진 표현(fixed binary representation))을 갖고 있음을 식별할 수 있다.

일부 예시들에서, 이 저장된 값들은 스트링(strings)으로 표현된다. 예를 들면, '폭' 필드의 인스턴스들(instances)은 '작은'(Small) 및 '중간'(Medium) 값들을 포함할 수 있다. 일부 예시들에서, 다양한 스트링 값들은 고정된 길이(fixed length) 일 수 있다(예컨대, 스트링이 '중간' 값과 같은 길이로 되도록 하기 위해, '작은' 값의 처음 또는 끝에 null 값이 부가될 수 있음). 일부 예시들에서는 그러나 각각의 저장된 스트링이 해당 스트링의 길이를 식별하는 식별자를 스트링의 시작 부분에 포함할 수 있다. 예를 들면, '작은' 값은 스트링이 5 비트 길이(또는 대응하는 2진 비트로 된 상응하는 숫자)임을 나타내는 식별자를 포함할 수 있다.

이 값들은 컬럼형 스트라이프(columnar stripe) 내에 연속적으로 저장될 수 있기 때문에, '반복' 및 '정의' 레벨이 이 컬럼형 스트라이프의 처음에 저장될 수 있다. 일부 예시들에서, '반복' 및 '정의' 레벨들은 특정 값에 대해 쌍(pairs)(인스턴스화된 것이든 또는 소실된 것이든)으로 저장된다. 일례로서, 반복 레벨 3은 한 바이트(byte)의 처음 4 비트(bit) 안에 저장될 수 있고, 정의 레벨 1은 이 바이트의 마지막 4 비트 안에 저장될 수 있다. 헤더(header)에 있는 다음 바이트는 레코드 내에 있는 필드의 다음 인스턴스(instance)(또는 뒤에 이어지는 레코드에 있는 첫 번째 인스턴스)에 대한 반복 레벨 및 정의 레벨을 포함할 수 있다.

반복 및 정의 레벨을 나타내는데 표현하기 위해 사용되는 비트 수는 최대 레벨 값을 기초에 기초할 수 있다. 예를 들면, 만일 최대 반복 레벨이 3이면, 반복 레벨은 2 비트로 표현될 수 있다. 만일 최대 반복 레벨이 4이면, 반복 레벨은 3 비트로 표현될 수 있다. 헤더는 반복 및 정의 레벨의 길이를 식별하는 정보를 포함할 수 있다.

여러 예시들에서, 반복 레벨들은 메모리 내에 연속적으로 저장될 수 있으며, 정의 레벨들은 메모리 내에 연속적으로 저장(예컨대, 쌍을 이루지 않고)될 수 있다. 여러 예시들에서, 반복 및 정의 레벨들은 그들의 상응하는 값(만일 그 값이 인스턴스화 되었다면)과 그룹을 지어 저장될 수 있다. 다시 말해, 컬럼형 스트라이프 내의 정보 시퀀스(a sequence of information)는 아래 등과 같이 판독될 수 있다.

Value1:RepetitionLevel1:DefinitionLevel1:Value2:RepetitionLevel2:DefinitionLevel2

컬럼형 스트라이프들은 정보의 블록들로 압축될 수 있다. 예를 들면, 각 컬럼형 스트라이프는 각각의 블럭이 각기 자신의 헤더를 포함하는 하나의 블록들의 셋(a set of blocks)으로 나뉠 수 있다. 제1 블록은 1,600,000 값들로부터 첫 번째 800,000 값들을 포함할 수 있으며, 제2 블록은 두 번째 800,000 값들을 포함할 수 있다. 블록 헤더는 블록에 의해 표현된 컬럼형 스트라이프의 일부에 대한 분석을 돕고, 그 컬럼형 스트라이프를 재구성하는데 사용될 수 있는 추가적인 정보와 함께 반복 및 정의 레벨들을 포함할 수 있다.

일부 예시들에서, 블록 헤더는 블록의 값들에서 발견되는 데이터의 유형을 정의하는 '주장' 값('Assertion' value)을 포함한다. 예를 들면, '비디오.해상도.폭' 필드에 대한 블록이 '큰' 폭 해상도('Large' width resolution)를 목록화 한 어떠한 값들도 포함하지 않을 수 있다. 따라서 이 '주장' 값은 해당 값들이 '작은'(Small) 및 '중간'(Medium) 값들만을 포함하고 있음을 나타낼 수 있다. 쿼리가 '높은' 폭 해상도('High' width resolution) 비디오들을 포함하는 레코드들에 대하여 수행된다면, 설명된 블록이 쿼리 시스템(querying system)에 의해 회피될 수 있다.

본 명세서에서 설명된 시스템은 컬럼형 스트라이프들 내의 정보를 레코드들로 재구성하지 않고, 또한 컬럼형 스트라이프들로부터 데이터베이스로 정보를 로딩하지 않고(예컨대, '삽입' 구문('Insert' clause)을 사용하지 않고), 컬럼형 스트라이프들 상에서 쿼리들을 수행할 수 있다. 따라서 이 데이터는 원래의 제 위치(in situ)에서 액세스될 수 있어, 계산 차수(the order of magnitudes)에 따른 연산적 분석 시간 절감을 제공할 수 있다.

쿼리 시스템은 쿼리 관계형 데이터베이스(querying relational databases)를 위해 사용되는 많은 구문들을 사용할 수 있다. 그러나 비관계형 데이터(non-relational data)에 특정된 추가적인 구문들이 사용될 수도 있다. 예를 들면, 'WITHIN' 구문은 연산(operation)들이 단일 레코드 또는 레코드의 일부(a portion of a record)에 속한 필드의 다중 인스턴스 상에서 수행되는 것을 허용한다. 하지만, 관계형 데이터베이스는 행(row) 내의 필드의 다수의 인스턴스(예컨대, 레코드의 표현) 보다 많이 저장할 수는 없을 수 있다. 따라서 관계형 데이터베이스 상의 쿼리는 근본적으로 페코드 '내(within)' 에서 쿼리들을 수행할 수 없을 수도 있다.

WITHIN 구문의 한 예로서, 특정 필드에 대한 값들이 곱해질 수 있다. 쿼리 명령어(query instruction)들이 'MutualFund.InterestRate'에 대한 모든 값들이 특정 레코드(각 레코드는 특정 계정 소유주(account account)에 대한 것일 수 있음)에 대해 함께 곱해지도록 요청하는 경우를 가정해 보자. 쿼리 시스템은 단일 레코드 내부의 모든 'MutualFund.InterestRate' 값들을 찾아, 그들을 함께 곱할 수 있다.

비관계형 내포된 데이터(non-relational nested data)에 특정된 것일 수 있는 다른 예시는 OMIT IF 구문이다. 이 구문은 특정 조건이 충족된다면(예컨대, 새로운 컬럼형 스트라이프 또는 레코드가 제거된 특정된 필드들과 함께 생성될 수 있음), 필드들의 인스턴스들을 제거하기 위하여 레코드가 필터링되도록 할 수 있다. 일례로서, 종업원들의 임금을 목록화한 값들의 스트라이프가 쿼리화될 수 있으며, $90,000 이상의 임금을 받는 종업원들을 제거한 새로운 스트라이프가 OMIT IF 구문을 이용하여 생성될 수 있다.

1. 서문(INTRODUCTION)

대규모 병렬 컴퓨팅(large-scale parallel computing)은 커머디티 머신들(commodity machines)의 공유된 클러스터들을 이용하여 수행될 수 있을 것이다. 'The Datacenter as a Computer:An Instroduction to the Design of Warehouse-Scale Machines'(L.A. Barroso와 U.Holzle 지음, Morgan & Claypool 출판사, 2009년)를 참조한다. 클러스터는 자원을 공유하고, 폭넓게 달라지는 워크로드(workloads)들을 갖으며, 다른 하드웨어 파라미터들을 갖는 머신들 상에서 구동되는 다수의 분산된 애플리케이션들(multitude of distributed applications)을 호스팅할 수 있을 것이다. 분산된 애플리케이션 내의 개별 컴퓨팅 머신은 주어진 작업을 처리하는데 있어서 다른 컴퓨터 머신보다 더 오래 걸리거나, 또는 클러스터 관리 시스템에 의한 선점(preemption) 또는 장애(failures)로 인해 완료되지 못할 수도 있다. 그러므로, 스트래글러(straggler)들(예컨대, 심각한 잠재물(latency)을 갖는 컴퓨팅 작업들) 및 장애물(failures)을 처리하여 빠른 실행 및 고장 허용 한계(fault tolerance)를 성취할 수 있다. '맵리듀스로 1PB를 분류하기(Sorting 1PB with MapReduce)'(G. Czajkowski 지음, 공식 Google Blog, 2008년 11월, http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html)를 참조한다.

웹(web)과 과학적 컴퓨팅(scientific computing)에 사용되는 데이터는 종종 비관계적(nonrelational)이다. 그러므로, 이러한 도메인(domain)들에서는 유연한 데이터 모델(flexible data model)이 유익할 수 있다. 프로그래밍 언어들, 분산된 시스템들에 의한 메시지 교환, 웹 트래픽 로그들(web traffic logs) 등에서 사용되는 데이터 구조들은 그들 자신에게 내포된 표현(nested representation)을 제공할 수 있다. 예를 들면, 데이터의 내포된 표현은 각각이 몇 레벨의 자식 필드를 포함하는 다수의 필드들을 포함할 수 있다. 일부 자식 필드들은 상응하는 데이터(corresponding data)를 포함할 수 있다. 웹(web) 스케일에서 그러한 데이터를 정규화(normalizing)하고 재결합(recombining)하는 것은 계산적으로 많은 비용이 필요할 수 있다. 내포된 데이터 모델은 주요 웹 기업들에서 일부 구조화된 데이터 처리의 기저를 이룬다.

본 명세서는 커머디티 머신(commodity machine)들의 공유된 클러스터를 통해 매우 큰 데이터세트(datasets)의 인터렉티브 분석을 지원하는 시스템을 설명한다. 종래 데이터베이스들과는 달리, 이것은 내포된 데이터의 원래의 제 위치상에서 운용할 수 있다. '원래의 제 위치상에서'('In situ')란 예를 들면, 구글 파일 시스템과 같은 분산된 파일 시스템('The Google File System': S. Ghemawat, H. Gobioff 및 S.-T. Leung 지음, In SOSP, 2003년. 참조) 또는 Bigtable과 같은 다른 스토리지 레이어(storage layer)('Bigtable: A Distributed Storage System for Structured Data': F. Chang, J. Dean, S. Ghemawat, W.C. Hsieh, D.A. Wallach, M. Burrows, T. Chandra, A. Fikes, 및 R. Gruber 지음, In OSDI, 2006년. 참조)에서 '그 자리에서(in place)' 데이터를 액세스하는 능력을 일컫는다.

이 시스템은 아주 짧은 실행시간이지만, 맵리듀스 작업들(jobs)의 시퀀스를 통상적으로 요구할 수 있는 그런 데이터에 대해 많은 쿼리들을 실행할 수 있다. 'MapReduce: Simplified Data Processing on Large Clusters'(J.Dean 및 S. Ghemawat 지음, In OSDI, 2004년)을 참조한다. 설명된 시스템은 맵리듀스 파이프라인들 또는 신속하게 프로토타입 대량 연산들(prototype larger computations)의 출력들을 분석하기 위해 맵리듀스와 결합되어 사용될 수 있다. 이 시스템을 이용한 사례들은 하기를 포함한다.

● 웹 로그(web logs) 및 크롤된 웹 문서(crawled web documents)에 대한 분석;

● 온라인 마켓플레이스(online marketplace)에 의해 제공되는 애플리케이션을 위한 인스톨 데이터(lnstall data);

● 애플리케이션 제품들을 위한 크래쉬 데이터(crash data);

● 멀티미디어 재생 통계(miltimedia playback statistics);

● 북 스캔한 것(scans of books)으로부터의 OCR 결과;

● 스팸 분석(spam analysis);

● 맵 타일(map tiles)의 디버깅;

● 관리되는 빅테이블 인스턴스(managed Bigtable instances) 내의 태블릿 마이그레이션(tablet migrations);

● 분산된 빌드 시스템(distributed build system) 상에서 구동하는 테스트들의 결과;

● 수십만 개의 디스크에 대한 디스크 I/O 통계;

● 몇 개의 데이터 센터들을 거친 맵 리듀스 작업들의 실행 로그들(execution logs); 및

● 코드베이스(codebase) 내의 심볼들(symbols) 및 디펜던시들(dependencies).

설명된 시스템은 웹 탐색 및 병렬 데이터베이스 관리 시스템들로부터의 아이디어를 기반으로 한다. 첫째, 그 아키텍쳐(architecture)는 분산된 탐색 엔진에서 사용되는 서빙 트리의 개념을 기반으로 한다. 'Challenges in Building Large-Scale Information Retrieval Systems:Invited Talk'(J. Dean 지음,In WSDM, 2009년)을 참조한다. 웹 탐색 요청과 같은 쿼리는 각 단계에서 트리(tree) 아래로 푸쉬되어 재작성(rewritten)된다. 쿼리의 결과는 저레벨의 트리로부터 수신된 응답들을 모음으로써 취합함으로써 어셈블링된다.

둘째, 설명된 시스템은 ad hoc 쿼리들을 표현하는 하이레벨의 SQL-라이크(like) 언어를 제공한다. Pig('Pig Latin: a Not-so-Foreign Language for Data Processing', C. Olston, B. Reed, U. Srivastava, R. Kumar, 및 A. Tomkins 지음, In SIGMOD, 2008년 참조) 및 Hive(Hive. http://wiki.apache.org/hadoop/Hive, 2009년)와 같은 레이어들(layers)과는 대조적으로, 이 쿼리 시스템은 쿼리들을 맵리듀스 작업들로 변환하지 않고 그대로 실행한다.

마지막으로, 설명된 시스템은 컬럼-스트라이프(column-striped)형 스토리지 표현을 사용함으로써, 보조 스토리지(secondary storage)로부터 보다 적은 데이터를 판독할 수 있게 하고, 보다 저렴한 압축으로 인해 CPU 원가를 줄일 수 있게 한다. 컬럼(column)은 분석을 위해 내포된 데이터 모델들로 확장된 것으로 생각되지 않는 관계형 데이터를 저장한다('Column-Oriented Database Systems', D. J. Abadi, P.A. Boncz, 및 S. Harizopoulos 지음, VLDB, 2(2), 2009년). 설명된 컬럼형 스토리지 포맷은 MapReduce, Sawzall('Interpreting the Data:Parallel Analysis with Sawzall', R. Pike, S. Dorward, R. Griesemer, 및 S. Quinlan 지음, Scientific Programming, 13(4), 2005년 참조) 및 FlumeJava('FlumeJava: Easy, Efficient Data-Parallel Pipelines', C. Chambers, A. Raniwala, F. Perry, S. Adams, R. Henry, R. Bradshaw, 및 N. Weizenbaum 지음, In PLDI, 2010년 참조)에 의해 지원될 수 있을 것이다.

4 절에서, 본 명세서는 내포된 데이터를 위한 컬럼형 스토리지 포맷을 기술한다. 알고리즘들은 내포된 레코드들을 컬럼들로 나누고(dissect), 그것들을 리어셈블링(reassembling)하기 위해 제시된다.

5 절에서는, 컬럼형 스토리지 포맷으로 저장된 데이터를 처리하기 위한 쿼리 언어가 설명된다. 이 쿼리 언어 및 이 언어의 실행은 컬럼-스트라이프형 내포된 데이터 상에서 효율적으로 동작되도록 설계되고, 내포된 레코드들의 재구성(restructuring)을 요구하지 않는다.

6 절에서는, 웹 탐색 서빙 시스템들에서 사용되는 실행 트리(execution tree)들을 데이터베이스 처리에 적용하는 사례가 제공된다. 취합 쿼리들에 효율적으로 응답함에 따른 이익이 설명된다.

7 절에서는, 시스템 인스턴스 상에서 행해진 실험들이 소개된다.

2 절 : 예시적 시나리오(EXAMPLE SCENARIO)

웹-탐색 회사의 엔지니어인 엘리스(Alice)가 웹 페이지들로부터 새로운 종류의 시그널들을 추출해 내기 위한 아이디어를 찾아냈다고 가정한다. 그녀는 웹 페이지들로부터의 컨텐츠를 포함하고, 새로운 시그널들을 포함하며, 분산된 파일 시스템에 수십억개의 레코드들에 저장되는 데이터세트를 만들어내는 입력 데이터를 통해 크랭크(crank)하는 맵리듀스 작업을 구동시킨다. 그녀의 실험 결과를 분석하기 위하여, 그녀는 본 명세서에 설명된 시스템을 런칭하고 몇 개의 인터렉티브 명령들을 실행한다:

DEFINE TABLE t AS /path/to/data/*

SELECT TOP(signal1,100), COUNT(*)FROM t

엘리스의 명령들은 수 초 내에 실행한다. 그녀는 그녀의 알고리즘이 제기능을 한다는 것을 확인하기 위해 몇 개의 다른 쿼리들을 구동시킨다. 그녀는 시그널 1에서 불규칙성(irregularity)을 발견하고 자신의 출력 데이터세트(output dataset)에 대해 보다 복잡한 분석적 계산을 수행하는 FlumeJava 프로그램을 작성함으로써 더 자세히 연구한다. 쟁점(issue)이 정해지면, 그녀는 인입(incoming) 입력 데이터를 연속적으로 처리하는 파이프라인을 셋업(sets up)한다. 그녀는 다양한 차원들에 걸쳐서 자신의 파이프라인 결과를 취합하는 몇 개의 캔드 SQL 쿼리들(canned SQL queries)을 만들어내고, 이들을 인터렉티브 대시보드(interactive dashboard)(예컨대, 서비스를 설명하고, 서비스에 대한 통계들을 상세하게 설명하는, 서비스에 대한 웹페이지)에 추가한다. 결국, 그녀는 카달로그에 자신의 새로운 데이터세트를 등록하고, 그로 인해 다른 엔지니어들은 빠르게 해당 데이터세트의 위치를 찾아내고 쿼리할 수 있다.

상기한 시나리오는 쿼리 프로세서와 다른 데이터 관리 툴(tools)들 간의 상호연동(interoperation)을 요구할 수 있다. 그러한 상호연동을 위한 첫 번째 구성요소는 공통 스토리지 레이어(common storage layer)이다. 구글 파일 시스템(The Google File System)은 사용될 수 있는 이러한 분산된 스토리지 레이어(distributed storage layer)이다. 구글 파일 시스템은 수천의 머신들(machines) 및 수만개의 디스크들(disks) 전역에서 초대형 복제된 데이터세트들(replicated datasets)을 관리한다.

복제(replication)는 불완전한(faulty) 하드웨어더라도 데이터를 보존하는 것을 도우며, 스트래글러들의 존재시 빠른 응답 시간을 달성할 수 있게 한다. 고성능 공유 스토리지 레이어(a high-performance shared storage layer)는 제위치 데이터 관리(in situ data management)를 위한 인자(factor)를 가능하게 하는 것이 핵심이다. 이는 분석적인 데이터 처리(데이터베이스 관리 시스템이 데이터를 로드하고 단일 쿼리를 실행하는 것이 가능하기 전에, 수십개의 맵리소스를 구동하는 것이 가끔 가능한 경우)에서 데이터베이스 사용에 대한 주요 임피던스인 로딩 단계(loading phase)에서의 시간소모 없이 데이터를 액세스할 수 있게 한다. 예를 들면, 데이터베이스 관리 시스템이 데이터 분석에 사용될 때, 해당 데이터베이스는 'Insert' 명령들을 사용하여 데이터와 함께 로드될 필요가 있을 수 있다. 그러한 로딩(loading)은 설명된 시스템에 의해 요구되지 않을 수도 있다. 부가된 이익으로서, 파일 시스템 내의 데이터는 표준 툴(standard tool)들을 이용하여 예컨대, 다른 클러스터로의 전송, 접속권한(access privileges)의 변경, 또는 파일 이름에 기초한 분석을 위하여 데이터 서브셋의 식별하기 위해 편리하게 다뤄질 수 있다.

상호연동가능 데이터 관리 컴포넌트들을 구축하기(bulding) 위한 두 번째 구성요소는 공유 스토리지 포맷(shared storage format)이다. 컬럼형 스토리지는 수평 관계형 데이터에 사용되고 있지만, 컬럼형 스토리지를 내포된 데이터 모델에 적응시키는 것은 그 기술이 웹 데이터에 적용될 수 있게 한다. 도 1은 데이터 구조 내의 내포된 필드의 모든 값들이 인접하게 저장되는 개념을 예시한다. 예를 들면, 내포된 데이터의 컬럼-지향형 표현(column-oriented representation)에서, 데이터 구조 내의 특정 내포된 필드(예컨대, 필드 A.B.C)에 대한 모든 값들은 메모리 내에서 서로 인접하게 연속적으로 저장된다. 그러므로, 필드 A.B.C에 대한 값들은 필드 A.E로부터의 값들 및 필드 A.B.D로부터의 값들을 판독하지 않고 메모리로부터 검색될 수 있다.

이에 더하여, 데이터 구조의 다른 인스턴스들에 있는 동일한 특정 필드(예컨대, '레코드')에 대한 값들이 인접하게 저장될 수 있다. 예를 들면, 레코드 'r1'에 대한 필드 A.B.C의 값들은 레코드 'r2'에 대한 동일 필드의 값들에 인접하게 저장된다. 이와 반대로, 내포된 데이터의 '레코드-지향형' 표현에서는, 특정 레코드에 속한 모든 필드들의 값들이 연속적으로 저장된다. 다시 말해서, 특정 필드에 대한 데이터 값들은 함께 번치(bunched)되어 있지 않다.

설명된 컬럼형 스토리지 포맷을 처리하는 문제(challenge)은 모든 구조적 정보를 보존하는 방법, 및 필드들의 임의적 서브셋(an arbitrary subset of fields)으로부터 레코드들을 재구성가능한 방법이다. 본 명세서는 다음으로 컬럼형 스토리지 포맷으로 된 필드들이 채워지는 데이터를 논의하고, 이어서 컬럼평 스토리지를 처리하기 위한 알고리즘과 컬럼형 스토리지에 있는 데이터 상에서 처리하는 쿼리로 이동한다.

3 절: 데이터 모델(DATA MODEL)

이 절은 설명된 시스템이 사용하는 데이터 모델을 설명하고, 이후에 사용될 몇몇 전문용어들을 소개한다. 설명된 프로토콜 버퍼 데이터 모델(Protocol Buffers data model)은 분산 시스템의 맥락에서 고안되었으며, 이는 오픈 소스(open source) 구현으로서 가능하다. 'Protocol Buffers: Developer Guide'(http://code.google.com/apis/protocolbuffers/docs/overview.html)에서 취득가능)를 참조한다. 이 데이터 모델은 강형(strongly-typed)의 내포된 레코드들을 기반으로 한다. 그 추상구문(abstract syntax)은 다음과 같이 주어진다:

τ=dom｜＜A ₁ :τ[*｜?],...,A _n :τ[*｜?]＞

여기서, τ는 원자 타입(atomic type) 또는 레코드 타입(record type)이다. dom에 있는 원자 타입은 정수, 부동소수점수(floating-point numbers), 스트링(strings) 등을 포함한다. 레코드들은 하나 또는 다수의 필드로 구성된다. 레코드 내의 필드 i는 이름 Ai 및 선택적 다양성 레이블(optional multiplicity label)을 갖는다. 반복 필드(repeated field)들(*)은 하나의 레코드 내에서 여러 차례 일어날 수 있다. 그것들은 목록 된 값들, 즉 레코드 내의 필드 발생 차수(order of field occurrences)가 중요한 것으로 해석된다. 선택적 필드(optional fields)(?)는 레코드에서 소실(missing)될 수 있다. 그렇지 않다면, 필드가 요구(예컨대, 반드시 정확하게 한번 나타나야함)된다.

하나의 실례로서, 도 2는 웹 문서를 표현하는 레코드 타입 'Document' (record type 'Document')을 정의한 스키마(schema)를 도시한다. 이 스키마 정의(schema definition)는 프로토콜 버퍼 문법(Protocol Buffers syntax)을 사용한다. 'Document'는 다른 웹 페이지들의 'DocIds'를 보유하고 있는 'Forward' 및 'Backward' 엔트리들의 목록을 포함하는 필수 정수(required integer) 'DocId' 및 선택적 'Links'을 갖는다. 'Document'는 해당 문서가 참조될 수 있는 서로 다른 URL인 복수의 'Names'를 가질 수 있다. 하나의 'Name'은 하나의 'Code' 시퀀스와 (선택적) 'Country'의 쌍을 포함한다. 도 2는 또한 상기 스키마를 따르는 두 개의 샘플 레코드, r1 및 r2를 보여준다. 이 레코드 구조는 들여쓰기(indentation)를 사용하여 아웃 라인(outlined)되어 있다. 도 2에서 샘플 레코드 r1 및 r2는 본 명세서 전반에 걸쳐 알고리즘들을 설명하는데 사용된다. 이 필드들은 트리 계층의 스키마 형태로 정의된다. 내포된 필드의 전체 경로는 도트 표기법(dotted notation)을 이용하여 표시되는데, 예컨대, Name.Language.Code는 도 2에 도시된 'Code' 필드에 대한 전체 경로 이름이다.

내포된 데이터 모델은 직렬화 된 구조의 데이터(serializing structured data)에 대해 확장가능한 메커니즘인 플랫폼-뉴트럴(platform-neutral)을 지지한다. 코드 생성 툴(code generation tool)들은 C++ 또는 자바(Java)와 같은 다른 프로그래밍 언어들에 대한 바인딩(binding)을 만든다. 교차언어(cross-language) 상호연동능력은 필드 값들이 레코드 내에서 일어난 순서에 맞춰 순차적으로 배열되는 레코드의 표준 2진 온-더-와이어(on-the-wire) 표현을 이용하여 달성된다. 이 방식, 즉 자바(Java)로 작성된 맵리듀스 프로그램은 C++ 라이브러리를 통해 노출된 데이터 소스로부터 레코드들을 소비할 수 있다. 그러므로, 레코드들이 컬럼형 표현으로 저장되면, 그들을 빠르게 어셈블링(assembling)하는 것이 맵리듀스와 다른 데이터 프로세싱 툴(data processing tools)의 상호연동을 도울 수 있다.

4 절 : 내포된 컬럼형 스토리지(NESTED COLUMNAR STORAGE)

도 1에 도시된 바와 같이, 목표는 검색 효율(retrieval efficiency)을 높이기 위해 주어진 필드의 모든 값들을 연속적으로 저장하는 것이다. 본 절에서는, 컬럼형 포맷으로 된 레코드 구조의 무손실 표현에 대한 문제(4.1 절), 빠른 인코딩(4.2 절), 및 효율적인 레코드 어셈블리(4.3 절)가 설명된다.

4.1 절 : 반복 및 정의 레벨들(REPETITION AND DEFINITION LEVELS)

값들의 연속적인 목록이 단독으로 레코드의 구조를 전달(convey)하지는 않는다. 레코드 내에서 반복된 필드 내의 주어진 두 값들을 고려해 볼 때, 시스템은 값들이 반복되는 "레벨"(예컨대, 두 값들이 다른 레코드로부터의 것인지, 아니면 동일 레코드로부터의 것인지)을 결정하지 못할 수도 있다. 마찬가지로, 한 선택적 필드가 레코드로부터 소실된다면, 명확하게 둘러싸고 있는(enclosing) 레코드들이 정의되어 있는 값들 및 그렇지 않은 값들이 단독으로 전달하지 않을 수 있다. 반복 및 정의 레벨의 개념이 그래서 소개된다. 도 3은 도 1에 도시된 샘플 레코드에 있는 원자형 필드들(automic field)에 대한 반복 및 정의 레벨을 요약한 테이블들을 포함한다.

반복 레벨. 도 2에 도시된 'Code' 필드를 고려한다. 이것은 레코드 'r1'에서 세 번 발생한다. 'en-us' 및 'en'의 발생이 첫 번째 'Name' 필드 내부에 있고, en-gb'는 세 번째 'Name' 필드에 있다. 컬럼형 구조 내에서의 이러한 발생의 차이를 명확히 하기 위하여, 반복 레벨이 컬럼형 구조 내에 저장될 각 값에 첨부된다. 반복 레벨은 필드의 경로 내에서 어떤 반복될 필드가 반복되었는지를 나타낸다. 예를 들면, 필드 경로 Name.Language.Code는 반복되는 두 개의 필드('Name' 및 'Language')를 포함한다. 그러므로, 'Code'의 반복 레벨은 0과 2 사이의 범위이다. 레벨 0은 새로운 레코드의 시작을 나타내고, 레벨 1은 'Name' 필드에서의 최근의 반복을 나타내며, 레벨 2는 'Language' 필드에서의 최근의 반복을 나타낸다.

필드에 대한 레벨을 결정하는 것에 대한 예시로서, 레코드 'r1'이 위에서부터 아래로 스캔될 수 있다. 'en-us' 값이 처음 접해지고, 레코드 내에서 가장 최근에 반복된, Name.Language.Code 경로 내의 필드를 식별하기 위한 체크가 수행될 수 있다. 이 예시에서는, 어떠한 필드도 반복되지 않았으므로, 그 반복 레벨은 0이다. Name.Language.Code 경로에 대하여 'en'값이 다음으로 접해지고, 'Language' 필드가 가장 최근 반복된 필드로서 인식된다. 예를 들면, 'en'값에서부터 위쪽으로 스캐닝하면, 반복하고 있는 Name.Language.Code 경로 내의 첫 번째 필드는 'Language'이다. 따라서 반복 레벨은 2(예컨대, 'Language'가 반복하는 Name.Language.Code 경로 내의 두 번째 필드이므로, '2'가 그 'Language' 필드에 상응하기 때문)이다. 마지막으로, 'en-gb'값이 접해지면, 'Name' 필드가 가장 최근에 반복되었으므로('Name' 이후로 'Language' 필드가 오직 한번 발생함), 반복 레벨은 1이다. 다시 말해, 값에 대한 반복 레벨은 가장 최근 반복된 필드를 표현하는 수(數)일 수 있다. 따라서 레코드 'r1' 내부의 코드 값들의 반복 레벨은 0, 2, 1 이다.

레코드 'r1' 내의 두 번째 'Name' 필드는 'Code' 필드에 대한 어떠한 값도 포함하고 있지 않다는 유의하자. 'Name' 필드의 두 번째 인스턴스가 아닌 세 번째 인스턴스 내에 내포되어 있는 필드에 대한 값으로서 'en-gb'가 발생하였는지를 판단하기 위해, 컬럼형 구조 내에 저장된 바와 같이(도 3 참조), NULL 값이 'en'과 'en-gb' 값의 사이에 부가된다. 'Code'는 'Language' 필드의 필수 자식 필드(required child field)이므로, 'Code' 필드에 대한 값이 소실되었다는 사실은 곧 'Languag' 필드 또한 정의되지 않았음을 의미한다. 그러나 통상적으로, 내포 레코드가 존재하는 수준까지 레벨 업(level up)을 정하는 것은 추가적인 정보를 요구할 수 있다.

정의 레벨. 경로 'p'와 함께 필드의 각 값, 특히 모든 NULL 값은 경로 'p' 내에 정의되지 않았을 수 있는 필드(예컨대, 해당 필드들이 선택적이거나 반복되기 때문에)들이 현재 레코드 내에 얼마나 많이 존재하는지를 특정하는 '정의 레벨'을 갖는다. 예시하자면, 레코드 'r1'은 'Links' 필드에 대하여 'Backward' 필드들을 갖고 있지 않음을 볼 수 있다. 그럼에도 불구하고, 'Link' 필드는 정의되어 있다.(레벨 1) 이 정보를 보존하기 위하여, 정의 레벨 1과 함께 NULL 값이 'Links.Backward' 컬럼(column;열)에 부가된다.

다시 말해, 'Links.Backward' 경로에 대하여 레벨 1을 특정하는 것은 선택적이거나 또는 반복되는 두 개의 필드(즉, 'Link' 필드 및 'Backward' 필드)를 포함하는 경로 내에 선택적이거나 반복적인 '1' 필드(즉, 'Links' 필드)가 정의되어 있다는 것을 나타낸다. 따라서 정의 '1'은 'Backward' 필드가 인스턴스화되지 않았다는 것을 나타낸다. 마찬가지로, 레코드 'r2' 내의 'Name.Language.Country'의 소실 발생은 정의 레벨 1을 가지지만, 레코드 'r1' 내의 'Name.Language.Country'의 소실 발생은 각각 정의 레벨 2('Name.Language' 안에)와 1('Name' 안에)을 갖는다. 이상 개시된 인코딩 프로시저(encoding procedure)는 레코드 구조를 손실없이 보존할 수 있다.

인코딩. 메모리에 저장된 바와 같이, 특정 필드에 상응하는 각 컬럼은 반복 및 정의 값들의 인접하는 목록을 포함하는 헤더(Header)와 함께 저장될 수 있으며, 실질적인 값들의 인접하는 목록이 뒤이어 저장될 수 있다. 반복 및 정의 값 각각은 비트 시퀀스(bit sequence)들로 저장(예컨대, 단일 바이트 내에)될 수 있다. 예를 들면, 한 바이트 중 처음 4비트는 특정 값에 대한 반복 레벨을 표현하는데 사용될 수 있고, 나머지 4비트는 정의 레벨을 표현하는데 사용될 수 있다. 일부 예시들에서, 구분 문자(delimiters)가 사용될 수 없을 수도 있으므로, 헤더는 비트 수의 길이에 대한 정의를 포함할 수 있다. 따라서 오직 비트 만이 필연적으로서 사용될 수 있다. 예를 들면, 최대 정의 레벨이 3이면, 정의 레벨 당 2비트(bits)가 사용될 수 있다.

따라서 단일 필드(예컨대, 'Name.Language.Code' 필드)에 대한 컬럼형 데이터의 표현은 상응하는 값들의 시퀀스(corresponding sequence of values)에 대한 반복 및 정의 레벨들을 표현하는 바이트들의 시퀀스(sequence of values)에 이어서 값들의 시퀀스가 함께 메모리에 저장될 수 있고, 값들의 열(sequence)이 뒤이어 올 수 있다. 그러나, NULL 값들은 정의 레벨을 분석함으로써 정해질 수 있기 때문에 명시적으로 저장되지 않을 수 있다. 예를 들어, 어떤 필드의 경로 내에 있는 반복 및 선택적 필드들의 수보다 작은 임의의 정의 레벨은 NULL을 나타낼 수 있다. 따라서 시스템은 연속적인 값들의 목록 내에서, NULL 값이 어디에 삽입되거나 나타내져야(infer) 하는지를 정할 수 있다. 일부 예시에서, 정의 레벨들은 항상 정의되어 있는 값들에 대해서 저장되지 않는다. 마찬가지로, 반복 레벨들은 필요할 경우에만 저장될 수 있다. 예를 들면, 정의 레벨 0은 반복 레벨 0을 의미하므로, 후자는 생략될 수 있다. 사실상, 도 3에 예시된 구조를 참조하면, 'DocID' 필드에 대해서 어떠한 레벨도 저장되지 않을 수 있다.

메모리 내의 컬럼형 데이터의 표현은 블록들의 세트로 나뉠 수 있다. 각 블록은 반복 및 정의 레벨 정보를 포함하는 헤더와, 그 필드에 대한 값들의 후속 목록을 포함할 수 있다. 각 헤더는 블록 내 값들의 허용 범위를 나타내는 'constraint' 값을 포함할 수 있다. 따라서 설명된 시스템은 시스템이 관심있어 하는 데이터를 포함하는 블록들을 식별해낼 수 있다. 또한, 'constraint'값은 값들의 다른 특성(예컨대, 그 값들이 분류되어 있는지 여부)을 나타낼 수 있다. 일반적으로, 'constraint'는 블록 내에서 어떤 종류의 값들이 발견되었는지에 관한 'assertion'로서 고려될 수 있다. 각 블록은 압축될 수 있다.

4.2 절: 레코드들을 컬럼으로 분해하기(SPLITTING RECORDS INTO COLUMNS)

상기한 설명은 컬럼형 포맷에서의 레코드 구조의 인코딩을 제시하였다. 문제는 반복 및 정의 레벨들로 컬럼 스트라이프를 효율적으로 생산하는 방법이다. 반복 및 정의 레벨들을 계산하기 위한 기본 알고리즘이 아래에 제공된다. 이 알고리즘은 레코드 구조로 리커스(recurse)하고 각 필드 값에 대한 레벨을 계산한다. 앞서 예시된 바와 같이, 필드 값이 소실되었더라도 반복 및 정의 레벨은 계산될 필요가 있을 수 있다. 많은 데이터세트들이 빈약(sparse)하고, 수천 필드들 가운데 주어진 레코드에서 사용되는 것은 불과 수백 필드에 불과한 스키마를 갖는 것이 보기 드문 일이 아닐 수 있다. 그러므로, 소실 필드들을 가능한 값싸게 처리하는 것이 유익할 수 있다. 컬럼 스트라이프들을 생산하기 위해, 그 구조가 스키마 내의 필드 계층에 매칭하는 필드 라이터들의 트리(a tree of field writers)가 생성된다. 기본적인 개념은 필드 라이터들이 자신의 데이터를 가지고 있을 때, 그 필드 라이터들을 업데이트시키고, 절대적으로 필요한 상황이 아니면 그 트리 아래로 부모 스테이트(parent state)를 전파시키지 않도록 하는 것이다. 이와 같이 하기 위하여, 자식 라이터가 그들의 부모로부터 레벨을 물려받는다. 자식 라이터는 새로운 값이 부가될 때마다, 그 부모의 레벨로 동기화한다.

레코드를 컬럼으로 분해하는 한 예시적 알고리즘이 도 4에 도시되어 있다. 'DissectRecord' 프로시저가 2진-인코딩된 레코드들을 트래버스하기 위해 사용되는 'RecordDecoder'의 인스턴스에 대해 패스(pass)된다. 'FieldWriters'는 입력 스키마의 트리 계층(tree hierarchy)과 동일한 모양의 트리 계층을 형성한다. 루트 'FieldWriter'는 반복레벨이 0으로 설정된, 새로운 레코드 각각에 대한 알고리즘에 대해 패스된다. 'DissectRecord' 프로시저의 주된 작업은 현재의 '반복레벨'을 유지관리하는 것이다. 현재의 '정의레벨'은 해당 필드의 경로 내에서 선택적 및 반복된 필드들의 수를 합한 값으로서, 현재 라이터의 트리 위치에 의해 고유하게 (uniquely) 정해진다.

알고리즘의 와일-루프(while-loop)(Line 5)는 주어진 레코드 내에 포함된 모든 원자형 및 레코드-밸류드 필드들(record-valued fields)에 대해서 반복한다. 'seenFields' 세트는 필드가 레코드 내에서 보이는지 여부를 추적(track)한다. 이것은 어떤 필드가 가장 최근에 반복되었는지를 판정하는데 사용된다. 자식 반복 레벨 'chRepetitionLevel'은 가장 최근에 반복된 필드의 레벨로 설정되거나 그렇지 않으면 자신의 부모의 레벨로 설정된다(Line 9-13). 이 프로시저는 내포된 레코드 상에서 반복적으로(recursively) 인보크(invoke)된다.(Line 18).

본 명세서는 레벨들을 누적(accomulate)하고, 축적된 레벨들을 저레벨 라이터(lower-level writers)로 느리게 전파하는 'FieldWriters'를 참조하였다. 이것은 (반복, 정의)레벨들의 시퀀스를 유지하는 넌-리프 라이터(non-leaf writer)에 의해 수행될 수 있다. 각 라이터는 또한 그것과 연관된 '버전'(version) 번호를 갖는다. 간단히 말해서, 라이터 버전은 레벨이 부가될 때마다 하나씩 증가된다. 그것은 자식이 자신이 동기화한 마지막 부모의 버전을 기억하는데 충분하다. 만일 자식 라이터가 언젠가 자신의 값(넌-널(non-null))을 갖는다면, 자식은 새로운 레벨을 패칭함으로써 자신의 상태를 부모와 동기시키고, 그런 이후에야 새로운 데이터를 부가한다.

입력 데이터는 수천의 필드와 수백만의 레코드들을 가질 수 있기 때문에, 모든 레벨을 메모리에 저장하는 것은 불가능할 수 있다. 일부 레벨들은 디스크 상의 파일 내에 임시로 저장될 수 있다. 비어있는 (서브)레코드들의 무손실 인코딩을 위하여, 비원자형 필드들(non-atomic fields)(예컨대, 도 2의 Name.Language)은 넌-널이 아닌 값을 제외한 레벨들만을 포함하는, 그들 자신의 컬럼형 스트라이프를 가질 필요가 있을 수 있다.

4.3 절: 레코드 어셈블리(RECORD ASSEMBLY)

컬럼형 데이터로부터 레코드들(예컨대, 레코드 'r1' 및 'r2')을 효율적으로 어셈블링하는 것이 레코드-지향형 데이터 프로세싱 툴(record-oriented data processing tools: 예컨대, MapReduce)에 있어서는 중요하다. 필드들의 서브셋이 주어진다고 하면, 목표는 마치 오리지널 레코드들이 선택된 필드들만을 포함하고 있었던 것처럼, 모든 다른 필드들은 없어진(stripped away) 상태로, 오리지널 레코드들을 재구성하는 것이다. 핵심 개념은 필드 값들 및 각 필드의 레벨을 판독하고, 출력 레코드들에 그 값들을 순차적으로 부가하는 유한 상태 기계(FSM)를 생성하는 것이다. FSM 상태는 각 선택된 필드에 대한 필드 리더(field reader)에 상응한다. 상태 천이(state transsition)는 반복 레벨을 붙인다. 리더가 값을 패치하면, 다음 반복 레벨이 다음으로 어떤 리더를 사용할 것인지 결정하기 위해 검사된다. FSM은 각 레코드에 대해 시작(start) 상태부터 끝 상태(end state)까지 한번에 트래버스된다.

도 5는 4.1 절에 설명된 블록들을 입력으로서 사용하여 설명중인 예시에서 완전한 레코드들을 재구성하는 FSM을 보여준다. 이 예시에서, 노드(node)들은 필드들로 라벨화되어 있고, 에지(edge)들은 반복 레벨들로 라벨화되어 있다. 시작 상태(start state)는 'DocID'이다. 'DocID' 값이 판독되면, FSM은 'Links.Backward' 상태로 천이한다. 모든 반복된 'Backward' 값들이 소모된(drained) 후, FSM은 'Links.Forward' 등으로 점프(jump)한다.

FSM 천이들이 어떻게 구성되는지 스케치하기 위해, 'I'가 'f' 필드에 대해 현재의 필드 리더가 리턴(return)한 다음 반복 레벨이 되게 한다. 스키마 트리(예컨대, 도 2의 스키마) 내의 'f'에서 시작하면, 레벨 'I'에서 반복하고 그 조상(ancestor) 내부에서 첫 번째 리프 필드(leaf field) 'n'을 선택하는, 그것의 조상이 발견된다. 이것은 FSM 천이 ('f';'I') → n을 제공한다. 예를 들면, 'I'=1 이 'f'= 'Name.Language.Country.'에 의해 판독된 다음 반복 레벨이 되게 한다. 반복 레벨 '1'을 갖는 그것의 조상은 Name이고, 조상의 첫 번째 리프 필드는 'n'='Name.Url'이다.

필드 서브셋에 대한 검색만이 필요하다면, 보다 저렴하게 실행할 수 있는 단순 FSM(a simpler FSM)이 구성될 수도 있다. 도 6은 'DocID' 필드 및 'Name.Language.Country' 필드를 판독하기 위한 FSM을 도시한다. 도면은 오토머턴(automaton)에 의해 생산된 출력 레코드 's1' 및 's2'를 보여준다. 인코딩 및 어셈블리 알고리즘이 'Country' 필드를 둘러싸고 있는 구조를 유지하고 있음에 주목하자. 이것은 예컨대, 두 번째 Name의 첫 번째 Language에 나타나는 Country를 액세스해야 하는 애플리케이션을 위해 중요할 수 있다. X 경로에서, 이것은 /Name[2]/Language[1]/Country와 같은 표현들을 평가하는 능력(ability to evaluate)에 상응할 수 있다.

FSM 구성 프로시저 . 도 7은 레코드 어셈블리를 수행하는 유한 상태 기계를 구성하기 위한 알고리즘을 나타낸다. 이 알고리즘은 레코드 내에 상주(populate)되어야만 하는 필드들을 입력으로서 취하는데, 그 순서는 그 필드들이 스키마에 나타나는 순서를 따른다. 이 알고리즘은 두 필드의 '공통 반복 레벨', 이는 그들의 가장 낮은 공통 조상의 반복 레벨이다. 예를 들면, 'Links.Backward'과 'Links.Forward'의 공통 반복 레벨은 1이다. 두 번째 개념은 '베리어'(barrier)의 그것인데, 이것은 시퀀스에서 현재의 필드 후에 있는 다음 필드이다. 직관(intuition)은 베리어가 히트(hit)되어 이전에 보여졌던 필드로의 점프를 요구할 때까지, 각 필드가 하나씩 처리되도록 시도되는 것이다.

이 알고리즘은 세 개의 단계로 구성된다. 1단계(라인 6-10)에서는, 공통 반복 레벨들이 역방향(backward)으로 처리된다. 이들은 증가되지 않도록(non-increasing) 보장된다. 접해진 각 반복 레벨에 대하여, 시퀀스 내의 가장 왼쪽 필드(the left-most field)가 선택되는데, 즉 상기 필드는 그 반복 레벨이 'FieldReader'에 의해 리턴될 때 천이될 필드이다. 2단계에서는, 그 간격(gap)이 채워진다(라인 11-14). 이 간격은 라인 8에서 계산된 공통 반복 레벨들 내에 모든 반복 레벨들이 존재하지 않기 때문에 생겨난다. 3단계(라인 15-17)에서는, 모든 레벨들에 대한 천이가 베리어 필드로 점프할 수 있는 베리어 레벨과 같거나 그 이하로 설정된다. 만일 'FieldReader'가 그와 같은 레벨을 생산하였다면, 내포된 레코드는 계속하여 구성될 수도 있으며, 베리어에 반사되어 나올 필요가 없을지도 모른다.

어셈블 레코드 프로시저. 어셈블 레코드 프로시저(도 8에 도시됨)는 'FieldReaders'의 세트 및 (암시적으로) 리더들(reader)간의 상태 천이를 갖는 FSM을 입력으로서 취한다. 다시 말해서, 이 알고리즘은 FSM 및 컬럼형 데이터에 대해 연산하고, 구성된 레코드를 출력한다. 가변 리더(variable reader)는 메인 루틴(main routine)(라인 4)에 현재 'FieldReader'를 유지(hold)한다. 가변 리더는 레코드에 추가되는 값을 갖는 마지막 리더을 유지하며, 도 7에 도시된 세 개의 프로시저들 모두에 이용할 수 있다. 메인 와일-루프(while-loop)는 라인 5에 있다. 다음 값이 현재 리더(current reader)로부터 패치(fetch) 된다. 만일 그 값이 NULL이 아니면, 이는 그 정의 레벨을 조사함으로써 판단되는데, 이 어셈블링되고 있는 레코드는 메소드 'MoveToLevel'에서 현재 리더의 레코드 구조에 동기화되고, 그 필드 값은 해당 레코드에 추가(append)된다. 다른 방법으로, 그 레코드 구조는 어떠한 값도 추가됨 없이 조정될 수 있다- 빈 레코드들이 존재하는 경우 행해질 수 있음. 라인 11 상에서, 'full definition level'이 사용되었다. 정의된 레벨 인자들이 필수 필드들(반복 및 선택적 필드들만이 카운트됨)에서 나온 것임을 상기(recall)한다. 전체 정의 레벨(full definition level)은 모든 필드들을 고려한다.

'MoveToLevel' 프로시저는 레코드를 'lastReader' 상태에서 'nextReader' 상태로 천이시킨다(라인 22 참조). 예를 들어, 'lastReader'가 도 2의 'Links.Backward'에 상응하고, 'nextReader'가 'Name.Language.Code'라고 가정한다. 이 메소드는 그 순서에 따라 내포된 레코드 링크를 종료하고, 새로운 레코드 Name 및 Language를 시작한다. 'ReturnsToLevel' 프로시저(라인 30)는 임의의 새로운 레코드들을 시작하지 않고 현재 레코드들을 종료하기만 하는 'MoveToLevel'의 대응물(counterpart)이다.

그것들의 온-더-와이어 표현에서는, 레코드들이 필드 값이 뒤따르는 필드 식별자(field identifier)의 쌍들로 마련된다. 내포된 레코드들은 XML과 유사한 (실제 바이너리 인코딩은 다를 수 있음) '오프닝 태그'(opening tag) 및 '클로징 태그'(closing tag)를 갖는 것으로 여겨질 수 있다. 레코드를 '시작한다'는 것에 대한 설명은 오프닝 태그들을 기록하는 것에 관련되고, 레코드를 ' 끝낸다'는 것에 대한 설명은 크로징 태크들을 기록하는 것에 관련된다.

5 절: 쿼리 언어(QUERY LANGUAGE)

설명된 시스템은 SQL을 기반으로 한 쿼리 언어를 사용할 수 있으며, 컬럼형 내포된 스토리지 상에 효율적으로 구현될 수 있도록 설계된다. 이 쿼리 언어의 양태(aspect)들이 본 명세서에서 설명된다. 각 SQL-like 선언문(및 SQL-like 선언문으로 번역되는 대수학 연산자(algebraic operator)들)은 하나 또는 다수의 내포된 테이블들(예컨대, 4.1 절에서 설명된 바와 같이, 테이블을 표현하는 컬럼형 데이터의 압축된 블록들의 세트) 및 그들의 스키마들을 입력으로서 취하고, 내포된 테이블(예컨대, 컬럼형 데이터의 변경된 인스턴스)과 그것의 출력 스키마를 만든다. 도 9는 프로젝션(projection), 셀렉션 및 레코드-내 취합(within-record aggregation)을 수행하는 하나의 샘플 쿼리를 도시한다. 이 쿼리는 도 2로부터의 테이블 t={r1,r2}를 통해 평가된다. 이 필드들은 경로 표현(path expression)들을 이용하여 참조된다. 이 쿼리는 쿼리 내에 존재하는 레코드 생성자(record constructor)가 없더라도 내포된 결과를 만든다.

쿼리가 하는 일을 설명하기 위해, 선택 연산(WHERE 구문)을 고려한다. 각 라벨이 파일 이름에 상응하는 라벨화된 트리(labeled tree)로서 내포된 레코드에 대해 생각해 본다. 선택 연산자는 특정 조건을 만족하지 않는 트리의 가지(branch)들을 잘라내 버린다. 따라서 'Name.Url'이 정의되고 'http'로 시작하는 그들의 내포된 레코드들만 유지(retain)된다. 다음으로, 프로젝션을 고려해 보자. SELECT 구문 내의 각 스칼라 표현(scalar expression)은 그 표현에서 사용된 가장 많이 반복된 입력 필드(most-repeated input field)로서, 동일한 내포 레벨에서의 값(a value at the same level of nesting)을 방출한다. 그래서, 문자열 연결 표현(string concatenation expression)은 입력 스키마 내의 'Name.Language.Code'의 레벨에서 'Str' 값을 방출한다.

카운트(COUNT) 표현은 레코드-내 취합을 설명한다. 취합은 각 'Name' 서브레코드 내에서 완료되고, 음이 아닌(non-negative) 64비트 정수(uint64)로서 각 'Name'에 대한 'Name.Language.Code'의 발생 횟수를 방출한다. 따라서 WITHIN 선언문은 인트라-로우 취합(intra-row aggregation)을 인에이블(enable) 시킨다. 다시 말해서, 동일 이름의 레코드들은 동일 레코드 또는 동일 자식 아래에서 취합될 수 있다. 이와 대조적으로, 내포된 데이터에 대해 연산할 수 없을 수도 있는 SQL은 인트라-로우 레코드에 대해 연산이 불가할 수도 있다.

이 언어는 중복된 서브쿼리(nested subquerie)들, 인터 및 인트라 레코드(inter and intra-record) 취합, top-k, 조인스(joins), 사용자-정의 함수(user-defined function)들 등을 지원한다. 이들 특징 중 일부가 실험 절(experimental section)에서 논의된다. 하나의 추가적인 예시로서, 설명된 쿼리 언어는 값들의 인트라-로우 그룹(intra-row group)을 필터링할 수 있는 OMIT IF 선언문을 포함한다. 예를 들면, 수천 개의 레코드들 각각은 그 각각이 숫자 값을 포함하는 몇 개의 반복된 'Cost' 필드를 포함할 수 있다. 필드들 내의 값들의 합이 숫자 '20'을 초과하는 경우, 쿼리 언어의 사용자는 모든 레코드들을 없애버리고 싶어할 수 있다. 따라서 사용자는 각 레코드 내의 합산된 'Cost'가 20 이하인 레코드들의 목록을 생성하기 위해 OMIT IF 선언문을 사용할 수 있다.

6 절: 쿼리 실행(QUERY EXECUTION)

트리 아키텍쳐 ( Tree Architecture ). 설명된 시스템은 쿼리들을 실행하기 위하여 멀티-레벨 서빙 트리(multi-level serving tree)를 사용한다(도 10 참조). 루트 서버가 인입 쿼리들을 수신하고, 그 테이블들로부터 메타데이터(metadata)를 판독하고, 서빙 트리 내에 있는 다음 레벨로 쿼리들을 라우팅한다. 리프 서버들은 스토리지 레이어(storage layer)와 통신하거나 또는 로컬 디스크 상의 데이터를 액세스 한다. 설명된 시스템에서 동작하는 많은 쿼리들은 싱글-스캔(single-scan) 취합들이다; 따라서 본 명세서는 그에 대한 설명에 집중하고, 다음 절에서는 실험을 위해 이것들을 사용한다. 아래와 같은 간단 취합 쿼리를 고려한다.

SELECT A, COUNT(B) FROM T GROUP BY A

루트 서버가 상기한 쿼리를 수신하면, 서버는 테이블 'T'를 포함하는 모든 테블릿들(즉 테이블의 수평 분할(horizontal partition))을 정하고, 그 쿼리를 아래와 같이 다시 작성한다.

SELECT A, SUM(c) FROM (R₁ ¹ UNION ALL ...R_n ¹) GROUP BY A

R₁ ¹ UNION ALL ...R_n ¹ 테이블들은 서빙 트리의 레벨 1에서 노드 1, ....., n 으로 전송되어진 쿼리들의 결과이다.:

R¹ _i) = SELECT A, COUNT(B) AS c FROM T_i ¹ GROUP BY A

T_i ¹은 레벨 '1'에서 서버 'I'에 의해 처리된 'T' 에 있는 태블릿들의 분해된 파티션(disjoint partition)이다. 각 서빙 레벨은 유사한 재작성(rewriting)을 실행한다. 최종적으로, 'T'에 있는 태블릿들을 평행하게 스캔하여, 쿼리들이 리프들(leaves)에 도달한다. 그 진행중에, 중개 서버들은 부분적 결과들의 병렬 취합(parallel aggregation)를 수행한다. 위에서 제시된 실행 모델은 소형 및 중형 사이즈 결과를 리턴하는, 매우 일반적인 클래스의 쿼리들을 취합하는데 아주 적합하다.

쿼리 디스패처 ( Query Dispatcher ). 설명된 시스템은 예컨대, 여러 개의 쿼리들이 동시에 실행될 수 있는 멀티-유저 시스템이다. 쿼리 디스패처는 그들의 우선 순위(priorities)를 기초하여 쿼리들을 스케쥴링하고, 부하를 분산시킨다. 그 밖의 다른 역할은 한 서버가 다른 서버들에 비해 현저하게 느려지거나 또는 어떤 태블릿 복제본(tablet replica)이 도달할 수 없게(unreachable) 되었을 때, 고장 허용 한계를 제공하는 것이다.

각 쿼리에서 처리된 데이터의 양이 실행을 위해 이용할 수 있는 프로세싱 유니트(슬롯(slots)으로 일컬어짐)들의 수보다 클 때가 종종 있다. 슬롯은 리프 서버 상의 실행 스레드(execution thread)에 상응한다. 예를 들면, 각각이 8개의 스레드를 사용하는 3,000개의 리프 서버로 된 시스템은 24,000슬롯을 갖는다. 그래서, 100,000개의 태블릿을 스패닝(spanning)하는 테이블은 각 슬롯에 약 5개의 태블릿을 할당함으로써 처리될 수 있다. 쿼리 실행이 진행되는 동안, 쿼리 디스패처는 태블릿 처리 시간(tablet processing time)의 히스토그램(histogram)을 계산한다. 만일 태블릿이 처리에 균형에 맞지 않게 긴 시간이 걸리면, 시스템은 다른 서버에 있는 해당 태블릿을 다시 스케쥴링한다. 일부 태블릿들은 여러 번(multiple times) 재 디스패치(redispatch)될 필요가 있을 수 있다.

리프 서버들은 컬럼형 표현 내의 내포된 데이터의 스트라이프(tripes of nested data)들을 판독한다. 각 스트라이프 내의 블록들은 비동기적으로 프리패치(prefetch)되는데; 사전-판독 캐시(read-ahead cache)는 일반적으로 95%의 히드 레이트(hit rate)를 달성한다. 태블릿들은 통상 쓰리-웨이(three-way) 복제된다. 리프 서버가 하나의 태블릿 복제본(tablet replica)을 액세스할 수 없을 때, 그 리프 서버는 다른 복제본에 접근(fall over)한다.

쿼리 디스패처는 결과를 리턴하기 전에 반드시 스캔되어야 하는 태블릿의 최소 퍼센트(minimum percentage)를 특정하는 파라미터를 수신(honor)한다. 이하에 설명되는 것처럼, 이러한 파라미터를 낮은 값(예컨대, 100% 대신에 98%)으로 설정하는 것(특히 더 작은 복제 인자(replication factor)를 사용할 때)은 종종 실행 속도를 올릴 수 있다.

각 서버는 도 7의 오른쪽에 도시된 바와 같이, 내부 실행 트리(internal execution tree)를 가질 수 있다. 내부 트리는 스칼라 표현의 평가(evaluation)를 포함하는 물리적 쿼리 실행 계획(physical query execution plan)에 따른다. 최적화된 유형-특정 코드(type-specific code)가 대부분의 스칼라 함수들을 위해 생성된다. 기본 실행 계획(basic execution plan)은 쿼리를 실행하는 동안 완전하게 레코드 어셈블리를 바이패싱시키면서, 락스텝(lockstep)에서 입력 컬럼들을 스캔하고, 정확한(correct) 반복 및 정의 레벨을 주석으로 달고 있는 스칼라 함수들을 방출하는 반복자(iterator)들의 세트로 구성된다.

설명된 시스템에 의한 일부 쿼리(예컨대, top-k 및 count-distinct)는 잘 알려진 싱글-스캔 알고리즘을 이용하여 대체로 정확한(approximate) 결과를 리턴한다.

7 절: 실험 데이터(EXPERIMENTAL DATA)

이 절은 몇 개의 데이터세트상에서 설명된 시스템의 실험 평가를 제공하며, 내포된 데이터에 대한 컬럼형 스토리지의 유효성을 검사한다. 이 연구에서 사용되는 데이터세트의 특성은 도 11에 요약되어 있다. 압축되지 않은 상태에서, 비복제 형태의 데이터세트들은 약 1페타바이트(petabyte)의 공간을 차지한다. 모든 테이블은 쓰리-웨이 복제되고, 원 투-웨이 복제 테이블을 제외하며, 100K에서부터 800K 까지의 다양한 크기의 태블릿(tablet)을 포함한다. 이 절은 단일 기계상에서 기본 데이터 액세스 특징들을 조사하는 것으로 시작하고, 이어 컬럼형 스토리지가 맵리듀스 실행을 어떻게 이롭게 하는지를 보여주고, 마지막으로 설명된 시스템의 성능(performance)에 초점을 맞춘다. 이 실험은 일반적인 비지니스 운영을 행하는 동안, 많은 다른 애플리케이션에 대해 2개의 데이터 센터에서 구동중인 시스템 인스턴스(system instance)들에 대해 실시되었다. 하기에서 사용되는 테이블 및 필드 이름들은 익명화되어 있다.

로컬 디스크. 첫 번째 실험에서, 컬럼형 대 레코드 지향형 스토리지의 성능 트레이드오프(performance tradeoff)들이 약 300K행(row)들을 포함하는 테이블(T1)의 1GB 프라그먼트(fragment)를 스캔함으로써 조사된다(도 12 참조). 데이터는 로컬 디스크에 저장되고, 압축된 컬럼형 표현으로 약 375MB를 차지한다. 레코드-지향형 포맷은 더 강한 압축을 사용하지만, 디스크상에 대략 동일한 크기로 된다. 이 실험은 70MB/s 판독 대역폭(read bandwidth)을 제공하는 디스크를 갖는 듀얼-코어 인텔 기계상에서 행해졌다. 모든 보고 시간은 찾기 어렵고(cold), OS 캐시는 각 스캔 이전에 비워졌다.

도 12는 필드의 서브셋에 대해, 데이터를 판독하고 압축 해제(decompress)에 걸리는 시간, 레코드들을 어셈블링하고 파싱하는데 걸리는 시간을 예시하는 5개의 그래프를 나타낸다. 그래프 (a)-(c)는 컬럼형 스토리지에 대한 결과를 도시한 것이다. 이들 그래프에 있는 데이터 포인트 각각은 30번 구동하는 동안의 측정값을 평균냄으로써 얻어진 것으로서, 각각의 데이터 포인트에는 랜덤하게 선택된 주어진 원소수(cardinality)를 갖는 컬럼들의 세트가 있다. 그래프 (a)는 판독 및 압축 해제 시간을 나타낸다. 그래프 (b)는 컬럼들로부터 내포된 레코드들을 어셈블링하는데 필요한 시간을 더한 것이다. 그래프 (c)는 레코드들을 강형 C++ 데이터 구조로 파싱하는데 얼마나 많은 시간이 걸리는지를 보여준다.

그래프 (d)-(e)는 레코드-지향형 스토리지상의 데이터에 액세스하기 위한 시간을 도시한 것이다. 그래프 (d)는 판독 및 압축 해제 시간을 나타낸다. 대부분이 시간이 압축 해제에 소요된다; 실제로, 압축된 데이터는 그 시간의 절반 내에 디스크로부터 판독될 수 있다. 그래프 (e)에 제시된 것처럼, 파싱에는 판독 및 압축 해제 시간의 상단에 또 다른 50%가 더해진다. 이것들의 비용은 필요하지 필드를 포함하여, 모든 필드에 대해 지불된다.

약간의 컬럼들이 판독될 때, 컬럼형 표현의 게인들이 거의 계산 차수일 수 있다. 컬럼형 내포된 데이터에 대한 반복 시간은 필드의 개수에 따라 선형적으로 증가할 수 있다. 레코드 어셈블리 및 파싱은 고가일 수 있으며, 각각은 잠재적으로 실행 시간의 두 배가 될 수 있다. 유사한 경향이 다른 데이터세트에서도 관찰되었다, 묻기(ask)에 대한 자연 질문(natural question)이 그래프의 상단 및 하단을 가로질러 있다. 즉, 레코드-와이즈 스토리지(record-wise storage)가 컬럼형 스토리지를 능가(outforming)하기 시작한다. 경험적으로, 교차 포인트(crossover point)가 수십개의 필드에 있을 수 있지만, 데이터세트 전역에서 바뀔 수 있고, 레코드 어셈블리가 필요한지 여부에 따라서 달라질 수 있다.

맵 리듀스 및 설명된 시스템. 다음으로, 맵리듀스 및 설명된 시스템의 실행이 컬럼 대 레코드 지향형 데이터에 대해 예시된다. 이 경우, 단일 필드가 액세스되고, 성능 게인들이 가장 확연하다(pronounced). 다수의 컬럼에 대한 실행 시간은 도 12에 도시된 결과를 사용하여 외삽(extrapolate)될 수 있다. 이 실험에서, 테이블 'T1'의 'txtField' 필드에 있는 용어(term)들의 평균 개수가 카운트된다. 맵리듀스 실험은 후술하는 쏘우젤(Sawzall) 프로그램을 사용하여 행해진다.

numRecs: table sum of int;

numWords: table sum of int;

emit numRecs <- 1;

emit numWords <- CountWords(input.txtField);

레코드의 개수가 변수 'numRecs.'에 저장된다. 각 레코드에 대해, 'numWords'가 'CountWords' 함수에 의해 리턴되는 'input.txtField'에 있는 용어 개수만큼 증가된다. 프로그램이 구동된 후에, 평균 용어 빈도가 numWords=numRecs로서 계산될 수 있다. SQL에서, 이 계산은 아래와 같이 표현된다:

Q₁: SELECT SUM(CountWords(textile)) / COUNT(*) FROM T1

도 13은 로그 스케일(logarithmic scale)에 대한, 2개의 맵리듀스 작업과 설명된 시스템의 시행 시간을 나타낸다. 2개의 맵리듀스 작업 모두는 3000개의 워커(예컨대, 서버들)상에서 구동된다. 마찬가지로, 본 시스템의 3000-노드 인스턴스가 쿼리 Q₁을 실행하는데 사용된다. 설명된 시스템과 맵리듀스-온-컬럼들은 약 0.5TB의 압축된 컬럼형 데이터 대 맵리듀스-온-레코드들에 의해 판독되는 87TB를 판독한다. 도 12에 도시된 바와 같이, 맵리듀스는 레코드-지향향에서 컬럼형 스토리지로 바뀜으로써, 효율면에서 계산 차수를 증가시킨다(수 시간에서 수 초까지). 또 다른 계산 차수가 설명된 시스템을 사용함으로써 달성된다(수 분에서 수 초로 됨)

서빙 트리 토폴로지 . 다음 실험에서는, 쿼리 실행 시간 동안 서빙 트리 뎁스(depth)의 영향이 예시된다. 2개의 GROUP BY 쿼리가 테이블 T2에 대해 수행되는데, 각각은 데이터에 대해 단일 스캔을 사용하여 실행된다. 테이블 T2는 240억개의 내포된 레코드를 가지고 있다. 각 레코드는 수량(numeric amount)을 가지는 반복된 필드 아이템을 구비한다. 필드 아이템.양(field item.amoumt)은 데이터세트에서 약 400억번 반복된다. 첫 번째 쿼리는 컨트리(country)에 의한 아이템 양을 합산한다.

Q₂: SELECT country, SUM(item.amount) FROM T2

GROUP BY country

수 백개의 레코드를 리턴하고 디스크로부터 약 60GB의 압축된 데이터를 판독한다. 다음 쿼리는 선택 조건으로 다음 필드 도메인 상에서 GROUP BY를 수행한다. 약 180GB를 판독하여, 약 110만개의 구별되는 도메인들을 만든다.

Q₃: SELECT domain, SUM(item.amount) FROM T2

WHERE domain CONTAINS '.net'

GROUP BY domain

도 14는 서버 토폴로지의 함수로서 각 쿼리에 대한 실행 시간을 나타낸다. 각 토폴로지에서, 복수의 리프 서버는 동일한 누적 스캔 속도(cumulative scan speed)를 가정할 수 있도록, 2900으로 일정하게 유지된다. 2-레벨 토폴로지(1:2900)에서는, 단일 루트 서버가 리프 서버들과 직접적으로 통신한다. 3 레벨의 경우에는, 1:100:2900 셋업이 사용되는데, 여기서 100은 엑스트라 레벨의 중개 서버를 나타낸다. 4-레벨 토폴로지는 1:10:100:2900이다.

3레벨이 서빙 트리에서 사용될 때, 쿼리 Q₂가 3초 내에 실행되므로, 엑스트라 레벨로부터의 이득이 크지 않다. 대조적으로, Q₃의 실행 시간은 증가된 병렬성(parallelism)으로 인하여 반으로 줄어든다. 2 레벨에서, Q₃는 수천개의 노드로부터 수신된 결과를 거의 연속적으로(near-sequentially) 취합하는데 필요한 루트 서버로서, 차트 밖으로 나간다. 이 실험은 어떻게 많은 그룹들을 리턴하는 취합값들이 멀티-레벨 서빙 트리로부터 이익을 얻을 수 있는지를 예시한다.

태블릿당 히스토그램들( Per - tablet Histograms ). 도 15는 Q₂ 및 Q₃의 특정 실행을 위하여, 리프 서버들이 얼마나 빠르게 타블랫들을 처리하는지를 나타낸다. 태블릿이 가용 슬롯에서 실행되도록 스케줄되었을 때(즉, 작업 큐에서 대기하는 시간 경과를 제외함), 그 지점에서 시작하여 시간을 측정한다. 이 측정 방법론은 동시에 실행하는 다른 쿼리들의 영향을 배제(factor out)한다. 각 히스토그램 아래 있는 영역은 100%에 상응한다. 도 15에 제시된 바와 같이, Q2(또는 Q3)의 99% 태블릿이 1초(또는 2초) 내에 처리된다.

레코드내 취합( Within - record Aggregation ). 다른 실험으로서, 쿼리 Q₄의 성능이 테이블 T3상에서 실행될 때 조사된다. 이 쿼리는 레코드내 취합을 예시하는데, 레코드내 취합은 레코드에서 발생하는 a.b.c.d 값들의 합이 a.b.p.q.r 값들의 합보다 클 경우, 모든 레코드를 카운트한다. 이 필드들은 서로 다른 내포 레벨로 반복한다. 컬럼 스트라이프링에 의해서, 단지 13GB(70TB 중에서)만이 디스크로부터 판독되어, 그 쿼리가 15초 내에 완료된다. 내포에 대한 지원이 없다면, T3에 대해 이 쿼리를 실행하는 것에 많은 비용이 들 수 있다.

Q₄ : SELECT COUNT(c1 > c2) FROM

(SELECT SUM(a.b.c.d) WITHIN RECORD AS c1, SUM(a.b.p.q.r)

WITHIN RECORD AS c2 FROM T3)

확장성( scalability ). 이어지는 실험은 1조(trillion)-레코드 테이블상에서 시스템의 확장성을 예시한다. 아래에 제시된 쿼리 Q₅는 테이블 T4에서 상위 20 애드(aid's) 및 그것들의 발생 횟수를 선택한다. 이 쿼리는 4.2TB의 압축된 데이터를 스캔한다.

Q₅: SELECT TOP(aid, 20), COUNT(^*) FROM T4

WHERE bid = {value1} AND cid = {value2}

이 쿼리는 1000 노드에서 4000노드까지의 범위에서, 시스템의 4가지 구성을 사용하여 실행되었다. 실행 시간은 도 16에 도시되어 있다. 각각의 실행에서, 총 소비된 CPU 시간은 약 300K초로 거의 동일하지만, 사용자-인지 시간(user-perceived time)은 시스템의 크기가 증가하는 것에 따라 거의 선형적으로 증가한다. 이 결과는 대형 시스템이 리소스 사용의 관점에서 소형 시스템만큼 효율적일 수 있다는 것을 제안하지만, 더 빠른 실행도 허용한다.

스트래글러들. 스트래글러들은 예를 들어, 태스크를 수행하는 기계가 작동상의 문제가 있거나 또는 그 기계가 주어진 높은-우선순위 태스크를 처리하기에 충분히 공격적(aggressive)이지 않기 때문에, 수행되지 않은 태스크들일 수 있다. 아래 쿼리 Q₆는 1조-열 테이블 T5 상에서 실행된다. 다른 데이터세트들과는 대조적으로, T5는 투-웨이 복제된다. 이런 이유로, 작업을 다시 스케쥴할 기회가 더 적어지기 때문에, 스트래글러들이 실행을 느리게 할 가능성이 더 높아진다.

Q₆: SELECT COUNT(DISTINCT a) FROM T5

쿼리 Q₆는 압축된 데이터를 1TB 이상 판독한다. 검색된 필드에 대한 압축율(compression rate)은 약 10이다. 도 17에 제시된 바와 같이, 태블릿들의 99%에 대한 처리 시간이 슬롯당 태블릿당 5초 미만이다. 그러나 2500 노드 시스템 상에서 실행될 때는, 쿼리 응답이 일분 미만에서 몇 분까지로 느려져서, 태블릿들의 일 부분이 더 긴 시간을 소모할 수 있다. 다음 절은 실험 결과(experimental finding)를 요약한다.

8절: 관찰(OBSERVATIONS)

도 18은 로그 스케일로, 설명된 시스템의 일반적인 한 달 워크로드에 대한 쿼리 응답 시간 분포(query response time distribution)를 나타낸다. 도 18에 제시된 바와 같이, 대부분의 쿼리는 양호한 인터렉티브 범위 내인, 10초 이내에 처리된다. 일부 쿼리들은 비지 클러스터(busy cluster)에서 초당 1000억 레코드에 가까운 스캔 처리량, 및 심지어 전용 기계에서는 더 높은 처리량을 실현하였다. 위에서 제시된 실험 데이터는 후술하는 관찰들을 제안한다.

● 스캔-기반 쿼리들은 수치 레코드들의 디스크-상주 데이터세트(disk-resident dataset)들에 대해 인터렉티브 속도로 실행될 수 있다;

● 컬럼들과 서버들의 개수면에서 거의-선형인 확장성이 수 천개의 노드들을 포함하는 시스템들을 위해 실현될 수 있다;

● 맵리듀스는 DBMS와 같은 컬럼형 스토리지로부터 이득을 얻을 수 있다;

● 레코드 어셈블리 및 파싱에 많은 비용이 들 수 있다. 소프트웨어 레이어들(쿼리 프로세싱 레이어의 상위에 있음)이 컬럼-지향형 데이터를 직접적으로 소비하기 위하여 최적화될 수 있다;

● 맵리듀스 및 쿼리 프로세싱은 한 레이어의 출력이 다른 레이어의 입력으로 제공되는, 보안적인(complementary) 방식에 사용될 수 있다;

● 멀티-사용자 환경에서, 대형 시스템은 질적으로 보다 나은 사용자 경험을 제공하면서, 스케일을 절약한다는 이익을 얻을 수 있다.

● 정확도에 대한 트레이딩 스피드(trading speed)가 허용가능하면, 쿼리는 좀 더 빨리 종료될 수 있고 대부분의 데이터도 볼 수 있다.

● 대부분의 웹-스케일 데이터세트가 마지막 몇 퍼센트로 갈수록 처리 시간의 양이 증가할 수 있음에도 불구하고, 빠르게 스캔될 수 있다.

도 19는 내포된 레코드들의 컬럼형 스토리지 표현들을 생성하고 처리하는 시스템의 블록 다이어그램이다. 레코드 생성기(1904)는 데이터 소스들(1920) 및 스키마(1902)로부터 내포된 데이터의 레코드들을 생성한다. 컬럼 생성기(1908)는 레코드들(1906)과 스키마(1902)를 입력으로서 수신하고, 레코드들(1906)로 데이터를 표현하되 컬럼형 포맷으로 표현하는 컬럼 스트라이프들을 출력한다. 컬럼형 데이터(1910)는 서로 다른 출력 컬럼들(1914)의 세트를 만들기 위해서 쿼리 시스템(1912)에 의해 원래 제 위치에서(in site) 쿼리될 수 있다. 컬럼형 데이터(1910)는 또한 레코드 어셈블러(1916)에 의해 레코드 형태(record form)로 다시 어셈블링될 수 있다. 레코드 어셈플러에 의해 출력되는 레코드들(1918)은 각각이 집합(1906)에 있는 오리지널 레코드들로부터의 필드들의 서브셋을 포함할 수 있다. 출력 레코드들(1918)은 레코드-기반 데이터 분석 프로그램(예컨대, 맵리듀스)에 의해 동작될 수 있다.

보다 구체적으로, 데이터 소스들(1920)은 실질적으로 비구조화된 데이터를 포함할 수 있다. 실질적으로 비구조화되었다는 것은 그 데이터가 구조를 나타내는 요소들을 포함할 수 있지만, 정보의 전체 스펙트럼이 유사하게 구조화되지 않은 것일 수 있다는 것을 나타낸다. 예시로서, 데이터 소스들(1920)은 수 백만의 웹사이트들 각각에 대한 소스 코드를 포함할 수 있다. 각 웹사이트들이 어느 정도의 구조를 포함하더라도, 각 웹 사이트의 콘텐츠는 공통 스키마에 기초하여 생성되지 않는다. 표준은 사이트의 포맷을 전반적으로 관할(govern)할 수 있지만, 콘텐츠 및 필드들의 배치(placement)는 단일 스키마에 의해 각각 및 모든 웹사이트에 대해 특정되지 않는다. 일부 예시들에서, 데이터 소스들(1920)에 있는 정보는 공통 스토리지 레이어(1922)에 저장되지 않고, 인터넷상의 외부 소스들로부터 직접적으로 가져온 것일 수 있다.

스키마(1902)는 데이터 소스들에 포함될 수 있는 정보에 대한 공통 구조를 정의한다. 상술한 바와 같이, 스키마(1902)는 정보의 특정 필드들을 요구할 수 있고, 선택적으로 정보의 다른 필드들이 저장되는 것을 허용할 수 있다.

레코드 생성기(1904)는 스키마(1902)와 데이터 소스들(1920)로부터의 정보를 입력으로서 수신한다. 레코드 생성기(1904)는 데이터 리소스들(1920)로부터 정보를 취득하여, 그 정보의 전부 또는 일부를 레코드들의 개별 인스터스(스키마(1902)를 따름)로 구조화한다. 예를 들어, 데이터 리소스들(1920)은 실질적으로 웹 페이지로부터의 비구조화된 데이터를 실질적으로 포함할 수 있고, 레코드 생성기(1904)는 특정 레코드들(1906)을 위해 포함하기 위해, 각 웹 페이지로부터의 정보의 일부를 선택할 수 있다.

따라서 레코드들(1906) 각각은 스키마(1902)에 따라 구조화된 데이터를 포함할 수 있다. 구조화된 데이터는 데이터 값들의 시맨틱스와 데이터 값들의 구조적 관계(structural relationship)를 나타낼 수 있는 필드들을 포함할 수 있다. 따라서 스키마가 데이터 값(예컨대, 현실 세계 또는 웹상에서 표현되는 데이터 값 또는 다른 값들과의 관계가 디지털화되어 저장된 것)에 대한 추가 정의 정보(additional definition information)를 얻기 위해 참조될 수 있다.

각 레코드(1906)는 내포된 필드들 및 데이터 값들을 포함할 수 있다. 내포된 레코드는 동일 이름 또는 경로를 갖는 둘 이상의 필드를 포함할 수 있다. 그러나 동일 이름 또는 경로를 갖는 필드들은 특정 레코드에서 서로 다른 위치에 구조적으로 위치될 수 있다. 예를 들어, 스키마에 의해 정의되는 단일 필드가 여러 번 반복될 수 있다. 이에 더하여, 필드들은 자식 필드들(즉, 내포된 필드들)을 가질 수 있다. 따라서 레코드의 최상위 레벨에 있는 특정 필드가 반복할 수 있고, 그 필드의 각 반복은 특정 자식 필드를 포함할 수도 있고, 포함하지 않을 수도 있다. 다시 말해서, 레코드는 자신의 일부분에는 자식 필드의 인스턴스들을 포함할 수 있지만, 그 레코드들의 다른 부분에는 자식 필드의 인스턴스들을 포함하지 않을 수도 있다.

레코드들(1906)의 집합은 레코드들로 된 정보의 처리 속도를 향상시키기 위해 컬럼형 데이터(1910)로 바뀔 수 있다. 예를 들어, 집합(1906)에 있는 레코드들의 양이 수십억이고, 각 레코드가 수십 개의 서로 다른 필드들을 포함할 수 있다면, 작은 수의 필드상의 정보가 바람직한 경우, 레코드들의 분석에 시간 소비가 집중(time-intensive)될 수 있다. 이것은 집합(1906)에 있는 레코드 각각이 그 레코드로부터의 다른 정보와 함께 저장되기 때문이다. 즉, 각 레코드는 메모리의 연속하는 부분에 함께(예컨대, 도 1에서 내포된 데이터의 '레코드-지향형(record-oreiented)' 묘사로 예시된 것처럼) 그룹화된다.

대조적으로, 컬럼형 데이터(1910)는 스커마(1902) 내의 단일 필드를 위한 정보를 각각(예컨대, 도 1에서 '컬럼-지향형(colume-oriented)' 묘사로 예시된 것처럼) 저장하는 컬럼들을 포함한다. 따라서 필드가 긴 바이트라면, 필드를 위한 컬럼이 수십억개의 레코드들(예컨대, 각 레코드가 메가바이트 크기일 수 있음)과 대조적으로 수십억개의 바이트들(예컨대, 각 레코드가 1바이트)의 배열(order)상에 있을 수 있다. 컬럼 생성기(1908)의 동작들은 4.2 절 "레코드들을 컬럼으로 분해하기"에 보다 자세하게 기재되어 있다. 컬럼형 데이터(1910)를 위한 스토리지 포맷은 4.1 절 "반복 및 정의 레벨들"에 보다 자세하게 기재되어 있다.

컬럼형 데이터(1910)는 쿼리 시스템(1912)을 사용하여 직접적으로 쿼리될 수 있다. 다시 말하면, 컬럼형 데이터(1910)는 데이터를 데이터베이스에 로딩하지 않고 쿼리될 수 있다. 쿼리 시스템은, 쿼리를 실행할 때, 컬럼형 데이터의 테이블을 입력으로서 수신할 수 있다. 일부 예시에서, 쿼리 시스템은 또한 스키마(1902)를 입력으로 수신할 수 있다. 컬럼형 스트라이프들은 데이터 자기-설명(data self-describing)을 만들기 위해 스키마와 함께 저장될 수 있다. 쿼리 시스템은 연산들이 컬럼형 데이터에 대해 수행될 수 있도록 하여, 출력 정보(1914)의 컬럼들을 생성할 수 있게 한다. 출력 컬럼들(1914)은 특정 쿼리로 의해 정해지는 것처럼, 컬럼형 데이터(1910)로 표현되는 값들의 서브셋을 포함할 수 있다. 일부 예시들에서, 쿼리 시스템은 컬럼(1914)을 대신하거나, 또는 그 컬럼(1914)에 더하여 레코드들(1918)을 출력한다.

예를 들어, 쿼리 시스템(1912)는 제1 쿼리를 수신하고, 그 쿼리에 응답하여, 데이터의 컬럼들을 선택하는 것을 통해 파싱할 수 있고, 하나 이상의 비디오를 갖는 모든 웹 페이지의 제목 및 각 웹페이지를 위하여 복수의 비디오들을 제공하는 출력 컬럼들의 세트를 생성할 수 있다. 쿼리 시스템은 제2 쿼리를 수신할 수 있고, 그에 응답하여, 최근 15분내에 생성되었던 모든 웹 페이지의 URL을 제공하는 출력 컬럼들의 제2 세트를 출력할 수 있다. 컬럼들(1910)로부터의 다른 정보가 특정 쿼리(1914)에 상응하는 출력 컬럼들의 세트에 포함되지 않을 수도 있다.

컬럼형 데이터(1910)로서 저장되는 데이터는 컬럼형 데이터에 대해 연산하지 않지만, 레코드들에 대해 연산하는 분석적 서비스(analytical service)에 의해 액세스될 필요가 있다. 따라서 레코드 어셈블러(1916)는 컬럼형 데이터를 입력으로서 수신하고 그 컬럼형 데이터로부터의 레코드를 어셈블링할 수 있다. 레코드들을 어셈블링하는 절차는 4.3 절 "레코드 어셈블리"에 보다 자세하게 기재되어 있다.

레코드들이 집합(1906)에서 이미 사용가능하지만, 레코드 어셈블러(1916)는 집합(1906)에 있는 레코드들의 필드들의 서브셋을 포함하는 레코드들의 세트를 생성할 수 있다. 예를 들어, 집합에 있는 레코드들은 수천의 서로 다른 필드들을 포함할 수 있다. 사용자는 모든 레코드에 대해서가 아니고, 두 개의 필드로부터의 지식(knowledge)만을 요구하는 레코드-지향형 분석 프로그램을 구동하고 싶어할 수 있다. 따라서 레코드 어셈블러(1916)는 필수 필드에 대한 정보만을 포함하는 레코드들의 세트를 생성할 수 있다. 이 방식에서, 출력 레코드들(1918)의 다수 세트들이 다른 분석 또는 다른 분석 프로그램용으로 생성(develop)될 수 있다. 소형 레코드들에 대한 분석이 집합(1906)에서 찾아지는 대형 레코드들을 트래버스해야만 하는 분석보다 빠를 수 있다.

시스템(1900)의 동작에 대한 상기 설명은, 레코드들(1906)의 집합이 스키마(1902)에 따라 포맷된 레코드들을 포함하고, 컬럼형 데이터(1910)가 이 단일의 유사하게 구조화된 데이터의 세트로부터 생성되는 예시들을 나타낸다. 다양한 예시들에서, 다수의 스키마(1902)가 다르게 구조화된 레코드들(1906)의 많은 세트들을 포함하는 레코드들의 집합을 생성하기 위해 사용될 수 있다. 그러나 각 레코드는 레코드의 생성에 사용되었던 스키마의 유형을 헤더에서 식별할 수 있다. 마찬가지로, 컬럼 스트라이프가 많은 유사하게 구조화된 레코드들의 세트 각각에 있는 각 필드에 대해 생성될 수 있다. 각 컬럼 스트라이프는 필드의 이름뿐만이 아니고, 컬럼형 데이터가 연관되는 스키마(즉, 컬럼형 데이터가 생성된 레코드들을 포맷하기 위해 사용된 스키마)를 나타낼 수 있다.

도 20은 컬럼형 데이터를 생성하기 위한 예시적 프로세스의 순서도이다. 이 프로세스는 시스템(1900)의 구성요소들에 의해 수행될 수 있다.

박스 2002에서, 레코드들의 세트가 생성된다. 레코드들의 생성은 레코드 생성기(1904)에 의해 수행될 수 있다. 비구조화된 데이터(예컨대, 데이터 소스들(1920)로부터)가 스키마(1902)에 의해 정의되는 표준화된 레코드 포맷으로 컴파일될 수 있다. 레코드들은 집합(1906)에 저장될 수 있다.

박스 2004에서, 집합(1906)에 있는 레코드들이 액세스된다. 예를 들어, 컬럼 생성기(1908)는 레코드들의 집합(1906)으로부터의 데이터를 입력으로서 수신한다.

박스 2006에서, 컬럼 스트라이프가 추가 필드를 대해 생성되어야 하는지에 대한 판단이 행해진다. 예를 들어, 스트라이프가 집합(1906)에 저장되는 레코드들의 세트에 있는 각 필드(및 스키마(1902)에 있는 각 레코드 또는 그것들의 서브셋)를 위해 생성되어야 한다. 이 예시에서는, 지금까지 스트라이프가 만들어지지 않았기 때문에, 필드들에 대한 스트라이프들이 생성되어야 한다. 따라서 프로세스는 특정 필드에 대한 연산들을 수행하기 위해 박스 2008로 진행한다. 만약 모든 스트라이프가 생성되었으면(예컨대, 레코드들의 집합(1906)에 있는 모든 필드에 대해 스트라이프가 생성되었으면), 이 프로세스는 종료할 수 있다.

박스 2008에서, 특정 필드에 대한 값들의 목록이 생성된다. 예를 들어, 레코드들 각각이 트래버스될 수 있어서, 특정 필드에 대한 값들의 목록이 생성된다.

박스 2010에서, 특정 필드에 대한 반복 레벨이 생성된다. 예를 들어, 컬럼 생성기(1908)는 필드에 대한 경로에서 가장 최근에 반복된 필드를 판정함으로써, 그 목록에 있는 각 값에 대한 반복 레벨을 결정한다.

박스 2012에서, 특정 필드에 대한 정의 레벨이 생성된다. 예를 들어, 컬럼 생성기(1908)는 각 레벨(위에서 보다 자세하게 설명된 것처럼, '소실'되는 값들을을 포함함)에 대한 정의 레벨을 결정한다.

박스 2014에서, 컬럼형 스트라이프는 특정 필드에 대해 어셈블링된다. 다양한 예시에서, 반복 및 정의 레벨은 스트라이프의 헤더에 그룹화된 쌍(paired grouping)으로 배치된다.

박스 2016에서, 컬럼형 스트라이프는 압축될 수 있는 블럭들로 나눠진다. 각 블럭은 값들의 세트와 자신에게 상응하는 반복 및 정의 레벨을 포함할 수 있다. 이어서 박스 2006에서, 컬럼형 스트라이프들이 추가 필드들에 대해 생성되어야 하는지에 대한 판단이 수행된다. 만약 컬럼형 스트라이프들이 추가적으로 생성되지 않아도 된다면, 이 프로세스는 종료된다.

도 20에서 도시된 프로세스는 컬럼형 스트라이프들을 생성하기 위한 예시적 프로세스이다. 이 프로세스에 대한 변형예들이 예상(contemplate)된다. 예를 들어, 각 박스들의 동작이 순서도에 제시된 것과 같이 순차적으로 수행되지 않을 수 있다. 다수 필드들에 대한 스트라이프들이 동시에 생성될 수 있다. 반복 레벨 및 정의 레벨이 각 값들이 레코드로부터 얻어질 때 생성될 수 있다. 컬럼형 스트라이프가 전제적으로 생성되지 않을 수도 있다. 그 대신, 각 블록이 스트라이프로부터 생성되어 독립적으로 압축될 수 있다. 따라서 이 순서도는 스트라이프의 생성을 이해하기 위한 개념적 메커니즘을 나타낼 수는 있으나, 이것으로 제한하는 것을 의도하지는 않는다. 컬럼형 데이터를 생성하기 위한 프로세스는 도 4의 알고리즘에 제시되어 있다.

도 21은 본 명세서에서 설명된 시스템과 방법을, 클라이언트 또는 단일 서버 또는 복수 서버 중 어느 하나로서 구현하기 위해 사용될 수 있는 컴퓨팅 디바이스(2100, 2150)의 블록도이다. 컴퓨팅 시스템(2100)은 랩탑, 데스크탑, 워크스테이션, PDA(Personal Digital Assistant), 서버, 블레이드(blade) 서버, 메인프레임, 및 그 밖의 적절한 컴퓨터들과 같은 다양한 형태의 디지털 컴퓨터를 나타내기 위해 사용된다. 컴퓨팅 디바이스(2150)는 PDA, 셀룰라 전화, 스마트폰, 및 그 밖의 유사한 컴퓨팅 디바이스와 같은 다양한 형태의 모바일 디바이스를 나타내기 위해 사용된다. 부가적으로 컴퓨팅 디바이스(2100 또는 2150)는 USB(Universal Serial Bus) 플래시 드라이브를 포함할 수 있다. USB 플래시 드라이버는 운영 체제와 그 밖의 애플리케이션를 저장할 수 있다. USB 플래시 드라이브는 다른 컴퓨팅 디바이스의 USB 포트에 삽입할 수 있는 USB 커넥터 또는 무선 트랜스미터와 같은 입/출력 구성요소를 포함할 수 있다. 본 명세서에서 나타낸 구성요소, 그들의 접속 및 관계, 및 그들의 기능들은 단지 예시적인 것을 의미하고, 본 명세서에서 설명하거나 또는 청구된 발명의 구현예를 제한하는 것을 의미하지 않는다.

컴퓨팅 디바이스(2100)는 프로세서(2102), 메모리(2104), 스토리지 디바이스(2106), 메모리(2104)와 고속 확장 포트(2110)에 접속하는 고속 인터페이스(2108), 및 저속 버스(2114)와 스토리지 디바이스(2106)에 접속하는 저속 인터페이스(2112)를 포함한다. 각 구성요소(2102, 2104, 2106, 2108, 2110, 및 2112)는 다양한 버스들을 사용하여 서로 접속되고, 공통 마더보드에 탑재되거나 또는 적절한 경우 다른 방식으로 탑재될 수 있다. 프로세서(2102)는 컴퓨팅 디바이스(2100) 내에서 실행하기 위한 명령어를 처리할 수 있으며, 이러한 명령어에는, 고속 인터페이스(2108)에 연결된 디스플레이(2116)와 같은 외장 입/출력 디바이스 상에서 GUI용 그래픽 정보를 디스플레이하기 위해, 메모리(2104) 또는 스토리지 디바이스(2106)에 저장되는 명령어가 포함된다. 다른 구현예에서, 다중 프로세서 및/또는 다중 버스는 적절한 경우, 다중 메모리 및 메모리 타입과 함께 사용될 수 있다. 또한, 다중 컴퓨팅 디바이스(2100)는 각 디바이스가 필요 동작의 부분을 제공하는 형태(예를 들어, 서버 뱅크, 블레이드 서버의 그룹, 또는 다중 프로세서 시스템)로 접속될 수 있다.

메모리(2104)는 컴퓨팅 디바이스(2100) 내에 정보를 저장한다. 일 구현예에서, 메모리(2104)는 휘발성 메모리 유닛 또는 유닛들이다. 또 다른 구현예서, 메모리(2104)는 비휘발성 메모리 유닛 또는 유닛들이다. 또한, 메모리(2104)는 마그네틱 또는 광 디스크와 같은 다른 형태의 컴퓨터 판독가능 매체일 수 있다.

스토리지 디바이스(2106)는 컴퓨팅 디바이스(2100)를 위한 대용량 스토리지(mass storage)를 제공할 수 있다. 일 구현예에서, 스토리지 디바이스(2106)는 플로피 디스크 디바이스, 하드 디스크 디바이스, 광 디스크 디바이스, 또는 테입 디바이스, 플래쉬 메모리 또는 다른 유사한 고체 상태 메모리 디바이스, 또는 저장 영역 네트워크 또는 다른 구성에 존재하는 디바이스를 포함하는 디바이스 어레이일 수 있다. 컴퓨터 프로그램 제품은 정보 캐리어(information carrier) 내에 유형적으로 구체화될 수 있다. 또한, 컴퓨터 프로그램 제품은 실행될 때, 상술한 것과 같은 하나 이상의 방법을 수행하는 명령어를 포함할 수 있다. 정보 캐리어는 메모리(2104), 스토리지 디바이스(2106), 또는 프로세서(2102) 상의 메모리와 같은 컴퓨터 또는 기계 판독가능 매체이다.

저속 제어부(2112)가 저대역-집약적 동작(lower bandwidth-intensive operations)을 관리하는 반면, 고속 제어부(2108)는 컴퓨팅 디바이스(900)에 대한 대역-집약적 동작을 관리한다. 이러한 기능들의 배치는 단지 예시적인 것이다. 일 구현예에서, 고속 제어부(2108)는 메모리(2104), 디스플레이(2116)(예를 들어, 그래픽 프로세서 또는 가속기를 통함)에 연결되고, 다양한 확장 카드(도시되지 않음)을 수용할 수 있는 고속 확장 포트(2110)에 연결된다. 일부 구현예에서는, 저속 제어부(2112)는 스토리지 디바이스(2106) 및 저속 확장 포트(2114)에 연결된다. 다양한 통신 포트(예를 들어, USB, 블루투스, 이더넷, 무선 이더넷)를 포함할 수 있는 저속 확장 포트는 키보드, 포인팅 디바이스, 스캐너와 같은 하나 이상의 입/출력 디바이스들에 연결되거나, 또는 예컨대 네트워크 어댑터를 통하여, 스위치나 라우터와 같은 네트워킹 디바이스에 연결될 수 있다.

컴퓨팅 디바이스(2100)는 도면에 도시된 바와 같이, 복수의 다른 형태로 구현될 수 있다. 예를 들어, 컴퓨팅 디바이스(2100)는 표준 서버(2120)로 구현되거나 이러한 서버들의 그룹에서 여러 번(multiple time) 구현될 수 있다. 또한, 컴퓨팅 디바이스(2100)는 랙 서버 시스템(2124)의 부분으로서 구현될 수 있다. 이에 더하여, 컴퓨팅 디바이스(2100)는 랩탑 컴퓨터(2122)와 같은 개인용 컴퓨터내에 구현될 수 있다. 선택적으로, 컴퓨팅 디바이스(2100)로부터의 구성요소는 디바이스(2150)와 같은 모바일 디바이스(도시되지 않음) 내 다른 구성요소와 조합될 수 있다. 이러한 디바이스 각각은 하나 이상의 컴퓨팅 디바이스(2100, 2150)를 포함하고, 전체 시스템은 서로 통신하는 다중 컴퓨팅 디바이스(2100, 2150)로 구성될 수 있다.

컴퓨팅 디바이스(2150)는 여러 구성요소 중에서 프로세서(2152), 메모리(2164), 디스플레이(2154)와 같은 입/출력 디바이스, 통신 인터페이스(2166), 및 트랜스시버(2168) 등을 포함한다. 또한, 디바이스(2150)에는 추가적인 스토리지를 제공하기 위하여, 마이크로 드라이브 또는 다른 디바이스와 같은 스토리지 디바이스가 제공될 수 있다. 구성요소(2150, 2152, 2164, 2154, 2166, 및 2168) 각각은 다양한 버스를 이용하여 서로 접속되고, 구성요소의 몇몇은 공통의 마더보스에 탑재되거나 적절한 다른 방법으로 탑재될 수 있다.

프로세서(2152)는 컴퓨팅 디바이스(2150) 내에서 명령어를 실행하며, 이 명령어에는 메모리(2164)에 저장된 명령어가 포함된다. 프로세서는 개별적이고 다중의 아날로그 및 디지털 프로세서를 포함하는 칩들의 칩 세트로서 구현될 수 있다. 부가적으로, 프로세서는 복수의 아키텍처 중 임의의 아키텍처를 사용하여 구현될 수 있다. 예를 들어, 프로세서(2152)는 CISC(Complex Instruction Set Computers) 프로세서, RISC(Reduced Instruction Set Computer) 프로세서, 또는 MISC(Minimal Instruction Set Computer) 프로세서일 수 있다. 프로세서는, 예를 들어, 사용자 인터페이스의 컨트롤, 디바이스(2150)에 의해 실행되는 애플리케이션, 및 컴퓨팅 디바이스(2150)에 의한 무선 통신과 같은 디바이스(2150)의 다른 구성요소들 사이에 조정을 제공할 수 있다.

프로세서(2152)는 제어 인터페이스(2158) 및 디스플레이(2154)에 연결된 디스플레이 인터페이스(2156)를 통해 사용자와 통신할 수 있다. 디스플레이(2154)는, 예를 들어, TFT LCD(Thin-Film-Tansistor Liquid Crystal Display) 디스플레이 또는 OLED(Organic Light Emitting Diode) 디스플레이, 또는 다른 적절한 디스플레이 기술일 수 있다. 디스플레이 인터페이스(2156)는 그래픽 및 다른 정보를 사용자에게 나타내기 위해 디스플레이(2154)를 구동하는 적절한 회로를 포함할 수 있다. 제어 인터페이스(2158)는 사용자로부터 명령들을 수신하고, 프로세서(2152)에 제출하기 위해 그 명령들을 변환한다. 더욱이, 확장 인터페이스(2162)는 디바이스(2150)와 다른 디바이스들 간에 근거리 통신이 가능하도록 하기 위해, 프로세서(2152)와의 통신에 제공될 수 있다. 확장 인터페이스(2162)는, 예를 들어, 일부 구현예에서는 유선 통신을 제공하고 다른 구현예에서 무선 통신을 제공하며, 또한 다중 인터페이스가 사용될 수 있다.

메모리(2164)는 컴퓨팅 디바이스(2150) 내에 정보를 저장한다. 메모리(2164)는 컴퓨터 판독가능 매체 또는 미디어, 휘발성 메모리 유닛 또는 유닛들, 또는 비휘발성 메모리 유닛 또는 유닛들 중 하나 이상으로서 구현될 수 있다. 또한, 확장 메모리(2174)가 제공되어, 예를 들어 SIMM(Single In Line Memory Module) 카드 인터페이스를 포함하는 확장 인터페이스(2174)를 통해 디바이스(2150)에 접속될 수 있다. 이러한 확장 메모리(2174)는 디바이스(2150)를 위한 여분의 스토리지 공간을 제공할 수 있고, 또한 애플리케이션 또는 디바이스(2150)를 위한 다른 정보를 저장할 수 있다. 특히, 확장 메모리(2174)는 상술된 프로세스를 실행하거나 보조하기 위한 명령어를 포함하고, 또한 보안 정보를 포함할 수 있다. 따라서 예를 들어, 확장 메모리(2174)는 디바이스(2150)용 보안 모듈(security module)로서 제공될 수 있고, 디바이스(2150)의 안전한 사용을 가능하게 하는 명령어로 프로그램될 수 있다. 더욱이, 보안 애플리케이션은, 해킹할 수 없는 방식(non-hackable manner)으로 SIMM 카드 상에 식별 정보를 위치시킨 것과 같은 추가적 정보와 함께 SIMM 카드를 통해 제공될 수 있다.

메모리는 아래에서 논의되는 것과 같이 예를 들어, 플래시 메모리 및/또는 NVRAM 메모리를 포함할 수 있다. 일 구현예에서, 컴퓨터 프로그램 제품은 정보 캐리어에 유형적으로 구체화된다. 컴퓨터 프로그램 제품은 실행될 때, 상술된 것과 같은 하나 이상의 방법을 수행하는 명령어를 포함한다. 정보 캐리어는 메모리(2164), 확장 메모리(2174), 또는 예를 들어 트랜스시버(2168) 또는 확장 인터페이스(2162)를 통해 수신될 수 있는 프로세서(2152) 상의 메모리와 같은 컴퓨터-또는 기계-판독가능 매체이다.

디바이스(2150)는 디지털 신호 처리 회로를 필요에 따라 포함하는 통신 인터페이스(2166)를 통해 무선으로 통신할 수 있다. 통신 인터페이스(2166)는 GSM 음성 호, SMS, EMS, 또는 MMS 메시징, CDMA, TDMA, PDC, WCDMA, CDMA2000, 또는 GPRS 등과 같은 다양한 모드 또는 프로토콜 하에서의 통신을 제공할 수 있다. 이러한 통신은 예를 들어, 무선-주파수 트랜스시버(2168)를 통해 수행될 수 있다. 또한, 단거리(short range) 통신은 예를 들어, 블루투스, WiFi, 또는 다른 이러한 트랜스시버(도시되지 않음)를 사용하여 수행될 수 있다. 이에 더하여, GPS(Global Position System) 수신기 모듈(2170)은 추가적인 네비게이션- 및 위치- 관련 무선 데이터를 디바이스(2150)에 제공할 수 있으며, 이 무선 데이터는 디바이스(2150)에서 실행중인 애플리케이션에 의해 적절하게 사용될 수 있다.

또한, 디바이스(2150)는 사용자로부터의 발화 정보(spoken information)를 수신하고, 그 발화 정보를 사용가능한 디지털 정보로 변환하는 오디오 코덱(2160)을 이용하여, 청취가능하게(audibly) 통신할 수 있다. 또한, 오디오 코덱(2160)은 예를 들어, 디바이스(2150)의 핸드셋 내의 스피커를 통하는 것과 같이 해서, 사용자가 들을 수 있는 음성을 생성한다. 이러한 음성은 음성 전화 호로부터의 음성을 포함할 수 있고, 녹음된 음성(예를 들어, 음성 메시지, 뮤직 파일 등)은 포함할 수 있고, 또한 디바이스(2150) 상에서 동작하는 애플리케이션에 의해 생성된 음성을 포함할 수 있다.

컴퓨팅 디바이스(2150)는 도면에 도시된 바와 같이, 복수의 다양한 형태로 구현될 수 있다. 예를 들어, 컴퓨팅 디바이스(2150)는 셀룰러 전화(2180)로서 구현될 수 있다. 또한, 컴퓨팅 디바이스(2150)는 스마트폰(2182), PDA, 또는 다른 유사한 모바일 디바이스의 일부로서 구현될 수 있다.

본 명세서에 기재된 시스템의 다양한 구현예와 기술은 디지털 전자 회로, 집적 회로, 특별하게 설계된 ASICs(Application Specific Intergrated Circuit), 컴퓨터 하드웨어, 펌웨어, 소프트웨어, 및/또는 그것의 조합물로 실현될 수 있다. 이러한 다양한 구현예는 하나 이상의 컴퓨터 프로그램으로 된 구현예를 포함하며, 이 컴퓨터 프로그램은 적어도 하나의 프로그램 가능한 프로세서를 포함하는 프로그램 가능한 시스템에서 실행가능하고 및/또는 해석가능하다. 또한, 전용 또는 범용 프로세서일 수 있는 이 프로그램 가능한 프로세서는 데이터와 명령어를 송수신하기 위해, 저장 시스템, 적어도 하나의 입력 디바이스 및 적어도 하나의 수신 디바이스에 연결된다.

컴퓨터 프로그램(또한 프로그램, 소프트웨어, 소프트웨어 애플리케이션, 또는 코드로 알려짐)은 프로그램 가능한 프로세서를 위한 기계 명령어를 포함하고, 고레벨 절차 및/또는 객체 지향 프로그램 언어(object-oriented programming language) 및/또는 어셈블리/기계 언어로 구현될 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 "기계 판독가능 매체(machine-readable medium)"와 "컴퓨터 판독가능 매체(computer-readable medium)"는 기계 명령어 및/또는 데이터를 프로그램 가능한 프로세서에 제공하기 위해 이용되는 임의의 컴퓨터 프로그램 제품, 장치, 및/또는 디바이스(예를 들어, 마그네틱 디스크, 광학 디스크, 메모리, PLDs(Programmable Logic Devices))를 가리키며, 기계 판독가능 신호와 같은 기계 명령어를 수신하는 기계 판독가능 매체를 포함한다. 용어 "기계 판독가능 신호(machine-readable signal)"는 기계 명령어 및/또는 데이터를 프로그램 가능한 프로세서에 제공하기 위해 사용되는 임의의 신호를 가리킨다.

사용자와의 인터렉티브을 제공하기 위하여, 본 명세서에 설명된 시스템과 기술은, 정보를 사용자에게 디스플레이하기 위한 디스플레이 디바이스(예를 들어, CRT(cathode ray tube) 또는 LCD 모니터)와 사용자가 컴퓨터에 입력을 제공할 수 있는 키보드 및 포인팅 디바이스(예를 들어, 마우스 또는 트랙볼)를 구비한 컴퓨터 상에서 구현될 수 있다. 사용자와의 인터렉티브을 제공하기 위하여 다른 종류의 디바이스가 또한 사용될 수 있다; 예를 들어, 사용자에게 제공되는 피드백(feedback)은 임의의 형태의 감각 피드백(예를 들어, 시각 피드백, 청각 피드백 또는 촉각 피드백)일 수 있고, 사용자로부터의 입력은 음향(acoustic), 음성(speech) 또는 촉각(tactile) 입력을 포함하는 임의의 형태로 수신될 수 있다.

본 명세서에서 설명한 시스템과 기술은, 백 엔드(back end) 구성요소(예를 들어, 데이터 서버와 같은), 또는 미들웨어 구성요소(예를 들어, 애플리케이션 서버), 또는 프론트 엔드(front end) 구성요소(예를 들어, 본 명세서에서 설명된 시스템 및 기술의 구현예와 사용자가 인터렉티브할 수 있는 그래픽 사용자 인터페이스 또는 웹브라우저를 구비한 클라이언트 컴퓨터), 또는 이러한 백 엔드, 미들웨어, 또는 프론트 엔드 구성요소들의 임의의 조합을 포함하는 컴퓨팅 시스템으로 구현될 수 있다. 시스템의 구성요소는 디지털 데이터 통신의 임의의 형태 또는 매체(예를 들어, 통신 네트워크)에 의해 상호 접속될 수 있다. 통신 네트워크의 예로서, 근거리 네트워크("LAN"), 광역 네트워크("WAN"), 및 인터넷이 있다.

컴퓨팅 시스템은 클라이언트와 서버를 포함할 수 있다. 클라이언트와 서버는 보통 서로 떨어져 있으며, 일반적으로는 통신 네트워크를 통하여 상호동작한다. 클라이언트와 서버의 관계는 각각의 컴퓨터 상에서 실행되고 상호 클라이언트-서버 관계를 갖는 컴퓨터 프로그램에 의하여 발생한다.

여러 개의 구현예가 상세히 설명되었지만, 다른 변형예들도 가능하다. 또한, 내포된 레코드들의 컬럼형 스토리지 표현들을 생성 및 처리하기 위한 다른 메커니즘들이 사용될 수 있다. 이에 더하여, 도면에서 묘사된 로직 흐름은 희망하는 결과를 달성하기 위해, 도시된 특정 순서 또는 시계열적 순서일 필요는 없다. 다른 단계들이 제공되거나, 그로부터 단계들이 제거될 수 있으며, 다른 구성요소들이 설명된 시스템에 추가되거나 그로부터 제거될 수 있다. 따라서 다른 구현예들은 후술하는 청구범위의 범위 내에 속한다.

1902: 스키마
1904: 레코드 생성기
1908: 컬럼 생성기
1912: 쿼리 시스템
1916: 레코드 어셈블러
1922: 공통 스토리지 레이어

Claims (15)

1. 컴퓨터로 구현되는 방법으로서,
   컴퓨팅 시스템에 의해, 컴퓨터 메모리에 저장된 데이터 레코드들의 집합에 액세스하는 단계 ― 상기 데이터 레코드들의 집합에 있는 각 레코드는 복수의 데이터 값들과 상기 복수의 데이터 값들로부터 상응하는 데이터 값들의 시멘틱스(semantics)를 식별하는 복수의 데이터 요소들을 포함하고, 상기 데이터 레코드들의 집합에 있는 하나 이상의 데이터 레코드 각각은 동일 데이터 요소의 다수의 인스턴스를 포함하고 상기 동일 데이터 요소의 다수의 인스턴스에 상응하는 데이터 값들을 포함하며, 상기 데이터 레코드들의 집합에 있는 적어도 하나의 데이터 레코드는 데이터 요소들 및 내포된 데이터 모델(nested data model)에 따라 저장되는 상응하는 데이터 값들을 포함함 ―;
   상기 컴퓨팅 시스템에 의해, 컬럼형 스트라이프(columnar stripe)들의 집합을 생성하는 단계―상기 컬럼형 스트라이프들의 집합은 상기 데이터 레코드들의 집합에 있는 각 데이터 레코드로부터의 상기 데이터 값들을 포함하고, 상기 컬럼형 스트라이프들의 집합에 있는 각 컬럼형 스트라이프는 상기 데이터 레코드들의 집합에 있는 각 레코드로부터의 특정 데이터 요소에 상응하는 모든 데이터 값을 포함함―; 및
   상기 컴퓨팅 시스템에 의해, 상기 컬럼형 스트라이프들의 집합에 있는 각 컬럼형 스트라이프에 있는 각 데이터 값에 대해, 그리고 상기 컬럼형 스트라이프들의 집합에 상기 데이터 값들과 함께 저장하기 위하여, 상기 데이터 레코드들의 집합으로부터 데이터 레코드 각각에 있는 상기 데이터 값 각각의 위치를 식별하는 데이터를 생성하는 단계를 포함하는, 방법.
2. 청구항 1에 있어서,
   상기 데이터는 반복값(repetition value)과 정의값(definition value)으로 구성되는, 방법.
3. 청구항 2에 있어서,
   상기 컬럼형 스트라이프들의 집합 내 각 데이터 값에 대해 상기 반복값 및 상기 정의값을 저장하면서 (ⅰ) 상기 컬럼형 스트라이프들의 집합에 있는 상기 컬럼형 스트라이프들과 (ⅱ) 상기 데이터로부터, 상기 데이터 레코드들의 집합에 있는 상기 레코드들로부터 데이터 요소들의 서브셋만을 포함하는 상기 레코드들의 세트를 재구성(reconstruction)하는 단계를 더 포함하는, 방법.
4. 청구항 1에 있어서,
   상기 컬럼형 스트라이프들의 집합에 상기 데이터 값들과 함께 저장하기 위하여, 상기 컬럼형 스트라이프들의 집합에 있는 특정 데이터 값 각각에 대한 반복값을 생성하는 단계를 더 포함하고,
   특정 데이터 요소 각각에 대한 경로(path)는 상기 특정 데이터 요소에 대한 하나 이상의 부모 데이터 요소를 포함하고;
   특정 데이터 값 각각에 대한 상기 반복값은 상기 특정 데이터 값에 상응하는 상기 특정 데이터 요소의 상기 경로에서 가장 최근에 반복된 데이터 요소(a most-recently repeated data element)를 식별하며;
   상기 특정 데이터 요소의 상기 경로에서 상기 가장 최근에 반복된 데이터 요소는, 분석중에 두 번째로 접하게 되는 상기 특정 데이터 요소의 상기 경로에 있는 상기 데이터 요소로서, 상기 데이터 요소는 상기 특정 데이터 값을 포함하는 특정 데이터 레코드에 있으며, 상기 특정 데이터 레코드에 있는 상기 특정 데이터 값의 위치(position)로부터 상기 특정 데이터 레코드의 시작점을 향해서 위쪽으로 작업(work)하는 데이터 요소인, 방법.
5. 청구항 1에 있어서,
   상기 데이터 요소들의 집합에 포함되는 상기 데이터 요소들의 특정 데이터 요소 각각은, 상기 특정 데이터 요소에 대한 하나 이상의 부모 데이터 요소를 포함하는 각각의 경로와 연관되고;
   상기 방법은, 상기 컬럼형 스트라이프들에 있는 상기 데이터 값들과 함께 저장하기 위해, 상기 데이터 레코드들의 집합에 있는 각 특정 경로 또는 특정 경로의 일부에 대한 정의 레벨을 생성하는 단계를 더 포함하고;
   상기 특정 경로 또는 상기 특정 경로의 일부에 대한 상기 정의 레벨은 특정 경로 또는 경로의 일부에 포함된 데이터 요소들의 양을 식별하는, 방법.
6. 청구항 1에 있어서,
   상기 컴퓨팅 시스템에 의해서 데이터 소스들의 집합으로부터 정보를 수신하는 단계 ― 각 데이터 소스는 미리 정해진 스키마(schema)에 따라서 구조화되지 않은 정보를 포함함 ―; 및
   상기 컴퓨팅 시스템에 의해서, 상기 스키마에 따라서 각 데이터 소스에 있는 상기 정보를 구조화함으로써 상기 데이터 레코드들의 집합에서 각 데이터 레코드를 생성하는 단계를 더 포함하는, 방법.
7. 청구항 1에 있어서,
   상기 컴퓨팅 시스템에 의해서, 상기 컬럼형 스트라이프들의 집합 내에서 쿼리를 수행하는 단계; 및
   상기 컴퓨팅 시스템에 의해, 상기 쿼리의 수행에 응답하여, 상기 쿼리에 의해 식별되는 상기 컬럼형 스트라이프의 집합 중 한 컬럼형 스트라이프로부터의 상기 값들의 서브셋을 포함하는 새로운 컬럼형 스트라이프를 출력하는 단계를 더 포함하는, 방법.
8. 청구항 7에 있어서,
   상기 컬럼형 스트라이프들의 집합의 상기 쿼리는 상기 컬럼형 스트라이프들의 집합에 포함된 상기 데이터 값들을 데이터베이스에 로딩하지 않고 수행되는, 방법.
9. 청구항 1에 있어서,
   상기 컴퓨팅 시스템이, 제1 컬럼형 스트라이프의 쿼리를 수행할 때, 상기 쿼리에 의해 특정되는 데이터 값을 포함하지 않는 하나 이상의 데이터 블럭들을 쿼리하는 것을 회피하도록, 상기 컬럼형 스트라이프들의 집합 중 적어도 하나의 상기 제1 컬럼형 스트라이프는 다수의 데이터 블럭을 포함하고, 상기 다수의 데이터 블럭 중 적어도 일부 각각은 각 블럭의 값들에서 발견되는 값들의 종류를 정의하는 주장값(assertion value)을 포함하는, 방법.
10. 청구항 1에 있어서,
    제1 데이터 레코드는 제2 데이터 요소에 대한 부모 데이터 요소인 제1 데이터 요소와 상기 제1 데이터 요소에 대한 자식 데이터 요소인 제2 데이터 요소를 포함하고,
    제1 컬럼형 스트라이프는 상기 제1 데이터 레코드에 있는 상기 제1 데이터 요소에 상응하는 데이터 값과 상기 데이터 레코드들의 집합에 있는 상기 제1 데이터 요소의 인스턴스들에 상응하는 모든 다른 데이터 값들을 포함하며, 그리고
    제2 컬럼형 스트라이프는 상기 제1 데이터 레코드에 있는 상기 제2 데이터 요소에 상응하는 데이터 값과 상기 데이터 레코드들의 집합에 있는 상기 제2 데이터 요소의 인스턴스들에 상응하는 모든 다른 데이터 값들을 포함하는, 방법.
11. 청구항 2에 있어서,
    상기 내포된 데이터 모델에 따라 저장된 상기 데이터 요소들 중 일부 데이터 요소들은, 상기 내포된 데이터 모델에 따라 저장된 상기 데이터 요소들 중 다른 데이터 요소들의 자식인 ― 상기 다른 데이터 요소들은 부모 데이터 요소들로서 참조됨 ―, 방법
12. 컴퓨터 프로그램 명령어들을 포함하는 컴퓨터 프로그램이 저장된 컴퓨터 판독가능 매체로서, 상기 컴퓨터 프로그램 명령어들은 하나 이상의 프로세서로 하여금 청구항 1 내지 11 중 어느 하나의 항에 따른 동작들을 수행하도록 동작가능한, 컴퓨터 판독가능 매체.
13. 시스템으로서,
    하나 이상의 프로그램 가능한 프로세서; 및
    상기 프로세서에 연결되고 그 내부에 저장된 명령어들을 가지는 컴퓨터-판독가능 스토리지 디바이스를 구비하고,
    상기 명령어들은 상기 하나 이상의 프로그램 가능한 프로세서들에 의해 실행될 때, 상기 하나 이상의 프로그램 가능한 프로세서들로 하여금 청구항 1 내지 11 중 어느 하나의 항에 따른 동작들을 수행하도록 하는, 시스템.
    
14. 삭제
15. 삭제

Images