質問: DBはmysqlをもちいております。 > > 1つのCommentが複数のArticleに関係することはあるのでしょうか? > > > 今の仕様では、複数には関係しません。 1つのCommentが一つのArticleに関係します。 > > アクセスのうち、Commentの書き込み(集計の処理対象)は何割ぐらいを占めるのでしょうか? > > > Commentの書き込みは全体の8割程を占めます。ここがメインの業務と言って過言ではありません。むしろ他の部分は負荷が少ないです。 > > counter_cacheだとデットロックのリスクがある > > > デットロックの問題を補ったcounter_cultureというgemがあるみたいです。 http://qiita.com/tachiba/items/797ea74e7eeb7f32f886 こちらを実運用した経験がないので、あるからといって何ともいえないのですが。 > > WebサーバとDBサーバは別ですか? > > > 別です。 > > また、DBの負荷とWebアプリの負荷どちらを懸念されていますか? > > > 今のところはそういう成約はないです。 また、負荷が高くなった際にスケールしても問題ないという許可は頂いております。
回答: すみません。 5)のみについての助言となりますが、ご容赦を。 WebサーバとDBサーバは別ですか? また、DBの負荷とWebアプリの負荷どちらを懸念されていますか? 負荷については、ソフト的に解決できるものと解決できないものがあります。 「WebサーバとDBサーバが別であれば、特にどちらかのサーバーに負荷を掛けてはいけない」のような制約に従うのが良いと思われます。 * Webサーバに負荷を掛けては行けない →集計の際に、DBに頑張ってもらう * DBサーバに負荷を掛けては行けない →集計の際に、Webアプリに頑張ってもらう サーバを増やすことに特に問題がないのであれば、集計専用のサーバ(DB、アプリケーション入り)を用意すれば、現状のサイトに一番影響がない状況になるのではないでしょうか。 簡単にいうと、「もうなんも考えたくねぇー。今のサーバーに負荷をあんまり掛けなきゃいいんでしょ?w」という解決法ですね。 **【新規サーバがやること】** * 新規サーバーからDBサーバ集計対象のデータを随時(or定期的に)取得し、保持する →ログデータとのことだったので、追加のデータしかありえないため、差分だけ取得する。 * 集計は定期的でもよいし、リアルタイムでもよい →なぜならば、一番負荷がかかるのは集計専用サーバのみだから。 **【既存サーバへの影響】** * 集計データを渡す際の負荷 * 集計結果を表示するページを作成する際に、新規サーバーへデータをとりに行く必要が出てくる(ちょっとイレギュラー)。