확장 가능한 스토리지 엔진

이 글은 일반적인 참고문헌 목록을 포함하고 있지만, 그에 상응하는 인라인 인용구가 충분하지 않다. 보다 정밀한 인용구를 도입하여 이 기사를 개선할 수 있도록 도와달라.(2021년 2월) (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기)

확장 가능한 스토리지 엔진

기타 이름	JET 블루
개발자	마이크로소프트
초기 릴리즈	1994; 28년 전 (1998년)
리포지토리	github.com/microsoft/Extensible-Storage-Engine
기록 위치	C++
운영 체제	마이크로소프트 윈도
플랫폼	IA-32, x86-64, ARM 및 Itanium(그리고 역사적으로 DEC Alpha, MIPS 및 전력)PC)
유형	데이터베이스 엔진
면허증	MIT 라이선스
웹사이트	docs.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine

JET Blue라고도 알려진 ISE(Extensible Storage Engine)는 마이크로소프트의 ISAM(Indexed Sequential Access method) 데이터 스토리지 기술이다.ESE는 마이크로소프트 Exchange 서버, Active Directory 및 윈도우즈 검색의 핵심이다.또한 Windows Update 클라이언트, 도움말 및 지원 센터를 비롯한 여러 Windows 구성 요소에서 사용되며,그 목적은 애플리케이션이 인덱스된 순차적 액세스를 통해 데이터를 저장하고 검색할 수 있도록 하는 것이다.

EESE는 거래된 데이터 업데이트 및 검색을 제공한다.시스템 충돌 시에도 데이터 일관성이 유지되도록 충돌 복구 메커니즘이 제공된다.EESE에서의 거래는 서버 애플리케이션에 적합한 EESE를 만들기 위해 매우 동시적이다.ESE는 데이터에 대한 고성능 액세스를 보장하기 위해 데이터를 지능적으로 캐슁한다.또한 EESE는 경량화 되어 있어 보조적 용도에 적합하다.

ESENT(ESE Runtime)DLL)은 Windows 2000 이후 모든 Windows 릴리스에 기본 x64 버전의 Windows XP 및 Windows Server 2003이 포함된 EESE 런타임 배송과 함께 출고되었다.마이크로소프트 Exchange 2003까지 지원되는 유일한 플랫폼인 32비트 버전만 탑재된 마이크로소프트 Exchange.Exchange 2007과 함께 64비트 버전과 함께 배송된다.

데이터베이스

데이터베이스는 데이터의 물리적 및 논리적 그룹이다.ESE 데이터베이스는 Windows에 단일 파일처럼 보인다.내부적으로 데이터베이스는 2, 4, 8, 16 또는 32KB 페이지 모음입니다(16 및 32KB 페이지 옵션은 윈도우즈 7과 Exchange 2010에서만 사용 가능).^[1] 균형 잡힌 B 트리 구조로 배열되어 있다.^[2]이 페이지에는 데이터베이스 내에 포함된 데이터, 데이터 그 자체, 데이터의 흥미로운 순서를 유지하기 위한 인덱스, 그리고 기타 정보를 기술하는 메타 데이터가 포함되어 있다.이 정보는 데이터베이스 파일 내에 혼합되어 있지만, 함께 사용되는 데이터를 데이터베이스 내에서 함께 클러스터링하기 위해 노력한다.EESE 데이터베이스는 8킬로바이트 크기의 페이지에 대해 최대 2페이지³² 또는 16테라바이트의 데이터를 포함할 수 있다.^[3]

EESE 데이터베이스는 인스턴스라는 그룹으로 구성된다.대부분의 애플리케이션은 단일 인스턴스를 사용하지만, 모든 애플리케이션도 여러 인스턴스를 사용할 수 있다.인스턴스의 중요성은 단일 복구 로그 시리즈를 하나 이상의 데이터베이스와 연결한다는 것이다.현재 EESE 인스턴스에 언제든지 최대 6개의 사용자 데이터베이스를 연결할 수 있다.ESE를 사용하는 각 개별 프로세스에는 최대 1024개의 EESE 인스턴스가 있을 수 있다.

데이터베이스는 실행 중인 하나의 EESE 인스턴스에서 분리되고 나중에 동일한 실행 인스턴스 또는 다른 실행 인스턴스에 연결될 수 있다는 점에서 이동성이 있다.분리되는 동안 데이터베이스는 표준 Windows 유틸리티를 사용하여 복사할 수 있다.EESE는 데이터베이스 파일을 독점적으로 열기 때문에 데이터베이스를 사용 중인 동안에는 복사할 수 없다.데이터베이스는 Windows에서 직접 주소 지정 가능한 I/O 작업을 지원하는 장치에 물리적으로 상주할 수 있다.

테이블

테이블은 레코드의 동질적인 모음이며, 각 레코드에는 동일한 열 집합이 있다.각 테이블은 테이블 이름으로 식별되며, 테이블의 범위는 테이블이 포함된 데이터베이스의 로컬이다.데이터베이스 내의 테이블에 할당된 디스크 공간의 양은 테이블이 CreateTable 작업으로 생성될 때 주어진 매개변수에 의해 결정된다.데이터 생성에 따라 테이블이 자동으로 증가함

