KR20170129959A - 인 플레이스 스냅샷들 - Google Patents

Abstract

데이터베이스 시스템은 분산 저장 시스템에 복수의 로그 레코드를 유지할 수 있다. 복수의 로그 레코드의 각각은 데이터 페이지에 대한 각각의 변경과 연관될 수 있다. 스냅샷에 대응하는 상태의 시점에서 데이터를 판독하기 위해 사용 가능한 스냅샷이 생성될 수 있다. 스냅샷을 생성하는 것은 로그 레코드들 중 특정한 로그 레코드의 특정한 로그 식별자를 가리키는 메타데이터를 생성하는 것을 포함할 수 있다. 스냅샷을 생성하는 것은 데이터의 추가적인 판독, 복사, 또는 기록 없이 수행될 수 있다.

Description

인 플레이스 스냅샷들{IN PLACE SNAPSHOTS}

소프트웨어 스택의 다양한 구성요소들의 분산은 일부 경우들에서 내 고장력(예를 들어, 복제를 통해), 고 지속성, 및 저가의 해결책들(예를 들어, 보다 적은 대형, 고가의 구성요소들 대신 많은 소형, 저가의 구성요소들을 통해) 제공(또는 지원)할 수 있다. 그러나, 데이터베이스는 역사적으로 분산하기가 제일 힘든 소프트웨어 스택의 구성요소들 사이에 있어왔다. 예를 들어, 그것들이 제공할 것으로 예상되는 소위 ACID 속성들(예를 들어, 원자성, 일관성, 분리성, 및 지속성)을 여전히 보장하면서 데이터베이스들을 분산하기가 어려울 수 있다.

대부분 기존의 관계 데이터베이스들이 분산되지 않지만, 일부 기존의 데이터베이스들은 두 개의 공통적인 모델들: "비공유" 모델, 및 "공유 디스크" 모델 중 하나를 사용하여 "스케일링 아웃(scale out)"된다(단지 보다 대형의 모놀리식 시스템을 채용함으로써 "스케일링 업(scale up)"되는 것과 대조적으로). 일반적으로, "비공유" 모델에서, 수신된 질의들은 데이터베이스 샤드들(database shards)(그 각각이 질의의 구성요소를 포함하는)로 분해되고, 이들 샤드들은 질의 절차를 위해 상이한 컴퓨트 노드들로 송신되며, 그것들이 리턴되기 전에 결과들이 수집되고 종합된다. 일반적으로, "공유 디스크" 모델에서, 클러스터에서의 모든 컴퓨트 노드는 동일한 기본 데이터에 액세스한다. 이 모델을 채용하는 시스템들에서, 캐시 일관성을 관리하기 위한 세심한 주의가 취해져야 한다. 이들 모델들 양자에서, 대형, 모놀리식 데이터베이스는 다수의 노드(독립형 데이터베이스 인스턴스의 모든 기능을 포함하는) 상에 복제되고, "글루(glue)" 로직이 그것들을 함께 스티칭(stitching)하기 위해 추가된다. 예를 들어, "비공유" 모델에서, 글루 로직은 질의들을 재분할하고, 다수의 컴퓨트 노트에 그것들을 송신한 후, 결과들을 결합하는 디스패처(dispatcher)의 기능을 제공할 수 있다. "공유 디스크" 모델에서, 글루 로직은 다수의 노드의 캐시들을 함께 퓨징(fusing)하는(예를 들어, 캐싱 계층에서 일관성을 관리하기 위해) 역할을 할 수 있다. 이들 "비공유" 및 "공유 디스크" 데이터베이스 시스템들은 배치하기에 고가이고 유지하기에 복잡할 수 있고, 많은 데이터베이스 사용 경우들을 맹신할 수 있다.

도 1은 일 실시예에 따라, 데이터베이스 소프트웨어 스택의 다양한 구성요소들을 예시하는 블록도이다.
도 2는 일부 실시예들에 따라, 웹 서비스들 기반의 데이터베이스 서비스를 구현하도록 구성될 수 있는 서비스 시스템 아키텍처를 예시하는 블록도이다.
도 3은 일 실시예에 따라, 데이터베이스 엔진 및 개별 분산 데이터베이스 저장 서비스를 포함하는 데이터베이스 시스템의 다양한 구성요소들을 예시하는 블록도이다.
도 4는 일 실시예에 따라, 분산 데이터베이스-최적화 저장 시스템을 예시하는 블록도이다.
도 5는 일 실시예에 따라, 데이터베이스 시스템에서의 개별 분산 데이터베이스-최적화 저장 시스템의 사용을 예시하는 블록도이다.
도 6은 일 실시예에 따라, 데이터 및 메타데이터가 분산 데이터베이스-최적화 저장 시스템의 소정의 노드에 저장될 수 있는 방법을 예시하는 블록도이다.
도 7은 일 실시예에 따라, 데이터베이스 볼륨의 예시적인 구성을 예시하는 블록도이다.
도 8은 데이터베이스 서비스에서 스냅샷을 생성 및/또는 사용하기 위한 방법의 일 실시예를 예시하는 흐름도이다.
도 9는 웹 서비스-기반 데이터베이스 서비스에서 로그 레코드들을 조작하기 위한 방법의 일 실시예를 예시하는 흐름도이다.
도 10은 다양한 실시예들에 따라, 데이터베이스 엔진 및 개별 분산 데이터베이스 저장 서비스를 포함하는 데이터베이스 시스템의 적어도 일부를 구현하도록 구성되는 컴퓨터 시스템을 예시하는 블록도이다.
실시예들이 몇몇 실시예들 및 예시적인 도면들을 위한 예로서 본 출원에 설명되지만, 당해 기술분야의 통상의 기술자들은 실시예들이 설명된 실시예들 또는 도면들에 제한되지 않는다는 것을 인식할 것이다. 도면들 및 그것들에 대한 상세한 설명이 실시예들을 개시된 특정한 형태로 제한하는 것으로 의도되지 않고, 이와 반대로, 첨부된 청구항들에 의해 정의된 바와 같은 사상 및 범위 내에 들어가는 모든 변형물들, 등가물들, 및 대안물들을 망라하도록 의도된다는 것이 이해되어야 한다. 본 출원에 사용된 머릿말들은 본 설명 또는 청구항들의 범위를 제한하는 것으로사용되도록 의도되지 않으며 단지 구조상의 목적들을 위함이다. 본 출원 전체에 걸쳐 사용된 바와 같이, 단어 "할 수 있다"는 필수적 의미(즉, 해야한다의 의미)가 아니라, 관대한 의미(즉, 가능성을 갖는 의미)로 사용된다. 단어들 "포함하다", "포함하는", 및 "포함한다"는 개방형 관계들을 나타내고 그에 따라 제한되지는 않으나 포함하는 것을 의미한다. 이와 유사하게, 단어들 "가진다", "갖는", 및 "갖는다"도 또한 개방형 관계들을 나타내고, 그에 따라 제한되지는 않으나 포함하는 것을 의미한다. 본 출원에 사용되는 바와 같은 단어들 "제1", "제2", "제3" 등은 그러한 순서가 명백히 다르게 표시되지 않는 한 그것들이 선행하는, 그리고 임의의 유형의 순서(예를 들어, 공간적, 시간적, 논리적 등)를 내포하지 않는 명사들을 위한 라벨들로서 사용된다.
다양한 구성요소들은 작업 또는 작업들을 수행"하도록 구성되는"과 같이 설명될 수 있다. 그러한 맥락들에서, "하도록 구성되는"은 일반적으로 동작 동안 작업 또는 작업들을 수행하는 "구조를 갖는 것"을 의미하는 광범위한 열거이다. 이와 같이, 구성요소는 구성요소가 현재 해당 작업을 수행하고 있지 않을 때조차 작업을 수행하도록 구성될 수 있다(예를 들어, 컴퓨터 시스템은 동작들이 현재 수행되고 있지 않을 때조차 동작들을 수행하도록 구성될 수 있다). 일부 맥락들에서, "하도록 구성되는"은 일반적으로 동작 동안 작업 또는 작업들을 수행하는 "회로를 갖는 것"을 의미하는 구조의 광범위한 열거일 수 있다. 이와 같이, 구성요소는 구성요소가 현재 작업 중이지 않을 때조차 작업을 수행하도록 구성될 수 있다. 일반적으로, "하도록 구성되는"에 대응하는 구조를 형성하는 회로는 하드웨어 회로들을 포함할 수 있다.
다양한 구성요소들은 설명에서 편의를 위해, 작업 또는 작업들을 수행하는 것으로 설명될 수 있다. 그러한 설명들은 절 "하도록 구성되는"을 포함하는 것으로 해석되어야 한다. 하나 이상의 작업을 수행하도록 구성되는 구성요소를 나열하는 것은 명확하게 해당 구성요소를 위한 35 U.S.C. § 112, 문단 6, 해석을 적용하도록 의도되지 않는다.
"~에 기초하여". 본 출원에서 사용되는 바와 같이, 이 용어는 결정에 영향을 미치는 하나 이상의 요인을 설명하는데 사용된다. 이 용어는 결정에 영향을 미칠 수 있는 추가적인 요인들을 배제하지 않는다. 즉, 결정은 단지 그러한 요인들에 기초하거나, 또는 적어도 부분적으로, 그러한 요인들에 기초할 수 있다. 절 "B에 기초하여 A를 결정한다"를 고려하자. B가 A의 결정에 영향을 미치는 요인일 수 있지만, 그러한 절은 또한 C에 기초하는 것으로부터 A를 결정하는 것을 배제하지 않는다. 다른 인스턴스들에서, A는 단지 B에 기초하여 결정될 수 있다.
본 발명의 범위는 그것이 본 출원에서 다뤄지는 문제들 중 임의의 문제 또는 모든 문제를 완화하는지 여부에 관계없이, 본 출원에 설명되는 피처들 중 임의의 피처 또는 그것들의 조합(명백하게 또는 함축적으로), 또는 그것들의 임의의 일반화를 포함한다. 따라서, 새로운 청구항들이 피처들의 임의의 그러한 조합을 위해 본 출원(또는 이에 대한 우선권을 주장하는 출원)의 절차가 진행되는 동안 만들어질 수 있다. 특히, 첨부된 청구항들을 참조하여, 종속 청구항들에서의 피처들은 독립 청구항들의 피처들과 조합될 수 있고 각각의 독립 청구항들에서의 피처들은 임의의 적절한 방식으로 조합될 수 있고 단지 첨부된 청구항들에서 열거되는 특정한 조합들로 조합되는 것은 아닐 수 있다.

스냅샷 생성의 다양한 실시예들이 개시된다. 본 실시예들 중 다양한 실시예들은 복수의 로그 레코드를 유지하는 데이터베이스 서비스의 분산 저장 시스템을 포함할 수 있다. 로그 레코드들은 데이터베이스 서비스에 의해 저장되는 데이터에 대한 각각의 변경들과 연관될 수 있다. 본 실시예들 중 다양한 실시예들은 스냅샷에 대응하는 상태의 시점에서 데이터를 판독하기 위해 사용 가능한 스냅샷을 생성하는 분산 저장 시스템을 포함할 수 있다. 스냅샷을 생성하는 것은 로그 레코드들 중 특정한 로그 레코드의 특정한 로그 식별자(예를 들어, 로그 시퀀스 번호, 타임 스탬프 등)를 가리키는 메타데이터를 생성하는 것을 포함할 수 있다. 일부 실시예들에서, 메타데이터는 또한 스냅샷 식별자를 가리킬 수 있다. 개시된 스냅샷 생성 기술들은 스냅샷 생성의 일부로서 데이터 페이지를 판독, 복사, 또는 기록하는 것 없이 수행될 수 있다.

로그 레코드 조작의 다양한 실시예들이 또한 개시된다. 본 실시예들 중 다양한 실시예들은 복수의 로그 레코드를 수신하는 데이터베이스 서비스의 분산 저장 시스템을 포함할 수 있다. 본 실시예들 중 다양한 실시예들은 또한 분산 저장 시스템의 복수의 저장 노드 사이에 복수의 로그 레코드를 저장하는 분산 저장 시스템을 포함할 수 있다. 본 실시예들 중 다양한 실시예들은 복수의 로그 레코드를 변환하는 분산 저장 시스템을 더 포함할 수 있다. 변환은 다른 변환들 중에서도, 레코드들을 자르는 것, 가지치는 것, 축소하는 것, 용합하는 것, 및/또는 다르게 삭제하는 것, 병합하는 것, 또는 추가하는 것을 포함할 수 있다.

본 명세서는 먼저 개시된 스냅샷 동작들(예를 들어, 생성하는 것, 삭제, 사용, 조작 등) 및 로그 레코드 조작 기술들을 구현하도록 구성되는 예시적인 웹 서비스 기반 데이터베이스 서비스를 설명한다. 예시적인 웹 서비스 기반 데이터베이스 서비스의 설명에는 데이터베이스 엔진 및 개별 분산 데이터베이스 저장 서비스와 같은, 예시적인 웹 서비스 기반 데이터베이스 서비스의 다양한 측면들이 포함된다. 본 명세서는 그 후 스냅샷 동작들 및 로그 레코드 조작을 위한 방법들의 다양한 실시예들의 흐름도들을 설명한다. 다음으로, 본 명세서는 개시된 기술들을 구현할 수 있는 예시적인 시스템을 설명한다. 다양한 예들이 본 명세서 전체에 걸쳐 제공된다.

본 출원에 설명되는 시스템들은 일부 실시예들에서, 클라이언트들(예를 들어, 가입자들)이 클라우드 컴퓨팅 환경에서의 데이터 저장 시스템을 작동하는 것을 가능하게 하는 웹 서비스를 구현할 수 있다. 일부 실시예들에서, 데이터베이스 시스템은 매우 가변적이고 확장 가능한 기업 급 데이터베이스 시스템일 수 있다. 일부 실시예들에서, 질의들은 다수의 물리적 자원에 걸쳐 분산되는 데이터베이스 저장소에 지시될 수 있고, 데이터베이스 시스템은 필요에 따라를 기초로 스케일 업 또는 스케일 다운될 수 있다. 데이터베이스 시스템은 상이한 실시예들에서, 다양한 유형들 및/또는 구조들의 데이터베이스 도식과 효과적으로 작용할 수 있다. 일부 실시예들에서, 클라이언트들/가입자들은 많은 방법들로, 예를 들어, 데이터베이스 시스템에 대한 SQL 인터페이스를 통해 쌍방향으로 질의들을 제출할 수 있다. 다른 실시예들에서, 외부 애플리케이션들 및 프로그램들은 데이터베이스 시스템에 대한 오픈 데이터베이스 연속성(ODBC; Open Database Connectivity) 및/또는 자바 데이터베이스 연속성(JDBC; Java Database Connectivity) 드라이버 인터페이스들을 사용하여 질의들을 제출할 수 있다.

보다 구체적으로, 본 출원에 설명되는 시스템들은 일부 실시예들에서, 단일 데이터베이스 시스템의 다양한 기능적 구성요소들이 본질적으로 분산되는 서비스 지향적인 데이터베이스 아키텍처를 구현할 수 있다. 예를 들어, 다수의 완전한 및 모놀리식 데이터베이스 인스턴스(그 각각이 애플리케이션 서버, 탐색 기능, 또는 데이터베이스의 코어 기능들을 제공하도록 요구되는 것을 넘어서는 다른 기능을 포함할 수 있는)를 함께 래싱(lashing)하기 보다, 이들 시스템들은 데이터베이스의 기본 동작들(예를 들어, 질의 프로세싱, 트랜잭션 관리, 캐싱 및 저장)을 개별적으로 그리고 독립적으로 가변적일 수 있는 티어들(tiers)로 구조화할 수 있다. 예를 들어, 일부 실시예들에서, 본 출원에 설명되는 시스템들에서의 각 데이터베이스 인스턴스는 데이터베이스 티어(단일 데이터베이스 엔진 헤드 노드 및 클라이언트-측 저장 시스템 드라이버를 포함할 수 있는), 및 개별, 분산 저장 시스템(기존 시스템들의 데이터베이스 티어에서 전통적으로 수행되는 동작들의 일부를 총괄적으로 수행하는 다수의 저장 노드를 포함할 수 있는)을 포함할 수 있다.

본 출원에 보다 상세하게 설명될 바와 같이, 데이터베이스의 최저 레벨 동작들의 일부, (예를 들어, 백업, 복구, 스냅샷, 복원, 로그 레코드 조작, 및/또는 다양한 공간 관리 동작들)는 데이터베이스 엔진으로부터 저장 계층으로 분담되고 다수의 노드 및 저장 디바이스에 걸쳐 분산될 수 있다. 예를 들어, 일부 실시예들에서, 데이터베이스 테이블들(또는 그것들의 데이터 페이지들)에 변경들을 적용한 후 변경된 데이터 페이지들을 저장 계층으로 송신하는 데이터베이스 엔진보다, 저장된 데이터베이스 테이블들(또는 그것들의 데이터 페이지들)에 대한 변경들의 애플리케이션이 저장 계층 그 자체의 책임일 수 있다. 이러한 실시예들에서, 변형된 데이터 페이지들이 아닌, 리두 로그 레코드들은 저장 계층으로 송신될 수 있고, 그 후 리두 (예를 들어, 리두 로그 레코드들의 애플리케이션)가 다소 느리게 그리고 분산 방식으로(예를 들어, 백그라운드 프로세스에 의해) 수행될 수 있다. 일부 실시예들에서, 장애 복구(예를 들어, 저장된 리두 로그 레코드들로부터 데이터 페이지들의 재구성)는 또한 저장 계층에 의해 수행될 수 있고 또한 분산된(그리고, 일부 경우들에서, 느리게) 백그라운드 프로세스에 의해 수행될 수 있다.

일부 실시예들에서, 단지 리두 로그들(그리고 변경된 데이터 페이지들이 아닌)이 저장 계층에 송신되기 때문에, 기존 데이터베이스 시스템들보다 데이터베이스 티어 및 저장 계층 간 훨씬 더 적은 네트워크 트래픽이 있을 수 있다. 일부 실시예들에서, 각 리두 로그는 그것이 변경을 명시하는 대응하는 데이터 페이지의 약 1/10 크기일 수 있다. 데이터베이스 티어 및 분산 저장 시스템으로부터 송신되는 요청이 비동기식일 수 있다는 것 및 다수의 그러한 요청이 동시에 진행될 수 있다는 것을 주의하자.

일반적으로, 데이터의 조각이 주어진 후, 데이터베이스의 주요 요건은 그것이 결국에는 데이터의 해당 조각을 다시 돌려줄 수 있다는 것이다. 이를 위해, 데이터베이스는 몇몇의 상이한 구성요소(또는 티어)를 포함할 수 있고, 그 각각은 상이한 기능을 수행한다. 예를 들어, 전통적인 데이터베이스는 세 개의 티어: 질의 분석, 최적화 및 실행을 수행하기 위한 제1 티어; 트랜잭션성, 복구, 및 지속성을 제공하기 위한 제2 티어; 및 지역적으로 연결된 디스크들 상에 또는 네트워크 연결 저장소 상에, 저장소를 제공하는 제3 티어를 갖는 것으로서 간주될 수 있다. 상기에서 언급한 바와 같이, 전통적인 데이터베이스를 스케일링하기 위한 이전 시도들은 전형적으로 데이터베이스의 모든 세 개의 티어를 복제하는 것 및 그러한 복제된 데이터베이스 인스턴스들을 다수의 기계에 걸쳐 분산하는 것을 수반했다.

일부 실시예들에서, 본 출원에 설명된 시스템들은 전통적인 데이터베이스와 상이하게 데이터베이스 시스템의 기능을 분배할 수 있고, 스케일링을 구현하기 위해 단지 기능 구성요소들의 서브세트(완전한 데이터베이스 인스턴스가 아닌)를 다수의 기계에 걸쳐 분산할 수 있다. 예를 들어, 일부 실시예들에서, 클라이언트-대면 티어는 데이터를 저장 또는 검색하는 방법이 아닌, 저장 또는 검색되는 데이터를 명시하는 요청을 수신하도록 구성될 수 있다. 이러한 티어는 요청 분석 및/또는 최적화(예를 들어, SQL 분석 및 최적화)를 수행할 수 있는 한편, 또 다른 티어는 질의 실행에 책임이 있을 수 있다. 일부 실시예들에서, 제3 티어는 트랜잭션성 및 결과들의 일관성을 제공하기 위한 책임이 있을 수 있다. 예를 들어, 이러한 티어는 소위 ACID 속성들의 일부, 특히, 데이터베이스 내 일관성을 유지하고, 데이터베이스를 타겟팅하는 트랜잭션들 간 분리성을 보장하면서, 데이터베이스를 타겟팅하는 트랜잭셩들의 원자성을 강화하도록 구성될 수 있다. 일부 실시예들에서, 제4 티어는 그 후 다양한 종류들의 고장들의 존재 시 저장된 데이터의 지속성을 제공하기 위한 책임이 있을 수 있다. 예를 들어, 이러한 티어는 변경 로깅, 데이터베이스 장애의 회복, 기본 저장 볼륨들에 대한 액세스를 관리하는 것 및/또는 기본 저장 볼륨들에서의 공간 관리에 책임이 있을 수 있다.

이제 도면들을 참조하면, 도 1은 일 실시예에 따라, 데이터베이스 소프트웨어 스택의 다양한 구성요소들을 예시하는 블록도이다. 이 예에서 예시된 바와 같이, 데이터베이스 인스턴스는 다수의 기능적 구성요소들(또는 계층들)을 포함할 수 있고, 그 각각은 데이터베이스 인스턴스의 기능의 일부를 제공한다. 이 예에서, 데이터베이스 인스턴스(100)는 질의 분석 및 질의 최적화 계층(110으로 도시된), 질의 실행 계층(120으로 도시된), 트랜잭션성 및 일관성 관리 계층(130으로 도시된), 및 지속성 및 공간 관리 계층(140으로 도시된)을 포함한다. 상기에서 언급한 바와 같이, 일부 기존 데이터베이스 시스템들에서, 데이터베이스 인스턴스를 스케일링하는 것은 전체 데이터베이스 인스턴스를 일회 또는 수회 복제한 후(도 1에 예시된 모든 계층을 포함하여), 그것들을 함께 스티칭하기 위해 글루 로직을 추가하는 것을 수반할 수 있다. 일부 실시예들에서, 본 출원에 설명된 시스템들은 데이터베이스 티어로부터 개별 저장 계층으로 지속성 및 공간 관리 계층(140)의 기능을 대신 분담할 수 있고, 해당 기능을 저장 계층에서의 다수의 저장 노드에 걸쳐 분산할 수 있다.

일부 실시예들에서, 본 출원에 설명된 데이터베이스 시스템들은 도 1에 예시된 데이터베이스 인스턴스의 상반부의 상당수의 구조를 유지할 수 있으나, 백업, 복원, 스냅샷, 복구, 및/또는 다양한 공간 관리 동작들 중 적어도 부분들에 대한 책임을 저장 티어에 재분산할 수 있다. 이러한 방식으로 기능을 재분산하는 것 및 데이터베이스 티어 및 저장 티어 간 로그 프로세싱을 단단히 결합하는 것은 가변 데이터베이스를 제공하기 위한 이전 접근법들과 비교할 때, 성능을 향상하고, 이용 가능성을 증가하며 비용을 감소시킬 수 있다. 예를 들어, 단지 리두 로그 레코드들(실제 데이터 페이지들보다 크기가 훨씬 더 작은)이 노드들에 걸쳐 수송될 수 있거나 기록 동작들의 지연 경로 내에서 지속되기 때문에, 네트워크 및 입력/출력 대역폭 요건들이 감소될 수 있다. 또한, 데이터 페이지들의 생성은 착신 기록 동작들을 블로킹하지 않고, 각 저장 노드(우위 프로세싱을 허용하는 바와 같은) 상의 백그라운드에서 독립적으로 완료될 수 있다. 일부 실시예들에서, 로그-구조의, 비-겹쳐쓰기 저장소의 사용은 백업, 복원, 스냅샷들, 시점 복구, 및 예를 들어, 데이터 페이지의 이동 또는 복사가 아니라 메타데이터 조작을 사용함으로써, 보다 효율적으로 수행될 볼륨 확대 동작들을 허용할 수 있다. 일부 실시예들에서, 저장 계층은 또한 다수의 저장 노드에 걸쳐 클라이언트들(및/또는 리두 로그 레코드들과 같은, 해당 데이터와 연관된 메타데이터)을 대신하여 저장된 데이터의 복제에 대한 책임을 맡을 수 있다. 예를 들어, 데이터(및/또는 메타데이터)는 지역적으로(예를 들어, 저장 노드들의 수집이 그 자체의 물리적으로 별개의, 독립적인 기반구조 상에서 실행하는 단일 "이용 가능 존" 내에서) 및/또는 단일 영역에서의 또는 상이한 영역들에서의 이용 가능 존들에 걸쳐 복제될 수 있다.

다양한 실시예들에서, 본 출원에 설명된 데이터베이스 시스템들은 다양한 데이터베이스 동작을 위해 표준 또는 주문형 애플리케이션 프로그래밍 인터페이스(API)를 지원할 수 있다. 예를 들어, API는 데이터베이스를 생성하기 위한 동작들, 테이블을 생성하기 위한 동작들, 테이블를 변경하기 위한 동작들, 사용자를 생성하기 위한 동작들, 사용자를 드롭하기 위한 동작들, 테이블에 하나 이상의 행을 삽입하기 위한 동작들, 테이블 내로부터 데이터를 선택하기 위한 동작들(예를 들어, 테이블에 질의하기 위한 동작들), 질의를 취소 또는 중단하기 위한 동작들, 스냅샷을 생성하기 위한 동작들 및/또는 다른 동작들을 지원할 수 있다.

일부 실시예들에서, 데이터베이스 인스턴스의 데이터베이스 티어는 다양한 클라이언트 프로그램들(예를 들어, 애플리케이션들) 및/또는 가입자들(사용자들)로부터 판독 및/또는 기록 요청들을 수신한 후, 그것들을 분석하여 관련 데이터베이스 동작(들)을 수행하기 위해 실행 계획을 개발하는 데이터베이스 엔진 헤드 노드 서버를 포함할 수 있다. 예를 들어, 데이터베이스 엔진 헤드 노드는 복합 질의들 및 조인들(joins)에 대한 결과들을 획득하는데 필요한 일련의 단계를 개발할 수 있다. 일부 실시예들에서, 데이터베이스 엔진 헤드 노드는 데이터베이스 시스템의 데이터베이스 티어 및 클라이언트들/가입자들 간 통신뿐만 아니라, 데이터베이스 티어 및 개별 분산 데이터베이스-최적화 저장 시스템 간 통신을 관리할 수 있다.

일부 실시예들에서, 데이터베이스 엔진 헤드 노드는 JDBC 또는 ODBC 인터페이스를 통해 말단 클라이언트들로부터 SQL 요청들을 수신하는 것 및 지역적으로 SQL 프로세싱 및 트랜잭션 관리(잠금을 포함할 수 있는)를 수행하는 것에 대한 책임이 있을 수 있다. 그러나, 지역적으로 데이터 페이지들을 생성하는 것보다, 데이터베이스 엔진 헤드 노드(또는 그것의 다양한 구성요소들)는 리두 로그 레코드들을 생성할 수 있고 그것들은 개별 분산 저장 시스템의 적절한 노드들로 수송할 수 있다. 일부 실시예들에서, 분산 저장 시스템을 위한 클라이언트-측 드라이버는 데이터베이스 엔진 헤드 노드 상에 호스팅될 수 있고 그것들의 리두 로그 레코드들이 지시되는 세그먼트들(또는 그것들의 데이터 페이지들)을 저장하는 저장 시스템 노드(또는 노드들)로 리두 로그 레코드들을 라우팅하는 것에 대한 책임이 있을 수 있다. 예를 들어, 일부 실시예들에서, 각 세그먼트는 보호 그룹을 형성하는 다수의 저장 시스템 노드 상에 미러링(또는 다르게 지속 가능하게) 될 수 있다. 이러한 실시예들에서, 클라이언트-측 드라이버는 클라이언트 요청이 수신될 때, 각 세그먼트가 저장된 노드들을 계속 추적할 수 있고 세그먼트가 저장된 모든 노드로 리두 로그들을 라우팅할 수 있다(예를 들어, 비동기식으로 및 병렬로, 실질적으로 동시에). 클라이언트-측 드라이버가 보호 그룹에서의 저장 노드들의 기록 쿼럼으로부터 다시 확인 응답(리두 로그 레코드가 저장 노드에 기록되었다는 것을 나타낼 수 있는)을 수신하자마자, 그것은 데이터베이스 티어에(예를 들어, 데이터베이스 엔진 헤드 노드에) 요청된 변경의 확인 응답을 송신할 수 있다. 예를 들어, 데이터가 보호 그룹들의 사용을 통해 지속 가능하게 만들어지는 실시예들에서, 데이터베이스 엔진 헤드 노드는 클라이언트-측 드라이버가 기록 쿼럼을 구성하기 위해 충분한 저장 노드 인스턴스들로부터 답신을 수신할 때까지 그리고 수신하지 않는 한 트랜잭션을 커밋할 수 없을 수 있다. 이와 유사하게, 특정한 세그먼트에 지시되는 판독 요청을 위해, 클라이언트-측 드라이버는 세그먼트가 저장된 모든 노드에 판독 요청을 라우팅할 수 있다(예를 들어, 비동기식으로 및 병렬로, 실질적으로 동시에). 클라이언트-측 드라이버가 보호 그룹에서의 저장 노드들의 판독 쿼럼으로부터 요청된 데이터를 수신하자마자, 그것은 데이터베이스 티어에(예를 들어, 데이터베이스 엔진 헤드 노드에) 요청된 데이터를 리턴할 수 있다.

