.net - 为什么 System.IO.Log SequenceNumbers 具有可变长度？

Question

我正在尝试使用 System.IO.Log构建可恢复交易系统的功能。我理解它是在 Common Log File System 之上实现的.

通常ARIES write-ahead logging 的方法涉及在日志以外的地方持久化日志记录序列号(例如，在被记录的操作修改的数据库页面的标题中)。

有趣的是，CLFS 的文档说这样的 sequence numbers are always 64-bit integers .

然而，令人困惑的是，围绕那些 SequenceNumber 的 .Net 包装器s 可以是 constructed from a byte[]但不是来自 UInt64。它的值也可以是read as a byte[] ，但不是 UInt64。检查 SequenceNumber.GetBytes() 的实现表明它实际上可以返回 8 或 16 字节的数组。

这提出了几个问题:

1. 为什么 .Net 序列号的大小与 CLFS 序列号不同？
2. 为什么 .Net 序列号的长度可变？
3. 为什么需要 128 位来表示这样的序列号？似乎您会在用完 64 位地址空间(16 exbibytes，或大约 10^19 字节，如果您寻址更长的字，更多)之前截断日志？
4. 如果日志序列号将被表示为 128 位整数，为什么不提供一种方法将它们序列化/反序列化为成对的 UInt64，而不是毫无意义地进行短时间的堆分配每次需要写入/读取一个时都使用新的 byte[] 吗？或者，为什么要把 SequenceNumber 变成一个值类型呢？

将日志序列号的存储开销加倍似乎是一种奇怪的权衡，这样你就可以拥有超过一百万 TB 的未截断日志，所以我觉得我在这里遗漏了一些东西，或者可能是一些东西。如果有知情人士可以让我直截了当，我将不胜感激。

澄清

我同意 Damien 和 Andras 所说的。到目前为止，这些担忧是对 byte[] 返回类型最可能的解释。但是，在检查反汇编时，CLFS 之上的当前实现具有创建 64 位 LSN 的代码路径和创建 128 位 LSN 的代码路径。为什么？在 CLFS 之上使用 System.IO.Log 的客户端能否安全地将 LSN 存储在固定长度的 64 位字段中？ 128 位字段？任意固定长度的字段？

如果 LSN 可以是任意长度，它几乎没有用，因为您需要页眉中某处的 LSN 字段来实现生理逻辑恢复。如果该字段的长度可变，那么寻址页面的非 header 部分的复杂性会显着增加。如果可变长度没有限制，那么您甚至无法确定页面上是否有空间来扩展 LSN header 字段，而不会将 header 或页面内容溢出到新页面，这两者都不是在一般情况下是可行的(因为如果您存储的数据结构甚至允许这种情况，您将检测到这种情况的点远没有您将获得有关如何执行此类恢复的信息的点抽象)。

Answer 1

最明显的原因是因为 UInt64 不符合 CLS，而 System.IO.Log Assembly 被明确标记为 CLSCompliant(true)(在反射器中打开)。

并且由于平台将基础类型定义为 ULONGLONG，因此将结果强制转换为 Int64 是不安全的，因为一半的结果将是负数并且结果空间会回绕。

因此，除了更改 CLS 规范以接受无符号整数之外，最好的解决方案是采用字节数组结果——正如 Damien 所建议的那样，它还具有额外的优势，可以在未来版本的 Windows 扩展它时进行 future 验证返回更多位。