読者です 読者をやめる 読者になる 読者になる

手作り感あふれる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の内部でやってることかもね...