KR101968474B1 - 플래시 캐시에서 트랜잭션 지원 방법 및 장치 - Google Patents

Abstract

플래시 캐시에서 트랜잭션을 지원하는 방법이 제공된다. 본 발명의 일 실시예에 따른 플래시 캐시에서 트랜잭션을 지원하는 플래시 캐시에서 어플리케이션이 요청한 트랜잭션을 복수의 캐시 블록들로 일괄 처리하기 위한 트랜잭션 지원 방법은 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 일괄하여 저장하는 단계와 트랜잭션 종료 API의 호출 이후에, 상기 복수의 캐시 블록을 일괄하여 대상 저장 장치에 저장하는 단계를 포함한다.

Description

플래시 캐시에서 트랜잭션 지원 방법 및 장치{A method and an apparatus for supporting transactions in the flash cache}

본 발명은 플래시 캐시에서 트랜잭션을 지원하는 방법에 관한 것이다. 보다 자세하게는, 트랜잭션 API(Application Programming Interface) 및 플래시 캐시 블록 관리 기법을 이용하여 쓰기 증폭을 제거하기 위한 트랜잭션 지원 방법 및 장치에 관한 것이다.

플래시 SSD(Solid State Drive)는 기존 하드디스크 대비 월등한 성능 때문에 서버에서부터 데스크탑까지 다양한 환경에서 활용되고 있다. 그러나, 플래시 SSD는 하드디스크 보다 용량 당 가격이 높기 때문에 하드디스크를 완전히 대체하는 대신 플래시 캐시를 하드디스크의 비휘발성 캐시 형태로 사용되고 있다.

플래시 캐시는 기존 어플리케이션의 수정 없이 사용하기 위해서 일반적으로 운영체제의 블록 계층에 소프트웨어 형태로 구현되어 있다. 이러한 캐시 구조에서는 모든 블록 쓰기 요청은 우선 플래시 SSD에 저장 된 후에 하드디스크로 최종 저장되는 방식으로 관리된다.

상기 기존의 플래시 캐시 구조에서 중복 쓰기 기반의 트랜잭션을 지원하는 어플리케이션이 실행되는 경우에 다음과 같은 문제점이 있다. 첫째, 어플리케이션이 중복 쓰기를 수행한 데이터에 대해 또 다시 플래시 SSD와 하드디스크로의 중복 쓰기를 수행함에 따라 불필요한 작업이 발생하여 플래시 SSD의 수명을 단축시킨다. 둘째, 상기 중복 쓰기 작업은 저장장치에서 불필요한 경쟁을 유발시켜 어플리케이션의 성능을 저하시킨다. 상술한 문제점을 해결하기 위한 트랜잭션 지원 방법 및 장치가 요구된다.

본 발명이 해결하고자 하는 기술적 과제는, 중복 쓰기 기반의 트랜잭션을 지원함에 있어서, 트랜잭션 API를 이용하여 트랜잭션을 지원하는 방법 및 장치를 제공하기 위함이다.

본 발명이 해결하고자 하는 다른 기술적 과제는, 중복 쓰기 기반의 트랜잭션을 지원함에 있어서, 플래시 캐시 블록을 관리하는 방법 및 장치를 제공하기 위함이다.

본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명의 기술분야에서의 통상의 기술자에게 명확하게 이해 될 수 있을 것이다.

상기 기술적 과제를 해결하기 위한, 본 발명의 일 실시예에 따른 플래시 캐시에서 트랜잭션 처리 방법은, 플래시 캐시에서 어플리케이션이 요청한 트랜잭션을 복수의 캐시 블록들로 일괄 처리하기 위한 트랜잭션 지원 방법에 있어서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 상기 어플리케이션에 의하여 호출된 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 일괄하여 저장하는 단계; 및 상기 트랜잭션 종료 API의 호출 이후에, 상기 복수의 캐시 블록을 모두 일괄하여 대상 저장 장치에 저장하는 단계를 포함할 수 있다.

일 실시예에서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 상기 어플리케이션에 의하여 호출된 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 일괄하여 저장하는 단계는 상기 트랜잭션 시작 API가 호출된 후, 상기 어플리케이션에 의하여 호출된 트랜잭션 철회 API가 상기 트랜잭션 시작 API에 의한 트랜잭션과 연관된 캐시 블록을 무효화 시키는 단계를 더 포함할 수 있다.

일 실시예에서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 단계는, 상기 캐시 블록에 대한 업데이트를 위해 상기 캐시 블록에는 고유의 트랜잭션 ID가 부여되고, 기존 캐시 블록을 재사용할 지 여부를 결정하는 단계; 및 상기 결정 단계에서, 들어오는 업데이트와 연관된 캐시 블록의 트랜잭션 ID가 같은 경우, 기존의 캐시 블록을 업데이트 하는 단계를 더 포함할 수 있다.

일 실시예에서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 단계는, 상기 캐시 블록에 대한 업데이트를 위해 상기 캐시 블록에는 고유의 트랜잭션 ID가 부여되고, 기존 캐시 블록을 재사용할 지 여부를 결정하는 단계; 및 상기 결정 단계에서, 상기 들어오는 업데이트와 상기 연관된 캐시 블록의 트랜잭션 ID가 다른 경우, 높은 트랜잭션 ID가 부여된 캐시 블록이 철회되는 단계를 더 포함 할 수 있다.

일 실시예에서, 상기 캐시 블록에 대한 메타 데이터의 메모리 레이아웃의 구조는 단일 배열 구조로 할 수 있다.

일 실시예에서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 상기 어플리케이션에 의하여 호출된 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 일괄하여 저장하는 단계는 상기 메타 데이터 영역의 빈 블록을 확보하기 위해 압축 스레드를 만드는 단계 및 상기 압축 스레드를 병합하는 위치에 대한 정보가 포함된 로그가 추가 되는 단계 및 상기 압축 스레드를 컴팩트 로그에 추가하는 단계를 더 포함할 수 있다.

