RISS 학술연구정보서비스

검색

인기 검색어

    다국어 입력

    http://chineseinput.net/에서 pinyin(병음)방식으로 중국어를 변환할 수 있습니다.

    변환된 중국어를 복사하여 사용하시면 됩니다.

    예시)
    • 中文 을 입력하시려면 zhongwen을 입력하시고 space를누르시면됩니다.
    • 北京 을 입력하시려면 beijing을 입력하시고 space를 누르시면 됩니다.
    닫기
    KCI등재

    행 기반 저장소에서 컬럼 접근 최적화 = Optimizing Column Accesses in Row-Store

    한글로보기

    https://www.riss.kr/link?id=A103729633

    • 0

      상세조회
    • 0

      다운로드
    서지정보 열기
    • 내보내기
    • 내책장담기
    • 공유하기
      • URL 복사
    • 오류접수
    인용문이 복사되었습니다.

    부가정보

    다국어 초록 (Multilingual Abstract) kakao i 다국어 번역

    In order to access a column value in traditional row-store DBMSs, its starting position should be identified. Even in most modern row-wise DBMS such as Oracle and PostgreSQL, all the preceding columns in a tuple to which a column under access belongs need to be scanned in order to calculate the offset of the column. With this approach, there exist two performance problems,especially when columns to be accessed are physically located at the rear part of long tuples: 1)many CPU instructions are required to calculate the offset and 2) excessive CPU cache misses are encountered from accessing other columns irrelevant to the query. In this paper, we propose an optimization technique for accessing columns in row-store DBMSs and describe our implementation using an open source DBMS, PostgreSQL. Specifically, in our scheme, the offset of each column is pre-calculated and stored in an array of column offset in the tuple header, and from the offset information, a column data can be accessed only by obtaining its offset from the array. According to our simple experiment using a table from TPC-H benchmark, our scheme can outperform the existing one by up to 50 percent. And this remarkable performance improvement can be explained by the reduced CPU instructions used in calculating the column offset, and increased cache efficiency by reducing main memory accesses while scanning the tuple. To make the calculation simpler, proposed structure would increase size of the table, but improves cache efficiency when scanned pages are not cached in CPU. Therefore, it will be effective to systems that queries are intensively executed on specific hot-data or main memory DBMS.
    번역하기

    In order to access a column value in traditional row-store DBMSs, its starting position should be identified. Even in most modern row-wise DBMS such as Oracle and PostgreSQL, all the preceding columns in a tuple to which a column under access belongs ...

    In order to access a column value in traditional row-store DBMSs, its starting position should be identified. Even in most modern row-wise DBMS such as Oracle and PostgreSQL, all the preceding columns in a tuple to which a column under access belongs need to be scanned in order to calculate the offset of the column. With this approach, there exist two performance problems,especially when columns to be accessed are physically located at the rear part of long tuples: 1)many CPU instructions are required to calculate the offset and 2) excessive CPU cache misses are encountered from accessing other columns irrelevant to the query. In this paper, we propose an optimization technique for accessing columns in row-store DBMSs and describe our implementation using an open source DBMS, PostgreSQL. Specifically, in our scheme, the offset of each column is pre-calculated and stored in an array of column offset in the tuple header, and from the offset information, a column data can be accessed only by obtaining its offset from the array. According to our simple experiment using a table from TPC-H benchmark, our scheme can outperform the existing one by up to 50 percent. And this remarkable performance improvement can be explained by the reduced CPU instructions used in calculating the column offset, and increased cache efficiency by reducing main memory accesses while scanning the tuple. To make the calculation simpler, proposed structure would increase size of the table, but improves cache efficiency when scanned pages are not cached in CPU. Therefore, it will be effective to systems that queries are intensively executed on specific hot-data or main memory DBMS.

    더보기

    국문 초록 (Abstract) kakao i 다국어 번역

    전통적인 행 기반 데이터베이스에서 특정 컬럼에 접근하기 위해서는 컬럼의 위치를 나타내는 오프셋을 구해야한다. Oracle이나 PostgreSQL과 같은 DBMS는 질의에 의해 요청된 컬럼의 오프셋을 구하기 위하여 선행하는 컬럼들의 길이를 더한다. 이때 선행하는 컬럼들의 길이는 컬럼의 헤더로부터 구할 수 있다. 이러한 방식은 적은 수의컬럼에 접근할 때에도 필요한 컬럼 뿐 아니라 다른 컬럼에 접근하면서 많은 CPU 명령어 수행을 필요로 하며, 튜플길이가 긴 경우 불필요한 데이터 캐시 미스를 유발한다. 본 논문에서는 행 기반 저장소에서의 컬럼 접근 최적화기법을 제안하고, 이를 오픈소스 DBMS PostgreSQL를 사용해서 구현하였다. 구체적으로, 컬럼 접근 최적화를 위해각 컬럼들의 오프셋 위치를 미리 계산해서, 튜플 헤더 부분에 배열 구조로 위치시키고 컬럼 접근시 오프셋 값을이용해서 해당 컬럼 데이터를 바로 접근하게 하였다. TPC-H 벤치마크의 특정 테이블을 사용한 실험 결과, 제안기법은 기존 방식에 비해 최대 50%까지 성능 개선을 확인하였다. 이러한 성능 향상은 컬럼 오프셋 위치를 구하는데필요한 CPU 명령어 감소와, 메모리 접근 횟수를 줄임으로써 캐시 효율이 증가하는 것에 기인한다. 제안한 방식은단순한 계산을 위하여 테이블의 크기를 증가시키지만 탐색중인 페이지가 CPU에 캐시 되지 않은 경우 캐시 효율증가를 기대할 수 있다. 따라서 특정 Hot data가 자주 사용되는 환경이나 메인 메모리 DB에서 효과 적일 것이다.
    번역하기

    전통적인 행 기반 데이터베이스에서 특정 컬럼에 접근하기 위해서는 컬럼의 위치를 나타내는 오프셋을 구해야한다. Oracle이나 PostgreSQL과 같은 DBMS는 질의에 의해 요청된 컬럼의 오프셋을 구...

    전통적인 행 기반 데이터베이스에서 특정 컬럼에 접근하기 위해서는 컬럼의 위치를 나타내는 오프셋을 구해야한다. Oracle이나 PostgreSQL과 같은 DBMS는 질의에 의해 요청된 컬럼의 오프셋을 구하기 위하여 선행하는 컬럼들의 길이를 더한다. 이때 선행하는 컬럼들의 길이는 컬럼의 헤더로부터 구할 수 있다. 이러한 방식은 적은 수의컬럼에 접근할 때에도 필요한 컬럼 뿐 아니라 다른 컬럼에 접근하면서 많은 CPU 명령어 수행을 필요로 하며, 튜플길이가 긴 경우 불필요한 데이터 캐시 미스를 유발한다. 본 논문에서는 행 기반 저장소에서의 컬럼 접근 최적화기법을 제안하고, 이를 오픈소스 DBMS PostgreSQL를 사용해서 구현하였다. 구체적으로, 컬럼 접근 최적화를 위해각 컬럼들의 오프셋 위치를 미리 계산해서, 튜플 헤더 부분에 배열 구조로 위치시키고 컬럼 접근시 오프셋 값을이용해서 해당 컬럼 데이터를 바로 접근하게 하였다. TPC-H 벤치마크의 특정 테이블을 사용한 실험 결과, 제안기법은 기존 방식에 비해 최대 50%까지 성능 개선을 확인하였다. 이러한 성능 향상은 컬럼 오프셋 위치를 구하는데필요한 CPU 명령어 감소와, 메모리 접근 횟수를 줄임으로써 캐시 효율이 증가하는 것에 기인한다. 제안한 방식은단순한 계산을 위하여 테이블의 크기를 증가시키지만 탐색중인 페이지가 CPU에 캐시 되지 않은 경우 캐시 효율증가를 기대할 수 있다. 따라서 특정 Hot data가 자주 사용되는 환경이나 메인 메모리 DB에서 효과 적일 것이다.

    더보기

    참고문헌 (Reference)

    1 A. Ailamaki, "Weaving Relations for Cache Performance" 169-180, 2001

    2 N. Bruno, "Teaching an Old Elephant New Tricks" 2009

    3 S. Byna, "Taxonomy of Data Prefetching for Multicore Processors" 24 (24): 405-417, 2009

    4 C. Kim, "Sort vs. Hash Revisited: Fast Join Implementation on Modern Multi-Core CPUs" 2 (2): 1378-1389, 2009

    5 P. A. Deshmukh, "Review on Main Memory Database"

    6 D. Levinthal, "Performance Analysis Guide for Intel® Core™ i7 Processor and Intel® Xeon™ 5500 processors"

    7 L. Ashdown, "Oracle® Database Concepts 11g Release 2" Oracle Corp. 248-249, 2011

    8 K. Delaney, "Microsoft® SQL Server® 2008 Internals" Microsoft press 267-270, 2009

    9 J. Rao, "Making B+ Trees Cache Conscious in Main Memory" 475-486, 2000

    10 H. Garcia-Molina, "Main Memory Database Systems: An Overview" 4 (4): 1992

    1 A. Ailamaki, "Weaving Relations for Cache Performance" 169-180, 2001

    2 N. Bruno, "Teaching an Old Elephant New Tricks" 2009

    3 S. Byna, "Taxonomy of Data Prefetching for Multicore Processors" 24 (24): 405-417, 2009

    4 C. Kim, "Sort vs. Hash Revisited: Fast Join Implementation on Modern Multi-Core CPUs" 2 (2): 1378-1389, 2009

    5 P. A. Deshmukh, "Review on Main Memory Database"

    6 D. Levinthal, "Performance Analysis Guide for Intel® Core™ i7 Processor and Intel® Xeon™ 5500 processors"

    7 L. Ashdown, "Oracle® Database Concepts 11g Release 2" Oracle Corp. 248-249, 2011

    8 K. Delaney, "Microsoft® SQL Server® 2008 Internals" Microsoft press 267-270, 2009

    9 J. Rao, "Making B+ Trees Cache Conscious in Main Memory" 475-486, 2000

    10 H. Garcia-Molina, "Main Memory Database Systems: An Overview" 4 (4): 1992

    11 K. Jung, "Implementing Storage Manager in Main Memory DBMS ALTIBASE™" 2003

    12 P. Larson, "High-Performance Concurrency Control Mechanisms for Main-Memory Databases" 5 (5): 298-309, 2011

    13 S. P. Vanderwiel, "Data Prefetch Mechanisms" 32 (32): 174-199, 2000

    14 A. Ailamaki, "DBMSs On A Modern Processor: Where Does Time Go?" 266-277, 1999

    15 A. El-Helw, "Column-Oriented Query Processing for Row Stores" 67-74, 2011

    16 A. Shatdal, "Cache Conscious Algorithms for Relational Query Processing" 510-521, 1994

    더보기

    분석정보

    View

    상세정보조회

    0

    Usage

    원문다운로드

    0

    대출신청

    0

    복사신청

    0

    EDDS신청

    0

    동일 주제 내 활용도 TOP

    더보기

    주제

    연도별 연구동향

    연도별 활용동향

    연관논문

    연구자 네트워크맵

    공동연구자 (7)

    유사연구자 (20) 활용도상위20명

    인용정보 인용지수 설명보기

    학술지 이력

    학술지 이력
    연월일 이력구분 이력상세 등재구분
    2026 평가 재인증평가 신청대상 (재인증)
    2020-01-01 등재 등재학술지 유지 (재인증) KCI등재
    2017-01-01 등재 등재학술지 유지 (계속평가) KCI등재
    2013-01-01 등재 등재학술지 유지 (등재유지) KCI등재
    2010-01-01 등재 등재학술지 선정 (등재후보2차) KCI등재
    2009-01-01 등재 등재후보 1차 PASS (등재후보1차) KCI등재후보
    2007-01-01 등재 등재후보학술지 선정 (신규평가) KCI등재후보
    더보기

    학술지 인용정보

    학술지 인용정보
    기준연도 WOS-KCI 통합IF(2년) KCIF(2년) KCIF(3년)
    2016 0.02 0.02 0.01
    KCIF(4년) KCIF(5년) 중심성지수(3년) 즉시성지수
    0.02 0.02 0.183 0.03
    더보기
    해외이동버튼