KR101938953B1 - 빅 데이터 질의 엔진을 위한 플래시 최적화된 열 데이터 배치 및 데이터 액세스 처리 알고리즘 - Google Patents

빅 데이터 질의 엔진을 위한 플래시 최적화된 열 데이터 배치 및 데이터 액세스 처리 알고리즘 Download PDF

Info

Publication number
KR101938953B1
KR101938953B1 KR1020167032457A KR20167032457A KR101938953B1 KR 101938953 B1 KR101938953 B1 KR 101938953B1 KR 1020167032457 A KR1020167032457 A KR 1020167032457A KR 20167032457 A KR20167032457 A KR 20167032457A KR 101938953 B1 KR101938953 B1 KR 101938953B1
Authority
KR
South Korea
Prior art keywords
selection
column
row
data
estimation
Prior art date
Application number
KR1020167032457A
Other languages
English (en)
Other versions
KR20160145785A (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 KR20160145785A publication Critical patent/KR20160145785A/ko
Application granted granted Critical
Publication of KR101938953B1 publication Critical patent/KR101938953B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/24569—Query processing with adaptation to specific hardware, e.g. adapted for using GPUs or SSDs
    • G06F17/30315—
    • G06F17/30519—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/22—Arrangements for sorting or merging computer data on continuous record carriers, e.g. tape, drum, disc
    • G06F7/24—Sorting, i.e. extracting data from one or more carriers, rearranging the data in numerical or other ordered sequence, and rerecording the sorted data on the original carrier or on a different carrier or set of carriers sorting methods in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1041—Resource optimization
    • G06F2212/1044—Space efficiency improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7208—Multiple device management, e.g. distributing data over multiple flash devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 발명은 질의들을 위한 데이터세트들의 플래시-최적화된 데이터 배치에 관한 것이다. 선택 열들이 선택 최적화된 배치에 따라 플래시 메모리에 저장되고, 상기 선택 최적화된 배치는 술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성된다. 상기 선택 최적화된 배치는, 각각의 선택 열에 대해서, 주어진 선택 열에서 고유 데이터 값들로 채워진 선택 열 사전을 저장하는 단계에 의해서 형성되고, 상기 고유 데이터 값들은 상기 선택 열 사전에서 소트된 순서로 저장된다. 행 위치 지정들은, 상기 주어진 선택 열에서 한 번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 주어진 선택 열 내에 상기 고유 데이터 값들이 존재하는 각 행 위치에 대응하여 저장된다.

Description

빅 데이터 질의 엔진을 위한 플래시 최적화된 열 데이터 배치 및 데이터 액세스 처리 알고리즘{FLASH OPTIMIZED COLUMNAR DATA LAYOUT AND DATA ACCESS ALGORITHMS FOR BIG DATA QUERY ENGINES}
[0001] 본 발명은 질의-처리(query processing) 동안 사용되는 플래시-최적화된 데이터 배치(flash-optimized data layout) 및 데이터 액세스 알고리즘에 관한 것이다.
[0002] "빅 데이터"라는 용어는 핸드-데이터 관리 툴들 또는 전통적인 데이터 처리 애플리케이션들을 사용하여서는 처리하기가 어려운 매우 크고 복잡한 데이터세트들의 모든 수집에 대한 전체적인 용어로서 급히 만들어져서 사용되었다. 빅 데이터의 도전들에는 캡처(capture), 큐레이션(curation), 저장(storage), 서치(search), 공유(sharing), 전송(transfer), 분석(analysis) 및 시각화(visualization)가 포함된다. 큰 데이터 세트들(larger data sets)에 대한 경향은 관련 데이터의 단일 큰 세트의 분석으로부터 파생될 수 있는 추가적인 정보 때문이며, 이는 데이터의 동일 총량을 갖는 분리된 작은 세트들과 비교할 때, 비즈니스 트렌드의 파악(spot business trends), 리서치의 품질 결정(determine quality of research), 질병 예방(prevent diseases), 판례 연결(link legal citations), 범죄와의 전쟁(combat crime) 및 실시간 도로교통 상황 결정(determine real-time roadway traffic conditions)을 위한 상관 관계들을 찾아낼 수 있게 해 준다.
[0003] 2012년에, 합리적인 시간 내에 처리 가능한 데이터 세트들의 크기의 한계는, 테라바이트의 수백만 배(millions of terabytes)인, 엑사바이트 정도의 데이터(on the order of exabytes of data)이다. 과학자들은 많은 영역들에서의 대규모 데이터 세트들로 인한 한계들에 정기적으로 부딪히는데, 이러한 영역들의 예들에는 기상학(meteorology), 유전체학(genomics), 신경 연결체학(connectomics), 복잡한 물리학 시뮬레이션(complex physics simulations), 그리고 생물학 및 환경 연구(biological and environmental research)가 포함된다. 그러한 한계들은 또한 인터넷 검색, 재정 및 비즈니스 정보학에도 영향을 준다. 데이터 세트들은 크기가 점점 증가하는데 그 이유는 그것들이 유비쿼터스 정보-감지 모바일 디바이스들(ubiquitous information-sensing mobile devices), 항공 감지 기술들(aerial sensory technologies (원격 감지)), 소프트웨어 로그들(software logs), 카메라들, 마이크로폰들(microphones), 무선 식별 리더들(radio-frequency identification (RFID) readers), 및 무선 센서 네트워크들(wireless sensor networks)에 의해서 수집되는 일이 증가하고 있기 때문이다. 정보를 저장하는 세계의 기술적 1인당 용량(The world's technological per-capita capacity)은 대략 1980년대 이후 매 40개월마다 두 배가 되었다. 2012년 현재, 매일 2.5엑사바이트들(2.5x1018) 의 데이터가 생성되었다.
[0004] 빅 데이터는 대부분의 관계형 데이터베이스 관리 시스템들(relational database management systems) 및 데스크탑 통계 그리고 시각화 패키지들(visualization packages)을 사용하여 작업하기는 어려운데, 수십, 수백 또는 수천의 서버들 상에서 병렬 소프트웨어를 대량으로 실행하는 것을 요구하기 때문이다."빅 데이터" 처리에서 고려할 사항은 데이터 세트를 관리하는 조직의 능력들, 및 자신의 영역에서 전통적으로 데이터 세트를 처리하고 분석하는 데 사용된 애플리케이션들의 능력들에 따라 다르다. 처음으로 수백 기가바이트의 데이터(hundreds of gigabytes of data)를 맞이하는, 일부 조직들에서는, 데이터 관리의 옵션들을 재고할 필요에서 시작할 수 있다. 다른 조직들에서는, 데이터 크기가 심각하게 고려되기 전에 수십 또는 수백 테라바이트에 달했을 수도 있다. 빅 데이터는 보통으로 사용되는 소프트웨어 툴들이 허용 가능한 처리시간 내에 데이터를 관리 및 처리하는 능력을 벗어난 크기를 갖는 데이터 세트들을 통상적으로 포함한다.
[0005] 한 실시 예에 따라, 질의들을 위한 데이터세트의 플래시-최적화된 데이터 배치 방법(a method for flash-optimized data layout)이 제공된다. 상기 방법은 선택 최적화된 배치(a selection optimized layout)에 따라 선택 열들(selection columns)을 플래시 메모리에, 프로세서에 의해서, 저장하는 단계를 포함하고, 상기 선택 최적화된 배치는 술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성된다. 상기 선택 최적화된 배치는, 각각의 선택 열을 위해, 주어진 선택 열 내의 고유 데이터 값들(unique data values)로 채워진 선택 열 사전(a selection column dictionary)을 저장하는 단계에 의해서 형성되고, 상기 고유 데이터 값들은 상기 선택 열 사전에서 소트된 순서로(in sorted order) 저장된다. 상기 선택 최적화된 배치는, 상기 주어진 선택 열에서 한번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함(duplicating)이 없이, 상기 주어진 선택 열 내에 상기 고유 데이터 값들이 존재하는 각각의 행 위치에 대응하는 행 위치 지정들(row position designations)을 저장함으로써 형성된다.
[0006] 한 실시 예에 따라, 질의들에 대한 데이터세트의 플래시-최적화된 저장을 위한 장치가 제공된다. 상기 장치는 프로세서, 및 메모리를 포함하고, 상기 메모리는, 상기 프로세서에 의해서 실행될 때, 상기 프로세서가 동작들을 실행하도록 하는 컴퓨터-실행가능 명령들을 포함한다. 상기 동작들은 선택 최적화된 배치에 따라 플래시 메모리 내에 선택 열들을, 상기 프로세서에 의해서, 저장하는 단계를 포함하고, 상기 선택 최적화된 배치는 술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성된다. 상기 선택 최적화된 배치는, 각각의 선택 열을 위해, 주어진 선택 열 내의 고유 데이터 값들로 채워진 선택 열 사전을 저장하는 단계에 의해서 형성되고, 상기 고유 데이터 값들은 상기 선택 열 사전에서 소트된 순서로 저장된다. 상기 선택 최적화된 배치는, 상기 주어진 선택 열에서 한번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 주어진 선택 열 내에 상기 고유 데이터 값들이 존재하는 각각의 행 위치에 대응하는 행 위치 지정들을 저장하는 단계에 의해서 형성된다.
[0007] 한 실시 예에 따라, 질의들에 대한 데이터세트의 플래시-최적화된 저장을 위한 컴퓨터 프로그램 제품이 제공된다. 상기 컴퓨터 프로그램 제품은 컴퓨터 읽기 가능 저장 매체를 포함하고, 상기 컴퓨터 읽기 가능 저장 매체는 그 위에 구현된 프로그램 명령들을 가지며, 처리회로에 의해서 실행 가능한 상기 프로그램 명령들은 상기 처리회로가 방법을 실행하도록 한다. 상기 방법은 선택 최적화된 배치에 따라 플래시 메모리 내에 선택 열들을, 프로세서에 의해서, 저장하는 단계를 포함하고, 상기 선택 최적화된 배치는 술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성된다. 상기 선택 최적화된 배치는, 각각의 선택 열에 대해, 주어진 선택 열에서 고유 데이터 값들로 채워진 선택 열 사전을 저장하는 단계에 의해서 형성되고, 상기 고유 데이터 값들은 상기 선택 열 사전에서 소트된 순서로 저장된다. 상기 선택 최적화된 배치는, 상기 주어진 선택 열에서 한번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 주어진 선택 열 내에 상기 고유 데이터 값들이 존재하는 각각의 행 위치에 대응하는 행 위치 지정들을 저장하는 단계에 의해서 형성된다.
[0008] 추가적인 특징들 및 장점들이 본 발명의 기술들을 통해서 실현된다. 본 발명의 다른 실시 예들 및 특징들이 여기서 상세히 기술되고 청구된 발명의 일부로 간주된다. 상기 장점들과 특징들을 갖는 본 발명을 더 잘 이해하기 위해 상세한 설명과 도면들을 참조한다.
[0009] 본 발명으로 간주되는 주제는 본 명세서의 결론 부분에 기재된 청구항들에서 구체적으로 기재되고 명확하게 청구되었다. 본 발명의 전술한 그리고 기타의 특징들 및 장점들은 첨부된 도면들과 함께 아래의 상세한 설명에서 명백하다.
[0010] 도 1a는 한 실시 예에 따른 클라우드 컴퓨팅 노드/클러스터에서의 컴퓨터 시스템/서버에 관한 개략도를 도시한다.
[0011] 도 1b는 한 실시 예에 따른 하나 또는 그 이상의 클라우드 컴퓨팅 노드들/클러스터를 갖는 클라우드 컴퓨팅 환경(50)을 도시한다.
[0012] 도 1c는 한 실시 예에 따른 컴퓨터 시스템/서버에서 특징들의 추가적인 상세 내용을 도시한다.
[0013] 도 2a는 TPCH 질의들에서 개별 선택 열들의 선택성(the selectivity)을 도시하는 그래프이다.
[0014] 도 2b는 TPCH 질의 6으로부터 개별 선택 열들의 선택성을 도시하는 그래프이다.
[0015] 도 3은 한 실시 예에 따른 노드/클러스터 내의 컴퓨터 시스템들/서버들에 걸친 분산파일 시스템(DFS) 블록들에서 단일 플래시질의파일(FlashQueryFile) 파일/배치로서 한 테이블이 어떻게 논리적으로 표현되는지를 도시한다.
[0016] 도 4a는 한 테이블 내에서 데이터 값들을 갖는 열들 및 행들의 원래 관계(the original relationship)를 도시한다.
[0017] 도 4b는 한 실시 예에 따른 선택 열들에 대한 선택 최적화된 배치를 도시한다.
[0018] 도 4c는 한 실시 예에 따른 추정 열들에 대한 추정 최적화된 배치를 도시한다.
[0019] 도 4d는 한 실시 예에 따른 상기 선택 최적화된 배치를 이용하는 예를 도시한다.
[0020] 도 4e는 한 실시 예에 따른 낮은/중간 농도 열들(low/medium cardinality columns)에 대한 추정 최적화된 배치의 구현을 도시한다.
[0021] 도 4f는 한 실시 예에 따른 높은 농도 열들(high cardinality columns)에 대한 추정 최적화된 배치의 구현을 도시한다.
[0022] 도 4g는 한 실시 예에 따른 추정 및/또는 선택 열들 모두에 사용될 수 있는 열들에 대한 하이브리드 추정 및 선택 배치(a hybrid projection and selection layout)를 도시한다.
[0023] 도 4h는 한 실시 예에 따른 추정 및/또는 선택 열들 모두에 사용될 수 있는 열들에 대한 최적화된 그리고 공간-효율적인(space-efficient) 추정 및 선택 배치를 도시한다.
[0024] 도 4i는 선택 및 추정 열로서 모두 인기 있는(popular) 한 실시 예에 따른 선택 최적화된 배치에 저장되는 열의 한 예를 도시한다.
[0025] 도 5는 한 실시 예에 따른 행 그룹들로 그룹화된 행들 및 열들을 도시하는 테이블이다.
[0026] 도 6은 한 실시 예에 따른 정규화된 데이터 읽기들의 비교를 도시한다.
[0027] 도 7은 한 실시 예에 따른 예시적 질의의 속도 증가(speedup)를 도시한다.
[0028] 도 8은 한 실시 예에 따른 처리 동안 데이터 읽기에서의 감소를 도시하는 그래프이다.
[0029] 도 9는 한 실시 예에 따른 데이터세트 질의들의 플래시-최적화된 데이터 배치를 위한 방법을 도시하는 흐름도이다.
[0030] 페타바이트의 데이터(petabytes of data)에 대한 특별 대화형 분석(ad hoc interactive analytics)이 급속히 힘을 얻어가고 있고 그리고 빅 데이터 웨어하우스들(Big Data warehouses)이 점점 인기를 얻고 있다. 특별 빅 데이터 질의 처리(ad hoc Big Data query processing)의 수행은 스토리지 성능에 크게 의존한다. 특별한 열 및 행-열 데이터 배치들(specialized columnar and row-columnar data layouts)과 연관된 알고리즘들이 개발되어서 데이터 읽기들을 질의들 내에 명시된 열들에만 한정함으로써 질의 처리의 속도를 높여 왔다(speed up). 그럼에도 불구하고, 이들 배치들은 질의와 관련이 없는 상당한 양의 데이터를 읽는 것을 수행한다. 질의 당 데이터 읽기의 양을 최소화하는 것과 추가적인 저장 계층 및 확장된 캐시로서 플래시와 같은 더 빠르고, 임의로 액세스 가능한 저장 매체를 이용하는(leverage) 것은 질의 수행과 스루풋(throughput)을 추가적으로 개선하기 위해 중요하다. 플래시는 하드 디스크(또한 하드 디스크 드라이브(HDD)라 함)와는 매우 다른 성능 특성을 가지고 있고; 하드 디스크들을 위해 최적화된 데이터 배치들 및 액세스 알고리즘들은 플래시 상에서는 최적에 못 미치는(suboptimal) 성능을 가져온다. HDD-최적화된 배치들 및 알고리즘들은 HDD들에 고유한 높은 찾기 시간들(high seek times)을 고려하여 가능한 한 임의의 I/O를 피하도록 설계되어 있으며, 순차적 액세스들이 강조되는데, 순차적 액세스들이 HDD들 상에서 임의의 액세스들보다 대단히(orders of magnitude) 빠르기 때문이다. 한편, 임의의 액세스들은 플래시 상에서는 아주 빠른데(HDD보다 40X~1000X 더 빠름), 그 이유는 플래시에서는 찾기 페널티(seek penalty)가 없기 때문이다. 플래시의 다른 성능 특성은 상기 배치들 및 알고리즘들의 기본적인 재설계를 요구한다.
[0031] 실시 예들은, 소위 플래시질의파일(FlashQueryFile)이라는 새로운 플래시-최적화된 데이터 배치, 플래시질의파일을 위한 연관된 직렬 변환기/직병렬 변환기(serializer/deserializer), 및 플래시질의파일(내의 테이블)의 즉석 질의 처리의 속도를 높이기 위한 선택 알고리즘들과 추정 알고리즘들을 제공한다. 상기 데이터 배치는 플래시 내 데이터가 저장된 테이블/열 구조이다. 플래시질의파일은 불필요한 데이터에 대하여 과감히 스킵함으로써 질의 당 데이터 읽기를 상당히 감소시킨다. 하드 디스크들을 위해 설계된 최신 기술의 배치들과는 달리, 플래시질의파일은 플래시에서 가능한 높은 임의 액세스 성능과 높은 내부 IO(입력 및 출력) 병렬화를 완전하게 이용함으로써 플래시로부터 최대 성능을 이용하기 위해 설계되었다. 플래시질의파일은 플래시 상에서 HDD-최적화된 행-열 데이터 배치(HDD-optimized row-columnar data layout) 및 그것과 연관된 알고리즘들과 비교하여 질의 속도 향상에서 4X~100X TPC-H 질의 속도 향상과 <1%~98% 범위의 질의 선택성에서 29%~99.08% 데이터 감소를 가져온다, TPCH는 트랜잭션 처리 성능 협회(the Transaction Processing Performance Council (TPC))가 제공하는 즉석 결정 지원 벤치마크(an ad hoc decision support benchmark )이다.
[0032] Hive, BigQuery, BigSQL, Impala, Presto, 및 HAWQ와 같은 빅 데이터 웨어하우스들은 점점 더 보편화되어 가고 있다. 특별 분석 (OLAP)SQL 질의들(ad hoc analytical (OLAP) SQL queries)을 페타바이트의 데이터에 대하여(over petabytes of data) 대화식으로(interactively) 실행하는 능력은 산업에서 아주 중요하다. 미리-계산된 큐브들(pre-computed cubes) 같은 분석적 질의들의 속도를 높이기 위한 전통적인 OLAP 기술들은 빅 데이터의 경우에는 더 이상 효과를 볼 수 없는데, 그 이유는 빅 데이터 세트들의 규모는 엄청나고(many-fold) 그리고 모든 차원들에 걸쳐 큐브를 유지하는 것은 비용이 너무 커서 불가능하기 때문이다(prohibitively expensive). 상기 질의들의 특수성을 고려할 때(Given the ad hoc nature of the queries), 인덱싱 또는 캐싱(indexing or caching)과 같은 기술들은 아무런 도움이 되지 않는다. 질의가 도착할 때 캐시 내에 데이터가 존재하지 않거나 또는 캐시 내에 데이터를 유지하기에는 너무 클 수 있는데, 이는 분석적 질의들은 통상적으로 최근 데이터뿐만 아니라 역사적 데이터를 액세스하기 때문이다. 그 결과 스토리지로부터 캐시되지 않은 데이터(uncached data)를 신속하게 액세스하는 능력이 특별 질의들의 대화식 처리에 중요한 역할을 한다. 전체 특별 분석적 질의 처리 시간을 감소시키기 위해 그리고 스루풋을 위해 저장 매체의 성능이 중요하다.
[0033] 빅 데이터 웨어하우스들은 스토리지 자체를 관리하지는 않고 그들을 위해 데이터를 저장하는 하부 분산 파일 시스템(the underlying distributed file system)에 의존한다. F1/BigQuery 는 콜로서스 파일 시스템(Colossus file system)을 사용하고 Hive, Impala 등과 같은 Hadoop 시스템들에 대한 SQL은 Hadoop 분산 파일 시스템(HDFS)을 사용한다. 빅 데이터 질의 처리를 위해 특별히 설계된 배치들 및 알고리즘들을 갖는, 직렬 변환기들/직병렬 변환기들(또한 serde들이라고도 함)이 파일 시스템(예를 들어, 기록-열(RCFile), 최적화된 기록-열(ORCFile), 및 Parquet)에서 테이블 데이터를 읽고 쓰기 위해 사용된다. 각각의 serde(즉, 직렬 변환기 및 직병렬 변환기)는 자기 자신의 파일/데이터 배치, 메타데이터, 인-메모리-데이터 구조들(in-memory data structures), 테이블 읽기(table read), 스캔(scan), 및 인제스트 오퍼레이터들(ingest operators)을 정의한다. 이들 serde들은 테이블 내 모든 열들을 읽지 않고 질의에 나타나는 열들만으로 데이터 읽기들을 제한함으로써 질의 당 데이터의 읽기 양을 줄여준다(cut down). 그러나, 이들 직렬 변환기들/직병렬 변환기들은 열들 내의 데이터가 모두 질의와 관련된 것이 아님에도 질의 내의 모든 열들을 위한 전체 열 테이블 데이터(the entire columnar table data for all the columns in the query)를 순차적으로 스캔해서 관련 없는 데이터를 상당히 읽는다. ORCFile이 술어부(predicate)에 기초하여 아주 조잡한 기준에서(at a very coarse-grained basis) 일부 데이터를 스킵하도록 하는 최대 및 최소 값들과 같은 열들에 관한 요약 정보를 유지함으로써 ORCFile은 테이블 스캔 오퍼레이터의 오버헤드를 감소시키려 한다. 선택 절(selection clause) 내 열들의 열 데이터가 소트되어 있고 높은 농도(high cardinality)(구별되는 값들의 수가 많음)를 가질 때 이러한 기술은 데이터를 스킵하는 데 효과적이다. 그러나, 열들의 대부분은 본래 소트되어 있지 않고 농도도 낮다. 질의 당 읽혀야 할 필요가 있는 데이터를 더욱 감소시키기 위해 정교한 내부-행-그룹 데이터 스킵핑(fine-grained, intra-row-group data skipping)을 가능하게 하는 IO-효율적인 배치들 및 기술들을 개발할 필요가 있다.
[0034] 본 출원이 클라우드 컴퓨팅에 관한 설명을 포함한다고 해서, 본 발명의 구현이 클라우드 컴퓨팅 환경에 한정되는 것이 아님을 이해하여야 한다. 다시 말하면, 본 발명의 구현들은 현재 알려져 있거나 또는 나중에 개발될 모든 종류의 컴퓨팅 환경에서 구현될 수 있다. 클라우드 컴퓨팅은 최소 관리 노력으로 또는 서비스의 제공자와 대화로서 신속하게 제공하고 해제할 수 있는 구성 가능한 컴퓨팅 자원들(예를 들어, 네트워크들, 네트워크 대역폭, 서버들, 처리, 메모리, 스토리지, 애플리케이션들, 가상 머신들, 및 서비스들)의 공유 풀(a shared pool)로 편리한, 온-디맨드 네트워크 액세스(convenient, on-demand network access)를 가능하게 해주는 서비스 전달의 한 모델이다. 이 클라우드 모델은 적어도 다섯 가지 특성들, 적어도 세 가지 서비스 모델들, 및 적어도 네 가지 배치 모델들을 포함할 수 있다.
[0035] 이제 도 1a를 참조하면, 클라우드 컴퓨팅 노드/클러스터의 개략도가 한 실시 예에 따라 도시되어 있다. 클라우드 컴퓨팅 노드/클러스터(10)은 빅 데이터를 저장하고/처리하는 데 이용될 수 있는 적당한 클라우드 컴퓨팅 노드/클러스터의 오직 한 예일 뿐이며 여기서 기술되는 실시 예들의 사용 범위 또는 기능에 관하여 어떠한 제한을 제안할 의도가 없다. 아무튼, 클라우드 컴퓨팅 노드/클러스터(10)은 여기서 설명하는 모든 기능 세트를 구현하거나 수행할 수 있다.
[0036] 클라우드 컴퓨팅 노드/클러스터(10)에는 다수의 컴퓨터 시스템들/서버들(12)가 존재하고, 이들은 다양한 기타 범용 목적 또는 특별 목적의 컴퓨팅 시스템 환경들 또는 구성들에서 동작 가능하다(operational). 다수의 컴퓨터 시스템들/서버들(12)은 접속들(82)(예를 들어, 파이버 옵틱스, 등)을 통해서 접속된다. 다수의 컴퓨터 시스템들/서버들(12)에 관한 특정 상세 사항들은 도 1a에 도시되어 있지만, 이러한 상세 사항들은 컴퓨터 노드/클러스터(10)의 다른 컴퓨터 시스템들/서버들에도 적용할 수 있다. 컴퓨터 시스템들/서버들(12)과 사용하기에 적합한 잘 알려진 컴퓨터 시스템들, 환경들, 및/또는 구성들의 예들에는, 개인용 컴퓨터 시스템들, 서버 컴퓨터 시스템들, 씬(thin) 클라이언트들, 씩(thick) 클라이언트들, 핸드헬드(handheld) 또는 랩탑 디바이스들, 멀티프로세서 시스템들, 마이크로프로세서-기반 시스템들, 셋톱 박스들, 프로그램 가능 가전제품들, 네트워크 PC들, 미니컴퓨터 시스템들, 메인프레임 컴퓨터 시스템들, 및 위의 시스템들 또는 디바이스들 모두 그리고 이와 유사한 것들을 포함하는 분산 클라우드 컴퓨팅 환경들이 포함되나, 이에 한정되지 않는다.
[0037] 컴퓨터 시스템들/서버들(12)는 컴퓨터 시스템에 의해서 실행되는, 프로그램 모듈들과 같은, 컴퓨터 시스템 실행 가능 명령들의 일반 맥락에서 기술될 수 있다. 일반적으로, 프로그램 모듈들은 특정 태스크를 수행하거나 또는 특정 추상 데이터 유형들(particular abstract data types)을 구현하는 루틴들, 프로그램들, 객체들, 컴포넌트들, 로직, 데이터 구조들 등을 포함할 수 있다. 컴퓨터 시스템들/서버들(12)는 분산 클라우드 컴퓨팅 환경들에서 사용될 수 있는데, 여기서 태스크들은 통신 네트워크를 통해서 링크된 원격 처리 디바이스들에 의해서 수행된다. 분산 클라우드 컴퓨팅 환경에서, 프로그램 모듈들은 메모리 스토리지 디바이스들을 포함하는 로컬 및 원격 컴퓨터 시스템 스토리지 매체 모두에 위치할 수 있다.
[0038] 도 1a에서 도시된 바와 같이, 클라우드 컴퓨팅 노드/클러스터(10)에서 컴퓨터 시스템들/서버들(12)는 범용-목적의 컴퓨팅 디바이스의 형태로 도시되었다. 컴퓨터 시스템들/서버들(12)의 컴포넌트들은 하나 또는 그 이상의 프로세서들 또는 처리 유닛들(16), 시스템 메모리(28), 및 시스템 메모리(28)을 포함하는 다양한 시스템 컴포넌트들을 프로세서(16)에 결합시키는 버스(18)을 포함할 수 있지만, 이에 한정되지는 않는다. 프로세서 유닛들(16)은 당업자가 이해하듯이 컴퓨터 실행 가능 명령들을 읽고, 처리하고, 그리고 실행하기 위해 처리 회로들(프로세서 회로들)을 포함한다.
[0039] 버스(18)은 여러 유형의 버스 구조들 중 하나 또는 그 이상을 나타내는데, 이에는 메모리 버스, 또는 메모리 컨트롤러, 주변 버스, 가속화된 그래픽 포트, 및 다양한 버스 아키텍처들 중 하나를 사용하는 프로세서 또는 로컬 버스가 포함된다. 전부는 아니지만, 예를 들면, 그러한 아키텍처들에는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 향상된 ISA(EISA) 버스, 비디오 전자 표준 협회(VESA) 로컬 버스, 및 주변 컴포넌트 인터커넥트(PCI) 버스가 포함된다.
[0040] 컴퓨터 시스템/서버들(12)는 다양한 컴퓨터 시스템 읽기 가능 매체를 포함한다. 그러한 매체는 컴퓨터 시스템/서버들(12)에 의해서 액세스 가능한 모든 이용 가능한 매체가 될 수 있으며, 이것은 휘발성 및 비-휘발성 매체, 제거 가능 및 비-제거 가능 매체를 포함한다. 시스템 메모리(28)은, 랜덤 액세스 메모리(RAM)(30) 및/또는 캐시 메모리(32)와 같은, 휘발성 메모리의 형태의 컴퓨터 시스템 읽기 가능 매체를 포함할 수 있다. 컴퓨터 시스템/서버(12)는 또한 다른 제거 가능/비-제거 가능, 휘발성/비-휘발성 컴퓨터 시스템 스토리지 매체를 포함할 수 있다. 예로서, 스토리지 시스템(34)는 비-제거가능, 비-휘발성 자기 매체(도시되지 않았고 이들은 통상적으로 "하드 드라이브", "하드 디스크", 및/또는 "하드 디스크 드라이브"라 부름)로부터 읽기와 이들에 대한 쓰기를 위해 제공될 수 있다. 비록 도시되지는 않았지만, 제거 가능, 비-휘발성 자기 디스크(예를 들어, "플로피 디스크")로부터 읽기와 이들에 대한 쓰기를 위한 자기 디스크 드라이브, 및, CD-ROM, DVD-ROM 또는 기타 광 매체와 같은, 제거 가능, 비-휘발성 광 디스크로부터 읽기와 이들에 대한 쓰기를 위한 광 디스크 드라이브가 제공될 수 있다. 그러한 경우에, 이들 각각은 하나 또는 그 이상의 데이터 매체 인터페이스들에 의해서 버스(18)에 접속될 수 있다. 아래에서 더 상세히 설명할 것이지만, 메모리(28)은 본 발명의 실시 예들의 기능들을 수행하도록 구성된 한 세트의(예를 들어, 적어도 하나의) 프로그램 모듈들을 갖는 적어도 하나의 프로그램 제품을 포함할 수 있다.
[0041] 예로서, 메모리(28)은 하나의 운영체제, 하나 또는 그 이상의 애플리케이션 프로그램들, 기타 프로그램 모듈들, 및 프로그램 데이터를 포함할 수 있지만, 이에 한정되는 것은 아니다. 상기 운영체제, 하나 또는 그 이상의 애플리케이션 프로그램들, 기타 프로그램 모듈들, 및 프로그램 데이터(또는 이들의 조합)는 네트워킹 환경의 구현을 포함할 수 있다.
[0042] 또한, 컴퓨터 시스템/서버(12)는 플래시 메모리(75)(또한 이를 플래시라 함)를 포함한다. 플래시 메모리(75)는 실시 예들에 따라 여기서 논의하는 빅 데이터를 하드 디스크 드라이브(34)와 함께 저장한다. 플래시 메모리(75)는 플래시질의파일(80)을 포함한다. 플래시질의파일 (80)은 메모리(28)의 다른 부분에 저장될 수 있다. 플래시질의파일(80)은 여기서 기술하는 실시 예들의 기능들 및/또는 방법들을 수행하는 프로그램 모듈들(42)(이들은 하나 또는 그 이상의 소프트웨어 애플리케이션들일 수 있음)을 갖는다. 플래시질의파일(80)은 여기서 더 논의할 알고리즘을 구현할 수 있다. 플래시질의파일(80)의 특징들이 단일 컴퓨터 시스템/서버(12)에서도 주목받을 수 있지만, 플래시질의파일(80)(및 그 기능)은 컴퓨팅 노드/클러스터(10) 내의 기타 컴퓨터 시스템/서버들(12)에 걸쳐 분산될 수 있다. 플래시질의파일(80)은 여기서 논의되는 실시 예들을 구현하는 데 필요한 모든 소프트웨어 엘리먼트들로 구성된다.
[0043] 컴퓨터 시스템/서버(12)는 또한, 키보드, 포인팅 디바이스, 디스플레이(24) 등과 같은, 하나 또는 그 이상의 외부 디바이스들; 사용자가 컴퓨터 시스템/서버(12)와 대화할 수 있게 하는 하나 또는 그 이상의 디바이스들; 및/또는 컴퓨터 시스템/서버(12)가 하나 또는 그 이상의 다른 컴퓨팅 디바이스들과 통신할 수 있게 해주는 모든 디바이스들(예를 들어, 네트워크 카드, 모뎀 등)과 통신할 수 있다. 그러한 통신은 입력/출력(I/O) 인터페이스들(22)를 통해서 일어날 수 있다. 또한, 컴퓨터 시스템/서버(12)는 네트워크 어댑터(20)을 통해서 근거리 네트워크(LAN), 일반 광역 네트워크(WAN), 및/또는 공중 네트워크(예를 들어, 인터넷)와 같은 하나 또는 그 이상의 네트워크들과 통신할 수 있다. 전술한 바와 같이, 네트워크 어댑터(20)은 버스(18)을 통해서 컴퓨터 시스템/서버(12)의 다른 컴포넌트들과 통신한다. 비록 도시되지는 않았지만, 기타 하드웨어 및/또는 소프트웨어 컴포넌트들이 컴퓨터 시스템/서버(12)와 함께 사용될 수 있음을 이해해야 한다. 이들의 예에는, 마이크로코드, 디바이스 드라이버들, 여분의 처리 유닛들, 외부 디스크 드라이브 어레이들, RAID 시스템들, 테이프 드라이브들, 및 데이터 아카이벌 스토리지 시스템들(data archival storage systems) 등을 포함할 수 있으나, 이에 한정되지는 않는다.
[0044] 이제 도 1b를 참조하면, 도 1b에는, 빅 데이터 웨어하우스로 고려될 수 있는, 예시적 클라우드 컴퓨팅 환경(50)이 도시되어 있다. 도시한 바와 같이, 클라우드 컴퓨팅 환경(50)은 하나 또는 그 이상의 클라우드 컴퓨팅 노드들(10)을 포함하는데, 클라우드 소비자들에 의해서 사용되는 로컬 컴퓨팅 디바이스들, 예를 들어, 개인 휴대용 단말기(PDA) 또는 셀룰러 폰(54a), 데스크탑 컴퓨터(54b), 랩탑 컴퓨터(54c), 및/또는 자동차 컴퓨터 시스템(54n)은 이들과 통신할 수 있다. 클라우드 컴퓨팅 환경(50)은 실시 예들에 따라 컴퓨팅 디바이스들(54a-n)으로부터 데이터를 저장, 처리, 및 질의하는 다수의 노드들/클러스터들(10)을 포함할 수 있다. 노드들/클러스터들(10)은 연결들(84)(예를 들어, 파이버 옵틱 연결들)을 통해서 서로 통신할 수 있다. 이들은, 예를 들어, 사설(Private), 지역(Community), 공중(Public), 또는 전술한 하이브리드(Hybrid) 클라우드, 또는 이들의 조합과 같은, 하나 또는 그 이상의 네트워크들에서 물리적으로 또는 가상으로 그룹화 될 수 있다(도시되지 않음). 이는 클라우드 컴퓨팅 환경(50)이 인프라스트럭처(infrastructure), 플랫폼들(platforms) 및/또는 소프트웨어를 서비스로 제공하여 클라우드 소비자가 로컬 컴퓨팅 디바이스 상에 자원들을 유지할 필요가 없게 한다. 도 1b에서 도시한 컴퓨팅 디바이스들(54a-n)의 유형들은 예시적으로만 제공된 것이며 컴퓨팅 노드들(10)과 클라우드 컴퓨팅 환경(50)은 모든 유형의 네트워크 및/또는 네트워크 주소지정 가능 연결(예를 들어, 웹 브라우저)을 통해 모든 유형의 컴퓨터화된 디바이스와 통신할 수 있음을 이해해야 한다. 도 1c는 특징이 흐려지지 않도록 일부 특징들을 생략한 한 실시 예에 따른 컴퓨터 시스템/서버의 특징들을 더 상세하게 도시한다.
[0045] 빅 데이터를 위해, 질의 처리를 위한 저장 매체의 성능은 다음 3가지 방식으로 향상될 수 있다: 1) IO-효율적인 serde들 및 열 배치들(columnar layouts)을 사용하여서 질의당 스캔될 필요가 있는 데이터를 감소시킴, 2) 더 높은 IO 스루풋을 위해 스케일-아웃 병렬처리(scale-out parallelism)에 의존함, 및/또는 3) 데이터에 대한 빠른 액세스를 위해 메모리 또는 플래시와 같은 더 빠른 매체들을 이용함. 본 출원은 실시 예들에 따라 기술들 1) 및 3)을 사용하여 저장 매체의 성능을 향상하는 데 초점을 맞추고 있다. 본 출원은 질의 처리의 성능을 향상하도록 질의 당 데이터 읽기를 감소시키기 위해 내부-행-그룹 수준에서(at intra-row-group level) 열 데이터의 정교한 스킵핑(fine-grained skipping)을 가능하게 하는 새로운 메커니즘을 제공한다.
[0046] 최신 기술의 serde들은 하드디스크들(HDD)을 위해 설계되었는데, 여기서 모든 아키텍처 결정들, 데이터 구조들, 추정 알고리즘들(projection algorithms), 선택 알고리즘들(selection algorithms), 및 결합 알고리즘들(join algorithms)은, 파라미터들과 함께, HDD들의 기본적인 성능 특성에 기초한다. HDD들에서의 본질적인 높은 찾기 시간(the high seek times)을 고려하여 임의의 I/O는 가능한 피하고, 순차적 액세스들이 강조되는데, 이들이 HDD들 상의 임의의 액세스들보다 훨씬 더 빠르기 때문이다. 저장 매체 계층에서 플래시와 같은 더 빠르고 임의로 액세스가 가능한 저장 매체들을 이용하는 일반적인 방법은 리액티브 티어링(reactive tiering)을 통해서 이루어졌다. 리액티브 티어링에서, 저장 모듈은 데이터에 대한 액세스 패턴들을 관리해서 빈번하게 액세스되는 데이터는 높은 성능의 플래시 계층(tier)(즉, 플래시 메모리)으로 이동시킨다. 그러한 이동은 애플리케이션이 알지 못하는 상태에서 투명하게 이루어진다. 그 결과, 애플리케이션은 하드 디스크들을 위해서 고유하게 설계된 동일 알고리즘들, 프리페칭 알고리즘들, API들(애플리케이션 프로그램 인터페이스들)을 가지고 플래시에 상주하는 데이터를 계속 액세스한다. 그 결과, 달성되는 성과는 실시 예들에서 개시된 플래시 최적화된 알고리즘들 및 코드에서 달성 가능한 성과보다는 대단히 적다. 최신 기술에서 사용되는 바와 같이, HDD-최적화된 알고리즘들 및 가정들을 사용하면서, 플래시에 기존의 SQL(구조화된 영어 질의 언어) 파일 포맷들 중 하나를 단순하게 데이터 배치하면 그러한 임의의 액세스 가능한 매체들에서 달리 달성 가능한 성능이득 및 정교한-데이터 스킵핑을 매우 적게 이용할 수 밖에 없다. 플래시의 더 높은 비용을 정당화 할 수 있는 최적 성과/$를 달성하기 위해, 순차적으로 액세스하던 HDD들로부터 플래시와 같은 임의의 액세스 가능 스토리지 매체들로 전환은 기본적인 설계 결정들, 데이터 배치들, 선택, 및 serde들의 추정 오퍼레이터들에 관한 재검토를 요구한다.
[0047] 그러나, 본 발명의 실시 예들은 컴퓨터 노드들/클러스터(10)에 저장된 빅 데이터에 대해 SQL을 위한 플래시질의파일(80)로 불리는 신규한 플래시 최적화된 직렬 변환기/직병렬 변환기를 제공한다. 플래시질의파일의 선택 알고리즘, 추정 알고리즘, 인제스천(ingestion) 알고리즘, 데이터 배치들, 및 메타데이터는 최적의 성과/$를 내기 위해 플래시(플래시 메모리(75))와 같은 임의의 액세스 가능 저장 매체에 대해 최적화된다. 플래시질의파일(80)은 저장 매체 계층화(tiering)를 인지하고 플래시 계층(tier)(플래시 메모리(75)) 내에 플래시-적합한, 인기 열들(popular coulms)의 서브세트의 예측 배치(predictive placement)를 애플리케이션-인지 방식으로(in an application-aware manner) 하기 위한 메커니즘을 제공한다. 이것은 플래시질의파일(80)이 특별 분석적 질의들에 대해 확실한(upfront) 성과 보장을 제공할 수 있게 해준다. 플래시질의파일(80)은 정교한 데이터 스킵핑을 할 수 있도록 데이터 구조들 및 메타데이터를 근본적으로 재설계를 하고 술어부 푸시다운(predicate pushdown) 및 늦은 구체화(late materialization)를 이용하여 선택들 및 추정들 동안 질의에 절대적으로 필요한 데이터만을 읽음으로써 질의 처리 지연을 감소시킨다. 플래시질의파일(80)은 또한 플래시에 의해서 허용된 내부 IO 병렬 처리에 의해서 가능하게 되는 자신의 선택 알고리즘 내의 데이터 액세스 병렬처리를 이용한다. 플래시질의파일(80)은 각각의 임의의 액세스가 또한 그것과 연관된 API 오버헤드를 가질 때 매우 중요한 스캔 알고리즘에서 순차적 및 임의의 액세스들의 균형을 유지함에 있어서 플래시(75)의 특성들을 조심스럽게 고려한다. 한번의 대규모 순차적 액세스를 하는 대신 소규모의 임의의 액세스들을 너무 자주 하면 API 콜 오버헤드가 지배적(dominant)이 될 경우 성능을 실질적으로 손상할 수 있다. 결국, 플래시의 성능의 장점들을 이끌어 낼 수 있게 하기 위해 고-성능 IO API들, 객체 직렬변환 및 직병렬 변환, 그리고 데이터 구조들을 사용하는 것의 중요성을 플래시질의파일(80)은 보여준다. 과도하게 버퍼를 하고 프리페치를 하는 API들 같은 하드 디스크들을 위해 고유하게 설계된 API들을 사용하면 플래시(75)의 성능 장점들을 실질적으로 무효화할 수 있다.
[0048] 최신 기술에서, 기존의 연구는 갱신이 많은 온라인 트랜잭션 처리(OLTP) 워크로드에서 플래시를 이용하는 것에 주로 치중했었다. 분석적 처리(OLAP) 워크로드에서 플래시를 이용하는 것에 대해서는 제한적으로 연구되었고, 빅 데이터 SQL을 위해서 플래시를 이용하는 것에 대해서는 연구가 전혀 없었다. OLAP 워크로드는 성격상 대부분 순차적이고 또한 전체 테이블을 스캔하는 것이 필요하므로 플래시를 이용할 수 없다는 것은 일반적인 오해이다. 그러나, 본 출원의 광범위한 실험들과, OLAP 워크로드 및 데이터 세트들의 분석의 결과에서 이것이 오해임이 밝혀졌다. 따라서, 본 발명의 실시 예들은 플래시질의파일(80)을 통해서 빅 데이터 분석적 질의 처리를 위한 플래시-최적화된 직렬 변환기 및 직병렬 변환기(serde)를 제공한다.
[0049] 아래의 표제들 및 부제들은 이해를 돕기 위해 설명의 목적으로 제공되는 것임을 유의해야 한다. 그러나, 표제들 및 부제들은 제한을 의미하지는 않는다.
[0050] I. 빅 데이터 생태계에서 플래시를 사용하는 것에 대한 지지/근거
[0051] 플래시는 빅 데이터 저장 매체 계층에서 점점 보편화되어 가고 있다. 플래시는 디스크들과 비교하여 임의의 액세스에서 40-1000X의 성능 향상을 그리고 순차적 대역폭에서 2-7X의 성능 향상을 제공한다. 플래시는 비-휘발성이고, 따라서, 데이터 중복을 가질 필요성이 없다. 플래시는 데이터를 위한 1차의 유일한 계층(the primary and only tier for the data)으로서 기능할 수 있다. 한편, RAM의 휘발성은 비-휘발성 매체에 데이터의 추가의 보존용 사본을 필요로 하고, 그 결과 상당한 데이터 중복을 야기하는데, 이는 빅 데이터 시스템에서 큰 문제이다. 플래시 디바이스들은 플래시 메모리 패키지들의 어레이 상에서 구축되고, 다수의 채널들을 통해서 플래시 메모리 컨트롤러들에 연결되므로, 디스크들보다 IO의 동시 처리를 위해 상당히 높은 정도의 IO 병렬 처리가 플래시에서는 가능하다. 논리적 블록들은 다수의 플래시 메모리 패키지들에 걸쳐 분해되는데(striped), 이는 독립적이고, 동시적인 데이터 액세스를 가능하게 한다. 플래시의 내부 IO 병렬처리는 더 높은 성능을 위해 추가로 이용될 수 있다.
[0052] 플래시는 용량에 제약이 있는 RAM보다 덜 비싸고 그리고 또한 여분의 RAM을 추가하기 보다는 제2 수준 캐시로서 사용하는 것이 더 낫다. 질의들과 반복적인 컴퓨팅을 위해 Hadoop을 더 빠르게 하는 것에 관한, 최근의 대규모 연구들은 매우 큰 사이즈의 RAM에 심하게 의존한다. 플래시는 아주 적은 비용으로 RAM보다 훨씬 더 높은 용량이 가능하므로 훨씬 높은 성능/$를 달성할 수 있다. 플래시는 또한 하드 디스크들보다 훨씬 더 에너지- 효율적이고 에너지-비례적이며, 이것은 추가적으로 플래시를 에너지 비용에서의 감소가 유지의 전체 비용에 중요한 영향을 미치는 빅 데이터 클러스터들에서의 저장을 위해 매력적인 선택이 되게 한다. 더 나아가서, 플래시는 Map Reduce 업무들로부터 맵(map)을 저장하는데 매우 바람직하며 그리고 성능을 소트(sort) 및 상당한 양의 중간 데이터를 생성하는 다른 벤치마크들의 3X 만큼 성능을 증가시킨다.
[0053] 플래시의 전체적인, 높은 성능, 적은 공간(small footprint), 저 전력 소비, 낮은 가격, 그리고 비-휘발성은, 본 발명의 실시 예들에 따른, 빅 데이터 클러스터들에서 스토리지 계층/캐시로서 사용하는 것을 아주 바람직하게 한다.
[0054] Ⅱ. 정교한 데이터 스킵핑을 위한 기회
[0055] 도 2a는 TPCH 질의들에서 개별 선택 열들의 선택성(the selectivity)을 도시하는 그래프(200)이다. 그래프(200)은 다양한 TPCH 질의들에서 각각의 선택 열의 질의 술어부(the query predicate)와 매치하는 행들을 보여준다. 열의 선택성은 질의(Q)의 술어부와 매치하는 열 내의 행들의 수이다. 예를 들어, 만일 주어진 열이 100% 선택성을 가지고 있다면, 이것은 열 내의 모든 행이 술어부와 매치한다는 것을 뜻한다. 만일 주어진 열이 25% 선택성을 갖는다면, 이것은 열 내의 행들의 25%가 그 질의의 술어부와 매치한다는 것을 뜻한다.
[0056] 당업자는 SQL 질의의 술어부(predicate)를 이해할 것이다. 예를 들어, 술어부들은 WHERE 절들(clauses) 및 HAVING 절들의 서치 조건(search condition)에서, FROM 절들의 결합 조건(join condition)에서, 그리고 (부울)값이 요구되는 기타 구성(construct)에서 사용된다. SQL에서 WHERE 절은 SQL 데이터 조작 언어(DML) 명제(statement)가 명시된 기준을 충족하는 행들에만 영향을 주어야 한다는 것을 명시한다. 이 기준은 술어부의 형태로 표현된다. WHERE 절들은 SQL DML 명제에 의해서 영향을 받는 또는 질의에 의해서 되돌려주는 행들의 수를 제한하기 위해 사용될 수 있다. 간단히 말해서, SQL WHERE 절은 SQL 명제, 예를 들어: SELECT, INSERT, UPDATE, 또는 DELETE 명제로부터 이들 결과들만 추출하기 위해 사용된다.
[0057] 그래프(200)에서, x-축은 TPCH 질의들을 도시하고 한편 y-축은 각각의 열에서 퍼센트(%) 선택성을 도시한다. TPCH 질의 6(Q6)이 600+백만 행들을 갖는 79 GB(기가바이트) TPCH 라인 항목 테이블(line item table)에 전달되었다(directed)고 가정하자. 최신 기술에서, 현재 열 및 행-열 serde들(the current columnar and row-columnar serdes)은 추정들(예를 들어, L_EXTENDEDPRICE, L_DISCOUNT) 및 선택 열들(예를 들어, 도 2b에서 그래프(210)을 참조하면, L_SHIPDATE, L_DISCOUNT, L_QUANTITY는 도 2a에서 TPCH 질의 6으로부터의 예시적 선택 열들임)모든 데이터(즉, 모든 행 위치들)를 읽어들일 것이다. 그러나, 도 2b에 표시되어 있는 바와 같이, 선택 열 L_SHIPDATE에서는 행들의 15%만, L_DISCOUNT에서는 18%만, 그리고 L_QUANTITY에서는 46%만 개별 열 질의 술어부들(individual column query predicates)과 매치한다. 세 개의 선택 열들에 걸쳐 오직 1%의 행들만 모든 술어부들과 매치하는데, 이는 질의와 관련한 추정 열들 L_EXTENDEDPRICE 및 L_DISCOUNT 내의 데이터는 오직 1%임을 뜻한다. 전체적으로, 다섯 개의 열들에 걸쳐서 오직 16%의 데이터가 질의와 관련된다. 기존의 serde들은 단지 1%의 관련 데이터를 추정하기(project) 위해 이들 추정 열들로부터 99% 정도의 높은 여분의 데이터를 읽을 수 있고 선택성이 50% 이하일 때 선택 열들로부터 50% 정도의 높은 여분의 데이터를 읽을 수 있다. 유사한 경향이 다른 질의들에서도 존재하며 선택 열들의 선택성은 대부분의 TPCH 질의들의 경우에 1%-63% 범위이다. 따라서, 선택과 추정 단계에서 오직 질의와 관련된 열 데이터만 읽을 수 있는 내부-행-그룹 정교한 데이터 스킵핑 기술(an intra-row-group fine-grained data skipping technique)은 분석적 질의 당(전술한) 읽어야 할 필요가 있는 데이터를 상당히 감소시킬 수 있다
[0058] Ⅲ. 플래시질의파일(FlashQueryFile)
[0059] 이 섹션에서, 본 출원은 플래시질의파일(80)의 플래시-최적화된 데이터 배치, 인제스천 알고리즘(ingestion algorithm), 선택 알고리즘, 및 추정 알고리즘을 설명한다.
[0060] A. 데이터 배치
[0061] 도 3은 한 실시 예에 따른 노드/클러스터(10) 내의 컴퓨터 시스템들/서버들(12)에 걸쳐 분산된 다수의 분산 파일 시스템(DFS) 블록들에 스플릿된(저장된) 단일 FlashQueryFile 파일/배치(304)으로서 어떻게 한 테이블이 논리적으로 표현되는지를 도시한다. 비록 도 3이 메모리(28)에 저장된 하나의 파일 블록(301)을 도시하지만, 하나의 파일 블록(301)은 노드/클러스터(10) 내의 컴퓨터 시스템들/서버들(12)에 걸쳐 분산된 수많은 파일 블록들(301)을 나타낸다. 도 3은 또한 플래시 메모리(75)에 저장된 메타데이터 헤더들을 강조하는데, 이에 관해서는 이하에서 논의한다.
[0062] 따라서, FlashQueryFile 파일/배치(304) 내의 열(coulmn)은 수평으로 나누어져서 다수의 행 그룹들을 구성하는데, 각각의 행은 구성 가능한 수의 행들(a configurable number of rows)을 포함한다. 하나의 파일 블록(301)은 다수의 행 그룹들을 포함한다. 플래시질의파일(80)은 다음의 세 개의 다른 수준들에서 메타데이터 헤더들을 유지한다: 1) RCHeader라 불리는 블록-수준 헤더, 2) RGHeader라 불리는 행-그룹-수준 헤더, 및 3) ColHeader라 불리는 열-수준 헤더. 헤더들(즉, RCHeader 310, RGHeader 315, 및 ColHeader 320)는 필요한 데이터로 빠르게 임의로 액세스하는 것을 돕기 위한 그리고 정교한 데이터 스킵핑(fine-grained data skipping)을 가능하게 하기 위한 데이터 구조들을 유지한다. 메타데이터 헤더들 RCHeader(310), RGHeader(315), 및 ColHeader(320) 각각은, 질의(예를 들어, 질의의 선택 단계/부분)를 실행하면서, 언제 전체 파일 블록을 스킵(하고 난 후 다음 파일 블록으로 이동)할지, 행 그룹을 스킵(하고 난 후 다음 행 그룹으로 이동)할지, 그리고/또는 열을 스킵(하고 난 후 다음 열로 이동)할지를 결정하기 위해 플래시질의파일(80)에 의해서 읽혀질 수 있는 메타데이터를 포함한다. 예로서, 선택 열(a selection column)(325), 낮은 농도 추정 열(a low cardinality projection column)(330), 및 아주 높은 농도 추정 열(a very high cardinality projection column)(335)가 도시되어 있다.
[0063] (파일 블록) RCHeader(310) 파일 블록 내 행 그룹들의 수(n_rgs) 및 버전 번호를 포함하며, 이 버전 번호는 플래시질의파일(80) 소프트웨어의 배치 동안 파일 블록 구조의 다양한 버전에 걸쳐 이 소프트웨어가 앞뒤의 호환성(backward and forward compatibility)을 유지하는 데 도움을 준다.
[0064] RGHeader(315) 헤더는 파일 블록 내 행 그룹의 시작 오프셋(rg_offset) 및 파일 블록 내 행 그룹의 사이즈(rg_size)를 포함한다. RGHeader(315)는 또한 행 그룹 내 존재하는 행들 및 열들의 수를 포함한다. 예를 들어, 만일 행 그룹 크기가 파일 블록을 위해 천만(10 million)이 되도록 구성된다면, rg_rows 필드는 그 값으로 천만을 포함할 것이다.
[0065] ColHeader(320)은 파일 블록 내 여러 가능한 열 배치들(various possible columnar layouts)에 대한 파일 오프셋 포인터들을 유지한다. 한 열의 사전(dictionary)의 파일 오프셋 및 크기는 u_offset 및 u_size에 각각 유지된다. u_offset 및 u_size 필드들은 빠른 추정 및 선택 위한 사전(예를 들어, 선택 사전 및/또는 추정 사전)을 이용하는 플래시질의파일 배치들을 위해 유지된다(populated). l_offset 및 l_size 필드들은 추정-최적화된 배치에서 사용되는 룩업 구조의 파일 오프셋(file offset of the lookup structure)을 포함한다. d_offset 및 d_size 필드들은 현 상태로(as-is) 저장되는 열들의 데이터의 파일 오프셋(file offset of data of columns)을 포함한다(예를 들어, 농도=1일 때 열들은 사전 없이(without any dictionary) 현 상태로 저장된다). FlashQueryFile(80)에 의해서 실행될 때, 화살들(341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354)은 관계들(relationships) 및 헤더들의 메타데이터의 사용들을 표시한다. 화살들(341-354)은 오프셋 필드와 그 오프셋 필드가 파일 블록(301) 내에서 가리키는 데이터 구조 사이의 관계를 표시한다.
[0066] 모든 구조들 내 데이터 유형들은 한 눈에 보아서 공간-효율이 유지되게 신중히 선택된다. 플래시질의파일(80)은 FlashQueryFile 파일(304)(인제스천 알고리즘(an ingestion algorithm) 102에 의해서 결정됨) 내에 두 개의 데이터 배치들을 유지한다: 하나는 질의의 선택 단계/부분에 대해 최적화된 것이고 다른 하나는 질의의 추정 단계/부분에 대해 최적화된 것이다. 실험자들의 관측에서, 술어부 값들(the predicate values)과, 열들의 순서(order) 및 수(number)가 특별 질의들(ad hoc queries)에 걸쳐서 변화하는 동안, 일부 열들(some columns)은 추정 또는 선택 열들로서 어느 쪽이든지 인기가 있는 경향을 보였다(tend to be popular). 예를 들어, TPCH 데이터 세트에서, 두 개의 열들, L_EXTENDEDPRICE (도시하지 않음) 및 L_DISCOUNT는 가장 인기 있는 추정 열들이다. 그들의 인기도(popularity)는 TPCH가 재무 벤치마크(a financial benchmark)로서 모델될 때 직관적이고(intuitive); 이들 수의(numeric) 열들은 돈(money)을 다루며 합계들(aggregations)은 오직 수치들 상에서만 발생할 수 있다. L_SHIPDATE(도 2b에서)와 같은 데이터 유형을 갖는 열들은 날짜(date)가 통상적으로 분석적 질의들에서 중요한 차원이기 때문에 선택 열로서 매우 인기가 있다. 유사하게, 일차 및 외래 키들(primary and foreign keys)도 인기 있는 선택 열들이다. BlinkDB 페이퍼는 Facebook으로부터의 실제-세계 질의들을 그들의 분석에 기초한 선택 열들에 관한 유사한 관측을 갖고 있다: 80% 임의성 질의들 중 선택 절 내 발생하는 열들의 20% 서브세트. 이 관측에 기초하여, 플래시질의파일(80)은 열 데이터를 위해 세 개의 데이터 포맷들을 제공한다: 하나는 인기 있는 선택 열들을 위한 빠른 선택에 대해서 최적화된 포맷이고, 다른 하나는 인기 있는 추정 열들을 위한 빠른 추정에 대해서 최적화된 포맷이며 그리고 세 번째 포맷은 추정 및/또는 선택 열들(질의 내 다른 시간들에서)로서 사용될 열들을 위해 사용되는 하이브리드 배치다. 디폴트 배치는 하이브리드 포맷이며, 여기서 (플래시질의파일(80)에서) 관리자(the administrator) 및/또는 예측자 모듈(a predictor module)은 하이브리드 배치보다 더 나은 공간-효율성을 위해 선택-전용(a selection-only) 또는 추정-전용(a projection-only) 배치를 선택할 수 있다. 산업 발자취들에 관한 이전의 분석(Earlier analysis of industry traces)은 또한 선택 열들의 세트가 특별 질의들에서도 매우 예측 가능하게 남아있음을 발견하였다. 그러한 관측들에 힘입어, 플래시질의파일(80)(인제스천 알고리즘(102)를 통해서)은 선택적으로 사용자들과 질의 엔진들에게 테이블에서 일부 열들을 유일하게 추정된 열들, 유일하게 선택된 열들, 및/또는 추정된 열들과 선택된 열들의 조합인 열들로서 표시할(mark) 수 있게 해준다. 따라서, 플래시질의파일(80)(인제스천 알고리즘(102)를 통해서)은 공간 효율((FlashQueryFile 파일(304)에서)을 위해 자신의 데이터 배치 결정에서 이 정보(즉, 유일하게 추정된 열들, 유일하게 선택된 열들, 및/또는 추정된 열들과 선택된 열들의 조합인 열들로서 테이블에서 표시된 열들)의 팩터들(factors)을 이용한다(leverage). 인제스천 타임 알고리즘(ingestion time algorithm)(102)는 아래의 테이블 1에 기술되어 있다. 일차 키(a primary key)는 행을 고유하게 식별하는 열 또는 열들의 그룹임에 유의해야 한다. 모든 테이블은 일차 키를 가져야 하고, 한 테이블은 하나 이상의 일차 키를 가질 수 없다. 일차 키 특성은, 테이블의 제1 열에서와 같이, 열 정의의 일부로서 명시될 수 있거나, 또는 CREATE TABLE 명제의 분리된 절로서 명시될 수 있다. 외래 키(a foregion key)는 값들이 다른(또는 동일) 테이블의 일차 키에서 매칭 값들을 갖는 한 테이블 내 하나의 열 또는 한 세트의 열들이다. 외래 키는 자신의 일차 키를 참조한다고 한다. 외래 키들은 데이터 무결성(data integrity)을 유지하기 위한 메커니즘이다.
[0067] 테이블 1: 플래시-최적화된 인제스천 알고리즘(Flash-Optimized Ingestion Algorithm)
Figure 112016113626224-pct00001
Figure 112016113626224-pct00002
Figure 112016113626224-pct00003
[0068] 1) 선택 최적화된 데이터 배치(Selection Optimized Data Layout):
[0069] 도 4a는 하나의 테이블 내 데이터 값들을 갖는 열들 및 행들의 원래 관계(original relationship)(401)을 도시한다. 상기 테이블은 본 발명의 실시 예들에 따라 플래시 메모리에 대해 최적화되도록 플래시질의파일(80)에 의해서 컴퓨터 시스템들/서버들(10) 내로 흡수된다(ingested). 실시 예들은 원래 관계 내에 상기 테이블을 저장하지 않는다. 실시 예들에 따라, 도 4b는 (기본) 선택 최적화된 배치를 도시하고 도 4c는 가변 크기의 인기 있는 추정 열(a variable sized popular projection column)을 위한 (기본) 추정 최적화된 배치를 도시한다. 구현들에 따라, 도 4b-4i는 예시적 배치들이며, 도 3의 파일 블록(301)의 상세 내용들 및 특정 예들을 추가적으로 보여준다. 한 실시 예에 따라, 도 4a의 테이블의 원래 관계(401)로부터, 도 4b에 도시된 선택 최적화된 데이터 배치(402)는 (스토리지를 위해 플래시질의파일(80)에 의해서) 빠른 술어부 매치를 돕기 위해 그리고 선택 절/부분 동안(예를 들어, 술어부를 포함하는 where 절) 데이터 읽기를 감소시키기 위해 설계되었다. 각각의 잠재적인 선택 열을 위해, 플래시질의파일(80)은 상기 열의 각각의 행 그룹에서 발생하는 고유 값들을 추출하고 상기 고유 값들을 선택 사전(403)에서 인접하게 저장한다. 열 헤더(Column header)는 상기 고유 값들의 시작(start)에 대해 오프셋(off)을 유지한다. 그 다음, 각각의 값을 위해, 플래시질의파일(80)은 오프셋들(450)(약어로 off 및/또는 O) 및 각각의 고유 값이 상기 열 내에서 발생하는 상기 행 위치들의 세트의 길이(즉, 사이즈)(도 4b에서는 도시되지 않지만 도 3에서는 도시됨)를 저장한다. 최종적으로, 플래시질의파일(80)은 행 위치들 지정(405) 내의 각각의 고유 값을 위해 행 위치들의 세트들을 저장한다. 오프셋들(450)은 개별 고유 값에 대한 행 위치들의 각각의 모음/그룹핑의 위치에 대응한다. 메타데이터 헤더에서, 플래시질의파일(80)은 또한 행 그룹 당 열에서 엔트리들의 최대, 최소, 중간, 평균, 및 카운트를 추적한다. 최대는 최대 값을, 최소는 최소 값을, 중간은 중간 값을, 평균은 한 열의 각 행 그룹에서 발생하는 평균 값을 말한다. 카운트는 상기 열의 행 그룹에서 행들의 수를 말한다.
[0070] 도 4a의 원래 관계 테이블(401)에 대해 살펴본 바와 같이, 선택 최적화된 데이터 배치(402)는 동일 데이터 값들의 저장을 반복할 필요가 없이 열 C1을 저장하기 위한 새로운 방법이다. 도 4b는 선택 사전(403)(열 헤더 내)이 열 C1을 위한 고유 데이터 값들을 저장하고, 그 고유 데이터 값들이 (121, 130, 140, 150)인 예를 도시한다. 행 위치들 지정들(405)(열 헤더 내)은 원래 관계(401)에서 고유 값들을 포함한 열 C1 내의 각각의 행 위치를 위한 행 위치(즉, 이름)를 저장한다. 예를 들어, 고유 데이터 값(121)은 행 위치들 지정들(405) 내의 (원래 관계에 대한) 행 위치들(r2, r3, 및 r6)에 존재하지만, 고유 값(121)은 오직 한 번만 저장되고 3개의 다른 행 위치들에 대해서 중복되지 않는다. 고유 데이터 값(130)은 행 위치들 지정들(405) 내의 (행 위치 블로브(blob)에서)행 위치들 (r1 및 r4)에 존재하는 것으로서 표시된다. 고유 데이터 값(140)은 행 위치들 지정들(405) 내의 (행 위치 블로브(blob)에서) 행 위치들 r7에 존재하는 것으로서 표시된다. 고유 데이터 값(150)은 행 위치들 지정들(405) 내의 행 위치들 r5에 존재하는 것으로서 표시된다. 각각의 행 위치 블로브는 동일 고유 값을 갖는 것으로 표시된 하나 또는 그 이상의 행 위치들의 모음(a gathering)이다. 오프셋들(450)의 각각은 특정 행 위치 블로브의 시작에 더해진다.
[0071] 이 예에서, 플래시질의파일(80)은 열 C1을 선택 최적화된 배치(402)를 위한 하나의 선택 열로서 선택한다고 가정한다. 플래시질의파일(80)은 열 C1 내 각각의 행 그룹에서 발생하는 고유 값들이 고유 값들(121, 130, 140, 150)이 되도록 결정하고 이들 고유 값들을 메모리(28) 내에 인접하게 저장한다. 고유함(Unique)이란 플래시질의파일(80)이 열 C1 내의 동일 값의 저장을 반복할 필요 없이 선택된 열 C1에서 고유 값 각각의 단일 엔트리(a single entry)만을 필요로 한다는 것을 의미한다. 플래시질의파일(80)은, 제1 고유 값(121)의 시작에 대한 오프셋 같은, 고유 값들의 시작에 대한 오프셋(off)을 저장하도록 열 헤더를 구성한다. 플래시질의파일(80) 오프셋(450)과 각각의 고유 값이 열에서 발생하는 행 위치들 세트의 길이(즉, 크기)를 저장하기 때문에, 플래시질의파일(80)은 고유 값들(121, 130, 140, 150)의 각각(이들은 메모리(28) 내에 나란히 저장됨)을 위한 데이터의 정확한 위치를 결정할 수 있다.
[0072] 2) 추정 최적화된 데이터 배치(Projection Optimized Data Layout):
[0073] 원래 관계 테이블(401)로부터 취해진(흡수된) 바와 같이, 도 4c는 추정을 위해서만 사용되는, 즉 선택 절(the select clause)에만 나타나는 가변 길이 열을 위해 사용되는 추정 최적화된 데이터 배치(404)(메모리(28)에 저장된)을 도시한다. 만일 열이 가변 길이면, 플래시질의파일(80)은 오프셋과 열 내의 각각의 행 위치의 크기를 포함하는 룩업 구조(406)을 유지한다. 그 다음 만일 열의 농도(the cardinality)가 낮으면(low) 열 데이터는 사전(408) 내에 배치된다(laid out). 그렇지 않으면, 데이터는 파일 시스템 블록 상에 순차적으로 단순히 배치된다. 열 헤더는 룩업 구조(406)의 오프셋 및 데이터(값)을 유지한다. 만일 (특정) 열이 고정-길이면, 룩업 구조는 사용되지 않고 데이터는 단순히 순차적으로 파일 시스템 블록 내에 배치된다. 플래시질의파일(80)은 나중의 룩업들(later lookups)을 지원하기 위해 열 헤더 내의 필드 길이를 추적한다.
[0074] 도 4a의 원래 관계 테이블(401)과 비교하여, 추정 최적화된 데이터 배치(404)는 동일 데이터 값의 저장을 반복할 필요 없이 열 C3을 저장하기 위한 새로운 방식이다. 예를 들어, 추정 사전(408)은 (오직) 고유 데이터 값들(600, 602, 603, 670, 680)만 저장한다(즉, 어떠한 데이터 값들도 반복함이 없이). 룩업 구조(406)은 메모리 내의 오프셋(off)과 각각의 데이터 값의 사이즈(예를 들어, 바이트, 킬로바이트 등)를 저장한다. 데이터 값(600)은 열 C3에 한번만 나타나므로(즉, 행 1에만), 데이터 값(600)은 룩업 구조(406) 내에서 offr1 (오프셋) 및 sizer2를 갖는다. 그러나, 데이터 값(670)은 열 C3에 두 번, 즉 행 4 및 행 6 모두에 나타나고; 따라서, 룩업 구조(406)은 offr4 및 sizer4를 저장함으로써 행 4를 표시하고, 또한 offr6 및 sizer6을 저장함으로써 행 6을 표시한다. 데이터 값(670)은 두 개의 분리된 행들 4 및 6에 대응하기 위해 추정 사전(408) 내에 한 번만 저장됨에 따라, 공간도 절약하고 데이터 값(670)의 매치가 존재하는지(그리고 열 C3 내의 모든 단일 데이터 값을 실제로 스캔할 필요 없이 룩업 구조(406)(즉, 메타데이터)를 스캔함으로써 열 C3에서 몇 개의 행들이 매치하는지) 결정하는 것도 더 쉬워진다.
[0075] 3) 선택 및 추정 최적화된 데이터 배치들의 추가적인 예
[0076] 도 4d는 한 실시 예에 따라 (플래시질의파일(80)의) 선택 최적화된 배치(402)를 이용하는 예를 도시한다. 도 4d는 각각의 행 위치(r1-r14) 내의 데이터 값들(원래 관계(401)로부터 열 C1의 추가적인 데이터 값들을 갖는)을 선택 최적화된 배치(402)에 대하여 보여주는 전형적인 열 데이터 배치를 도시한다. 도 4d는 다음의 질의를 가정한다: Select sum( c2 ) where c1 =130 and c1 =150. 플래시질의파일(80)의 선택 알고리즘은 선택 최적화된 배치(402)로부터 사전(403) 및 오프셋(450)을 읽는다. 플래시질의파일(80)의 선택 알고리즘은 C1=130 및 C1=150의 술어부 매치를 수행한다. 최종적으로, 플래시질의파일(80)의 선택 알고리즘은 (오직) 매치하는 행 위치들의 목록(405)을 읽고(찾고(seek)) 그리고 매치하지 않는 행 위치들의 목록(405) 내의 행 위치들을 스킵한다. 결정된 행 위치들은 플래시질의파일(80)의 추정 알고리즘으로 전달된다.
[0077] 도 4e는 한 실시 예에 따른 (플래시질의파일(80)의) 낮은/중간 농도 열들(low/medium cardinality columns)을 위한 추정 최적화된 배치(the projection optimized layout)(404)의 구현을 도시한다. 낮은 그리고 중간 농도 열들은 높은 농도 열들보다 더 낮은 농도를 갖는다. 낮은 농도 열들은 중간 농도 열들보다 더 낮은 농도 값을 갖는다. 사전(408)은 열 데이터(열들 C3 및 C4의) 내에 발생하는 모든 고유 값들을 저장하기 위해 생성된다. 그 다음, 룩업 구조(406)은 각각의 행 위치의 열 값을 사전 값에 매핑하는 인덱스들로 생성된다. 도 4e에서, 인덱스들은 도 4c에서 도시한 오프셋 및 크기를 사용하지 않고 사전(408) 내의 각각의 엔트리에 매핑하기 위해 룩업 구조(406)에서 이용된다는 것에 유의한다. 룩업 구조(406) 내에서, indexr1 및 indexr2 모두는 사전(408) 내의 고유 값 Rosa Parks에 매핑된다. 열 헤더 내의 l_offset 및 l_size 필드들은 파일 블록(301) 내의 직렬화된 룩업 구조의 파일 오프셋을 가리키기 위해 세트된다. u_offset 및 u_size 필드들은 파일 블록(301) 내의 직렬화된 사전을 가리키기 위해 세트된다.
[0078] 도 4e에서, 플래시질의파일(80)의 추정 알고리즘은 모든 술어부들을 매칭하는 행들의 목록의 입력(선택 알고리즘으로부터의)을 수신하도록 구성되고, 행 위치들의 목록은 r1, r5, 및 r7이다. 플래시질의파일(80)은 사전(408)(고유 값들의)을 읽어 들이도록 구성된다. 플래시질의파일(80)은 (r1, r5, 및 r7과 같은) 각각의 원하는 행 위치를 위해 룩업 구조(406)에 저장된 인덱스에서 사전 값을 룩업(그리고 검색)하도록 구성된다.
[0079] 다른 실시 예에 따라, 도 4f는 높은 농도 열들을 위한 다른 추정 최적화된 배치(404)를 도시한다. 이 경우에는 공간-효율과 성능상의 이유들 때문에 사전이 사용되지 않는다. 열 데이터는 파일 블록(301)에 관해서 직렬화되고, 룩업 구조(406)은 가변 길이 열들을 갖는 열들(열 C3을 위해 표시된)에 대한 각각의 행 위치에서 열 값의 오프셋(예를 들어, offr1, offr2 등)을 저장한다. 열이 높은 농도와 고정 길이를 가질 때, 열 C4는 예시적 표시이다. 열 헤더 내의 l_offset 및 l_size 필드들은 파일 블록(301) 내의 직렬화된 룩업 구조의 파일 오프셋을 가리키도록 세트된다. d_offset 및 d_size 필드들은 파일 블록(301) 내의 직렬화된 열 데이터를 가리키도록 세트된다.
[0080] 도 4f에서, 플래시질의파일(80)의 추정 알고리즘은 모든 술어부들을 매칭하는 행들의 목록의 입력(선택 알고리즘으로부터의)을 수신하도록 구성되고, 행 위치들의 목록은 r1, r5, 및 r7이다. 만일 열이 가변 길이를 갖는다면, 플래시질의파일(80)은 개별 룩업 엘리먼트(룩업 구조(406)에서)를 하나의 선택(option)으로서 읽도록 또는 행 위치들을 클러스터하여 룩업 구조(406)의 덩어리(엘리멘트들의 그룹)를 읽도록 구성된다. 플래시질의파일(80)은 룩업 구조(406)에 저장된 off(오프셋)에 d_offset(열 헤더로부터)을 더함에 의해서 행 위치의 값의 파일 오프셋을 계산하도록 구성된다. 만일 열이 고정 길이를 갖는다면, 플래시질의파일(80)은 행 위치 오프셋을 d_offset + 행위치 * 필드 길이로서 계산한다. 플래시질의파일(80)은 플레시로부터 직접적으로 회색으로 표시된(즉 강조표시된)엔트리들을 읽도록 구성되고 나머지 데이터 읽기는 스킵한다.
[0081] 한 실시 예에 따라, 도 4g는 질의에 따라서 추정 및/또는 선택 열들 모두로서 사용될 수 있는 열들을 위한 하이브리드 추정 및 선택 배치(480)을 도시한다. 도 4g는 선택 및 추정 최적화된 배치들(402 및 404)의 조합을 갖는 배치를 도시한다.
[0082] 한 실시 예에 따라, 도 4h는 질의에 따라서 추정 및/또는 선택 열들 모두로서 사용될 수 있는 열들을 위한 최적화되고 공간-효율적인 추정 및 선택 배치(490)을 도시한다. 이 조합된 배치(490)은 열이 소트된 경우에만 사용될 수 있다. 룩업 테이블 내 각각의 그리고 모든 행 위치에 대한 룩업 엔트리를 유지하는 대신에, 오직 시작과 끝의 행 위치들은 룩업 테이블(491)에서 추적된다. 룩업 테이블(491)은 각각의 고유 값에 대응하는 룩업 엔트리에 대한 리버스 포인터(a reverse pointer)를 마리네이트시킴(marinating)으로써 사전(403, 408) 내의 각각의 고유 값을 위한 행 위치 블로브(blob)로서 기능한다.
[0083] 도 4i는 한 실시 예에 따라 (플래시질의파일(80)의) 선택 최적화된 배치(402)를 이용하는 다른 예를 도시한다. 한 실시 예에 따라, 도 4i는 질의가 선택 최적화된 배치(402)에 배치된 열을 동일 질의 내의 추정 열로서 사용하는 경우에도 (질의의) 추정 단계를 최적화하는 메커니즘을 도시한다. 예를 들어, 도 4i는 선택 및 추정 열로서 모두 인기가 있는 열(이를 하이브리드라 함)의 예를 도시하고, 실시 예들에 따라 플래시질의파일(80)은 (선택 및 추정 열 모두로서 사용되는) 이 하이브리드 열을 선택 최적화된 데이터 배치(402)에 저장한다. 이것이 가능한 이유는 플래시질의파일(80)에서 선택 처리가 추정 처리 이전에 일어나기 때문이다. 추정 알고리즘이 필요로 하는 룩업 구조(460)는 런-타임 질의 처리 동안 동적으로 생성된다. 선택 알고리즘은 열 값들 및 술어부와 매치하는 관련 열 위치들을 생성한다. 리버스 룩업 구조(460)은 상기 값들에 행 위치들을 매핑하는 이 추출된(distilled) 정보로부터 생성된다. 그 다음, 룩업 구조(460)는 추정 최적화된 데이터 배치에서 추가로 논의된 바와 같이 관심 있는 행 위치들에 관한 값들을 추정하기 위해 추정 단계 동안 사용된다.
[0084] 도 4i에서, (플래시질의파일(80)의) 하이브리드들을 위한 추정 알고리즘은 술어부들이 열 C1=130 및 열 C1=150인 모든 술어부들과 매치하는 행들의 목록의 (선택 알고리즘으로부터) 입력을 수신하도록 구성된다. 플래시질의파일(80)은 술어부들과 매치하는 목록 또는 열들의 입력을 수신하고, 인-메모리 룩업(in-memory lookup)(예를 들어, 사전(403))으로부터 직접적으로 (회색으로 표시된/강조표시된) 엔트리들을 읽고 나머지 데이터는 스킵한다.
[0085] B. 플래시-최적화된 선택 알고리즘
[0086] 플래시질의파일 플래시-최적화된 선택 알고리즘(104)(이를 또한 스캔 알고리즘이라고도 함)은 플래시를 위해 최적화되고, 전술한 바와 같이 성능을 위해 플래시에서 가능한 임의의 액세스들과 내부 병렬처리를 이용한다(leverage). 플래시질의파일(80)은 최소 가능 데이터를 가능한 한 빠르게 읽는 것의 목표를 가지고 설계된다. 플래시(예를 들어, 플래시 메모리(75))는 하드 디스크 드라이브들(하드 디스크 드라이브(34))보다 동시 IO 연산들에서 훨씬 많은 내부 병렬처리가 가능하고, 플래시질의파일(80)은 플래시-최적화된 선택 알고리즘(104)(스캔 알고리즘)을 사용함으로써 플래시에서 가능한 병렬처리를 이용한다. 최신 기술의 RCFile 및 ORCFile은 각각의 행-그룹을 직렬로 읽지만, 한편 플래시질의파일(80)은 각각의 행-그룹을 병렬로(즉, 동시에) 읽는다. 이에 더하여, 술어부와 매치하는 열 값들의 행 위치 블로브들도 또한 병렬로 읽는다. 모든 술어부들과 매치하는 행 위치들의 최종 교차점은 그 다음 추정 알고리즘(106)으로 전달된다.
[0087] 이제, 선택 알고리즘(104)의 연산들을 도시하기 위해, 다음 질의를 고려해 본다: select avg (a), sum(b) from the table where c = 5 and d > 10. 테이블 내에 열들 a, b, c, 및 d가 존재함에 유의한다. 이 예시적 질의에서, 추정 부분/단계는 select avg (a), sum(b) from the table 이고, 한편 선택 부분/단계는 where c = 5 and d > 10이다. 이 질의에서, 열 c에 대해 술어부는 c=5 (즉, 5)이고, 열 d에 대해 술어부는 d > 10 (즉, >10)이다.
[0088] 플래시질의파일의 선택 오퍼레이터(selection operator)는 먼저 블록 헤더(RCHeader)를 읽어 들인다. RCHeader는 행 그룹 당 모든 열들의 최대 및 최소 값들에 관한 통계 정보를 포함한다. 열 c의 최대 값이 < 5 또는 최소 값이 > 5일 때 열 d의 최대 값이 < 10인 모든 행 그룹들은 스킵된다. 열 c 및 d는 그 다음 그들의 농도에 기초하여 정렬된다(ranked). 더 낮은 농도를 갖는 열이 먼저 평가된다. 순서를 정하는(ordering) 목적은 데이터 읽기를 최소화 하기 위해서이다. 아래의 논의에서 이해할 수 있듯이 여기서 c는 낮은 농도를 갖는 열로 가정된다. 각각의 남아있는 행 그룹들을 위해, 플래시질의파일(80)은 열 c의 고유 값들을 포함하는 데이터 구조를 직병렬 변환하여(deserialize) 읽어 들이는(read in) 스레드들(threads)을 병렬이 되게 한다. 술어부 매치(프로세스/연산)는 열 c의 고유 값들에 대하여 수행되고, 만일 술어부(즉, 열c=5)가 하나 또는 그 이상의 고유 값들과 매치하면, 매치하는 고유 값들에 관련된 행 위치 블로브들은 병렬로 읽혀진다. 행 위치 블로브들의 나머지는 스킵되고, 그 결과 만일 질의의 선택성이 고려하는 선택 열보다 낮으면(low) 데이터 읽기는 상당히 감소된다. 만일 술어부가 매치하지 않는다면(예를 들어, 열 c=5에 대해서), 술어부 매치 연산은 (특정의 비-매치된) 행 그룹을 위해 열 d에 대해서 스킵되고, 그 결과 데이터 읽기는 상당히 감소된다(열 c의 모든 행 위치 블로브들 읽기, 열 d를 위한 사전 읽기 및 열 d를 위한 행 위치 블로브들 읽기는 읽는 단계로부터 스킵될 것이다). c의 술어부 및 d의 술어부 모두와 매치하는 행 위치들의 교차점이 표시되고 저장된다. 이와 대조적으로, 현재 최신 기술 파일 포맷들은 (전술한 바와 같은 스킵핑없이) 열들 c 및 d의 전체 데이터를 읽는다.
[0089] 시나리오를 좀더 계속하면, 열 c=5의 술어부가 매치된/식별된 행 그룹들 내의 고유 값들과 매치될 때, 술어부 매치 연산은 그 다음 열 d의 고유 값들에 대하여 실행되고, 만일 술어부(즉, 열 d>10)가 하나 또는 그 이상의 고유 값들과 매치하면, 매치하는 고유 값들에 관련된 행 위치들은 병렬로 읽혀진다.
[0090] 실시 예들의 방식은 여러 시나리오들에서의 선택 단계 읽기 요건들에서 읽을 필요가 있는 데이터를 상당히 감소시킨다:
[0091] 1) 술어부는 일부 고유 값들에 매치하지 않음. 이런 경우에는. 선택 알고리즘이 술어부와 매치하지 않는 고유 값들에 대한 행 위치들을 읽는 것을 스킵하도록 구성된다;
[0092] 2) 열은 소트되고 높은 농도(high cardinality)를 가짐. 이 시나리오에서, 대규모 행 그룹들이 스킵될 수 있다; 그리고
[0093] 3) 선택 열의 농도는 낮고, 선택성도 낮음. 이 시나리오는 선택 동안 가장 적은 양의 데이터 읽기를 가져온다. 고유 값들의 사전은 낮은 농도 때문에 실제 열 데이터보다 훨씬 더 적다. 만일 술어부에 매치하는 값들이 매우 적다면, 대부분의 행 위치 블로브들은 읽혀질 것이고, 그 결과 상당한 데이터 감소를 가져오게 될 것이다. 행 위치 블로브들은 고유 값에 관련된 행 위치들의 가변-길이 세트를 말한다. 한 세트(또는 열)의 농도(cardinality)는 그 세트(또는 열)의 구별되는 또는 고유한 엘리먼트들의 수의 측정 값임을 유의해야 하다.
[0094] 테이블 2는 플래시-최적화된 선택 알고리즘(104)의 예를 도시한다.
[0095] 테이블 2: 플래시-최적화된 선택 알고리즘:
Figure 112016113626224-pct00004
Figure 112016113626224-pct00005
[0096] C. 플래시-최적화된 추정 알고리즘(Flash-Optimized Projection Algorithm)
[0097] 플래시-최적화된 추정 알고리즘(106)은 플래시질의파일(80)에서 최근에 구현됨에 따라 선택 알고리즘(104)보다 나중에 출현되었다. 플래시질의파일(80)에는 추정 단계 동안 읽혀야 할 필요가 있는 데이터(예를 들어, select avg (a), sum(b) from the table)를 먼저 선택 단계를 실행함으로써(where c = 5 and d > 10) 오직 관련 행 위치들로만 제한하는 최근 구현이 사용된다. 추정 알고리즘(106)은 선택 단계의 이전 연산들에서 결정된 술어부에 매치하는 행 위치 들의 최종 세트(예를 들어, c=5 및 d>10)인 경우 행들)를 수신한다. 만일 선택성(즉, 술어부에 매치하는 주어진 열 내의 행들의 수)이 구성 가능한 스레시홀드(the configurable threshold)보다 더 낮으면, 플래시질의파일(80)은 추정 열들 내 원하는 행 위치의 파일 오프셋을 계산/결정하고, 상기 오프셋에서 고유 값의 포인트 읽기를 한다. 그 다음, 플래시질의파일(80)은 응답을 질의에 돌려준다. 선택성 스레시홀드는 구성 가능하고 워크로드에 기초하여 변경될 수 있다. 한 예로서, 디폴트 선택성 스레시홀드 값은 1.5%가 될 수 있다. 1.5%의 이 디폴트 선택성 스레시홀드는 모든 술어부들에 매칭하는 행 위치들의 수가 1.5%보다 적을 경우, (플래시질의파일(80)에 의한) 포인트 읽기가 데이터를 읽기 위해 사용된다는 것을 의미한다. 1.5%보다 더 높은 질의 선택성을 위해서, 클러스터된 방법(a clustered approach)이 사용될 수 있다. 이 예에서, 추정 알고리즘은 선택 알고리즘에 의해서 (이전에) 결정된 행 위치들의 세트에서 발생하는 열 a의 값들의 평균과 열 b의 값들의 합계를 돌려주도록 구성된다. 만일 선택성이 구성 가능한 스레시홀드와 같거나 그리고/또는 더 크다면, 플래시질의파일(80) 행 위치들을 묶어서(즉, 합쳐서) 한 파일 시스템 콜(one file system call) 내 행 위치들의 구성 가능한 수의 값들을 읽는다. 그 다음, 플래시질의파일(80)은 질의에 대한 응답을 돌려준다. 이 기술은 만일 질의의 선택성이 낮다면, 즉, 행 위치들의 아주 적은 수가 술어부에 매치한다면, 데이터 읽기를 상당하게 감소시킨다. 이와 대조적으로, 최신 기술의 파일 포맷 스캔 오퍼레이터들은 열들 a, b 앞줄의(upfront) 전체 데이터를 읽는다(그러나 플래시질의파일(80)에서는 그렇지 않다). 만일 선택성이, 예로서, 0.01%라면, 최신 기술의 방법은 0.99% 열의 데이터의 불필요한 읽기를 수행하게 된다. 플래시와 같은 임의로 액세스 가능한 저장 매체들은 성능에 손상을 가져옴이 없이 그러한 타켓된 임의 읽기들(such targeted random reads)을 가능하게 하는 데 핵심 역할(a key enabler)을 한다.
[0098] 테이블 3은 플래시-최적화된 추정 알고리즘(106)의 예를 도시한다.
[0099] 테이블 3: 플래시-최적화된 추정 알고리즘
Figure 112016113626224-pct00006
Figure 112016113626224-pct00007
[0100] D. 행 그룹 사이즈 결정
[0101] 최신 기술 파일 포맷들과 달리, 플래시질의파일(80)은, 더 나은 성능을 얻기 위해 더 많이 알려진 행 그룹 사이즈 결정(a more informed row group size determination)을 하기 위해, 정렬 순서(sort order)와 같은 열 특성들을 계산에 넣도록(factor in) 구성된다. 예를 들어, 개시된 실시 예들에서, 만일 열이 높은 농도(cardinality)를 갖고 있고 소트되지 않았다면, 더 큰 행 그룹 사이즈를 갖는 것이 실시 예들에서 선택 알고리즘(104)(스캔 알고리즘)을 더 빠르게 한다.
[0102] 한편, 만일 열이 소트되고, 높은 농도를 갖고 있다면, 적은 행 그룹 사이즈는 많은 행 그룹 스킵들을 초래하므로 훨씬 더 나은 결과를 가져온다. 따라서, 플래시질의파일(80)은 그러한 경우에서와 같이 적은 행 그룹 사이즈를 갖도록 FlashQueryFile 파일(304)를 구성한다. 예를 들어, 큰 행 그룹 사이즈는 수백만 개의 행들(예들 들어, 천만 개)을 포함할 수 있고, 적은 행 그룹 사이즈는 오직 수천 개(예를 들어, 50,000)의 행들을 포함할 수 있다.
[0103] E. 고성능 코딩(High Performance Coding)
[0104] Hadoop와 같은 빅 데이터 생태계를 위한 언어로 현재 선택된, Java는 고 성능 컴퓨팅을 위해, 고유하게, 최적화되어 있지 않다. 본 발명의 실험자는 여러 번 변경을 하면서 API들을 조심스럽게 선택했는데, 이는 플래시로부터 최대 성능을 개발하는 데 심각한 고유의 오버헤드(significant inherent overhead)를 갖지 않기 때문이다. API들의 대부분은, 특히 파일 시스템 API들은 하드 디스크들에 관하여 설계되어 있다. 예를 들어, 버퍼된 입력 스트림(Buffered Input Stream)은 필요한 것보다 더 많은 데이터를 Java 버퍼에 불필요하게 읽어 들이므로 이것은 4 바이트의 적은 데이터 또는 4KB(킬로바이트)의 데이터조차 읽기에는 최선의 선택은 아니다. 만일 IO가 다른 블록들에 대해서 임의로 발생한다면 많은 락 첵킹(a lot of lock checking)을 수행하고 스레드-안전(thred-safeness)를 위해 설계된 파일 시스템 API를 사용하는 것은 또한 필요치 않다. 콜(the call) 내에 명시된 오프셋을 갖는 단순 파일 채널(a simple file channel)을 사용하면 최선의 결과를 얻을 수 있다. 직접 IO를 허용하는 API들이 간접 IO보다 더 나은 결과를 가져올 수 있다. 클래스들(classes)의 Java 직렬변환 및 직병렬 변환(serialization and deserialization)에는 시간이 매우 많이 들고 실제 클래스 사이즈보다 스토리지 상에서 훨씬 더 많은 공간을 소비한다. 본 발명의 실험자는, 사전(dictionary), 룩업(lookup), 행 위치 블로브들(row position blobs) 등과 같은, 필요한 데이터 구조의 빠르고 공간-효율적인 표시와 하부 스토리지에 대한 데이터 구조들의 읽기 및 쓰기 메커니즘들(read and write mechanisms)을 작성하였다(coded). C와 같은 언어들은 데이터 구조들의 효율적인 표시를 지원하고 직렬 변환/직병렬 변환의 비용이 비싸지는 않다. 따라서, 데이터 구조들은 코드의 C 버전의 구조체(structs)로서 표시될 수 있다.
[0105] F. 하이브리드 및 계층화된 배치(Hybrid and Tiered Layout)
[0106] 플래시는 하드 디스크 드라이브보다 더 비싸고 솔루션을 위한 최선의 성능/$ 값을 가져오는 방식으로 현명하게 사용될 필요가 있는 제한된 용량을 가지고 있다. 한편 플래시는 디스크들보다 40-1000X 더 높은 임의의 IOP(IO 프로세서) 성능을 갖지만, 순차 대역폭은 디스크들보다 겨우 2-7X 더 높다. 플래시를 사용하는 단순한 방법은 인기 있는(popular) 열들을 모두 플래시에 배치하는 것이다. 그러나, 인기 있는 열들이 모두 플래시에 적합한 특성들을 갖는 것은 아니다. 예를 들어, 성(gender)을 추적하는 열과 같이 한 열이 매우 낮은 농도를 갖는 경우를 생각해보자(즉, 남성 또는 여성, 따라서 이 경우는 농도가 2(남성, 여성)이다). 그러한 열에 대한 데이터의 관심은 아주 높기 때문에(즉, 높은 인기도 때문에), 데이터를 임의로 읽기 위해 다수의 콜들을 내보내는 대신 하나의 콜로 데이터를 단순하게 순차적으로 스캔하는 것이 훨씬 더 좋다. 따라서, 그러한 열은, 그것의 인기도에도 불구하고, 플래시질의파일(80)에 의해서 계산되고 결정되는 플래시에 대한 최선의 성능/$ 값을 가져오지는 못한다. 한편, 높은 농도를 갖는 열은 상대적으로 적은 수의(less) 데이터가 값마다 읽혀질 필요가 있으므로 플래시에 더 적합하다. 플래시질의파일(80)은 플래시 내에 배치될 데이터에 관해 매우 선택적이며 특정 데이터베이스 열을 위한 바른 계층(the right tier)(즉, 플래시 메모리(75) 또는 하드 디스크 드라이브(28) 중 어느 하나)을 결정하기 위해 열 특성들(이는 본 출원의 범위를 벗어난다)에 기초한 최적화 알고리즘을 사용한다. 계층으로된 세팅(a tiered setting)에서, 선택 열의 고유 값들을 포함하는 사전은 플래시 내에 배치되고, 배치의 나머지는 하드 디스크 드라이브에 배치된다. 추정 열들(projection coulmns)의 경우에, 룩업 구조는 또한 플래시에 배치된다.
[0107] 플래시질의파일(80)에 의해서 실행되는 바와 같이, 도 5는 FlashQueryFile 파일 블록의 배치를 도시하고, 동일(단일의) 데이터 노드/클러스터(10) 상의 파일 시스템 블록들에 걸친 열들의 분할(split)을 도시한다. 도 5는, 행들 및 열들이 (행 그룹(RG1) 내지 행 그룹(RGN)과 같은) 행 그룹들로 그룹화되도록 하는, 행들 및 열들의 원래 관계를 도시하는 테이블(502)이고, 이는 한 실시 예에 따라 결정되는 바와 같이 플래시 메모리(75) 및/또는 하드 디스크 드라이브 메모리(34)에 저장하기 위해 플래시질의파일(80)에 의해서 흡수된다(ingested). 이 행 그룹들은 논의된 바와 같이 이용된다.
[0108] IV. 평가(Evaluation)
[0109] 본 발명의 실험자들은 40의 스케일 팩터(a scale factor)를 선정해서 40GB의 TPCH 데이터세트를 생성하였다. 라인 아이텀 테이블(the line item table)은 가변 길이들 및 특성들의 240+백만 행들과 16 열들을 가졌다. 본 발명의 실험자들은 플래시질의파일(80) serde의 성능을 ORCFile serde와 비교하였다. 두 개의 시나리오 모두에서 데이터를 플래시에 배치하였는데, 이는 최적화된 ORCFile 포맷을 플래시에 배치하고 HDD 최적화된 ORCFile 선택 및 추정 오퍼레이터들을 사용하여 HDD 최적화된 ORCFile 포맷을 액세스하는 것과 비교하여 플래시질의파일(80)의 새로운 플래시 최적화된 파일 포맷, 데이터 배치, 선택 알고리즘, 및 추정 알고리즘의 유효성을 강조하기 위해서이다. 이 시나리오는 데이터가 인기 있는 것으로 가정하여 질의를 수행하는 애플리케이션을 저장 매체에 통보하지 않고 더 느린 HDD 계층으로부터 더 빠른 저장 매체 계층으로 이동되는 경우들에서 매우 전형적인 것이다. 그 결과, 데이터의 새로운 위치를 의식하지 못하는, 애플리케이션은 여전히 HDD-최적화된 코드를 사용하여 데이터를 액세스한다. 여섯 쿼드-코어 Intel Xeon CPU E5645@ 2.40GHz 및 96GB RAM을 갖는 서버에 관해서 평가가 수행되었다. 도시된(도 7에 도시된) 결과들은 TPCH 질의 1에 관한 것이며 다수의 술어부 값들은 질의 선택성의 범위를 허용하기 위해 사용되었다.
[0110] A. 성능 및 데이터 분석(Performance and Data Analysis)
[0111] 도 6은 다른 알고리즘과 비교한 플래시질의파일(80)을 위한 정규화된 데이터 읽기를 보여주는 그래프(600)을 도시한다.
[0112] 그래프(700)에서, 도 7은 실시 예들에 따라 플래시질의파일(80)에서 질의 1의 속도 증가의 예를 보여준다. 도 7은 플래시질의파일(80)에서 TPCH 질의 1의 속도 증가를 ORCFile에 대해서 보여준다. 도 7은 플래시질의파일 (80)에서 질의 1의 속도 증가를 보여준다. 질의는 하나의 선택 열 l_shipdate 와 여섯의 추정 열들을 갖는다. 이 결과들의 선택성을 보여주기 위해, 질의 1의 선택성은 선택 열 l_shipdate에 대한 술어부 값을 변경시킴으로써 <1%로부터 98%까지 변화되었다. 플래시질의파일(80)은 ORCFile보다 질의들을 훨씬 더 빠르게 처리하는데, 그 이유는 플래시질의파일(80)은 자신의 IO-효율적인 알고리즘들 및 배치들로 인하여 훨씬 더 적은 데이터를 읽고 플래시의 높은 내부 병렬 처리 및 빠른 임의의 액세스를 이용하기 때문이다.
[0113] 도 8은 플래시질의파일(80)에서 TPCH 질의 1의 선택 및 추정 단계에서의 데이터 감소를 도시한다. ORCFile은 행 그룹들을 걸러내기 위해 배치된 최소 및 최대 요약 정보에 기초한 조잡한 메커니즘(a coarse-grained mechanism)을 가지고 있을 뿐이다. ORCFile은 HDD를 위해 설계되었지만 플래시질의파일의 포맷과 액세스 방법들은 플래시에 대해 최적화되어 있기 때문에 플래시질의파일은 ORCFile이 또한 플래시 메모리 상에 배치되는 시나리오에서조차 23X(배)까지 속도를 높일 수 있다. X-축은 선택성을 도시하고 그리고 y-축은 플래시질의파일(80)이 ORCFile보다 더 빠른 타임들에서 속도 증가의 크기를 보여준다. 속도 증가는 ORCFile의 질의 처리 시간을 플래시질의파일의 질의 처리 시간으로 나눔으로써 계산된다. 플래시질의파일(80)의 플래시-최적화된 파일 포맷(여기서 개시한)은 플래시(예를 들어, 플래시(75))로부터 실제 성능/$ 값(the true performance/$ value)을 산출하기 위해 중요하다. 새로운 포맷과 알고리즘들, 플래시의 고성능 임의의 액세스들의 이용, 그리고 RCFile과 비교하여 플래시질의파일의 더 높은 수준의 IO 병렬처리에 의해서 높은 속도 증가가 가능하게 되는데 이는 데이터 읽기 양의 감소 때문이다. HDD를 위해 최적화된 ORCFile과 같은 serde는 플래시 또는 RAM과 같은 더 빠르고, 임의로 액세스 가능한 매체들에 단순히 배치되었을 때 훨씬 적은 성능 이득을 산출한다.
[0114] 더 나아가, 도 8은 자신의 정교한 데이터 스킵핑(fine-grained data skipping)에 의해서 플래시질의파일(80)이 데이터에서 상당한 감소를 달성할 수 있음을 보여준다. ORCFile은 질의 1을 위해 선택 열 내의 전체 데이터를 읽게 된다. 선택 열 l_shipdate의 농도(cardinality)는 낮고, 선택성이 낮은 시나리오들에서, 대규모 행 위치 데이터는 스킵될 수 있고 따라서 읽히지 않는다. 추정 알고리즘은 추정 단계 동안 데이터 읽기의 추가적인 감소를 가져온다. 더 나아가서, 선택 최적화된 사전 기반의 배치는 더 공간-효율적인 데이터 인코딩을 가능하게 하며 이것이 선택성이 98%만큼 높은 시나리오에서 조차도 데이터 감소가 가능한 이유이다.
[0115] ORCFile은 행 그룹들을 걸러내기 위해 배치된 최소 및 최대 요약 정보에 기초한 조잡한 메커니즘(a coarse-grained mechanism)을 가지고 있을 뿐이다. ORCFile의 상기 메커니즘은 스킵할 행 그룹을 찾아내지 못해서 질의 1을 위해 선택 열 내의 전체 데이터를 읽어버린다. 한편, 플래시질의파일(80)은 내부-행-그룹 데이터 스킵핑(intra-row-group data skipping)을 수행하고 선택 열 l_shipdate에서 데이터의 81%를 스킵할 수 있다. l_shipdate의 농도는 낮다. 사전의 사이즈는 작고(small) 각각의 행 위치 블로브는 크다(large). 술어부에 매치하지 않는 행 위치 블로브들(the row position blobs)은 플래시질의파일(80)에 의해서 스킵되고, 그 결과 데이터의 19%만 읽혀진다. 더 나아가서, 사전 기반 배치(dictionary based layout)는 더 공간-효율적인 인코딩을 가능하게 하고 도 7에서 도시한 바와 같이 선택성이 98%만큼 높은 시나리오에서 조차 데이터 감소를 가능하게 한다. 플래시질의파일이 모든 술어부들에 매치하는 행 위치들의 최종 세트로부터만 데이터를 읽을 때뿐만 아니라 추정 단계 동안에도 데이터 감소는 일어난다. 데이터 감소는 추정 버퍼 사이즈(the projection buffer size)에 따라 달라지는데, 사이즈가 적을수록 데이터 감소는 더 많아진다. 그러나, 성능은 추정 버퍼의 사이즈가 너무 적으면 떨어지는데, 선택성이 <1%가 안될 때까지 떨어진다. 추정 알고리즘의 데이터 감소는 추정성(the projectivity)이 증가할 때 증가한다.
[0116] 도 9는 한 실시 예에 따라 데이터 세트 질의들의 플래시-최적화된 데이터 배치를 위한 (서브-컴포넌트들을 포함하는 플래시질의파일(80)에 의해서 실행되는) 방법을 도시하는 흐름도(900)이다. 도 1-8을 참조할 수 있다. 비록 속도에서 가장 뛰어난 개선이 플래시 메모리에서 달성될 수 있다 하더라도, 다양한 알고리즘들과 선택 및 추정 배치들이 플래시 메모리 및 HDD 메모리 모두를 위해 사용될 수 있음에 유의한다.
[0117] 블록 (905)에서, 플래시질의파일(80)은 선택 최적화된 배치(402)에 따라 플래시 메모리(75) 내 선택 열들을 (하나 또는 그 이상의 프로세서들(16)을 통해서) 저장하도록 구성되고, 선택 최적화된 배치(402)는 선택 열들에 대한 임의의 액세스들(및/또는 술어부 매칭 및 데이터 스킵핑)을 최적화하도록 구성된다.
[0118] 블록 (910)에서, 선택 최적화된 배치(402)는, 각각의 선택 열을 위해, 구성되는데, 주어진 선택 열 내에 고유 데이터 값들로만 채워진 선택 열 사전(403)을 저장함에 의해서 구성되며(예를 들어, 비록 고유 데이터 값들 중 일부가 원래 관계(401)에서 반복된다 하더라도 열 C1만 고유 데이터 값들(121, 130, 140, 150)을 선택 열 사전(403)에 저장한다), 상기 고유 데이터 값들은 선택 열 사전 (403) 내에 소트된 순서로 저장된다.
[0119] 블록(915)에서, 선택 최적화된 배치(402)는, 각각의 선택 열을 위해, 형성되는데, 주어진 선택 열에서 한번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 주어진 선택 열 내에 고유 데이터 값들이 존재하는 각각의 행 위치에 대응하는 행 위치 지정들(row position designations)(405)을 저장함에 의해서 형성된다. 예를 들어, 데이터 값(121)은 (원래 관계(40)에서) 행 위치들(r2, r3, r6) 내에 3번 발생하지만, 데이터 값(121)은 도 4b의 사전(403)에서 오직 한 번만 고유하게 저장된다.
[0120] 선택 최적화된 배치는, 주어진 선택 열을 위해, 형성되는데, 행 위치들 지정들 내에 동일 고유 데이터 값을 갖는 개별 행 위치들에 대해 단일의 오프셋을 저장함에 의해서 형성된다. 예를 들어, 도 4d는 오프셋 구조(450) (예를 들어, 플래시 메모리(75) 내의 저장 위치)를 갖고, 오프셋 구조(450)은 모두 동일 고유 데이터 값(121)을 갖는 개별 행 위치들(r2, r3, r6, r9, r10, r11, r13)(행 위치 지정들/목록(405))에 대응하는 오프셋 O1을 저장한다. 도 4d의 열 C1을 위해, 고유 데이터 값(121)은 사전(403) 내에 오직 한 번만 저장된다.
[0121] 동일 고유 데이터 값을 갖는 개별 행 위치들은 행 위치들 지정들(405) 내의 동일 메모리 위치에 저장된다. 예를 들어, 개별 행 위치들(r2, r3, r6, r9, r10, r11, r13)은 도 4d의 행 위치 지정들/목록(405)에서 단일의/동일 메모리 위치 내에 저장된다.
[0122] 개별 행 위치들 각각은 주어진 선택 열 내의 동일 고유 데이터 값에 대응하는데, 동일 고유 데이터 값을 갖지 않는 다른 개별 행 위치들을 읽을 필요 없이 동일 고유 데이터 값에 대한 매치가 개별 행 위치들의 각각이 동일 메모리 위치로부터 읽히도록 대응한다. 도 4d에서, 오퍼레이션 2는 고유 데이터 값(130 및 150)을 술어부 c1=130 및 c1=150에 대해 각각 매치한다. 오퍼레이션 3은 대응 행 위치 블로브들을 읽어내는데, 이들은 고유 데이터 값(130)을 매칭하기 위한 개별 행 위치들(r1, r4)와 고유 데이터 값(150)을 매칭하기 위한 개별 행 위치들(r5, r12)를 포함하는 메모리 위치이다.
[0123] 플래시질의파일(80)은 추정 최적화된 배치(404)에 따라 플래시 메모리(75)에 추정 열들을 저장하도록 구성되고, 추정 최적화된 배치(404)는 추정 열들에 대한 임의의 액세스들을 최적화하도록 구성된다. 추정 최적화된 배치(404)는, 각각의 추정 열을 위해, 형성되는데, 주어진 추정 열 내의 고유 데이터 값들만으로 채워진 추정 열 사전(408)을 저장함에 의해서 형성되고, 고유 데이터 값은 추정 열 사전(408)에 소트된 순서로 저장된다. 예를 들어, 추정 열 사전(408)은 비록 도 4a에서의 원래 관계(401)가 이들 데이터 값들의 일부를 반복하더라도 도 4c에서의 고유 데이터 값들(600, 602, 603, 670, 680)을 오직 한 번만 저장한다. 추정 최적화된 배치(404)는, 각각의 추정 열을 위해, 룩업 구조(406)을 저장하는데, 주어진 추정 열에서 한 번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이 저장하고, 룩업 구조(406)은 (고유 데이터 값들의 각각에 대한 행 위치 당 사이즈와 함께) 주어진 추정 열 내의 고유 데이터 값들의 각각에 대해 행 위치 당 인덱스(다른 경우에는 행 위치 당 오프셋)를 포함한다.
[0124] 추정 최적화된 배치는, 주어진 추정 열을 위해, 형성되는데, 주어진 추정 내의 동일 고유 데이터 값을 갖는 개별 행 위치들에 대한 인덱스들(다른 경우에 동일 사이즈 및 동일 오프셋)을 룩업 구조 내에 저장함으로써 형성되고, 그렇게 하여 개별 행 위치들은 주어진 추정 열 내의 모든 행 위치들을 읽을 필요 없이 읽혀지게 된다. 도 4c의 행 위치들(r4 및 r6)을 위한 룩업 구조(406)에서, 오프셋들(offr4 및 offr6)은 그들의 대응 고유 데이터 값(670)에 대해 동일하다. 마찬가지로, (도 4c의 행 위치들 r4 및 r6을 위한 룩업 구조(406)에서) 데이터 사이즈(킬로바이트)(sizer4 및 sizer6)은 그들의 동일 대응 고유 데이터 값(670)에 대해 동일하다.
[0125] 추정 최적화된 배치는, 주어진 추정 열을 위해, 형성되는데, 주어진 추정 내의 다른 동일 고유 데이터 값을 갖는 기타 개별 행 위치들에 대한 다른 동일 사이즈 및 다른 동일 오프셋을 룩업 구조 내에 저장함으로써 형성된다. 예를 들어, 도 4c의 행 위치들(r5 및 r7)을 위한 룩업 구조(406)에서, 이들 행 위치들은 열 c3에서 그들의 동일 대응 고유 데이터 값(680)을 위해 동일 오프셋들(값)(offr5 및 offr7)과 동일 사이즈들(sizer5 및 sizer7)을 갖는다.
[0126] 플래시질의파일(80)은 데이터 세트에 대하여 실행될 질의를 수신하도록 구성되고, 질의는 추정 부분과 선택 부분을 포함한다. 플래시질의파일(80)은 질의의 추정 부분(이를 또한 여기서 나중 구현(late materialization)이라 함)을 실행하기 전에 선택 부분을 실행하도록 구성된다. 선택 부분은 선택 부분 내의 규칙들에 따라 매치될 술어부를 포함한다. 추정 부분은 데이터세트로부터 고유 데이터 값들을 검색하기 위한 요건을 포함한다.
[0127] 선택 부분을 (플래시질의파일(80)에 의해서) 실행하는 단계는 술어부의 범위를 벗어나는 통계 정보를 갖는 행 그룹들을 스킵하기 위해서 주어진 선택 열을 위한 행 그룹들의 통계 정보(즉, 도 3의 메타데이터 헤더들)를 읽는 단계를 포함하고, 상기 주어진 선택 열의 행 그룹들의 통계 정보를 읽는 단계는 상기 행 그룹들 내의 고유 데이터 값들을 상기 읽는 단계의 시기에 스스로 읽을 필요 없이 수행된다. 행 그룹들은(도 5에서 도시한 바와 같이) 함께 그룹화되어 있는 주어진 선택 열 내의 행들이다. 스킵되지 않은 주어진 선택 열의 나머지 행 그룹들에 대해서, 플래시질의파일 (80)은 주어진 선택 열의 나머지 행 그룹들(스킵되지 않은 행 그룹들)을 위해 선택 열 사전(403)에서 고유 데이터 값들을 각각의 스레드가 개별 행 그룹을 처리하는 멀티-스레드된 방식으로(in a multi-threaded fashion) 검색하도록 구성된다. 스레드는 프로세서에 의해서 실행되는 프로그램 명령들의 시퀀스(a sequence)이다. 플래시질의파일(80)은 매칭 고유 값들을 찾기 위해서 나머지 행 그룹들에 대하여 선택 열 사전(403) 내 고유 데이터 값들에 대한 술어부의 술어부 매칭을 실행하도록 구성된다. 플래시질의파일(80)은 스킵된 행 그룹 위치들을 검색하는(또는 읽는) 단계 없이 주어진 선택 열 내의 매칭하는 고유 값들에 대한 행 위치들만 검색한다(retrieve).
[0128] 질의의 추정 부분을 실행하는 것에는 매칭 고유 값들을 검색하기 위해서 매칭 고유 값들을 위한 행 위치들의 각각에 관한 오프셋들(예를 들어, 룩업 구조(406)에서)을 검색하는 것이 포함된다. 응답을 질의에 돌려주기 위해서 행 위치들의 매칭 고유 값들에 관하여 질의의 추정 부분 내의 (매칭 고유 값들의 행 위치들을 단지 검색(retrieve)할 수 있는) 요건이 실행된다. 추정 부분은 데이터 세트로부터 데이터 값들을 검색하기 위한 요건을 포함한다. 질의의 추정 부분/단계는 플래시질의파일(80)에게 매칭 고유 값들로 무엇을 해야 하는지를 알려준다.
[0129] 더 나아가서 플레시 메모리에 관해서 설명하면, 플래시 메모리는 당업자가 이해하는 바와 같이 전기적으로 지우고 재프로그램될 수 있는 전자적 비-휘발성 컴퓨터 저장 매체(an electronic non-volatile computer storage medium)이다. NAND와 NOR 로직 게이트들의 이름을 딴, 두 가지 메인 유형의 플래시 메모리가 있다. 개별 플래시 메모리 셀들의 내부 특성들은 이들 대응 게이트들과 유사한 특성들을 보여준다. NAND 유형의 플래시 메모리는 전체 디바이스보다 일반적으로 훨씬 더 적은 블록들(또는 페이지들)에서 기록되고 읽혀질 수 있다. NOR 유형의 플래시는 단일 머신 워드(a single machine word)(바이트)가 독립적으로 (지워진 위치에) 쓰여지거나 또는 읽혀지는 것이 가능하다. 플래시 메모리는 플로팅-게이트 트랜지스터들로부터 만들어진 메모리 셀들의 어레이 내에 정보를 저장한다. 전동적인 단일-수준 셀(SLC) 디바이스들에서, 각각의 셀은 오직 한 비트의 정보만을 저장한다. 트리플-수준 셀(TLC) 디바이스들을 포함하는, 멀티-수준 셀(MLC) 디바이스들로 알려진, 새로운 플래시 메모리는 셀 당 한 비트 이상을 저장할 수 있는데, 이는 셀들의 플로팅 게이트들에 인가할 전하의 다수 수준들 사이에서 선택하게 함으로써 그렇게 할 수 있다.
[0130] 더 나아가서 하드 디스크 드라이브들에 관해서 설명하면, 하드 디스크 드라이브(HDD)는 자기 재료로 코팅된 빠르게 회전하는 디스크들(플래터들)을 사용하는 디지털 정보를 저장하고 검색하기 위해 사용되는 데이터 저장 디바이스이다. HDD는 전원을 껐을 때도 데이터를 유지한다. HDD는 가동 액추에이터 암 상에 배열된 자기 헤드들을 갖는 하나 또는 그 이상의 단단하며("hard") 빠르게 회전하는 디스크들(플래터들)로 구성되어 디스크들 표면에서 데이터를 읽거나 디스크들 표면에 데이터를 기록한다.
[0131] 본 발명의 다양한 실시 예들에 관한 기술들은 예시의 목적으로 제공된 것이지, 이것들이 전부라거나 또는 개시된 실시 예들로 한정된다는 것을 의도하는 것은 아니다. 상기 기술된 실시 예들의 범위 및 정신을 벗어남이 없이 많은 수정들 및 변경들이 당업자들에게 명백하다. 여기서 사용된 용어는 상기 실시 예들의 원리들, 실제적 응용 또는 시장에서 발견되는 기술들에 대한 기술적 개선을 가장 잘 설명하도록, 또는 여기 기술된 상기 실시 예들을 다른 당업자들이 이해할 수 있도록 선택된 것이다.
[0132] 본 발명은 시스템, 방법, 및/또는 컴퓨터 프로그램 제품일 수 있다. 컴퓨터 프로그램 제품은 컴퓨터 읽기 가능 저장 매체를 포함할 수 있으며 이 매체 상에 프로세서가 본 발명의 특징들을 수행하도록 하기 위한 컴퓨터 읽기 가능 프로그램 명령들을 갖는다.
[0133] 상기 컴퓨터 읽기 가능 저장 매체는 명령 실행 디바이스에 의해 사용될 명령들을 유지 및 저장할 수 있는 유형의(tangible) 디바이스일 수 있다. 상기 컴퓨터 읽기 가능 저장 매체는, 예를 들면, 전자 저장 디바이스, 자기 저장 디바이스, 광 저장 디바이스, 전자기 저장 디바이스, 반도체 저장 디바이스, 또는 전술한 것들의 모든 적절한 조합일 수 있으며, 그러나 이에 한정되지는 않는다. 컴퓨터 읽기 가능 저장 매체의 더 구체적인 예들의 비포괄적인 목록에는 다음이 포함될 수 있다: 휴대용 컴퓨터 디스켓, 하드 디스크, 랜덤 액세스 메모리(RAM), 읽기-전용 메모리(ROM), 소거 및 프로그램가능 읽기-전용 메모리(EPROM 또는 플래시 메모리), 정적 랜덤 액세스 메모리(SRAM), 휴대용 컴팩트 디스크 읽기-전용 메모리(CD-ROM), 디지털 다용도 디스크(DVD), 메모리 스틱, 플로피 디스크, 천공-카드들 또는 명령들이 기록된 홈에 있는 융기된 구조들 같이 기계적으로 인코딩된 디바이스, 및 전술한 것들의 모든 적절한 조합. 여기에서 사용될 때, 컴퓨터 읽기 가능 저장 매체는 무선 전파들이나 다른 자유롭게 전파되는 전자기파들, 도파관이나 기타 전송 매체(예를 들어, 광섬유 케이블을 통해 전달되는 광 펄스들)를 통해 전파되는 전자기파들, 또는 선(wire)을 통해 전송되는 전기 신호들 같이 그 자체로 일시적인(transitory) 신호들로 해석되지는 않는다.
[0134] 여기에 기술되는 컴퓨터 읽기 가능 명령들은 컴퓨터 읽기 가능 저장 매체로부터 각각 컴퓨팅/처리 디바이스들로 다운로드될 수 있거나 또는, 예를 들어, 인터넷, 근거리 통신망, 광역 통신망 및/또는 무선 네트워크 등의 통신망(네트워크)을 통해 외부 컴퓨터 또는 외부 저장 디바이스로 다운로드될 수 있다. 상기 통신망(네트워크)은 구리 전송 케이블, 광학 전송 섬유, 무선 전송, 라우터, 방화벽, 스위치, 게이트웨이 컴퓨터 및/또는 엣지 서버를 포함할 수 있다. 각 컴퓨팅/처리 디바이스 내 네트워크 어댑터 카드 또는 네트워크 인터페이스는 상기 통신망(네트워크)으로부터 컴퓨터 읽기 가능 프로그램 명령들을 수신하고 그 컴퓨터 읽기 가능 프로그램 명령들을 각각의 컴퓨팅/처리 디바이스 내의 컴퓨터 읽기 가능 저장 매체에 저장하기 위해 전송한다.
[00135] 본 발명의 연산들을 실행하기 위한 컴퓨터 읽기 가능 프로그램 명령들은 Smalltalk, C++ 또는 그와 유사 언어 등의 객체 지향 프로그래밍 언어와 "C" 프로그래밍 언어 또는 그와 유사한 언어 등의 종래의 절차적 프로그래밍 언어들을 포함하여, 하나 또는 그 이상의 프로그래밍 언어들을 조합하여 작성된(written) 어셈블러 명령들, 명령-세트-아키텍처(ISA) 명령들, 머신 명령들, 머신 종속 명령들, 마이크로코드, 펌웨어 명령들, 상태-셋팅 데이터, 또는 소스 코드나 목적 코드일 수 있다. 상기 컴퓨터 읽기 가능 프로그램 명령들은 전적으로 사용자의 컴퓨터상에서, 부분적으로 사용자의 컴퓨터상에서, 독립형(stand-alone) 소프트웨어 패키지로서, 부분적으로 사용자의 컴퓨터상에서 그리고 부분적으로 원격 컴퓨터상에서 또는 전적으로 원격 컴퓨터나 서버상에서 실행될 수 있다. 위에서 마지막의 경우에, 원격 컴퓨터는 근거리 통신망(LAN) 또는 광역 통신망(WAN)을 포함한 모든 유형의 네트워크를 통해서 사용자의 컴퓨터에 접속될 수 있고, 또는 이 접속은 (예를 들어, 인터넷 서비스 제공자를 이용한 인터넷을 통해서) 외부 컴퓨터에 이루어질 수도 있다. 일부 바람직한 실시 예들에서, 예를 들어 프로그램 가능 로직 회로, 필드-프로그램 가능 게이트 어레이들(FPGA), 또는 프로그램 가능 로직 어레이들(PLA)을 포함한 전자 회로는 본 발명의 특징들을 수행하기 위해 전자 회로를 맞춤화하도록 상기 컴퓨터 읽기 가능 프로그램 명령들의 상태 정보를 활용하여 상기 컴퓨터 읽기 가능 프로그램 명령들을 실행할 수 있다.
[0136] 여기에서는 본 발명의 실시 예들에 따른 방법들, 장치들(시스템들), 및 컴퓨터 프로그램 제품들의 순서 예시도들 및/또는 블록도들을 참조하여 본 발명의 특징들을 기술한다. 순서 예시도들 및/또는 블록도들의 각각의 블록과 순서 예시도들 및/또는 블록도들 내 블록들의 조합들은 컴퓨터 읽기 가능 프로그램 명령들에 의해 구현될 수 있다는 것을 이해할 수 있을 것이다.
[0137] 이 컴퓨터 읽기 가능 프로그램 명령들은 범용 컴퓨터, 특수목적용 컴퓨터, 또는 기타 프로그램가능 데이터 처리 장치의 프로세서에 제공되어 머신(machine)을 생성하고, 그렇게 하여 그 명령들이 상기 컴퓨터 또는 기타 프로그램가능 데이터 처리 장치의 프로세서를 통해서 실행되어, 상기 순서도 및/또는 블록도의 블록 또는 블록들에 명시된 기능들/동작들을 구현하기 위한 수단을 생성할 수 있다. 이 컴퓨터 읽기 가능 프로그램 명령들은 또한 컴퓨터 읽기 가능 스토리지 매체에 저장될 수 있으며, 컴퓨터, 프로그램가능 데이터 처리 장치 및/또는 기타 디바이스들에 지시하여 명령들이 저장된 상기 컴퓨터 읽기 가능 스토리지 매체가 상기 순서도 및/또는 블록도의 블록 또는 블록들에 명시된 기능/동작의 특징들을 구현하는 명령들을 포함하는 제조품(an article of manufacture)을 포함하도록 특정한 방식으로 기능하게 할 수 있다.
[0138] 상기 컴퓨터 읽기 가능 프로그램 명령들은 또한 컴퓨터, 기타 프로그램가능 데이터 처리 장치, 또는 다른 디바이스에 로드되어, 상기 컴퓨터, 기타 프로그램가능 장치 또는 다른 디바이스에서 일련의 동작 단계들이 수행되게 하여 컴퓨터 구현 프로세스를 생성하며, 그렇게 하여 상기 컴퓨터, 기타 프로그램가능 장치, 또는 다른 장치 상에서 실행되는 명령들이 순서도 및/또는 블록도의 블록 또는 블록들에 명시된 기능들/동작들을 구현할 수 있다.
[0139] 도면들 내 순서도 및 블록도들은 본 발명의 여러 실시 예들에 따른 시스템들, 방법들 및 컴퓨터 프로그램 제품들의 가능한 구현들의 아키텍처, 기능(functionality), 및 연산(operation)을 예시한다. 이와 관련하여, 상기 순서도 또는 블록도들 내 각 블록은 상기 명시된 논리적 기능(들)을 구현하기 위한 하나 또는 그 이상의 실행 가능한 명령들을 포함한 모듈, 세그먼트 또는 명령들의 일부분을 나타낼 수 있다. 일부 다른 구현들에서, 상기 블록에 언급되는 기능들은 도면들에 언급된 순서와 다르게 일어날 수도 있다. 예를 들면, 연속으로 도시된 두 개의 블록들은 실제로는 사실상 동시에 실행될 수도 있고, 또는 이 두 블록들은 때때로 관련된 기능에 따라서는 역순으로 실행될 수도 있다. 블록도들 및/또는 순서 예시도의 각 블록, 및 블록도들 및/또는 순서 예시도 내 블록들의 조합들은 특수목적용 하드웨어 및 컴퓨터 명령들의 명시된 기능들 또는 동작들, 또는 이들의 조합들을 수행하는 특수목적용 하드웨어-기반 시스템들에 의해 구현될 수 있다는 것에 또한 유의한다.