일 실시예에서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 단계는, 캐시 미스가 발생한 경우 상기 어플리케이션에 의하여 호출된 쓰기 요청에 응답하여 캐시 블록 할당 및 대체를 수행하는 단계를 포함하되, 상기 캐시 블록 할당 및 대체를 수행하는 단계는, 무효화 된 캐시 블록을 회수하여 대체 캐시 블록 자리에 새로운 캐시 블록으로 할당하고, 상기 무효화 된 캐시 블록이 없는 경우, 클린 상태의 캐시 블록을 대체 캐시 블록 자리에 할당하며, 상기 클린 상태의 캐시 블록이 없는 경우, 라이트백 된 클린 상태의 캐시 블록을 대체 캐시 블록 자리에 할당 하는 단계를 더 포함할 수 있다.

일 실시예에서, 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 단계는, 시스템이 장애로부터 복구 된 후, 플래시 캐시 메타 데이터를 리커버리 하는 단계를 포함하되, 메타 데이터 로그를 검색하기 위해 상기 메타 데이터 영역을 스캔하고, 상기 스캔이 종료되면, 새로운 메타 데이터의 매핑을 유지하고, 기존의 캐시 블록을 복구하는 리커버리 단계를 더 포함할 수 있다.

일 실시예에서, 플래시 캐시에서 어플리케이션이 복수의 캐시 블록들을 일괄 처리하기 위한 트랜잭션을 지원하는 장치는 상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 플래시 캐시 및 상기 트랜잭션 종료 API의 호출 이후에, 상기 복수의 캐시 블록을 모두 일괄 저장하는 대상 저장 장치를 포함 할 수 있다.

상술한 본 발명에 따르면, 트랜잭션을 지원하는 어플리케이션에 적용 시, 불필요한 쓰기 요청의 수를 줄임으로써 어플리케이션 리퀘스트에 대한 처리량을 향상시키고 응답 지연을 감소시키는 효과가 있다.

또한, 불필요한 쓰기 요청의 수를 줄임으로써 플래시 SSD의 수명을 향상시키는 효과가 있다.

본 발명의 효과들은 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.

도 1은 본 발명의 일 실시예에 따른 플래시 캐시에서 트랜잭션을 지원하는 시스템에 대한 블록 구성도이다.
도 2는 상기 트랜잭션을 지원하는 시스템에서 트랜잭션 API를 나타내는 블록 구성도이다.
도 3은 본 발명의 일 실시예에 따른 플래시 캐시 블록 관리 기법에서 각 캐시 블록의 상태도이다.
도 4는 상기 플래시 캐시 블록 관리 기법에서 캐시 블록 상태에 따른 상태 전이도이다.
도 5는 메타 데이터 로그에 관한 구조를 설명하기 위한 도면이다.
도 6은 트랜잭션 커밋 절차에서 메타 데이터 로거 및 플래시 상의 메타 데이터를 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따른 트랜잭션 커밋 절차의 예를 나타내는 도면이다.
도 8 내지 도 10은 본 발명의 일 실시예에 따른 TxFCache의 트랜잭션 API를 활용한 경우 실험 결과를 나타내는 도면이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예들을 상세히 설명한다. 본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 게시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 게시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다. 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다.

기존의 트랜잭션 지원 기술들은 하드웨어 또는 펌웨어 수준에서 수정을 통한 API(Application Programming Interface) 지원이 필요하지만, 본 발명이 제공하는 트랜잭션 지원 방법은 시중에서 판매되고 있는 상용 플래시 SSD 또는 하드 디스크에 플래시 캐시를 구성하더라도 소프트웨어 구현만으로 트랜잭션을 지원할 수 있다.

DRAM 또는 SRAM 과 같은 휘발성 메모리 기반의 트랜잭션 지원 기술과는 달리 본 발명이 제공하는 트랜잭션 지원 방법은 비 휘발성 메모리인 플래시 SSD를 대상으로 하기 때문에 전원이 꺼지는 등의 시스템 크래시가 발생한 경우에도 변경이 진행 중이던 데이터 블록의 내용이 재부팅 시에도 그대로 남아있다. 따라서, 휘발성 메모리 기반과는 달리 비 휘발성 플래시 메모리에 저장되어 있는 데이터를 일관성 있게 복구하는 것이 필요하다.

바이트 단위로 접근이 가능한 비 휘발성 메모리의 경우(e.g. MRAM, Battery-backed DRAM)와 달리 플래시 메모리는 블록 단위로만 접근이 가능하다. 본 발명이 제공하는 일 실시예에서의 트랜잭션 지원 방법은 블록 단위 기반의 읽기/쓰기가 가능한 플래시 SSD와 하드 디스크를 대상으로 트랜잭션이 처리될 수 있도록 한다.

이하, 도면들을 참조하여 본 발명의 몇몇 실시예들을 설명한다.

도 1은 본 발명의 일 실시예에 따른 플래시 캐시에서 트랜잭션을 지원하는 시스템에 대한 블록 구성도이다. 이하, 도 1을 참조하여 본 실시예에 따른 플래시 캐시에서 트랜잭션을 지원하는 시스템을 설명한다.

도 1을 참조하면, 어플리케이션은 상기 플래시 캐시에서 트랜잭션을 지원하는 시스템에서 자체 중복 쓰기 기반의 트랜잭션 쓰기 프로토콜을 사용하는 대신에 새로운 트랜잭션 API를 사용한다. 상기 트랜잭션 API를 이용하여, 복수의 캐시 블록들을 하나의 트랜잭션 단위로 일괄 처리하고, 캐싱 대상 데이터를 캐시 디바이스(Cache Device)에 일괄하여 저장한다. 트랜잭션이 종료 된다면, 상기 복수의 캐시 블록들은 일괄하여 대상 저장 장치(Source Disk)에 저장된다. 기존에는 트랜잭션이 블록 별로 처리되었던 것과는 달리, 본 실시예에서는 복수의 캐시 블록들을 일괄하여 하나의 트랜잭션 단위로 처리하고, 하나의 트랜잭션 단위로 트랜잭션에 포함되는 전체 블록들이 저장 또는 미 저장 되도록 보장한다. 상기 복수의 캐시 블록들을 일괄하여 처리하는 과정으로 인하여 불필요한 쓰기 요청 수 감소 및 트랜잭션 처리량의 증가 등의 효과가 있다. 상기 트랜잭션을 지원하는 시스템에서 TxFCache는 라이트백(Write-back) 정책과 함께 플래시 캐시의 Out-of-place 특성을 활용한 트랜잭션 쓰기 프리미티브(Primitive)를 제공한다. 상기 어플리케이션이 트랜잭션 쓰기를 사용하지 않더라도, 플래시 캐시는 In-place 업데이트를 피할 수 있다. 따라서, 어플리케이션은 여러 블록의 트랜잭션 업데이트를 보장할 수 있으며, 상기 TxFCache는 트랜잭션 쓰기로 인한 쓰기 증폭을 줄이면서 동일한 수준의 충돌 일관성을 보장할 수 있다.