일부 실시예들에서, 데이터베이스 티어(또는 보다 구체적으로, 데이터베이스 엔진 헤드 노드)는 최근 액세스된 데이터 페이지들이 일시적으로 유지되는 캐시를 포함할 수 있다. 이러한 실시예들에서, 그러한 캐시에 유지된 데이터 페이지를 타겟팅하는 기록 요청이 수신되면, 저장 계층으로 대응하는 리두 로그 레코드를 수송하는 것에 추가하여, 데이터베이스 엔진은 그것의 캐시에 유지된 데이터 페이지의 복사본에 변경을 적용할 수 있다. 그러나, 데이터베이스 시스템들에서와 다르게, 캐시에 유지되는 데이터 페이지는 저장 계층에 전혀 플러싱될 수 없고, 그것을 언제라도(예를 들어, 캐싱된 복사본에 가장 최근에 적용된 기록 요청을 위한 리두 로그 레코드가 저장 계층에 송신되고 확인 응답된 후 언제라도) 폐기될 수 있다. 캐시는 상이한 실시예들에서, 동시에 최대한 하나의 기록기(또는 다수의 판독기)에 의한 캐시에의 액세스를 제어하기 위해 다양한 잠금 메커니즘들 중 임의의 것을 구현할 수 있다. 그러나, 그러한 캐시를 포함하는 실시예들에서, 캐시는 다수의 노드에 걸쳐 분산될 수 없으나, 단지 소정의 데이터베이스 인스턴스를 위한 데이터베이스 엔진 헤드 노드 상에 존재할 수 있다는 것을 주의하자. 따라서, 관리할 어떤 캐시 일관성 이슈들도 존재하지 않을 수 있다.

일부 실시예들에서, 데이터베이스 티어는 시스템에서의 동기식 또는 비동기식 판독 복제본들, 예를 들어, 판독 요청이 라우팅될 수 있는 데이터베이스 티어의 상이한 노드 상에서의 데이터의 판독-전용 복사본들의 사용을 지원할 수 있다. 이러한 실시예들에서, 소정의 데이터베이스 테이블을 위한 데이터베이스 엔진 헤드 노드가 특정한 데이터 페이지에 지시되는 판독 요청을 수신하면, 이들 판독-전용 복사본들 중 임의의 본사본(또는 특정한 복사본)에 대한 요청을 라우팅할 수 있다. 일부 실시예들에서, 데이터베이스 엔진 헤드 노드에서의 클라이언트-측 드라이버는 이들 다른 노드들에 캐싱된 데이터 페이지들에 대한 업데이트들 및/또는 무효화들을 통지하도록 구성될 수 있다(예를 들어, 그것들이 그것들의 캐시들을 무효화하도록 유도하기 위해, 그 후 그것들이 저장 계층으로부터의 업데이트된 데이터 페이지들의 업데이트된 복사본들을 요청할 수 있다).

일부 실시예들에서, 데이터베이스 엔진 헤드 노드 상에서 작동하는 클라이언트-측 드라이버는 저장 티어에 사설 인터페이스를 노출시킬 수 있다. 일부 실시예들에서, 그것은 또한 하나 이상의 다른 구성요소(예를 들어, 다른 데이터베이스 엔진들 또는 가상 컴퓨팅 서비스 구성요소들)에 전통적인 iSCSI 인터페이스를 노출시킬 수 있다. 일부 실시예들에서, 저장 티어에서의 데이터베이스 인스턴스를 위한 저장소는 제한 없이 크기가 커질 수 있고, 제한 없이 그것과 연관된 IOPS를 가질 수 있는 단일 볼륨으로서 모델링될 수 있다. 볼륨이 생성될 때, 그것은 특정한 크기로, 특정한 이용 가능/지속 특성(예를 들어, 그것이 복제되는 방법을 명시하는)으로, 및/또는 그것과 연관된 IOPS 레이트(예를 들어, 피크 및 유지 양자 모두)로 생성될 수 있다. 예를 들어, 일부 실시예들에서, 다양한 상이한 지속성 모델들이 지원될 수 있고, 사용자들/가입자들은 그것들의 데이터베이스 테이블들에 대해, 다수의 복제 복사본, 존, 또는 영역 및/또는 복제가 그것들의 지속성, 성능 및 비용 목적들에 기초하여 동기식인지 또는 비동기식인지를 명시할 수 있을 수 있다.

일부 실시예들에서, 클라이언트 측 드라이버는 볼륨에 대한 메타데이터를 유지할 수 있고 저장 노드들 간 추가적인 홉들(hops)을 요구하지 않고 판독 요청들 및 기록 요청들을 이행하는데 필요한 저장 노드들 각각에 비동기식 요청들을 직접 송신할 수 있다. 예를 들어, 일부 실시예들에서, 데이터베이스 테이블을 변경하기 위한 요청에 응답하여, 클라이언트-측 드라이버는 타겟 데이터 페이지를 위한 저장소를 구현하고 있는 하나 이상의 노드를 결정하도록, 그리고 그러한 저장 노드들에 해당 변경을 명시하는 리두 로그 레코드(들)을 라우팅하도록 구성될 수 있다. 그 후 저장 노드들은 미래의 어느 지점에서 타겟 데이터 페이지에 리두 로그 레코드에서 명시된 변경을 적용하는 것에 대한 책임이 있을 수 있다. 기록들이 클라이언트-측 드라이버로 다시 확인 응답됨에 따라, 클라이언트-측 드라이버는 볼륨이 지속 가능한 지점으로 진행될 수 있고 데이터베이스 티어에 다시 커밋들을 확인 응답할 수 있다. 이전에 언급된 바와 같이, 일부 실시예들에서, 클라이언트-측 드라이버는 저장 노드 서버들에 데이터 페이지들을 전혀 송신하지 않을 수 있다. 이는 네트워크 트래픽을 단지 감소시키지 않을 수 있으나, 또한 이전 데이터베이스 시스템들에서의 우위-프로세싱 스루풋을 제한하는 체크포인트 또는 백그라운드 기록기 스레드들의 필요를 제거할 수 있다.

일부 실시예들에서, 많은 판독 요청들은 데이터베이스 엔진 헤드 노드 캐시에 의해 제공될 수 있다. 그러나, 단지 메모리 내 복제를 허용하기 위해 대규모 고장 이벤트들이 매우 흔할 수 있기 때문에, 기록 요청들은 지속성을 요구할 수 있다. 따라서, 본 출원에 설명된 시스템들은 두 개의 영역: 리두 로그 레코드들이 데이터베이스 티어로부터 수신될 때 그것들이 기록되는 작은 첨부-전용 로그-구조 영역, 및 로그 레코드들이 백그라운드에 데이터 페이지들의 신규 버전들을 생성하기 위해 함께 병합되는 보다 큰 영역으로서 저장 티어에 데이터 저장소를 구현함으로써 우위 레이턴시 경로에 있는 리두 로그 레코드 기록 동작들의 비용을 최소화하도록 구성될 수 있다. 일부 실시예들에서, 메모리 내 구조는 인스턴스화된 데이터 블록이 참조될 때까지 로그 레코드들을 역방향으로 연결하여, 해당 페이지에 대한 마지막 리두 로그 레코드를 가리키는 각 데이터 페이지에 대해 유지될 수 있다. 이러한 접근법은 판독들이 주로 캐싱되는 애플리케이션들에 포함하여, 혼합된 판독-기록 작업부하들에 양호한 성능을 제공할 수 있다.

일부 실시예들에서, 리두 로그 레코드를 위한 로그-구조의 데이터 저장소에의 접근들이 일련의 순차적인 입력/출력 동작(랜덤 입력/출력 동작이 아닌)으로 구성되기 때문에, 이루어지는 변경들이 함께 단단하게 패킹될 수 있다. 데이터 페이지에 대한 각 변경이 영구 데이터 저장을 위한 두 개의 입력/출력 동작(리두 로그 레코드를 위한 하나 및 변경된 데이터 페이지 자체를 위한 하나)을 야기하는 기존 시스템들과 비교하여, 일부 실시예들에서, 본 출원에 설명된 시스템들은 리두 로그 레코드들의 수신에 기초하여 분산 저장 시스템의 저장 노드들에 데이터 페이지들을 병합함으로써 이러한 "기록 확장"을 방지할 수 있다는 것이 또한 주의되어야 한다.

이전에 언급된 바와 같이, 일부 실시예들에서, 데이터베이스 시스템의 저장 티어는 데이터베이스 스냅샷들을 취하는 것에 책임이 있을 수 있다. 그러나, 저장 티어가 로그-구조의 저장소를 구현하기 때문에, 데이터 페이지(예를 들어, 데이터 블록)의 스냅샷을 취하는 것은 데이터 페이지/블록에 가장 최근에 적용된 리두 로그 레코드와 연관된 타임스탬프(또는 데이터 페이지/블록의 신규 버전을 생성하기 위해 다수의 리두 로그 레코드를 병합하기 위한 가장 최근의 동작과 연관된 타임스탬프)를 레코딩하는 것, 및 레코드 시점까지 페이지/블록 및 임의의 후속 로그 엔트리들의 이전 버전의 가비지 수집(garbage collection)을 예방하는 것을 포함할 수 있다. 이러한 실시예들에서, 데이터베이스 스냅샷을 취하는 것은 오프-볼륨 백업 전략을 채용할 때 요구될 수 있는 바와 같이, 데이터 블록을 판독하는 것, 복사하는 것, 또는 기록하는 것을 요구하지 않을 수 있다. 일부 실시예들에서, 사용자/가입자들이 그들이 활성 데이터 세트에 추가하여 온-볼륨 스냅샷들을 위해 얼마나 많은 추가 공간을 유지하기 원하는지 선택할 수 있을 수 있더라도, 단지 변형된 데이터만이 추가 공간을 요구할 수 있기 때문에, 스냅샷들에 대한 공간 요건들이 최소일 수 있다. 상이한 실시예들에서, 스냅샷들은 별개(예를 들어, 각 스냅샷은 특정한 시점으로부터 데이터 페이지에서의 모든 데이터에 대한 액세스를 제공할 수 있다) 또는 연속적(예를 들어, 각 스냅샷은 두 개의 시점 간 데이터 페이지에 존재하는 데이터의 모든 버전에 대한 액세스를 제공할 수 있다)일 수 있다. 일부 실시예들에서, 이전 스냅샷으로 회귀하는 것은 스냅샷이 무효이고 수집 가능한 이후 해당 모든 리두 로그 레코드 및 데이터 페이지를 나타내기 위해 로그 레코드를 레코딩하는 것, 및 스냅샷 지점 이후 모든 데이터베이스 캐시 엔트리를 폐기하는 것을 포함할 수 있다. 이러한 실시예들에서, 마치 저장 시스템이 정상적인 순방향 기록/판독 처리에서 수행하는 바와 같이, 그것이 블록마다를 기초로, 리두 로그 레코드들을 모든 노드에 걸쳐 백그라운드에 그리고 요구되는 바와 같이 데이터 블록들에 적용할 것이기 때문에 어떤 롤-포워드(roll-forward)도 요구되지 않을 수 있다. 그렇게 함으로써 장애 복구는 노드들가 걸쳐 병렬로 이루어지고 분산될 수 있다. 스냅샷 생성, 사용, 및/또는 조작에 관한 추가적인 세부사항들이 도 8 및 도 9에서 설명된다.

웹 서비스 기반 데이터베이스 서비스를 구현하도록 구성될 수 있는 서비스 시스템 아키텍처의 일 실시예가 도 2에 예시된다. 예시된 실시예에서, 다수의 클라이언트(데이터베이스 클라이언트들(250a 내지 250n)으로 도시된)는 네트워크(260)를 통해 웹 서비스 플랫폼(200)과 상호작용하도록 구성될 수 있다. 웹 서비스 플랫폼(200)은 데이터베이스 서비스(210), 분산 데이터베이스-최적화 저장 서비스(220) 및/또는 하나 이상의 다른 가상 컴퓨팅 서비스(230) 중 하나 이상의 인스턴스와 인터페이싱하도록 구성될 수 있다. 소정의 구성요소의 하나 이상의 인스턴스가 존재할 수 있는 곳에서, 본 출원에서의 해당 구성요소에 대해 단일 또는 복수 어느 하나로 참조될 수 있다는 것이 주의된다. 그러나, 어느 하나의 형태의 사용이 다른 형태를 배제하도록 의도되지 않는다.

다양한 실시예들에서, 도 2에 예시된 구성요소들은 컴퓨터 하드웨어(예를 들어, 마이크로프로세서 또는 컴퓨터 시스템)에 의해 직접 또는 간접적으로 실행 가능한 명령들로서, 또는 이들 기술들의 조합을 사용하여, 컴퓨터 하드웨어 내에서 직접 구현될 수 있다. 예를 들어, 도 2의 구성요소들은 다수의 컴퓨팅 노드(또는 단순히, 노드)를 포함하는 시스템에 의해 구현될 수 있고, 그 각각은 도 10에 예시된 그리고 아래 설명될 컴퓨터 시스템 실시예와 유사할 수 있다. 다양한 실시예들에서, 소정의서비스 시스템 구성요소(예를 들어, 데이터베이스 서비스의 구성요소 또는 저장 서비스의 구성요소)의 기능은 특정한 노드에 의해 구현될 수 있거나 몇몇의 노드에 걸쳐 분산될 수 있다. 일부 실시예들에서, 소정의 노드는 하나보다 많은 서비스 시스템 구성요소(예를 들어, 하나보다 많은 데이터베이스 서비스 시스템 구성요소)의 기능을 구현할 수 있다.

일반적으로 말해서, 클라이언트들(250)은 데이터베이스 서비스들에 대한 요청들(예를 들어, 스냅샷을 생성하기 위한 요청 등)을 포함하여, 네트워크(260)를 통해 웹 서비스 플랫폼(200)으로 웹 서비스 요청들을 제출하도록 구성 가능한 임의의 유형의 클라이언트를 포함할 수 있다. 예를 들어, 소정의 클라이언트(250)는 웹 브라우저의 적합한 버전을 포함할 수 있거나, 웹 브라우저에 의해 제공되는 실행 환경으로 또는 실행 환경 내 확장으로서 실행하도록 구성되는 플러그-인 모듈 또는 다른 유형의 코드 모듈을 포함할 수 있다. 대안적으로, 클라이언트(250)(예를 들어, 데이터베이스 서비스 클라이언트)는 데이터베이스 애플리케이션(또는 그것의 사용자 인터페이스), 미디어 애플리케이션, 오피스 애플리케이션 또는 하나 이상의 데이터베이스 테이블을 저장 및/또는 액세스하기 위해 영구 저장 자원들을 사용할 수 있는 임의의 다른 애플리케이션과 같은 애플리케이션을 포함할 수 있다. 일부 실시예들에서, 그러한 애플리케이션은 모든 유형의 웹 기반 데이터를 위해 완전한 브라우저 지원을 반드시 구현하지 않고도 웹 서비스 요청들을 생성 및 프로세싱하기 위한 충분한 프로토콜 지원(예를 들어, 하이퍼텍스트 전송 프로토콜(HTTP)의 적합한 버전을 위한)을 포함할 수 있다. 즉, 클라이언트(250)는 웹 서비스 플랫폼(200)과 직접 상호작용하도록 구성된 애플리케이션일 수 있다. 일부 실시예들에서, 클라이언트(250)는 REST(Representational State Transfer)-방식 웹 서비스 아키텍처, 문서 또는 메시지 기반 웹 서비스 아키텍처, 또는 다른 적합한 웹 서비스 아키텍처에 따라 웹 서비스 요청들을 생성하도록 구성될 수 있다.

일부 실시예들에서, 클라이언트(250)(예를 들어, 데이터베이스 서비스 클라이언트들)는 다른 애플리케이션들에 명료한 방식으로 그러한 애플리케이션들에 데이터베이스 테이블들의 웹 서비스 기반 저장소에의 액세스를 제공하도록 구성될 수 있다. 예를 들어, 클라이언트(250)는 본 출원에 설명된 저장 모델들의 적합한 변종에 따라 저장소를 제공하기 위해 운영 시스템 또는 파일 시스템과 통합하도록 구성될 수 있다. 그러나, 운영 시스템 또는 파일 시스템은 파일들, 디렉토리들 및/또는 폴더들의 통상의 파일 시스템 계층과 같은, 애플리케이션들에 상이한 저장 인터페이스를 제공할 수 있다. 이러한 실시예에서, 애플리케이션들은 도 1의 저장 시스템 서비스 모델을 사용하기 위해 변형될 필요는 없을 수 있다. 대신에, 웹 서비스 플랫폼(200)에 대한 인터페이싱의 세부사항들은 운영 시스템 환경 내에서 실행하는 애플리케이션들을 대신하여 운영 시스템 또는 파일 시스템 및 클라이언트(250)에 의해 조정될 수 있다.

클라이언트들(250)은 네트워크(260)를 통해 웹 서비스 플랫폼(200)으로 웹 서비스 요청들(예를 들어, 스냅샷 요청, 스냅샷의 파라미터들 요청, 판독 요청, 스냅샷 복구 등)을 전달하고 그로부터 응답들을 수신할 수 있다. 다양한 실시예들에서, 네트워크(260)는 클라이언트들(250) 및 플랫폼(200) 간 웹 기반 통신을 설정하는데 필요한 네트워킹 하드웨어 및 프로토콜들의 임의의 적합한 조합을 포함할 수 있다. 예를 들어, 네트워크(260)는 일반적으로 다양한 통신 네트워크들 및 인터넷을 총괄적으로 구현하는 서비스 제공자들을 포함할 수 있다. 네트워크(260)는 또한 공중 또는 사설 무선 네트워크들뿐만 아니라 로컬 영역 네트워크들(LAN들) 또는 광역 네트워크들(WAN들)과 같은 사설 네트워크들을 포함할 수 있다. 예를 들어, 소정의 클라이언트(250) 및 웹 서비스 플랫폼(200)은 각각 그들 자체의 내부 네트워크들을 갖는 기업 내에 제공될 수 있다. 이러한 실시예에서, 네트워크(260)는 인터넷 및 웹 서비스 플랫폼(200) 간 뿐만 아니라 소정의 클라이언트(250) 및 인터넷 간 네트워킹 링크를 설정하는데 필요한 하드웨어(예를 들어, 모뎀들, 라우터들, 스위치들, 부하 분산장치들, 프록시 서버들 등) 및 소프트웨어(예를 들어, 프로토콜 스택들, 회계 소프트웨어, 방화/보안 소프트웨어 등)을 포함할 수 있다. 일부 실시예들에서, 클라이언트들(250)은 공중 인터넷이 아닌 사설 네트워크를 사용하여 웹 서비스 플랫폼(200)와 통신할 수 있다. 예를 들어, 클라이언트들(250)은 데이터베이스 서비스 시스템(예를 들어, 데이터베이스 서비스(210) 및/또는 분산 데이터베이스-최적화 저장 서비스(220)를 구현하는 시스템)으로서 동일한 기업 내에 제공될 수 있다. 이러한 경우, 클라이언트들(250)은 사설 네트워크(260)(예를 들어, 공중이 액세스 가능하지 않으나 인터넷 기반 통신 프로토콜들을 사용할 수 있는 LAN 또는 WAN)를 통해 전적으로 플랫폼(200)과 통신할 수 있다.

일반적으로 말해서, 웹 서비스 플랫폼(200)은 데이터 페이지들(또는 그것들의 레코드들)에의 액세스를 위한 요청들과 같은, 웹 서비스 요청들을 수신 및 프로세싱하도록 구성되는 하나 이상의 서비스 종단점을 구현하도록 구성될 수 있다. 예를 들어, 웹 서비스 플랫폼(200)은 특정한 종단점을 구현하도록 구성된 하드웨어 및/또는 소프트웨어를 포함할 수 있어, 해당 종단점에 지시되는 HTTP 기반 웹 서비스 요청이 적절하게 수신 및 프로세싱된다. 일 실시예에서, 웹 서비스 플랫폼(200)은 클라이언트들(250)로부터 웹 서비스 요청들을 수신하고 그것들을 데이터베이스 서비스(210), 분산 데이터베이스-최적화 저장 서비스(220) 및/또는 프로세싱하기 위한 또 다른 컴퓨팅 서비스(230)를 구현하는 시스템의 구성요소들에 전송하도록 구성된 서버 시스템으로 구현될 수 있다. 다른 실시예들에서, 웹 서비스 플랫폼(200)은 부하 분산을 구현하는 다수의 별개의 시스템(예를 들어, 클러스터 토폴로지 내) 및 부하들을 프로세싱하는 대형 웹 서비스 요청을 동적으로 관리하도록 구성된 다른 요청 관리 피처들로 구성될 수 있다. 다양한 실시예들에서, 웹 서비스 플랫폼(200)은 REST-방식 또는 문서 기반(예를 들어, SOAP 기반) 유형들의 웹 서비스 요청들을 지원하도록 구성될 수 있다.

클라이언트의 웹 서비스 요청들을 위해 어드레스 지정 가능한 종단점으로 기능하는 것에 추가하여, 일부 실시예들에서, 웹 서비스 플랫폼(200)은 다양한 클라이언트 관리 피처들을 구현할 수 있다. 예를 들어, 플랫폼(200)은 이를테면 요청 클라이언트들(250)의 정체들, 클라이언트 요청들의 수 및/또는 빈도, 클라이언트들(250)을 대신하여 저장 또는 검색된 데이터베이스 테이블들(또는 그것들의 레코드들)의 크기, 클라이언트들(250)에 의해 사용되는 전체 저장 대역폭, 클라이언트들(250)에 의해 요청되는 저장소의 클래스, 또는 다른 측정 가능한 클라이언트 사용량 파라미터를 추적함으로써, 저장 자원들을 포함하여, 웹 서비스들의 클라이언트 사용량의 계량 및 계산을 조정할 수 있다. 플랫폼(200)은 또한 재무 회계 및 과금 시스템들을 구현할 수 있거나, 클라이언트 사용량 활동의 보고 및 과금을 위해 외부 시스템들에 의해 질의 및 프로세싱될 수 있는 사용량 데이터의 데이터베이스를 유지할 수 있다. 어떤 실시예들에서, 플랫폼(200)은 클라이언트들(250)로부터 수신된 요청들의 레이트들 및 유형들을 반영하는 지표, 그러한 요청들에 의해 활용되는 대역폭, 그러한 요청들에 대한 시스템 프로세싱 레이턴시, 시스템 구성요소 활용(예를 들어, 네트워크 대역폭 및/또는 저장 서비스 시스템 내 저장소 활용), 요청들로부터 야기되는 에러들의 레이트들 및 유형들, 저장 및 요청된 데이터 페이지들 또는 그것들의 레코드들의 특성들(예를 들어, 크기, 데이터 유형 등), 또는 임의의 다른 적합한 지표와 같은, 다양한 저장 서비스 시스템 운영 지표를 수집, 모니터링 및/또는 종합하도록 구성될 수 있다. 일부 실시예들에서 그러한 지표는 시스템 구성요소들을 조정 및 유지하기 위해 시스템 관리자들에 의해 사용될 수 있는 반면, 다른 실시예들에서 그러한 지표(또는 그러한 지표의 관련 부분들)는 클라이언트들(250)이 데이터베이스 서비스(210), 분산 데이터베이스-최적화 저장 서비스(220) 및/또는 또 다른 가상 컴퓨팅 서비스(230)(또는 그러한 서비스들을 구현하는 기본 시스템들)에 대한 그들의 사용량을 모니터링하게 하기 위해 클라이언트들에 노출될 수 있다.

일부 실시예들에서, 플랫폼(200)은 또한 사용자 인증 및 액세스 제어 절차들을 구현할 수 있다. 예를 들어, 특정한 데이터베이스 테이블에의 액세스를 위한 소정의 웹 서비스 요청을 위해 플랫폼(200)은 요청과 연관된 클라이언트(250)가 특정한 데이터베이스 테이블에 액세스할 권한이 있는지를 확인하도록 구성될 수 있다. 플랫폼(200)은 예를 들어, 특정한 데이터베이스 테이블과 연관된 자격들과 대조하여 아이디, 비밀번호 또는 다른 자격을 평가함으로써, 또는 특정한 데이터베이스 테이블에 대한 액세스 제어 리스트와 대조하여 특정한 데이터베이스 테이블에의 요청된 액세스를 평가함으로써 그러한 인증을 결정할 수 있다. 예를 들어, 클라이언트(250)가 특정한 데이터베이스 테이블에 액세스하기 위해 충분한 자격들을 가지지 않는다면, 플랫폼(200)은 예를 들어 에러 상태를 나타내는 응답을 요청 클라이언트(250)에 리턴함으로써, 대응하는 웹 서비스 요청을 거부할 수 있다. 다양한 액세스 제어 정책들은 데이터베이스 서비스(210), 분산 데이터베이스-최적화 저장 서비스(220) 및/또는 다른 가상 컴퓨팅 서비스들(230)에 의해 액세스 제어 정보의 레코드들 또는 리스트들로 저장될 수 있다.

웹 서비스 플랫폼(200)은 클라이언트들(250)이 데이터베이스 서비스(210)를 구현하는 데이터베이스 시스템의 피처들을 액세스할 수 있는 주요 인터페이스를 나타낼 수 있지만, 그것이 그러한 피처들에 대한 유일한 인터페이스를 나타낼 필요가 없다는 것이 주의된다. 예를 들어, 웹 서비스 인터페이스와 별개일 수 있는 대안적인 API는 데이터베이스 시스템을 제공하는 기업 내부의 클라이언트들이 웹 서비스 플랫폼(200)을 우회하는 것을 허용하는데 사용될 수 있다. 본 출원에 설명된 많은 예에서, 분산 데이터베이스-최적화 저장 서비스(220)는 클라이언트들(250)에 데이터베이스 서비스들을 제공하는 컴퓨팅 시스템 또는 기업 시스템 내부에 있을 수 있고, 외부 클라이언트들(예를 들어, 사용자들 또는 클라이언트 애플리케이션들)에 노출되지 않을 수 있다. 이러한 실시예들에서, 내부 "클라이언트"(예를 들어, 데이터베이스 서비스(210))는 분산 데이터베이스-최적화 저장 서비스(220) 및 데이터베이스 서비스(210) 간 유일한 라인으로 도시된, 로컬 또는 사설 네트워크를 통해(예를 들어, 이들 시스템들을 구현하는 시스템들 간 직접적으로 API를 통해) 분산 데이터베이스-최적화 저장 서비스(220)에 액세스할 수 있다. 이러한 실시예들에서, 클라이언트들(250)을 대신하여 데이터베이스 테이블들을 저장하는 것에 있어서의 분산 데이터베이스-최적화 저장 서비스(220)의 사용은 그러한 클라이언트들에 명료할 수 있다. 다른 실시예들에서, 분산 데이터베이스-최적화 저장 서비스(220)는 데이터베이스 관리를 위해 데이터베이스 서비스(210)에 의존하는 것들이 아닌 애플리케이션들을 위한 데이터베이스 테이블들 또는 다른 정보의 저장소를 제공하기 위해 웹 서비스 플랫폼(200)을 통해 클라이언트들(250)에 노출될 수 있다. 이는 웹 서비스 플랫폼(200) 및 분산 데이터베이스-최적화 저장 서비스(220) 간 점선에 의해 도 2에 예시된다. 이러한 실시예들에서, 분산 데이터베이스-최적화 저장 서비스(220)의 클라이언트들은 네트워크(260)를 통해(예를 들어, 인터넷을 통해) 분산 데이터베이스-최적화 저장 서비스(220)에 액세스할 수 있다. 일부 실시예들에서, 가상 컴퓨팅 서비스(230)는 클라이언트(250)를 대신하여 컴퓨팅 서비스들(230)을 수행하는데 사용되는 객체들을 저장하기 위해 분산 데이터베이스-최적화 저장 서비스(220)로부터(예를 들어, 가상 컴퓨팅 서비스(230) 및 분산 데이터베이스-최적화 저장 서비스(220) 간 직접적으로 API를 통해) 저장 서비스들을 수신하도록 구성될 수 있다. 이는 가상 컴퓨팅 서비스(230) 및 분산 데이터베이스-최적화 저장 서비스(220) 간 점선에 의해 도 2에 예시된다. 일부 경우들에서, 플랫폼(200)의 계정 및/또는 자격 인증 서비스들은 동일한 기업 내 서비스 구성요소들 사이에 또는 관리상의 클라이언트들과 같은 내부 클라이언트들에 불필요할 수 있다.

