MongoTokyo2012メモ
＃本当にメモ書きなので期待しないでください(^^;
Introduction
マスタ1台
→落ちたら書き込み読み込みできない
マスタスレーブ1台
→マスタが落ちると読み込みしかできない
マスタ1台スレーブ2台
→マスタが落ちても自動昇格するので読み書き可能
replicasetがデータセンター間で構成されていればデータセンターが落ちても大丈夫！
workingset
どのようなスペックのマシンが必要か
→ディスクはIO性能が大事、メモリ必要とか普通の話だけしてた
SSDはどう？
→高いよね。HDDとSSDのハイブリッドの構成だよね普通。
※いや、普通にSSDだけにしてるけど...
Monitoring モニタリング
→組み込みのツール mongostat
→グラフ化ならcacti/zabbix使おうね
→MMS(MongoMonitoringSystem?)を使うとパフォーマンス状況を10genに送れる？無料
安定的に動作している状況をきちんと把握しておくことが、問題分析に重要
バックアップとリストア
ちゃんと事前にテストしておこうね
replicasetならすでにコピーがあるわけなのでそのままで問題なし
shardingの場合はバックアップ戦略が必要
複数人でバックアップリストアの習熟練習をしておくべき
QAタイム
replicasetの場合。
マスタが落ちたときにまだスレーブにデータが行き渡っていないときどうなる？
ほぼすべてのデータがメモリ上にある。キャッシュはどのように管理されている？
既存ユーザの最大ノード数は？
→10genでは把握しきれていない。ヨーロッパで300～400ノード、他に1000ノード使っている例をきいたことがあるが、実際にはどのくらいが最大かわからない。
MongoはCPUあまり使わない
→JOINやトランザクションないし。でもIOは激しいのでそっち(メモリや速いHDD/SSDなど)が重要
shardingしているとcount操作時、実際の数字より多く返戻されると聞いたが、本当か？また改善方法はあるのか？
→がんばってるけどまだ完全ではない。
shardingをOFFにすれば大丈夫？
→状況によるので、個別に話した方がいいかも（えー
マスタが落ちたときにメモリとHDDで非同期書き込みなのでその間に電源断したらどうなるの？
→デフォルト非同期実行なので、消える。用途によって同期書き込みにしたほうがいい（できるのかな
楽天
largeインスタンスで店舗データを置いてみた
100GB(6000万object)をshardingせずに配置。
バッチで全データつっこむ→5時間弱かかった
6000万件のデータにindex1つ追加するのに60分くらい
replica1台追加するのに60分くらい(自動的に行われるもの)
MongoDB使った時の落とし穴
lockオペレーションがきつい→グローバルロックなので
→background indexはprimaryの時のみ有効。secondaryはforeground index作成になるので全ロックする→読み書きできなくなる orz
※次のリリースで改善される模様（secondaryでもbackground indexが有効になる）
CyberAgent
AnimalLandの事例
体制
プロデューサー2名
デザイナー1名
Flasher3名
エンジニア4名
m1.Largeとx1.ExLargeで作ってる？
MongoDB用マシンは34GBメモリ搭載。CPU使わないのでもったいないけど仕方ない
Why Mongodb?
アメーバPicoで使ってたから。ノウハウ的にもたまっていたので
複雑なデータ構造に耐えられる
複雑なクエリにも対応できる。好きな場所にindex張れるし
適材適所
・課金データとかは安定性をとってMySQL
・セッションはmemcached
・トランザクションとかないのでデータはMongoDB
ユーザにまつわるデータは全て1documentにつっこんでる
→家の場所とか友人の数とかいろいろ
いくつかスライドがあがっていたので張っておく。
＃本当にメモ書きなので期待しないでください(^^;
Introduction
マスタ1台
→落ちたら書き込み読み込みできない
マスタスレーブ1台
→マスタが落ちると読み込みしかできない
マスタ1台スレーブ2台
→マスタが落ちても自動昇格するので読み書き可能
replicasetがデータセンター間で構成されていればデータセンターが落ちても大丈夫！
workingset
どのようなスペックのマシンが必要か
→ディスクはIO性能が大事、メモリ必要とか普通の話だけしてた
SSDはどう？
→高いよね。HDDとSSDのハイブリッドの構成だよね普通。
※いや、普通にSSDだけにしてるけど...
Monitoring モニタリング
→組み込みのツール mongostat
→グラフ化ならcacti/zabbix使おうね
→MMS(MongoMonitoringSystem?)を使うとパフォーマンス状況を10genに送れる？無料
安定的に動作している状況をきちんと把握しておくことが、問題分析に重要
バックアップとリストア
ちゃんと事前にテストしておこうね
replicasetならすでにコピーがあるわけなのでそのままで問題なし
shardingの場合はバックアップ戦略が必要
複数人でバックアップリストアの習熟練習をしておくべき
QAタイム
replicasetの場合。
マスタが落ちたときにまだスレーブにデータが行き渡っていないときどうなる？
ほぼすべてのデータがメモリ上にある。キャッシュはどのように管理されている？
既存ユーザの最大ノード数は？
→10genでは把握しきれていない。ヨーロッパで300～400ノード、他に1000ノード使っている例をきいたことがあるが、実際にはどのくらいが最大かわからない。
MongoはCPUあまり使わない
→JOINやトランザクションないし。でもIOは激しいのでそっち(メモリや速いHDD/SSDなど)が重要
shardingしているとcount操作時、実際の数字より多く返戻されると聞いたが、本当か？また改善方法はあるのか？
→がんばってるけどまだ完全ではない。
shardingをOFFにすれば大丈夫？
→状況によるので、個別に話した方がいいかも（えー
マスタが落ちたときにメモリとHDDで非同期書き込みなのでその間に電源断したらどうなるの？
→デフォルト非同期実行なので、消える。用途によって同期書き込みにしたほうがいい（できるのかな
楽天
largeインスタンスで店舗データを置いてみた
100GB(6000万object)をshardingせずに配置。
バッチで全データつっこむ→5時間弱かかった
6000万件のデータにindex1つ追加するのに60分くらい
replica1台追加するのに60分くらい(自動的に行われるもの)
MongoDB使った時の落とし穴
lockオペレーションがきつい→グローバルロックなので
→background indexはprimaryの時のみ有効。secondaryはforeground index作成になるので全ロックする→読み書きできなくなる orz
※次のリリースで改善される模様（secondaryでもbackground indexが有効になる）
CyberAgent
AnimalLandの事例
体制
プロデューサー2名
デザイナー1名
Flasher3名
エンジニア4名
m1.Largeとx1.ExLargeで作ってる？
MongoDB用マシンは34GBメモリ搭載。CPU使わないのでもったいないけど仕方ない
Why Mongodb?
アメーバPicoで使ってたから。ノウハウ的にもたまっていたので
複雑なデータ構造に耐えられる
複雑なクエリにも対応できる。好きな場所にindex張れるし
適材適所
・課金データとかは安定性をとってMySQL
・セッションはmemcached
・トランザクションとかないのでデータはMongoDB
ユーザにまつわるデータは全て1documentにつっこんでる
→家の場所とか友人の数とかいろいろ
いくつかスライドがあがっていたので張っておく。