테이블에는 하나 이상의 인덱스가 있다.기록 데이터를 위해 적어도 하나의 클러스터링된 인덱스가 있어야 한다.응용 프로그램에 의해 군집화된 인덱스가 정의되지 않을 경우, 기록 삽입의 연대순에 따라 기록을 정렬하고 군집화하는 인위적인 인덱스를 사용한다.인덱스는 흥미로운 데이터 순서를 유지하고, 인덱스 순서에 따라 레코드에 순차적으로 액세스하며, 인덱스 열 값에 따라 레코드에 직접 액세스할 수 있도록 정의된다.EESE의 클러스터링된 인덱스도 기본 인덱스여야 하며 이는 인덱스 키가 고유해야 함을 의미한다.

클러스터링된 인덱스와 비클러스터된 인덱스는 B+ 트리를 사용하여 표현된다.삽입 또는 업데이트 작업으로 페이지가 오버플로되면 페이지는 분할된다. 새 페이지는 할당되고 이전에 인접한 두 페이지 사이에 논리적으로 체인으로 연결된다.이 새로운 페이지는 물리적으로 논리적인 이웃과 인접하지 않기 때문에, 접속이 그만큼 효율적이지 않다.ESSE는 데이터를 다시 압축하는 온라인 압축 기능을 가지고 있다.테이블이 자주 업데이트될 것으로 예상되는 경우, 테이블 또는 색인을 작성할 때 적절한 페이지 밀도를 지정하여 향후 삽입을 위해 공간을 예약할 수 있다.이를 통해 분할 작업을 피하거나 연기할 수 있다.

레코드 및 열

레코드는 관련 열 값 집합이다.레코드는 업데이트 작업을 통해 삽입 및 업데이트되며 삭제 작업을 통해 삭제할 수 있다.열은 각각 SetColumns 및 RetrieveColumns 작업을 통해 설정 및 검색된다.레코드의 최대 크기는 8킬로바이트 페이지에 대해 8110바이트로, 긴 값 열을 예외로 한다.LongText와 LongBinary의 열 유형은 이러한 크기 제한에 크게 기여하지 않으며, 데이터를 긴 값 열에 저장할 때 레코드는 데이터베이스 페이지 크기보다 훨씬 큰 데이터를 저장할 수 있다.긴 값 참조를 레코드에 저장하면 기록 내 데이터 9바이트만 있으면 된다.이러한 긴 값 자체는 최대 2기가바이트(GB)까지 될 수 있다.

레코드는 일반적으로 각 레코드에 동일한 열 집합에 대한 값 집합이 있다는 점에서 균일하다.EESE에서는 또한 테이블에 대해 많은 열을 정의할 수 있지만, 주어진 레코드에 적은 수의 NULL이 아닌 열 값만 포함되도록 할 수 있다.이런 의미에서 표는 이질적인 기록의 집합이 될 수도 있다.

EESE는 1비트부터 2GB까지의 다양한 열 값을 지원한다.열의 유형이 인덱스에 대한 순서를 포함하여 많은 속성을 결정하기 때문에 올바른 열 유형을 선택하는 것이 중요하다.ESE에서 지원하는 데이터 유형은 다음과 같다.

열 유형

이름	설명
비트	3차 값(NULL, 0 또는 1)
서명되지 않은 바이트	1바이트 부호 없는 정수
짧다	2바이트 부호 정수
서명되지 않은 쇼트	2바이트 부호 없는 정수
긴	4바이트 부호 정수
서명되지 않은 긴 길이	4바이트 무부호 정수
롱롱	8바이트 부호 정수
서명되지 않은 LongLong	8바이트 무부호 정수
통화	8바이트 부호 정수
IEEE 싱글	4바이트 부동 소수점 번호
IEEE 더블	8바이트 부동 소수점 번호
날짜 시간	8바이트 날짜-시간(초기 날짜, 부분 시간)
GUID	16바이트 고유 식별자
이진수	이진 문자열, 길이 <= 255바이트
텍스트	ANSI 또는 유니코드 문자열, 길이 <= 255바이트
긴 이진수	큰 이진 문자열, 길이 < 2GB
긴 텍스트	큰 ANSI 또는 유니코드 문자열, 길이 < 2GB

고정, 변수 및 태그가 지정된 열

각 EESE 표는 최대 127개의 고정 길이 열, 128개의 가변 길이 열 및 64,993개의 태그된 열을 정의할 수 있다.

• 고정 열은 본질적으로 각 기록에서 그 값에 관계없이 동일한 공간을 차지하는 열이다.고정 열은 열 값의 NULLity를 나타내기 위해 1비트를 차지하며, 해당 열 또는 나중에 정의된 고정 열이 설정된 각 기록에서 고정 공간의 양을 나타낸다.
• 변수 열은 기본적으로 특정 열 값의 크기에 따라 설정된 각 기록에서 가변적인 공간을 차지하는 열이다.가변 열은 NULLity와 크기를 결정하는 데 2바이트를 차지하며, 해당 열이 설정된 각 기록의 가변 공간 크기를 결정한다.
• 태그가 지정된 열은 레코드에 설정되지 않은 경우 공백이 전혀 필요하지 않은 열입니다.그것들은 단일 가치일 수도 있지만 또한 다중 가치일 수도 있다.동일한 태그가 붙은 열은 단일 레코드에 여러 개의 값을 가질 수 있다.태그가 지정된 열을 레코드에 설정하면 태그가 지정된 각 열의 인스턴스는 태그가 지정된 열 인스턴스 값 크기 외에 약 4바이트의 공간이 소요된다.태그가 지정된 단일 열의 인스턴스 수가 클 경우 태그가 지정된 열 인스턴스당 오버헤드는 약 2바이트가 된다.태그가 지정된 열은 설정되지 않은 경우 공간을 전혀 차지하지 않기 때문에 희소성 열에 이상적이다.다중값 태그가 지정된 열이 인덱싱되면 인덱스는 태그가 지정된 열의 각 값에 대한 레코드에 대해 하나의 항목을 포함하게 된다.

