アプリゲームのDBを完全にMongodbでやろうとして
使っている方に聞いて見た。
推薦ポイント
・MySQLのHA Proxyが構成出来ない時。
・Auto fail overを使いたい。
・初期設計・開発等テーブル定義がゆるい時のテスト用(他社実績有りとのこと)・ApacheのログやMySQLに格納したある期間のログデータを突っ込んでMapreduce等で解析を行いたい。
・データを突っ込んでから時差をおいてデータを読み込んで良い場合。
非推薦ポイント
・容量が食い過ぎ。
すべての動作ログを残すというのもあるが70Gを用意してサービス開始3日で70%を超えたと。
・以前570Gを超えたところから動作が可笑しくなり700Gで制御不能になった。
・安易にSecondaryのHDDを増設したらPrimaryとのSyncで2日。
・今回のゲーム仕様に3回まで入力できるがあるが、TransactionがなくSyncの時差により4,5回まで入力できる事が普通にありえるとのこと(これは仕方ないかも)。
・ShardingがTuningがやはり難しく偏り過ぎて諦めた。
結果
3回までのもありMySQLがやはりやりやすいかと。
但し開発初期のときだけはMongoDBでやってみるのも有りかも。
使っている方に聞いて見た。
推薦ポイント
・MySQLのHA Proxyが構成出来ない時。
・Auto fail overを使いたい。
・初期設計・開発等テーブル定義がゆるい時のテスト用(他社実績有りとのこと)・ApacheのログやMySQLに格納したある期間のログデータを突っ込んでMapreduce等で解析を行いたい。
・データを突っ込んでから時差をおいてデータを読み込んで良い場合。
非推薦ポイント
・容量が食い過ぎ。
すべての動作ログを残すというのもあるが70Gを用意してサービス開始3日で70%を超えたと。
・以前570Gを超えたところから動作が可笑しくなり700Gで制御不能になった。
・安易にSecondaryのHDDを増設したらPrimaryとのSyncで2日。
・今回のゲーム仕様に3回まで入力できるがあるが、TransactionがなくSyncの時差により4,5回まで入力できる事が普通にありえるとのこと(これは仕方ないかも)。
・ShardingがTuningがやはり難しく偏り過ぎて諦めた。
結果
3回までのもありMySQLがやはりやりやすいかと。
但し開発初期のときだけはMongoDBでやってみるのも有りかも。