http://ameblo.jp/joe-ab298/entry-10798866093.html
この記事に自己レス。
『shardingされたコレクションには1つだけユニークなインデックスを持つ事が可能です。そのコレクションには他のユニークなインデックスは存在しません。（_id を除く）』
これが何を指してるのか理解できた。
ユニークな、っていうのは結局のところ一意制約のかかっているkeyを作ることが
できる、ということに他ならないんですね。
だから衝突するようなキーをinsertしようとしたら、duplicate！って怒られるように
設定ができるようです。
昨日、mongoTokyoなるカンファレンスに参加してきましたが、結局みんな
atomic Operation使ってauto increment 的なkeyを自作してるみたいなので
その辺を使うと柔軟さの中に少し制約が加えられるのかな、と。
なので、「unique:true」とした場合には、指定したshardKeyが重複することは
ないですよ、ということになるんですね。
参考：mongoDB 日本語ドキュメント（インデックス）
http://www.mongodb.org/pages/viewpage.action?pageId=5800049
shardingしてても、shardkey以外にindexは勿論張ることができるんだけど、
性能を引き出すに当たっては、indexもさることながら、shardkeyの設計？が
重要です。
結局「どのshard（かたまり）に取りに行くのか？」を決めるのが
そのkeyになるので、shardkey以外を検索条件にするような場合には、
複数台あるshardサーバーを横断的にスキャンすることになるので、
find()は遅くなります。
なのでそこで悩んだらデータ設計考え直した方がいいのかもね、っていう
話もあるのかなぁと思います。
まぁいろいろ考えて、試したことは、いくつかあるので、どこかに残しておこう。
この記事に自己レス。
『shardingされたコレクションには1つだけユニークなインデックスを持つ事が可能です。そのコレクションには他のユニークなインデックスは存在しません。（_id を除く）』
これが何を指してるのか理解できた。
ユニークな、っていうのは結局のところ一意制約のかかっているkeyを作ることが
できる、ということに他ならないんですね。
だから衝突するようなキーをinsertしようとしたら、duplicate！って怒られるように
設定ができるようです。
昨日、mongoTokyoなるカンファレンスに参加してきましたが、結局みんな
atomic Operation使ってauto increment 的なkeyを自作してるみたいなので
その辺を使うと柔軟さの中に少し制約が加えられるのかな、と。
なので、「unique:true」とした場合には、指定したshardKeyが重複することは
ないですよ、ということになるんですね。
参考：mongoDB 日本語ドキュメント（インデックス）
http://www.mongodb.org/pages/viewpage.action?pageId=5800049
shardingしてても、shardkey以外にindexは勿論張ることができるんだけど、
性能を引き出すに当たっては、indexもさることながら、shardkeyの設計？が
重要です。
結局「どのshard（かたまり）に取りに行くのか？」を決めるのが
そのkeyになるので、shardkey以外を検索条件にするような場合には、
複数台あるshardサーバーを横断的にスキャンすることになるので、
find()は遅くなります。
なのでそこで悩んだらデータ設計考え直した方がいいのかもね、っていう
話もあるのかなぁと思います。
まぁいろいろ考えて、試したことは、いくつかあるので、どこかに残しておこう。