ＡＳＩＤ特性が必要な場合ＲＤＢ，いらなければファイルで、それらを意識せずアクセスしない？

うん？？と思った記事があるんで、ちょっと確認。

ここの話
「クラウドによるIT補完計画」とは
http://slashdot.jp/it/09/07/02/173247.shtml
なんだけど、元ネタは、ここ

もう1つの、DBのかたち、分散Key-Valueストアとは
http://www.atmarkit.co.jp/fjava/rensai4/bigtable01/01.html

ってことで、まあ、元ネタのほうで考えましょうか（以下斜体は上記@ITの記事から引用）

---

クラウドなどで使われる、分散ＫＶＳ（Key-Valueストア）というのがある。
で、こいつは、ＲＤＢにくらべ、

トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。


ってかいてあるけど、つーか、もともと、ＡＣＩＤ特性を確保するためにＲＤＢが
出てきたので、そうでなきゃ、ファイルシステムでＯＫ。


　ＡＣＩＤ特性はつまり、中途半端にデータベースがコミットされることはないってことであり
（たとえば、給与振込みで、会社の残金－給与額と、従業員の残金＋給与が同時に
　行われるってこと。会社の残金から給与分が減っている＝会社的には振り込んだのに、
　従業員の給与は増えていない（従業員から見ると振り込まれていない）ということがない）
　
　これを実現するために、トランザクションのコミット、ロールバック、排他制御がしっかり入っている。

　現在の事務系アプリにおいて、たとえば、給料を支払ったのに振り込まれてない、なんていうことは
まず許されないから、このＡＣＩＤ特性が担保されないっていうのは、超困る。
　そこで、事務系アプリにおいては、たいていＲＤＢを使う。

---

　でも、もし、ＡＳＩＤ特性を担保しなくてよい場合（データ検索など）では、ＲＤＢがある前のシステム、つまり、ファイルシステムでよい。

　ファイルシステムは、ファイル名をキーとし、中身をバリューと考えると、すでに、キーバリューの形になっている。そして、ファイルシステムはすでに分散されている。

　早い検索を行いたければ、インデックスを作るけど、実は、Ｌｉｎｕｘなどでは、これはリンクにより
実現できる（同じキーに複数値があることがある場合、ディレクトリがキーになる場合があるけど）

　ただ、ファイルシステムでは問題ありありという場合は、ＸＭＬ（ＸＭＬＤＢ）というアプローチもある。

　ってことで、分散ＫＶＳ（Key-Valueストア）は、こちらのほうに属する技術だろう・・・

---

