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");
- ※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を比較した場合の特徴のひとつとして,