Btrieve의 건축물

Architecture of Btrieve

Btrieve퍼베이시브 소프트웨어가 개발한 데이터베이스다.Btrieve의 아키텍처는 기록 관리를 염두에 두고 설계되었다.이는 Btrieve가 기초적인 레코드 생성, 데이터 검색, 레코드 업데이트 및 데이터 삭제 원시 요소만을 다룬다는 것을 의미한다.마이크로커널 데이터베이스 엔진과 함께 ISAM, 인덱싱된 순차 액세스 방법을 기본 스토리지 메커니즘으로 사용한다.

Btrieve는 본질적으로 데이터를 조직하기 위해 키와 인덱스를 사용하는 데이터베이스다.그러나 파일 구조 자체는 Btrieve에서 "페이지"라고 불리는 작은 데이터 단위를 중심으로 크게 구축된다.Btrieve의 다양한 버전에 걸쳐 구조가 바뀌었지만, 파일 구조는 여전히 페이지의 구성을 정의하는 FCR(File Control Record)과 데이터가 포함된 Btrieve 파일의 페이지를 중심으로 회전한다.역사적으로 Btrieve는 "물리적 페이지" 즉 파일의 고정 위치에 있는 페이지를 사용했다.버전 6.0에서 시작하여 페이지 할당 테이블(PAT)에 매핑된 "논리적 페이지"가 사용되기 시작했으며, 이를 통해 Btrieve는 나중에 "사전 이미지 페이징"으로 알려진 레코드 업데이트 기법을 "섀도 페이징"이라는 기법으로 변경할 수 있었다.

Btrieve는 버전 6.15까지 Btrieve의 버전이 표준 파일 형식을 사용하고 Btrieve 6.0이 출시될 때까지 완전히 역호환되기 때문에 이전 버전과의 호환성에 전념하고 있다.Btrieve 6.0은 새로운 기능을 도입했고 더 고급화된 기능을 구현하기 위해 이전 버전의 소프트웨어와의 호환성을 깨야 했다.API도 마찬가지로 한 가지 기능(별도의 미디어에 분할 파일)만 삭제되는 등 역호환성을 유지했다.한때 Btrive의 전 CEO Ron Harris는 "버전 1.0 API는 버전 6.15에서 여전히 지원되고 있으며, 우리는 그것을 영원히 유지할 것이다!"(Kyle, 페이지 11)라고 말했다.

데이터베이스 용어

퍼베이티브는 처음에 Btrieve를 묘사하기 위해 "navigational database"라는 용어를 사용했지만, 나중에 이것을 "transactional database"로 바꾸었다.항법 데이터베이스는 데이터 레코드 사이를 탐색하기 위해 "점자"와 "경로"를 사용하며, 이러한 포인터는 레코드 자체에 포함되어 있기 때문에 항법 데이터베이스라는 용어의 사용은 이례적이었다. Btrieve의 기본 구조인 ISAM은 이러한 포인터를 저장하기 위해 보조 인덱스 테이블을 사용하여 검색 시간을 줄인다.따라서, 두 가지 유형의 데이터베이스는 서로 다르며, Pervivis가 그들의 데이터베이스를 분류하기 위해 다른 용어를 사용하기 시작한 이유를 설명할 수도 있고 그렇지 않을 수도 있다.(참고: 이것은 엄밀히 말하면 옳지 않다. 항법 데이터베이스는 애플리케이션 레벨 인터페이스 또는 API를 통해 데이터베이스에 있는 데이터에 대한 논리적 액세스가 이루어지는 데이터베이스로, 논리적 관계가 애플리케이션 코드에 의해 "내비게팅"되어 데이터베이스를 통과하는 방식으로 통과된다는 점에서 항법적이다. 이를 달성하기 위해 어떤 물리적 기법을 사용하는가, 즉 ISAM, 임베디드 포인터 등은 논의와는 거의 무관하다. 대조적으로, 관계형 데이터베이스는 논리적인 데이터베이스 구조를 통해 "탐색"할 수 있는 방법을 애플리케이션 계층에 제공하지 않고 대신 데이터의 선택, 집계 및 결합을 위한 설정 수준 인터페이스를 제공한다. 관계형 데이터베이스는 또한 위에서 언급한 것과 같은 데이터에 접근하기 위해 다양한 물리적 기법을 사용할 수 있지만, "관계형"의 중요한 측면은 데이터에 관계형 접근, 즉 항법 모델보다는 설정된 질의 모델을 사용하는 것이다.)

