上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コミュニティ検索 »
以前も書いたように、所謂Web屋さんたちの間では当然のように使われているMySQLの並列化&Read/Writeを分けるアーキテクチャですが、Javaでこれをやろうとするとイマイチ難しかったりします。

なぜかというと、Javaのトランザクション機構は良く出来すぎていて、自分でデータソース変えまくってRead/Writeを処理ごとに分けるのが難しい(というかめんどくさい、慣れの問題?)からです。
プログラムレベルではほとんど意識しなくてよいようにフレームワークなどを作ってしまうため、プログラムでRead/Write先が違うことなんてないんです。すみません。

で久々にトラバってみたyujikさんの記事でも注目の「Java分散キャッシュ」が、Javaにおいては救世主になりうるかも。いやならないのかも。

カテゴリはWeb2.0にしたけど、実はJava中心の話で、SOAにもちょっと関連。


とりあえずyujikさん、ブログでもよろしくということで。

でまあ、分散キャッシュ(メモリ共有含む)ですが、イケてる部分もありますが、イケてなさそうな部分もあると。
せっかくなのでちょっとまとめてみようかなと。

ちなみに分散キャッシュとは、Tangosol Coherence、JBossやHibernateでおなじみTreeCacheやhcache辺りが有名ですが、
これら以外でも同じことができるもの、例えば
JavaSpacesGigaSpacesが実装としては有名)、Prevayler(これはどういう分類だろう?)、C-JDBC辺りでも同じことが実現できるという意味でここでは一緒くたです。
たぶん同じメリット/デメリットがあるはず。ちゃんと調べてないけど。

以下はDBの前に分散キャッシュを置いた前提。


分散キャッシュのメリット


  • Readが早い

  • Writeが非同期に実行可能 = Writeも早い

  • VMまたがってもトランザクションが使える = 排他可能

  • フェイルオーバー可能 = 可用性も高い

  • 上記特徴からO/Rマッパーと相性が良い

  • その他一般的なメリットはこちらの製品ページを参照
    (どこまでホントに使えるか、というのが実は一番のネック?)


分散キャッシュのデメリット


  • Read早いけど、アイソレーションレベルってRepeatable Read以上は無理じゃない?

  • Writeっていつされるの?⇒Read遅延タイミングがよくわからん

  • フェイルオーバーってどのタイミングの分まで実施されんの?

  • O/Rマッパーのキャッシュの仕組み(HibernateだとSessionに保存されるやつ)との整合性はどう取ればいい?

  • DB中心ではなくオブジェクト中心の設計をする必要あり 
     ↑ これは排他の単位がオブジェクトであることも強く影響

  • その他一般的になってないノウハウが少なすぎ


こうして見ると、やっぱり「使ったことないから不安」みたいな要素が多いですね。
頑張って一度使ってみればいいんでしょうか?



Web2.0サービス?のインフラ

Amazon社長のインタビューにもあるように、Linuxブレードサーバを並べまくるアーキテクチャは、実際に稼働しており成果を残しています。
DBはMySQLではないかもしれないですが、サービス指向のアーキテクチャになっていることは間違いなく、分散技術は確立されていると言えます。
MySQLならば日本ではmixiやGREE、はてななんかで同様に成果を出していると言えます。

それでもあまりそういったノウハウは聞こえてきません。どうやらサービス提供者は、本業が忙しくてノウハウを伝えることにまで意識が向かないし、そこに価値をあまり見出していないようです。
SIerからするとよいコンサルネタだったりするので、もったいないと思ってしまうのは、やっぱり僕はまだSIerなんでしょうねw

Web2.0企業代表と言えるAmazonが実践している分散アーキテクチャは、今後普及を見せていくことでしょう。既に普及していると言えるかも知れません。
ただ、今はそれはLAMPを中心としたものですが、今後は分散キャッシュ機構なのかJavaSpacesなのか、はたまたGlobusなのかはわかりません。
ネットワーク技術も同様に重要になっており、分散アーキテクチャの基盤であることは明白です。

少なくとも一つ言えるのは、こういった新技術をサービスに「活かす技術」がより求められる時代になっていくのだろうと。
漠然とですが、潜在ニーズは相当あると思っています。
そしてこういうところが、エンタープライズとWeb2.0との接点かなとも。
スポンサーサイト
コメント (2) | トラックバック (0)
コミュニティ検索 »
トラックバック
この記事のトラックバックURL
http://completemirage.blog55.fc2.com/tb.php/21-b9197684
この記事にトラックバックする(FC2ブログユーザー)
コメント

mixiのスケーラビリティ

通りすがりのものです。
mixiのスケーラビリティについては、下記
500万倍のスケーラビリティ
http://blog.miraclelinux.com/yume/2006/07/post_7ad0.html
LiveJournalのアーキテクチャ
http://blog.miraclelinux.com/yume/2006/07/livejournal_a718.html
などを参照ください。
2006/07/18(火) 23:04 hyoshiok URL [編集]

コメントありがとうございます

GREEの勉強会での公演聞かせて頂きました!
PostgreSQLのベンチマーク結果は面白かったです。
カーネルやDB周りまではソース読めないので、他は感覚で聞いていましたがw

mixiのアーキテクチャ情報ありがとうございます!
実は私も知り合いにこういう本があると言う話を、このエントリ直後に聞いていました。
Flickrの人が書いているらしいです。
http://www.amazon.com/gp/product/0596102356/103-6352339-2211808?redirect=true

mixiがスケールアウトしてきた話は、別のイベントかなんかで聞いたことがありましたが、実際それを実現するのに相当なノウハウが貯まったと思うのは私だけでしょうか?
ぜひ私もmixiの方にお話聞きたいですねえ。会う機会・接点が現状は全くありませんがw

そのノウハウはもったいないというか、ぜひ欲しいものですね。
というか今ならオープンにするのが世の流れなのかもしれませんが。
私も何か世の中に貢献できるよう精進したいと思う、今日この頃です。

あと、hyoshiokさんのカーネル読書会に出られるよう、ソース読解能力も精進しておきます。
2006/07/26(水) 00:28 Miyazima URL [編集]







非公開コメント
プロフィール
 

miyazima

Author:miyazima
常に変化を好み、面白いことを探しています。次の次は?

カレンダー
 
03 | 2017/03 | 04
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31 -
カウンター
 
天気予報
 

-天気予報コム- -FC2-
ブログ内検索
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。