다양한 실시예들에서, 상이한 저장 정책들은 데이터베이스 서비스(210) 및/또는 분산 데이터베이스-최적화 저장 서비스(220)에 의해 구현될 수 있다. 그러한 저장 정책들의 예들은 지속성 정책(예를 들어, 저장될 데이터베이스 테이블(또는 그것의 데이터 페이지)의 다수의 인스턴스 및 그것들이 저장될 다수의 상이한 노드를 나타내는 정책) 및/또는 부하 분산 정책(요청 트래픽을 동등하게 하려는 시도로 상이한 노드들, 볼륨들 및/또는 디스크들에 걸쳐 데이터베이스 테이블, 또는 그것의 데이터 페이지들을 분산할 수 있는)을 포함할 수 있다. 또한, 상이한 저장 정책들은 다양항 서비스들 중 하나에 의해 상이한 유형들의 저장된 아이템들에 적용될 수 있다. 예를 들어, 일부 실시예들에서, 분산 데이터베이스-최적화 저장 서비스(220)는 데이터 페이지들보다 리두 로그 레코드들을 위해 더 높은 지속성을 구현할 수 있다.

도 3은 일 실시예에 따라, 데이터베이스 엔진 및 개별 분산 데이터베이스 저장 서비스를 포함하는 데이터베이스 시스템의 다양한 구성요소들을 예시하는 블록도이다. 이 예에서, 데이터베이스 시스템(300)은 몇몇 데이터베이스 테이블 각각을 위한 각각의 데이터베이스 엔진 헤드 노드(320) 및 분산 데이터베이스-최적화 저장 서비스(310)(데이터베이스 클라이언트들(350a 내지 350n)로 도시된, 데이터베이스 시스템의 클라이언트들에 보일 수 있거나 보이지 않을 수 있는)를 포함한다. 이 예에서 예시된 바와 같이, 하나 이상의 데이터베이스 클라이언트(350a 내지 350n)는 네트워크(360)를 통해(예를 들어, 이들 구성요소들은 데이터베이스 클라이언트들(350a 내지 350n)에 네트워크-주소 지정 가능하고 액세스 가능할 수 있다) 데이터베이스 헤드 노드(320)(예를 들어, 그 각각이 각각의 데이터베이스 인스턴스의 구성요소인, 헤드 노드(320a), 헤드 노드(320b), 또는 헤드 노드(320c))에 액세스할 수 있다. 그러나, 데이터베이스 클라이언트들(350a 내지 350n)을 대신하여 하나 이상의 데이터베이스 테이블의 데이터 페이지들(및 리두 로그 레코드들 및/또는 그것들과 연관된 다른 메타데이터)을 저장하기 위해, 그리고 본 출원에 설명된 데이터베이스 시스템의 다른 기능들을 수행하기 위해 데이터베이스 시스템에 의해 채용될 수 있는, 분산 데이터베이스-최적화 저장 서비스(310)는, 상이한 실시예들에서, 저장 클라이언트들(350a 내지 350n)에 네트워크-주소 지정 가능하고 액세스 가능할 수 있거나 가능하지 않을 수 있다. 예를 들어, 일부 실시예들에서, 분산 데이터베이스-최적화 저장 서비스(310)는 저장 클라이언트들(350a 내지 350n)에 비가시적인 방식으로 다양한 저장, 액세스, 변경 로깅, 복구, 로그 레코드 조작 및/또는 공간 관리 동작들을 수행할 수 있다.

이전에 언급된 바와 같이, 각 데이터베이스 인스턴스는 다양한 클라이언트 프로그램들(예를 들어, 애플리케이션들) 및/또는 가입자들(사용자들)로부터 요청들(예를 들어, 스냅샷 요청 등)을 수신한 후, 그것들을 분석하고, 그것들 최적화하며, 관련 데이터베이스 동작(들)을 수행하기 위해 실행 계획을 개발하는 단일 데이터베이스 엔진 헤드 노드(320)를 포함할 수 있다. 도 3에 예시된 예에서, 데이터베이스 엔진 헤드 노드(320a)의 질의 분석, 최적화, 및 실행 구성요소(305)는 데이터베이스 클라이언트(350a)로부터 수신되고 데이터베이스 엔진 헤드 노드(320a)가 구성요소인 데이터베이스 인스턴스를 타겟팅하는 질의들을 위해 이들 기능들을 수행할 수 있다. 일부 실시예들에서, 질의 분석, 최적화, 및 실행 구성요소(305)는 데이터베이스 클라이언트(350a)에 질의 응답들을 리턴할 수 있는데, 이 질의 응답들은 적절하게, 기록 확인 응답들, 요청된 데이터 페이지들(또는 그것들의 부분들), 에러 메시지들, 및 또는 다른 응답들을 포함할 수 있다. 이 예에서 예시된 바와 같이, 데이터베이스 엔진 헤드 노드(320a)는 또한 클라이언트-측 저장 서비스 드라이버(325)를 포함할 수 있는데, 이는분산 데이터베이스-최적화 저장 서비스(310) 내 다양한 저장 노드들에 판독 요청들 및/또는 리두 로그 레코드들을 라우팅하고, 분산 데이터베이스-최적화 저장 서비스(310)로부터 기록 확인 응답들을 수신하고, 분산 데이터베이스-최적화 저장 서비스(310)로부터 요청된 데이터 페이지들을 수신하며, 및/또는 데이터 페이지들, 에러 메시지들, 또는 다른 응답들을 질의 분석, 최적화, 및 실행 구성요소(305)(결과적으로, 그것들을 데이터베이스 클라이언트(350a)에 리턴할 수 있는)에 리턴할 수 있다.

이 예에서, 데이터베이스 엔진 헤드 노드(320a)는 데이터 페이지 캐시(335)를 포함하는데, 여기에 최근에 액세스된 데이터 페이지들이 일시적으로 유지될 수 있다. 도 3에 예시된 바와 같이, 데이터베이스 엔진 헤드 노드(320a)는 또한 트랜잭션 및 일관성 관리 구성요소(330)를 포함할 수 있는데, 이는 데이터베이스 엔진 헤드 노드(320a)가 구성요소인 데이터베이스 인스턴스에서의 트랜잭션성 및 일관성을 제공하는 것에 책임이 있을 수 있다. 예를 들어, 이러한 구성요소는 데이터베이스 인스턴스 및 해당 데이터베이스 인스턴스에 지시되는 트랜잭션들의 원자성, 일관성, 및 분리성 속성들을 보장하는 것에 책임이 있을 수 있다. 도 3에 예시된 바와 같이, 데이터베이스 엔진 헤드 노드(320a)는 또한 트랜잭션 로그(340) 및 언두 로그(undo log)(345)를 포함할 수 있는데, 이들은 다양한 트랜잭션들의 상황을 추적하고 커밋하지 않은 트랜잭션들의 임의의 지역적으로 캐싱된 결과들을 롤백(roll back)하기 위해 트랜잭션 및 일관성 관리 구성요소(330)에 의해 채용될 수 있다.

도 3에 예시된 다른 데이터베이스 엔진 헤드 노드들(320) 각각(예를 들어, 320b 및 320c)이 유사한 구성요소들을 포함할 수 있고 하나 이상의 데이터베이스 클라이언트(350a 내지 350n)에 의해 수신되고 그것이 구성요소인 각각의 데이터베이스 인스턴스들에 지시되는 질의들을 위한 유사한 기능들을 수행할 수 있다는 것을 주의하자.

일부 실시예들에서, 본 출원에 설명된 분산 데이터베이스-최적화 저장 시스템들은 하나 이상의 저장 노드 상의 저장소를 위해 다양한 논리 볼륨들, 세그먼트들, 및 페이지들로 데이터를 구조화할 수 있다. 예를 들어, 일부 실시예들에서, 각 데이터베이스 테이블은 논리 볼륨에 의해 제시될 수 있고, 각 논리 볼륨은 저장 노드들의 수집을 통해 세그먼트화된다. 저장 노드들 중 특정한 저장 노드 상에 존재하는, 각 세그먼트는 인접한 블록 어드레스들의 세트를 포함한다. 일부 실시예들에서, 각 데이터 페이지는 세그먼트에 저장되어, 각 세그먼트는 하나 이상의 데이터 페이지의 집한 및 그것이 저장하는 각 데이터 페이지를 위한 변경 로그(또한 리두 로그로 지칭되는)(예를 들어, 리두 로그 레코드들의 로그)를 저장한다. 본 출원에 상세하게 설명된 바와 같이, 저장 노드들은 리두 로그 레코드들(또한 본 출원에서 ULR들로 지칭될 수 있는)을 수신하도록 그리고 대응하는 데이터 페이지들 및/또는 추가적인 또는 대체 로그 레코드들의 신규 버전들을 생성하기 위해 리두 로그 레코드들을 병합하도록(예를 들어, 느리게 및/또는 데이터 페이지에 대한 요청 또는 데이터베이스 장애에 응답하여) 구성될 수 있다. 일부 실시예들에서, 데이터 페이지들 및/또는 변경 로그들은 다양한 구성(클라이언트를 대신하여 데이터베이스 시스템에 유지되고 있는 데이터베이스 테이블에 의해 명시될 수 있는)에 따라, 다수의 저장 노드에 걸쳐 미러링될 수 있다. 예를 들어, 상이한 실시예들에서, 데이터 또는 변경 로그들의 하나, 두 개, 또는 세 개의 복사본은 디폴트 구성, 애플리케이션 특정 지속 성능, 또는 클라이언트 명시 지속 성능에 따라, 하나, 두 개, 또는 세 개의 상이한 이용 가능 존들 또는 영역들 각각에 저장될 수 있다.

본 출원에서 사용되는 바와 같이, 이하의 용어들은 다양한 실시예들에 따라, 분산 데이터베이스-최적화 저장 시스템에 의해 데이터의 구조화를 설명하는데 사용될 수 있다.

볼륨: 볼륨은 저장 시스템의 사용자/클라이언트/애플리케이션이 이해하는 저장소의 매우 지속 가능한 유닛을 나타내는 논리 개념이다. 보다 구체적으로, 볼륨은 데이터베이스 테이블의 다양한 사용자 페이지들에 대한 기록 동작들의 단일의 일관된 순서의 로그로서 사용자/클라이언트/애플리케이션에 나타나는 분산 저장이다. 각 기록 동작은 사용자 로그 레코드(ULR; User Log Record)로 인코딩될 수 있고, 이는 볼륨 내 단일 사용자 페이지의 콘텐츠에 대한 논리, 순서 변형을 나타낸다. 상기에서 언급된 바와 같이, ULR은 또한 본 출원에서 리두 로그 레코드로서 지칭될 수 있다. 각 URL은 포함할 수 고유의 식별자(예를 들어, 논리 시퀀스 번호(LSN; Logical Sequence Number), 타임 스탬프 등)를 포함할 수 있다. 고유 식별자가 점증적으로 증가되고 로그 레코드들 중 특정한 로그 레코드에 고유할 수 있다는 것을 주의하자. 또한 로그 레코드들에 할당되는 식별자들의 시퀀스에 갭들이 존재할 수 있다는 것을 주의하자. 예를 들어, LSN 예에서, LSN들 1, 4, 5, 6, 및 9가 다섯 개의 각각의 로그 레코드에 할당될 수 있으며 LSN들 2, 3, 7, 및 8은 사용되지 않는다. 각 URL은 URL에 높은 지속성 및 이용 가능성을 제공하기 위해, 보호 그룹(PG; Protection Group)을 형성하는 분산 저장에서의 하나 이상의 동기식 세그먼트에 지속될 수 있다. 볼륨은 LSN-유형의 판독/기록 인터페이스에 가변 크기의 인접 범위의 바이트들을 제공할 수 있다.

일부 실시예들에서, 볼륨은 각각이 보호 그룹을 통해 지속 가능한, 다수의 범위로 구성될 수 있다. 이러한 실시예들에서, 볼륨은 이변 인접 시퀀스의 볼륨 범위들로 구성되는 저장소의 유닛을 나타낼 수 있다. 볼륨에 지시되는 판독들 및 기록들은 구성 볼륨 범위들에 대응하는 판독들 및 기록들로 매핑될 수 있다. 일부 실시예들에서, 볼륨의 크기는 볼륨의 말단으로부터 볼륨 범위들을 추가 또는 제거함으로써 변경될 수 있다.

세그먼트: 세그먼트는 단일 저장 노드에 할당되는 저장소의 제한 지속성 유닛이다. 보다 구체적으로, 세그먼트는 특정한 고정 크기 바이트 범위의 데이터를 위해 제한된 최선 노력 지속성(예를 들어, 영구적이나, 저장 노드인 고장의 비-리던던트 단일 지점)을 제공한다. 이러한 데이터는 일부 경우들에서 사용자 주소 지정 가능한 데이터의 미러일 수 있거나, 그것은 다양한 실시예들에서, 볼륨 메타데이터 또는 소거 코딩된 비트들과 같은, 다른 데이터일 수 있다. 소정의 세그먼트는 정확히 하나의 저장 노드에 존재할 수 있다. 저장 노드 내에, 다수의 세그먼트는 각 SSD에 존재할 수 있고, 각 세그먼트는 하나의 SSD로 한정될 수 있다(예를 들어, 세그먼트는 다수의 SSD에 걸쳐 이어지지 않을 수 있다). 일부 실시예들에서, 세그먼트는 SSD 상의 인접 영역을 점유하도록 요구되지 않을 수 있다; 오히려 세그먼트의 각각에 의해 소유되는 영역을 설명하는 각 SSD에서의 할당 맵이 존재할 수 있다. 상기에서 언급한 바와 같이, 보호 그룹은 다수의 저장 노드에 걸쳐 확산되는 다수의 세그먼트로 구성될 수 있다. 일부 실시예들에서, 세그먼트는 LSN-유형의 판독/기록 인터페이스에 고정 크기 인접 범위의 바이트들을 제공할 수 있다(여기서 크기는 생성 시 정의된다). 일부 실시예들에서, 각 세그먼트는 세그먼트 UUID(예를 들어, 세그먼트의 보편적 고유 식별자)에 의해 식별될 수 있다.

저장 페이지: 저장 페이지는 메모리의 블록이고, 이는 일반적으로 고정 크기를 가진다. 일부 실시예들에서, 각 페이지는 운영 시스템에 의해 정의되는 크기의 메모리의(예를 들어, 가상 메모리, 디스크, 또는 다른 물리 메모리의) 블록이고, 또한 본 출원에서 용어 "데이터 블록"에 의해 지칭될 수 있다. 보다 구체적으로, 저장 페이지는 인접 섹터들의 세트일 수 있다. 그것은 SSD들에서의 할당 유닛으로, 뿐만 아니라 헤더 및 메타데이터가 존재하는 로그 페이지들에서의 유닛으로 역할을 할 수 있다. 일부 실시예들에서, 그리고 본 출원에 설명된 데이터베이스 시스템들의 맥락에서, 용어 "페이지" 또는 "저장 페이지"는 데이터베이스 구성에 의해 정의되는 크기의 유사한 블록을 나타낼 수 있는데, 이는 전형적으로 4096, 8192, 16384, 또는 32768 바이트와 같은, 2의 배수일 수 있다.

로그 페이지: 로그 페이지는 저장 로그 레코드들(예를 들어, 리두 로그 레코드 또는 언두 로그 레코드들)에 사용되는 저장 페이지의 유형이다. 일부 실시예들에서, 로그 페이지들은 저장 페이지들과 크기가 동일할 수 있다. 각 로그 페이지는 해당 로그 페이지에 대한 메타데이터 예를 들어, 그것이 속하는 세그먼트를 식별하는 메타데이터를 포함하는 헤더를 포함할 수 있다. 로그 페이지는 구조화 유닛이고 기록 동작들에 포함되는 데이터 유닛일 필요는 없을 수 있다는 것을 주의하자. 예를 들어, 일부 실시예들에서, 정상적인 순방향 프로세싱 동안, 기록 동작들은 동시에 하나의 섹터를 로그의 테일에 기록할 수 있다.

로그 레코드들: 로그 레코드들(예를 들어, 로그 페이지의 개별적인 요소들)은 몇몇 상이한 클래스를 가질 수 있다. 예를 들어, 저장 시스템의 사용자들/클라이언트들/애플리케이션들에 의해 생성 및 이해될 수 있는, 사용자 로그 레코드들(URL들)은 볼륨에서 사용자 데이터에 대한 변경들을 나타내는데 사용될 수 있다. 저장 시스템에 의해 생성되는, 제어 로그 레코드들(CLR들)은 현재 무조건적인 볼륨 지속 가능 LSN(VDL)과 같은 메타데이터를 계속 추적하는데 사용되는 제어 정보를 포함할 수 있다. 널 로그 레코드들(NLR들)은 일부 실시예들에서 로그 섹터 또는 로그 페이지에서의 미사용 공간을 채우기 위한 패딩(padding)으로서 사용될 수 있다. 일부 실시예들에서, 이들 클래스들 각각 내 다양항 유형들의 로그 레코드들일 수 있고, 로그 레코드의 유형은 로그 레코드를 해석하는데 적용되어야 하는 기능에 대응할 수 있다. 예를 들어, 하나의 유형은 특정한 압축 포맷을 사용하여 압축된 포맷으로 사용자 페이지의 모든 데이터를 나타낼 수 있고; 제2 유형은 사용자 페이지 내 바이트 범위의 신규 값들을 나타낼 수 있고; 제3 유형은 정수로서 해석되는 바이트들의 시퀀스에 대한 증분 동작을 나타낼 수 있으며; 제4 유형은 페이지 내 또 다른 장소에 한 바이트 범위를 복사하는 것을 포함할 수 있다. 일부 실시예들에서, 로그 레코드 유형들은 GUID들에 의해(정수들 또는 이넘들(enums)에 의해서가 아니라) 식별될 수 있는데, 이는 단순히 특히 ULR들을 위한, 버저닝(versioning) 및 개발일 수 있다.

페이로드: 로그 레코드의 페이로드는 특정한 유형의 로그 레코드 또는 로그 레코드들에 특수한 데이터 또는 파라미터 값들이다. 예를 들어, 일부 실시예들에서, 대부분(또는 모든) 로그 레코드들이 포함하고, 저장 시스템 그 자체가 이해하는 파라미터들 또는 속성들의 세트가 존재할 수 있다. 이들 속성들은 공통 로그 레코드 헤더/구조의 부분일 수 있는데, 이는 섹터 크기와 비교할 때 상대적으로 작을 수 있다. 또한, 대부분의 로그 레코드들은 해당 로그 레코드 유형에 특수한 추가적인 파라미터들 또는 데이터를 포함할 수 있고, 이러한 추가적인 데이터는 해당 로그 레코드의 페이로드로 간주될 수 있다. 일부 실시예들에서, 특정한 URL에 대한 페이로드가 사용자 페이지 크기보다 크다면, 그것은 그것의 페이로드가 사용자 페이지에 대한 모든 데이터를 포함하는 절대적 URL(AURL)에 의해 대체될 수 있다. 이는 저장 시스템이 사용자 페이지들의 크기와 동일한 ULR들에 대한 페이로드의 크기에 대한 상한을 강화하는 것을 가능하게 할 수 있다.

저장 로그 레코드들이 세그먼트 로그에 있을 때, 페이로드는 일부 실시예들에서, 로그 헤더와 함께 저장될 수 있다는 것을 주의하자. 다른 실시예들에서, 페이로드는 개별 장소에 저장될 수 있고, 페이로드가 저장되는 장소에 대한 포인터들은 로그 헤더와 저장될 수 있다. 또 다른 실시예들에서, 페이로드의 일부는 헤더에 저장될 수 있고, 페이로드의 잔여 부분은 개별 장소에 저장될 수 있다. 전체 페이로드가 로그 헤더와 저장된다면, 이는 대역 내 저장소로 지칭될 수 있고; 그 외 저장소는 대역 외인 것으로서 지칭될 수 있다. 일부 실시예들에서, 대부분의 대형 AULR들의 페이로드들은 로그의 콜드 존(아래에서 설명될)에서 대역 외에 저장될 수 있다.

사용자 페이지들: 사용자 페이지들은 저장 시스템의 사용자들/클라이언트들에 가시적인 특정한 볼륨을 위한 바이트 범위들(고정된 크기의) 및 그것의 정렬들이다. 사용자 페이지들은 논리 개념이고, 특정한 사용자 페이지들의 바이트들은 그대로 임의의 저장 페이지에 저장될 수 있거나 저장되지 않을 수 있다. 특정한 볼륨에 대한 사용자 페이지들의 크기는 해당 볼륨에 대한 저장 페이지 크기에 독립적일 수 있다. 일부 실시예들에서, 사용자 페이지 크기는 볼륨마다 구성 가능할 수 있고, 저장 노드 상의 상이한 세그먼트들은 상이한 사용자 페이지 크기들을 가질 수 있다. 일부 실시예들에서, 사용자 페이지 크기들은 다수의 섹터 크기(예를 들어, 4KB)이도록 제한될 수 있고, 상한(예를 들어, 64KB)을 가질 수 있다. 반면에, 저장 페이지 크기는 전체 저장 노드에 대해 고정될 수 있고 기본 하드웨어에 대한 변경이 존재하지 않는 한 변하지 않을 수 있다.

데이터 페이지: 데이터 페이지는 압축된 포맷으로 사용자 페이지 데이터를 저장하는데 사용되는 저장 페이지의 유형이다. 일부 실시예들에서 데이터 페이지에 저장되는 데이터의 모든 조각은 로그 레코드와 연관되고, 각 로그 레코드는 데이터 페이지(또한 데이터 섹터로 지칭되는) 내 섹터에 대한 포인터를 포함할 수 있다. 일부 실시예들에서, 데이터 페이지들은 각 섹터에 의해 제공되는 것이 아닌 임의의 내장된 메타데이터를 포함하지 않을 수 있다. 데이터 페이지 내 섹터들 간 어떤 관계도 존재하지 않을 수 있다. 대신에, 페이지들로의 구조화는 세그먼트에 대한 데이터의 할당의 세분화의 표현으로서 단지 존재할 수 있다.

저장 노드: 저장 노드는 저장 노드 서버 코드가 배치되는 단일 가상 기계이다. 각 저장 노드는 다수의 지역적으로 연결된 SSD을 포함할 수 있고, 하나 이상의 세그먼트에의 액세스를 위한 네트워크 API를 제공할 수 있다. 일부 실시예들에서, 다양한 노드들은 활성화 리스트 상에 또는 저하된 리스트 상에(예를 들어, 그것들이 응답하기에 느리거나 다르게 손상을 입은 경우, 그러나 완전히 사용 불가능하지 않은 경우) 있을 수 있다. 일부 실시예들에서, 클라이언트-측 드라이버는 노드들이 대체되어야 할 경우 및 대체되어야 할 때를 결정하기 위해, 그리고/또는 관측된 성능에 기초하여, 다양한 노드들 중에 데이터를 재분산할 때 및 재분산하는 방법을 결정하기 위해, 노드들을 활성 또는 저하로서 분류하는 것을 보조할 수 있다(또는 그것에 책임이 있을 수 있다).

SSD: 본 출원에서 지칭되는 바와 같이, 용어 "SSD"는 해당 저장 볼륨, 예를 들어, 디스크, 고체 상태 드라이브, 배터리 백업형 RAM, NVMRAM 디바이스(예를 들어, 하나 이상의 NVDIMM), 또는 또 다른 유형의 영구 저장 디바이스에 의해 채용되는 저장소의 유형에 관계없이, 저장 노드에 의해 보여지는 바와 같이 로컬 블록 저장 볼륨을 나타낼 수 있다. SSD는 반드시 하드웨어에 직접 매핑될 필요는 없다. 예를 들어, 단일 고체 상태 저장 디바이스는 각 볼륨이 다수의 세그먼트로 분할되고 다수의 세그먼트에 걸쳐 나뉘는 다수의 로컬 볼륨으로 분산될 수 있고/있거나, 단일 드라이브는 상이한 실시예들에서, 단순히 관리의 용이함을 위해 다수의 볼륨으로 분산될 수 있다. 일부 실시예들에서, 각 SSD는 단일 고정 장소에 할당 맵을 저장할 수 있다. 이러한 맵은 특정한 세그먼트들에 의해 소유되는 저장 페이지들이 어느 것인지, 및 이들 중 로그 페이지들(데이터 페이지들이 아니라)인 페이지들이 어느 것인지를 나타낼 수 있다. 일부 실시예들에서, 저장 페이지들은 순방향 프로세싱이 할당을 기다릴 필요가 없을 수 있도록 각 세그먼트에 미리 할당될 수 있다. 할당 맵에 대한 임의의 변경들은 새로 할당된 저장 페이지들이 세그먼트들에 의해 사용되기 전에 지속 가능하게 되어야 할 수 있다.

분산 데이터베이스-최적화 저장 시스템의 일 실시예는 도 4의 블록도에 의해 예시된다. 이 예에서, 데이터베이스 시스템(400)은 분산 데이터베이스-최적화 저장 시스템(410)을 포함하는데, 이는 상호연결부(460)를 통해 데이터베이스 엔진 헤드 노드(420)와 통신한다. 도 3에 예시된 예에서와 같이, 데이터베이스 엔진 헤드 노드(420)는 클라이언트-측 저장 서비스 드라이버(425)를 포함할 수 있다. 이 예에서, 분산 데이터베이스-최적화 저장 시스템(410)은 다수의 저장 시스템 서버 노드(430, 440, 및 450으로 도시된 것들을 포함하는)를 포함하는데, 그 각각은 그것이 저장하는 세그먼트(들)을 위한 데이터 페이지들 및 리두 로그들을 위한 저장소, 및 다양한 관리 기능을 수행하도록 구성되는 하드웨어 및/또는 소프트웨어를 포함한다. 예를 들어, 각 저장 시스템 서버 노드는 다음의 동작들: 복제(지역적으로, 예를 들어, 저장 노드 내), 데이터 페이지들을 생성하기 위한 리두 로그들의 병합, 스냅샷들(예를 들어, 생성하는 것, 복구, 삭제 등), 로그 관리(예를 들어, 로그 레코드들을 조작하는 것), 장애 복구, 및/또는 공간 관리(예를 들어, 세그먼트를 위한) 중 임의의 또는 모든 동작의 적어도 일부를 수행하도록 구성되는 하드웨어 및/또는 소프트웨어를 포함할 수 있다. 각 저장 시스템 서버 노드는 또한 데이터 블록들이 클라이언트들(예를 들어, 사용자들, 클라이언트 애플리케이션들, 및/또는 데이터베이스 서비스 가입자들)을 대신하여 저장될 수 있는 다수의 연결 저장 디바이스(예를 들어, SSD들)를 가질 수 있다.