마이크로커널 데이터베이스 엔진

MKDE 모델은 다른 데이터베이스 백엔드를 퍼베이시브 소프트웨어 제품에 연결할 수 있도록 한다.

6.15 버전부터 퍼베이시브에서는 개발자들이 사용하던 인터페이스에서 데이터베이스 백엔드를 분리하는 새로운 모듈식 방법을 사용하기 시작했다.이들은 Btrieve 및 확장 가능한 SQL 모듈에서 핵심 데이터베이스 작업(예: 업데이트, 쓰기 및 삭제)을 분리했다.마이크로-커널 데이터베이스 엔진(MKDE)을 다른 기능에서 분리함으로써 프로그래머가 데이터베이스에 동시에 액세스하는 여러 가지 방법을 사용할 수 있도록 했다.예를 들어 Btrieve API를 사용하여 애플리케이션을 생성할 수 있으며 동일한 데이터에 액세스해야 하는 다른 애플리케이션은 확장 가능한 SQL을 사용하는 것과 같이 완전히 다른 방법을 사용할 수 있다.기록 원형은 이러한 방법에서 분리되었기 때문에, 두 애플리케이션 모두 MKDE를 사용하여 동일한 데이터 파일에 액세스할 수 있다.

마이크로커널 데이터베이스 엔진은 마이크로커널 운영 체제 커널과 관련이 없다.

페이징

Btrieve 파일 형식은 전적으로 페이지로 구성되는데, 이는 엔진이 I/O 작업을 수행할 때 메모리와 저장 매체 사이를 이동하는 데이터다.6.0 이전 버전은 데이터 페이지, 인덱스 페이지 및 파일 제어 레코드(FCR)만 사용했다.그 파일에는 실제 페이지와 연결된 검색 색인이 있었다.버전 6.0 논리 페이지는 PATs(페이지 할당 테이블) 세트 사용을 통해 디스크의 물리적 페이지(파일 내 고정된 위치에 있는 페이지)에 매핑되는 페이지인 버전 6.0 논리 페이지가 사용되기 시작했다.

파일 제어 기록

파일 제어 기록(FCR)은 Btrieve 데이터베이스 파일에 대한 중요한 정보를 포함하고 있다.페이지 크기, 현재 사용 중인 페이지 수, 파일을 인덱싱할 수 있는 키 수, 파일의 레코드 수 및 기타 세부 정보를 보관한다.6.0 버전 이후 중복성을 위해 FCR 2개가 사용되었다.각 FCR에 존재하는 32비트 사용량 카운트 필드를 사용하여 어떤 FCR을 사용할 수 있는지 결정한다.파일 작업이 완료될 때마다 필드는 증분된다.사용 횟수가 가장 많은 FCR은 유효한 FCR이 된다.FCR은 짐 카일의 샘플 출처에 잘 설명되어 있다.MKDE 버전 8의 도입으로 FCR 페이지의 구조가 변경된다.페이지 크기는 이제 FCR 내에서 이동되며 일반 32비트 필드가 아니다.버전 8부터는 오프셋 0x2A에서 32비트 필드를 취하여 페이지 크기를 계산하고 256으로 곱해야 한다.

페이지 할당 테이블