주어진 표의 경우, 열은 두 가지 범주 중 하나로 분류된다. 즉, 각 기록에서 정확히 한 번 발생하며, NULL 값은 몇 개일 수 있다. 그리고 드물게 발생하거나 단일 기록에서 다중 발생이 발생할 수 있다.고정 및 가변 열은 이전 범주에 속하고 태그가 지정된 열은 후자에 속한다.두 열 카테고리의 내부 표현은 서로 다르며, 열 카테고리 간의 트레이드오프를 이해하는 것이 중요하다.고정 및 가변 열은 발생이 NULL 값을 갖는 경우에도 일반적으로 모든 기록에 표시된다.이들 열은 오프셋 표를 통해 신속하게 처리할 수 있다.태그가 지정된 열 발생은 열 식별자가 선행하며, 태그가 지정된 열 집합을 이진 검색하여 열을 찾는다.

긴 값

긴 텍스트와 긴 이진 형식의 열 유형은 큰 이진 객체다.그것들은 긴 값 ID와 바이트 오프셋으로 키화된 클러스터링된 색인으로부터 별도의 B+트리에 저장된다.EESE는 이러한 열에 대한 추가, 바이트 범위 덮어쓰기 및 설정 크기를 지원한다.또한 EISE는 단일 인스턴스 저장소 기능을 가지고 있어, 여러 레코드가 동일한 큰 이진 객체를 참조할 수 있으며, 마치 각 레코드마다 정보의 복사본이 있는 것처럼, 즉 레코드 간 잠금 충돌이 없다.긴 텍스트 또는 긴 이진수 열 값의 최대 크기는 2GB이다.

버전, 자동 증가 및 에스크로 열

업데이트 작업을 통해 이 열이 포함된 레코드가 수정될 때마다 버전 열이 EESE에 의해 자동으로 증가된다.이 열은 응용 프로그램에서 설정할 수 없고 읽기 전용이다.버전 열의 응용 프로그램에는 주어진 레코드의 메모리 내 복사본을 새로 고쳐야 하는지 여부를 결정하는 데 사용되는 것이 포함된다.테이블 레코드의 값이 캐시된 복사본의 값보다 크면 캐시된 복사본이 오래된 것으로 알려져 있다.버전 열은 Long 유형이어야 한다.

자동 증분 열은 표의 모든 레코드에 대해 열에 포함된 값이 고유하도록 EESE에 의해 자동으로 설정된다.이러한 열은 버전 열과 마찬가지로 응용 프로그램에서 설정할 수 없다.자동 증분 열은 읽기 전용이며, 업데이트 작업을 통해 테이블에 새 레코드를 삽입할 때 자동으로 설정된다.열의 값은 레코드 수명 동안 일정하게 유지되며 테이블당 하나의 자동 증분 열만 허용된다.자동 증분 열은 Long 또는 Currency 유형일 수 있다.

EscrowUpdate 작업을 통해 Escrow 열을 수정할 수 있다.에스크로이드 업데이트는 숫자 델타 작업이다.에스크로 열은 Long 유형이어야 한다.숫자 델타 연산의 예로는 값에 2를 추가하거나 값에서 1을 빼는 것이 있다.ESE는 업데이트의 최종 값이 아닌 값의 변화를 추적한다.ESSE는 어떤 트랜잭션을 커밋하고 어떤 트랜잭션을 롤백하는지에 관계없이 실제 엔드 값을 결정할 수 있기 때문에 여러 세션이 각각 EscrowUpdate를 통해 동일한 값으로 변경될 수 있다.이를 통해 여러 사용자가 숫자 델타를 변경하여 열을 동시에 업데이트할 수 있다.선택적으로 데이터베이스 엔진은 열의 값이 0인 레코드를 지울 수 있다.이러한 에스크로 기둥에 대한 일반적인 용도는 참조 카운터인데, 많은 스레드가 자물쇠 없이 값을 증가/감소하며, 카운터가 0에 도달하면 레코드가 자동으로 삭제된다.

인덱스

인덱스는 테이블의 레코드를 지속적으로 정렬하는 것이다.인덱스는 정의된 순서의 행에 대한 순차적 액세스와 인덱싱된 열 값에 기반한 직접 레코드 탐색에 모두 사용된다.색인에 의해 정의된 순서는 열 배열의 관점에서 우선 순서에 따라 설명된다.이 열 배열을 인덱스 키라고도 한다.각 열을 인덱스 세그먼트라고 한다.각 지수 세그먼트는 주문 기여도 측면에서 오름차순 또는 내림차순일 수 있다.테이블에 대해 원하는 수의 인덱스를 정의할 수 있다.EESE는 풍부한 인덱싱 기능 세트를 제공한다.

클러스터된 인덱스