도 4에 예시된 예에서, 저장 시스템 서버 노드(430)는 데이터 페이지(들)(433), 세그먼트 리두 로그(들)(435), 세그먼트 관리 기능들(437), 및 연결 SSD들(471 내지 478)을 포함한다. 다시 라벨 "SSD"는 고체 상태 드라이브를 나타낼 수 있거나 나타내지 않을 수 있으나, 보다 일반적으로 그것의 기본 하드웨어와 관계없이, 로컬 블록 저장 볼륨을 나타낼 수 있다는 것을 주의하자. 이와 유사하게, 저장 시스템 서버 노드(440)는 데이터 페이지(들)(443), 세그먼트 리두 로그(들)(445), 세그먼트 관리 기능들(447), 및 연결 SSD들(481 내지 488)을 포함한다; 그리고 저장 시스템 서버 노드(450)는 데이터 페이지(들)(453), 세그먼트 리두 로그(들)(455), 세그먼트 관리 기능들(457), 및 연결 SSD들(491 내지 498)을 포함한다.

이전에 언급한 바와 같이, 일부 실시예들에서, 섹터는 SSD 상의 정렬 유닛이고 기록이 단지 부분적으로만 완전할 리스크 없이 기록될 수 있는 SSD 상에서 최대 크기일 수 있다. 예를 들어, 다양한 고체 상태 드라이브들 및 스피닝 매체(spinning media)에 대한 섹터 크기는 4KB일 수 있다. 본 출원에 설명된 분산 데이터베이스-최적화 저장 시스템들의 일부 실시예들에서, 각 및 모든 섹터는 섹터가 부분인 상위 레벨 개체와 관계없이, 섹터의 시작에서 64-비트(8 바이트) CRC를 가질 수 있다. 이러한 실시예들에서, 이러한 CRC(섹터가 SSD로부터 판독되는 시간마다 인증될 수 있는)는 손상들을 검출하는데 사용될 수 있다. 일부 실시예들에서, 각 및 모든 섹터는 또한 그 값이 로그 섹터, 데이터 섹터, 또는 초기화되지 않은 섹터로서의 섹터인지를 식별하는 "섹터 유형" 바이트를 포함할 수 있다. 예를 들어, 일부 실시예들에서, 0의 섹터 유형 바이트 값은 섹터가 초기화되지 않은 것을 나타낼 수 있다.

일부 실시예들에서, 분산 데이터베이스-최적화 저장 시스템에서의 저장 시스템 서버 노드들 각각은 예를 들어, 리두 로그들을 수신하고, 데이터 페이지들을 다시 송신하는 등을 위해, 데이터베이스 엔진 헤드 노드와의 통신을 관리하는 노드 서버의 운영 시스템 상에서 작동하는 프로세스들의 세트를 구현할 수 있다. 일부 실시예들에서, 분산 데이터베이스-최적화 저장 시스템에 기록된 모든 데이터 블록은 장기 및/또는 아카이벌 저장소에(예를 들어, 원격 키-값 지속 가능 백업 저장 시스템에) 백업될 수 있다.

도 5는 일 실시예에 따라, 데이터베이스 시스템에서의 개별 분산 데이터베이스-최적화 저장 시스템의 사용을 예시하는 블록도이다. 이 예에서, 하나 이상의 클라이언트 프로세스(510)는 데이터를 데이터베이스 엔진(520) 및 분산 데이터베이스-최적화 저장 시스템(530)을 포함하는 데이터베이스 시스템에 의해 유지되는 하나 이상의 데이터베이스 테이블에 저장할 수 있다. 도 5에 예시된 예에서, 데이터베이스 엔진(520)은 데이터베이스 티어 구성요소들(560) 및 클라이언트-측 드라이버(540)(분산 데이터베이스-최적화 저장 시스템(530) 및 데이터베이스 티어 구성요소들(560) 간 인터페이스로서 역할을 하는)를 포함한다. 일부 실시예들에서, 데이터베이스 티어 구성요소들(560)은 도 3의 질의 분석, 최적화 및 실행 구성요소(305) 및 트랜잭션 및 일관성 관리 구성요소(330)에 의해 수행되는 것들과 같은 기능들을 수행할 수 있고/있거나, 데이터 페이지들, 트랜잭션 로그들 및/또는 언두 로그들(도 3의 데이터 페이지 캐시(335)에 의해 저장되는 것들, 트랜잭션 로그(340) 및 언두 로그(345)와 같은)을 저장할 수 있다.

이 예에서, 하나 이상의 클라이언트 프로세스(510)는 데이터베이스 티어 구성요소들(560)에 데이터베이스 질의 요청들(515)(하나 이상의 저장 노드(535a 내지 535n) 상에 저장된 데이터를 타겟팅하는 판독 및/또는 기록 요청들을 포함할 수 있는)을 송신할 수 있고, 데이터베이스 티어 구성요소들(560)로부터 데이터베이스 질의 응답들(517)(예를 들어, 기록 확인 응답들 및/또는 요청된 데이터를 포함하는 응답들)을 수신할 수 있다. 데이터 페이지에 기록하기 위한 요청을 포함하는 각 데이터베이스 질의 요청(515)은 하나 이상의 기록 레코드 요청(541)을 생성하기 위해 분석되고 최적화될 수 있는데, 이는 분산 데이터베이스-최적화 저장 시스템(530)에 후속하여 라우팅하기 위해 클라이언트-측 드라이버(540)에 송신될 수 있다. 이 예에서, 클라이언트-측 드라이버(540)는 기록 레코드 요청(541)에 대응하는 하나 이상의 리두 로그 레코드(531)를 생성할 수 있고, 그것들을 분산 데이터베이스-최적화 저장 시스템(530)의 저장 노드들(535) 중 특정한 저장 노드들에 송신할 수 있다. 분산 데이터베이스-최적화 저장 시스템(530)은 데이터베이스 엔진(520)에(구체적으로 클라이언트-측 드라이버(540)에) 각 리두 로그 레코드(531)에 대한 대응하는 기록 확인 응답(532)을 리턴할 수 있다. 클라이언트-측 드라이버(540)는 데이터베이스 티어 구성요소들(560)에 이들 기록 확인 응답들(기록 응답들(542)와 같은)을 전달할 수 있는데, 이는 그 후 데이터베이스 질의 응답들(517)로서 하나 이상의 클라이언트 프로세스(510)에 대응하는 응답들(예를 들어, 기록 확인 응답들)을 송신할 수 있다.

이 예에서, 데이터 페이지를 판독하기 위한 요청을 포함하는 각 데이터베이스 질의 요청(515)은 하나 이상의 판독 레코드 요청(543)을 생성하기 위해 분석되고 최적화될 수 있는데, 이는 분산 데이터베이스-최적화 저장 시스템(530)에 후속하여 라우팅하기 위해 클라이언트-측 드라이버(540)에 송신될 수 있다. 이 예에서, 클라이언트-측 드라이버(540)는 이들 요청들을 분산 데이터베이스-최적화 저장 시스템(530)의 저장 노드들(535) 중 특정한 저장 노드들에 송신할 수 있고, 분산 데이터베이스-최적화 저장 시스템(530)은 데이터베이스 엔진(520)에(구체적으로 클라이언트-측 드라이버(540)에) 요청된 데이터 페이지들(533)을 리턴할 수 있다. 클라이언트-측 드라이버(540)는 리턴 데이터 레코드들(544)로서 요청된 데이터 페이지들을 데이터베이스 티어 구성요소들(560)에 송신할 수 있고, 그 후 데이터베이스 티어 구성요소들(560)은 데이터베이스 질의 요청들(517)로서 데이터 페이지들을 하나 이상의 클라이언트 프로세스(510)에 송신할 수 있다.

일부 실시예들에서, 다양한 에러 및/또는 데이터 손실 메시지들(534)은 데이터베이스 엔진(520)에(구체적으로 클라이언트-측 드라이버(540)에) 분산 데이터베이스-최적화 저장 시스템(530)으로부터 송신될 수 있다. 이들 메시지들은 에러 및/또는 손실 보고 메시지들(545)로서 클라이언트-측 드라이버(540)로부터 데이터베이스 티어 구성요소들(560)에, 그리고 그 후 데이터베이스 질의 응답(517)과 함께(또는 그 대신) 하나 이상의 클라이언트 프로세스(510)에 전달될 수 있다.

일부 실시예들에서, 분산 데이터베이스-최적화 저장 시스템(530)의 API들(531 내지 534) 및 클라이언트-측 드라이버(540)의 API들(541 내지 545)은 데이터베이스 엔진(520)이 분산 데이터베이스-최적화 저장 시스템(530)의 클라이언트인 것처럼 데이터베이스 엔진(520)에 분산 데이터베이스-최적화 저장 시스템(530)의 기능을 노출시킬 수 있다. 예를 들어, 데이터베이스 엔진(520)(클라이언트-측 드라이버(540)를 통해)은 데이터베이스 엔진(520) 및 분산 데이터베이스-최적화 저장 시스템(530)의 조합에 의해 구현되는 데이터베이스 시스템의 다양한 동작들(예를 들어, 저장, 액세스, 변경 로깅, 복구, 및/또는 공간 관리 동작들)을 수행하기 위해(또는 그것들의 수행을 용이하게 하기 위해) 이들 API들을 통해 리두 로그 레코드들 또는 요청 데이터 페이지들을 기록할 수 있다. 도 5에 예시된 바와 같이, 분산 데이터베이스-최적화 저장 시스템(530)은 저장 노드들(535a 내지 535n) 상에 데이터 블록들을 저장할 수 있고, 그 각각은 다수의 연결 SSD들을 가질 수 있다. 일부 실시예들에서, 분산 데이터베이스-최적화 저장 시스템(530)은 다양한 유형들의 리던던시 기법의 애플리케이션을 통해 저장된 데이터 블록에 높은 지속성을 제공할 수 있다.

다양한 실시예들에서, 도 5의 데이터베이스 엔진(520) 및 분산 데이터베이스-최적화 저장 시스템(530) 간 API 호들 및 응답들(예를 들어, API들(531 내지 534)) 및/또는 클라이언트-측 드라이버(540) 및 데이터베이스 티어 구성요소들(560) 간 API 호들 및 응답들(예를 들어, API들(541 내지 545))은 보안 프록시 연결(예를 들어, 게이트웨이 제어 평면에 의해 관리되는 것)을 통해 수행될 수 있거나, 공중 네트워크를 통해 또는, 대안적으로, 가상 사설 네트워크(VPN) 연결과 같은 사설 채널을 통해 수행될 수 있다. 본 출원에 설명된 데이터베이스 시스템들의 구성요소들에 대한 및/또는 구성요소들 간 이들 및 다른 API들은 이들에 제한되지 않으나, SOAP(Simple Object Access Protocol) 기술 및 REST(Representational state transfer)를 포함하는, 상이한 기술들에 따라 구현될 수 있다. 예를 들어, 이들 API들은 반드시는 아니나, SOAP API들 또는 RESTful API들로서 구현될 수 있다. SOAP는 웹 기반 서비스들의 맥락에서 정보를 교환하기 위한 프로토콜이다. REST는 분산 하이퍼미디어 시스템들을 위한 아키텍처 유형이다. RESTful API(또한 RESTful 웹 서비스로 지칭될 수 있는)는 HTTP 및 REST 기술을 사용하여 구현되는 웹 서비스 API이다. 본 출원에에 설명된 API들은 일부 실시예들에서 데이터베이스 엔진(520) 및/또는 분산 데이터베이스-최적화 저장 시스템(530)과의 통합을 지원하기 위해 이들에 제한되지는 않으나, C, C++, Java, C# 및 Perl을 포함하는, 다양한 언어들로 클라이언트 라이브러리들로 랩핑될 수 있다.

상기에서 언급한 바와 같이, 일부 실시예들에서, 데이터베이스 시스템의 기능 구성요소들은 데이터베이스 엔진에 의해 수행되는 구성요소들들 및 개별, 분산, 데이터베이스-최적화 저장 시스템에서 수행되는 구성요소들 사이에 분배될 수 있다. 하나의 특정한 예에서, 데이터베이스 테이블로 무언가를 삽입하기 위해(예를 들어, 해당 데이터 블록에 레코드를 추가함으로써 단일 데이터 블록을 업데이트하기 위해) 클라이언트 프로세스(또는 그것의 스레드)로부터 요청을 수신하는 것에 응답하여, 데이터베이스 엔진 헤드 노드의 하나 이상의 구성요소는 질의 분석, 최적화, 및 실행을 수행할 수 있고, 질의의 각 부분을 트랜잭션 및 일관성 관리 구성요소에 송신할 수 있다. 트랜잭션 및 일관성 관리 구성요소는 다른 어떤 클라이언트 프로세스(또는 그것의 스레드)도 동시에 동일한 행을 변형하려 시도하고 있지 않다는 것을 보장할 수 있다. 예를 들어, 트랜잭션 및 일관성 관리 구성요소는 이러한 변경은 원자적으로, 일관적으로, 지속적으로, 및 데이터베이스에서 분리된 방식으로 수행되는 것을 보장하는 것에 책임이 있을 수 있다. 예를 들어, 트랜잭션 및 일관성 관리 구성요소는 분산 데이터베이스-최적화 저장 서비스에서 노드들 중 하나에 송신될 리두 로그 레코드를 생성하기 위해 그리고 그것들을 순서대로 및/또는 ACID 속성들이 이러한 트랜잭션을 위해 충족되는 것을 보장하는 타이밍에 분산 데이터베이스-최적화 저장 서비스로 송신하기 위해(다른 클라이언트 요청들에 응답하여 생성된 다른 리두 로그 레코드과 함께) 데이터베이스 엔진 헤드 노드의 클라이언트-측 저장 서비스 드라이버와 함께 작동할 수 있다. 리두 로그 레코드(또한 업데이트 레코드로 지칭될 수 있는)를 수신 시, 대응하는 저장 노드는 데이터 블록을 업데이트할 수 있고, 데이터 블록을 위한 리두 로그 레코드(예를 들어, 데이터 블록에 지시되는 모든 변경들의 레코드)를 업데이트할 수 있다. 일부 실시예들에서, 데이터베이스 엔진은 이러한 변경을 위한 언두 로그 레코드를 생성하는 것에 책임이 있을 수 있고, 또한 트랜잭션성을 보장하기 위해 지역적으로(데이터베이스 티어 내에서) 사용될 수 있는 리두 로그 레코드 및 언두 로그 레코드 양자를 생성하는 것에 책임이 있을 수 있다. 그러나, 전통적인 데이터베이스 시스템과 달리, 본 출원에 설명된 시스템들은 변경들을 데이터 블록들에 적용(데이터베이스에의 데이터 블록들을 적용하는 것 및 변경된 데이터 블록들을 저장 시스템에 수송하는 것이 아닌)하기 위한 책임을 저장 시스템에 전가할 수 있다. 게다가, 본 출원에 도 8 및 도 9에서 설명되는 바와 같이, 다양한 실시예들에서, 스냅샷 동작들 및/또는 로그 조작들은 또한 저장 시스템에 의해 수행될 수 있다.

다양한 상이한 할당 모델이 상이한 실시예들에서, SSD를 위해 구현될 수 있다. 예를 들어, 일부 실시예들에서, 로그 엔트리 페이지들 및 애플리케이션 페이지들은 SSD 디바이스와 연관된 페이지들의 단일 히프(heap)로부터 할당될 수 있다. 이러한 접근법은 불특정으로 유지하기 위한 그리고 사용에 자동적으로 적응시키기 위한 로그 페이지들 및 데이터 페이지들에 의해 소모되는 상대적인 저장량을 허용하는 이점을 가질 수 있다. 그것은 또한 페이지들이 그것들이 사용될 때까지 준비되지 않은 상태로, 및 준비 없이 자유로이 다른 목적에 맞게 고치도록 유지하는 것을 허용하는 이점을 가질 수 있다. 다른 실시예들에서, 할당 모델은 저장 디바이스를 로그 엔트리들 및 데이터 페이지들을 위한 개별 공간들로 분배할 수 있다. 그러한 할당 모델이 도 6의 블록도에 의해 예시되고 아래에 설명된다.

도 6은 일 실시예에 따라, 데이터 및 메타데이터가 분산 데이터베이스-최적화 저장 시스템의 소정의 저장 노드(또는 영구 저장 디바이스)에 저장될 수 있는 방법을 예시하는 블록도이다. 이 예에서, SSD 저장 공간(600)은 라벨링된 공간의 일부(610)에 SSD 헤더 및 다른 고정 메타데이터를 저장한다. 그것은 라벨링된 공간의 일부(620)에 로그 페이지들을 저장하고, 추가적인 로그 페이지들을 위해 초기화 및 예약 할당되는 라벨링된 공간(630)을 포함한다. SSD 저장 공간(600)의 일부(640으로 도시된)는 초기화되나, 비할당되고, 공간의 다른 부분(650으로 도시된)은 비초기화 및 비할당된다. 마지막으로, 라벨링된 SSD 저장 공간(600)의 일부(660)는 데이터 페이지들을 저장한다.

이 예에서, 처음 사용 가능한 로그 페이지 슬롯은 615으로 언급되고, 마지막으로 사용된 로그 페이지 슬롯(단기)은 625로 언급된다. 마지막으로 예약 할당된 로그 페이지 슬롯은 635로 언급되고, 마지막 사용 가능한 로그 페이지 슬롯은 645로 언급된다. 이 예에서, 처음 사용된 데이터 페이지 슬롯(단기)는 665로 언급된다. 일부 실시예들에서, SSD 저장 공간(600) 내 이들 요소들의 각각(615, 625, 635, 645, 및 665)의 위치들은 각각의 포인터에 의해 식별될 수 있다.

도 6에 예시된 할당 접근법에서, 유효한 로그 페이지들은 플랫 저장 공간의 시작으로 패킹될 수 있다. 자유롭게 된 로그 페이지들로 인해 이용할 수 있게 된 홀들은 어드레스 공간까지 더 먼 추가적인 로그 페이지 슬롯들이 사용되기 전에 재사용될 수 있다. 예를 들어, 최악의 경우, 처음 n 로그 페이지 슬롯들은 유효한 로그 데이터를 포함하고, 여기서 n은 동시에 존재한 적 없는 최다수의 유효한 로그 페이지들이다. 이 예에서, 유효한 데이터 페이지들은 플랫 저장 공간의 마지막으로 패킹될 수 있다. 자유롭게 된 데이터 페이지들로 인해 이용할 수 있게 된 홀들은 어드레스 공간에서 더 낮은 추가적인 로그 페이지 슬롯들이 사용되기 전에 재사용될 수 있다. 예를 들어, 최악의 경우, 처음 m 데이터 페이지들은 유효한 데이터를 포함하고, 여기서 m은 동시에 존재한 적 없는 최다수의 유효한 데이터 페이지들이다.

일부 실시예들에서, 로그 페이지 슬롯이 유효한 로그 페이지 엔트리들의 잠재적인 세트의 부분이 될 수 있기 전에, 그것은 유효한 장래 로그 엔트리 페이지에 대해 혼동될 수 없는 값으로 초기화되어야 한다. 이는 회수된 로그 페이지가 신규 유효 로그 페이지에 대해 절대 혼동되지 않을 충분한 메타데이터를 갖기 때문에, 재활용된 로그 페이지 슬롯들에 대해 함축적으로 사실이다. 그러나, 저장 디바이스가 처음 초기화될 때, 또는 애플리케이션 데이터 페이지들을 저장하는데 잠재적으로 사용된 공간이 재활용될 때, 로그 페이지 슬롯들은 그것들이 로그 페이지 슬롯 풀에 추가되기 전에 초기화되어야 한다. 일부 실시예들에서, 재균형/재활용 로그 공간은 백그라운드 태스크로서 수행될 수 있다.

도 6에 예시된 예에서, 현재 로그 페이지 슬롯 풀은 처음 사용 가능한 로그 페이지 슬롯(615에서) 및 마지막으로 예약 할당된 로그 페이지 슬롯(625) 사이에 영역을 포함한다. 일부 실시예들에서, 이러한 풀은 신규 로그 페이지 슬롯들의 재-초기화 없이 마지막으로 사용 가능한 로그 페이지 슬롯(625)까지 안전하게 확대될 수 있다(예를 들어, 마지막으로 예약 할당된 로그 페이지 슬롯들, 635를 식별하는 포인터에 대한 업데이트를 지속함으로써). 이 예에서, 마지막으로 사용 가능한 로그 페이지 슬롯(포인터(645)에 의해 식별되는)을 지나, 풀은 초기화된 로그 페이지 슬롯들을 지속하고 마지막으로 사용 가능한 로그 페이지 슬롯(645)에 대한 포인터를 지속적으로 업데이트함으로써 처음으로 사용된 데이터 페이지 슬롯(포인터(665)에 의해 식별되는)까지 확대될 수 있다. 이 예에서, 650으로 도시된 SSD 저장 공간(600)의 이전에 비초기화 및 비할당된 부분은 로그 페이지들을 저장하기 위한 서비스로 유도될 수 있다. 일부 실시예들에서, 현재 로그 페이지 슬롯 풀은 마지막으로 예약 할당된 로그 페이지 슬롯에 대한 포인터(635)에 대한 업데이트를 지속함으로써 마지막으로 사용된 로그 페이지 슬롯(포인터에 의해 식별되는)의 위치 아래로 축소될 수 있다.

도 6에 예시된 예에서, 현재 데이터 페이지 슬롯 풀은 마지막으로 사용 가능한 로그 페이지 슬롯(포인터(645)에 의해 식별되는) 및 SSD 저장 공간(600)의 마지막 사이에 영역을 포함한다. 일부 실시예들에서, 데이터 페이지 풀은 마지막으로 사용 가능한 로그 페이지 슬롯(645)에 대한 포인터에 대한 업데이트를 지속함으로써 마지막으로 예약 할당된 로그 페이지 슬롯(635)에 대한 포인터에 의해 식별되는 위치로 안전하게 확대될 수 있다. 이 예에서, 640으로 도시된 SSD 저장 공간(600)의 이전에 초기화되었으나, 비할당된 부분은 데이터 페이지들을 저장하기 위한 서비스로 유도될 수 있다. 이를 지나, 풀은 로그 페이지들이 아닌 데이터 페이지들을 저장하기 위해 630 및 640으로 도시된 SSD 저장 공간(600)의 부분들을 효과적으로 재할당하여, 마지막으로 예약 할당된 로그 페이지 슬롯(635) 및 마지막으로 사용 가능한 로그 페이지 슬롯(645)에 대한 포인터들에 대한 업데이트들을 지속함으로써 마지막으로 사용된 로그 페이지 슬롯(625)에 의해 식별되는 위치로 안전하게 확대될 수 있다. 일부 실시예들에서, 데이터 페이지 슬롯 풀은 추가적인 로그 페이지 슬롯들을 초기화하고 마지막으로 사용 가능한 로그 페이지 슬롯(645)에 대한 포인터에 대한 업데이트를 지속함으로써 처음으로 사용된 데이터 페이지 슬롯(665)에 대한 포인터에 의해 식별되는 위치로 안전하게 축소될 수 있다.

도 6에 예시된 할당 접근법을 채용하는 실시예들에서, 로그 페이지 풀 및 데이터 페이지 풀에 대한 페이지 크기들은 여전히 양호한 패킹 동작을 용이하게 하면서, 독립적으로 선택될 수 있다. 이러한 실시예들에서, 추가적인 데이터에 의해 형성되는 스푸핑(spoofing)된 로그 페이지에 연결하는 유효한 로그 페이지의 어떤 가능성도 존재하지 않을 수 있고, 손상된 로그 및 아직 기록되지 않은 다음 페이지에 연결하는 유효한 로그 테일을 구별하는 것이 가능할 수 있다. 도 6에 예시된 할당 접근법을 채용하는 실시예들에서, 시작 시, 마지막으로 예약 할당된 로그 페이지 슬롯(635)에 대해 포인터에 의해 식별되는 위치까지의 모든 로그 페이지 슬롯은 빠르게 그리고 순차적으로 판독될 수 있고, 전체 로그 인덱스가 재구성될 수 있다(추론된 연결/순서화를 포함하여). 이러한 실시예들에서, 모든 것이 LSN 시퀀싱 제약으로부터 추론될 수 있기 때문에, 로그 페이지들 간 명백한 연결을 위한 어떤 요구도 존재하지 않을 수 있다.

일부 실시예들에서, 세그먼트는 세 개의 주요 부분(또는 존): 핫 로그를 포함하는 하나, 콜드 로그를 포함하는 하나, 및 사용자 페이지 데이터를 포함하는 하나로 구성될 수 있다. 존들은 반드시 SSD의 인접 영역들일 필요는 없다. 오히려, 그것들은 저장 페이지의 세분화로 산재될 수 있다. 또한, 세그먼트 및 그것의 속성들에 대한 메타데이터를 저장하는 각 세그먼트에 대한 루트 페이지가 존재할 수 있다. 예를 들어, 세그먼트를 위한 루트 페이지는 세그먼트에 대한 사용자 페이지 크기, 세그먼트에서의 사용자 페이지들의 수, 핫 로그 존의 현재 도입부/헤드(플러시 번호 형태로 레코딩될 수 있는), 볼륨 이포크(volume epoch), 및/또는 액세스 제어 메타데이터를 저장할 수 있다.

일부 실시예들에서, 핫 로그 존은 그것들이 저장 노드에 의해 수신됨에 따라 클라이언트로부터 신규 기록들을 수용할 수 있다. 페이지의 이전 버전으로부터 델타(delta) 형태로 사용자/데이터 페이지에 대한 변경을 명시하는, 델타 사용자 로그 레코드들(DULR들; Delta User Log Records), 및 완전한 사용자/데이터 페이지의 콘텐츠를 명시하는, 절대 사용자 로그 레코드들(AULR들; Absolute User Log Records) 양자는 완전하게 로그 내에 기록될 수 있다. 로그 레코드들은 대략 그것들이 수신되는(예를 들어, 그것들이 LSN에 의해 정렬되지 않는다) 순서로 이 존에 추가될 수 있고 그것들은 로그 페이지들에 걸쳐 이어질 수 있다. 로그 레코드들은 자체 기술할 수 있다, 예를 들어, 그것들은 그들 자체 크기의 표시를 포함할 수 있다. 일부 실시예들에서, 어떤 가비지 수집도 이 존에서 수행되지 않는다. 대신에, 공간은 모든 요구된 로그 레코드가 콜드 로그로 복사된 후 로그의 시작으로부터 절단됨으로써 재활용될 수 있다. 핫 존에서의 로그 섹터들은 섹터가 기록되는 각 시간마다 가장 최근에 알려진 무조건적인 VDL으로 주석이 첨가될 수 있다. 조건부 VDL CLR들은 그것들이 수신됨에 따라 핫 존 내에 기록될 수 있으나, 가장 최근에 기록된 VDL CLR이 의미있을 수 있다.

일부 실시예들에서, 신규 로그 페이지가 기록될 때마다, 그것은 플러시 번호로 할당될 수 있다. 플러시 번호는 각 로그 페이지 내 모든 섹터의 부분으로 기록될 수 있다. 플러시 번호들은 두 개의 로그 페이지를 비교할 때 어느 로그 페이지가 나중에 기록되었는지를 결정하는데 사용될 수 있다. 플러시 번호들은 단조롭게 증가하고 SSD(또는 저장 노드)로 스코프(scope)된다. 예를 들어, 단조롭게 증가하는 플러시 번호의 세트는 SSD 상의 모든 세그먼트들(또는 저장 노드 상의 모든 세그먼트들) 간에 공유된다.

일부 실시예들에서, 콜드 로그 존에서, 로그 레코드들은 그것들의 LSN들의 증가하는 순으로 저장될 수 있다. 이 존에서, AULR들은 반드시 그것들의 크기에 따라, 인-라인으로 데이터를 저장할 필요는 없을 수 있다. 예를 들어, 그것들이 큰 페이로드들을 가지면, 페이로드들의 전부 또는 일부는 데이터 존에 저장될 수 있고 그것들은 그것들의 데이터가 데이터 존에 저장되는 곳을 가리킬 수 있다. 일부 실시예들에서, 콜드 로그 존에서의 로그 페이지들은 섹터마다가 아니라, 동시에 하나의 완전한 페이지가 기록될 수 있다. 콜드 존에서의 로그 페이지들은 동시에 완전한 페이지가 기록되기 때문에, 모든 섹터들에서의 플러시 번호들이 동일하지 않은 콜드 존에서의 임의의 로그 페이지는 불완전하게 기록된 페이지로 간주될 수 있고 무시될 수 있다. 일부 실시예들에서, 콜드 로그 존에서, DULR들은 로그 페이지들에 걸쳐 이어질 수 있을 수 있다(최대 두 로그 페이지까지). 그러나, AULR들은 로그 섹터들에 걸쳐 이어지지 않을 수 있을 수 있다, 예를 들어, 따라서 병합 동작은 DULR을 단일 원자 기록에서 AULR로 대체할 수 있을 것이다.

