更新可能な分散キャッシュ

DB2固有のデッドロック問題を前向きにとらえて解決策を考えていくと
いろいろな解決策がある。



まずはWebSphere CommerceではCMPをAccess Beanでラップして
ブラウザからリクエストが来てレスポンスを返すまでの短い期間のキャッシュを
実装している。

EJBのアクセスでDBサーバへのSQLアクセスが頻繁に発生し、レスポンスの低下と
デッドロックの多発がDB2では起きるので、短い期間だけキャッシュするのである。
ブラウザにレスポンスを返すコミットの直前にまとめてDBに更新を書き込むやりかた。

デッドロックは減るが、DBサーバの負荷は少ししか減らない。



J2EEのEJBの仕様で、EJBの分離レベルを設定するようになっている。


	Serializable (== Repeatable Read)
	Repeatable Read (== Read Stability)
	Read Committed (== Cursor Stability)
	Read Uncommitted


いちばん効率的な設定はRead Committed (== Cursor Stability)である。
これは、JDBCにしようがEJBにしようがDBにSQLアクセスが必ず発生することを意味している。


一時BEAもIBMもEJBサーバ層をクラスター構成にして提案していたことがあったが
分離レベルがREAD_COMMITEDでは、データを参照すると必ずDBに対するSELECTが発行されることになり
DBサーバの負荷が全く軽減しないので両者ともやめてしまった。


                          HTTPサーバ#1+アプリケーションサーバ(Webモジュール/Jsp/Servlet)  アプリケーションサーバ(EJBモジュールt)#1
ブラウザ→ロードバランサ→HTTPサーバ#2+アプリケーションサーバ(Webモジュール/Jsp/Servlet)→アプリケーションサーバ(EJBモジュールt)#2→DBサーバ
                          HTTPサーバ#3+アプリケーションサーバ(Webモジュール/Jsp/Servlet)  アプリケーションサーバ(EJBモジュールt)#3


データベースに対する負荷をうまくクラスタ構成のアプリケーションサーバに分散できないと
スケーラビリティの問題を解決できないのである。




1999年頃、松井証券/Fitechはインターネット証券システムで
更新可能な分散キャッシュ技術を使って他社より、
ものすごく速い実装を売り物していた。
対照的に日興ビーンズはWebSphereで実装していたが結果は一目瞭然である。


仕掛けは単純で、EJBに似たORマッピングされたキャッシュDAOを作成し
データベースへのアクセスをDAO経由で行う。
DAOはキャッシュなのでデータベースへのSELECTは発生しないので
DBサーバに対する負荷を軽減し、アプリケーションサーバに負荷分散できるのである。

このDAOは更新できて、表の更新があると
表のトリガーを使ってDAOのキャッシュを無効にする(Invalidate)仕掛けがある。

次にDAOをアクセスするときはデータベースからデータをリロードするのだ。

実はこの単純なキャッシュ実装でWebサイトのDBサーバへの負荷は劇的に減ってしまう。
単純に２０倍から３０倍のスループットの増加を望める。

さらにアクセスユーザ数が増加していっても、
アプリケーションサーバのクラスタの筐体を増やせばいいだけなので
スケーラビリティの問題も改善できるのである。

Fitechlabsの「xTrade」という製品 http://www.fitechlabs.co.jp
このアイデアは今年３月にUSで特許がとれたらしい。

Apache JakartaプロジェクトのTurbinフレームワークの「JCS(Java Caching System)
	http://jakarta.apache.org/turbine/jcs/index.html

Oracle9iにパクられてしまって
	JCache/ Object Caching Service for Java (OCS4J) 2.0 http://otn.oracle.com/products/ocs4j/content.html
	JSR 107にもなっている。 http://jcp.org/en/jsr/detail?id=107

BorlandのJDataStoreという製品

Microsoftにもパクられて
	.Net Cache
	System.Web.Caching http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcacheapis.asp


になっている。

現在ZEUS2フレームワークでは業務がSQLを発行する実装である。
負荷テストの結果をみればわかるようにDBサーバに負荷が集中して
スケーラビリティの問題を解決できない。

DAOというよりは
リレーショナルデータベースをJavaのインスタンスにマップする
ORマッピングはやはり必要である。

現在はORマッピングの遅さを以上のような更新可能な分散キャッシュ技術で解決する時代になった。

End of FILE.