1

特定の種類のデータにカスタム インデックスを使用すると、データベースの断片化が減少するかどうかを確認しようとしています。

[編集: MS SQL Server 2008 R2 を使用しています]

タイムスタンプ付きの測定データを含む SQL データベースがあります。大量のデータが常に挿入されますが、一度挿入されると、実質的に更新する必要はありません。ただし、複数のデバイス (約 50 台) が同時にデータを測定するため、これらのタイムスタンプは一意ではありません。

これは、テーブル内の 50 行ごとに同じタイムスタンプ値が含まれていることを意味します。このデータは多かれ少なかれ同時に受信されますが、行が可能な限り順番に書き込まれるようにするために追加の注意を払うことができますが (それが役立つ場合)、おそらくしばらくメモリに保持し、データを取得したときにのみ書き込むことによって可能です。単一のタイムスタンプのすべてのデバイスから。

Guid.Comb で NHibernate を使用して、単純な bigint ID でのインデックス ルックアップを回避しています。単純な GUID とは対照的に、これは断片化を減らすはずですが、挿入が非常に多いため、断片化はすぐに発生します。

私のデータにはタイムスタンプが付けられ、データはほぼ順番に挿入される (タイムスタンプが増加する) ため、このテーブルの一意のクラスター化インデックスを使用して主キーを作成するより賢い方法があるかどうか疑問に思っています。Timestamp 列は基本的に bigint 数値 (.NET DateTime ティック) です。

また、同じタイムスタンプ列の非クラスター化インデックスもかなり断片化されていることに気付きました。この場合、ヒープの断片化を減らすためにどのようなインデックス戦略をお勧めしますか?

4

2 に答える 2

2

多分この答えを見てください、HiLoは面白そうです。

また、断片化は、インデックス値の順序とそれらが追加される順序との不一致の結果ではなく、自然なファイルの成長効果 (ここで説明されているように) の結果ではないでしょうか?

于 2010-11-17T09:42:40.083 に答える
1

キーの個別の列は、データを更新しないため、このテーブルにはあま​​り意味がありません。ただし、おそらくそのタイムスタンプ列に基づいて、多くのクエリを実行することになると思います。

主キーをタイムスタンプ列とデバイス ID 列の組み合わせにすることができます。それをクラスター化してみることができます。これにより、可能な限り速く書くことができるはずです。ただし、デバイスでクエリを実行する場合は、デバイス ID とタイムスタンプに別のインデックスが必要になる場合があります (逆)。ただし、クラスター化されたものを逆にすることはしません。これにより、末尾のページではなく、テーブル全体で書き込みが行われるようになります。また、ほとんどのクエリに日付範囲と複数のデバイスが含まれる場合、最初にタイムスタンプでクラスタリングすると、最高のパフォーマンスが得られます。

于 2010-11-17T23:11:57.473 に答える