6

500 以上のテーブルを持つデータベースがあり、そのほとんどすべてのテーブルには、データ型が guid (uniqueidentifier) のクラスター化された PK があります。

現在、.NET の Guid.NewGuid() メソッドで生成された「通常の」「ランダムな」guid から、NHibernate guid.comb アルゴリズムで生成されたシーケンシャル guid への切り替えをテスト中です。これはうまく機能しているように見えますが、「ランダムな」主キー値を持つ何百万もの行をすでに持っているクライアントはどうでしょうか?

  • 今後生成される新しい ID がシーケンシャルになるという事実から、彼らは恩恵を受けるでしょうか?
  • 既存のデータに対して何かできる/すべきことはありますか?

これについての指針を前もって感謝します。

4

3 に答える 3

0

テーブルがプライマリインデックスにクラスター化されているか、別のインデックスにクラスター化されているかによって異なります。たとえば、GUID PKと作成日を使用してテーブルに大量の新しいレコードを作成する場合、挿入操作を最適化するために、通常は作成日でクラスター化するのが理にかなっています。

一方、実行されるクエリによっては、GUID上のクラスターの方が適している場合があります。その場合、シーケンシャルGUIDを使用すると、挿入のパフォーマンスが向上します。使い方を深く知っていないと、質問に最終的な答えを出すことはできないと思います。

于 2010-04-13T11:35:45.303 に答える
0

同様の問題に直面しています。NHibernate guid.comb アルゴリズムを使用して既存のキーを更新するアプリケーションを作成することで、既存のデータを更新できると思います。新しいキーを関連する外部キー テーブルに伝播するために、更新を一時的にカスケードすることは可能でしょうか? .NET コードでこれを行うと、SQL スクリプトよりも遅くなります。別のオプションとして、SQL で guid.comb ロジックを複製することもできますが、これが可能かどうかはわかりません。

既存のデータを保持することを選択した場合、guid.comb アルゴリズムを使用するとパフォーマンスがいくらか向上するはずです。挿入時にページ分割が発生しますが、新しい GUID は完全にランダムではなくシーケンシャルであるため、これは少なくともいくらか軽減されます。考慮すべきもう 1 つのオプションは、GUID プライマリ キーのクラスター化インデックスを削除することですが、既存のクエリのパフォーマンスがどの程度影響を受けるかはわかりません。

于 2010-09-14T04:51:47.953 に答える
0

あなたはこれを行うことができますが、あなたがしたいかどうかはわかりません。シーケンシャル GUID を使用する利点はありません。実際、分散/レプリケーションの理由がない限り、GUID を主キーとして使用することはお勧めしません。クラスタ化インデックスを使用していますか?

そうは言っても、先に進む場合は、最初にアルゴリズムの値をテーブルにロードすることをお勧めします。

外部キーに問題が発生します。前述のテーブルで古い GUID と新しい GUID を関連付け、外部キーを削除し、トランザクション更新を実行してから、外部キーを再適用する必要があります。

整数ベースのシステムと言うために GUID から完全に離れていない限り、手間をかける価値があるとは思いません。

于 2010-04-13T11:02:21.397 に答える