Claims (20)

  1. 질의들을 위한 데이터세트(a dataset for queries)의 플래시-최적화된 데이터 배치(flash-optimized data layout)를 위한 방법에 있어서, 상기 방법은:
    술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성되는, 선택 최적화된 배치(a selection optimized layout)에 따라 플래시 메모리 내에 선택 열들(selection columns)을, 프로세서에 의해서, 저장하는 단계(storing) ― 상기 선택 최적화된 배치는, 각각의 선택 열에 대해서, 선택 열 사전 내에 소트된 순서로(in sorted order) 저장되는 고유 데이터 값들(unique data values)로 채워진 선택 열 사전(a selection column dictionary)을 주어진 선택 열 내에 저장하는 단계, 및, 상기 주어진 선택 열에서 한 번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 고유 데이터 값들이 상기 주어진 선택 열 내에 존재하는 각각의 행 위치에 대응하는 행 위치 지정들(row position designations)을 저장하는 단계에 의해서 형성됨 ―;
    하이브리드 추정 및 선택 최적화된 배치(a hybrid projection and selection optimized layout)에 따라 상기 플래시 메모리 내에 하이브리드 추정 및 선택 열들(hybrid projection and selection columns)을 저장하는 단계(storing) ― 각각의 하이브리드 추정 및 선택 열은 주어진 하이브리드 추정 및 선택 열 내의 중복적인 데이터 값들(duplicative data values)이 연속 행들에(in consecutive rows) 배열되도록 소트된 순서를 가지고 있고, 상기 하이브리드 추정 및 선택 최적화된 배치는: 각각의 하이브리드 추정 및 선택 열에 대해서, 그리고 상기 주어진 하이브리드 추정 및 선택 열 내의 상기 중복적인 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 주어진 하이브리드 추정 및 선택 열 내의 각각의 중복적인 데이터 값의 1(one)로 채워진 하이브리드 추정 및 선택 열 사전을 저장하는 단계 ― 상기 각각의 중복적인 데이터 값들의 1(one)들은 상기 하이브리드 추정 및 선택 열 사전 내에 소트된 순서로 저장됨 ―, 룩업 및 행 위치 지정 구조를 저장하는 단계 ― 상기 룩업 및 행 위치 지정 구조는, 상기 하이브리드 추정 및 선택 열 사전 내에 저장된 각각의 데이터 값에 대해서, 상기 주어진 하이브리드 추정 및 선택 열 내에 주어진 데이터 값이 존재하는 제1 행 위치 및 최종 행 위치에 대응하는 한 쌍의 행 위치 지정들을 포함하고, 행 위치 지정들의 각 쌍에 대해서, 상기 하이브리드 추정 및 선택 열 사전 내의 대응 데이터 값에 대한 포인터(a pointer)를 포함함 ―, 및 복수의 오프셋들을 저장하는 단계 ― 각각의 오프셋은 상기 하이브리드 추정 및 선택 열 사전 내의 데이터 값에 대응하고, 상기 데이터 값에 대응하는 행 위치 지정들의 주어진 쌍의 제1 행 위치(a first row position)의 위치(location)를 표시하는 기능을 수행함 ― 에 의해서 형성됨 ―;
    상기 데이터세트에 대하여 실행될 질의들을 수신하는 단계(receiving) ― 상기 질의는 추정 부분(a projection part)과 선택 부분(a selection part)을 포함하고, 상기 선택 부분은 상기 선택 부분 내의 규칙들(rules)에 따라 제1 하이브리드 추정 및 선택 열 내의 데이터 값들에 매칭될 술어부를 포함하며 상기 추정 부분은 상기 질의에 응답하는데 사용하기 위해 제2 하이브리드 추정 및 선택 열로부터 특정 데이터를 검색하기 위한 요건을 포함함 ―;
    상기 선택 부분을 실행하는 단계(executing) ― 상기 선택 부분을 실행하는 단계는 상기 제1 하이브리드 추정 및 선택열을 위한 제1 하이브리드 추정 및 선택열 사전 내의 제1 데이터 값에 상기 술어부를 매칭하는 단계, 상기 제1 데이터 값에 대응하는 제1 오프셋을 상기 제1 하이브리드 추정 및 선택열 사전 내의 데이터 값들에 대한 제1 복수의 오프셋들 중에서 식별하는 단계, 및 상기 제1 오프셋을 사용하여 그리고 상기 제1 하이브리드 추정 및 선택열을 위한 제1 룩업 및 행 위치 지정 구조 내에서, 상기 제1 하이브리드 추정 및 선택열 내에 상기 제1 데이터 값이 존재하는 제1 행 위치 및 최종 행 위치에 대응하는 행 위치 지정들의 제1쌍을 찾는 단계(locating)에 의해서 실행함 ―;
    상기 추정 부분을 실행하는 단계(executing) ― 상기 추정 부분을 실행하는 단계는: 상기 행 위치 지정들의 제1 쌍을 사용하여, 상기 제2 하이브리드 추정 및 선택열을 위한 제2 룩업 및 행 위치 지정 구조 내의 행 위치 지정들의 제2 쌍을 식별하는 단계 ― 상기 행 위치 지정들의 제2쌍은 상기 행 위치 지정들의 제1쌍을 오버랩함 ―, 상기 행 위치 지정들의 제2 쌍에 대응하는 상기 제2 룩업 및 행 위치 지정 구조 내의 제2 포인터를 사용하여, 상기 제2 하이브리드 추정 및 선택 열 내의 상기 행 위치 지정들의 제2 쌍 내에 존재하는 제2 추정 및 선택 열 사전 내의 제2 데이터 값을 찾는 단계, 및 상기 질의에 응답하기 위해 상기 제2 데이터 값을 사용하는 단계(using)에 의해서 실행함 ― 를 포함하는
    방법.
  2. 제1항에 있어서, 상기 선택 최적화된 배치는, 상기 주어진 선택 열에 대해, 복수의 단일 오프셋들(a plurality of single offsets)을 저장하는 단계에 의해서 형성되고, 한 세트의 개별 행 위치들(a set of individual row positions)에 대응하는 각각의 단일 오프셋은 상기 행 위치 지정들 내에 동일 고유 데이터 값을 가지며, 그리고 상기 복수의 단일 오프셋들은 함께 그룹화되어 저장되는
    방법.
  3. 삭제
  4. 삭제
  5. 제1항에 있어서, 상기 방법은 추정 최적화된 배치(a projection optimized layout)에 따라 상기 플래시 메모리 내에 추정 열들을 저장하는 단계를 더 포함하고, 상기 추정 최적화된 배치는 상기 추정 열들에 대한 임의의 액세스들(random accesses)을 최적화하도록 구성되며, 상기 추정 최적화된 배치는, 각각의 추정 열에 대해:
    주어진 추정 열 내에 추정 열 사전 내에서 소트된 순서로 저장되는 고유의 데이터 값들로 채워진 추정 열 사전(a projection column dictionary)을 저장하는 단계; 및
    상기 주어진 추정 열에서 한 번 이상 발생하는 상기 고유 데이터 값들 중 어느 것도 저장을 중복함이 없이, 상기 주어진 추정 열 내의 상기 고유의 데이터 값들의 각각에 대한 행 위치 당 인덱스(an index per row position)를 포함하는 룩업 구조(a lookup structure)를 저장하는 단계에 의해서 형성되는
    방법.
  6. 제1항에 있어서, 상기 선택 열 사전은 상기 고유 데이터 값들의 어레이를 포함하고, 상기 고유 데이터 값들은 상기 어레이 내에 인접하여 저장되는
    방법.
  7. 제1항에 있어서, 각각의 선택 열에 대해, 상기 선택 열 사전과 상기 저장된 행 위치 지정들은 상기 주어진 선택 열이 저장되는 개별 구조(a separate structure)에 대한 인덱스로서 기능하지 않고 함께 상기 주어진 선택 열을 저장하는
    방법.
  8. 삭제
  9. 삭제
  10. 삭제
  11. 질의들(queries)을 위한 데이터세트의 플래시-최적화된 저장을 위한 장치(an apparatus for flash-optimized storage)에 있어서, 상기 장치는:
    프로세서; 및
    상기 프로세서에 의해서 실행되었을 때, 상기 프로세서가 연산들(operations)을 수행하도록 하는 컴퓨터-실행가능 명령들을 포함하는 메모리를 포함하고, 상기 연산들은:
    술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성되는, 선택 최적화된 배치(a selection optimized layout)에 따라 플래시 메모리 내에 선택 열들(selection columns)을, 프로세서에 의해서, 저장하는 단계(storing) ― 상기 선택 최적화된 배치는, 각각의 선택 열에 대해서, 선택 열 사전 내에 소트된 순서로(in sorted order) 저장되는 고유 데이터 값들(unique data values)로 채워진 선택 열 사전(a selection column dictionary)을 주어진 선택 열 내에 저장하는 단계, 및, 상기 주어진 선택 열에서 한 번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 고유 데이터 값들이 상기 주어진 선택 열 내에 존재하는 각각의 행 위치에 대응하는 행 위치 지정들(row position designations)을 저장하는 단계에 의해서 형성됨 ―;
    하이브리드 추정 및 선택 최적화된 배치(a hybrid projection and selection optimized layout)에 따라 상기 플래시 메모리 내에 하이브리드 추정 및 선택 열들(hybrid projection and selection columns)을 저장하는 단계(storing) ― 각각의 하이브리드 추정 및 선택 열은 주어진 하이브리드 추정 및 선택 열 내의 중복적인 데이터 값들(duplicative data values)이 연속 행들에(in consecutive rows) 배열되도록 소트된 순서를 가지고 있고, 상기 하이브리드 추정 및 선택 최적화된 배치는: 각각의 하이브리드 추정 및 선택 열에 대해서, 그리고 상기 주어진 하이브리드 추정 및 선택 열 내의 상기 중복적인 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 주어진 하이브리드 추정 및 선택 열 내의 각각의 중복적인 데이터 값의 1(one)로 채워진 하이브리드 추정 및 선택 열 사전을 저장하는 단계 ― 상기 각각의 중복적인 데이터 값들의 1(one)들은 상기 하이브리드 추정 및 선택 열 사전 내에 소트된 순서로 저장됨 ―, 룩업 및 행 위치 지정 구조를 저장하는 단계 ― 상기 룩업 및 행 위치 지정 구조는, 상기 하이브리드 추정 및 선택 열 사전 내에 저장된 각각의 데이터 값에 대해서, 상기 주어진 하이브리드 추정 및 선택 열 내에 주어진 데이터 값이 존재하는 제1 행 위치 및 최종 행 위치에 대응하는 한 쌍의 행 위치 지정들을 포함하고, 행 위치 지정들의 각 쌍에 대해서, 상기 하이브리드 추정 및 선택 열 사전 내의 대응 데이터 값에 대한 포인터(a pointer)를 포함함 ―, 및 복수의 오프셋들을 저장하는 단계 ― 각각의 오프셋은 상기 하이브리드 추정 및 선택 열 사전 내의 데이터 값에 대응하고, 상기 데이터 값에 대응하는 행 위치 지정들의 주어진 쌍의 제1 행 위치(a first row position)의 위치(location)를 표시하는 기능을 수행함 ― 에 의해서 형성됨 ―;
    상기 데이터세트에 대하여 실행될 질의들을 수신하는 단계(receiving) ― 상기 질의는 추정 부분(a projection part)과 선택 부분(a selection part)을 포함하고, 상기 선택 부분은 상기 선택 부분 내의 규칙들(rules)에 따라 제1 하이브리드 추정 및 선택 열 내의 데이터 값들에 매칭될 술어부를 포함하며 상기 추정 부분은 상기 질의에 응답하는데 사용하기 위해 제2 하이브리드 추정 및 선택 열로부터 특정 데이터를 검색하기 위한 요건을 포함함 ―;
    상기 선택 부분을 실행하는 단계(executing) ― 상기 선택 부분을 실행하는 단계는 상기 제1 하이브리드 추정 및 선택열을 위한 제1 하이브리드 추정 및 선택열 사전 내의 제1 데이터 값에 상기 술어부를 매칭하는 단계, 상기 제1 데이터 값에 대응하는 제1 오프셋을 상기 제1 하이브리드 추정 및 선택열 사전 내의 데이터 값들에 대한 제1 복수의 오프셋들 중에서 식별하는 단계, 및 상기 제1 오프셋을 사용하여 그리고 상기 제1 하이브리드 추정 및 선택열을 위한 제1 룩업 및 행 위치 지정 구조 내에서, 상기 제1 하이브리드 추정 및 선택열 내에 상기 제1 데이터 값이 존재하는 제1 행 위치 및 최종 행 위치에 대응하는 행 위치 지정들의 제1쌍을 찾는 단계(locating)에 의해서 실행함 ―;
    상기 추정 부분을 실행하는 단계(executing) ― 상기 추정 부분을 실행하는 단계는: 상기 행 위치 지정들의 제1 쌍을 사용하여, 상기 제2 하이브리드 추정 및 선택열을 위한 제2 룩업 및 행 위치 지정 구조 내의 행 위치 지정들의 제2 쌍을 식별하는 단계 ― 상기 행 위치 지정들의 제2 쌍은 상기 행 위치 지정들의 제1 쌍을 오버랩함 ―, 상기 행 위치 지정들의 제2쌍에 대응하는 상기 제2 룩업 및 행 위치 지정 구조 내의 제2 포인터를 사용하여, 상기 제2 하이브리드 추정 및 선택 열 내의 상기 행 위치 지정들의 제2 쌍 내에 존재하는 제2 추정 및 선택 열 사전 내의 제2 데이터 값을 찾는 단계, 및 상기 질의에 응답하기 위해 상기 제2 데이터 값을 사용하는 단계(using)에 의해서 실행함 ― 를 포함하는
    장치.
  12. 제11항에 있어서, 상기 선택 최적화된 배치는, 상기 주어진 선택 열에 대해, 복수의 단일 오프셋들(a plurality of single offsets)을 저장하는 단계에 의해서 형성되고, 한 세트의 개별 행 위치들(a set of individual row positions)에 대응하는 각각의 단일 오프셋은 상기 행 위치 지정들 내에 동일 고유 데이터 값을 가지며, 그리고 상기 복수의 단일 오프셋들은 함께 그룹화되어 저장되는
    장치.
  13. 삭제
  14. 삭제
  15. 제11항에 있어서, 상기 연산은 추정 최적화된 배치(a projection optimized layout)에 따라 상기 플래시 메모리 내에 추정 열들을 저장하는 단계를 더 포함하고, 상기 추정 최적화된 배치는 상기 추정 열들에 대한 임의의 액세스들(random accesses)을 최적화하도록 구성되며, 상기 추정 최적화된 배치는, 각각의 추정 열에 대해:
    주어진 추정 열 내에 추정 열 사전 내에서 소트된 순서로 저장되는, 고유의 데이터 값들로 채워진 추정 열 사전(a projection column dictionary)을 저장하는 단계; 및
    상기 주어진 추정 열에서 한 번 이상 발생하는 상기 고유 데이터 값들 중 어느 것도 저장을 중복함이 없이, 상기 주어진 추정 열 내의 상기 고유의 데이터 값들의 각각에 대한 행 위치 당 인덱스(an index per row position)를 포함하는 룩업 구조(a lookup structure)를 저장하는 단계에 의해서 형성되는
    장치.
  16. 제11항에 있어서, 상기 선택 열 사전은 상기 고유 데이터 값들의 어레이를 포함하고, 상기 고유 데이터 값들은 상기 어레이 내에 인접하여 저장되는
    장치.
  17. 제11항에 있어서, 각각의 선택 열에 대해, 상기 선택 열 사전과 상기 저장된 행 위치 지정들은 상기 주어진 선택 열이 저장되는 개별 구조(a separate structure)에 대한 인덱스로서 기능하지 않고 함께 상기 주어진 선택 열을 저장하는
    장치.
  18. 삭제
  19. 삭제
  20. 질의들을 위한 데이터세트(a dataset for queries)의 플래시-최적화된 데이터 배치(flash-optimized data layout)를 위한 방법을 수행하는, 컴퓨터 프로세서에 의해서 판독 가능한, 프로그램 명령들을 저장하는 컴퓨터 판독가능 스토리지 매체 ― 상기 컴퓨터 판독가능 스토리지 매체는 신호가 아님 ― 에서, 상기 방법은:
    술어부 매칭(predicate matching)과 데이터 스킵핑(data skipping)을 최적화하도록 구성되는, 선택 최적화된 배치(a selection optimized layout)에 따라 플래시 메모리 내에 선택 열들(selection columns)을 저장하는 단계(storing) ― 상기 선택 최적화된 배치는, 각각의 선택 열에 대해서, 선택 열 사전 내에 소트된 순서로(in sorted order) 저장되는 고유 데이터 값들(unique data values)로 채워진 선택 열 사전(a selection column dictionary)을 주어진 선택 열 내에 저장하는 단계, 및 상기 주어진 선택 열에서 한 번 이상 발생하는 고유 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 고유 데이터 값들이 상기 주어진 선택 열 내에 존재하는 각각의 행 위치에 대응하는 행 위치 지정들(row position designations)을 저장하는 단계에 의해서 형성됨 ―;
    하이브리드 추정 및 선택 최적화된 배치(a hybrid projection and selection optimized layout)에 따라 상기 플래시 메모리 내에 하이브리드 추정 및 선택 열들(hybrid projection and selection columns)을 저장하는 단계(storing) ― 각각의 하이브리드 추정 및 선택 열은 주어진 하이브리드 추정 및 선택 열 내의 중복적인 데이터 값들(duplicative data values)이 연속 행들에(in consecutive rows) 배열되도록 소트된 순서를 가지고 있고, 상기 하이브리드 추정 및 선택 최적화된 배치는: 각각의 하이브리드 추정 및 선택 열에 대해서, 그리고 상기 주어진 하이브리드 추정 및 선택 열 내의 상기 중복적인 데이터 값들 중 어느 것의 저장도 중복함이 없이, 상기 주어진 하이브리드 추정 및 선택 열 내의 각각의 중복적인 데이터 값의 1(one)로 채워진 하이브리드 추정 및 선택 열 사전을 저장하는 단계 ― 상기 각각의 중복적인 데이터 값들의 1(one)들은 상기 하이브리드 추정 및 선택 열 사전 내에 소트된 순서로 저장됨 ―, 룩업 및 행 위치 지정 구조를 저장하는 단계 ― 상기 룩업 및 행 위치 지정 구조는, 상기 하이브리드 추정 및 선택 열 사전 내에 저장된 각각의 데이터 값에 대해서, 상기 주어진 하이브리드 추정 및 선택 열 내에 주어진 데이터 값이 존재하는 제1 행 위치 및 최종 행 위치에 대응하는 한 쌍의 행 위치 지정들을 포함하고, 행 위치 지정들의 각 쌍에 대해서, 상기 하이브리드 추정 및 선택 열 사전 내의 대응 데이터 값에 대한 포인터(a pointer)를 포함함 ―, 및 복수의 오프셋들을 저장하는 단계 ― 각각의 오프셋은 상기 하이브리드 추정 및 선택 열 사전 내의 데이터 값에 대응하고, 상기 데이터 값에 대응하는 행 위치 지정들의 주어진 쌍의 제1행 위치(a first row position)의 위치(location)를 표시하는 기능을 수행함 ― 에 의해서 형성됨 ―;
    상기 데이터세트에 대하여 실행될 질의들을 수신하는 단계(receiving) ― 상기 질의는 추정 부분(a projection part)과 선택 부분(a selection part)을 포함하고, 상기 선택 부분은 상기 선택 부분 내의 규칙들(rules)에 따라 제1 하이브리드 추정 및 선택 열 내의 데이터 값들에 매칭될 술어부를 포함하며 상기 추정 부분은 상기 질의에 응답하는데 사용하기 위해 제2 하이브리드 추정 및 선택 열로부터 특정 데이터를 검색하기 위한 요건을 포함함 ―;
    상기 선택 부분을 실행하는 단계(executing) ― 상기 선택 부분을 실행하는 단계는: 상기 제1 하이브리드 추정 및 선택열을 위한 제1 하이브리드 추정 및 선택열 사전 내의 제1 데이터 값에 상기 술어부를 매칭하는 단계, 상기 제1 데이터 값에 대응하는 제1 오프셋을 상기 제1 하이브리드 추정 및 선택열 사전 내의 데이터 값들에 대한 제1 복수의 오프셋들 중에서 식별하는 단계, 및 상기 제1 오프셋을 사용하여 그리고 상기 제1 하이브리드 추정 및 선택열을 위한 제1 룩업 및 행 위치 지정 구조 내에서, 상기 제1 하이브리드 추정 및 선택열 내에 상기 제1 데이터 값이 존재하는 제1 행 위치 및 최종 행 위치에 대응하는 행 위치 지정들의 제1쌍을 찾는 단계(locating)에 의해서 실행함 ―;
    상기 추정 부분을 실행하는 단계(executing) ― 상기 추정 부분을 실행하는 단계는 상기 행 위치 지정들의 제1 쌍을 사용하여, 상기 제2 하이브리드 추정 및 선택열을 위한 제2 룩업 및 행 위치 지정 구조 내의 행 위치 지정들의 제2 쌍을 식별하는 단계 ― 상기 행 위치 지정들의 제2 쌍은 상기 행 위치 지정들의 제1 쌍을 오버랩함 ―, 상기 행 위치 지정들의 제2 쌍에 대응하는 상기 제2 룩업 및 행 위치 지정 구조 내의 제2 포인터를 사용하여, 상기 제2 하이브리드 추정 및 선택 열 내의 상기 행 위치 지정들의 제2 쌍 내에 존재하는 제2 추정 및 선택 열 사전 내의 제2 데이터 값을 찾는 단계, 및 상기 질의에 응답하기 위해 상기 제2 데이터 값을 사용하는 단계(using)에 의해서 실행함 ― 를 포함하는
    컴퓨터 판독가능 스토리지 매체.