일부 실시예들에서, 콜드 로그 존은 핫 로그 존으로부터 로그 레코드들을 복사함으로써 파퓰레이팅된다. 이러한 실시예들에서, LSN이 현재 무조건적인 볼륨 지속 가능한 LSN(VDL)보다 적거나 동일한 로그 레코드들이 단지 콜드 로그 존에 복사될 자격이 있을 수 있다. 로그 레코드들을 핫 로그 존으로부터 콜드 로그 존으로 이동시킬 때, 일부 로그 레코드들(많은 CLR과 같은)은 그것들이 더 이상 필요하지 않기 때문에 복사할 필요가 없을 수 있다. 또한, 사용자 페이지들의 일부 추가적인 병합이 이 지점에서 수행될 수 있는데, 이는 요구되는 복사량을 감소시킬 수 있다. 일부 실시예들에서, 소정의 핫 존 로그 페이지가 완전히 기록되었고 더 이상 최신 핫 존 로그 페이지가 아닐 때, 그리고 핫 존 로그 페이지 상의 모든 ULR이 성공적으로 콜드 로그 존으로 복사되었을 때, 핫 존 로그 페이지는 자유롭게 되어 재사용될 수 있다.

일부 실시예들에서, 가비지 수집은 폐 로그 레코드들, 예를 들어, 더 이상 저장 티어의 SSD들에 저장될 필요가 없는 로그 레코드들에 의해 차지되는 공간을 재활용하기 위해 콜드 로그 존에서 이행될 수 있다. 예를 들어, 로그 레코드는 동일한 사용자 페이지에 대한 후속 AULR이 존재할 때 더 이상 쓸모 없게 될 수 있고 그 로그 레코드에 의해 제시되는 사용자 페이지의 버전은 SSD 상의 보유를 위해 필요하지 않다. 일부 실시예들에서, 가비지 수집 프로세스는 두 개 이상의 인접한 로그 페이지를 병합하고 그것들을 그것들이 대신하고 있는 로그 페이지들로부터의 모든 쓸모없지 않은 로그 레코드들을 포함하는 더 적은 신규 로그 페이지로 대체함으로써 공간을 재활용할 수 있다. 신규 로그 페이지들은 그것들이 대신하고 있는 로그 페이지들의 플러시 번호들보다 큰 신규 플러시 번호들이 할당될 수 있다. 이들 신규 로그 페이지들의 기록이 완료된 후, 대체된 로그 페이지들은 자유 페이지 풀에 추가될 수 있다. 일부 실시예들에서, 임의의 포인터들을 사용하는 로그 페이지들의 임의의 명백한 연결이 존재하지 않을 수 있다는 것을 주의하자. 대신에, 로그 페이지들의 시퀀스는 그것들의 페이지들 상의 플러시 번호들에 의해 함축적으로 결정될 수 있다. 로그 레코드의 다수의 복사본이 발견될 때마다, 최고 플러시 번호를 갖는 로그 페이지에 존재하는 로그 레코드는 유효한 것으로 간주될 수 있고 다른 것들은 쓸모없는 것으로 간주될 수 있다.

일부 실시예들에서, 예를 들어, 데이터 존 내(섹터)에서 관리되는 공간의 세분화가 데이터 존 밖(저장 페이지)의 세분화와 상이할 수 있기 때문에, 일부 단편화가 존재할 수 있다. 일부 실시예들에서, 제어되는 이러한 단편화를 유지하기 위해, 시스템은 각 데이터 페이지에 의해 사용되는 섹터들의 수를 계속 추적할 수 있고, 거의 빈 공간이 없는 데이터 페이지들로부터 우선적으로 할당할 수 있으며, 거의 빈 데이터 페이지들을 우선적으로 가비지 수집한다(그것이 여전히 관련되면 신규 장소에 데이터를 이동시킬 필요가 있을 수 있다). 세그먼트에 할당된 페이지들이 일부 실시예들에서 세 개의 존 사이에서 다른 목적에 맞게 만들어질 수 있다. 예를 들어, 세그먼트에 할당되었던 페이지가 자유롭게 될 때, 그것은 일부 시간의 기간 동안 해당 세그먼트와 연관되게 유지할 수 있고 후속하여 해당 세그먼트의 세 개의 존 중 임의의 존에서 사용될 수 있다. 모든 섹터의 섹터 헤더는 섹터가 속하는 존을 나타낼 수 있다. 페이지에서의 모든 섹터가 자유로울 때, 페이지는 존들에 걸쳐 공유되는 공통 자유 저장 페이지 풀에 리턴될 수 있다. 이러한 자유 저장 페이지 공유는 일부 실시예들에서 단편화를 감소(또는 방지)할 수 있다.

일부 실시예들에서, 본 출원에 설명된 분산 데이터베이스-최적화 저장 시스템들은 메모리 내 다양한 데이터 구조들을 유지할 수 있다. 예를 들어, 세그먼트에 존재하는 각 사용자 페이지에 대해, 사용자 페이지 테이블은 이 사용자 페이지가 "제거"되는지 여부(즉, 그것이 모든 제로를 포함하는지 여부)를 나타내는 비트, 페이지를 위한 콜드 로그 존으로부터의 최신 로그 레코드의 LSN, 및 페이지를 위한 핫 로그 존으로부터의 모든 로그 레코드의 장소들의 어레이/리스트를 저장할 수 있다. 각 로그 레코드에 대해, 사용자 페이지 테이블은 섹터 번호, 해당 섹터 내 로그 레코드의 오프셋, 해당 로그 페이지 내에서 판독할 섹터들의 수, 제2 로그 페이지의 섹터 번호(로그 레코드가 로그 페이지들에 걸쳐 이어지는 경우), 해당 로그 페이지 내에서 판독할 섹터들의 수를 저장할 수 있다. 일부 실시예들에서, 사용자 페이지 테이블은 또한 콜드 로그 존으로부터 모든 로그 레코드의 LSN들 및/또는 그것이 콜드 로그 존에 있는 경우 최신 AULR의 페이로드에 대한 섹터 번호들의 어레이를 저장할 수 있다.

본 출원에 설명된 분산 데이터베이스-최적화 저장 시스템들의 일부 실시예들에서, LSN 인덱스가 메모리에 저장될 수 있다. LSN 인덱스는 LSN들을 콜드 로그 존 내 로그 페이지들에 매핑할 수 있다. 콜드 로그 존에서의 해당 로그 레코드들이 정렬되면, 그것은 로그 페이지마다 하나의 엔트리를 포함하는 것일 수 있다. 그러나, 일부 실시예들에서, 모든 쓸모없지 않은 LSN은 인덱스에 저장되고 대응하는 섹터 번호들, 오프셋들, 및 각 로그 레코드에 대한 섹터들의 번호들에 매핑될 수 있다.

본 출원에 설명된 분산 데이터베이스-최적화 저장 시스템들의 일부 실시예들에서, 로그 페이지 테이블은 메모리에 저장될 수 있고, 로그 페이지 테이블은 콜드 로그 존의 가비지 수집 동안 사용될 수 있다. 예를 들어, 로그 페이지 테이블은 어느 로그 레코드들이 쓸모없는지(예를 들어, 어느 로그 레코드들이 가비지 수집될 수 있는지) 및 자유 공간이 각 로그 페이지 상에서 이용 가능한 방법을 식별할 수 있다.

본 출원에 설명된 저장 시스템들에서, 범위는 볼륨을 나타내기 위해 다른 범위들(연결되거나 또는 나뉘는)과 결합될 수 있는 매우 지속 가능한 저장 유닛을 나타내는 논리 개념일 수 있다. 각 범위는 단일 보호 그룹에서의 일원에 의해 지속 가능하게 될 수 있다. 범위는 생성 시 정의되는 고정 크기를 갖는 인접 바이트 서브-범위에 LSN-유형 판독/기록 인터페이스를 제공할 수 있다. 어느 범위까지의 판독/기록 동작들은 포함하는 보호 그룹에 의해 하나 이상의 적절한 세그먼트 판독/기록 동작으로 매핑될 수 있다. 본 출원에서 사용되는 바와 같이, 용어 "볼륨 범위"는 볼륨 내 바이트들의 특정한 서브-범위의 바이트들을 나타내는데 사용되는 범위를 나타낼 수 있다.

상기에서 언급한 바와 같이, 보호 그룹에 의해 제시되는 각각이 하나 이상의 세그먼트를 구성하는, 볼륨은 다수의 범위로 구성될 수 있다. 일부 실시예들에서, 상이한 범위들에 지시되는 로그 레코들은 인터리빙된 LSN들을 가질 수 있다. 특정한 LSN까지 지속 가능할 볼륨에 대한 변화들에 대해 그것은 그것들이 속하는 범위에 관계없이, 지속 가능할 해당 LSN까지의 모든 로그 레코드에 필요할 수 있다. 일부 실시예들에서, 클라이언트는 아직 지속 가능하게되지 않은 미처리된 로그 레코드들을 추적할 수 있고, 특정한 LSN까지의 모든 ULR이 지속가능하게 될 때, 그것은 볼륨 내 보호 그룹들 중 하나에 볼륨 지속 가능한 LSN(VDL) 메시지를 송신할 수 있다. VDL은 보호 그룹을 위해 모든 동기식 미러 세그먼트에 기록될 수 있다. 이는 때때로 "무조건적인 VDL"로 지칭되고 그것은 세그먼트들 상에서 일어나는 기록 활동과 함께 다양한 세그먼트들에(또는 보다 구체적으로, 다양한 보호 그룹들에) 주기적으로 지속될 수 있다. 일부 실시예들에서, 무조건적인 VDL은 로그 섹터 헤더들에 저장될 수 있다.

다양한 실시예들에서, 세그먼트 상에서 수행될 수 있는 동작들은 클라이언트로부터 수신되는 DULR 또는 AULR을 기록하는 동작(핫 로그 존의 테일에 DULR 또는 AULR을 기록한 후 사용자 페이지 테이블을 업데이트하는 동작을 수반할 수 있는), 콜드 사용자 페이지를 판독하는 동작(사용자 페이지의 데이터 섹터들의 정확한 위치를 찾고 그것들을 임의의 추가적인 DULR들을 적용할 필요 없이 리턴하는 동작을 수반할 수 있는), 핫 사용자 페이지를 판독하는 동작(사용자 페이지에 대한 가장 최근 AULR의 데이터 섹터들의 정확한 위치를 찾는 동작을 수반하고 그것을 리턴하기 전에 사용자 페이지에 임의의 후속 DULR들을 적용할 수 있는), DULR들을 AULR들로 대체하는 동작(적용된 마지막 DULR을 대신하는 AULR을 생성하기 위해 사용자 페이지에 대한 DULR들을 병합하는 동작을 수반할 수 있는), 로그 레코드들을 조작하는 동작 등을 포함할 수 있다. 본 출원에 설명된 바와 같이 병합은 사용자 페이지의 이후 버전을 생성하기 위해 사용자 페이지의 이전 버전에 DULR들을 적용하는 프로세스이다. 사용자 페이지를 병합하는 것은 (또 다른 DULR이 기록될 때까지) 병합하기 전에 기록된 모든 DULR이 요구에 따라 판독 및 적용될 필요가 없을 수 있기 때문에 판독 레이턴시를 감소시키는 것을 도울 수 있다. 그것은 또한 오래된 AULR들 및 DULR들을 쓸모없게 만듦으로써(로그 레코드들이 존재하도록 요구하는 어떤 스냅샷도 존재하지 않는다면) 저장 공간을 재활용하는 것을 도울 수 있다. 일부 실시예들에서, 병합 동작은 가장 최근 AULR의 정확한 위치를 찾는 동작 및 DULR들 중 임의의 것을 스킵하지 않고 시퀀스 내 임의의 후속 DULR들을 적용하는 동작을 포함할 수 있다. 상기에서 언급한 바와 같이, 일부 실시예들에서, 병합은 핫 로그 존 내에서 수행되지 않을 수 있다. 대신에, 콜드 로그 존 내에서 수행될 수 있다. 일부 실시예들에서, 병합은 또한 로그 레코드들이 핫 로그 존으로부터 콜드 로그 존으로 복사됨에 따라 수행될 수 있다.

일부 실시예들에서, 사용자 페이지를 병합하기 위한 결정은 페이지에 대해 계류 중인 DULR 연결의 크기에 의해(예를 들어, DULR 연결의 길이가 시스템-와이드, 애플리케이션-특정 또는 클라이언트-특정 정책에 따라, 병합 동작을 위해 미리 결정된 임계치를 초과하는 경우), 또는 클라이언트에 의해 판독된 사용자 페이지에 의해 트리거될 수 있다.

도 7은 일 실시예에 따라, 데이터베이스 볼륨(710)의 예시적인 구성을 예시하는 블록도이다. 이 예에서, 다양한 어드레스 범위들(715) 각각(어드레스 범위들(715a 내지 715e)로 도시된)에 대응하는 데이터는 상이한 세그먼트들(745)(세그먼트들(745a 내지 745n)로 도시된)로 저장된다. 보다 구체적으로, 다양한 어드레스 범위들(715) 각각에 대응하는 데이터는 상이한 범위들(범위들(725a 및 725b), 및 범위들(735a 내지 735h)로 도시된)로 구조화될 수 있고, 이들 범위들의 다양한 범위들은 나뉘거나 나뉘지 않고(스트라이프 세트(720a) 및 스트라이프 세트(720b)로서 도시된 것과 같은) 상이한 보호 그룹들(730)(730a 내지 730f로 도시된)에 포함될 수 있다. 이 예에서, 보호 그룹 1은 소거 코딩의 사용을 예시한다. 이 예에서, 보호 그룹들 2 및 3 및 보호 그룹들 6 및 7은 서로의 미러링된 데이터 세트들을 나타내고, 보호 그룹 4는 단일-인스턴스(비-리던던트) 데이터 세트를 나타낸다. 이 예에서, 보호 그룹 8은 다른 보호 그룹들을 결합하는 멀티-티어 보호 그룹을 나타낸다(예를 들어, 이는 멀티-영역 보호 그룹을 나타낼 수 있다). 이 예에서, 스트라이프 세트 1(720a) 및 스트라이프 세트 2(720b)는 범위들(예를 들어, 범위들(725a 및 725b))이 일부 실시예들에서, 볼륨으로 어떻게 나뉠 수 있는지를 예시한다.

보다 구체적으로, 이 예에서, 보호 그룹 1(730a)은 범위들 a 내지 c(735a 내지 735c)을 포함하는데, 이는 범위들 1 내지 3(715a 내지 715c), 각각을 포함하고, 이들 범위들을 세그먼트들 1 내지 4(745a 내지 745d)에 매핑된다. 보호 그룹 2(730b)는 범위 d(735d)를 포함하는데, 이는 범위 4(715d)로부터 나뉘는 데이터를 포함하며, 이 범위는 세그먼트들 5 내지 7(745e 내지 745g)에 매핑된다. 이와 유사하게, 보호 그룹 3(730c)는 범위 e(735e)를 포함하는데, 이는 범위 4(715d)로부터 나뉘는 데이터를 포함하며, 세그먼트들 8 및 9(745h 및 745i)에 매핑되고; 보호 그룹 4(730d)는 범위 f(735f)를 포함하는데, 이는 범위 4(715d)로부터 나뉘는 데이터를 포함하며, 세그먼트 10(745j)에 매핑된다. 이 예에서, 보호 그룹 6(730e)은 범위 g(735g)를 포함하는데, 이는 범위 5(715e)로부터 나뉘는 데이터를 포함하며, 세그먼트들 11 및 12(745k 내지 745l)에 매핑되고; 보호 그룹 7(730f)는 범위 h(735h)를 포함하는데, 이는 또한 범위 5(715e)로부터 나뉘는 데이터를 포함하며, 세그먼트들 13 및 14(745m 및 745n)에 매핑된다.

이제 도 8을 참조하면, 다양한 실시예들에서, 데이터베이스 시스템(400)은 스냅샷을 생성, 삭제, 수정, 및/또는 다르게 사용하도록 구성될 수 있다. 도 8의 방법이 분산 데이터베이스-최적화 저장 시스템(410)(예를 들어, 저장 시스템 서버 노드(들)(430, 440, 450 등))과 같은, 로그-구조 저장 시스템의 다양한 구성요소들에 의해 수행되는 것으로 설명될 수 있지만, 방법은 일부 경우들에서 임의의 특정한 구성요소에 의해 수행될 필요는 없다. 예를 들어, 일부 경우들에서, 도 8의 방법은 일부 실시예들에 따라, 일부 다른 구성요소 또는 컴퓨터 시스템에 의해 수행될 수 있다. 또는, 일부 경우들에서, 데이터베이스 시스템(400)의 구성요소들은 도 4의 예에 도시된 방식과 상이한 방식으로 조합되거나 존재할 수 있다. 다양한 실시예들에서, 도 8의 방법은 분산 데이터베이스-최적화 저장 시스템의 하나 이상의 컴퓨터에 의해 수행될 수 있고, 그 중 하나는 도 10의 컴퓨터 시스템으로 도시된다. 도 8의 방법이 스냅샷 생성, 삭제, 수정, 사용 등을 위한 방법의 하나의 예시적인 구현예로서 도시된다. 다른 구현예들에서, 도 8의 방법은 도시된 블록들에 추가적인 블록들 또는 도시된 블록들보다 적은 블록들을 포함할 수 있다.

810에서, 각각이 데이터베이스 서비스에 의해 저장/유지되는 데이터에 대한 각각의 변경과 연관되는, 복수의 로그 레코드가 유지될 수 있다. 다양한 실시예들에서, 로그 레코드들에 의해 제시되는, 변경들은 데이터베이스 서비스의 분산 데이터베이스-최적화 저장 시스템의 저장 시스템 서비스 노드(430)에 의해 저장될 수 있다. 본 출원에서 설명된 바와 같이, 일 실시예에서, 로그 레코드들은 데이터베이스 서비스의 데이터베이스 엔진 헤드 노드로부터, 분산 데이터베이스-최적화 저장 시스템에 의해, 수신될 수 있다. 다른 실시예들에서, 로그 레코드들은 분산 데이터베이스-최적화 저장 시스템과 별개인 데이터베이스 서비스의 다른 구성요소로부터 수신될 수 있다.

일 실시예에서, 각 로그 레코드는 본 출원에 설명된 바와 같이, 순차적으로 순서화된 식별자(예를 들어, 로그 시퀀스 번호("LSN"; log sequence number))와 같은, 각각의 식별자와 연관될 수 있다. 로그 레코드들은 그것들이 수신될 때 각각의 LSN과 연관될 수 있거나 또는 저장 시스템은 LSN을 그것이 수신된 순서로 소정의 로그 레코드에 할당할 수 있다.

복수의 로그 레코드에 대응하는 데이터는 단일 데이터 페이지(예를 들어, 데이터 페이지(들)(도 4의 433, 443, 또는 453)) 또는 다수의 데이터 페이지일 수 있다. 복수의 로그 레코드가 LSN들 1-4를 갖는 네 개의 로그 레코드를 포함하는 시나리오를 고려하자. 일 예에서, LSN들 1-4의 각각은 데이터 페이지 A에 적용될 수 있다. 또는, 다른 예에서, LSN들 1 및 3은 데이터 페이지 A에 적용될 수 있고 LSN들 2 및 4는 데이터 페이지 B에 적용될 수 있다. 예들에서, 각 특정한 로그 레코드가 단일 사용자/데이터 페이지(예를 들어, LSN1-페이지 A, LSN2-페이지 B 등)와 연관될 수 있다는 것을 주의하자.

다양한 실시예들에서, 로그 레코드들이 저장 시스템 서버 노드들(도 4의 430, 440, 및 450)과 같은, 다양한 노드들에 걸쳐 분산 방식으로 저장될 수 있다는 것을 주의하자. 일부 실시예들에서, 로그 레코드의 단일 복사본은 단일 노드에 저장될 수 있거나, 또는 단일 복사본은 다른 예들 중에서, 다수의 노드들에 저장될 수 있다. 상기로부터의 네 개의 로그 레코드 예를 계속하면, LSN 1을 갖는 로그 레코드는 노드들(430 및 440) 양자에 저장될 수 있고, LSN 2는 노드(430)에 저장될 수 있으며, LSN들 3 및 4는 세 개의 노드(430, 440, 및 450) 모두에 저장될 수 있다. 그러한 예에서, 다양한 노드들 및/또는 미러들의 전부가 로그 레코드들의 전체 세트를 갖는 최신의 것은 아닐 수 있다. 도 9에 설명된 바와 같이, 로그 레코드 조작은 다양한 노드들에 저장된 로그 레코드들 간 차이들을 조정하는 것을 용이하게 하기 위해 수행될 수 있다.

일부 실시예들에서, 소정의 로그 레코드가 저장되는 곳(예를 들어, 어떤 노드 또는 노드들)은 데이터베이스 엔진 헤드 노드에 의해 결정될 수 있고 분산 데이터베이스-최적화 저장 시스템에 제공되는 라우팅 정보로서 포함될 수 있다. 대안적으로 또는 추가적으로, 분산 데이터베이스-최적화 저장 시스템은 어떤 노드 또는 노드들이 소정의 로그 레코드를 저장하는지를 결정할 수 있다. 일 실시예에서, 분산 데이터베이스-최적화 저장 시스템에 의한 그러한 결정은 로그 레코드들을 다양한 노드들 중에 대략 비례적으로 분산시킴으로써 성능을 극대화하는 것일 수 있다. 일 실시예에서, 분산 데이터베이스-최적화 저장 시스템에 의한 그러한 결정은 로그 레코드의 중요도에 따를 수 있다. 예를 들어, 중요한(예를 들어, 빈번하게 액세스되는) 데이터 페이지의 AULR은 다수의 노드에 저장될 수 있는 반면, 덜 중요한 데이터 페이지와 연관된 DULR은 단지 단일 노드에 저장될 수 있다.

본 출원에 설명된 바와 같이, 로그 레코드들은 DULR들 및 AULR들을 포함할 수 있다. 다양한 실시예들에서, 애플리케이션, 데이터베이스 서비스, 및/또는 데이터베이스 서비스의 사용자(또는 다른 구성요소)는 데이터 페이지에 대한 소정의 변경에 대해 DULR 또는 AULR을 생성할지 여부를 결정할 수 있다. 예를 들어, 데이터베이스 서비스는 소정의 데이터 페이지에 대한 모든 10개의 로그 레코드 중 적어도 하나가 AULR임을 보장할 수 있다. 그러한 예에서, 소정의 데이터 페이지에 대한 로우에서의 9개의 로그 레코드가 DULR들이면, 데이터베이스 서비스는 다음 로그 레코드가 AULR이라는 것을 명시할 수 있다.

또한, 다양한 실시예들에서, 볼륨에서의 각 데이터 페이지는 AULR을 필요로 할 수 있다. 따라서, 데이터 페이지의 제1 기록에 대해, 로그 레코드는 AULR일 수 있다. 일 실시예에서, 시스템 개시의 일부로서, 각 데이터 페이지는 데이터 페이지들을 AULR로 초기화하기 위해 특정 값(예를 들어, 모든 0)으로 기록될 수 있다. 모든 0의 AULR은 데이터 페이지의 후속 기록들이 DULR들일 수 있도록 충분할 수 있다.

820에 도시된 바와 같이, 스냅샷이 생성될 수 있다. 다양한 실시예들에서, 스냅샷을 생성하는 것은 특정한 로그 레코드의 로그 식별자(예를 들어, LSN)를 가리키는 메타데이터를 생성하는 것을 포함할 수 있다. 일부 예들에서, 다른 특정한 로그 레코드들의 하나 이상의 다른 로그 식별자를 가리키는 메타데이터가 또한 생성될 수 있다. 로그 레코드(들)의 로그 식별자(들)를 가리키는 그러한 메타데이터는 그 특정한 로그 레코드들이 해당 스냅샷을 위해 유지되어야 한다(예를 들어, 삭제되거나 가비지 수집되지 않아야 한다)(해당 스냅샷이 삭제 또는 대체될 때까지)는 것을 표시할 수 있다.

일부 실시예들에서, 생성된 메타데이터는 또한 스냅샷 식별자를 가리킬 수 있다. 예시적인 스냅샷 식별자들은 스냅샷과 연관된 순차적인 번호, 명칭, 시간 중 하나 이상을 포함할 수 있다. 예를 들어, 특정한 스냅샷은 SN1로 불리워질 수 있고/있거나 2005년 12월 22일 GMT 14:00.00(2pm 정각)의 타임스탬프를 가질 수 있다.

다양한 실시예들에서, 스냅샷과 연관된 메타데이터는 하나 이상의 로그 레코드가 가비지 수집되는 것을 방지하기 위해 사용 가능할 수 있다. 예를 들어, 메타데이터는 소정의 페이지를 스냅샷과 연관된 로그 레코드/LSN까지 재생성하기 위해 요구되는 하나 이상의 로그 레코드를 표시할 수 있다. 결과적으로, 메타데이터는 데이터 페이지(들)가 스냅샷과 연관된 LSN까지 생성될 수 있다는 것을 보장할 수 있다.

다양한 실시예들에서, 메타데이터는 여러 가지의 상이한 위치에 저장될 수 있다. 예를 들어, 메타데이터는 각 로그 레코드 내에 저장될 수 있고 가비지 수집 상황으로부터 각각의 로그 레코드의 보호를 표시할 수 있다. 예를 들어, LSN들 2, 3, 및 4를 갖는 로그 레코드들이 특정한 스냅샷에 대해 가비지 수집되지 않아야 하면, LSN들 2, 3, 및 4의 로그 레코드들과 연관된 메타데이터는 LSN들 2, 3, 및 4의 로그 레코드들이 가비지 수집되지 않아야 한다는 것을 표시해야 한다. 다른 예로서, 스냅샷 메타데이터는 분산 데이터베이스-최적화 저장 시스템의 더 높은 레벨에(예를 들어, 세그먼트, 볼륨, 또는 로그 레코드 레벨, 또는 다른 곳 등에) 저장될 수 있고 복수의 로그 레코드의 가비지 수집 상황의 상황을 표시할 수 있다. 그러한 예에서, 메타데이터는 스냅샷 마다 유지되어야 하는 로그 레코드들에 대응하는 LSN들의 리스트를 포함한다. 후속 스냅샷을 취할 시, 유지될 로그 레코드(들)가 변경될 수 있다는 것을 주의하자. 결과적으로, 로그 레코드들 중 특정한 로그 레코드들에 대응하는 메타데이터가 또한 변경될 수 있다. 예를 들어, LSN들 2, 3, 및 4는 더 이상 장차의 스냅샷을 위해 유지되어야 할 필요가 없을 수 있다. 따라서, 그러한 예에서, 메타데이터는 그것이 더 이상 LSN들 2, 3, 및 4에 대응하는 로그 레코드들이 유지되어야 한다는 것을 표시하지 않도록 수정될 수 있다.

일 실시예에서, 메타데이터는 어떤 로그 레코드들이 가비지 수집 가능하지 않은지를 명백하게 표시할 수 있거나 또는 그것은 스냅샷에 대응하는 특정한 LSN과 함께 스냅샷 유형(하기 설명될)을 대신 표시할 수 있다. 이러한 실시예에서, 분산 데이터베이스-최적화 저장 시스템의 가비지 수집 프로세스는 스냅샷 유형 및 특정한 LSN으로부터, 어떤 로그 레코드들이 가비지 수집 가능한지 및 그렇지 않은지를 결정할 수 있다. 예를 들어, 가비지 수집 프로세스는 특정한 LSN 및 각 DULR과 연관된 로그 레코드가 해당 데이터 페이지에 대한 이전 AULR이 가비지 수집 가능하지 않을 때까지의 시간으로 돌아가는 것을 결정할 수 있다.

다양한 실시예들에서, 스냅샷은 특정한 데이터 페이지에 특유할 수 있거나, 또는 그것은 다수의 데이터 페이지(예를 들어, 세그먼트 , 볼륨)에 특유할 수 있다.