상기 TxFCache는 라이트백(Write-back) 정책과 함께 플래시 캐시의 Out-of-place 특성을 활용한 트랜잭션 쓰기 프리미티브를 제공하는 트랜잭션 플래시 캐시이다. 상기 TxFCache는 캐시 블록 관리 기법(Cache Block Management), 메타 데이터 관리 기법(Metadata Management), 회복(Recovery), 라이트백(Write-back)을 이용한다. 상기 플래시 캐시에서 트랜잭션을 지원하는 시스템은, 상기 트랜잭션 API를 이용하여 하나의 트랜잭션에 포함되는 다수의 쓰기 작업에 대한 정보를 플래시 캐시 장치에 전달한다. 결과적으로 상기 TxFCache는 트랜잭션 쓰기로 인한 쓰기 증폭을 줄이면서 동일한 수준의 충돌 일관성을 보장할 수 있도록 한다.

도 2는 본 발명의 일 실시예에 따른 트랜잭션 API를 나타내는 블록 구성도이다. 이하 도 2를 참조하여 본 실시예에 따른 상기 트랜잭션 API에 대하여 설명한다.

상기 TxFCache에서 캐시 블록 관리 기법은 상기 트랜잭션 API를 이용하여 수행된다. 상기 트랜잭션 API는 tx_begin(), tx_end() 및 tx_abort()로 정의 될 수 있다. 상기 tx_begin()은 새로운 트랜잭션이 오픈 됨을 플래시 캐시 모듈에 알려주고, 해당 트랜잭션에 속하는 쓰기 작업을 수행하도록 하는 트랜잭션 시작 API이다. 상기 tx_end()는 트랜잭션이 완료되었음을 플래시 캐시 모듈에 알려주도록 하는 트랜잭션 종료 API이다. 상기 tx_abort()는 트랜잭션 쓰기 작업이 완료되기 전에 오픈 한 트랜잭션을 취소하기 위하여 플래시 캐시에 저장 된 데이터들을 무효화 시키도록 하는 트랜잭션 철회 API이다. 상기 tx_begin()과 상기 tx_end() 사이의 복수의 캐시 블록에 대한 쓰기 작업을 묶어줌으로써 하나의 트랜잭션 단위를 생성할 수 있다. 또한, 상기 tx_begin()을 이용하여 쓰기 작업을 진행하는 도중에 상기 tx_abort()를 호출하면 해당 시점까지 쓰여진 블록들은 모두 tx_begin() 이전 상태로 돌아가게 된다.

각 트랜잭션에는 OS 커널의 블록 계층에 의해 할당되고, 단조롭게 증가하는 카운터인 고유한 트랜잭션 ID(Tx_id)가 배정된다. 상기 TxFCache에 대한 각 블록 쓰기는 Tx_id와 TxFCache를 수반하여 서로 다른 트랜잭션에서 캐시 블록을 분리하고 할당한다.

도 3은 본 발명의 일 실시예에 따른 플래시 캐시 블록 관리 기법에서 각 캐시 블록의 상태도 이다. 이하 도 3을 참조하여 본 실시예에 따른 캐시 블록 관리 기법에 대해서 설명한다.

전형적인 캐시 블록 관리 기법에서는 플래시 캐시 블록은 클린(Clean), 더티(Dirty) 및 인밸리드(Invalid) 세 가지 상태로 정의하여 관리된다. 상기 클린 상태는 원본 디스크(Source disk)에서 원본 데이터를 읽어서 플래시 SSD 캐시 블록에 저장한 경우이다. 상기 더티 상태는 플래시 캐시에 캐싱된 블록만이 변경되고 아직 디스크 원본에 반영되지 않은 경우를 나타낸다. 마지막으로, 상기 인밸리드 상태는 의미있는 데이터가 들어 있지 않은 경우를 나타낸다. 기본적으로, 트랜잭션이 커밋(Commit)된 이후에는 캐시 블록들은 클린 상태 또는 더티 상태에 있을 수 있다. 캐시 미스가 발생하면, 캐시 채우기 작업은 캐시 블록의 상태를 인밸리드 상태에서 클린 상태로 변경한다. 쓰기가 되면 캐시 블록은 더티 상태로 변경된다. 더티 상태의 캐시 블록이 라이트백 된 후에는 클린 상태로 된다. 상기 전형적인 캐시 블록 관리 기법으로 인하여 트랜잭션 전반에 걸쳐 원자성(Atomicity), 지속성(Durability) 및 독립성(Isolation)을 제공할 수 있다.

본 발명의 일 실시예에 따른 캐시 블록 관리 기법에서는 상기 세 가지 상태에 있어서 커미티드(Committied) 상태 및 언커미티드(Uncommittied) 상태를 부가적으로 도입하였다.

상기 커미티드 상태는 어플리케이션이 tx_begin()을 통해 오픈한 트랜잭션을 tx_end()를 호출하여 정상적으로 종료된 상태를 나타낸다. 상기 커미티드 상태의 블록들은 시스템에 문제가 생기거나 전원이 나가는 일이 생기더라도 항상 안전하게 복구되어야 하는 블록들이다. 따라서, 커미티드 상태의 블록들에는 덮어쓰기를 허용하지 않는다. 더티 커미티드 상태의 블록들은 기존의 블록 단위로 디스크 원본에 반영하여 클린 상태로 전이시키던 것과는 달리 하나의 트랜잭션에 속하는 블록들 전체가 디스크 원본에 반영되어야 클린 커미티드 상태로 전이될 수 있다. 클린 커미티드 상태의 블록들에 대해서는 디스크 원본 블록이 존재하기 때문에 덮어쓰기를 허용한다. 상기 방식은 트랜잭션에서 원자성을 보장하기 위한 것이다.