KR1020167032457A 2014-06-16 2015-06-10 빅 데이터 질의 엔진을 위한 플래시 최적화된 열 데이터 배치 및 데이터 액세스 처리 알고리즘 KR101938953B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/305,179 2014-06-16
US14/305,179 US9846567B2 (en) 2014-06-16 2014-06-16 Flash optimized columnar data layout and data access algorithms for big data query engines
PCT/IB2015/054387 WO2015193771A1 (en) 2014-06-16 2015-06-10 Flash optimized columnar data layout and data access algorithms for big data query engines

Publications (2)

Publication Number Publication Date
KR20160145785A KR20160145785A (ko) 2016-12-20
KR101938953B1 true KR101938953B1 (ko) 2019-01-15

Family

ID=54836185

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020167032457A KR101938953B1 (ko) 2014-06-16 2015-06-10 빅 데이터 질의 엔진을 위한 플래시 최적화된 열 데이터 배치 및 데이터 액세스 처리 알고리즘

Country Status (5)

Country Link
US (3) US9846567B2 (ko)
JP (1) JP6639420B2 (ko)
KR (1) KR101938953B1 (ko)
GB (1) GB2544206B (ko)
WO (1) WO2015193771A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102175183B1 (ko) 2020-06-09 2020-11-05 이창근 기업 데이터 통합 관리 방법, 장치, 및 시스템

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9501550B2 (en) * 2012-04-18 2016-11-22 Renmin University Of China OLAP query processing method oriented to database and HADOOP hybrid platform
US9442954B2 (en) * 2012-11-12 2016-09-13 Datawise Systems Method and apparatus for achieving optimal resource allocation dynamically in a distributed computing environment
US9846567B2 (en) 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US10127260B2 (en) * 2014-11-25 2018-11-13 Sap Se In-memory database system providing lockless read and write operations for OLAP and OLTP transactions
US10409835B2 (en) * 2014-11-28 2019-09-10 Microsoft Technology Licensing, Llc Efficient data manipulation support
US9952808B2 (en) 2015-03-26 2018-04-24 International Business Machines Corporation File system block-level tiering and co-allocation
JP6893209B2 (ja) * 2015-10-30 2021-06-23 アクシオム コーポレーション 構造化されたマルチフィールドファイルのレイアウトの自動解釈
KR101780652B1 (ko) * 2016-03-11 2017-09-21 주식회사 이디엄 열-지향 레이아웃 파일 생성 방법
CN107360103A (zh) * 2016-05-09 2017-11-17 中国移动通信集团四川有限公司 一种操作维护系统和资源调度方法
US10873582B2 (en) 2016-05-23 2020-12-22 Jpmorgan Chase Bank, N.A. Security design and architecture for a multi-tenant Hadoop cluster
US10437780B2 (en) * 2016-07-14 2019-10-08 Snowflake Inc. Data pruning based on metadata
US10762071B2 (en) * 2016-11-29 2020-09-01 Sap Se Value-ID-based sorting in column-store databases
US10956469B2 (en) * 2017-01-06 2021-03-23 International Business Machines Corporation System and method for metadata correlation using natural language processing
US10409814B2 (en) * 2017-01-26 2019-09-10 International Business Machines Corporation Network common data form data management
US10585913B2 (en) * 2017-03-20 2020-03-10 Datameer, Inc. Apparatus and method for distributed query processing utilizing dynamically generated in-memory term maps
CN107644070B (zh) * 2017-09-13 2020-09-15 北京柠檬微趣科技股份有限公司 数据索引方法、数据查询方法及电子设备
US10621167B2 (en) 2017-10-26 2020-04-14 Sap Se Data separation and write redirection in multi-tenancy database systems
US10733168B2 (en) * 2017-10-26 2020-08-04 Sap Se Deploying changes to key patterns in multi-tenancy database systems
US10740315B2 (en) 2017-10-26 2020-08-11 Sap Se Transitioning between system sharing types in multi-tenancy database systems
US10713277B2 (en) 2017-10-26 2020-07-14 Sap Se Patching content across shared and tenant containers in multi-tenancy database systems
US10657276B2 (en) 2017-10-26 2020-05-19 Sap Se System sharing types in multi-tenancy database systems
US10740318B2 (en) 2017-10-26 2020-08-11 Sap Se Key pattern management in multi-tenancy database systems
CN110020227B (zh) * 2017-10-31 2021-10-15 北京国双科技有限公司 一种数据排序方法和装置
CN110019218B (zh) 2017-12-08 2023-08-25 阿里巴巴集团控股有限公司 数据存储与查询方法及设备
TWI664527B (zh) * 2018-03-20 2019-07-01 慧榮科技股份有限公司 用來於一記憶裝置中進行初始化之方法、記憶裝置及其控制器以及電子裝置
EP3547166B1 (en) * 2018-03-26 2020-12-02 Hasso-Plattner-Institut für Digital Engineering gGmbH Data placement in hybrid data layouts for tiered htap databases
US10915551B2 (en) 2018-06-04 2021-02-09 Sap Se Change management for shared objects in multi-tenancy systems
US11379450B2 (en) * 2018-10-09 2022-07-05 Oracle International Corporation Relational method for transforming unsorted sparse dictionary encodings into unsorted-dense or sorted-dense dictionary encodings
CN109637278A (zh) * 2019-01-03 2019-04-16 青岛萨纳斯智能科技股份有限公司 大数据教学实验实训平台
US11106674B2 (en) * 2019-03-31 2021-08-31 International Business Machines Corporation Extensible data skipping
US11176133B2 (en) * 2019-04-04 2021-11-16 Sap Se Filter evaluation for table fragments
US11163766B2 (en) * 2019-04-04 2021-11-02 Sap Se Unique key lookup with additional filter
US11327995B2 (en) 2019-09-11 2022-05-10 Micro Focus Llc Complex data type encoding within columnar database
CN110795407B (zh) * 2019-10-14 2022-06-10 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 适用于分布式文件系统的文件随机写方法及系统
US11914589B2 (en) * 2020-02-28 2024-02-27 Sap Se Efficient computation of order by, order by with limit, min, and max in column-oriented databases
US11366796B2 (en) * 2020-04-30 2022-06-21 Oracle International Corporation Systems and methods for compressing keys in hierarchical data structures
US11762559B2 (en) 2020-05-15 2023-09-19 International Business Machines Corporation Write sort management in a multiple storage controller data storage system
US11580022B2 (en) 2020-05-15 2023-02-14 International Business Machines Corporation Write sort management in a multiple storage controller data storage system
US11954134B2 (en) * 2021-12-08 2024-04-09 Sap Se Visualization of complex hierarchy data with interactive adjustments
US11886409B1 (en) * 2022-08-11 2024-01-30 Sap Se Searchable catalog of columnar numerical data

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5918225A (en) * 1993-04-16 1999-06-29 Sybase, Inc. SQL-based database system with improved indexing methodology
US5848406A (en) 1996-09-03 1998-12-08 Matsushita Electric Industrial Co., Ltd. Method for presenting information on display devices of varying sizes
US6330555B1 (en) 1999-02-19 2001-12-11 Nortel Networks Limited Method and apparatus for enabling a view of data across a database
US6487641B1 (en) 1999-04-19 2002-11-26 Oracle Corporation Dynamic caches with miss tables
US7024414B2 (en) 2001-08-06 2006-04-04 Sensage, Inc. Storage of row-column data
US7499907B2 (en) * 2001-10-12 2009-03-03 Teradata Us, Inc. Index selection in a database system
US7117222B2 (en) 2003-03-13 2006-10-03 International Business Machines Corporation Pre-formatted column-level caching to improve client performance
EP2261821B1 (en) 2003-09-15 2022-12-07 Ab Initio Technology LLC Data profiling
KR100684942B1 (ko) 2005-02-07 2007-02-20 삼성전자주식회사 복수의 사상 기법들을 채용한 적응형 플래시 메모리 제어장치 및 그것을 포함한 플래시 메모리 시스템
US8538969B2 (en) * 2005-06-03 2013-09-17 Adobe Systems Incorporated Data format for website traffic statistics
US7457910B2 (en) 2005-06-29 2008-11-25 Sandisk Corproation Method and system for managing partitions in a storage device
CN100471180C (zh) * 2006-02-09 2009-03-18 华为技术有限公司 一种消息传递的方法、装置和系统
US7761444B2 (en) 2006-10-05 2010-07-20 Hewlett-Packard Development Company, L.P. Identifying a sequence of blocks of data to retrieve based on a query
KR101464199B1 (ko) 2006-12-26 2014-11-21 샌디스크 테크놀로지스, 인코포레이티드 연속 논리 주소 공간 인터페이스를 구비한 다이렉트 데이터 파일 시스템을 사용하는 방법
US8150850B2 (en) 2008-01-07 2012-04-03 Akiban Technologies, Inc. Multiple dimensioned database architecture
US9805077B2 (en) 2008-02-19 2017-10-31 International Business Machines Corporation Method and system for optimizing data access in a database using multi-class objects
US8121975B2 (en) 2008-02-20 2012-02-21 Panorama Software Inc. Creating pivot tables from tabular data
US8478775B2 (en) 2008-10-05 2013-07-02 Microsoft Corporation Efficient large-scale filtering and/or sorting for querying of column based data encoded structures
US8935223B2 (en) 2009-04-30 2015-01-13 Oracle International Corporation Structure of hierarchical compressed data structure for tabular data
WO2010141182A2 (en) * 2009-06-02 2010-12-09 Saffron Technology, Inc. Methods, systems and computer program products for providing a distributed associative memory base
US20110029319A1 (en) * 2009-07-29 2011-02-03 Google Inc. Impression forecasting and reservation analysis
CN102859517B (zh) * 2010-05-14 2016-07-06 株式会社日立制作所 时序数据管理装置、系统以及方法
US9218408B2 (en) 2010-05-27 2015-12-22 Oracle International Corporation Method for automatically creating a data mart by aggregated data extracted from a business intelligence server
US8284627B2 (en) 2010-10-22 2012-10-09 International Business Machines Corporation Reducing energy consumption and optimizing workload and performance in multi-tier storage systems using extent-level dynamic tiering
JP5178813B2 (ja) 2010-12-16 2013-04-10 ヤフー株式会社 検索システム及び方法
EP2671160A2 (en) 2011-02-01 2013-12-11 Drobo, Inc. System, apparatus, and method supporting asymmetrical block-level redundant storage
US10152482B2 (en) * 2011-10-07 2018-12-11 Synopsys, Inc. Method of speeding up access to design databases having large numbers of design units
US8914353B2 (en) 2011-12-20 2014-12-16 Sap Se Many-core algorithms for in-memory column store databases
US11347443B2 (en) 2012-04-13 2022-05-31 Veritas Technologies Llc Multi-tier storage using multiple file sets
US9658896B2 (en) 2012-05-16 2017-05-23 International Business Machines Corporation Apparatus and method to manage device performance in a storage system
US8868576B1 (en) 2012-06-28 2014-10-21 Emc Corporation Storing files in a parallel computing system based on user-specified parser function
US10909113B2 (en) 2013-07-31 2021-02-02 Sap Se Global dictionary for database management systems
US9292554B2 (en) * 2013-08-20 2016-03-22 Pivotal Software, Inc. Thin database indexing
CA2867589A1 (en) 2013-10-15 2015-04-15 Coho Data Inc. Systems, methods and devices for implementing data management in a distributed data storage system
US9450602B2 (en) * 2014-01-02 2016-09-20 Sap Se Efficiently query compressed time-series data in a database
US9633058B2 (en) 2014-06-16 2017-04-25 International Business Machines Corporation Predictive placement of columns during creation of a large database
US9846567B2 (en) 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US9952808B2 (en) 2015-03-26 2018-04-24 International Business Machines Corporation File system block-level tiering and co-allocation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102175183B1 (ko) 2020-06-09 2020-11-05 이창근 기업 데이터 통합 관리 방법, 장치, 및 시스템