하나의 인덱스는 클러스터링된 인덱스 또는 기본 인덱스로 지정할 수 있다.EESE에서 클러스터링된 인덱스는 고유해야 하며 주 인덱스라고 한다.다른 인덱스는 비클러스터 또는 보조 인덱스로 설명된다.1차 인덱스는 인덱스 항목이 레코드 자체라는 점에서 2차 인덱스와 다르며 레코드에 대한 논리적 포인터가 아니다.2차 인덱스는 1차 인덱스의 레코드에 논리적으로 연결할 수 있는 1차 키를 가지고 있다.즉, 테이블은 물리적으로 1차 인덱스 순서에 따라 군집화된다.비색인 기록 데이터를 1차 지수 순서로 검색하는 것은 일반적으로 2차 지수 순서보다 훨씬 빠르다.이는 단일 디스크 액세스가 메모리에 여러 개의 레코드를 가져올 수 있으며, 이 레코드는 시간 내에 서로 근접하게 접근할 수 있기 때문이다.동일한 디스크 액세스가 여러 개의 레코드 액세스 작업을 만족한다.그러나 1차 지수 순서에 의해 결정되는 대로 지수의 중간에 레코드를 삽입하는 것은 지수의 끝에 그것을 추가하는 것보다 훨씬 더 느릴 수 있다.테이블 설계를 수행할 때 검색 패턴에 대해 업데이트 빈도를 주의 깊게 고려해야 한다.테이블에 대해 정의된 기본 인덱스가 없는 경우 데이터베이스 키(DBK) 인덱스라고 하는 암시적 기본 인덱스가 생성된다.DBK는 단순히 레코드를 삽입할 때마다 증가하는 고유 오름차순이다.그 결과 DBK지수의 레코드의 물리적 순서는 연대순 삽입순서로, 표의 끝에 항상 새로운 레코드가 추가된다.응용 프로그램이 고유하지 않은 인덱스에 데이터를 클러스터링하려면 고유하지 않은 인덱스 정의의 끝에 자동 증가 열을 추가하면 된다.

다중값 열 인덱싱

인덱스는 다중값 열에 걸쳐 정의될 수 있다.인덱싱된 열에 대한 값이 여러 개 있는 레코드의 경우 이 인덱스에 여러 개의 항목이 존재할 수 있다.다중값 열은 단일 값 열과 함께 색인화할 수 있다.두 개 이상의 다중값 열이 함께 색인화되면 다중값 속성은 색인에서 첫 번째 다중값 열에 대해서만 지정된다.우선순위가 낮은 열은 단일 평가된 것처럼 처리된다.

스파스 인덱스

인덱스 또한 희박하다고 정의할 수 있다.스파스 인덱스는 테이블의 각 레코드에 대해 적어도 하나의 항목을 가지고 있지 않다.희소 색인을 정의하는 데는 여러 가지 옵션이 있다.전체 인덱스 키가 NULL일 때, 키 세그먼트가 NULL일 때 또는 첫 번째 키 세그먼트만 NULL일 때 인덱스에서 레코드를 제외하는 옵션이 존재한다. 인덱스도 조건부 열을 가질 수 있다.이러한 열은 결코 색인 내에 나타나지 않지만 조건 열이 NULL이거나 NULL이 아닌 경우 레코드가 색인화되지 않도록 할 수 있다.

투플 인덱스

또한 텍스트 또는 긴 텍스트 열의 각 하위 문자열마다 하나의 항목을 포함하도록 색인을 정의할 수 있다.이러한 인덱스를 튜플 인덱스라고 한다.이들은 하위 문자열 일치 술어를 사용하여 쿼리 속도를 높이는 데 사용된다.TUPle 인덱스는 Text 열에 대해서만 정의할 수 있다.예를 들어 텍스트 열 값이 "I love JET Blue"이고 색인이 최소 튜플 크기 4자, 최대 튜플 길이 10자로 구성된 경우 다음과 같은 하위 문자열이 색인화된다.

“I love JET” "Love JET " "Love JET B" "사랑하는 JET Bl" “ve JET Blu” “e JET Blue” "JET 블루" "JET 블루" "ET 블루" "T 블루" "파란색" "파란색"

튜플 인덱스는 매우 클 수 있지만 "JET Blue"가 포함된 모든 레코드를 찾는 등 형식의 쿼리를 상당히 빠르게 할 수 있다.검색 하위 문자열을 최대 튜플 길이 검색 문자열로 나누고 결과를 교차시켜 최대 튜플 길이보다 긴 하위 문자열에 사용할 수 있다.이들은 인덱스 교차점이 없는 최대 튜플 길이 또는 최소 튜플 길이만큼 짧은 문자열의 정확한 일치에 사용할 수 있다.EESE에서 인덱스 교차로 수행에 대한 자세한 내용은 인덱스 교차를 참조하십시오.튜플 인덱스는 검색 문자열이 최소 튜플 길이보다 짧은 쿼리 속도를 높일 수 없다.

트랜잭션

트랜잭션은 BeginTransaction과 CommitTransaction 또는 Rollball로 구분된 처리의 논리적 단위다.트랜잭션 중에 수행되는 모든 업데이트는 원자적이다. 모두 동시에 데이터베이스에 나타나거나 전혀 나타나지 않는다.다른 거래에 의한 후속 업데이트는 거래에 보이지 않는다.그러나 트랜잭션은 그 동안 변경되지 않은 데이터만 업데이트할 수 있다. 그렇지 않으면 작업이 기다리지 않고 한 번에 실패한다.읽기 전용 트랜잭션은 기다릴 필요가 없으며, 업데이트 트랜잭션은 서로 다른 업데이트 트랜잭션에만 간섭할 수 있다.롤백 또는 시스템 충돌로 종료된 트랜잭션은 데이터베이스에 추적을 남기지 않는다.일반적으로 데이터 상태는 BeginTransaction 이전 상태로 롤백될 때 복원된다.

