---

将来の話をしよう。


twitterのシステムを模倣するとして、ぶち当たるであろう壁としてデータベースの限界です。
この限界には大まかに2つの意味が入っており「記憶容量の限界」と「アクセス負荷の限界」があります。

まぁ前者は自分でサーバー立てるわけじゃないのでどうしようもないかも知れないんですが、その辺は追々考えるつもりですが、とりあえず分割システムは作っておかなくてはなりませんね。
後者のアクセス負荷に関しても、これまた何らかの手段で分散をしなければなりませんね。


このような問題を考えた時、まず考えるべきは先人の知恵を借りることだと思うのでtwitterを丸パクリ参考にします。
※ちなみに、実際にはMySQLを使っていなかったりするので、丸パクリできるほどの知識がないのが現状なんですよね(-ω-｀;)

具体的にはこちらのページでコラムが書かれているのですが、とりあえずやりたいのは以下の2つです。


1.マスタースレーブ･･････マスター(本体)一つとスレーブ(複製)複数を作る⇒アクセス負荷対策
2.パーティション･･････テーブルを何らかの形で分割する⇒メモリ分散対策


軽く調べてみたところ、これらは共にMySQLにて標準でサポートされているらしいので、実装はそんなに厳しくはなさそうです。
マスタースレーブ構成が目指すところは、兎にも角にも負荷分散です。皆さんにはたくさんあるコピーにアクセスしてもらい、その更新情報を非同期にマスターに随時まとめていく、そういう仕組みです。
仮にスレーブ側が4つあると、単純計算でサーバー負荷は1/4になるワケです。

まぁ、「非同期に」ってとこをちょっと考えれば分かるかもしれませんがオートインクリメント使えなくねっていう問題が発生するんですよね。これに関しての問題解決はしなければなりません。
スレーブの更新結果を受け取るのではなく、マスターの更新結果をスレーブが受け取る、という形じゃないとオートインクリメントが実装できませんね。どうするんでしょうね。
まぁ100%解決策はあるのでいつか調べます。ないと困りますからねオートインクリメント。


パーティションに関しては、twitterでは月ごとにテーブルを分割しているそうなので、僕の方でもそれに習おうかなと思っています。
これに関してはそんなに難しくなさそう･･････？例えば追加読み込みであれば、取得したレコードの数が規定数以下だったら次のテーブルを追加で読み込む、とかすれば良いわけですしね。
ということは、Ajaxで渡すべき値に「年月」が加わるワケですね。いちいち計算してたらしょうがないですしね。


ほんとは、もっと本格的な対策を講じる必要は将来的に出てくるかと思います。
メソッドの方を弄ったり、サーバーの性能的限界などなど。レンタルサーバーがどこまでやれるかも分かりませんし、場合によってはサーバー移転をしなければならないかもしれません。
でも、そんな難しいことを考えても仕方がないので、今はこういった基本的なことだけをやっておけたら良いかな、と思っています。