2

System.IO.Log機能を使用して、回復可能なトランザクション システムを構築しようとしています。Common Log File Systemの上に実装されることを理解しています。

ARIESの先行書き込みロギングへの通常のアプローチでは、ログ レコード シーケンス番号をログ以外の場所 (たとえば、ログに記録されたアクションによって変更されたデータベース ページのヘッダー) に保持します。

興味深いことに、CLFS のドキュメントには、このようなシーケンス番号は常に 64 ビット整数であると記載されています。

ただし、紛らわしいことに、これらの .Net ラッパーはから構築SequenceNumberできますが、 からは構築byte[]できませんUInt64。その値はとして読み取るbyte[]こともできますが、 として読み取ることはできませんUInt64。の実装を調べるとSequenceNumber.GetBytes()、実際には 8 バイトまたは 16 バイトの配列を返すことができることがわかります。

これにより、いくつかの疑問が生じます。

  1. .Net シーケンス番号のサイズが CLFS シーケンス番号と異なるのはなぜですか?
  2. .Net シーケンス番号の長さが可変なのはなぜですか?
  3. このようなシーケンス番号を表すのに、なぜ 128 ビットが必要なのですか? 64 ビットのアドレス空間 (16 エクスビバイト、または約 10^19 バイト、より長い単語をアドレス指定する場合はさらに多く) を使い果たす前に、ログを切り捨てるように思えますか?
  4. ログ シーケンス番号が 128 ビット整数として表される場合、書き込み/読み取りが必要になるたびにUInt64、存続期間の短い新しい s に対してかなり無意味にヒープ割り当てを発生させる代わりに、それらを s のペアとしてシリアル化/逆シリアル化する方法を提供してみませんか? byte[]1？あるいは、なぜわざわざSequenceNumber値型を作るのでしょうか?

100 万テラバイトを超える切り捨てられていないログを保持できるようにするためだけに、ログ シーケンス番号のストレージ オーバーヘッドを 2 倍にするのは奇妙なトレードオフのように思えます。知っている人が私を正してくれたら、とてもありがたいです。

明確化

ダミアンとアンドラスが言っていることに同意します。これらの懸念は、byte[] 戻り値の型の最も可能性の高い説明です。しかし、CLFS の上にある現在の実装には、逆アセンブリを調べると、64 ビット LSN を作成するコード パスと、128 ビット LSN を作成するコード パスがあります。なんで？また、CLFS 上で System.IO.Log を使用するクライアントは、LSN を固定長の 64 ビット フィールドに安全に格納できますか? 128ビットフィールド？固定長のフィールド?

生理学的回復を実装するには、ページ ヘッダーのどこかに LSN フィールドが必要なため、LSN が任意の長さにできる場合は、ほとんど役に立ちません。フィールドが可変長の場合、ページのヘッダー以外の部分に対処するための複雑さが重要ではなくなります。可変長に制限がない場合、ヘッダーまたはページの内容を新しいページにこぼさずに LSN ヘッダー フィールドを展開するためのスペースがページにあることを確認することさえできません。一般的なケースでは実行可能です (この状態を検出するポイントは、保存しているデータ構造がそのようなことを許可している場合でも、そのような回復を実行する方法に関する情報を得るポイントよりもはるかに抽象的ではないため)。

4

3 に答える 3

4

これの最も明白な理由は、UInt64がCLSに準拠していないのに対し、System.IO.Log AssemblyはCLSCompliant（true）（リフレクターで開いている）として明示的にマークされているためです。

また、プラットフォームは基になるタイプをULONGLONGとして定義しているため、結果の半分が負になり、結果スペースがラップアラウンドするため、結果をInt64に強制することは安全ではありません。

したがって、符号なしintを受け入れるようにCLS仕様を変更する以外の最善の解決策は、バイト配列の結果を採用することでした。これには、Damienが示唆するように、将来のバージョンのWindowsが拡張して、より多くを返す場合に備えて、将来を保証するという追加の利点もあります。ビット。

于 2010-06-01T13:19:02.497 に答える
3

最初のリンクでは、IRecordSequence インターフェイスの 2 つの実装について言及していますが、そのうちの 1 つだけが CLFS ベースのものです。そしてもちろん、他の将来の実装もある可能性があります。そのため、より長いシーケンス番号を使用する他のシステムを認識している可能性があり、シーケンス番号が常に 64 ビットであると想定するコードを作成することを望んでいません。

于 2010-04-10T06:19:03.487 に答える
1

可変長 LSN に関する私の個人的な直感は、アプリケーションがその LSN のサイズを予測できないと想定することを意図したものではないということです (プロバイダーが変更されていない場合)。本当の理由については、私よりよく知っている人々と連絡を取らずに推測するのは役に立たないと思います.

将来について確信を持って言える限り、CLFS のユーザーは、Win32 API で大量のチャーンが発生しなければ、妥当な期間、LSN の長さが変化しないと想定できると言っても過言ではありません。(これは、数年間 CLFS に取り組んできた者として言います。)

可変長 LSN をサポートしなければならないのは技術的に難しいアプリケーションがたくさんあることに同意します。

于 2010-08-29T07:18:46.323 に答える