페이지 할당 테이블(PAT)은 논리 페이지를 실제 페이지에 매핑한다.각 PAT는 잘 정의된 위치에 위치한 실제 페이지일 뿐이다.FCR과 마찬가지로 PAT는 항상 쌍으로 발생하며, 현재 유효한 복사본은 더 많은 사용 횟수를 가지고 있다.첫 번째 쌍의 PAT는 처음 두 개의 FCR을 즉시 따르고 물리적인 페이지 2와 3을 차지한다.다른 페이지들의 가변적인 수가 뒤따르고, 새로운 PAT 쌍이 차례로 이것을 따른다.각 PAT에는 논리 페이지에 대한 포인터가 고정되어 있으며, 비어 있는 각 항목은 값이 0이다.

PAT에 저장할 수 있는 논리 레코드의 양은 페이지 크기에 따라 결정된다.MKDE 버전 6.x와 7.x의 각 페이지 포인터는 4바이트의 공간을 차지하며, PAT 헤더는 8바이트를 차지하므로 PAT의 논리 페이지 양은 다음과 같이 된다.

논리 페이지 수 = (페이지 크기 ÷ 4) - 8

MKDE 버전 8의 도입으로 페이지 헤더의 크기가 변경되어 이 공식이 더 이상 적용되지 않고 원칙은 그대로 유지되었다.

사전 이미지 페이징 vs 섀도 페이징

버전 6.0까지는 레코드에 대한 업데이트를 수행할 때 사전 이미지 페이징을 사용했다.그것은 변경되기 전에 새로운 "사전 이미지 파일"을 만드는 것을 포함했고, 그리고 나서 원본 데이터 파일의 페이지들이 일시적으로 이 새로운 사전 이미지 파일에 복사되었다.그러면 시스템이 원본 파일을 변경하게 된다.만약 업데이트가 중단되고 페이지에 쓰여진 데이터의 절반만 있다면, 페이지는 단지 이전 이미지 파일의 페이지를 원래의 데이터베이스 파일의 손상된 페이지로 다시 복사함으로써 엔진에 의해 롤백될 것이다. 그러면 임시 사전 이미지 파일은 삭제될 것이다.프리이미지 파일에는 확장자가 주어졌다.PRE. 따라서 일반적으로 시스템에서 이러한 파일을 찾으면 트랜잭션이 올바르게 수행되지 않았고 복구가 성공하지 못했다는 것을 알 수 있다.

6.0 버전부터는 사전 이미징 대신 섀도 페이징을 사용했으며, 현재까지도 사용되고 있다.페이지를 임시 파일로 복사하는 대신, 데이터베이스 파일의 다음 여유 물리적 위치가 발견되어 이 위치에 페이지가 기록되었다.이 페이지는 여전히 파일의 PAT에 그 위치를 기록하지 않았기 때문에 그림자 페이지라고 불린다.섀도 페이지에 대한 업데이트가 완료되면 PAT가 업데이트되고 파일에 있는 다음 사용 가능한 현재 실제 페이지의 PAT에 항목이 기록된다.그러나 섀도 페이지를 업데이트하는 동안 시스템 오류가 발생하면 PAT가 업데이트되지 않으므로 PAT에서 현재 및 다음 항목이 업데이트되지 않았기 때문에 변경 사항이 삭제된다.

사전 이미지 페이징에서 섀도 페이징으로의 전환은 이전 버전의 Btrieve와 버전 6.x 간의 호환성을 깨는 급진적인 파일 포맷 변경을 야기했다.

대체 정렬 시퀀스 페이지

ACS(Aternate Collating Sequence) 페이지는 레코드를 다른 순서로 정렬할 수 있는 페이지다.데이터 정렬은 서면 정보를 표준 순서로 조합하는 것이다.일반적인 용어로, 비록 정렬이 알파벳의 문자를 주문하는 것에 국한되지는 않지만, 이것을 알파벳화라고 부른다.예를 들어 ACS는 대/소문자를 구분하는 정렬 순서 및 대/소문자를 구분하지 않는 순서 모두를 정렬할 수 있다.6.0 이전 버전에서는 한 개의 ACS만 파일에 저장할 수 있었지만, 6.0이 출시된 후에는 한 번에 두 개 이상의 ACS 페이지를 파일과 연결할 수 있었다.

