Shardingの紹介

based on v49

shard
chunk
configサーバ
mongosプロセス
shardキー
オペレーションのタイプ
サーバレイアウト
参照

MongoDBは、システムの一部としてauto-sharding機能を含みます。このドキュメントはshardingのアーキテクチャの概要と使い方を示します。

alphaリリースでの制限はShardingの制限を参照してください。

MongoDBクラスターは、複数の shards ( mongod インスタンス) 、 mongos ルーティングプロセス、1つ以上の configサーバ 、 クライアント で構成されます。

shard

それぞれのshardは1つ以上のサーバで構成され、mongodプロセス (mongodはMongoDBのデータベースプロセスのコアです) を使いデータを保存します。

典型的なケースでは、可用性を高めるため、1つのshardに対し複数のサーバを使います。この複数のサーバ/mongodプロセスのセットは、 replica set から成ります。

Note: Replica sets は、 (SERVER-557 ) で予定されている、MongoDBの新しいバージョンのレプリケーションです。それまでの間、一つのshardは1つのmongodサーバで動かすことができます。高い可用性と冗長性のためには、それぞれのshardのmongodでmaster/slaveの運用してください。

データは、特定のshardにある範囲で順序を保持したままアサインされます。このため、shardキーでの範囲でのクエリの実行を効果的に行えます。これは、Googleの BigTable の設計に似ています。

chunk

chunkは、特定のコレクションの連続した範囲のデータ(ドキュメント)です。 (コレクション, 最小キー, 最大キー)の組み合わせでchunkを表現できます。shardキーKのドキュメントは、最小キー >= K > 最大キーと言う条件のchunkにマッチします。

chunkは、最大サイズ(例えば50MB)まで増えます。 chunkが最大サイズに達すると、そのchunkは2つの新しいchunkに分割されます。 shardが余剰データを持っている場合、chunkがシステムによって他のshardに移動されます。同様に、サーバ(shard)を追加したときchunkは移動します。

configサーバ

configサーバは、クラスタのメタデータを保存します。これは、基本的なshardとサーバ、chunkの情報などを含みます。
configサーバによって保存される主なデータは、chunkの情報です。それぞれのconfigサーバは、すべてのchunkの情報のコピーを完全に持ちます。 configサーバ間での一貫性を確実にするために 2 phase commitが使われています。
configサーバがダウンした場合、shardの追加や移動ができないので、クラスタのメタデータは読み込み専用になります。データの読み書きは通常通りできます。

mongosプロセス

mongos プロセスとは、クラスタの様々なコンポーネントがまるでが1つのシステムに見えるようにするためのルーティングやコーディネートをするプロセスと考えてください。 mongosは永続的な情報を持ちません。またどのサーバ上でも動かせます(shardサーバと同一のサーバ上で走らせることを選ぶこともでえきますが、クライアントサーバのように別の場所で動かすこともできます)。

mongosは起動するためにconfigサーバからメタ情報を取得します。そして、クライアントからのリクエストがあった場合、それを的確なサーバへ割り振ります。そして結果を収集し、クライアントへ返します。

システムは、いくつでもmongosのインスタンスを持つことができます。それぞれのインスタンスはメタデータのためのRAM領域が必要です。そうでなければ、mongosのインスタンス間でまったくコーディネートがないので、制限がないです。（？） (すべてのコーディネートは、一つのmongosと、shardサーバ群、configサーバ群から成ります。加えてshardサーバは、もう一つとshardと、configサーバ群と通信します)

shardキー

コレクションを分割するために、shardキーのパターンを定義します。このパターンはインデックスの定義で使われるパターンに似ています。1つかまたは2つ以上のフィールが分散するデータのキーになります。以下はshardキーのいくつかの例です。

{ name : 1 } 
{ _id : 1 } 
{ lastname : 1, firstname : 1 } 
{ tag : 1, timestamp : -1 }

MongoDBは順番を保持します。shardキーによって、近くのデータは同じサーバに(同じchink)に存在する傾向があります。 configデータベースはchunkの情報を下記のように保持します。

注意: shardキーは粒度が細かくなるようにすべきです。たとえば上の例で、100万人が同じ名前を持つということはないでしょう。さむないと、chunkが巨大になり、分割ができなくなります。そのような場合には、複合shardキーを使い、値を分解できるようにフィールドを追加します。

オペレーションのタイプ

shardされたシステムでは、二つのスタイルのオペレーションを持ちます。 global と targeted です。

targeted オペレーションでは、mongosは最小限のshardにアクセスします。多くの場合1つだけです。この操作はとても効率的です。

globalオペレーションは、システム内の(ほぼ)すべてのshardにアクセスします。

次のテーブルは、様々なオペレーションとタイプです。下記の例では、 { x : 1 } をshardキーと仮定しています。

Operation	Type	Comments
db.foo.find( { x : 300 } )	Targeted	1つのshardでクエリー
db.foo.find( { x : 300, age : 40 } )	Targeted	1つのshardでクエリー
db.foo.find( { age : 40 } )	Global	すべてのshardでクエリー
db.foo.find()	Global	sequential
db.foo.find(...).count()		find() オペレーションと同じ
db.foo.find(...).sort( { age : 1 } )	Global	並列
db.foo.find(...).sort( { x : 1 } )	Global	順番
db.foo.count()	Global	並列
db.foo.insert( <object> )	Targeted
db.foo.update( { x : 100 }, <object> ) db.foo.remove( { x : 100 } )	Targeted
db.foo.update( { age : 40 }, <object> ) db.foo.remove( { age : 40 } )	Global
db.getLastError()	?
db.foo.ensureIndex(...)	Global

サーバレイアウト

サーバは様々に編成されます。 1つ目は、config、mongos、mongodをそれぞれのサーバで動かす方法です。しかし、この方法はconfig DBなどの負荷は少ないので、やりすぎになりがちです。下記に、過剰にならずに、物理サーバをいくつかのプロセスで共有する方法を示します。

その他の設定も可能です。たとえば、server 1-6のすべてでmongosを走らせます。または、アプリケーションサーバ(server 7）でmongosを走らせます。 mongosをアプリケーションサーバで走らせると、localhostでアプリケーションサーバとmongosが通信できるという利点もあるかもしれません。

参照

Configuring