트랜잭션이 오픈(tx_begin()) 된 후에는 모든 블록 쓰기에는 언커미티드 캐시 블록이 생성된다. 상기 언커미티드 상태는 중복 쓰기 유도에 사용된다. 더티 언커미티드 상태는 어플리케이션이 tx_begin()을 통해서 트랜잭션을 오픈 하여 업데이트가 진행되었지만, tx_end()를 통해 완료되지 않은 블록들을 나타낸다. 상기 상태의 블록들은 아직 어플리케이션이 완료시키지 않았기 때문에 tx_abort()를 통해서 명시적으로 인밸리드 상태로 되돌릴 수 있고, 시스템이 꺼지거나 하는 경우에는 자동으로 업데이트 된 내용들이 날아가게 된다.

도 4는 본 발명의 일 실시예에 따른 플래시 캐시 블록 관리 기법에서 캐시 블록 상태에 따른 상태 전이도이다. 이하 도 4를 참조하여 본 실시예에 따른 캐시 블록 관리 기법에서 캐시 블록 상태에 따른 캐시 블록의 상태 전이 과정에 대하여 설명한다.

트랜잭션 쓰기 요청이 수신이 된다(S100). 트랜잭션 쓰기 요청이 수신되면, 캐시 메모리가 해당 데이터를 가지고 있다면 캐시 히트가 발생하고, 해당 데이터가 없는 경우 다른 메모리에서 캐시 블록을 할당 받아야 하는 캐시 미스가 발생한다. 캐시 미스가 발생하면(S110), 인밸리드 상태의 캐시 블록에는 대상 데이터 쓰기 작업이 수행된다. 상기 캐시 블록은 언커미티드 상태로 된다(S120).

한편, 캐시 히트가 발생한 경우(S110), 기존 캐시 블록 상태에 따라 상기 기존 블록을 재사용 할 지 여부를 결정한다(S130). 캐시 블록이 클린 상태인 경우(S140), 상기 캐시 블록에는 대상 데이터 쓰기 작업이 수행된다(S150). 상기 캐시 블록은 언커미티드 상태로 된다. 원본 디스크에는 기존의 캐시 블록이 있으므로 In-place 업데이트가 실행 가능하다. 캐시 블록이 더티 상태인 경우(S140), 인밸리드 상태의 캐시 블록이 할당되고(S160) 상기 인밸리드 캐시 블록에 대상 데이터 쓰기 작업이 수행된다(S170). 상기 업데이트 된 캐시 블록은 플래시 캐시에만 있기 때문에 이는 out-of-place 업데이트이다. 상기 캐시 블록은 언커미티드 상태로 된다.

상기 캐시 블록이 언커미티드 상태인 경우, 두 가지 경우가 가능하다. 기존 캐시 블록에 연관된 Tx_id가 들어오는 갱신된 Tx_id와 동일한 경우, 기존 블록이 업데이트 된다. 만약 상기 연관 Tx_id와 갱신된 Tx_id가 다른 경우, Tx_id가 높은 트랜잭션이 철회된다. 이는 동일한 논리적 블록에 엑세스하는 트랜잭션 사이의 격리를 제공하기 위함이다. 상기 두 가지 경우 모두 중복 쓰기를 생성하지 않는다.

tx_abort()가 호출되면 트랜잭션과 연관된 캐시 블록이 무효화 된다. 업데이트 프로토콜이 항상 플래시 캐시 또는 원본 디스크에 있는 원래 캐시 블록을 보존하기 때문에 미해결 트랜잭션의 원자성이 유지 될 수 있다. 또한 원래 캐시 블록의 지속성도 보존된다.

tx_end()가 호출되면 해당 트랜잭션은 커미티드 상태로 된다. 커밋(commit) 절차와 상기 커밋 절차와 연관된 메모리 및 플래시 상의 캐시 메타 데이터에 대해서는 하기에서 설명하도록 한다.

도 5 내지 도 7은 트랜잭션 커밋 절차를 설명하기 위한 도면이다. 도 5 내지 도 7을 참조하여 커밋 절차에 대하여 자세히 설명한다.

상기 TxFCache의 커밋 절차를 설명하기 위하여 우선 TxFCache의 메타 데이터(캐시 인덱스) 구조를 설명한다. 상기 라이트백 플래시 캐시에서 블록 공간은 메타 데이터 영역과 데이터 블록의 두 영역으로 나누어 진다. 메타 데이터 영역은 디스크 블록에서 캐시 블록으로의 매핑 정보와 각 캐시 블록의 상태를 저장한다. 반면, 데이터 블록 영역은 실제 데이터를 저장한다.

플래시 캐시가 시스템에서 사용되는 경우, 메타 데이터는 메모리에 캐싱되며, 캐시 조회를 가속화하기 위해 플래시 상의 레이아웃과 다른 구조를 형성한다. 캐시 메타 데이터의 인 메모리(in-memory) 레이아웃은 플래시 캐시 구현에 따라 다를 수 있지만 간단한 배열 기반 구조인 단일 배열 구조를 사용한다. 배열의 각 요소에는 디스크 블록이 캐시 된 매핑 정보와 캐시 블록의 상태가 있다. 상기 캐시 블록 관리 기법에서 설명한 바와 같이 캐시 상태가 변경될 때 인 메모리 메타 데이터가 수정된다.

인 메모리 메타 데이터와는 달리, 플래시 상의 메타 데이터는 돌발적인 충돌이나 정전에 대해 안정적이고 일관성 있게 만들기 위해 신중하게 설계되어야 한다. 다중 메타 데이터 블록을 작성하는 것이 원자적으로 수행될 수 없기 때문에 복잡한 매핑 배열 구조는 부적절하다. 메타 데이터 블록을 업데이트 하는 도중에 충돌이 발생하면 메타 데이터 블록의 일관성이 손상될 수 있다.

도 5는 메타 데이터 로그에 관한 구조를 설명하기 위한 도면이다.

도 5에서는 플래시 상의 메타 데이터를 위해 로그 구조화 된 디자인을 나타낸다. 상기 캐시 블록의 메타 데이터 변경 사항이 로그에 기록되고 트랜잭션이 커밋 될 때 플래시 상의 메타 데이터 영역에 로그가 추가된다. 이로 인하여 상기 캐시 블록의 메타 데이터 변화에 대한 로그가 원자적으로 저장 될 수 있다. 또한, 메타 데이터 쓰기 중 시스템 장애가 발생하면 로그가 삭제되고 캐시 상태는 이전의 일관된 상태로 롤백(Rollback) 될 수 있다. 상기 메타 데이터 로그가 미디어에 완전히 기록되면 트랜잭션은 안전하게 커밋되고 변경된 사항은 지속성이 유지된다. 이를 위한 상기 메타 데이터의 로그 구조에는 log_header, log_footer 및 log_entry의 구성요소가 있다.

상기 log_header, log_footer 및 log_entry에 대해 더 자세히 설명한다. 상기 log_header는 log_type(로그 유형), log_id(로그 ID) 및 nr_entries(로그 엔트리의 개수)의 분야가 포함된다. 상기 메타 데이터 변경은 커밋에서 발생했을 뿐만 아니라 라이트백이 캐시 블록의 상태를 변경하여 쓰기 때문에 다시 캐시 블록 대체와 라이트백 단계에서 발생할 수 있다. 상기 log_type은 메타 데이터 로그가 만들어지는 컨텍스트를 나타내므로 커밋 또는 라이트백과 같은 두 가지 상태 중 하나를 가질 수 있다. 상기 TxFCache는 상기 log_id가 해당 메타 데이터 로그의 타임 스탬프를 나타내므로 상기 log_id에 단조롭게 증가하는 카운터를 할당한다. 상기 nr_entries는 상기 log_header 및 상기 log_footer를 포함하는 항목 수를 의미한다. 상기 log_footer는 상기 log_header와 동일한 내용을 가지며 메타 데이터 로그의 끝에 위치한다. 상기 TxFCache는 log_header와 log_footer를 사용하여 메타 데이터 로그 쓰기가 성공적으로 완료되었는지 확인한다. 상기 log_entry에는 캐시 블록의 메타 데이터가 포함되므로 캐시 블록 번호(캐시 색인)와 원본 디스크 블록 번호가 포함된다.

경우에 따라 트랜잭션 커밋에 추가 메타 데이터 변경이 포함되는 경우가 있다. 예를 들어, 이전에 커밋 된 캐시 블록이 새롭게 커밋 된 트랜잭션에 의해 무효화되는 경우 일관된 캐시 메타 데이터를 재구성하기 위해 그러한 무효화 로그가 필요하기 때문에 변경된 상태는 지속성 있게 저장되어야 한다. 상기 TxFCache는 메타 데이터 변경을 메타 데이터 로그로 압축하여 트랜잭션의 커밋에서 메타 데이터 변경 사항의 데이터를 만든다. 커밋과 무효화 로그를 구분하기 위해 log_entry에 캐시 블록 번호의 MSB(most significant byte)를 예약한다.

도 6는 트랜잭션 커밋 절차에서 메타 데이터 로거 및 플래시 상의 메타 데이터를 설명하기 위한 도면이다. 이하 도 6를 참조하여 메타 데이터 로거 및 플래시 상의 메타 데이터를 자세히 설명한다.

도 6를 참조하면, 상기 TxFCache는 원형 대기열 형태로 플래시 상의 메타 데이터 영역을 관리하며, 메타 데이터의 메모리 레이아웃 구조는 단일 배열 구조로 한다. 메타 데이터 로그는 메타 데이터 쓰기 순서대로 추가된다. 트랜잭션 크기에 따라 메타 데이터 로그는 하나 이상의 블록을 차지한다. 메타 데이터 로거는 결과 블록을 메타 데이터 로그에 할당한다.

상기 메타 데이터 로그가 플래시 메타 데이터 영역에 계속 추가되기 때문에 플래시 메타 데이터 영역의 빈 블록을 모두 사용할 수 있다. 이를 처리하기 위해 TxFCache는 플래시 상의 메타 데이터 영역의 빈 블록을 확보하기 위한 압축 스레드(thread)를 만든다. 상기 메타데이터 로그의 수가 사전에 정의된 임계값(예: 플래시 메타 데이터 영역 크기의 50%)에 도달하면 압축 스레드가 활성화되어 사전에 정의 된 수의 메타 데이터 로그를 검색한다. 다음으로, 압축 스레드는 검색된 메타 데이터 로그를 log_ids와 비교하여 동일한 캐시 색인에 대한 log_entry 중에서 최신 log_entry를 선택하여 compact_log(컴팩트 로그)라는 단일 메타 데이터 로그에 병합한다. 마지막으로 압축 스레드는 검사한 메타 데이터로 상기 최신 log_id를 compact_log에 할당하고 compact_log를 큐의 끝에 추가한다. 메타 데이터 로거는 플래시 상의 메타 데이터 영역의 compact_logs에 대한 캐시 메타 데이터 영역을 예약하고 초기화 시간에 해당 크기를 구성할 수 있다. Compact_logs의 수가 증가하면 압축 스레드는 이전의 compact_log를 새로운 compact_log로 병합한다.

안전한 크래시 리커버리(Recovery)를 위해서는 플래시 SSD에 저장되는 캐시 메타 데이터를 안전하고 일관되게 관리하는 것이 중요하다. 기존의 단순한 플래시 캐시 메타 데이터 저장 방식은 각 캐시 블록 별로 해당하는 캐시 메타 데이터의 원본이 존재하여 캐시 블록의 상태가 변경되는 경우에 해당 캐시 메타 데이터 블록에 바로 반영을 한다. 하지만, 이러한 방식을 사용하게 되면 하나의 트랜잭션에 포함되는 캐시 메타 데이터 블록들의 업데이트 작업에 대한 원자성을 보장할 수 없기 때문에 기존의 캐시 메타 데이터 관리 방식 대신 도 6과 같은 메타 데이터 로깅 방식을 사용한다.