여분의 페이지

버전 6.0 이상 파일에서는 실제 사용되는 것보다 더 많은 물리적 페이지가 존재할 수 있다.이는 섀도우 페이징으로 시스템의 일부 페이지에 PAT 항목이 없을 수 있기 때문이다.이 페이지는 "추가" 페이지로 표시되며, 새 페이지의 공간이 할당되기 전에 모두 사용된다.

가변테일 할당 테이블

Btrieve에서 각 페이지는 고정되어 있지만 레코드는 페이지 크기보다 클 수 있다.이것은 기록들이 종종 여러 다른 페이지들에 분산되고 퍼질 필요가 있다는 것을 의미한다.매우 큰 레코드를 사용하는 경우, 이것은 레코드를 저장하기 위해 수백 페이지를 사용해야 할 수 있다는 것을 의미한다.링크된 목록 접근방식은 이러한 단편화를 허용할 수 있지만 Btrieve 엔진은 순차적 기록을 읽는데 어려움을 겪을 것이다.따라서 버전 6.1부터 데이터 레코드를 구성하는 각 페이지의 포인터를 저장하는 파일에 테이블을 사용한다.이 표를 VAT(Variable-tail Assignment Table)라고 한다.

인덱싱

Btrieve는 데이터를 빠른 속도로 검색하기 위해 특정 열의 인덱스를 사용한다.상단의 구조는 b-트리 데이터 구조로 데이터베이스 테이블의 사원 ID 을 색인한다.화살표는 색인 값에서 "직원 ID" 열의 값을 포함하는 행을 가리킨다.

Btrieve는 b-tree 형식을 사용하여 특정 테이블 에 레코드 인덱스를 저장한다.인덱스는 각 인덱스 열 값 집합을 해당 열 값이 있는 에 대한 고유 식별자 집합에 매핑하므로 인덱싱된 열을 사용하여 테이블 내에서 행을 빠르게 찾을 수 있다.B-tree는 트리 데이터 구조로 빠른 데이터 검색을 위한 메커니즘으로서 매우 효율적이다.btree의 단점은 데이터가 트리에 삽입될 때 지속적으로 균형을 유지해야 한다는 것이다. 따라서 Btrieve는 레코드 인덱스를 btree로 저장하여 레코드를 삽입하고 업데이트하는 데 걸리는 시간을 줄인다.시스템의 각 지수에 대해 별도의 b-트리가 유지되며, 루트 노드 정보는 FCR에 보관된다.Btrieve 6.x에서는 파일 생성 시 새로운 인덱스를 생성하거나 파일이 생성된 후 추가 및 삭제될 수 있다.인덱스 페이지도 필요에 따라 만들어진다.Btrieve 6.0 기존 키 인덱스를 제거할 수 없었지만, 보조 인덱스는 필요에 따라 생성 및 삭제될 수 있었다.

Btrieve는 인덱스에서 중복된 키 값을 허용한다.Btrieve는 연결된 중복 방법을 사용하거나 반복 복제 방법을 사용하여 중복 키를 처리한다(이 용어는 버전 6.0이 출시되었을 때 사용되기 시작했다).링크드 복제 방법은 인덱스 페이지 자체의 레코드 포인터를 사용하여 이중으로 연결된 중복목록의 머리와 꼬리를 가리켰다.이것은 리스트에 있는 중복 키의 순서가 입력된 순서대로 되어 있다는 것을 의미했다.중복된 키 방법은 링크된 목록을 사용하지 않고, 오히려 새로운 인덱스 키를 만들고 레코드 포인터 주소를 키 끝에 추가하여 모든 키를 고유하게 만들었다.이는 키가 위치 순서를 통해 검색된다는 것을 의미한다.

파일 공유