　ただ、今のアプリ開発側から見ると、データベース、ファイルの差異をなくすため、ＤＡＯ(データアクセスオブジェクト＝ってか、データアクセス層）を作ってアクセスする

　　　　　　　　　　　　　　　　　　　　　　業務アプリ
　　　　　　　　　　　　　　　　　　　　　　　　｜（入出力）
　　　　　　　　　データアクセス層（ＨａｓｈＭａｐの配列などでデータを渡したり、ＤＯＭで渡したり）
　　　　　　　　　　　｜　　　　｜　　　　　　　　　｜　　　　｜　　　　｜　　
　　　　　　　　　　ＲＤＢ　　プロパティファイル　ＣＳＶ　　ＸＭＬ　分散ＫＶＳ？？

　ＤＢに直接アクセスするのでなく、１回抽象化した層を挟む。
　そして、パフォーマンスなどによって、ＲＤＢにするか、ファイルにするか、オンメモリにするか（＝セッションに入れておくなど）を決める。
※セッションに入れたくても、ロードバランシングで、さまざまなサーバーにデータが飛ぶ場合、セッションに入れられず、分散ファイルに保存するなんてこともある。なので、一概にどれがいいとはいえない。

　もし、データアクセス層を作らないと、開発者全員が、アクセス方法を知らないといけなくなり、人月単価が高くなり、ソフト開発競争力がなくなる。そこで、簡単にアクセスできるＤＡＯを作成し、差を吸収する。

　ということで、別に分散ＫＶＳが出てきたところで、データアクセス層で差を吸収してしまうので、たいした問題でなく、「出来損ないの群体として行き詰まったITシステムを、完全な単体インフラへ人工進化させる」（クラウドによるIT補完計画）というほどのはなしかあ？ってなります。いや、ＡＳＩＤ特性をばっちり持った超高速アップデート方式が見つかれば、そっちのほうが、利用価値は高いです。

　なので、それを実現する、分散型インメモリ・データグリッド・ソリューションである、Oracle Coherenceのほうが、話的には面白いと思うけどなあ・・・

ＩＰＶ６に移行”しない”ための、ラージスケールＮＡＴ

　ＩＰアドレス枯渇問題。１つの解決策としては、ＩＰＶ６に移行することだけど、
　もう１つの解決方法として、プロバイダ（ＩＳＰ）ごとにグローバルアドレスを持って、各顧客はＩＳＰが発行するローカルＩＰアドレスを使うというものがある。これがラージスケールＮＡＴ。
　ＩＰＶ４枯渇後は、ＩＰＶ６アドレスと、ラージスケールＮＡＴによるアドレスの両方を発行する等といわれている。

　で、そのそのラージスケールＮＡＴ（ＬＳＮ）について、日経コンピューター２００９年６月２４日号１２６ページあたりに、問題点が書かれている。ここで、「利用者が特定できない」っていうのは言われていたけど、それ以外に、たしかに、セッション数の問題はあるよね。
　外から見ると、同じＩＰになるので、ＩＰごとにセッション数制約とか、その手の制約があるよね。

　今、ケータイなんかが、おんなじ仕組み（ケータイでネットを使う場合、キャリアがＤＨＣＰにより、アドレスを貸し出している）だけど、そのため、パブリッククラウドのようなサービスで、１アドレス何アクセスというのだと、キャリア全体でのアクセス数になってしまうため・・・なんていう話題がでることがあるけど、あんな様な話は出てきそうだ。

　ま、ＩＰＶ６にいっちゃえばいいってことはあるんだけどね。
　Ｖ６に行くには、ソースの直しは必要だよね。むしろＶ４用のチェックを入れちゃってるようなところもあるし・・・

Ｐ．Ｓ　そーいう意味では、もっと長い期間使っているのに破綻していない電話番号は偉大？？

OpenSourceWorld、行きましたあ？

　みなさーん、７月１日、２日（つまり、昨日まで）やっていた、OpenSourceWorld 2009って、行きましたあ？
　昨日、行ってきたんだけど、雨だからってこともあるけど、じみでしたあ・・・

　OSCのほうが、にぎやかだし、ＯｐｅｎＳｏｕｒｃｅのほうの話に限れば、展示・講演も多そう・・・
　ＬｉｎｕｘＷｏｒｌｄがかわって、これになったみたいだけど、なんか、かなり地味になって、別物と考えたほうがよさそうですね。
　２０００年初頭ころの、ディストリががんがん出てきたときとは、大違いです。
　衰退しちゃいましたね・・・っていうか、ＯＳＣに取って代わられたというのが、正しい判断？

　ＵｌｔｒａＭｏｎｋｅｙのコミュニティが出ていたくらいかな、目新しいことは。
　あと、小江戸らぐが、ある雑誌の萌え小型化をしていた。

　ＭｉｃｒｏｓｏｆｔのＰＨＰ on IISに、とっても興味があったんだけど、
　そこにいくには、おねーさんが、アンケートを取ろうと、しっかりガードしていたので、
　アンケート答えたくないウィリアムのいたずらは、まったく見えませんでしたよ・・・

　
　Next Generation Data Center 2009も同時開催だったんだけど・・・
　ま、こちらは、あとで別立てで書きます。

　一言で言い切っちゃうと、こちらも地味。
　だって、２つあわせて、東京国際フォーラムの展示スペースで収まっちゃうんだから（＾＾；）