상기 로깅 방식에서는 캐시 메타 데이터를 해당 캐시 블록의 상태가 변경되는 경우에 플래시 SSD의 지정된 영역에 로그 형태로 추가(append)하는 방식으로 저장된다. 원본에 in-place 업데이트 하는 방식이 아니기 때문에 로그가 계속 쌓여 지정된 영역의 공간을 다 써버리는 문제가 발생할 수 있다. 상기 문제를 해결하기 위해서 지정된 영역의 공간이 어느 수준 이상 차게 되면, 컴팩션 스레드를 만들어서 쌓여있는 로그들을 스캔하여 동일한 캐시 블록에 대한 로그들은 가장 최신 버전만을 남겨두고 모두 삭제하는 작업을 수행한다. 상기 작업을 통해서 캐시 메타 데이터 로그 공간을 지속적으로 확보할 수 있다.

미해결 트랜잭션의 캐시 블록 메타 데이터는 블록 쓰기 완료 시 즉시 저장될 필요가 없다. 블록이 최종적으로 커밋 될 것인지 여부는 알 수 없다. 따라서, 상기 TxFCache는 관련 트랜잭션이 커밋 될 때까지 캐시 메타 데이터 쓰기를 지연시킨다. 커밋될 때까지 상기 TxFCache는 미해결 트랜잭션의 메타 데이터 변경 사항 및 종속성을 수집한다. 커밋할 때 상기 TxFCache는 수집된 종속성을 기반으로 오래된 캐시 블록을 무효화(invalidated)하고 트랜잭션의 캐시 블록을 커밋된 블록으로 표시한다. 트랜잭션의 캐시 블록 상태가 성공적으로 변경된 후 상기 TxFCache는 메타 데이터 변경 사항 요약을 메타 데이터 로거에 제출한다. 결과적으로, 상기 TxFCache는 커밋 시점에 트랜잭션의 수명 기간 동안 유도된 다수의 메타 데이터 업데이트를 단일 메타 데이터 업데이트로 흡수한다.

도 7은 본 발명의 일 실시예에 따른 트랜잭션 커밋 절차의 예를 나타내는 도면이다. 도 7을 참조하여 커밋 절차를 설명한다.

도 7에서는 두 개의 트랜잭션을 커밋 하였다. 각 트랜잭션은 두 개의 데이터 블록으로 구성된다. 우선 도 7에서 (a)단계에 대해서 설명한다. 오래된 원본 블록이 무효화되고(A와 B로 표시됨) 가장 최근의 블록이 캐시에 더티 상태로 (A'와 B'로 표시됨) 된다. 어플리케이션이 tx_begin()을 통해 하나의 트랜잭션을 오픈하여 A, B 두 블록에 대한 쓰기를 진행하면(아직 언커미티드 상태) 이전 트랜잭션에서 수정한 A', B' 블록에 대한 디스크 원본 반영 작업이 완료되지 않은 상태(더티 커밋 상태)이기 때문에 덮어쓰기를 수행하지 못하고 새로운 캐시 블록 A", B"을 할당 받는다.

다음으로 (b)단계에 대해서 설명한다. 이제 작업은 블록 A' 및 B'를 업데이트 하려고 한다. 블록 쓰기 요청을 제출하기 전에 태스크는 tx_begin()을 호출하여 새 트랜잭션의 시작을 알린다. 이후에, 다음 태스크는 블록 쓰기 요청을 제출한다. 상기 TxFCache는 블록 쓰기 요청을 후킹하고 일치하는 캐시 블록을 찾기 위해 매핑 테이블을 확인한다. 일치 된 블록 A'와 B'가 커밋 된 블록이기 때문에, 상기 TxFCache는 새로운 캐시 블록 A"와 B"에 할당하고 쓰기를 수행한다. 또한 상기 TxFCache는 커밋되지 않은 블록의 커밋 된 블록 간의 관계를 기록한다. 따라서 A'와 B'는 각각 A"와 B"에 연결된다. 이러한 관계는 새 블록이 커밋 될 때 오래된 커밋 된 블록을 찾고 무효화하는 데 사용된다. 블록 갱신 완료 후, 태스크는 tx_end()를 호출하여 두 개의 블록 갱신 사항을 확약한다. 커밋 절차 중에 상기 TxFCache는 이전 버전의 블록(A'와 B')을 무효화하고 새 블록(A"및 B") 및 무효화 된 블록(A'및 B')을 표시한다. 메타 데이터 로거는 SSD에 메타 데이터 로그를 생성하고 기록한 다음 상기 TxFCache가 어플리케이션에 커밋 완료를 알린다. 어플리케이션이 tx_end()를 통해서 트랜잭션 커밋을 요청하면 현재 트랜잭션에 의해 변경된 A", B"블록은 더티 커미티드 상태로 바뀌고, A' 와 B' 캐시 블록은 더 이상 최신본이 아니기 때문에 무효화 된다. 이 때, 각 캐시 블록들의 상태가 바뀌었기 때문에 해당하는 내용들을 앞서 설명한 메타 데이터 로그 형태로 지정된 영역에 기록한다.

마지막으로 (c)단계에 대해서 설명한다. 커밋 된 캐시 블록(A" 및 B")은 다시 쓰기 정책에 따라 원본 디스크에 다시 기록된다. 이것은 또한 캐시 블록 상태가 변경되기 때문에 메타 데이터 로그의 쓰기를 수반한다. 디스크의 데이터 원본에 반영하는 작업을 수행하여 A" 및 B" 블록은 클린 커미티드 상태로 바뀌게 되고, 해당 내용을 메타 데이터 로그로 기록한다.

다음은, 캐시 블록 대체 및 라이트백에 대해서 설명한다.

캐시 미스가 발생하면 상기 TxFCache는 수신된 요청에 대한 캐시 블록을 할당해야 한다. 여유 공간이 없으면 캐시 블록 대체가 발생해야 한다. 상기 캐시 블록 대체 과정은 다음 순서로 희생 캐시 블록을 선택한다. 첫째, 무효화(invalidated) 된 캐시 블록을 회수하고, 상기 무효화 된 캐시 블록을 새로운 캐시 블록 할당에 사용한다. 만약, 무효화 된 캐시 블록이 없으면 클린 상태의 캐시 블록이 대체 과정에서 할당된다. 클린 캐시 블록도 없는 경우, 상기 회수는 캐시 블록이 라이트백 되어 클린 캐시 블록을 가질 때까지 대기한다. 임의의 잘 알려진 대체 정책은 캐시 블록 대체와 결합된다.

