8. OSC 2014 Kansai@Kyoto 8/52
RDBMS と NoSQL(2)
しかしクラウド時代においては、データの一貫性保
持はコストが高い……こともある
一貫性保持は常に必要なのか?
例: EC サイトの在庫状況はリアルタイムでなくてもよい
決済時に一貫性が担保されていればよい
一貫性の完全な保持を諦めれば水平にスケールできる
DB
App
Tokyo
US App
EU App EU AppDB
US AppDB
Tokyo AppDB
9. OSC 2014 Kansai@Kyoto 9/52
RDBMS と NoSQL(3)
クラウドに必要な要件を持つストレージエンジンを
RDBMS と使いわける
シンプルな機能
高速
スケーラブル
Not Only SQL = NoSQL (SQL に NO! ではない )
Key Value Store (KVS) Apache Cassandra, Tokyo Cabinet,
Rakuten ROMA, Redis, Riak
グラフ指向 DB Neo4j, HyperGraphDB
列指向 DB Apache HBase
ドキュメント指向 DB CouchDB, MongoDB
24. OSC 2014 Kansai@Kyoto 24/52
●MongoDB の性能の秘密
MongoDB はファイルシステムに展開されているコレ
クションを mmap している
ローカリティがある READ アクセスについてはオンメモリ
でアクセスするので高速
要は「ディスクにスワップアウトできるオンメモリ DB 」
ローカリティが低いアクセスは性能が出ない
Storage
V. mem
P. mem
35. OSC 2014 Kansai@Kyoto 35/52
レプリカセット応用 (3)
セカンダリノードに対するアクセス
Write Concern
データの書き込みがどこまで波及
するまで待つかを設定する値
基本は即座に戻る
セカンダリノードの数も指定可
Read Prefence
セカンダリノードからの読み込みを
許可してプライマリの負荷を下げる
古い値を掴んでも大丈夫なとき
P
S S
j : 1
w : 2
P
S S
PRIMARY
SECONDARY
45. OSC 2014 Kansai@Kyoto 45/52
オートシャーディングの仕組み (2)
リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと
最小のチャンク数を持つシャードの差が規定値を超えた
場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシング
が起きる
A
Shard 1 Shard 2
A
Shard 1 Shard 2
B
46. OSC 2014 Kansai@Kyoto 46/52
オートシャーディングの仕組み (2)
リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと
最小のチャンク数を持つシャードの差が規定値を超えた
場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシング
が起きる
A
Shard 1 Shard 2
A
Shard 1 Shard 2
B
A
Shard 1 Shard 2
B
C
47. OSC 2014 Kansai@Kyoto 47/52
オートシャーディングの仕組み (2)
リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと
最小のチャンク数を持つシャードの差が規定値を超えた
場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシング
が起きる
A
Shard 1 Shard 2
A
Shard 1 Shard 2
B
A
Shard 1 Shard 2
B
C
A
Shard 1 Shard 2
B
C
C