Team Blogで紹介されてるSQL Azureの水平パーティショニングのパターンは微妙な気がしてきた。。。主キーにGuidってどうなの?
2011-02-04 09:59:37更新の早いテーブルで PK の検索性能の為に noncluster index を使うという場合に、ランダム生成される物のインデックスへの挿入が頻発する危険がある RT @kamebuchi: @kazuk 明確に絶対使うな、とかそういうレベルではないってことですね。
2011-02-04 10:20:42@kamebuchi @kazuk 使うなってことはないけど、そーした方がいいかどうかは場合によりけり。単に「主キー」として使うだけなら、int でいいと思うし。Guid 使って効果あるのは、主キーとして使えるナチュラルな項目がなく、かつ主キーを人の目に触れることがある場合?
2011-02-04 10:21:58nonclusterの場合実際にソートが発生するんで要注意、性能要件の高いテーブルでは後にボトルネックとして顕在化する危険があるから避けるのが望ましい。
2011-02-04 10:23:18人の目に触れる+前後関係の推測性をなくしたい場合ですな RT @hidori: @kamebuchi @kazuk 使うなってことはないけど、そーした方がいいかどうかは場合によりけり。単に「主キー」として使うだけなら、int でいいと思うし。Guid 使って効果あるのは、主キーと
2011-02-04 10:26:07@hidori @kazuk そんなに認識にずれがなくて安心しました。類推されるのを防ぎたいとか人目に触れないかもしれないけど触れられたくない(顧客IDとか?)本来のGuidらしい使い方なら許容範囲かなぁ。あとはIndex回りやら適材適所考える感じですかね
2011-02-04 10:26:22@kamebuchi 個人的にはレコード数の最大値が仕様上決められないトランザクションテーブルならあり。ただ、多くの場合インデックスの付いた複合キーがレコード内に隠れているはず。
2011-02-04 10:26:58@kamebuchi 主キーではなくパーティショニングキーでした。すみません。パーティショニングを行う場合に、GUIDでパーティショニングした場合、完全にランダムで分散されてしまうため、区切りとしてはどうなの?って思いました。データベースをまたぐJOINとかは性能を落としますし。
2011-02-04 10:28:54Guidが性能ネックになったら少なくとも昇順保障つけばインデックスが荒れる心配ないので、登録日時+何らかのカウンタをGuidにねじ込む事でGuidぽい何かを作ることが多いな RT @kamebuchi: @hidori @kazuk そんなに認識にずれがなくて安心しました。類推さ
2011-02-04 10:30:24@Surf174 なるほど~ありがとうございます。そっち方面はすごく疎いのですが、どうパーティショニングするかは設計次第?同一パーティションはDBまたぐんでしょうか…
2011-02-04 10:31:01@kamebuchi SQL AzureではSQL Serverのようなパーティショニングができないです。1パーティション=1DBになります。なので同一パーティションでDBをまたぐことはないと思います。(続く)
2011-02-04 10:35:24@kamebuchi パーティションの設計としては、データがどう参照されるかとかどのデータが多く追加されそうなのか分析して設計するのがベストじゃないかなぁと思います。自分は実際にDBの設計はしたことないんですが・・・w
2011-02-04 10:37:18@Surf174 そんなに認識にずれがなくてよかったですw気になったのは主キーにGuidという部分だったのですが、、そこまでDB使い倒したことがないっすw
2011-02-04 10:41:30@ishisaka 最大値あるのは確かに怖いですよね。他のケースはもっとちゃんと設計しないといけないんだろうなぁと改めて思いました
2011-02-04 10:42:58