Readノードの選択
システムで保証する一貫性のレベルに応じて，
| 設定名 | 意味 |
|---|---|
| PRIMARY | PRIMARYノードのみからReadする |
| PRIMARY PREFERRED | 可能であればPRIMARYノードからReadする |
| SECONDARY | SECONDARYノードのみからReadする |
| SECONDARY PREFERRED | 可能であればSECONDARYノードからReadする |
| NEAREST | レイテンシの小さいノードからReadする※ |
- ※1 結果整合性
- 書き込みが行われたPRIMARYノードからReadを保証せず，
状況や設定によってSECONDARYノードからREADする。最新の状態が反映されているかどうかは保証されないが， 可用性と性能は向上する （例：DNS）。
※ NEARESTに設定すると，
「ドライバからReplica Setsにpingをし，
設定はアプリケーションのコード中で行います。
Rubyでの設定例
@collection.find({:doc => 'foo'}, :read => :primary) #primaryノードからReadする
@collection.find({:doc => 'foo'}, :read => :secondary) #secondaryノード群からReadする
Tagを利用したSharding
Shardingに参加しているノードにTagを追加しTagRangeを設定することで，
設定例
> sh.addShardTag("shard0000", "TokyoDC");
> sh.addTagRange("appdb.users", { "uid" : 1 }, { "uid" : 100 }, "TokyoDC");
図4 大陸間をまたがったHA構成の例
- ※2 Awareness
（アウェアネス） - ある問題に対する人々の知識の程度，
危機・ 問題意識の高さ， といった意味
TTL（Time To Live） Collections
一定時間が経過した後，
起点とするフィールドに{"expireAfterSeconds":数値}というハッシュを第二引数に入れてensureIndex()でインデックスを作成することで，
制限として，
TTL Collectionsの例
// eventsコレクションのデータを，created_atフィールドを起点に30秒後に
// 削除されるように設定
> db.events.ensureIndex( { “created_at”: 1 }, { expireAfterSeconds: 30 } )
// statusにはdate-type型を入れる。new Date()でOK
// statusがdata-type型以外，またはcreated_atが無いデータは消えない
> db.events.insert( { "myid" : 1, "created_at" : new Date() } );
> db.events.insert( { "myid" : 2, "created_at" : "String" } );
> db.events.insert( { "myid" : 3, "time_field" : new Date() } );
> db.events.count();
// => 3
//30秒後
> db.events.count();
// => 2
> db.events.find({},{"_id":0})
{ "myid" : 2, "created_at" : "String" }
{ "myid" : 3, "time_field" : ISODate("2012-11-28T16:04:19.781Z") }
// "myid" : 1 のデータが消えている
次回のテーマ
今回はv2.
MongoDBと他のNoSQLを比較した場合の特徴のひとつとして，
