出稼ぎのとある案件で、redisを使ってますが、色々ヤラれますね。
そんな訳で、それをwebソーシャルゲームのフロントから使ってるオレらが悪いんですけどね。そんなに言うなら使うなって?もちろん使いませんよ。選んだのは小生じゃない。「3ヶ月前から決まってるから、オレの顔に泥を塗るんじゃねえ!」とか言われたら引き下がりますよ。面倒臭いし。こっちは外注の身ですから。
MongoDBでいいんじゃね?と思ってるしね。
- 運用面
 - スキーマ(に相当する概念)を、整数で管理しなければならない
 - 故に、DBを取り違えても、書き込めてしまう。
 - 書き込み先DBを間違えてることに、果たして何時気がつくやら。
 - 端的に言えば、複数のredisインスタンスを使い分けるような運用を想定してないのでしょう。
 - 逆に言えば、そんな使い方するならredisを選択するのが間違ってます。
 - バックアップは、永続ファイル1個をコピーするしかない。
 - 逆にいうと、バックアップが必要になるような運用にredisを選択するのが間違ってます。
 - appendonly=true は永続ファイルを壊す可能性は減るが
 - 実はジャーナルなので、永久に増え続ける。
 - 長期運用するとG単位になるケースもある。そこまで来ると再起動に20分とか掛かる。
 - プログラム面
 - DB全体から「検索」或いは、hashの中身を取得すると、hitした全件を取得するしかない。
 - PHPは、メモリを食いつぶすと、即死するので、非常に相性が悪い。
 - 例えば Set型を使って、タグの運用が楽にできますよー。http://gihyo.jp/dev/feature/01/redis/0004 とか得意気にいってるが
 - 50万件hitしたら、それが$resultにドカーんと送信してくるわけです。
 - ini_set("memory_limit","8000M"); にすりゃいいとかって話でもない。
 - 基本、バッチ実行で使うことを想定してる気がする。
 - expireは、メモリ次第で、期待より早期に消える場合がある
 - キャッシュとしての想定しかないのでしょう。
 - だったらmemcacheでいいじゃねえか。
 - phpredisは https://github.com/nicolasff/phpredis
 - オブジェクト類を、テキトーにシリアライズして保存してはくれるが独自実装なので、他の言語から使うときには互換性がない。
 - そんな想定ないけどね。
 - 本来はsession_handlerに使う程度の想定しかないんじゃねえかと。https://github.com/nicolasff/phpredis#php-session-handler
 
そんな訳で、それをwebソーシャルゲームのフロントから使ってるオレらが悪いんですけどね。そんなに言うなら使うなって?もちろん使いませんよ。選んだのは小生じゃない。「3ヶ月前から決まってるから、オレの顔に泥を塗るんじゃねえ!」とか言われたら引き下がりますよ。面倒臭いし。こっちは外注の身ですから。
MongoDBでいいんじゃね?と思ってるしね。