트랜잭션은 최대 7단계까지 중첩될 수 있으며, 하나의 추가 수준은 EISE 내부용으로 예약된다.이것은 거래의 일부가 전체 거래를 롤백할 필요 없이 롤백될 수 있다는 것을 의미한다; 중첩된 거래의 커밋트랜잭션은 단지 하나의 처리 단계의 성공을 의미할 뿐이고, 외부 거래는 아직 실패할 수 있다.변경사항은 가장 바깥쪽 트랜잭션이 커밋된 경우에만 데이터베이스에 커밋된다.이것은 거래 수준 0에 대한 커밋이라고 알려져 있다.트랜잭션이 트랜잭션 수준 0으로 커밋되면, 후속 시스템 충돌 시에도 트랜잭션이 완료되도록 하기 위해 트랜잭션을 설명하는 데이터가 동시에 로그에 플러시된다.로그를 동시에 플러시하면 EISE 트랜잭션이 지속 가능해진다.그러나 어떤 경우에는 애플리케이션이 업데이트를 주문하기를 원하지만 즉시 변경이 이루어질 것이라고 보장하지는 않는다.여기서 애플리케이션은 JET_bitIndexLazy로 변경 사항을 커밋할 수 있다.붉어지다

EESE는 멀티버전싱이라고 하는 동시성 제어 메커니즘을 지원한다.다중 버전에서, 모든 트랜잭션은 트랜잭션이 시작되었을 때와 같은 전체 데이터베이스의 일관된 보기를 쿼리한다.그것이 마주치는 유일한 업데이트는 그것에 의해 만들어진 업데이트들이다.이렇게 하여 각 거래는 쓰기 충돌의 경우를 제외하고, 시스템에서 실행 중인 유일한 활성 거래인 것처럼 운용된다.거래는 다른 거래에서 이미 갱신된 데이터 읽기를 기반으로 변경될 수 있기 때문에, 다중버전 자체만으로는 시리얼 가능한 트랜잭션을 보장하지 않는다.그러나 업데이트의 기반이 되는 읽기 데이터를 잠그기 위해 명시적 레코드 읽기 잠금 장치를 사용하는 것만으로 원할 때 연속성을 달성할 수 있다.읽기 및 쓰기 잠금 모두 GetLock 작업을 통해 명시적으로 요청할 수 있다.

또한 ESSE는 에스크로 잠금이라고 알려진 고급 동시성 제어 기능을 지원한다.에스크로 잠금(Escrow locking)은 숫자 값이 상대적인 방식으로 변경되는, 즉 다른 숫자 값을 추가 또는 빼는 매우 동시적인 업데이트다.에스크로 업데이트는 동일한 기준점에 대한 다른 동시 에스크로 업데이트에도 충돌하지 않는다.이는 지원되는 운영이 통용 가능하고 독립적으로 커밋되거나 롤백될 수 있기 때문에 가능하다.따라서 동시 업데이트 트랜잭션에는 간섭하지 않는다.이 기능은 종종 유지 보수 집계에 사용된다.

또한 EESE는 데이터 조작 작업에서 데이터 정의 작업으로 트랜잭션 의미론도 확장한다.테이블에 인덱스를 추가할 수 있으며 트랜잭션을 동시에 실행하면 트랜잭션 잠금 경합 없이 동일한 테이블을 업데이트할 수 있다.나중에 이러한 거래가 완료되면 새로 생성된 인덱스는 모든 거래에서 사용할 수 있으며, 업데이트가 발생했을 때 인덱스의 존재를 인식할 수 없는 다른 거래에 의해 만들어진 레코드 업데이트 항목이 있다.데이터 정의 연산은 기록 업데이트를 위한 트랜잭션 메커니즘에 기대되는 모든 특징으로 수행될 수 있다.이러한 방식으로 지원되는 데이터 정의 작업에는 AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable 및 DeleteTable이 포함된다.

커서 탐색 및 복사 버퍼

커서는 테이블 색인 내의 논리 포인터다.커서는 첫 번째 레코드 이전, 마지막 레코드 이후 또는 레코드 사이에 위치할 수 있다.커서가 레코드 앞이나 뒤에 위치하면 현재 레코드가 없다.동일한 테이블 인덱스에 여러 커서를 넣을 수 있다.많은 레코드 및 컬럼 연산은 커서 위치에 기초한다.커서 위치는 이동 연산에 의해 순차적으로 이동하거나 탐색 연산이 있는 인덱스 키를 사용하여 직접 이동할 수 있다.또한 커서는 인덱스 내에서 부분적인 위치로 이동할 수 있다.이렇게 하면 커서를 썸바 위치로 빠르게 이동할 수 있다.이 작업은 탐색 작업과 동일한 속도로 수행된다.간섭되는 데이터에 접근해서는 안 된다.

