Hatena::ブログ(Diary)

winplusの日記 このページをアンテナに追加 RSSフィード

2009-10-18

1時間ごと更新なのにリアルタイムとは、これいかに。

楽しいアプリ制作の会 #08(終了) « 楽しいアプリ制作の会 [たのアプ]に参加して思ったこと。

報告1:クラウドの一般的なご紹介 => 分散DBが新しい。

報告2:Google App Engineでのアプリ開発 => BigTableが使いこなしのキモ。

報告3:Windows Azureでのアプリ開発 => SQL AzureではSQLが使えるよ。

報告4:オープンソースMapReduce/分散ストレージ実装、Hadoopの紹介 => RDBはスケールしない。やっぱり分散だね。

端折りすぎですが、やっぱり分散DBというのが大きなポイントになっていると思いました。SQLが使えない => JOINが使えない => 正規化できない => 値の整合性を自前で保証しないといけない。ということでアプリケーションの「つくり」が大きくかわる。

とくに報告4の「悩める成長企業のお話」がよくできていて、ハード面でRDBをスケールさせるのはすぐ限界がくるし、それ以外のくふう(非正規化やキャッシュやレプリカなどなど)をすればするほど、強い意味でのACIDは保証できなくなってくるのでは?だったらRDBを利用する意味がないし、で、分散DBをどうぞ、と。気になって、分散DBではACIDをどのように保証しているのかと質問すると、保証できないし厳密なACIDが必要なシステムでは(少なくとも現状では)RDBと住み分けることになるとのこと。事例とかもサイト検索とかログ分析とか大規模なもので、いわゆる業務システム的なものはあまりなさそう。

結論がこれでは「あまりにも」なので、もう少し考えてみる。

 ここで、先ほどから何度か触れている「データの整合性」とは何かを、業務用の「会計ソフト」を例に上げて説明してみよう。例えば、八百屋さんで「60円で仕入れたリンゴ1つを100円で売った」こと(Sales Transaction)を記録する場合を想定しよう。

 会計ソフトが一般的な会計の常識に従って作られていれば、この1つのSales Transactionにより、少なくとも4つの変更がデータベースに加えられる。

1. 「手持ちの現金の増減」を記録するテーブルに「現金100円の増加」を記録

2. 「売り上げ」を記録するテーブルに「100円の売り上げ」を記録

3. 「在庫の増減」を記録するテーブルに「リンゴ1つ減少」を記録

4. 「経費の計上」を記録するテーブルに「仕入れ値60円の経費計上」を記録

 八百屋さんのビジネスにとって大切なことは、この4つの変更が同時に行われること。このうち一つの変更だけが欠けていたりすると、テーブル間のつじつまが合わなくなってしまい、年度末の決算がちゃんとできなくなってしまう。

 この「データの変更が中途半端でつじつまが会わなくなってしまっている状況」のことがすなわち「データの整合性が壊れた」状況である。

Life is beautiful: Ruby on Railsの「えせMVC」の弊害

このような状況を避けるために、RDBにはトランザクション機構があってACIDを保証している。分散DBだと「この4つの変更が同時に行われること」が保証されない。たとえば、[1.]だけ成功して[2.]が失敗すれば、売上がないのに現金が100円多いという状態になって困る。これを解決するには、「4つの変更」を「1つの変更」にするしかない。つまり、「60円で仕入れたリンゴ1つを100円で売った」ことを「1つの変更」として記録すればよいのだ。「Sales Transaction」というテーブルだけをつくって、そこに「60円で仕入れたリンゴ1つを100円で売った」とか「80円で仕入れバナナ1つを150円で売った」とか記録しておく。いまある現金を知りたければ、「Sales Transaction」に記録されている仕入額と販売額から、そのたびに計算すればよい。力業こそ分散DBのやり方なのだ(dragonさんによる)。うーん、これで本当にうまくいくのか分かりません。

もうひとつ、分散DBだと「60円で仕入れたリンゴ1つを100円で売った」ことが、システム全体として見たとき、いつ記録されたことになるのか、という問題もある。つまり「60円で仕入れたリンゴ1つを100円で売った」という記録が、あるノードでは書き込みに成功しても、他のノードでは書き込み前かもれしないし、失敗するかもしれないし、リトライ中かもしれない。このため、現金の有高を問い合わせたときに同じ値が返ってくるとは限らない。これは回避しようがない。もちろん一定の時間が経過すれば、どのノードに問い合わせても同じ値を返すようになる。だとすれば、結局、その業務がどこまで「リアルタイム」である必要があるのか、がポイントになる。個人的な経験だけいうと、かなり厳密に「リアルタイム」な処理を求められるのは在庫引き当て位かな。夜間のバッチ処理で整合をとればよいとか、クライアントのデータを1時間に1回だけサーバに更新するとか、それで十分だったりすることも多い。それこそ、1時間ごと更新なのに、業務としては「○○リアルタイム・データ」と呼んでいたりするし。うーん、ここも、それなりに回避できるのかも。

上記2つの整合性(の無さ)は、yohei-y:weblog: CAPのCとACIDのCで指摘されているところかな。とにかく、うまくすれば分散DBで業務システムという可能性もありそうな感じもします。

勉強会は盛りだくさんの内容で、予定を大きくオーバーして終了しました。アンケートも提出せずにいそいそと退出していまいました。すみません。

あとは自分への課題。以下をちゃんと読むこと。

分散アーキテクチャにおいて一貫性と交換でスケーラビリティを手に入れる

SOA実践の最前線:第5回:クラウド時代のトランザクション | 豆蔵ソフト工学ラボ

クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future

EventuallyConsistent - (corrupted, sorry)

とくに以下。

Cloudの技術的特徴について--- ScalabilityとAvailability ---

【追加】以下の記事では、ACIDなしでの業務の可能性を考察されています。この延長で業務を見直すのは、分散DBを採用しないとしてもアリだと思います。

クラウドの一貫性って - noopな日々

【追加:2011/3/2】以下の記事は、まさにタイトル通り。ちゃんと試しているところがすごい。ぼやっと考えているだけではダメですね。

あえてNoSQLでクラウド上にエンタープライズアプリを作ってみる : 小野和俊のブログ

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/winplus/20091018/1255862867