Also Published As

Publication number Publication date
GB2544206B (en) 2017-11-08
US20180011690A1 (en) 2018-01-11
WO2015193771A1 (en) 2015-12-23
US20180225090A1 (en) 2018-08-09
US9846567B2 (en) 2017-12-19
JP2017518584A (ja) 2017-07-06
KR20160145785A (ko) 2016-12-20
GB2544206A (en) 2017-05-10
US10048937B2 (en) 2018-08-14
US10162598B2 (en) 2018-12-25
GB201621179D0 (en) 2017-01-25
JP6639420B2 (ja) 2020-02-05
US20150363167A1 (en) 2015-12-17

Similar Documents

Publication Publication Date Title
KR101938953B1 (ko) 빅 데이터 질의 엔진을 위한 플래시 최적화된 열 데이터 배치 및 데이터 액세스 처리 알고리즘
US11593037B2 (en) File system block-level tiering and co-allocation
US11194780B2 (en) Early exit from table scans of loosely ordered and/or grouped relations using nearly ordered maps
US20190138500A1 (en) Using a distributed prime data sieve for efficient lossless reduction, search, and retrieval of data
US10114908B2 (en) Hybrid table implementation by using buffer pool as permanent in-memory storage for memory-resident data
US10042914B2 (en) Database index for constructing large scale data level of details
KR102034833B1 (ko) 플래시 저장장치의 내부 병렬성을 이용하는 키 값 기반의 데이터 액세스 장치 및 방법
Mostak An overview of MapD (massively parallel database)
US9218394B2 (en) Reading rows from memory prior to reading rows from secondary storage
US9569477B1 (en) Managing scanning of databases in data storage systems
WO2018205151A1 (zh) 数据更新方法和存储装置
US11468031B1 (en) Methods and apparatus for efficiently scaling real-time indexing
Yang et al. Pase: Postgresql ultra-high-dimensional approximate nearest neighbor search extension
JP6726690B2 (ja) 基本データシーブを用いて無損失削減されたデータに対する多次元検索、コンテンツ連想的な取出し、ならびにキーワードベースの検索および取出しの実行
US11520763B2 (en) Automated optimization for in-memory data structures of column store databases
Omar et al. A scalable array storage for efficient maintenance of future data
Otoo et al. Accelerating queries on very large datasets
US20230394017A1 (en) Systems and methods for column store indices
Ravindran et al. Data structures for big data stores
Šalgová et al. The impact of table and index compression
Han et al. Chunk-oriented dimension ordering for efficient range query processing on sparse multidimensional data

Legal Events

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