Oracle RAC + memcached でオラクルでも快適なセッション管理を!

セッション管理に向いているデータベースは MySQL ? Oracle ?」に書いたとおり、Oracle だけでセッション管理をするのは現実的でなさそうなことがわかってきました。

もう一度復習すると、Oracle は LOB 型のパフォーマンスが悪いために、insert の処理コストが高すぎて、結果全体のレスポンスが悪くなります。あの実験以降もいろいろと検証を重ねてきて、例えば、

ID    int          NOT NULL,  ※セッションID
SUBID int          NOT NULL,  ※セッションID毎に1〜の通番を振って4000byte越えを
DATA  varchar2(4000)  NULL

のようなセッションテーブルを定義して、セッションデータを4000byte毎に区切って格納したりと苦し紛れの方法を検証したりしましたが、どれもピンとくる結果になりませんでした。(※NOLOGGIN モードなら許容できる速度かも。)

で、結論。何千万というお高ぁ〜いデータベースシステムを構築しても、やっぱ memcached 必須でしょ。

- スポンサーリンク -

で、オラクルの RAC と組み合わせるとこんな感じの仕組みになるのかなぁ〜と思ったり。memcached サーバを別に用意しても良いんだけど、それだと memcached サーバの冗長化なんて事になるので、せっかくの RAC の冗長化をいかそう!ってコンセプトで。

セッション管理は全部 memcached にお任せして、本当に保存が必要なデータは oracle に流すという。

rac_memcached.jpg

まぁ RAC っていっても、そこらに転がってる RAC なんて結局 HA と変わりないノード数2なので、memcached を sync させてもそんなにコストにはならないかなぁと。未検証だけど。sync させておかないと、ノード1が死んだときにセッションが引き継げないのでマズイよなぁ〜やっぱり。

アプリ側ではノード1を memcached のプライマリにでもしておいて、適時 VIP とかを調査して RAC 障害が発生していないかを監視しつつ、障害児にはノード2のセカンダリ memcached へアクセスできるようにしてあげればOK?

なんて構想を練ってます。それにしても memcached 速いわぁ〜。mysql 版とベンチをとっても数十倍も高速ですなぁ。

__追記(備忘録)__
メモリさえ許せば、参照系データに対する SQL のクエリーキャッシュ(いわゆる SQL とその結果をキャッシュする)も memcached 上にのせると、さらに全体的なパフォーマンスを向上できてウマーなことになりそうだなぁ〜

- スポンサーリンク -

関連する記事&スポンサーリンク