각 커서는 새 레코드를 만들거나 기존 레코드를 열별로 수정하기 위해 복사 버퍼가 있다.SetColumns 연산을 통해 내용을 변경할 수 있는 내부 버퍼다.복사 버퍼의 수정은 저장된 데이터를 자동으로 변경하지 않는다.현재 레코드의 내용은 업데이트 준비 작업을 사용하여 복사 버퍼에 복사할 수 있으며 업데이트 작업에서는 복사 버퍼의 내용을 레코드로 저장할 수 있다.복사 버퍼는 탐색 작업뿐만 아니라 트랜잭션 커밋 또는 롤백 시 암시적으로 지워진다.RetrieveColumns는 레코드 또는 복사 버퍼(있는 경우)에서 열 데이터를 검색하는 데 사용될 수 있다.

쿼리 처리

EESE 애플리케이션은 반드시 데이터를 쿼리한다.문서의 이 섹션은 ESE에 질의 행렬 논리를 작성하기 위한 응용 프로그램의 특징과 기법을 설명한다.

정렬 및 임시 테이블

EESE는 임시 테이블 형태로 정렬 기능을 제공한다.응용 프로그램은 데이터 레코드를 한 번에 한 레코드씩 정렬 프로세스에 삽입한 다음, 한 번에 한 레코드씩 정렬된 순서대로 검색한다.실제로 마지막 레코드 삽입과 첫 번째 레코드 검색 사이에 정렬이 수행된다.임시 테이블은 부분 및 전체 결과 집합에도 사용할 수 있다.이러한 표는 정렬 정의와 일치하는 색인 키를 사용하여 순차적으로 또는 행으로 직접 이동하는 기능을 포함하여 기본 표와 동일한 기능을 제공할 수 있다.또한 임시 테이블은 복잡한 집계를 계산하기 위해 업데이트할 수 있다.원하는 Aggregate가 정렬 프로세스의 자연적인 결과인 정렬과 유사한 기능으로 단순 Aggregate를 자동으로 계산할 수 있다.

색인 포함

2차 인덱스에서 열 데이터를 직접 검색하는 것은 중요한 성능 최적화다.RetrieveColumns 작업의 RetrieveFromIndex 플래그를 통해 데이터 레코드에 액세스하지 않고 보조 인덱스에서 열을 직접 검색할 수 있다.인덱스로 탐색할 때 레코드보다 보조 인덱스에서 열을 검색하는 것이 훨씬 효율적이다.기록에서 열 데이터를 검색한 경우 기본 키로 레코드를 찾기 위해 추가 탐색이 필요하다.이로 인해 추가 디스크 액세스가 발생할 수 있다.인덱스가 필요한 모든 열을 제공할 때 커버링 인덱스라고 한다.테이블 주 인덱스에 정의된 열은 보조 인덱스에도 있으며 JET_bitRetrieveFromPrimaryBookmark를 사용하여 유사하게 검색할 수 있다는 점에 유의하십시오.

인덱스 키는 대부분의 경우 원래 열 값으로 정규화될 수 있는 정규화된 형태로 저장된다.정상화는 항상 되돌릴 수 있는 것은 아니다.예를 들어, 텍스트 및 긴 텍스트 열 유형은 생략할 수 없다.또한 인덱스 키는 열 데이터가 매우 길면 잘릴 수 있다.2차 인덱스에서 직접 열을 검색할 수 없는 경우에는 항상 레코드에 액세스하여 필요한 데이터를 검색할 수 있다.

인덱스 교차점

질의는 종종 데이터에 대한 제약의 조합을 포함한다.제한을 처리하는 효율적인 방법은 가용지수를 사용하는 것이다.그러나 질의가 여러 제한사항을 포함하는 경우, 응용 프로그램은 종종 단일 지수로 만족하는 가장 제한적인 술어의 전체 지수 범위를 걸어 제한사항을 처리한다.잔여 술어로 불리는 나머지 술어는 기록 자체에 술어를 적용하여 처리한다.이것은 간단한 방법이지만, 잔여 술어를 적용하기 위해 레코드를 메모리로 가져오기 위해 많은 디스크 액세스를 수행해야 하는 단점이 있다.

인덱스 교차점은 복합적인 제약을 보다 효율적으로 처리하기 위해 여러 인덱스를 함께 사용하는 중요한 쿼리 메커니즘이다.단일 인덱스만 사용하는 대신 여러 인덱스의 인덱스 범위가 결합되어 나머지 술어를 적용할 수 있는 레코드의 수가 훨씬 적다.교차로를 제공하여 EESE를 통해 이 문제를 쉽게 해결인덱스 작업.이 작업은 동일한 테이블의 인덱스에서 일련의 인덱스 범위를 허용하고 모든 인덱스 술어를 만족하는 기본 테이블 레코드로 이동하는 데 사용할 수 있는 기본 키의 임시 테이블을 반환한다.

미리 조인된 테이블

조인(join)은 논리적으로 관련된 데이터를 애플리케이션에 사용하기 위해 함께 가져오는 표준화된 테이블 설계에서 일반적인 작업이다.관련 데이터를 메모리로 가져오기 위해 많은 데이터 액세스가 필요할 수 있기 때문에 조인은 비용이 많이 들 수 있다.이러한 노력은 경우에 따라 둘 이상의 논리 테이블에 대한 데이터가 포함된 단일 기본 테이블을 정의함으로써 최적화될 수 있다.기본 테이블의 열 집합은 이러한 논리 테이블의 열 집합의 조합이다.태그가 붙은 열은 다중값 및 희소량 값 데이터를 잘 처리하므로 이를 가능하게 한다.관련 데이터가 같은 레코드에 함께 저장되기 때문에 함께 접속해 조인 수행을 위한 디스크 액세스 수를 최소화한다.EESE는 최대 64,993개의 태그가 붙은 열을 지원할 수 있기 때문에 이 프로세스는 많은 수의 논리 테이블로 확장될 수 있다.인덱스는 다중값 열에 걸쳐 정의될 수 있기 때문에, 여전히 'interior' 테이블을 인덱싱할 수 있다.그러나 일부 제한사항이 존재하며 응용 프로그램은 이 기법을 사용하기 전에 사전 결합을 신중하게 고려해야 한다.