일 실시예에서, 메타데이터는 본 출원에 설명되는 바와 같이, 스냅샷의 유형(예를 들어, 스냅샷이 연속적인 스냅샷인지 또는 개별적인 스냅샷인지)을 표시할 수 있다. 스냅샷의 유형은 메타데이터에 직접적으로 표시될 수 있거나(예를 들어, 연속적 또는 이산적) 또는 그것 간접적으로 표시될 수 있다(예를 들어, 로그 레코드(들)가 가비지 수집 가능하지 않은 것으로서 표시되는지는 어떤 스냅샷이 연속적인지 또는 개별적인지를 가리킬 수 있다). 예를 들어, 연속적인 스냅샷은 가비지 수집 가능하지 않은 로그 레코드(들)의 하나의 세트를 표시할 수 있는 반면 개별적인 스냅샷은 가비지 수집 가능하지 않은 로그 레코드(들)의 상이한(예를 들어, 보다 작은) 세트를 표시할 수 있다. 일부 상황들에서, 연속적인 그리고 개별적인 스냅샷은 로그 레코드(들)의 동일한 세트를 표시하는 메타데이터를 가질 수 있다. 예를 들어, AULR에 대응하는 시점에서 취해지는 데이터 페이지의 스냅샷에 대해, 연속적인 그리고 개별적인 스냅샷은 모두 단지 AULR이 가비지 수집으로부터 보호되어야 한다는 것을 표시하는 메타데이터를 가질 수 있다.

연속적인 스냅샷은 연속적인 스냅샷의 시간과 이전 시간(예를 들어, 최근의 AULR) 사이의 각각의 시점에 대한 데이터를 복구하기 위해 사용 가능할 수 있다. 이에 반해, 개별적인 스냅샷은 스냅샷의 시점으로서의 상태에 대한 데이터를 복구하기 위해 재사용 가능할 수 있다. 예를 들어, 해당 데이터 페이지 이후에, 데이터 페이지(AULR)의 신규 버전이 이어지는, 세 개의 델타 로그 레코드 및 데이터 페이지의 해당 신규 버전에 대한 세 개의 델타 로그 레코드를 더 갖는, 데이터 페이지(AULR)의 예를 고려하자. 데이터를 복구하기 위해 스냅샷을 사용하는 것은 본 출원에서 데이터의 이전 버전의 복사본을 만들지 않고 스냅샷 시점에서 데이터를 판독하는 것을 설명하는데 사용된다. 개별적인 스냅샷이 모든 엔트리(AULR들 및 모든 여섯 개의 DULR 모두) 이후의 시점에서 취해지면, 가비지 수집 가능하지 않은 것으로 표시될 수 있는 로그 엔트리들은 데이터 페이지의 신규 버전 및 해당 데이터 페이지 이후의 세 개의 로그 엔트리를 포함한다. 연속적인 스냅샷이 현재 스냅샷 시점으로부터 데이터 페이지의 제1 버전의 시점까지 취해지면, 가비지 수집 가능하지 않은 것으로 표시될 수 있는 로그 엔트리들은 제1 데이터 페이지 및 모든 여섯 개의 로그 레코드를 포함한다. 중간 예시된 블록(예를 들어, 데이터 페이지(AULR)의 신규 버전)이 그것이 데이터 페이지의 제1 버전 및 제1 세 개의 로그 레코드로 재생성 가능하기 때문에 가비지 수집 가능하지 않은 것으로 표시되지 않을 수 있다는 것을 주의하자. 이 예에서, 연속적인 스냅샷이 로그 레코드들이 존재하는 시점들 중 임의의 시점에 대한 데이터 페이지를 복구하기 위해 사용 가능한 반면 개별적인 스냅샷은 스냅샷의 시점 및 스냅샷의 시점과 스냅샷 이전의 최근 AULR들 사이의 각각의 시점에 대한 데이터 페이지를 복구하기 위해 사용 가능하다는 것을 주의하자.

일부 실시예들에서, 스냅샷을 생성하는 것은 오프-볼륨 백업 전략을 채용할 때 요구될 수 있는 바와 같이, 데이터 블록을 추가로 판독, 복사, 또는 기록하지 않고 수행될 수 있다. 따라서, 스냅샷은 스냅샷 생성이 데이터의 백업을 취하는 것을 요구하지 않을 수 있도록 그 자리에서 생성될 수 있다. 데이터가 또한 다른 곳에 저장되는 데이터의 백업들이 발생할 수 있으나 그러한 발생이 스냅샷 생성 프로세스 이외에서 수행될 수 있다는 것을 주의하자. 예를 들어, 클라이언트는 데이터의 다수의 복사본이 별개의 저장장치 위치들에 저장되는 것을 요청할 수 있다.

830에서, 데이터는 스냅샷에 대응하는 상태의 시점에서 판독될 수 있다. 예를 들어, 사용자가 테이블을 드롭하였으나 다시 해당 테이블을 원하면, 스냅샷은 테이블이 다시 이용 가능하도록 데이터(예를 들어, 데이터 페이지, 세그먼트, 볼륨 등)를 판독/복구하는데 사용될 수 있다. 스냅샷을 판독/복구하는 것은 스냅샷의 지점 이후에서 수행되었던 일부 데이터/작업을 손실하는 것을 포함할 수 있고 판독/복구 프로세스의 일부로서 데이터의 이전 버전의 복사본을 생성하는 것을 포함하지 않을 수 있다는 것을 주의하자.

스냅샷에 대응하는 상태에 대한 데이터를 복구하는 것은 메타데이터에 표시되는 특정한 로그 레코드를 포함하는, 로그 레코드들 중 하나 이상의 로그 레코드를, 데이터의 이전 버전에 적용하는 것을 포함할 수 있다. 데이터의 이전 버전은 AULR의 형태일 수 있거나 또는 그것은 DULR의 형태일 수 있다(DULR 이전의 하나 이상의 DULR 및/또는 AULR에 적용되는 바와 같이).

일부 실시예들에서, 하나 이상의 로그 레코드를 데이터의 이전 버전에 적용하는 것은 데이터베이스 서비스에 대한 백그라운드 프로세스로서 수행될 수 있다. 일 실시예에서, 로그 레코드(들)를 데이터의 이전 버전에 적용하는 것은 데이터베이스 서비스의 다양한 노드들에 걸쳐 분산될 수 있다. 일 실시예에서, 로그 레코드(들)를 데이터의 이전 버전에 적용하는 것은 그 다양한 노드들에 걸쳐 동시에 수행될 수 있다.

840에 도시된 바와 같이, 특정한 스냅샷으로 복구한 이후, 스냅샷과 연관된 시간보다 늦은 관련 시간들을 갖는 하나 이상의 로그 레코드가 가비지 수집 가능한 것으로 표시될 수 있다. 예를 들어, LSN들 1 내지 6을 갖는 로그 레코드들이 LSN 3에서 취해진 스냅샷을 갖는 데이터 페이지를 위해 존재하면, LSN 3에서 취해진 스냅샷을 복구 시, LSN들 4 내지 6이 가비지 수집 가능한 것으로 표시될 수 있거나 또는 가비지 수집 가능하지 않다는 표시를 간단히 제거할 수 있다(그렇게 함으로써 그것들을 가비지 수집 가능한 것으로 만든다). 그에 따라, 제2 스냅샷이 LSN 6에서 취해졌다 하더라도, LSN 3으로부터 스냅샷을 복구 시, LSN 6에서 취해진 스냅샷은 LSN 6에서 취해진 스냅샷에 대응하는 로그 레코드들의 보호가 더 이상 유효하지 않을 수 있도록 더 이상 그 자리에 있지 않을 수 있다. 또는, 일 실시예에서, 제2 스냅샷은 이전 스냅샷으로 복구할 때조차 여전히 보존될 수 있다.

다양한 실시예들에서, 가비지 수집은 장차 다른 로그 레코드들에 대해(또는 다른 데이터에 대해) 환원할 로그 레코드들을 저장하는데 사용되는 공간을 허용하는 백그라운드 프로세스일 수 있다. 가비지 수집은 가비지 수집이 분산된 프로세스로서 동시에 발생할 수 있도록 다양한 노드들에 걸쳐 분산될 수 있다. 가비지 수집 프로세스에 의해 환원되는 것은 하나 이상의 로그 레코드를 삭제하는 것을 포함할 수 있다. 삭제할 그 로그 레코드들은 메타데이터에 표시되는 특정한 로그 레코드(들)에 기초하여 가비지 수집 프로세스에 의해 결정될 수 있고/있거나 스냅샷의 유형에 기초할 수 있다. 또는, 일 실시예에서, 여기서 각각의 보호된 로그 레코드는 메타데이터에 명백하게 표시되고, 그 후 가비지 수집 프로세스는 메타데이터에서 보호되는 것으로 표시되지 않은 로그 레코드들을 간단히 삭제할 수 있다.

일부 실시예들에서, 복수의 로그 레코드는 적어도 부분적으로, 스냅샷에 기초하여 병합될 수 있다. 예를 들어, 소정의 데이터 페이지에 대해, AULR이 LSN 1에 존재하고, DULR들이 LSN들 2 내지 8에 존재하며, 개별적인 스냅샷이 LSN 8에서 취해지면, 신규 AULR은 LSN 2 내지 8로부터의 로그 레코드들 각각이 LSN 1의 AULR에 적용되도록 LSN 8의 DULR을 대체하기 위해 생성될 수 있다. LSN 8의 신규 AULR은 그 후 LSN 1 내지 7의 로그 레코드들이 가비지 수집 가능한 것을 가능하게 할 수 있고 그렇게 함으로써 그 로그 레코드들을 저장하는데 사용되는 공간을 해제할 수 있다. 연속적인 스냅샷에 대해, 병합하는 것은 연속적인 스냅샷에 의해 커버되는 시점들의 각각으로 복구하는 능력을 유지하기 위해 일어나지 않을 수 있다는 것을 주의하자. 클라이언트가 연속적인 스냅샷들이 이전의 이틀동안 유지되고 주기적인(예를 들어, 매일 두 번, 매일 한 번) 개별적인 스냅샷들이 그 전 30일 동안 유지되는 것을 요청할 수 있다는 것을 주의하자. 연속적인 스냅샷이 이전의 이틀 범위에 포함되지 있을 때, 그것은 개별적인 스냅샷으로 변환될 수 있고, 변환된 이상적인 스냅샷을 위해 더 이상 요구되지 않는 로그 레코드들은 더 이상 유지되지 않을 수 있다.

매일 한 번 개별적인 스냅샷이 1 내지 30일의 각각을 위해 존재하고 연속적인 스냅샷들이 30일부터 32일까지 존재하는 예를 고려하자. 33일에, 30일부터 31일까지의 연속적인 스냅샷은 그것이 더 이상 최근 2일 기간 내가 아니기 때문에 더 이상 클라이언트에 의해 필요하지 않을 수 있다. 따라서, 30일부터 31일까지의 연속적인 스냅샷은 개별적인 스냅샷으로 변환될 수 있다. 30일부터 31일까지의 연속적인 스냅샷의 일부를 개별적인 스냅샷으로 변환하기 위해, 메타데이터는 해당 시점에서 개별적인 스냅샷에 대해 더 이상 요구되지 않는 로그 레코드(들)가 가비지 수집 가능한 것으로 표시될 수 있도록(또는 더 이상 가비지 수집 가능하지 않은 것으로 표시되지 않을 수 있도록) 수정될 수 있다. 같은 방식으로, 1일에서의 개별적인 스냅샷은 그것이 더 이상 최근 이틀 이전의 선행하는 30일 윈도우 내에 포함되지 않기 때문에 또한 삭제 및/또는 가비지 수집될 수 있다(2일의 개별적인 스냅샷이 1일에서의 개별적인 스냅샷의 로그 레코드들에 종속하지 않는다고 가정하면). 1일에서의 스냅샷을 삭제하는 것은 그 레코드들이 그 후 가비지 수집 가능할 수 있도록 1일의 스냅샷과 연관된 로그 레코드들이 가비지 수집되는 것으로부터 보호한 메타데이터를 수정 및/또는 삭제하는 것을 포함할 수 있다(후속 스냅샷에 의해 요구되지 않는 한). 2일에서의 개별적인 스냅샷이 1일에서의 개별적인 스냅샷의 로그 레코드들에 종속적이면, 2일에서의 개별적인 스냅샷과 연관된 하나 이상의 로그 레코드가 1일의 로그 레코드들이 삭제 및/또는 가비지 수집될 수 있도록 AULR(들)에서 변환될 수 있다는 것을 주의하자.

본 출원에 설명되는 바와 같이, 도 8의 방법은 단일 데이터 페이지의 데이터에 또는 다수의 데이터 페이지로부터의 데이터에 적용할 수 있다. 따라서, 다양한 실시예들에서, 스냅샷은 다수의 상이한 데이터 페이지로부터 또는 단일 데이터 페이지로 데이터를 복구하기 위해 사용 가능할 수 있다. 따라서, 스냅샷의 메타데이터는 단일 데이터 페이지에 대한 하나 이상의 로그 레코드에 대한 하나 이상의 로그 식별자 또는 다수의 데이터 페이지에 대한 다수의 로그 레코드에 대한 다수의 로그 식별자를 가리킬 수 있다. 또한 단일 데이터 페이지에 대한 스냅샷에 대응하는 메타데이터가 일부 인스턴스들에서, 또한 다수의 로그 레코드에 대한 다수의 로그 식별자를 가리킬 수 있다는 것을 주의하자. 예를 들어, 메타데이터는 스냅샷이 DULR에 대응하는 경우와 같이, 가비지 수집되지 않아야 하는 다수의 로그 레코드를 가리킬 수 있다. 그러한 예에서, 메타데이터는 각각의 DULR이 최근 AULR에 대한 시간으로 돌아가는 것 및 해당 페이지에 대한 최근 AULR이 가비지 수집되어야 하는 것을 표시할 수 있다(직접적으로 또는 간접적으로).

개시된 인-플레이스(in-place) 스냅샷 기술들은 데이터 블록의 판독, 복사, 및 기록에 의해 스냅샷을 수행하기 위해 데이터를 백업하는 시스템과는 대조적으로 더 적은 IO 및 네트워킹 자원들을 사용한다는 면에서 시스템의 성능을 향상시킬 수 있다. 그리고 그 성능 향상들로 인해, 개시된 기술들은 시스템의 사용자들(예를 들어, 우위 활동을 위해 시스템을 사용하는 그들)에 보일 수 있는 더 낮은 처리 속도의 스톨들 또는 스로틀링을 제공할 수 있다.

이제 도 9를 참조하면, 다양한 실시예들에서, 데이터 베이스 시스템(400)은 로그 레코드들을 조작(예를 들어, 변환, 수정 등)하도록 구성될 수 있다. 도 9의 방법이 분산 데이터베이스-최적화 저장 시스템(410)(예를 들어, 저장 시스템 서버 노드(들)(430, 440, 450 등))과 같은, 로그-구조 저장 시스템의 다양한 구성요소들에 의해 수행되는 것으로 설명될 수 있지만, 방법은 일부 경우들에서 임의의 특정한 구성요소에 의해 수행될 필요는 없다. 예를 들어, 일부 경우들에서, 도 9의 방법은 일부 실시예들에 따라, 일부 다른 구성요소 또는 컴퓨터 시스템에 의해 수행될 수 있다. 또는, 일부 경우들에서, 데이터베이스 시스템(400)의 구성요소들은 도 4의 예에 도시된 방식과 상이한 방식으로 조합되거나 존재할 수 있다. 다양한 실시예들에서, 도 9의 방법은 분산 데이터베이스-최적화 저장 시스템의 하나 이상의 컴퓨터에 의해 수행될 수 있고, 그 중 하나는 도 10의 컴퓨터 시스템으로 도시된다. 도 9의 방법은 로그 변환/조작을 위한 방법의 하나의 예시적인 구현예로서 도시된다. 다른 구현예들에서, 도 9의 방법은 도시된 블록들에 추가적인 블록들 또는 도시된 블록들보다 적은 블록들을 포함할 수 있다. 예를 들어, 도 9의 방법은 도 9의 방법이 도 8의 방법의 하나 이상의 블록을 포함하도록 도 8의 방법과 함께 사용될 수 있다.

910에서, 복수의 로그 레코드가 수신될 수 있다. 예를 들어, 로그 레코드들은 데이터베이스 서비스의 데이터베이스 엔진 헤드 노드로부터, 분산 데이터베이스-최적화 저장 시스템에 의해, 수신될 수 있다. 도 8에서 언급된 바와 같이, 그리고 본 출원에서 설명된 바와 같이, 각각의 로그 레코드는 각각의 로그 시퀀스 식별자와 연관될 수 있고 데이터베이스 시스템에 의해 저장되는 데이터에 대한 각각의 변경과 연관될 수 있다. 또한 본 출원에서 설명된 바와 같이, 로그 레코드들은 또한 베이스라인 로그 레코드(들)로 지칭되는, 하나 이상의 AULR 및/또는 하나 이상의 DULR을 포함할 수 있다. 베이스라인 로그 레코드(들)는 데이터의 페이지를 포함할 수 있어, 그것은 페이지에 대한 전체 데이터를 포함하고 단지 데이터에 대한 변경들을 포함하지 않는다. 대조적으로, DULR들은 데이터의 페이지에 대한 변경을 포함하고 데이터의 전체 페이지는 포함하지 않을 수 있다.

다음 문단들은 로그 레코드들의 범위를 설명하기 위한 예시적인 표기를 설명한다. 단순한 괄호들 () 및 사각 괄호들 []은 범위의 개방형(배타적인) 및 폐쇄형(포괄적인) 경계들을 표시한다. 본 출원에서 설명된 바와 같이, LSN들은 로그 레코드들의 순차적인 순서일 수 있고, 따라서 0 <= a <= b <= c <= d <= e이다. LSN t는 0에서 시작하는, 테일을 나타내는 특유의 LSN이고, 기록들이 볼륨 상에서 발생함에 따라 계속적으로 증가한다. 본 출원에서 사용되는 바와 같이, 로그 섹션은 베이스라인 LSN에서의 볼륨을 고려하여, 하나 이상의 타겟 LSN의 볼륨을 판독할 수 있는데 필요한 모든 정보를 가지는 로그 레코드들의 집합이다. 일 실시예에서, 로그 섹션은 베이스라인 LSN보다 적거나 동일한 또는 최상위 타겟 LSN보다 큰 LSN을 갖는 임의의 로그 레코드를 포함하지 않는다. 예를 들어, 베이스라인 LSN 'a'에 완전한 볼륨이 존재하고, 로그 섹션이 L(a;b]이면, 볼륨이 생성되고 LSN 'b'에서 판독될 수 있다.

예시적인 신택스를 사용하여, 로그 섹션은 그 후 L(<베이스라인 LSN>;<타겟 LSN들의 세트>]로서 제시될 수 있다. 일 실시예에서, <베이스라인 LSN>은 단일 LSN(예를 들어, '0' 또는 'a')일 수 있다. <타겟 LSN들의 세트>는 단일 LSN(예를 들어, 'b'), 개별적인 LSN들의 시퀀스(예를 들어, 'b, c'), LSN들의 포괄적인 범위(예를 들어, ‘c..d’), 또는 그것들의 조합(예를 들어, ‘b,c,d..e’)일 수 있다. c..d와 같은 포괄적인 범위는 충분한 정보가 c와 d 사이의 임의의 볼륨을 복구하기 위해 이용 가능하다는 것을 표시한다. 예시적인 신택스에 따라, 타겟 LSN들은 베이스라인 LSN 보다 크거나 동등하다. 또한 예시적인 신택스에 따라, 로그 섹션의 LSN들은 오름차순으로 나열된다.

다양한 실시예들에서, 로그 섹션에서의 레코드들은 AULR들 및/또는 DULR들의 조합일 수 있다. 로그 섹션은 단지 DULR들 또는 단지 AULR들을 대안적으로 포함할 수 있다. 예를 들어, 로그 섹션은 단지 베이스라인과 타겟 LSN들 사이에서 수정되었던 사용자 페이지들에 대한 AULR들을 포함할 수 있다. 다양한 실시예들에서, 타겟 LSN들이 아닌 LSN들에서의 사용자 페이지들의 버전들을 생성할 수 있는 것이 요구되지 않는다. 예를 들어, 로그 섹션 L(a;c]는 LSN b(여기서 a<b<c)에서의 사용자 페이지들을 생성하기에 충분한 정보를 가지고 있지 않을 수 있다.

볼륨의 초기 상태가 모두 0으로 구성되는 것을 가정하면, 형태 L(0;a]의 로그 섹션은 LSN a에서의 볼륨을 나타낼 수 있다.

본 출원에 설명된 로그 섹션 표기는 다수의 데이터/사용자 페이지를 포함하는 볼륨에 대한 LSN들을 가리킨다. 예를 들어, 단지 두 페이지, x 및 y를 포함하는 볼륨을 고려하자. LSN 1을 갖는 로그 레코드는 페이지 x에 대한 AULR일 수 있고 LSN 2를 갖는 로그 레코드는 페이지 y에 대한 AULR일 수 있다. 예를 계속하여, LSN들 3 및 5를 갖는 로그 레코드들은 페이지 x에 대한 DULR들일 수 있고 LSN들 4 및 6을 갖는 로그 레코드들은 페이지 y에 대한 DULR들일 수 있다. 판독 요청이 페이지 y에 대해 들어오면, 데이터베이스 서비스는 페이지 y에 대한 최근 AULR인, LSN 2의 AULR로 시작하고, LSN들 4 및 6으로부터의 변경들을 그것 위에 적용할 수 있다. 이와 유사하게, 페이지 x에 대한 판독 요청에 대해, 데이터베이스 서비스는 LSN 1의 AULR로 시작하고 그 후 페이지 x를 리턴하기 전 LSN들 3 및 5의 로그 레코드들로부터의 변경들을 요청자에 적용할 수 있다.

920에 도시된 바와 같이, 복수의 로그 레코드는 분산 데이터베이스-최적화 저장 시스템의 저장 노드들 중에 저장될 수 있다. 일 실시예에서, 소정의 로그 레코드는 분산 데이터베이스-최적화 저장 시스템의 하나 이상의 저장 노드에 저장될 수 있다. 일 실시예에서, 분산 데이터베이스-최적화 저장 시스템은 소정의 로그 레코드를 저장하기 위한 하나 이상의 저장 노드를 결정할 수 있거나, 또는 분산 데이터베이스-최적화 저장 시스템은 소정의 로그 레코드를 저장하기 위한 하나 이상의 저장 노드를 표시하는 데이터베이스 엔진 헤드 노드로부터 명령들을 수신할 수 있다. 일부 인스턴스들에서, 각 저장 노드가 소정의 시간에 동일한 하나 이상의 로그 레코드를 저장하지 않을 수 있기 때문에, 저장 시스템의 하나 이상의 노드 및/또는 미러는 현재 로그 레코드들의 완전한 세트를 갖는 최신의 것이 아닐 수 있다.

930에 예시된 바와 같이, 복수의 로그 레코드가 변환될 수 있다. 본 출원에 설명된 예시적인 표기에 표시된 바와 같이, 변환될 수 있는 복수의 로그 레코드는 두 개 이상의 로그 섹션을 포함할 수 있다. 그 두 개 이상의 로그 섹션은 변환을 위한 피연산자들일 수 있다. 피연산자들(예를 들어, L(a;c], L(a;b,d], L(a;b,c..e] 등)과 같은 로그 섹션들의 다양한 예들이 하기에 제공된다. 변환은 다양한 방식들로 발생할 수 있다. 예를 들어, 일 실시예에서, 복수의 로그 레코드를 변환하는 것은 수정된 복수의 로그 레코드를 야기할 수 있다. 수정된 복수의 로그 레코드는 상이한 복수의 로그 레코드일 수 있다. 상이한 복수의 로그 레코드는 본래 유지된 복수의 로그 레코드보다 수가 적거나, 수가 크거나, 또는 수가 동등하나 로그 레코드들 중 적어도 하나에 있어서 상이할 수 있다. 로그 레코드들의 변환은 보다 효율적인 시스템(예를 들어, 저장 공간, 네트워크 사용량 등의 면에서)을 야기할 수 있다.

일 실시예에서, 복수의 노드 및 미러를 갖는 분산 시스템에서, 노드들 및/또는 미러들 중 일부가 최신의 것일 수 있고, 일부는 아닐 수 있다. 그러한 실시예에서, 복수의 로그 레코드를 변환하는 것은 저장 노드들 중 상이한 저장 노드들에 유지되는 로그 레코드들에 차이들이 존재한다는 것을 결정하는 것 및 다양한 노드들에 유지되는 로그 레코드들에서의 그 차이들을 조정하는 것을 포함할 수 있다. 로그 레코드들에서의 차이들을 조정하는 것은 다양한 노드들에 저장된 다양한 로그 레코드들을 조정하는 로그 레코드들의 전체 마스터 로그의 형태로 수정된 복수의 로그 레코드를 생성 및/또는 재구성하는 것을 포함할 수 있다. 일 실시예에서, 마스터 로그는 그 후 로그들의 컨텐츠를 동기화하기 위해(예를 들어, 최신의 것이 아닌 로그를 대체함으로써) 다양한 노드들 및/또는 미러들에 제공될 수 있다. 또는, 일 실시예에서, 마스터 로그는 특정한 노드 상에 유지될 수 있다. 마스터 로그는 로그 조정의 다음 발생까지 저장 노드들의 마스터 로그로 간주될 수 있다.

로그 조정을 예시하기 위해, 세 개의 저장 노드, SN1, SN2, 및 SN3을 갖는 간단한 예를 고려하자. SN1은 식별자들(LSN 1, LSN 2, 및 LSN 3)을 갖는 로그 레코드들을 저장할 수 있다. SN2는 식별자들(LSN 3, LSN 4, 및 LSN 5)을 갖는 로그 레코드들을 저장할 수 있고, SN3은 식별자(LSN 6)를 갖는 로그 레코드를 저장할 수 있다. 로그 레코드들을 변환하는 것은 SN1 및 SN2 양자에 저장되지 않았던, LSN 3의 두 개의 인스턴스들이 아닌 LNS들 1 내지 6의 인스턴스를 한 번 포함하는 마스터 로그 레코드를 생성하는 것을 포함할 수 있다. 로그 조정을 수행하는 것은 하나 이상의 로그 동작을 로그 레코드들에 적용하는 것을 포함할 수 있다. 예시적인 로그 동작들은 로그 레코드들 병합하는 것, 가지치는 것, 자르는 것, 축소하는 것, 용합하는 것, 및/또는 다르게 삭제하는 것 또는 추가하는 것을 포함한다. 그러한 예시적인 로그 동작들은 하기에서 보다 상세하게 설명된다.

본 출원에 설명되는 바와 같이, 일 실시예에서, 로그 레코드들을 변환하는 것은 복수의 로그 레코드를 병합하는 것을 포함할 수 있다. 로그 레코드들을 병합하는 것은 델타 로그 레코드를 신규 베이스라인 로그 레코드로 변환하는 것을 포함할 수 있다. LSN들 1, 2, 15, 및 16이 각각의 AULR들의 식별자들이고 LSN들 2 내지 14가 각각의 DULR들의 식별자들인 데이터 페이지들 x 및 y에 대한 예를 고려하자. 로그 레코드들을 병합하는 것은 LSN 8의 DULR을 AULR로 변환하는 것을 포함할 수 있다. LSN 8을 AULR로 변환하기 위해, LSN 8의 로그 레코드를 포함하는, LSN 8과 동일한 데이터 페이지(예를 들어, 데이터 페이지 y)에 대응하는 로그 레코드들로부터의 변경들이 해당 데이터 페이지에 대한 최근 AULR에 적용될 수 있다. 예를 들어, LSN 2가 데이터 페이지 y에 대한 AULR에 대응하고 LSN들 4, 6, 및 8이 데이터 페이지 y에 대한 DULR들에 대응하면, LSN 8의 DULR을 AULR로 변환하는 것은 LSN들 4, 6, 및 8의 로그 레코드들의 변경들을 LSN 2의 AULR에 적용하는 것을 포함한다. 본 출원에서 설명된 바와 같이, 특정 상황들에서, LSN 2, 4, 및 6의 로그 레코드들은 그 후 가비지 수집되거나 다르게 삭제될 수 있는 반면, 다른 상황들에서(예를 들어, 연속적인 스냅샷 또는 다른 종속을 위해), 그 LSN들은 더 이상 요구되지 않을 때까지 유지될 수 있다.

