ページ

2010年11月4日

MongoDBのshardとreplica その1

MongoDBのshardingとreplicaについてのメモ。間違っていたらごめんさい。

まず、MongoDBの負荷分散、もしくは、データの分散については、shardingという仕組みで行っています。shard自体は通常のmongodのプロセスです。各shardには、データがchunkの単位で保存されています。chunkは、キーに対してデータの連続性が確保されているので、連続したデータへのアクセスが高速化されます。一つのmongodのプロセスにchunk単位以上のデータがセットされたり、サーバの数が増加すると、他のshardにデータが自動的に移動します。この仕組みだけをみると、shardは増えることはあっても、減るのは苦手のように聞こえます。

shardが自動でデータの分散を行ったり、どこにデータがあるのかを見つけるためにconfigサーバがいます。mongodが実データを扱うのに対して、configサーバはメタデータを扱います。メタデータは、shardなどのサーバの情報とchunkの情報です。configサーバはchunkの情報を更新するために2フェーズコミットを採用しているようです。また、製品レベルで運用する場合は、3つのconfigサーバを別々のマシンで動作させておくように言っています。configサーバがいないと、shardでのchunkの更新は行われなくなります(データの移動などが行われない)。

mongosというプロセスが、shardのフロントエンドに配置されます。mongosはconfigサーバとやりとりして、クライアントからのリクエストなどをどのshardに送信するか決めます(ルーティング)。また、複数のshardにリクエストした場合は、それらの結果を一つに纏めてクライアントに返します。


レプリケーションは各shard単位(replica set)で行われます。各shard内のmongodはprimaryとsecondaryのプロセスにわかれます。mongodのプロセスがreplica setに追加されると、データは自動的にコピーされます。masterのプロセスが落ちた場合は、自動的にsecondaryのmongodがmasterに昇格します。一度昇格すると、設定で降格させられないか、敵前逃亡してプロセスが死なない限りは、masterのままです。複数のsecondaryがいる場合は、どの順番にmasterになるかは、設定によって自動的にきまります。

server1,2,3とあった場合、データAはserver1と2、データBはserver2と3、データCはserver3と1のように分散させて配置するパターンもありますが、MongoDBはshard単位でreplicaを制御するようになっています。
単純なKVSとしてみた場合、configサーバをみれば、データがどこにあるか判別できるのは速度的にすてきかも。

その2に続くかも。でわでわ。

0 件のコメント: