手作り感あふれるRDBチューニングについてのだらだら思考メモ
開発メモ: Kyoto Tycoonのバイナリプロトコルを読んで、永続化やレプリケーションにはMySQLなどのRDBを使い、よく参照され、あまり更新されない（というか参照でスケールアウトする場合にはそういう仮定があるはずだ）一時viewの内容をKey-value storeでキャッシュしておき、スケールアウトはそちらで行う。とかいうネタについて考えてみた。DBに詳しい人ならいまさらなネタだと思うけど、以下、自分用にメモです。
Kyoto Tycoon/Kyoto Cabinetのレプリケーション機能などを使って、RDBのviewの更新差分をとりこんでいくわけだ。今回のバイナリプロトコル実装は、そこんところが主たるターゲットらしい。
自分で作るのは以下の部分だけ
ところで、よく使うviewをKVSに乗せるようにロジックを組み替えるほうが、実運用中は負荷が低いのでは？？？いや、その工程のコストとタイムラグ、バグ混入の危険性は無視できないので、RDBによるモデルの見通しの良さ（からくるバグの頻度低下）を維持したまま、チューニングを自動化してしまうのは正当化できるんじゃなかろうか、とか妄想。
そもそも、、
queryの頻度を分析して、hotspotとなっているviewをkvsというかindexを使ってアクセスできるテーブルとしてキャッシュする、、、これってのは普通にRDBの内部でやってることかもね...