다양한 실시예들에서, 복수의 로그 레코드는 이전 상태에 대한 데이터를 복구하기 위해 사용 가능한 적어도 하나의 스냅샷(예를 들어, 도 8의 방법에 따라 생성된 바와 같은 스냅샷)과 연관될 수 있다. 그러한 실시예들에서, 복수의 레코드를 변환하는 것은 적어도 부분적으로, 스냅샷에 기초하여, 하나 이상의 로그 레코드를 가비지 수집하는 것을 포함할 수 있다. 예를 들어, 이전의 병합하는 예를 계속하여, LSN들 2, 4, 및 6이 연속적인 스냅샷의 일부로서 요구되면, 그 LSN들에 대응하는 로그 레코드들이 가비지 수집 가능하지 않을 수 있다(그리고 제1 위치에 병합되지 않을 수 있다). 대조적으로, 그 로그 레코드들이 스냅샷의 일부로서 요구되지 않으면, 그것들은 가비지 수집될 수 있다. 예를 들어, 개별적인 스냅샷이 LSN들 2, 4, 및 6 이후의 LSN에, 예를 들어, LSN 10에 존재하면, LSN들 2, 4, 및 6의 로그 레코드들은 LSN 8의 로그 레코드가 AULR이기 때문에 요구되지 않을 수 있다. 따라서, LSN들 2, 4, 및 6의 로그 레코드들은 가비지 수집될 수 있다.

본 출원에서 설명된 바와 같이, 로그 레코드들을 변환하는 것은 하나 이상의 로그 레코드가 가비지 수집 가능하다는 것을 표시하는 것을 포함할 수 있다. 그러한 예에서, 하나 이상의 로그 레코드가 가비지 수집 가능하다는 것을 표시하도록 로그 레코드들을 변환하는 것은 그 로그 레코드들이 가비지 수집 가능하다는 것을 표시하도록 그 하나 이상의 로그 레코드와 연관된 메타데이터를 생성 및/또는 수정하는 것을 포함할 수 있다.

일 실시예에서, 로그 레코드들을 변환하는 것은 하나 이상의 로그 레코드를 삭제하는 것을 포함할 수 있다. 본 출원에서 설명된 바와 같이, 로그 레코드를 삭제하는 것은 다른 동작들 중에서도, 가지치기 또는 자르기 동작의 일부일 수 있다. 로그 레코드를 삭제하는 것은 일부 실시예들에서, 가비지 수집이 백그라운드 프로세스로서 소극적으로 그리고 느리게 수행될 수 있는 반면, 삭제는 우위 프로세스로서 수행될 수 있다는 점에서, 가비지 수집과 상이할 수 있다.

일 실시예에서, 로그 레코드들을 변환하는 것은 복수의 로그 레코드를 자르기 위해 자르기 동작을 수행하는 것을 포함할 수 있다. 자르기 동작을 수행하는 것은 타겟 식별자의 값(예를 들어, 타겟 LSN) 미만의 또는 그 이하의 각각의 식별자들(예를 들어, LSN 값)을 갖는 하나 이상의 로그 레코드를 삭제하는 것(및/또는 가비지 수집 가능한 것으로 표시하는 것)을 포함할 수 있다. 자르기 동작은 로그 섹션의 베이스라인 LSN을 증가하는데 사용될 수 있다. 각각의 식별자들이 시간에 따라 순차적으로 순서화될 수 있고, 따라서, 일부 실시예들에서, 자르는 것은 타겟 식별자의 관련 시간 전의 각각의 관련 시간들을 갖는 로그 레코드들을 삭제하는 것을 포함할 수 있다.

일 실시예에서, 동작에 대한 좌측 인수는 베이스라인 LSN B1을 갖는 로그 섹션일 수 있고 우측 인수는 제거될 LSN들의 범위일 수 있다. 따라서, 결과는 타겟 LSN에 대응하는 시점에서 시작하는 LSN들을 갖는 하나 이상의 로그 레코드일 수 있다. 일례로서, 다음 예시적인 자르기 동작, L(a;c]-(a,b]=L(b;c]을 고려하자, '-'는 자르기를 표기한다. 이에 따라, 부분 (a,b]는 (a;c]로부터 자르기되어, 새로운 범위 (b;c]를 야기한다. 상기에서 언급한 바와 같이, 단순한 () 괄호들은 범위의 개방형 경계들을 표시할 수 있고 사각 [] 괄호들은 범위의 폐쇄형 경계들을 표시할 수 있다. 다른 자르기 예로서, 자르기 동작 L(a;b,d]-(a,c]를 고려하자. 결과는 L(c;d]이다. 또 다른 자르기 예로서, L(a;b,c..e]-(a,d]=L(d;e]인 자르기 동작을 고려하자.

자르기 동작의 결과로서, 신규 베이스라인 LSN보다 적거나 동등한 LSN을 갖는 하나 이상의 로그 레코드는 삭제(또는 가비지 수집)될 수 있다. 일부 예들에서, 본래 로그 섹션이 자르기 위한 임의의 그러한 로그 레코드들을 포함하지 않을 수 있다는 것이 가능하다. 그 예들에서, 자르기 동작은 로그 섹션의 크기의 감소를 야기하지 않을 수 있다.

일 실시예에서, 로그 레코드들을 변환하는 것은 복수의 로그 레코드를 가지치기 위해 가지치기 동작을 수행하는 것을 포함할 수 있다. 가지치기 동작을 수행하는 것은 타겟 식별자의 값(예를 들어, 타겟 LSN) 초과의 또는 그 이상의 각각의 식별자들(예를 들어, LSN 값)을 갖는 하나 이상의 로그 레코드를 삭제하는 것(및/또는 가비지 수집 가능한 것으로 표시하는 것)을 포함할 수 있다. 가지치기 동작은 로그 섹션의 트레일링 부분을 제거하는데 사용될 수 있다. 자르기 동작과 유사하게, 각각의 식별자들이 시간에 따라 순차적으로 순서화될 수 있기 때문에, 일부 실시예들에서, 가지치는 것은 타겟 식별자의 관련 시간 이후의 각각의 관련 시간들을 갖는 로그 레코드들을 삭제하는 것을 포함할 수 있다.

일 실시예에서, 가지치기 동작에 대한 좌측 인수는 타겟 LSN(들) T1을 갖는 로그 섹션일 수 있고 우측 인수는 신규 타겟 LSN(들) T2일 수 있고, T2는 T1의 적절한 서브세트이다. 가지치기 동작은 제거된 LSN들이 유지된 LSN들보다 크도록 LSN들을 제거할 수 있다. 예를 들어, T2에서의 L2를 갖는 {T1-T2}에서의 LSN들 L3에 대해, 다음 조건: L3>L2이 참으로 유지될 수 있다.

일례로서, 다음 예시적인 가지치기 동작, L(a;b,c]@[b]=L(a;b]을 고려하자, ‘@’는 자르기를 표기한다. 이에 따라, 타겟 식별자 b보다 큰 각각의 식별자들을 갖는 로그 레코드들의 일부는 로그 섹션 L(a;b,c]로부터 삭제된다. 다른 예는 L(a;b..d]@[b..c]=L(a;b..c]를 포함한다. 자르기 동작을 갖는 경우가 가지치기 동작이었던 바와 같이, 본래의 로그 섹션은 가지치기 위한 임의의 그러한 로그 레코드들을 포함하지 않을 수 있다. 그 예들에서, 가지치기 동작은 로그 섹션의 크기의 감소를 야기하지 않을 수 있다.

일 실시예에서, 로그 레코드들을 변환하는 것은 복수의 로그 레코드를 축소하는 것을 포함할 수 있다. 축소 동작은 최상위 타겟 LSN을 변경하지 않고 로그 섹션의 타겟 LSN들의 세트를 축소할수 있다. 따라서, 축소 동작은 가지치기 동작에 대한 보완 동작일 수 있다. 축소하는 것은 로그 섹션의 헤드 또는 테일 말단을 절단하지 않을 수 있으나 대신 섹션의 중간 부분을 제거할 수 있다. 축소 동작의 예는 스냅샷의 연속적인 부분을 제거하는 것일 수 있다. 예를 들어, 연속적인 스냅샷이 마지막 이틀에 대해 요청되고 개별적인 스냅샷이 마지막 30일에 대해 요청되는 경우, 연속적인 스냅샷의 일부가 이틀보다 더 오래되었을 때, 일부는 제거될 수 있고 그렇게 함으로써 하나 이상의 개별적인 스냅샷을 야기할 수 있다.

축소 동작은 ‘@@'에 의해 표기될 수 있다. 축소 동작에 대한 좌측 인수는 타겟 LSN T1을 갖는 로그 섹션일 수 있고 우측 인수는 다음 타겟 LSN T2이고, T2는 T1의 적절한 서브세트이다. T1에서의 최상위 LSN은 T2에서의 최상위 LSN과 동등할 수 있다. 예로서, L(a;b..c]@@[c]는 L(a;c]를 야기할 수 있다. 다른 예로서, L(a;a..b,c..e]@@[b,d..e]는 L(a;b,d..e]을 야기할 수 있다. 어떤 로그 레코드들도 축소 동작의 일부로서 삭제되도록 요청되지 않을 수 있다는 것을 주의하자. 일부 예들에서, 일부 로그 레코드들은 신규 타겟 LSN들에 사용자 페이지 버전들을 생성하도록 요청되지 않을 수 있다. 그 로그 레코드들은 안전하게 삭제될 수 있으나 삭제되도록 요청되지 않는다. 그 로그 레코드들은 그 자리에 남겨지고/지거나 느리게 가비지 수집될 수 있다. 어떤 로그 레코드들이 삭제 가능한지(예를 들어, 삭제 또는 가비지 수집을 통해)를 식별하는 것은 복수의 로그 레코드 중의 결정된 종속성들에 따라 결정될 수 있다. 예를 들어, 특정 DULR들은 하나 이상의 이전 DULR 및/또는 이전 AULR에 종속적일 수 있다. 따라서, 일 실시예에서, 삭제 가능하고 그것에 종속하는 다른 로그 레코드들을 갖지 않는 로그 레코드가 삭제 및/또는 가비지 수집 가능할 수 있는 반면, 그와 다르게 삭제 가능할 수 있으나 그것에 종속하는 다른 로그 레코드들을 갖는 로그 레코드는 유지될 수 있고 삭제 및/또는 가비지 수집되지 않을 수 있다.

일부 실시예들에서, 베이스라인 LSN을 유연한 방법으로 증가시키는 것이 가능한(예를 들어, 자르기 동작을 사용하여) 한편, 타겟 LSN의 유사한 감소는 이용 가능하지 않을 수 있다는 것을 주의하자. 예를 들어, L(a;c]이 L(b;c]로 변환될 수 있는 한편, 일부 실시예들에서, 그것은 b와 c 사이 AULR(들)로 대체된, L(a;c]가 a와 b 사이 일부 로그 레코드(들)을 잃을 수 있기 때문에, L(a;b]로 변환되지 않을 수 있다. 따라서, L(a;c]는 LSN b에서의 전체 볼륨을 생성하기에 충분한 정보가 부족할 수 있다. 로그 섹션의 신규 타겟 LSN 세트는 이전 타겟 LSN 세트의 서브 세트이어야 할 수 있다. 예를 들어, L(a;b..c] 및 L(a;a..c]은 LSN b에서의 전체 볼륨을 생성하기에 필요한 정보를 가지지 않을 수 있으나 가지치기 및 축소 동작들을 사용하여 L(a;b]로 변환될 수 있다.

일 실시예에서, 로그 레코드들을 변환하는 것은 용합 동작으로 복수의 로그 레코드를 다른 복수의 로그 레코드와 조합하는 것을 포함할 수 있다. 예를 들어, 용합 동작은 로그 섹션들 양자의 타겟 LSN들이 유지되도록 두 개의 인접한 로그 섹션을 단일 로그 섹션으로 조합하는 것을 포함할 수 있다. 용합 동작은 ‘+’에 의해 제시될 수 있다. 좌측 인수는 하부 베이스라인 LSN B1을 갖는 로그 섹션을 포함할 수 있고 최상위 타겟 LSN은 T1이다. 우측 인수는 상부 베이스라인 LSN B2를 갖는 로그 섹션을 포함할 수 있다. B2는 일부 실시예들에서, T1과 동등하다. 하나의 예시적인 용합 동작은 L(a;b]+L(b;c]=L(a;b,c]이다. 다른 예시적인 용합 동작은 L(a;b,c]+L(c;d,e]=L(a;b,c,d,e]이다. 다양한 실시예들에서, 어떤 로그 레코드들도 용합 동작의 일부로서 삭제되지 않을 수 있다.

일 실시예에서, 가비지 수집이 임의의 스냅샷들을 유지하지 않고 수행되면, 로그는 L(0;t]에 의해 제시될 수 있다. 어떤 가비지 수집도 수행되지 않으면, 로그는 L(0;0..t]에 의해 제시될 수 있다.

LSN 'a'에서의 볼륨을 나타내기 위한 표시는 V[a]일 수 있다. V[0]는 모든 제로를 포함하도록 가정될 수 있다. 일 실시예에서, 볼륨의 로그 레코드들을 변환하는 것은 ‘*’에 의해 제시되는, 구성 동작을 포함할 수 있다. 신규 볼륨이 하부 LSN에서의 볼륨 및 LSN 갭에 대응하는 로그 섹션을 고려하여 최상위 LSN으로 생성될 수 있다. 좌측 인수는 LSN B에서의 볼륨일 수 있고 우측 인수는 베이스라인 LSN B 및 단일 타겟 LSN T를 갖는 로그 섹션일 수 있다. 다수의 타겟 LSN을 갖는 로그 섹션은 원하는 볼륨을 구성하기 전 관심있는 단일 LSN으로 가지치기 및/또는 축소될 수 있다. 예는 V[a]*L(a;b]=V[b]를 포함한다.

일 실시예에서, 로그 레코드들을 변환하는 것은 복수의 로그 레코드에 대한 동작들의 조합들을 수행하는 것을 포함할 수 있다. 동작들의 조합으로부터 유도된 다음 변환: {L(b;c],L(b;d]}→ L(b;c,d]을 고려하자. 그러한 변환은 다음: L(b;d]-(b,c]=L(c;d] 및 L(b;c]+L(c;d]=L(B;c,d]과 같이 자르기 및 용합 동작들로부터 유도될 수 있다. 다른 예시적인 유도된 변환은 이전 예: {L(a;c],L(b;d]}→L(b;c,d]를 확장하는데, 이는 이전 예로부터 자르기 및 용합을 포함하고 추가적인 자르기 L(a;c]-(a,b]=L(b;c]을 더 포함한다. ‘→’의 사용은 동작들의 세부사항들을 제시하지 않고 포괄적인 변환을 나타낸다는 것을 주의하자. 예를 들어, {L1,L2}→{L3}은 변환을 수행하기 위한 기본 동작들을 제시하지 않는 L1 및 L2로부터의 L3으로의 변환이다.

다양한 실시예들에서, 복수의 로그 레코드 상에서 다수의 동작의 조합들을 수행하는 것은 스냅샷 동작들(예를 들어, 도 8에서와 같이 스냅샷을 취하는 것, 복구하는 것, 절단하는 것, 및/또는 삭제하는 것의 일부로서의), 또는 다른 동작들 중에서도, 로그 레코드 조정을 용이하게 할 수 있다. 개별적인 그리고 연속적인 스냅샷들을 취하는 것, 복구하는 것, 및 삭제하는 것에 대한 예시적인 조합들은 뒤따른다.

개별적인 스냅샷을 취하는 동작들을 조합하는 예에 대해, 분산 저장 시스템에 대한 라이브 로그(live log)의 초기 상태는 L(0;t]일 수 있다. 스냅샷은 테일이 LSN a에 도달할 때 취해질 수 있다, L(0;a,t]. L(0;a,t]은 그 후 [a]에서 가지치기될 수 있다, L(0;a,t]@[a]=L(0;a]. L(0;a]은 스냅샷 저장장치 위치로 복사될 수 있는데, 이는 분산 저장 시스템과 별개의 저장장치 위치일 수 있다. 다른 스냅샷은 테일이 LSN b에 도달할 때 취해질 수 있다, L(0;a,b,t]. L(0;a,b,t]은 그 후 L(0;a,b,t]-(0,a]에 따라 자르기되어, L(a;b,t)을 야기할 수 있다. L(a;b,t)은 그 후 [b]에서 가지치기되어(L(a;b,)@[b]), L(a;b]을 야기할 수 있다. L(a;b]은 그 후 또한 스냅샷 저장장치 위치로 복사될 수 있다.

개별적인 스냅샷을 복구하는 동작들을 조합하는 예에 대해, 스냅샷 저장장치 위치에서 이용 가능할 다음: L(0;a],L(a;b]을 고려하자. L(0;a] 및 L(a;b]은 복구 목적지로 복사될 수 있고 L(0;a]+L(a;b]=L(0;a,b]에 따라 용합될 수 있다. 용합된 섹션은 그 후 L(0;a,b]@@[b]=L(0;b]에 따라 축소될 수 있다. L(0;b]은 복구하기 원하는 스냅샷일 수 있고 신규 볼륨을 시작하는데 사용될 수 있다.

예전 개별적인 스냅샷을 삭제하는 동작들을 조합하는 예에 대해, 다음 초기 라이브 로그 상태 L(0;a,b,t]을 고려하자. L(a;a,b,t]@@[b,t]=L(0;b,t]은 a에서의 스냅샷을 삭제하는데 사용될 수 있고 L(0;a,b,t]@@[t]=L(0;t]은 스냅샷들 a 및 b 양자를 삭제하는데 사용될 수 있다.

연속적인 스냅샷을 취하는 동작들을 조합하는 예에 대해, 분산 저장 시스템에 대한 라이브 로그의 초기 상태는 개별적인 스냅샷에서의 경우를 취함에 따라 L(0;t]일 수 있다. 연속적인 스냅샷은 L(0;a..t]에 의해 표시되는 바와 같이, 테일이 LSN a에 도달할 때 시작될 수 있다. 테일이 LSN b(b<t)를 지난 후, L(0;.a..t]이 [a..b]에 의해 가지치기(@@)되어 L(0;a..b]을 제공한다. L(0;a..b]은 그 후 또한 스냅샷 저장장치 위치로 복사될 수 있다. 테일이 LSN c(c<t)를 지난 후, L(0;a..t]@@[a..c]=L(0;a..c). L(0;a..c)@@[b..c]=L(0;b..c]. L(0;b..c]은 그 후 (0,a]에서 자르기될 수 있어 L(b;b..c]을 제공하는데, 이는 그 후 스냅샷 저장장치 위치로 복사될 수 있다. 연속적인 스냅샷은 테일이 LSN d에 도달할 때 스트롭(strop)될 수 있다: L(0,a..d,t].

연속적인 스냅샷을 복구하는 동작들을 조합하는 예에 대해, 스냅샷 저장장치 위치에서 이용 가능할 다음: L(0;a..b], 및 L(b;b..c]을 고려하자. L(0;a..b], 및 L(b;b..c]은 복구 목적지로 복사될 수 있고 여기서 두 개의 로그 섹션이 L(0;a..b] + L(b;b..c] = L(0;a..c]과 같이 함께 용합될 수 있다. LSN x(여기서 b<x<c)에 대해 복구가 요청되었다면, 다음: L(0;a..c] @[a..x]=L(0;a..x]이 수행될 수 있다. 결과는 그 후 [x]에서 축소(@@)되어 L(0;x]을 야기할 수 있다. 원하는 스냅샷은 L(0;x]일 수 있고 신규 볼륨을 시작하는데 사용될 수 있다.

연속적인 스냅샷을 삭제하는 동작들을 조합하는 다음 예들을 고려하자, 라이브 로그의 초기 상태는 L(0,a..d,t]이다. L(0,a..d,t]은 연속적인 스냅샷 전체를 삭제하기 위해 [t]에 의해 축소되어 L(0;t](어떤 스냅샷들도 유지되지 않는 로그 섹션)을 야기할 수 있다. 다른 예로서, L(0,a..d,t]은 c로부터 d까지의 연속적인 스냅샷의 일부를 삭제하기 위해 [a..c,t]에 의해 축소되어 L(0,a..c,t]을 야기할 수 있다. 다른 예로서, L(0,a..d,t]은 a로부터 c까지의 연속적인 스냅샷의 일부를 삭제하기 위해 [c..d,t]에 의해 축소되어 L(0,c..d,t]을 야기할 수 있다.

현재 연속적인 스냅샷을 절단하는 다음 예를 고려하자, 라이브 로그의 초기 상태는 L(0,a..t]이고, 여기서 c<t이다. L(0,a..t]@@[c..t]=L(0;c..t], 이는 현재 연속적인 스냅샷의 단지 최근의 일부를 포함할 수 있다.

다양한 실시예들에서, 데이터베이스 서비스는 사용자로부터, 스냅샷에 대한 시간 프레임들, 범위들, 또는 윈도우들의 요청을 수신할 수 있고/있거나 요청된 스냅샷의 유형(예를 들어, 연속적인 또는 개별적인)의 표시를 수신할 수 있다. 예를 들어, 사용자는 그들이 이전 이틀 동안의 연속적인 스냅샷들 및 이전 30일 동안의 개별적인 스냅샷들이 원한다는 것을 요청할 수 있다. 데이터베이스 서비스는 그 후 사용자의 요청을 충족시키기 위해 로그 섹션들 상에서 수행할 로그 레코드 동작(들)(예를 들어, 자르기, 축소, 가지치기 등)을 결정할 수 있다. 예를 계속하여, 연속적인 스냅샷의 일부가 이틀보다 더 오래될 때, 시스템은 축소 동작이 더 이상 요구되지 않는 로그 레코드들에 대한 공간을 환원(예를 들어, 가비지 수집을 통해)하기에 적절하다는 것을 결정할 수 있다.

본 출원에 설명된 방법들은 다양한 실시예들에서 하드웨어 및 소프트웨어의 임의의 조합에 의해 구현될 수 있다. 예를 들어, 일 실시예에서, 방법들은 프로세서들에 결합된 컴퓨터 판독 가능 저장 매체 상에 저장된 프로그램 명령들을 실행하는 하나 이상의 프로세서를 포함하는 컴퓨터 시스템(예를 들어, 도 10에서와 같은 컴퓨터 시스템)에 의해 구현될 수 있다. 프로그램 명령들은 본 출원에 설명된 기능(예를 들어, 본 출원에 설명된 데이터베이스 서비스/시스템들 및/또는 저장 서비스들/시스템을 구현하는 다양한 서버들 및 다른 구성요소들의 기능)을 구현하도록 구현될 수 있다.

도 10은 다양한 실시예들에 따라, 본 출원에 설명된 데이터베이스 시스템들의 적어도 일부를 구현하도록 구성된 컴퓨터 시스템을 예시하는 블록도이다. 예를 들어, 컴퓨터 시스템(1000)은 상이한 실시예들에서, 데이터베이스 티어의 클라이언트들을 대신하여 데이터베이스 테이블들 및 관련 메타데이터를 저장하는 개별 분산 데이터베이스-최적화 저장 시스템의 복수의 저장 노드 중 하나, 또는 데이터베이스 티어의 데이터베이스 엔진 헤드 노드를 구현하도록 구성될 수 있다. 컴퓨터 시스템(1000)은 이들에 제한되지는 않으나, 개인용 컴퓨터 시스템, 데스크탑 컴퓨터, 랩탑 또는 노트북 컴퓨터, 메인프레임 컴퓨터 시스템, 핸드헬드 컴퓨터, 워크스테이션, 네트워크 컴퓨터, 고객 디바이스, 애플리케이션 서버, 저장 디바이스, 전화, 모바일 전화, 또는 일반적으로 임의의 유형의 컴퓨팅 디바이스를 포함하는, 다양한 유형들의 디바이스들 중 임의의 디바이스일 수 있다.

컴퓨터 시스템(1000)은 입력/출력(I/O) 인터페이스(1030)를 통해 시스템 메모리(1020)에 결합되는 하나 이상의 프로세서(1010)(그 각각은 다수의 코어를 포함할 수 있는데, 이는 단일 또는 다수-스레드일 수 있다)를 포함한다. 컴퓨터 시스템(1000)은 I/O 인터페이스(1030)에 결합된 네트워크 인터페이스(1040)를 더 포함한다. 다양한 실시예들에서, 컴퓨터 시스템(1000)은 하나의 프로세서(1010)를 포함하는 단일 프로세서 시스템, 또는 몇몇(예를 들어, 2, 4, 8, 또는 또 다른 적합한 수) 프로세서(1010)를 포함하는 멀티프로세서 시스템일 수 있다. 프로세서들(1010)은 기존 명령들을이 가능한 임의의 적합한 프로세서들일 수 있다. 예를 들어, 다양한 실시예들에서, 프로세서들(1010)은 x86, PowerPC, SPARC, 또는 MIPS ISA들, 또는 임의의 다른 적합한 ISA와 같은, 다양한 명령 세트 아키텍처들(ISA들) 중 임의의 아키텍처를 구현하는 범용 또는 내장 프로세서들일 수 있다. 다수의 프로세서 시스템들에서, 프로세서들(1010) 각각은 필수적이지는 않으나, 통상, 동일한 ISA를 구현할 수 있다. 컴퓨터 시스템(1000)은 또한 통신 네트워크(예를 들어, 인터넷, LAN등)를 통해 다른 시스템들 및/또는 구성요소들과 통신하기 위한 하나 이상의 네트워크 통신 디바이스(예를 들어, 네트워크 인터페이스(1040))를 포함한다. 예를 들어, 시스템(1000) 상에서 실행하는 클라이언트 애플리케이션은 본 출원에서 설명된 데이터베이스 시스템들의 구성요소들 중 하나 이상을 구현하는 서버들의 클러스터 상의 또는 단일 서버 상의 서버 애플리케이션과 통신하기 위해 네트워크 인터페이스(1040)를 사용할 수 있다. 다른 예에서, 컴퓨터 시스템(1000) 상에서 실행하는 서버 애플리케이션의 인스턴스는 다른 컴퓨터 시스템들(예를 들어, 컴퓨터 시스템들(1090)) 상에서 구현될 수 있는 서버 애플리케이션(또는 또 다른 서버 애플리케이션)의 다른 인스터스들과 통신하기 위해 네트워크 인터페이스(1040)를 사용할 수 있다.

예시된 실시예에서, 컴퓨터 시스템(1000)은 또한 하나 이상의 영구 저장 디바이스(1060) 및/또는 하나 이상의 I/O 디바이스(1080)를 포함한다. 다양한 실시예들에서, 영구 저장 디바이스들(1060)은 디스크 드라이브들, 테이프 드라이버들, 고체 상태 메모리, 다른 대량 저장 디바이스들, 또는 임의의 다른 영구 저장 디바이스에 대응할 수 있다. 컴퓨터 시스템(1000)(또는 분산 애플리케이션 또는 그 상에서 작동하는 운영 시스템)은 요구 시 영구 저장 디바이스들(1060)에 명령들 및/또는 데이터를 저장할 수 있고, 필요 시 저장된 명령 및/또는 데이터를 검색할 수 있다. 예를 들어, 일부 실시예들에서, 컴퓨터 시스템(1000)은 저장 시스템 서버 노드를 호스팅할 수 있고, 영구 저장소(1060)는 해당 서버 노드에 연결된 SSD들을 포함할 수 있다.