더티 상태의 캐시 블록과 언커미티드 상태의 캐시 블록은 대체의 대상이 아니다. 상기 두 유형의 블록 모두 최신 데이터를 저장하는 유일한 블록이다. 따라서, 두 블록 모두 지속성을 위해 보존된다.

언커미티드 캐시 블록은 연관된 트랜잭션이 커밋 될 때 더티 캐시 블록이 된다. 더티 상태의 캐시 블록은 TxFCache의 라이트백 정책에 의해 원본 디스크에 다시 기록된다.

상기 TxFCache는 더티 상태의 캐시 블록의 비동기적 라이트백을 수행하는 전용 라이트백 스레드(thread)를 생성한다. 더티 상태의 캐시 블록의 개수가 사전에 정의된 양보다 많다면, 스레드가 발생하여 더티 상태의 페이지를 원본 디스크에 저장한다. 쓰기 저장이 완료되면 적절한 메타 데이터 로그가 추가되어 캐시 블록이 원본 디스크와 동기화 되었음을 나타낸다. 상기 메타 데이터 업데이트는 캐시 블록이 원본 디스크에 데이터 복사본이 있는지 여부에 따라 쓰기의 중복이 발생하기 때문에 중요하다.

다음은 리커버리(Recovery)에 대해서 설명한다.

시스템이 장애로부터 복구 된 후, 상기 TxFCache는 인 메모리 캐시 인덱스(캐시 메타 데이터)를 복구하려고 시도한다. 이는 저장된 메타 데이터 로그가 변경된 메타 데이터의 기록이기 때문이다. 가장 중요한 조건은 모든 메타 데이터 로그의 재생 시퀀스가 단조롭게 증가하는 log_id(로그 ID)의 시퀀스라는 것이다.

플래시 메타 데이터 영역은 원형 대기열 이므로, 상기 TxFCache는 재생을 수행하기 전에 어떤 메타 데이터 로그가 대기열의 헤드인지 알 수 없다. 따라서, 상기 TxFCache는 먼저 모든 메타 데이터 로그를 검색하여 가장 오래된 메타 데이터 로그를 찾는다. 상기 TxFCache가 가장 오래된 메타 데이터 로그를 찾으면 상기 TxFCache는 발견된 위치에서 원형 대기열를 통해 플래시 캐시 메타 데이터 영역을 스캔하기 시작한다.

상기 메타 데이터 로그를 재생할 때마다, 상기 TxFCache는 header 항목과 footer 항목을 비교하여 로그의 무결성을 검사한다. 로그가 유효하면, 상기 TxFCache는 예상되는 로그 ID를 가진 md_log(메타 데이터 로그)를 확인한다. 상기 md_log에 예상되는 로그 ID가 있으면 상기 TxFCache는 log_entrys에서 매핑을 추출한다. 다음으로, 상기 TxFCache는 md_log의 로그 ID가 있는 매핑을 메모리의 매핑 테이블에 할당한다. 매핑 테이블에 기 할당된 매핑이 있으면, 상기 TxFCache는 매핑의 로그 ID들을 비교한 다음 더 새로운 로그 ID를 선택한다. 상기 md_log가 유효하지 않거나 예상된 log_id가 없는 경우, 상기 TxFCache는 스캐닝 단계를 종료한다.

상기 스캐닝 단계가 종료되면, 상기 TxFCache는 원본 디스크의 동일한 위치를 가리키는 매핑 테이블의 중복 매핑을 찾는다. 중복 매핑이 있는 경우 상기 TxFCache는 중복 매핑 중 가장 새로운 매핑을 유지한다. 이후에, 상기 TxFCache는 기존의 캐시 블록을 복구하고 리커버리를 완료한다.

플래시 상의 메타 데이터 영역에 compact_logs가 있는 경우, 상기 TxFCache는 먼저 compact_logs를 재생한 다음 메타 데이터 로그를 재생한다. compact_logs의 재생 프로세스 세부 정보는 메타 데이터 재생의 세부 정보와 동일하다.

도 8 내지 도 10은 본 발명의 일 실시예에 따른 TxFCache의 트랜잭션 API를 활용한 경우 실험 결과를 나타내는 도면이다.

도 8을 참조하면, 파일시스템 수준에서 중복쓰기 기반 트랜잭션을 제거하고 상기 TxFCache의 트랜잭션 API를 활용한 경우 플래시 SSD로의 쓰기 횟수를 비교하였다. 파일시스템 설정에서 데이터는 파일시스템의 데이터 수준에서의 일관성을 보장하는 것으로 가장 안전한 설정이지만 모든 데이터에 대해서 중복 쓰기를 수행하기 때문에 성능상으로 가장 안 좋은 설정이다. Ordered는 파일시스템의 메타 데이터만을 중복 쓰기 하여 파일시스템 메타 데이터 수준에서의 일관성만을 보장하는 설정이고, Off는 중복 쓰기 기반 트랜잭션을 비활성화하여 성능상으로는 가장 좋을 수 있는 설정이지만 파일시스템 전체의 일관성이 깨져서 데이터 복구가 불가능해질 수 있는 설정이다. 상기 TxFCache는 파일시스템에 제안하는 기술을 적용하여 Data 설정과 동일한 가장 높은 수준의 데이터 안정성을 보장하면서도 파일시스템 수준에서의 중복 쓰기를 제거한 설정이다. 아래의 표 1은 도 8의 실험에서 작업 시간을 나타낸다.

Configuration	Data-intensive	Metadata-intensive
Data	261.71.s	210.58s
Ordered	272.87s	216.18s
Off	181.67s	41.00s
TxFCache	125.41s	39.35s