로깅 및 충돌 복구

ESE의 로깅 및 복구 기능은 시스템 충돌 시 데이터 무결성과 일관성을 보장한다.로그는 로그 파일에 데이터베이스 업데이트 작업을 중복적으로 기록하는 과정이다.로그 파일 구조는 시스템 충돌에 대해 매우 견고하다.복구는 이 로그를 사용하여 시스템 충돌 후 데이터베이스를 일관된 상태로 복원하는 프로세스 입니다.

트랜잭션 작업이 기록되고 각 트랜잭션 수준 0에 커밋하는 동안 로그가 디스크에 플러시된다.이를 통해 복구 프로세스가 트랜잭션 수준 0에 커밋된 트랜잭션에 의해 만들어진 업데이트를 다시 수행하고 트랜잭션 수준 0에 커밋되지 않은 트랜잭션에 의한 변경사항을 실행 취소할 수 있다.이러한 유형의 복구 계획을 흔히 '롤 포워드/롤 백워드' 복구 계획이라고 한다.로그는 아래에 설명된 백업 프로세스를 통해 데이터가 안전하게 복사될 때까지 보존하거나, 시스템 충돌로부터 복구하는 데 더 이상 필요하지 않은 즉시 순환 방식으로 재사용할 수 있다.순환 로깅은 로그에 필요한 디스크 공간을 최소화하지만 미디어 장애 시 데이터 상태를 재생성하는 기능에 영향을 미친다.

백업 및 복원

또한 로깅과 복구는 미디어 장애로부터 데이터를 보호하는 역할을 한다.ESSE는 하나 이상의 데이터베이스가 복사되는 온라인 백업과 함께 데이터베이스 작업에 영향을 미치지 않는 방식으로 로그 파일을 지원한다.백업이 이루어지는 동안 데이터베이스를 계속 쿼리하고 업데이트할 수 있다.일관성 있는 데이터베이스 집합을 복원하려면 백업 복원의 일부로 복구 프로세스를 실행해야 하기 때문에 백업을 '불완전한 백업'이라고 부른다.스트리밍 및 섀도 복사본 백업이 모두 지원된다.

스트리밍 백업은 백업 프로세스 중에 원하는 모든 데이터베이스 파일과 필요한 로그 파일의 복사본이 만들어지는 백업 방법이다.파일 사본은 테이프에 직접 저장하거나 다른 저장 장치에 저장할 수 있다.스트리밍된 백업에서는 어떤 종류의 작업도 중지할 필요가 없다.데이터베이스와 로그 파일을 모두 합산하여 백업 프로세스 중에 데이터 세트 내에 손상된 데이터가 없는지 확인하십시오.스트리밍 백업은 증분 백업일 수도 있다.증분 백업은 로그 파일만 복사되고 모든 데이터베이스를 최근 상태로 만들기 위해 이전 전체 백업과 함께 복원할 수 있는 백업이다.

섀도 복사본 백업은 새로운 고속 백업 방법이다.섀도 복사본 백업은 짧은 기간 동안 애플리케이션을 중지한 후 가상으로 복사되기 때문에 훨씬 더 빠르다.이후 데이터가 업데이트되면 가상 복사본이 구체화된다.경우에 따라 섀도 복사본 백업을 위한 하드웨어 지원은 가상 복사본을 실제로 저장할 필요가 없다는 것을 의미한다.섀도 복사본 백업은 항상 전체 백업임.

복원을 사용하여 단일 백업을 적용하거나, 하나 이상의 증분 백업과 단일 전체 백업의 조합을 적용할 수 있다.또한 기존 로그 파일도 재생성하여 트랜잭션 수준 0에 커밋된 것으로 기록된 마지막 트랜잭션까지 전체 데이터 세트를 재생성할 수 있다.백업 복원은 원래 응용프로그램을 지원할 수 있는 모든 시스템으로 이루어질 수 있다.그것은 같은 기계 또는 심지어 같은 기계 구성이 필요하지 않다.파일 위치는 복원 과정의 일부로 변경할 수 있다.

다른 하드웨어로 백업 및 복원

ESENT 데이터베이스가 생성되면 실제 Disk 섹터 크기가 데이터베이스와 함께 저장된다.물리적 섹터 크기는 세션 간에 일관성을 유지할 것으로 예상된다. 그렇지 않으면 오류가 보고된다.물리적 드라이브를 복제하거나 드라이브 이미지에서 다른 물리적 섹터 크기(고급 포맷 드라이브)를 사용하는 드라이브로 복원하면 ESENT가 오류를 보고한다.^[4]

이것은 알려진 문제이고 마이크로소프트는 핫픽스를 사용할 수 있다.윈도우즈 비스타 또는 윈도우즈 서버 2008의 경우 KB2470478을 참조하십시오.^[5]윈도우즈 7 또는 윈도우즈 서버 2008 R2의 경우 KB982018을 참조하십시오.^[6]