컴퓨터 시스템(1000)은 프로세서(들)(1010)에 의해 액세스 가능한 명령들 및 데이터를 저장하도록 구성되는 하나 이상의 시스템 메모리(1020)를 포함한다. 다양한 실시예들에서, 시스템 메모리들(1020)은 임의의 적합한 메모리 기술, (예를 들어, 하나 이상의 캐시, 정적 랜덤 액세스 메모리(SRAM), DRAM, RDRAM, EDO RAM, DDR 10 RAM, 동기식 동적 RAM (SDRAM), 램버스 RAM, EEPROM, 비-휘발성/플래시-유형 메모리 또는 임의의 다른 유형의 메모리)을 사용하여 구현될 수 있다. 시스템 메모리(1020)는 본 출원에 설명된 방법들 및 기술들을 구현하기 위해 프로세서(들)(1010)에 의해 실행 가능한 프로그램 명령들(1025)을 포함할 수 있다. 다양한 실시예들에서, 프로그램 명령들(1025)은 플랫폼 고유의 바이너리, JavaTM 바이트-코드와 같은 임의의 해석된 언어로, 또는 C/C++, JavaTM 등과 같은 임의의 다른 언어로, 또는 이들의 임의의 조합으로 인코딩될 수 있다. 예를 들어, 예시된 실시예에서, 프로그램 명령들(1025)은 상이한 실시예들에서, 데이터베이스 티어의 클라이언트들을 대신하여 데이터베이스 테이블들 및 관련 메타데이터를 저장하는 개별 분산 데이터베이스-최적화 저장 시스템의 복수의 저장 노드 중 하나, 또는 데이터베이스 티어의 데이터베이스 엔진 헤드 노드의 기능을 구현하도록 실행 가능한 프로그램 명령들을 포함한다. 일부 실시예들에서, 프로그램 명령들(1025)은 다수의 개별 클라이언트, 서버 노드, 및/또는 다른 구성요소를 구현할 수 있다.

일부 실시예들에서, 프로그램 명령들(1025)은 UNIX, LINUX, SolarisTM, MacOSTM, WindowsTM 등과 같은, 다양한 운영 시스템들 중 임의의 운영 시스템일 수 있는, 운영 시스템(미도시)을 구현하도록 실행 가능한 명령들을 포함할 수 있다. 프로그램 명령들(1025) 중 임의의 또는 모든 프로그램 명령들은 컴퓨터 프로그램 제품, 또는 소프트웨어로서 제공될 수 있는데, 이는 그 상에 명령들을 저장한 비-일시적 컴퓨터 판독 가능 저장 매체를 포함할 수 있고, 이들은 다양한 실시예들에 따라 프로세스를 수행하기 위해 컴퓨터 시스템(또는 다른 전자 디바이스들)을 프로그래밍하는데 사용될 수 있다. 비-일시적 컴퓨터 판독 가능 저장 매체는 기계(예를 들어, 컴퓨터)에 의해 판독 가능한 형태(예를 들어, 소프트웨어, 프로세싱 애플리케이션)로 정보를 저장하기 위한 임의의 메커니즘을 포함할 수 있다. 일반적으로 말해서, 비-일시적 컴퓨터 액세스 가능 매체는 마그네틱 또는 광 미디어, 예를 들어, I/O 인터페이스(1030)를 통해 컴퓨터 시스템(1000)에 결합된 디스크 또는 DVD/CD-ROM과 같은 메모리 미디어 또는 컴퓨터 판독 가능 저장 매체를 포함할 수 있다. 비-일시적 컴퓨터 판독 가능 저장 매체는 또한 RAM(예를 들어 SDRAM, DDR SDRAM, RDRAM, SRAM 등), ROM 등과 같은 임의의 휘발성 또는 비-휘발성 미디어를 포함할 수 있는데, 이는 시스템 메모리(1020) 또는 다른 유형의 메모리로서 컴퓨터 시스템(1000)의 일부 실시예들에 포함될 수 있다. 다른 실시예들에서, 프로그램 명령들은 네트워크 인터페이스(1040)를 통해 구현될 수 있는 바와 같은, 네트워크 및/또는 무선 링크와 같은 통신 매체를 통해 전달되는 전파된 신호(예를 들어, 바송파들, 적외선 신호들, 디지털 신호들 등)의 광학, 음향 또는 다른 형태를 사용하여 전달될 수 있다.

일부 실시예들에서, 시스템 메모리(1020)는 데이터 저장소(1045)를 포함할 수 있는데, 이는 본 출원에 설명된 바와 같이 구성될 수 있다. 예를 들어, 본 출원에 설명된 데이터베이스 티어들의 기능들을 수행하는데 있어 사용되는 트랜잭션 로그, 언두 로그, 캐싱된 페이지 데이터, 또는 다른 정보와 같은, 데이터베이스 티어(예를 들어, 데이터베이스 엔진 헤드 노드 상의)에 의해 저장되는 바와 같이 본 출원에 설명된 정보는 여러 경우들에 그리고 다양한 실시예들에서 데이터 저장소(1045)에 또는 하나 이상의 노드 상의 시스템 메모리(1020)의 또 다른 부분에, 영구 저장소(1060)에, 그리고/또는 하나 이상의 원격 저장 디바이스(1070)에 저장될 수 있다. 이와 유사하게, 저장 티어에 의해 저장된 바와 같이 본 출원에 설명된 정보(예를 들어, 리두 로그 레코드들, 병합된 데이터 페이지들, 및/또는 본 출원에 설명된 분산 저장 시스템들의 기능들 수행하는데 사용되는 다른 정보)는 여러 경우들에 그리고 다양한 실시예들에서 데이터 저장소(1045)에 또는 하나 이상의 노드 상의 시스템 메모리(1020)의 또 다른 부분에, 영구 저장소(1060)에, 그리고/또는 하나 이상의 원격 저장 디바이스(1070)에 저장될 수 있다. 일반적으로, 시스템 메모리(1020)(예를 들어, 시스템 메모리(1020) 내 데이터 저장소(1045)), 영구 저장소(1060), 및/또는 원격 저장소(1070)는 데이터 블록들, 데이터 블록들의 복제본들, 데이터 블록들과 연관된 메타데이터 및/또는 그것들의 상태, 데이터베이스 구성 정보, 및/또는 본 출원에 설명된 방법들 및 기술들을 구현하는데 사용 가능한 임의의 다른 정보를 저장할 수 있다.

일 실시예에서, I/O 인터페이스(1030)는 네트워크 인터페이스(1040) 또는 다른 주변 인터페이스들을 통해서를 포함하여, 시스템에서 프로세서(1010), 시스템 메모리(1020) 및 시스템 내 임의의 다른 디바이스들 간 I/O 트래픽을 조정하도록 구성될 수 있다. 일부 실시예들에서, I/O 인터페이스(1030)는 데이터 신호들을 하나의 구성요소(예를 들어, 시스템 메모리(1020))로부터 또 다른 구성요소(예를 들어, 프로세서(1010))에 의해 사용하기에 적합한 포맷으로 변환하기 위해 임의의 필요한 프로토콜, 타이밍, 또는 다른 데이터 변환들을 수행할 수 있다. 일부 실시예들에서, I/O 인터페이스(1030)는 예를 들어, 다양한 주변 구성요소 상호연결(PCI) 버스 표준 또는 범용 직렬 버스(USB) 표준과 같은, 다양한 유형들의 주변 버스들을 통해 연결되는 디바이스들에 대한 지원을 포함할 수 있다. 일부 실시예들에서, I/O 인터페이스(1030)의 기능은 예를 들어, 노스 브리지(north bridge) 및 사우스 브리지(south bridge)와 같은, 두 개 이상의 개별 구성요소로 분배될 수 있다. 또한, 일부 실시예들에서, 시스템 메모리(1020)에 대한 인터페이스와 같은, I/O 인터페이스(1030)의 기능의 일부 또는 전부는 프로세서(1010)로 직접 포함될 수 있다.

네트워크 인터페이스(1040)는 데이터가 예를 들어, 컴퓨터 시스템(1000) 및 다른 컴퓨터 시스템들(1090)(본 출원에 설명된 하나 이상의 저장 시스템 서버 노드, 데이터베이스 엔진 헤드 노드, 및/또는 데이터베이스 시스템들의 클라이언트)과 같은, 네트워크에 연결된 다른 디바이스들 사이에서 교환되는 것을 허용하도록 구성될 수 있다. 또한, 네트워크 인터페이스(1040)는 컴퓨터 시스템(1000) 및 다양한 I/O 디바이스들(1050) 및/또는 저장소(1070) 사이의 통신을 허용하도록 구성될 수 있다. 입력/출력 디바이스들(1050)은 일부 실시예들에서, 하나 이상의 디스플레이 단자, 키보드, 키패드, 터치패드, 스캐닝 디바이스, 음성 또는 광 인식 디바이스, 또는 하나 이상의 컴퓨터 시스템(1000)에 의해 데이터를 입력 또는 검색하기에 적합한 임의의 다른 디바이스를 포함할 수 있다. 다수의 입력/출력 디바이스(1050)는 컴퓨터 시스템(1000)에 존재할 수 있거나 컴퓨터 시스템(1000)를 포함하는 분산 시스템의 다양한 노드들 상에 분산될 수 있다. 일부 실시예들에서, 유사한 입력/출력 디바이스들은 컴퓨터 시스템(1000)과 별개일 수 있고 네트워크 인터페이스(1040)를 통해서와 같이, 유선 또는 무선 연결을 통해 컴퓨터 시스템(1000)을 포함하는 분산 시스템의 하나 이상의 노드와 상호작용할 수 있다. 네트워크 인터페이스(1040)는 통상 하나 이상의 무선 네트워킹 프로토콜(예를 들어, Wi-Fi/IEEE 802.11, 또는 또 다른 무선 네트워킹 표준)을 지원할 수 있다. 그러나, 다양한 실시예들에서, 네트워크 인터페이스(1040)는 예를 들어, 다른 유형들의 이더넷 네트워크들과 같은, 임의의 적합한 유선 또는 무선의 일반적인 데이터 네트워크들을 통해 통신을 지원할 수 있다. 추가적으로, 네트워크 인터페이스(1040)는 아날로그 음성 네트워크들 또는 디지털 파이버 통신 네트워크들과 같은 전화통신/전화기 네트워크들을 통해, 파이버 채널 SAN들과 같은 저장 영역 네트워크를 통해, 또는 임의의 다른 적합한 유형의 네트워크 및/또는 프로토콜을 통해 통신을 지원할 수 있다. 다양한 실시예들에서, 컴퓨터 시스템(1000)은 도 10에 예시된 것들보다 많은, 적은, 또는 상이한 구성요소들(예를 들어, 디스플레이들, 비디오, 카드들, 오디오 카드들, 주변 디바이스들, ATM 인터페이스, 이더넷 인터페이스, 프레임 릴레이 인터페이스(Frame Relay interface) 등과 같은 다른 네트워크 인터페이스들)을 포함할 수 있다.

본 출원에 설명된 분산 시스템 실시예들 중 임의의 실시예, 또는 그것들의 구성요소들 중 임의의 구성요소는 하나 이상의 웹 서비스로서 구현될 수 있다는 것이 주의된다. 예를 들어, 데이터베이스 시스템의 데이터베이스 티어 내 데이터베이스 엔진 헤드 노드는 데이터베이스 서비스들 및/또는 웹 서비스들로서 클라이언트들을 위해 본 출원에 설명된 분산 저장 시스템을 채용하는 다른 유형들의 데이터 저장 서비스들을 제공할 수 있다. 일부 실시예들에서, 웹 서비스는 네트워크를 통해 공동 운전 가능한 기계 대 기계 상호작용을 지원하도록 설게된 소프트웨어 및/또는 하드웨어 시스템에 의해 구현될 수 있다. 웹서비스는 웹 서비스 설명 언어(WSDL)와 같은, 기계 프로세스 가능 포맷으로 설명되는 인터페이스를 가질 수 있다. 다른 시스템들은 웹 서비스의 인터페이스의 설명에 의해 규정된 방식으로 웹 서비스와 상호작용할 수 있다. 예를 들어, 웹 서비스는 다른 시스템들이 적용할 수 있는 다양한 동작들을 정의할 수 있고, 다양한 동작들을 요구할 때 다른 시스템들이 따르도록 기대될 수 있는 특정한 애플리케이션 프로그래밍 인터페이스(API)를 정의할 수 있다.

다양한 실시예들에서, 웹 서비스는 웹 서비스 요청과 연관된 파라미터들 및/또는 데이터를 포함하는 메시지의 사용을 통해 요청 또는 적용될 수 있다. 그러한 메시지는 확장 가능 마크업 언어(XML)와 같은 특정한 마크업 언어에 따라 포맷팅될 수 있고/있거나 단순 객체 액세스 프로토콜(SOAP)과 같은 프로토콜을 사용하여 캡슐화될 수 있다. 웹 서비스 요청을 수행하기 위해, 웹 서비스 클라이언트는 요청을 포함하는 메시지를 어셈블링하고 그 메시지를 하이퍼텍스트 전송 프로토콜(HTTP)과 같은 인터넷 기반 애플리케이션 계층 전송 프로토콜을 사용하여, 웹 서비스에 대응하는 주소 지정 가능한 엔드포인트(예를 들어, 고유한 자원 위치 표시자(URL))에 전달할 수 있다.

일부 실시예들에서, 웹 서비스들은 메시지 기반 기술들이 아닌 "RESTful"(Representational State Transfer) 기술들을 사용하여 구현될 수 있다. 예를 들어, RESTful 기술에 따라 구현된 웹 서비스는 SOAP 메시지 내로 캡슐화되기보다, PUT, GET, 또는 DELETE와 같은 HTTP 방법 내에 포함되는 파라미터들을 통해 적용될 수 있다.

앞서 말한 실시예들은 다음 절들을 고려하여 보다 양호하게 이해될 수 있다:

1. 시스템으로서:

각각이 적어도 하나의 프로세서 및 메모리를 포함하는, 하나 이상의 컴퓨팅 노드로서,

각각이 분산 로그-구조 저장 시스템에 의해 저장된 데이터에 대한 각각의 변경과 연관되고, 각각이 복수의 로그 시퀀스 번호 중 각각의 로그 시퀀스 번호와 연관되는, 복수의 로그 레코드를 수신하고;

스냅샷에 대응하는 상태의 시점에서 데이터를 판독하기 위해 사용 가능한 스냅샷을 생성하도록 구성되는 데이터베이스 서비스의 분산 로그-구조 저장 시스템을 총괄적으로 구현하도록 구성되는, 상기 하나 이상의 컴퓨팅 노드를 포함하고, 스냅샷을 상기 생성하는 것은:

스냅샷 식별자를 가리키고 복수의 로그 레코드 중 특정한 로그 레코드와 연관되는 복수의 로그 시퀀스 번호 중 하나를 또한 가리키는 메타데이터를 생성하는 것을 포함하고;

스냅샷을 상기 생성하는 것은 스냅샷을 상기 생성하는 것의 일부로서 데이터의 페이지를 판독하는 것, 복사하는 것, 또는 기록하는 것 없이 수행되는, 시스템.

2. 절 1에 있어서, 메타데이터는 로그 레코드들 중 하나 이상이 가비지 수집되는 것을 방지하기 위해 사용 가능한, 시스템.

3. 절 1에 있어서, 메타데이터는 복수의 로그 레코드 중 다른 특정한 로그 레코드와 연관되는 복수의 로그 시퀀스 번호 중 다른 하나를 또한 가리키는, 시스템.

4. 절 1에 있어서, 메타데이터는 스냅샷이 연속적인 스냅샷이라는 것을 표시하고, 연속적인 스냅샷은 제1 시점과 제2 시점 사이 복수의 시점에 대한 데이터를 복구하기 위해 사용 가능한, 시스템.

5. 방법에 있어서:

데이터베이스 서비스의 하나 이상의 컴퓨터에 의해:

각각이 데이터베이스 서비스에 의해 저장된 데이터에 대한 각각의 변경과 연관되는, 복수의 로그 레코드를 유지하는 단계; 및

스냅샷에 대응하는 상태의 시점에서 데이터를 판독하기 위해 사용 가능한 스냅샷을 생성하는 단계로서, 로그 레코드들 중 특정한 로그 레코드의 특정한 로그 식별자를 가리키는 메타데이터를 생성하는 단계를 포함하는, 상기 스냅샷을 상기 생성하는 단계를 수행하는 단계를 포함하고;

스냅샷을 상기 생성하는 단계는 스냅샷을 상기 생성하는 것의 일부로서 데이터의 페이지를 판독하는 것, 복사하는 것, 또는 기록하는 것 없이 수행되는, 방법.

6. 절 5에 있어서, 메타데이터는 특정한 로그 레코드를 포함하는 로그 레코드들 중 하나 이상이 삭제되는 것을 방지하기 위해 사용 가능한, 방법.

7. 절 5에 있어서, 메타데이터는 스냅샷의 유형이 연속적인지 또는 개별적인지를 표시하는, 방법.

8. 절 5에 있어서,

스냅샷에 대응하는 상태의 시점에서 데이터를 판독하는 단계로서, 특정한 로그 레코드를 포함하는 로그 레코드들 중 하나 이상을 데이터의 이전 버전의 복사본을 만들지 않고 데이터의 이전 버전에 적용하는 단계를 포함하는, 상기 판독하는 단계를 더 포함하는, 방법.

9. 절 8에 있어서, 상기 적용하는 단계는 데이터베이스 서비스에 대한 백그라운드 프로세스로서 수행되는, 방법.

10. 절 8에 있어서, 상기 적용하는 단계는 데이터베이스 서비스의 다양한 노드들에 걸쳐 동시에 수행되는, 방법.

11. 절 5에 있어서,

적어도 부분적으로, 로그 레코드들 중 하나 이상이 가비지 수집으로부터 보호되는 것을 표시하지 않는 메타데이터에 기초하여 로그 레코드들 중 하나 이상을 삭제하는 단계를 더 포함하는, 방법.

12. 절 5에 있어서,

로그 레코드들 중 하나 이상이 적어도 부분적으로, 스냅샷의 유형에 기초하여 삭제되어야 한다는 것을 결정하는 단계; 및

로그 레코드들 중 상기 하나 이상을 삭제하는 단계를 더 포함하는, 방법.

13. 절 5에 있어서,

데이터를 스냅샷에 대응하는 상태로 복구하는 단계; 및

스냅샷과 연관된 시간 이후의 시간들과 연관된 하나 이상의 로그 레코드가 가비지 수집 가능하다는 것을 표시하는 단계를 더 포함하는, 방법.

14. 절 5에 있어서,

적어도 부분적으로, 스냅샷에 기초하여 복수의 상기 로그 레코드를 병합하는 단계를 더 포함하는, 방법.

15. 프로그램 명령들을 저장하는 비-일시적 컴퓨터-판독 가능 저장 매체로서, 상기 프로그램 명령들은 분산 저장 시스템을 구현하도록 컴퓨터-실행 가능하고, 상기 분산 저장 시스템은:

각각이 데이터 페이지에 대한 각각의 변경과 연관되는, 복수의 로그 레코드를 분산 저장 시스템의 복수의 노드에 저장하고;

스냅샷에 대응하는 상태의 시점에서 데이터 페이지를 판독하기 위해 사용 가능한 스냅샷을 생성하는 것으로서, 스냅샷을 상기 생성하는 것은 복수의 로그 레코드 중 특정한 로그 레코드와 연관된 시간을 가리키는 메타데이터를 생성하는 것을 포함하는, 스냅샷을 생성하도록 구성되고;

스냅샷을 상기 생성하는 것은 스냅샷을 상기 생성하는 것의 일부로서 데이터의 페이지를 판독하는 것, 복사하는 것, 또는 기록하는 것 없이 수행되는, 비-일시적 컴퓨터-판독 가능 저장 매체.

16. 절 15에 있어서, 메타데이터는 로그 레코드들 중 하나 이상이 가비지 수집되는 것을 방지하기 위해 사용 가능한, 비-일시적 컴퓨터-판독 가능 저장 매체.

17. 절 15에 있어서, 분산 저장 시스템은:

각각이 다른 데이터 페이지에 대한 각각의 변경과 연관되는, 다른 복수의 로그 레코드를 분산 저장 시스템의 복수의 노드에 저장하도록 더 구성되고;

스냅샷은 스냅샷에 대응하는 상태의 시점에서 다른 데이터 페이지를 판독하기 위해 또한 사용 가능하고, 메타데이터는 다른 복수의 로그 레코드 중 특정한 로그 레코드를 또한 가리키는, 비-일시적 컴퓨터-판독 가능 저장 매체.

18. 절 15에 있어서, 분산 저장 시스템은:

스냅샷에 대응하는 상태의 시점에서 데이터 페이지를 판독하고;

스냅샷과 연관된 시간 이후의 시간들과 연관된 하나 이상의 로그 레코드가 가비지 수집 가능하다는 것을 표시하도록 더 구성되는, 비-일시적 컴퓨터-판독 가능 저장 매체.

19. 절 15에 있어서, 분산 저장 시스템은:

스냅샷에 대응하는 상태의 시점에서 데이터 페이지를 판독하는 것으로서, 상기 판독하는 것은 특정한 로그 레코드를 포함하는 로그 레코드들 중 하나 이상을 데이터 페이지의 이전 버전의 복사본을 만들지 않고 데이터 페이지의 이전 버전에 적용하는 것을 포함하는, 상기 판독하도록 더 구성되는, 비-일시적 컴퓨터-판독 가능 저장 매체.

20. 절 19에 있어서, 상기 적용하는 것은 분산 저장 시스템의 복수의 노드에 걸쳐 분산되는, 비-일시적 컴퓨터-판독 가능 저장 매체.

도면들에서 예시되고 본 출원에서 설명된 바와 같은 다양한 방법들은 방법들의 예시적인 실시예들을 나타낸다. 방법들은 소프트웨어에서, 하드웨어에서, 또는 이들의 조합에서 수동으로 구현될 수 있다. 임의의 방법의 순서는 변경될 수 있고, 다양한 요소들이 추가, 재순서화, 결합, 생략, 수정 등이 될 수 있다.

상기에서 실시예들이 상당히 상세하게 설명되었지만, 많은 변경 및 변형이 상기 개시내용이 완전히 이해되면 당해 기술분야의 통상의 기술자들에게 명백해질 바와 같이 이루어질 수 있다. 이하의 청구항들이 모든 그러한 변형 및 변경을 포함하고, 그에 따라, 상기 설명이 제한적인 의미가 아닌 예시적으로 간주되도록 해석된다는 것이 의도된다.

Claims (15)

1. 시스템으로서,
   하나 이상의 컴퓨팅 노드를 포함하고,
   상기 하나 이상의 컴퓨팅 노드의 각각은 적어도 하나의 프로세서 및 메모리를 포함하고,
   상기 하나 이상의 컴퓨팅 노드는,
   각각이 분산 로그-구조 저장 시스템에 의해 저장된 데이터에 대한 각각의 변경을 명시하고, 각각이 복수의 로그 시퀀스 번호 중 각각의 로그 시퀀스 번호와 연관되는, 복수의 로그 레코드를 수신하고;
   프로그램 인터페이스를 통해, 스냅샷과 연관된 시간에 대응하는 상태의 시점에서 데이터를 판독하기 위해 사용 가능한 상기 스냅샷을 생성하기 위한 요청을 수신하고;
   상기 요청의 수신에 응답하여, 상기 스냅샷을 생성하도록 구성되는, 데이터베이스 서비스의 상기 분산 로그-구조 저장 시스템을 총괄적으로 구현하도록 구성되고,
   상기 스냅샷을 생성하는 것은, 상기 요청된 스냅샷과 연관된 상기 시간까지 이루어진 상기 데이터에 대한 각각의 변경을 명시하는 상기 복수의 로그 레코드 중 하나 이상이 가비지 수집되는 것을 방지하기 위해 메타데이터를 생성하는 것을 포함하는, 시스템.
2. 제1항에 있어서,
   상기 메타데이터는 스냅샷 식별자를 가리키고 상기 복수의 로그 레코드 중 특정한 로그 레코드와 연관되는 상기 복수의 로그 시퀀스 번호 중 하나를 또한 가리키는, 시스템.
3. 제1항에 있어서,
   상기 메타데이터는 상기 복수의 로그 레코드 중 다른 특정한 로그 레코드와 연관되는 상기 복수의 로그 시퀀스 번호 중 다른 하나를 또한 가리키는, 시스템.
4. 제1항에 있어서,
   상기 메타데이터는 상기 스냅샷이 연속적인 스냅샷이라는 것을 표시하고, 상기 연속적인 스냅샷은 제1 시점과 제2 시점 사이 복수의 시점으로 상기 데이터를 복구하기 위해 사용 가능한, 시스템.
5. 데이터베이스 서비스의 하나 이상의 컴퓨터에 의해:
   각각이 상기 데이터베이스 서비스에 의해 저장된 데이터에 대한 각각의 변경을 명시하는, 복수의 로그 레코드를 유지하는 단계;
   프로그램 인터페이스를 통해, 스냅샷과 연관된 시간에 대응하는 상태의 시점에서 데이터를 판독하기 위해 사용 가능한 상기 스냅샷을 생성하기 위한 요청을 수신하는 단계; 및
   상기 요청의 수신에 응답하여 상기 스냅샷을 생성하는 단계를 수행하는 단계를 포함하고,
   상기 스냅샷을 생성하는 단계는, 상기 요청된 스냅샷과 연관된 상기 시간까지 이루어진 상기 데이터에 대한 각각의 변경을 명시하는 상기 로그 레코드들 중 하나 이상이 가비지 수집되는 것을 방지하기 위해 메타데이터를 생성하는 단계를 포함하는, 방법.
6. 제5항에 있어서,
   상기 메타데이터는 상기 하나 이상의 로그 레코드들의 특정한 로그 식별자를 가리키는, 방법.
7. 제5항에 있어서, 상기 메타데이터는 상기 스냅샷의 유형이 연속적인지 또는 개별적인지를 표시하는, 방법.
8. 제5항에 있어서,
   상기 스냅샷에 대응하는 상기 상태의 시점에서 상기 데이터를 판독하는 단계를 더 포함하고, 상기 판독하는 단계는 상기 로그 레코드들 중 상기 하나 이상을 상기 데이터의 이전 버전의 복사본을 만들지 않고 상기 데이터의 상기 이전 버전에 적용하는 단계를 포함하는, 방법.
9. 제8항에 있어서,
   상기 적용하는 단계는 상기 데이터베이스 서비스에 대한 백그라운드 프로세스로서 수행되는, 방법.
10. 제8항에 있어서,
    상기 적용하는 단계는 상기 데이터베이스 서비스의 다양한 노드들에 걸쳐 동시에 수행되는, 방법.
11. 제5항에 있어서,
    적어도 부분적으로, 상기 로그 레코드들 중 특정한 하나 이상이 가비지 수집으로부터 보호된다는 것을 표시하지 않는 상기 메타데이터에 기초하여 상기 로그 레코드들 중 상기 특정한 하나 이상을 삭제하는 단계를 더 포함하는, 방법.
12. 제5항에 있어서,
    상기 로그 레코드들 중 특정한 하나 이상이 적어도 부분적으로, 상기 스냅샷의 유형에 기초하여 삭제되어야 한다는 것을 결정하는 단계; 및
    상기 로그 레코드들 중 상기 특정한 하나 이상을 삭제하는 단계를 더 포함하는, 방법.
13. 제5항에 있어서,
    상기 데이터를 상기 스냅샷에 대응하는 상기 상태로 복구하는 단계; 및
    상기 스냅샷과 연관된 시간 이후의 시간들과 연관된 상기 로그 레코드들 중 특정한 하나 이상이 가비지 수집 가능하다는 것을 표시하는 단계를 더 포함하는, 방법.
14. 제5항에 있어서,
    적어도 부분적으로, 상기 스냅샷에 기초하여 상기 로그 레코드들 중 둘 이상을 병합하는 단계를 더 포함하는, 방법.
15. 하나 이상의 프로세서; 및
    하나 이상의 메모리로서, 상기 메모리들은 프로그램 명령들을 저장하고, 상기 프로그램 명령들이 상기 하나 이상의 프로세서 상에서 실행될 때:
    각각이 데이터 페이지에 대한 각각의 변경을 명시하는, 복수의 로그 레코드를 분산 저장 시스템의 복수의 노드에 저장하고;
    프로그램 인터페이스를 통해, 스냅샷과 연관된 시간에 대응하는 상태의 시점에서 상기 데이터 페이지를 판독하기 위해 사용 가능한 상기 스냅샷을 생성하기 위한 요청을 수신하고;
    상기 요청의 수신에 응답하여 상기 스냅샷을 생성하도록 구성되는 상기 분산 저장 시스템을 구현하는, 상기 하나 이상의 메모리를 포함하고;
    상기 스냅샷을 생성하는 것은, 상기 요청된 스냅샷과 연관된 상기 시간까지 이루어진 상기 데이터 페이지에 대한 각각의 변경을 명시하는 상기 복수의 로그 레코드 중 하나 이상이 가비지 수집되는 것을 방지하기 위한 메타데이터를 생성하는 것을 포함하는, 시스템.

Images