System.IO.Log SequenceNumbers의 길이가 가변적 인 이유는 무엇입니까?

Question

복구 가능한 트랜잭션 시스템을 구축하기 위해 System.IO.Log 기능을 사용하려고합니다. Common Log File System 상단에 구현 된 것으로 알고 있습니다.

보통 미리 쓰기 로깅에 대한 접근 방식은 로그 이외의 위치 (예 : 기록 된 작업으로 수정 된 데이터베이스 페이지의 헤더)에 로그 레코드 시퀀스 번호를 지속하는 것과 관련이 있습니다.

흥미롭게도 CLFS의 설명서에는 그러한 sequence numbers are always 64-bit integers이 나와 있습니다.

그러나, SequenceNumber 주위의 .Net 래퍼는 이 아닌 constructed from a byte[] 일 수 있습니다. 값이 read as a byte[] 일 수도 있지만 UInt64이 아닐 수도 있습니다. SequenceNumber.GetBytes() 구현을 검사하면 실제로 8 또는 16 바이트 배열을 반환 할 수 있음을 알 수 있습니다.

이 몇 가지 질문이 제기

1. 왜 닷넷 시퀀스 번호의 크기가 다를 않는 CLFS 시퀀스 번호에서를?
2. .Net 시퀀스 번호의 길이가 가변적 인 이유는 무엇입니까?
3. 왜 이러한 시퀀스 번호를 나타내는 데 128 비트가 필요합니까? 64 비트 주소 공간 (16 바이트 또는 약 10^19 바이트)을 사용하기 전에 로그를 자르면 오래 걸리는 것처럼 보입니다.
4. 로그 시퀀스 번호가 128 비트 정수로 표시 될 경우 항상 의 힙 할당을 무의미하게 초래하지 않고 UInt64 쌍으로 직렬화/비 직렬화하는 방법을 제공하십시오. 쓰고 읽을 필요가 있니? 또는 왜 SequenceNumber 값 유형을 전혀 만들지 않아도됩니까?

그냥 그래서 당신은 더 이상 백만 테라 바이트보다 untruncated 로그를 가질 수 로그 시퀀스 번호의 저장 오버 헤드를 두 배로 이상한 균형을 것 같다, 그래서 어쩌면 몇 가지를 여기에 뭔가를 누락되었거나 것 같은 느낌. 내가 아는 사람이 나를 똑바로 세울 수 있다면 정말 고마워.

해명 나는 데미안와 안드라스이 말하는 것을 동의

. 이러한 우려는 byte [] 반환 유형에 대한 가장 확실한 설명입니다. 그러나 CLFS 상단의 현재 구현은 디스 어셈블리의 검사에서 64 비트 LSN을 생성하는 코드 경로와 128 비트 LSN을 생성하는 코드 경로를 가지고 있습니다. 왜? CLFS 상단의 System.IO.Log를 사용하는 클라이언트는 고정 길이의 64 비트 필드에 LSN을 안전하게 저장할 수 있습니까? 128 비트 필드? 고정 된 길이의 필드?

물리 - 논리 복구를 구현하기 위해 페이지 헤더 어딘가에 LSN 필드가 필요하기 때문에 LSN이 임의의 길이가 될 수 있다면 쓸모가 없습니다. 필드의 길이가 가변 인 경우 페이지의 비 - 머리 부분을 처리하는 복잡성이 크게 증가하지 않습니다. 가변 길이에 경계가 없으면 머리글이나 페이지 내용을 새 페이지에 흘리지 않고 LSN 머리글 필드를 확장 할 수있는 페이지 공간을 확보 할 수 있는지도 모를 수 있습니다. 일반적인 상황에서 실행 가능합니다 (이 조건을 감지 할 시점은 저장하는 데이터 구조가 그런 종류의 것을 허용하는 경우에도 그러한 복구를 수행하는 방법에 대한 정보가있는 시점보다 훨씬 추상적이기 때문에).

Answer 1

첫 번째 링크에는 IRecordSequence 인터페이스의 두 가지 구현이 포함되어 있으며 그 중 하나만 CLFS 기반 인터페이스입니다. 물론, 다른 미래의 구현도있을 수 있습니다. 어쩌면 그들은 더 긴 시퀀스 번호를 사용하는 다른 시스템을 알고있을 것이며 시퀀스 번호가 항상 64 비트라고 가정하는 코드를 사람들이 작성하는 것을 원하지 않을 것입니다.

Answer 2

가장 명백한 이유는 UInt64가 CLS 규격이 아니고 System.IO.Log 어셈블리가 명시 적으로 CLSCompliant (true) (리플렉터에서 열림)로 표시 되었기 때문입니다.

플랫폼에서 기본 유형을 ULONGLONG으로 정의 했으므로 결과의 절반이 음수가되고 결과 공간이 줄 바꿈되기 때문에 결과를 Int64에 강제로 적용하는 것은 안전하지 않습니다.

따라서 부호없는 정수를 허용하도록 CLS 사양을 변경하는 것 외에 가장 좋은 해결책은 바이트 배열 결과를 채택하는 것입니다.이 방법은 향후 버전의 Windows를 확장해야하는 경우에도 향후 교정이 추가된다는 장점이 있습니다. 더 많은 비트를 반환합니다.

Answer 3

내 개인용 직관적 인 가변 길이 LSN은 LSN의 크기를 예측할 수 없다는 가정하에 (LSN이 공급자를 변경하지 않았다는 가정하에) 의미가 없습니다. 실제 이유는 나보다 잘 알고있는 사람들과 접촉하지 않고 추측하는 것이 도움이되지 않을 것이라고 생각합니다.

미래에 대해 확실하게 말할 수있는 한 CLFS 사용자는 LSN이 많은 시간을 들이지 않고 합리적인 시간 동안 길이가 변하지 않을 것이라고 가정하는 것이 안전하다고 생각합니다. 그것의 Win32 API. (나는 이것을 CLFS에서 몇 년 동안 일한 사람으로 말합니다.)

가변 길이 LSN을 기술적으로 지원해야하는 애플리케이션이 많습니다.