역사

JET Blue는 원래 마이크로소프트 Access에서 JET Red 데이터베이스 엔진을 업그레이드하기 위해 마이크로소프트에 의해 개발되었지만, 이 역할에는 결코 사용되지 않았다.대신 Exchange 서버, Active Directory, 파일 복제 서비스(FRS), 보안 구성 편집기, 인증서 서비스, 윈도우즈 인터넷 이름 서비스(WINS) 및 기타 마이크로소프트 서비스, 애플리케이션 및 윈도우즈 구성 요소에 의해 계속 사용됐다.^[7]수년간 마이크로소프트(MS)에서만 사용하는 비공개 API였지만 이후 누구나 사용할 수 있는 공개 API로 자리 잡았다.

1989년 3월 앨런 리페어(Allen Repeat)가 마이크로소프트(MS)에 합류하면서 데이터 액세스 엔진(DAE)에 대한 작업이 시작됐다.그 다음 해에 걸쳐 네 명의 개발자 팀이 앨런을 위해 ISAM을 대부분 완성하기 위해 일했다.마이크로소프트는 이미 BC7 ISAM(JET Red)을 가지고 있었지만, 당시 새로운 클라이언트-서버 아키텍처 영역에 진입하기 위해 보다 강력한 데이터베이스 엔진을 구축하기 위한 DAE(Data Access Engine) 노력을 시작했다.1990년 봄, BC7 ISAM과 DAE 팀이 합류하여 공동 엔진 기술(JET)의 노력이 되었다. 즉, 동일한 API 규격(JET API)을 준수하는 v1(JET Red)과 v2(JET Blue) 두 개의 엔진을 생산한다.DAE는 이스라엘의 국기 색깔을 위해 JET Blue가 되었다.BC7 ISAM은 러시아의 국기 색깔을 위해 JET Red가 되었다.JET Blue와 JET Red는 동일한 API 사양에 따라 작성되었지만 ISAM 코드를 전혀 공유하지 않았다.그들은 둘 다 공통 쿼리 프로세서인 QJET를 지원했는데, 나중에 BC7 ISAM과 함께 JET Red와 동의어가 되었다.

JET Blue는 1994년에 WINS, DHCP용 ISAM으로 처음 출하되었으며, 현재는 폐기된 RPL 서비스는 윈도 NT 3.5에서 판매되고 있다.그것은 1996년에 마이크로소프트 Exchange의 저장 엔진으로 다시 선적되었다.추가 윈도 서비스들은 그들의 스토리지 기술로 JET Blue를 선택했고 2000년까지 모든 윈도 버전들은 JET Blue와 함께 출하되기 시작했다.JET Blue는 Active Directory에 의해 사용되었으며 TCB(Trusted Computing Base)라는 특수 Windows 코드 세트의 일부가 되었다.JET Blue를 사용하는 마이크로소프트 애플리케이션의 수는 계속해서 증가하고 있으며, JET Blue API는 윈도우즈 내외에서 점점 더 많은 수의 애플리케이션과 서비스의 사용을 촉진하기 위해 2005년에 출판되었다.

A Microsoft Exchange Web Blog entry^[8] stated that developers who have contributed to JET Blue include Cheen Liao, Stephen Hecht, Matthew Bellew, Ian Jose, Edward "Eddie" Gilbert, Kenneth Kin Lum, Balasubramanian Sriram, Jonathan Liem, Andrew Goodsell, Laurion Burchall, Andrei Marinescu, Adam Foxman, Ivan Trindev, Spencer Low and Brett Shirley.

2021년 1월 마이크로소프트 오픈 소싱 ^[9]EESE그것은 GitHub에 허용 MIT 라이선스와 함께 게시되었다.

JET Red와 비교

그들은 공통된 혈통을 가지고 있지만 JET Red와 EESE 사이에는 엄청난 차이가 있다.

• JET Red는 파일 공유 기술로, EESE는 서버 애플리케이션에 임베디드하도록 설계돼 파일을 공유하지 않는다.
• JET Red는 파일 복구를 위해 최선의 노력을 다하고, EESE는 충돌 복구를 보장하기 위해 미리 쓰기 로깅과 스냅샷 분리를 했다.
• 버전 4.0 이전의 JET Red는 페이지 레벨 잠금만 지원하며, EESE 및 JET Red 버전 4.0은 레코드 레벨 잠금을 지원한다.
• JET Red는 ODBC와 OLE DB를 포함한 다양한 쿼리 인터페이스를 지원한다. EESE는 쿼리 엔진과 함께 배송되지 않고 대신 응용 프로그램에 의존하여 C ISAM 코드로 쿼리를 작성한다.
• JET Red는 최대 데이터베이스 파일 크기가 2GiB인 반면, EESE는 최대 데이터베이스 파일 크기가 4KiB인 8TiB, 8KiB인 16TiB이다.

참조

• "Exchange Terminology". Archived from the original on 2008-11-09. Retrieved 2015-08-20.
• "Understanding Information Store Essentials". Archived from the original on June 9, 2007. Retrieved 2007-06-18.

외부 링크

• 공식 웹사이트
• GitHub의 확장형 스토리지 엔진
• 확장 가능한 스토리지 엔진 - 코드 프로젝트