도 9를 참조하면, 전세계적으로 가장 많이 쓰이고 있는 오픈소스 데이터베이스 서버인 MySQL과 호환되는 MariaDB에 TxFCache의 트랜잭션 API를 적용하여 LinkBench와 SysBench 벤치마크를 사용하여 성능 개선 효과를 측정한 그래프를 나타낸 도면이다. MariaDB는 기본적으로 데이터가 깨지는 문제가 발생하지 않도록 double-write-buffer라는 중복쓰기 방식을 사용하고 있다. 상기 TxFCache를 적용한 경우에는 이러한 MariaDB 수준에서의 중복쓰기를 비활성화하는 대신 제공하는 트랜잭션 API를 사용하도록 한다.

도 10은 모바일부터 데스크탑까지 다양한 환경에서 애플리케이션의 데이터베이스 라이브러리로 활용되고 있는 SQLite의 성능 개선 효과를 나타낸 그래프를 나타낸 도면이다. 도 10을 참조하면, Facebook, Gmail 등의 모바일 앱에서의 사용 시나리오에 대한 수행 시간을 측정하는 방식으로 진행하였고, RBJ(Roll Back Journaling)은 SQLite에서 가장 단순한 형태의 트랜잭션 지원 기법이지만 많은 양의 중복쓰기를 유발한다. WAL(Write Ahead Logging)은 SQLite에서 RBJ를 개선하기 위해 로그 형식의 중복 쓰기만을 수행하여 중복쓰기의 양을 줄인 기법이다. OFF는 SQLite의 중복쓰기 기반 트랜잭션 지원을 비활성화하여 가장 높은 성능을 제공하지만 데이터의 안정성은 보장하지 않는 설정이다. 상기 TxFCache는 제안하는 기술을 SQLite에 적용하여 데이터베이스 수준에서의 중복쓰기를 제거하면서도 데이터의 안정성을 보장하는 설정이다.

이상 첨부된 도면을 참조하여 본 발명의 실시예들을 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다.

Claims (9)

1. 플래시 캐시에서 어플리케이션이 요청한 쓰기 트랜잭션을 복수의 캐시 블록들로 일괄 처리하기 위한 트랜잭션 지원 방법에 있어서,
   상기 어플리케이션에 의하여 호출된 트랜잭션 시작 API가 호출된 때부터 상기 어플리케이션에 의하여 호출된 트랜잭션 종료 API가 호출된 때까지의 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 단계;
   상기 트랜잭션 종료 API의 호출에 응답하여, 상기 복수의 캐시 블록의 상태를 커밋 상태로 설정하는 단계; 및
   상기 트랜잭션 종료 API의 호출 이후에, 커밋 상태로 설정된 상기 복수의 캐시 블록을 대상 저장 장치에 저장하는 단계를 포함하되,
   상기 캐싱 대상 데이터를 복수의 캐시 블록에 저장하는 단계는,
   제1 캐싱 대상 데이터의 캐시 히트 판정에 응답하여, 히트된 제1 캐시 블록의 상태를 확인하는 단계;
   상기 제1 캐시 블록의 상태가 더티 상태라는 판정에 응답하여, 인밸리드 상태의 신규 캐시 블록을 할당하는 단계; 및
   상기 제1 캐싱 대상 데이터를 상기 신규 캐시 블록에 저장하는 단계를 포함하는,
   트랜잭션 지원 방법.
2. 제 1항에 있어서,
   상기 트랜잭션 종료 API가 호출되기 이전에, 상기 어플리케이션에 의하여 트랜잭션 철회 API가 호출됨에 응답하여, 상기 쓰기 트랜잭션과 연관된 캐시 블록을 일괄하여 무효화하는 단계를 더 포함하는,
   트랜잭션 지원 방법.
3. 제 1항에 있어서,
   상기 캐싱 대상 데이터를 상기 복수의 캐시 블록에 저장하는 단계는,
   제2 캐싱 대상 데이터가 저장될 제2 캐시 블록을 결정하는 단계;
   상기 제2 캐시 블록에 기 설정된 트랜잭션 ID를 식별하는 단계; 및
   상기 쓰기 트랜잭션의 ID와 상기 기 설정된 트랜잭션 ID가 동일한 경우, 상기 제2 캐싱 대상 데이터로 상기 제2 캐시 블록을 업데이트하는 단계를 더 포함하는,
   트랜잭션 지원 방법.
4. 제 1항에 있어서,
   상기 캐싱 대상 데이터를 상기 복수의 캐시 블록에 저장하는 단계는,
   제2 캐싱 대상 데이터가 저장될 제2 캐시 블록을 결정하는 단계;
   상기 제2 캐시 블록에 기 설정된 트랜잭션 ID를 식별하는 단계; 및
   상기 쓰기 트랜잭션의 ID와 상기 기 설정된 트랜잭션 ID가 상이한 경우, 상기 쓰기 트랜잭션을 철회하는 단계를 더 포함하는,
   트랜잭션 지원 방법.
5. 제 1항에 있어서,
   상기 캐시 블록에 대한 메타 데이터의 메모리 레이아웃의 구조는,
   단일 배열 구조로 하는,
   트랜잭션 지원 방법.
6. 제 5항에 있어서,
   상기 메타 데이터 영역의 빈 블록을 확보하기 위해 압축 스레드를 만드는 단계;
   상기 압축 스레드를 병합하는 위치에 대한 정보가 포함된 로그가 추가 되는 단계; 및
   상기 압축 스레드를 컴팩트 로그에 추가하는 단계;
   를 더 포함하는,
   트랜잭션 지원 방법.
7. 제 1항에 있어서,
   상기 캐싱 대상 데이터를 상기 복수의 캐시 블록에 저장하는 단계는,
   제2 캐싱 대상 데이터의 캐시 미스 판정에 응답하여, 인밸리드 상태의 제2 캐시 블록이 존재하는지 여부를 판정하는 단계;
   상기 제2 캐시 블록이 존재한다는 판정에 응답하여, 상기 제2 캐시 블록을 상기 제2 캐싱 대상 데이터의 캐시 블록으로 할당하는 단계; 및
   상기 제2 캐시 블록이 존재하지 않는다는 판정에 응답하여, 클린 상태의 제3 캐시 블록을 상기 제2 캐싱 대상 데이터의 캐시 블록으로 할당하는 단계를 더 포함하는,
   트랜잭션 지원 방법.
8. 삭제
9. 삭제

Images