4月9日に
これまでの MongoDB JPの活動について
まずはMongo DBの日本ユーザーグループの活動について簡単にお話しします。
2010年11月に
それに引き続き,
なお前回のカンファレンスより,
今回の勉強会の内容
「第2回 MongoDB JP 勉強会 in Tokyo」
順番 | 発表者 | タイトル |
---|---|---|
1 | @doryokujin | Sharding詳解〜機能と仕組みの理解〜 |
2 | @bibrost | Type-safe MongoDB with Scala |
3 | @muddydixon | アクセスログをできるだけいろいろ見る時のmapreduce + ニフティクラウドでの構築とパフォーマンスを初心者からわかりやすく |
4 | @yamaneko1212 | 地理空間インデックスを利用したWebアプリケーション(LT) |
5 | @joe_ |
Tachy with MongoDB |
6 | @everyone | ディスカッション 〜MongoDBを活用し, ※時間の都合により中止となりました。 |
7 | @everyone | 懇親会 |
勉強会最後にディスカッションの時間を用意していましたが,
なお,
@doryokujin 「Sharding詳解〜機能と仕組みの理解〜」
筆者 @doryokujin からはMongoDBの特徴的な機能であるShardingについて,
MongoDBが掲げるShardingのコンセプトは3つはあります。
- 1. Make the cluster “invisible”
クライアントが裏側でサーバーがSharding
(分割) されているいることを意識することなく, シングルサーバーで運用しているときと同じ扱いで各種の操作ができます。 - 2. Make the cluster always available for reads and writes
フェイルオーバー・
データの分割・ Shard間でのバランシング, これらをすべて自動で行うことで, クラスタ全体を常に健全に保ち, 常に読み書き可能な状態を保証しています。 - 3. Let the cluster grow easily
新しいサーバーの追加・
撤退も自動かつ容易に行えるような仕組みになっています。
このようなコンセプトを掲げるMongoDBのShardingを深く理解するために,
- 1. Shard key
Shard KeyはShardingによってコレクションを分割する際のキーとなるものです。このShard Keyの選び方によって,
Shard間に偏りが起こる確率が変わってきますので慎重に選択しなければなりません。また一度Shard Keyを決定してしまうと変更はほぼ不可能です。そんなShard Key選択における悪い例を3つ, 良い例を1つを紹介しました。 - 2. Balancing, Migration
これらの機能はShard間のデータの均等な分散を維持する仕組みを提供してくれます。BalancingはShard間でデータの不均衡が生じた際に偏りの大きなShardからデータを移行することによって是正してくれる機能です。また,
データの移行のことをMigrationと呼んでいます。MongoDBはこれらの機能を自動で行ってくれますが, 「いつBalancing機能が発動するのか?」 「Migrationが起こった時に生じる問題点」 などを紹介しました。結論としてMigrationが起こってしまう (Balancing機能が発動する) と (4. Shardingクエリで詳しく紹介しますが) 色々不都合が生じる可能性があるため, それ自身が起こらないように工夫する (Shard Keyの慎重な決定や継続的なモニタリング) ことが重要です。 - 3. mongos, config, mongo
これらはShardingを構成するサーバー群です。それぞれが異なる役割をもっており,
特にmongosサーバーがクライアントとShardサーバー群を仲介する役割を持っており, コンセプト 「Make the cluster “invisible”」を実現しています。それぞれのサーバーの役割について詳しく説明しました。 - 4. Sharding クエリ
Sharding環境における各種クエリは,
シングルサーバーにおけるクエリと結果がどう違うのかについて説明しました。Shard環境におけるクエリはfindやupdateなどの多くのクエリに対しては効率的に処理を行ってくれますが, 条件にShard Keyを指定しないと効率の良い処理が行われないこと, またMigration実行中のCountなどの集約処理においては正しい結果が得られない可能性があること, 複数のShardに対してほぼ同時に書き込みがあった場合, ユニークキーの重複などDB自身に矛盾が起こってしまう可能性があることを紹介しました。
発表を終えて,
勉強会の後,