Btrieve가 레코드에 액세스하기 위해 파일 공유를 해야 할 때, 두 가지 다른 유형의 파일 공유 모드를 사용할 수 있다.단일 엔진 파일 공유(SEFS) 모드 및 다중 엔진 파일 공유(MEFS) 모드.SEFS는 해당 엔진에 액세스한 클라이언트만 데이터베이스를 변경할 수 있도록 허용했으며, 다른 엔진에 액세스한 다른 클라이언트는 데이터베이스에 액세스할 수 없었다.MEFS는 다른 엔진에서 실행되는 다른 클라이언트가 데이터베이스에 액세스할 수 있도록 허용한다.

동시성

Btrieve는 6.x 시리즈의 동시 트랜잭션을 처리할 수 있었다.Btrieve 6.0 이전에는 엔진은 파일 레벨 잠금 또는 독점 잠금만 할 수 있었다. 6.0부터는 레코드를 개별적으로 잠글 수 있었다.레코드(또는 페이지) 수준의 잠금은 동시 잠금으로 알려져 있었다.둘 이상의 클라이언트가 동일한 레코드에 액세스하지 않는 한 동시에 파일에 액세스할 수 있다는 장점이 분명하여 성능 향상으로 이어졌다.또한 다른 클라이언트는 잠긴 페이지를 읽을 수 있었고, 레코드를 잠근 다른 프로세스에 의해 쓰기 트랜잭션과 관련된 파일의 변경사항을 볼 수 없었다.

MEFS 모드는 동시 잠금을 완전히 지원하지 않았다.클라이언트가 동시 트랜잭션을 시작한 다음 기록으로 쓰기 작업을 수행하려고 하면 Btrieve 엔진은 동시 잠금이 사용 중임에도 불구하고 파일이 잠겨 있음을 나타내는 상태 코드 85를 반환할 것이다.

시스템 및 사용자 트랜잭션

Btrieve 버전 6.15를 시작으로, 시스템 거래라고 하는 새로운 형태의 데이터베이스 거래가 도입되었는데, 이는 사용자 거래와 분리되었다.사용자 트랜잭션은 독점적이고 동시적인 트랜잭션인 반면 시스템 트랜잭션은 비거래 작업 및/또는 사용자 트랜잭션의 묶음이다.시스템 트랜잭션은 MKDE가 데이터 복구를 위해 독점적으로 사용하였으며, 시스템 장애로 인해 데이터 손상이 발생할 경우 MKDE가 재시작되면 시스템 트랜잭션에 오류가 발생한 모든 파일을 감지하여 복구하려고 시도하였다.그러나 마지막 시스템 트랜잭션을 롤백할 때 사용자 트랜잭션이 손실되었을 수 있으므로, MKDE가 엔진이 "End Operation" 요청을 받았을 때 사용자 트랜잭션을 완료하도록 강제하는 옵션이 설정될 수 있다.

참조

  • 다은시, 아요들레 (1998년 1월 1일)BtrieveScaleable SQL4 이해.클라리온 매거진.
  • 카일, 짐(1995)Btrieve complete: 개발자시스템 관리자를 위한 가이드.매사추세츠 주의 레딩:애디슨-웨슬리 출판사. ISBN0-201-48326-2.
  • Novell(날짜 없음)NetWare Btrieve구성 요소.2004년 12월 12일 회수.
  • 퍼베이시브(1997) DOS용 Btrieve 설치작동 설명서.제품 설명서.
  • 퍼베이시브(1998)NetWare NLM 응용 프로그램의 상태 96.퍼베이시브 기술 자료 문서(문서 ID: BTRTT-970801)2004년 12월 12일 회수.
  • 퍼베이시브 (1996년 11월)Btrieve for Windows NT/Windows 95 설치작동.제품 설명서.
  • C 피들러(2010년 7월)btrieve 데이터베이스 파일 액세스(PageSize 탐지).
  • dbcoretech(2010년 7월).btrieve 복구 유틸리티(오픈 소스).