第2回 MongoDB.jp 勉強会 in Tokyo ( #mongotokyo ) 2011/04/09(Sat.)
-
- いいね！0
ななころび
@7korobi
悪い例：Low-Cardinality Shard Key 自動バランス化する仕組みが能力を発揮できない。 #mongotokyo
2011-04-09 14:42:58
Kenji Yoshida
@xuwei_k
自分は最初からずっと聞こえるけど、聞こえない人いるのはなんでだろ ( #mongotokyo live at http://ustre.am/v6yz)
2011-04-09 14:43:52
ななころび
@7korobi
悪い例：Ascending Shard Key ふるいChankは放置される。かならず最大値のChankが分割される。 #mongotokyo
2011-04-09 14:44:27
ななころび
@7korobi
悪い例：Random Shard Key 均等に分散するが、非常に範囲が広がるため、indexが非効率、RAMを圧迫する、巨大なShardingになってしまう。 #mongotokyo
2011-04-09 14:46:33
railute
@railute
Shard Keyの悪い例：ランダム値（MD5など） インデックスの危機が悪い。場合によってはデータが偏る。 #mongotokyo
2011-04-09 14:47:30
ななころび
@7korobi
良い例：Coarsely Ascending Key + Search Key 解析対象である部分は頻繁に更新され、興味のない部分はMigrationが起こらない。 #mongotokyo
2011-04-09 14:48:46
Masakazu Matsushita
@matsukaz
Random Shard Keyが良くないのは、古い情報も新しい情報も関係なく全てのChunkにデータが分散するからだと認識してます。 ( #mongotokyo live at http://ustre.am/v6yz)
2011-04-09 14:51:43
Masakazu Matsushita
@matsukaz
例えば、データを10件取りたいときに、1つのchunkから取れれば効率的なところを、10のchunkを見に行かなければならなくなったりします。 ( #mongotokyo live at http://ustre.am/v6yz)
2011-04-09 14:52:17
Naoki Nemoto
@nemoton
ShardKey の悪い例を解説されている、(1)Low Cordiality ShardKey, (2)Ascending ShardKey, (3)Random ShardKey. 善い例は一種類、Coarsely Ascending ShardKey #mongotokyo
2011-04-09 14:53:15
ななころび
@7korobi
migration中の、当該Chankへの挿入は？ （きっと可能だと思う。自動で発生するんだから、ロックしてちゃ使いものにならない。重いかも。） #mongotokyo
2011-04-09 14:53:50
MATSUO a.k.a マッツォ
@understeer
#mongotokyo 懇親会、38名の参加受付を頂きました。多めに頼んでいますので、休憩中に受付にお声がけください。
2011-04-09 14:59:51
ななころび
@7korobi
・config メタ情報を引き受ける、特殊なmongodサーバー。balancing抑止など、こちらへ指示。 #mongotokyo
2011-04-09 15:00:53
suisui@Tokyo
@suisui
configサーバー：configサーバー同士はレプリケーションしない。configサーバー同士が同期する(?) #mongotokyo
2011-04-09 15:01:55
Road to 労働(Vtuber志望)
@takochuu
#mongotokyo に参加中ー。Shardingを使う場合はMigrationをoffにして使うのが現実的そうな印象
2011-04-09 15:02:25
Naoki Nemoto
@nemoton
mongos サーバーは、あらゆる仲介役、ただし、自分自身ではデータは持たない。ルーティングする感じ、でも死んだらクライアントは何もできなくなる。 #mongotokyo
2011-04-09 15:02:40